[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <E1Xbyx9-0007kA-0X@rmm6prod02.runbox.com>
Date: Wed, 08 Oct 2014 17:39:23 -0400 (EDT)
From: "David A. Wheeler" <dwheeler@...eeler.com>
To: "oss-security" <oss-security@...ts.openwall.com>
Subject: Re: Thoughts on Shellshock and beyond
On Wed, 8 Oct 2014 13:50:17 -0700, Michal Zalewski <lcamtuf@...edump.cx> wrote:
> I don't really want to get in the super-existential debate about code
> vs data; I fully recognize that I'm gonna be in the minority on the
> list, and maybe even in the wrong, but I just can't get too passionate
> about this "best practice", having seen how few systems are (or can
> be) designed with it in mind; and how little of a difference it makes
> to them in the end.
>
> In a pragmatic sense, it's just that almost *everything* violates it.
> The CPUs we use, the memory allocators we have running on them, all
> the popular progamming languages and web frameworks. We still need to
> secure these systems, rather than saying "oh well, you should have
> done it differently from the start" =)
If there was some ironclad rule that "data and code must be totally isolated
at all times" then I agree it's absurdly impractical. Compilers
(including those in JIT systems) take data and generate code,
so if you can't mix them, then you can't run compiler-generated code.
Scripting languages wouldn't work. And so on.
But there's no reason to go that far. Just treat it as a
"rule of thumb" - a guide towards "safer practices"
that help people stay out of trouble. If you cannot apply the guideline,
life does not end, but then you *know* you're doing something more dangerous,
and that you'll need to take other (additional) precautions.
You don't have to make it ironclad, just a *move* in that ideal direction
can eliminate many problems.
> > It was certainly hard for the original developer to anticipate how
> > this would become a problem, given the time and place. But I think we
> > can try to learn from this and similar issues and hopefully make fewer
> > of these mistakes in the future.
>
> Sure. I'm not entirely convinced what the lessons are, though. I mean,
> you expect the next big issue in OpenSSL or Apache. You can probably
> even guess what it may be. You can maybe even make an intelligent
> guess about the language features or coding patterns that will
> contribute to it, or to learn from past bugs. With the bash bug... hm.
Hm is right. But I'm trying to make a crack at it, and I'm open to suggestions.
We as a software development community need to try to keep
learning from past mistakes. Our future mistakes should be NEW mistakes :-).
> I have no
> doubt that if the () { thing was mentioned in README.security, it
> would not have taken 20+ years to spot the bug.
I agree. And that, I think, is actually a countermeasure. Simply
documenting (specifically) the external interface, and then asking
"is that okay for security?", could go a long way.
I now have more content here:
http://www.dwheeler.com/essays/shellshock.html#detect-or-prevent
Hopefully it's a start at something worthwhile.
--- 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.
