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.