[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 8 Oct 2014 13:50:17 -0700
From: Michal Zalewski <lcamtuf@...edump.cx>
To: oss-security <oss-security@...ts.openwall.com>
Subject: Re: Thoughts on Shellshock and beyond
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" =)
> 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.
> So yes, documentation is important for setting expectations. But no
> one reads the manual, either.
It's not necessarily about every user reading the doc; just about
making sure that at least the infosec community understands the
exposure, which would mean that problems could be audited for,
workarounds could be implemented, or semantics changed. I have no
doubt that if the () { thing was mentioned in README.security, it
would not have taken 20+ years to spot the bug.
Cheers,
/mz
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.
