[rinon]

I'm not affiliated with Copperhead at all, but I am familiar with the sorts of techniques they are using. Exploit mitigations, such as Address Space Layout Randomization, Control-Flow Integrity, Fine-grained Randomization, etc. provide a layer of hardening to make exploitation of a source code vulnerability harder, or even not possible on the protected device. The bug (zero-day) still exists, it's just not as exploitable to do bad stuff.

[mtgx]

They talk a bit about them in these posts:

https://copperhead.co/blog/2015/06/11/android-pax

https://copperhead.co/blog/2015/07/27/hardening-bionic

https://copperhead.co/blog/2015/05/11/aslr-android-zygote

[strcat]

https://copperhead.co/android/docs/technical_overview covers much more and is mostly up-to-date.

[vox_mollis]

ASLR is already a part of pretty much every current operating system ( save FreeBSD-RELEASE )

[neerdowell]

Not all ASLR implementations are equal, eg. PaX's ASLR vs standard Linux KASLR.

[mtgx]

Or Android's almost useless 32-bit ASLR (even on 64-bit platforms) for that matter:

https://googleprojectzero.blogspot.com/2015/09/stagefrighten...

https://copperhead.co/blog/2015/05/11/aslr-android-zygote

[droopybuns]

I've heard rumors that the new ASLR in Android N is actually worse than the current implementation. I don't have anything online to link to, unfortunately.

[Animats]

ASLR is a band-aid. If you need it, your system is already insecure. It's just that the attacker may need to crash your system a few times before they get in.

[hackcasual]

64 bit ASLR is not a bandaid. There are definitely ASLR approaches that don't have enough entropy, but that doesn't mean ASLR as a whole is unworkable.

[viraptor]

All systems need it. All systems are already insecure. All desktops systems already implement it. This has been the situation for years now.

[nickpsecurity]

No, they need tech that either contains the attack in its own partition or prevents it entirely by language/compiler-level action on the target. Both exist in academia and commercial sector with varying capabilities, prices, maturity levels, and so on. Most such things are rejected in favor of band-aids like ASLR.

And the systems continue to get hacked through the very holes covered in bandaids. As he said, if you're using a bandaid, you're covering up something inherently broken.

[viraptor]

That's not a practical solution. Sure - you could write super-secure (Ada-style?) code in a verified environment (?), running on verified kernel (SL4?), on secure hardware (got any ideas how to solve rowhammer?). Realistically though - nobody does that (in a product which we can buy). Producing any application in that kind of environment would be too expensive and not possible for most companies. We don't even have secure hardware available. Academia will experiment with that. Some industries will care enough to apply it.

But in a mass-produced software/hardware? Realistically my choice for productive desktop is OSX/Win/Lin. We can talk about cool, perfect solutions for a very long time. In the meantime I'm making sure my apps are running with ASLR. I hope you're not actually advising people not to use it, just because there's some ideal solution maybe possible on the horizon, that doesn't run any apps they need?

[pcwalton]

Whoa there. There's an entire spectrum of options in between "ASLR" and "formally verified everything" that defend against memory safety related RCE. Such as, for instance, writing in a memory-safe, high-level language where reasonable (which is in fact not only practical, it's what Android does).

(That's not to say ASLR isn't great as a way to harden the C and C++ code at the core levels of the system, of course. Daniel Micay's work here is very solid.)

[nickpsecurity]

I'm talking things as simple as Code-Pointer Integrity, common tools recoded in safer language, or app-level sandboxing with or without microkernels. People rarely use strong stuff even if it's a straight-foward download, recompile, or configuration. Hell, most wont use protected messaging when it's as easy as Signal. It's a demand-driven problem largely about convenience and access to insecure apps.

Btw, solutions like OKL4 exist already and are fielded w/ Android + other OS support. Android hardening tech also exists. Cryptophones also exist. Not perfect, future tech so much as existing tech companies and FOSS developers mostly ignore. With exception of Blackberry that tried something decent by integrating QNX with stellar results.

[rinon]

Indeed, I was trying to give well-known examples. Some of the more interesting, not widely-deployed PaX mitigations are more accurate here.