[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20141008235332.GE12633@sentinelchicken.org>
Date: Wed, 8 Oct 2014 16:53:32 -0700
From: Tim <tim-security@...tinelchicken.org>
To: oss-security@...ts.openwall.com
Subject: Re: Thoughts on Shellshock and beyond
> Well, in the specific context of bash, where it's being singled out as
> a major contributing factor to the bug: how would you establish an
> out-of-band channel for exporting functions that keeps them separate
> from "pure" data? As far as I can tell, there is no trivial and
> portable way.
Well, I think we can all think of a few options, some more portable
than others. The current namespace change is one option, obviously,
but one might go a different route with more time to design it
initially. Other ideas:
1) A single dedicated environment variable for all function exports.
e.g.:
BASH_FUNCTIONS='f() { ... }
g() { ... }
...
'
It can be easier to defend a single environment variable than
multiple, and something like "BASH_FUNCTIONS" would become much more
like LD_PRELOAD from a threat perspective.
2) A bash-specific file handle. Before forking, bash sets up a pipe
to share with it's child. A single special environment variable (like
the above) instructs the child which file descriptor to read, which
contains the function definitions (or perhaps, even a serialized
compiled form of the functions for extra speeds!). Is this safer
than #1? I'm not sure, but it seems like it might be harder for an
attacker to control both the pipe and the env var in specific
situations.
> Or, in a slightly broader context: would a shell environment that
> enforces strict and unconditional separation between any and all data
> variables (even of the trusted kind - keep in mind that the author of
> this code clearly assumed that the environment is trusted) and the
> stuff that ever gets executed would be easy to construct, useful, or
> would ever have a chance of gaining comparable popularity?
I don't see how the current fix or the above approaches would somehow
restrict popularity of this feature. Those who do use export wouldn't
notice how the functions are transmitted in any case, right?
> I think that instinctively shouting "code and data should be
> separated" in this context, if we don't have good answers to these
> questions, is just... well, kinda counter-productive =)
I think we do have good answers for the technical issues related to
this specific bug. What would be better answers?
The thing is, when I see design choices like the ones already
discussed, they immediately raise red flags in my mind.
Similar design choices in similar contexts in obscure systems that
I've tested raise red flags for me, even if I can't pinpoint a
vulnerability at the time.
For some reason, these things don't raise red flags for many
developers. Why? How can we communicate the potential dangers of
similar choices?
My debates with the Apache Struts folks kind of floored me, because it
is completely obvious to me why you wouldn't use a complex scripting
language parser to directly interpret remote user input. To them it
wasn't and they are still resistant to changing that approach.
> Sure. So what specific implementation advice in the spirit of
> "separate code and data" should have been provided for bash that would
> have prevented a developer who assumed that the environment is trusted
> from making this mistake, while still getting exports to work on
> everything from Cygwin to AmigaOS?
"When an existing construct in a system is widely expected to be used
for storing data, avoid overloading it for use of storing code."
Is that any better? I don't know, I'm trying.
As I already stated, in the bash case it may have been hard to
anticipate in the time and place. However, CGI is damn-near 20 years
old. Were there not other examples of people storing potentially
malicious data in environment variables around that time? I have no
clue, I was still coding on my commodore 64 back then.
tim
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.
