4 ms·
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 Rand
by rinon 10y ago
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.
- vox_mollis 10y agoASLR is already a part of pretty much every current operating system ( save FreeBSD-RELEASE )
- rinon 10y agoIndeed, I was trying to give well-known examples. Some of the more interesting, not widely-deployed PaX mitigations are more accurate here.
- neerdowell 10y agoNot all ASLR implementations are equal, eg. PaX's ASLR vs standard Linux KASLR.
- droopybuns 10y agoI'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.
- mtgx 10y agoOr Android's almost useless 32-bit ASLR (even on 64-bit platforms) for that matter: https://googleprojectzero.blogspot.com/2015/09/stagefrightened.html https://googleprojectzero.blogspot.com/2015/09/stagefrighten... https://copperhead.co/blog/2015/05/11/aslr-android-zygote https://copperhead.co/blog/2015/05/11/aslr-android-zygote
- Animats 10y agoASLR 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 10y ago64 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 10y agoAll systems need it. All systems are already insecure. All desktops systems already implement it. This has been the situation for years now.
- nickpsecurity 10y agoNo, 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 10y agoThat'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?
- mtgx 10y agoThey talk a bit about them in these posts: https://copperhead.co/blog/2015/06/11/android-pax https://copperhead.co/blog/2015/06/11/android-pax https://copperhead.co/blog/2015/07/27/hardening-bionic https://copperhead.co/blog/2015/07/27/hardening-bionic https://copperhead.co/blog/2015/05/11/aslr-android-zygote https://copperhead.co/blog/2015/05/11/aslr-android-zygote
- strcat 10y agohttps://copperhead.co/android/docs/technical_overview https://copperhead.co/android/docs/technical_overview covers much more and is mostly up-to-date.