On Sat, Feb 27, 2021 at 10:29:14PM -0700, Warner Losh wrote: > On Sat, Feb 27, 2021 at 9:34 PM Ihor Antonov <ihor_at_antonovs.family> wrote: > > > > > > > But isn't it well-known that ASLR/ASR/any-related-buzzwork does not add > > > any security, except imaginary? The only purpose of it is to have a > > > check-list item ticked green. > > > > I don't know if I should parse this as sarcasm (or any other form of > > "humor") or is a serious statement? But this does leave me with a whole > > bunch of questions.. > > > > If this is really how Konstantin is describing it then is it OK to say > > about this to the whole Internet? Why FreeBSD Foundation is paying for > > meaningless work then? Why members of the Core team do this work? Does > > this mean that FreeBSD is working to satisfy the silly needs of some fat > > customer? What about project independence and not being controlled by > > big money? > > > > Where can I read about ASLR and security myths? > > Why not spend time and explain why this does not work? > > > > Not to rise to the baitiness of all these leading questions (they really > are quite contrary to how our community usually comports itself, but for > the sake of civil discourse, I'll ignore).... > > I'll bet it has something to do with the many known ASLR attacks. One is > chronicled in https://www.vusec.net/projects/anc/ and elsewhere, which show > how MMU side channels can defeat ASLR. Or maybe he's familiar with the > offset2lib attack against Linux 64-bit ASLR documented in this paper > https://cybersecurity.upv.es/attacks/offset2lib/offset2lib-paper.pdf. > There's many others as well that show the shortcomings of ASLR and disclose > ways to defeat it using various clever means. Problem with these papers is that they put ASLR on a pedestal it doesn't deserve. If you take a look at PaX's original ASLR paper, you'll learn that ASLR was not designed to protect against local attacks. You'll also learn that the infoleak weakness was already postulated, even in its initial design and implementation. Attacks against the MMU require local code execution--for example, javascript in a browser. ASLR was never meant to protect against such a case. We must take the original design into account when discussing ASLR's valid shortcomings. The point of ASLR is to combine it with W^X. Without W^X, ASLR makes no sense. FreeBSD recently gained a W^X implementation that requires opt-in. When combined with W^X, exploit authors must chain together multiple vulnerabilities in order to successfully exploit. The combination of ASLR and W^X have forever changed the very foundation of exploitation. Both, when combined, do their job well--that of raising the economic cost of successful remote exploitation. Now that FreeBSD has both a form of ASLR known as ASR and a W^X implementation, FreeBSD can move on to other exploit mitigations, such as CFI and SafeStack (both of which are already integrated in some form in HardenedBSD.) This is likely to be my only response to this thread as I'm incredibly tired of rehashing the same arguments, especiall with regards to kib_at_, over the span of many years. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD GPG Key ID: 0xFF2E67A277F8E1FA GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 https://git-01.md.hardenedbsd.org/HardenedBSD/pubkeys/src/branch/master/Shawn_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:27 UTC