[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20140927150614.GA4434@openwall.com>
Date: Sat, 27 Sep 2014 19:06:14 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Cc: Chester Ramey <chet.ramey@...e.edu>
Subject: Re: Fwd: Non-upstream patches for bash
On Sat, Sep 27, 2014 at 03:26:01PM +0200, Roman Drahtmueller wrote:
> By way of exposing the parser to potentionally harmful content: Is the
> importing of functions the only occasion, or are there more than this?
That's a great question. This aspect is arguably more important than
individual parsing bugs, in part because distros are already adopting
Florian's prefix/suffix patch turning parser bugs on function imports
into non-security issues.
Has anyone started reviewing bash for possible other code paths where
untrusted input may hit the parser?
Of course, what input is trusted vs. not may be unclear. Apparently, 20
years ago bash developers considered all env vars to be trusted input,
regardless of the names, which is how we got here.
Are bash scripts themselves exclusively trusted input, or should we
assume that portions of them (which?) may be untrusted (e.g., for
scripts generated by other programs, with some user input substituted
into them)? Clearly, it makes no sense to treat scripts as untrusted in
their entirety - the very purpose of bash is to do a wide variety of
things based on script contents - but maybe some individual tokens, etc.
within scripts may reasonably (and thus should?) be treated as untrusted
(to the extent possible within bash script syntax specs).
For example, what if a DHCP client sanitizes some input field and then
embeds it in a generated script? That's risky design, yet bash could
try to be robust when faced with scripts like that. Ideally, it should
behave only as specified, with no extra "features" available e.g. via
syntactically correct yet overly long tokens, etc.
Perhaps this boils down to the parser's robustness in general: treating
whatever we can (even within scripts) as untrusted input is the same as
having the most robust parser. This is why I wrote "arguably" in the
first paragraph above.
Now, is it realistic to make bash's parser so robust by finding and
patching individual bugs? I doubt it. We should find and patch the
bugs, but perhaps we shouldn't declare bash's parser robust, and perhaps
we shouldn't treat bash issues triggerable via untrusted script contents
as security issues. Perhaps we should instead declare bash unsafe to
use on scripts containing any untrusted input in them, and focus on
treating inputs to such scripts (env vars and command line) safely.
This also means that we should treat any programs that generate bash
scripts with (sanitized) untrusted input in them as unsafe, and patch
those to use safer mechanisms to pass (sanitized) inputs to scripts
(preferably use env vars with fixed names).
Comments?
Alexander
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
