Stories
Slash Boxes
Comments

SoylentNews is people

posted by takyon on Sunday July 26 2015, @03:30PM   Printer-friendly
from the hard-mode-os dept.

A relatively new fork of FreeBSD, HardenedBSD, has completed its Address Space Layout Randomization (ASLR) feature. Without ASLR, applications are loaded into memory in a deterministic manner. An attacker who knows where a vulnerability lies in memory can reliably exploit that vulnerability to manipulate the application into doing the attacker's bidding. ASLR removes the determinism, making it so that even if an attacker knows that a vulnerability exists, he doesn't know where that vulnerability lies in memory. HardenedBSD's particular implementation of ASLR is the strongest form ever implemented in any of the BSDs.

The next step is to update documentation and submit updates to the patches they have already submitted upstream to FreeBSD. ASLR is the first step in a long list of exploit mitigation technologies HardenedBSD plans to implement.


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by TheRaven on Monday July 27 2015, @11:21AM

    by TheRaven (270) on Monday July 27 2015, @11:21AM (#214228) Journal
    I disagree. The difference between a bug and a vulnerability is often the intelligence of the attacker and it only takes one exploitable bug to compromise the program. If you want to make your programs bug free, then you're going to have to spend a lot more on them. The seL4 team currently has the lowest cost per line code that's been formally verified and their estimate is that it's around 30 times more expensive to write it than writing the same code with well-written tests and documentation. If you want to fix all the bugs, then you need at least 30 times more programmers (it's not clear how their techniques scale - seL4 is only about 10KLoC and formal verification costs tend not to scale linearly with project size) and you'll need a lot of them to be educated to a significantly higher level than most programmers. Techniques that can mitigate entire classes of vulnerability are far cheaper to deploy and can have a huge benefit. For example, FreeBSD is using Capsicum-based sandboxing for a number of system utilities now, so that *any* bug can only compromise the running process and can't open new sockets or write to the file system. No matter how buggy the code is, it's very hard for an attacker to do anything other than cost you CPU cycles.

    That said, ASLR doesn't make ROP much harder these days. Things like fixed-offset PLTs make it relatively easy to bypass.

    --
    sudo mod me up
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2  
  • (Score: 2) by FatPhil on Monday July 27 2015, @11:59AM

    by FatPhil (863) <pc-soylentNO@SPAMasdf.fi> on Monday July 27 2015, @11:59AM (#214244) Homepage
    We'll have to agree to disagree, then. If someone ROPs your ASLR code, then rather than getting predictable exploitation, you get unpredictable god-knows-what, and you have lost. OK, they may not have won, but you have still lost.
    --
    Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves
    • (Score: 2) by TheRaven on Monday July 27 2015, @12:53PM

      by TheRaven (270) on Monday July 27 2015, @12:53PM (#214279) Journal
      I'd take a containable application crash over an arbitrary code execution vulnerability any day. I'd rather not have either, but that isn't an option at a price that people are willing to pay (we'd happily ship you a formally verified version of FreeBSD, if you've got a couple of billion to spend - oh, and the same again for the next version).
      --
      sudo mod me up