oss-sec mailing list archives
Re: Healing the bash fork
From: Rich Felker <dalias () libc org>
Date: Tue, 30 Sep 2014 18:19:59 -0400
On Tue, Sep 30, 2014 at 08:41:24AM -0500, Kobrin, Eric wrote:
"innocuous looking setuid program" made my day ;)We should take care not to blame all and everything to bash.I don't find that blame is a useful tool for fixing security problems. What's more interesting to me is: what system components are in a position to help. If a change in bash can make a bunch of "innocuous looking setuid programs" not be vectors for the import of malicious functions, let's do it.
While it sounds nice in theory, I don't think this approach really works, at least not in general. There's a whole school of security dedicated to removing documented functionality that's deemed "risky" that completely ignores the security implications of breaking the previously documented interface contract. The best-known might be dummying out printf/scanf %n support; if a program is expecting %n to work as documented, and needs the correct offset to be stored in the target object, very bad things could happen (buffer overflows, random memory writes, etc.) if the offset is never written and the target variable remains uninitialized or still holds an outdated value. I'm going to play the devil's advocate here: what if somebody has a script that relies on redefining certain commands via bash function export/import in order to suppress functionality that could be dangerous when the child script is invoked to process untrusted input? (Perhaps the author of the exporting script wants to avoid making changes to the script that runs in the child process.) In the case of function importing, I do think the feature should just be removed, despite the risk of changing the documented functionality. It's basically impossible to use correctly (unlike my above example, %n, which is trivial to use safely), and it's "wrong" not just on a security basis, but also on a language-semantics basis (a really really ugly kind of dynamic scope that's inherited from outside the program). But I don't think "component X is in a position to help" is inherently a valid argument that component X should attempt to help. "Blame", or more specifically interface contracts, are a useful concept that should not be thrown out. Rich
Current thread:
- Re: Healing the bash fork Mark R Bannister (Sep 30)
- <Possible follow-ups>
- Re: Healing the bash fork Sven Kieske (Sep 30)
- Re: Healing the bash fork Mark R Bannister (Sep 30)
- Re: Healing the bash fork Sebastian Krahmer (Sep 30)
- Re: Healing the bash fork Kobrin, Eric (Sep 30)
- Re: Healing the bash fork Sebastian Krahmer (Sep 30)
- Re: Healing the bash fork John Haxby (Sep 30)
- Re: Healing the bash fork Ed Prevost (Sep 30)
- Re: Healing the bash fork Rich Felker (Sep 30)
- Re: Healing the bash fork Kobrin, Eric (Sep 30)
- Re: Healing the bash fork Michal Zalewski (Sep 30)
- Re: Healing the bash fork Simon McVittie (Sep 30)
- Re: Healing the bash fork Mark R Bannister (Sep 30)
- Re: Healing the bash fork Tavis Ormandy (Sep 30)
- Re: Healing the bash fork Ed Prevost (Sep 30)
- Re: Healing the bash fork Zach Wikholm (Sep 30)
- Re: Healing the bash fork David A. Wheeler (Sep 30)
- Re: Healing the bash fork Michal Zalewski (Sep 30)
- Re: Healing the bash fork Stuart D. Gathman (Sep 30)
- Re: Healing the bash fork Ed Prevost (Sep 30)