[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20140930221959.GH23797@brightrain.aerifal.cx>
Date: Tue, 30 Sep 2014 18:19:59 -0400
From: Rich Felker <dalias@...c.org>
To: oss-security@...ts.openwall.com
Subject: Re: Healing the bash fork
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
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.
