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.