[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALx_OUB1M5AByht4cAw5sx=6KZS-y0WCC9+Um-xSPDTDskCmcQ@mail.gmail.com>
Date: Tue, 7 Oct 2014 21:06:14 -0700
From: Michal Zalewski <lcamtuf@...edump.cx>
To: oss-security <oss-security@...ts.openwall.com>,
"David A. Wheeler" <dwheeler@...eeler.com>
Subject: Re: Thoughts on Shellshock and beyond
I feel that to some extent, "separation of code and data" is an
overused, overly simplistic, and arbitrarily applied mantra; it is
also the antithesis of interpreted scripting (and a good chunk of
other stuff in computing), for mostly valid reasons.
Heck, did you know that web fonts loaded and displayed by your browser
come with an embedded hinting bytecode that gets executed in a
miniature VM? And while this is kind of crazy, it's there because...
well, there aren't that many sane alternatives.
(Some 15 years ago, I would have given you a different answer - I even
had a pet project of a brand new operating system that would solve all
of world's ills. Today, I sort of accept that we're stuck with Unix
and that there's plenty of usability-security trade-offs that exist
for a reason, not just because other people are clueless ;-).
If I really had to pinpoint the causes (and that feels a bit like a
function-fitting exercise), I'd say that four things went
maybe-kinda-preventably wrong:
1) The feature was clearly added with no basic consideration for the
possibility of ever seeing untrusted data in the value of an
environmental variable. This lack of a threat model seems to be the
core issue, essentially precluding the discussion of potential "best
practices" such as namespaces, magical out-of-band function passing,
etc.
Ideally, post Morris worm, this assumption should have raised some
eyebrows. On the flip side, the code predated much of the modern
infosec practice, and it's unlikely that any security engineers
monitor bash development even today - so while it's easy to prescribe
solutions in retrospect, not sure how credible they can be...
2) The mechanism wasn't well-documented *and* just as importantly, has
fallen into near complete obscurity, largely precluding security
researchers from bumping into it by accident. The "not falling into
obscurity" part is not solvable, although it's a pattern that also
haunts the browser world, and may be an argument for aggressively
sunsetting features that do not catch on - something currently not
mentioned on your list.
The detailed documentation part is perhaps easier to tackle. The
security properties of shells are generally under-documented and
counterintuitivie, as evidenced in some of the followup discussions
where somebody was showing off a "safe" use of system() supposedly
rendered unsafe by Florian's patch. Decent security-centric docs,
authored or even merely just reviewed by the maintainers, would have
helped highlight the risk.
3) Apparently, for 20+ years, nobody in the security community has
ever read a book on shell programming that mentioned this feature, and
has never ventured deep enough into the man page, to have a "hmm, I
wonder how that works" moment when seeing a vague mention of the
feature.
I don't think that's easily fixable; as mentioned earlier, you sort of
start with certain assumptions on what may be a good use of your time,
and a behavior like this would be completely off the radar. You
wouldn't reasonably expect /bin/uname to phone home to a server in
Russia, so you don't check manually and it probably doesn't cross your
mind to create some sort of an automated validation model that
verifies the same. The infosec community is small, and there's plenty
of bugs to find, so we have to prioritize pretty heavily.
4) Following the original find but before the end of the embargo,
there was no immediate realization that the underlying parser is
complex and likely not designed with security in mind, and therefore,
that it will very likely follow a well-established pattern and come
apart under closer scrutiny. I'm not sure if this is an argument for
not having embargoes (perhaps) or for sanctioning more thoughtful
reviews of the proposed fixes. Or perhaps it's just a fluke.
/mz
On Tue, Oct 7, 2014 at 7:47 PM, David A. Wheeler <dwheeler@...eeler.com> wrote:
> All:
>
> Given the feedback here and elsewhere, I've tried to distill how to detect or prevent shellshock-like things ahead-of-time. My current try is here:
>
> http://www.dwheeler.com/essays/shellshock.html#detect-or-prevent
>
> More ideas and refinements would be welcome. I've also made a number of refinements (e.g., the timeline has more info, where the name came from has been identified, etc.).
>
> Thanks again!
>
> --- David A.Wheeler
>
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.
