4 ms·

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

rinon 11y ago
Indeed, I was trying to give well-known examples. Some of the more interesting, not widely-deployed PaX mitigations are more accurate here.
neerdowell 11y ago
Not all ASLR implementations are equal, eg. PaX's ASLR vs standard Linux KASLR.
- droopybuns 11y ago
  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.
- mtgx 11y ago
  Or 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 11y ago
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 11y ago
  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 11y ago
  All systems need it. All systems are already insecure. All desktops systems already implement it. This has been the situation for years now.
  - nickpsecurity 11y ago
    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 11y ago
      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?
      - nickpsecurity 11y ago
        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 11y ago

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

neerdowell 11y ago

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

droopybuns 11y ago
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.
mtgx 11y ago
Or 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 11y ago

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 11y ago
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 11y ago
All systems need it. All systems are already insecure. All desktops systems already implement it. This has been the situation for years now.
- nickpsecurity 11y ago
  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 11y ago
    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?
    - nickpsecurity 11y ago
      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.