[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 7 Oct 2014 21:02:50 +0800
From: Pavel Labushev <pavel.labushev@...box.no>
To: oss-security@...ts.openwall.com
Subject: Re: Thoughts on Shellshock and beyond
On Tue, 7 Oct 2014 12:21:19 +0200
Hanno Böck <hanno@...eck.de> wrote:
> > What works is recognising and eliminating whole bug _classes_, or
> > deploying exploitation mitigation measures against them.
>
> I am fully with you on that. I advocate CSP and prepared statements
> where I can and Softbound+CETS (trying to kill all C-memory-errors)
> looks really interesting.
Are those the most significant things that come to your mind when you
think of bug class elimination/exploitation prevention/mitigation?
> However I won't go as far as claiming that fixing bugs is pointless.
It's proven to be pointless as the primary approach.
Eliminate some bug classes, make exploitation of another bug classes
more difficult and less reliable, mitigate the potential impact of their
exploitation. Then make some strong decisions and implement them:
rewrite the most insane parts of the code, get rid of some
insignificant legacy stuff, break some compatibility; make the
architecture more modular and language-agnostic to facilitate writing
new code in different languages, using different approaches (strict
process-level sandboxing, for example, as in SECCOMPv1); come up with
new, more bug- and fool-proof APIs; change your workflow, make security
a priority, be prepared to sacrifice bits of performance, etc, etc,
etc. And then, maybe start investing resources in finding and fixing
security bugs. How about that.
> Two thoughts on that:
> * We have to live with what we have now. We can talk that it'd be
There's a LOT of things we can do with what we have now, other than bug
fixing. Just a few good keywords: EMET, PaX, SECCOMPv1, POLA,
compile/link-time hardening/instrumentation.
> better to re-write all our operating systems in better languages, but
How about writing some new parts in "better languages"?
> even considering that happens it won't happen any time soon. We have
> to fix the bugs in the software we use today.
We have to fix the bugs we find, yes. But that doesn't mean we should
prioritize finding and fixing them on purpose, _instead of_
implementing superior approaches.
> * Heartbleed is an out of bounds memory read. Well understood and yes,
> it should be possible to implement mitigations against these kinds of
> things.
It IS possible. It's also important how we use the "old stuff" like
OpenSSL: do we choose to use the essential stuff only, like cipher
suits or even particular ciphers, and prefer something more reliable for
ASN.1, TLS, etc? Or do we build our crypto using this entire mess with
terrible APIs and not only suffer from Heartbleed but also fail to
implement certificate verification over and over again?
> What class of bug is Shellshock? "Weird feature invented in
> pre-Internet era"? How do you conquer this class of bugs?
Depends on the bug class definition is in this case. If it's narrow
enough ("insecure function import from environment variables' content
in bash"), it's possible to disable the insecure feature by default
(that's what some of the BSDs have done) or maybe even remove it
entirely. Compare that with "bug fixing" which is represented by
attempts to make function imports "secure" in this case, and we already
saw how "well" it worked. I wonder if anyone is still surprised.
> My point is: Even if we eliminate classes of bugs there will still be
> security issues that don't fit in your bug class cateogries.
Please, correct me if I'm wrong, but your point, as expressed both in
your initial letter and the blog post, lacks any notion of bug class
elimination/exploitation prevention/mitigation.
Content of type "application/pgp-signature" skipped
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.
