3 ms·

Very cool work. > I'd like to see more review of and enhancements to it by the types of people that broke prior, SFI schemes. I only glanced at the abstract s

Very cool work. > I'd like to see more review of and enhancements to it by the types of people that broke prior, SFI schemes. I only glanced at the abstract so far, but it looks like they don't protect against non-control data attacks [1]. For example, the adversary might still be able to whack the int that stores the userid and change it to some more-privileged value. [1] https://www.usenix.org/conference/14th-usenix-security-symposium/non-control-data-attacks-are-realistic-threats https://www.usenix.org/conference/14th-usenix-security-sympo...

nickpsecurity 11y ago
I agree. It's a major risk area. It's why most of my work and evangelism is on stronger stuff, esp in hardware. Any of these CFI type things are taking in risk to try to make stuff fast enough to be adopted on legacy systems. Thanks for the paper as I'm sure it will come in handy in a future discussion on this stuff. Here's a more thorough solution with the kind of performance hit I talk about: http://www.cis.upenn.edu/acg/papers/pldi09_softbound.pdf http://www.cis.upenn.edu/acg/papers/pldi09_softbound.pdf Better than predecessors I read about, though. On hardware side, the SAFE team (crash-safe.org) have enforced several policies simultaneously on their modified processor. Was quite a performance hit but unoptimized and with many protections. Burroughs B5000 (below) had a bit for pointer protection, a bit for code vs data separation, type checks in hardware for procedure calls, array bounds-checking in hardware, and much applied by compiler from HLL to binary. I'm sure most of that could be implemented with simple hardware on modern processes. Finally, I've seen a taint-checking approach that only took two bits, had under 10% performance hit, and was Linux compatible IIRC. So, there's methods with high promise if you ditch the legacy system but people don't want to do that... http://www.smecc.org/The%20Architecture%20%20of%20the%20Burroughs%20B-5000.htm http://www.smecc.org/The%20Architecture%20%20of%20the%20Burr...

nickpsecurity 11y ago

I agree. It's a major risk area. It's why most of my work and evangelism is on stronger stuff, esp in hardware. Any of these CFI type things are taking in risk to try to make stuff fast enough to be adopted on legacy systems. Thanks for the paper as I'm sure it will come in handy in a future discussion on this stuff. Here's a more thorough solution with the kind of performance hit I talk about: http://www.cis.upenn.edu/acg/papers/pldi09_softbound.pdf http://www.cis.upenn.edu/acg/papers/pldi09_softbound.pdf Better than predecessors I read about, though. On hardware side, the SAFE team (crash-safe.org) have enforced several policies simultaneously on their modified processor. Was quite a performance hit but unoptimized and with many protections. Burroughs B5000 (below) had a bit for pointer protection, a bit for code vs data separation, type checks in hardware for procedure calls, array bounds-checking in hardware, and much applied by compiler from HLL to binary. I'm sure most of that could be implemented with simple hardware on modern processes. Finally, I've seen a taint-checking approach that only took two bits, had under 10% performance hit, and was Linux compatible IIRC. So, there's methods with high promise if you ditch the legacy system but people don't want to do that... http://www.smecc.org/The%20Architecture%20%20of%20the%20Burroughs%20B-5000.htm http://www.smecc.org/The%20Architecture%20%20of%20the%20Burr...