3 ms·

Ostensibly, "control flow hijack attacks" is a recently coined umbrella term for the various standard non-managed memory corruption vulnerabilities like buffer,

Ostensibly, "control flow hijack attacks" is a recently coined umbrella term for the various standard non-managed memory corruption vulnerabilities like buffer, heap overflows and uncontrolled format strings. The main target for so-called CPI then appears to be LLVM's SafeStack: http://clang.llvm.org/docs/SafeStack.html http://clang.llvm.org/docs/SafeStack.html

jcr 11y ago
And it's a ridiculously huge umbrellla. ;) Of the three parts mentioned (CPI, CPS and SafeStack), SafeStack had the least performance impact, so it seems it was the easiest to get committed upstream [1]. The differential revision comments are also interesting reading. [2] Though their CPS and CPI work exists (linked in article), I'm not sure if or when it will be ready for prime time. [1] https://github.com/llvm-mirror/llvm/commit/7ffec838a2b72e6841d9fb993b5fe6a45f3b2a90 https://github.com/llvm-mirror/llvm/commit/7ffec838a2b72e684... [2] http://reviews.llvm.org/D6094 http://reviews.llvm.org/D6094
nickpsecurity 11y ago
At one point, most of the research focused on the memory safety property as a whole or many tactics for protecting memory/pointeres in narrow ways. The first had too much of a performance hit or required different hardware. The second wasn't good enough because, like you said, a whole umbrella of attacks existed that achieved same goal. Eventually, this paper [1] coined "Control Flow Integrity" as the property of protecting control flow rather than all memory issues. It cites lots of other work that specifically tries to protect control flow. The general idea seems to be that stopping code injection is highest priority and methods that focus just on that might have less performance hit than full memory safety. Plus, if you focus on preserving a property in all situations, then the individual ways to exploit a lack of that property no longer matter. Unless they're things that destroy your whole model. ;) At least, that's the impression I received from reading most of the papers. A few were clever enough to use segments like the old high assurance A1 systems did. CPI enforces a similar property on pointers with an interesting design and segments in its strongest form. Resulting performance penalty is negligible despite a large number of attacks stopped by it. This field is rife with failures so it wouldn't surprise me if more issues are found. Yet, combined with the bug bounty, the weaker SFI model used in Chrome has worked well enough. The stronger, CPI might deliver after enough analysis and fixes. Note: While looking that up, I found a recent CFI scheme [2] by Criswell et al that builds on their SVA-OS scheme. It supports my assertion about why CFI exists with this claim: "Where comparable numbers are available, the overheads of KCoFI are far lower than heavyweight memory-safety techniques." [1] http://research.microsoft.com/pubs/64250/ccs05.pdf http://research.microsoft.com/pubs/64250/ccs05.pdf [2] http://sva.cs.illinois.edu/pubs/KCoFI-Oakland-2014.pdf http://sva.cs.illinois.edu/pubs/KCoFI-Oakland-2014.pdf

jcr 11y ago

And it's a ridiculously huge umbrellla. ;) Of the three parts mentioned (CPI, CPS and SafeStack), SafeStack had the least performance impact, so it seems it was the easiest to get committed upstream [1]. The differential revision comments are also interesting reading. [2] Though their CPS and CPI work exists (linked in article), I'm not sure if or when it will be ready for prime time. [1] https://github.com/llvm-mirror/llvm/commit/7ffec838a2b72e6841d9fb993b5fe6a45f3b2a90 https://github.com/llvm-mirror/llvm/commit/7ffec838a2b72e684... [2] http://reviews.llvm.org/D6094 http://reviews.llvm.org/D6094

nickpsecurity 11y ago

At one point, most of the research focused on the memory safety property as a whole or many tactics for protecting memory/pointeres in narrow ways. The first had too much of a performance hit or required different hardware. The second wasn't good enough because, like you said, a whole umbrella of attacks existed that achieved same goal. Eventually, this paper [1] coined "Control Flow Integrity" as the property of protecting control flow rather than all memory issues. It cites lots of other work that specifically tries to protect control flow. The general idea seems to be that stopping code injection is highest priority and methods that focus just on that might have less performance hit than full memory safety. Plus, if you focus on preserving a property in all situations, then the individual ways to exploit a lack of that property no longer matter. Unless they're things that destroy your whole model. ;) At least, that's the impression I received from reading most of the papers. A few were clever enough to use segments like the old high assurance A1 systems did. CPI enforces a similar property on pointers with an interesting design and segments in its strongest form. Resulting performance penalty is negligible despite a large number of attacks stopped by it. This field is rife with failures so it wouldn't surprise me if more issues are found. Yet, combined with the bug bounty, the weaker SFI model used in Chrome has worked well enough. The stronger, CPI might deliver after enough analysis and fixes. Note: While looking that up, I found a recent CFI scheme [2] by Criswell et al that builds on their SVA-OS scheme. It supports my assertion about why CFI exists with this claim: "Where comparable numbers are available, the overheads of KCoFI are far lower than heavyweight memory-safety techniques." [1] http://research.microsoft.com/pubs/64250/ccs05.pdf http://research.microsoft.com/pubs/64250/ccs05.pdf [2] http://sva.cs.illinois.edu/pubs/KCoFI-Oakland-2014.pdf http://sva.cs.illinois.edu/pubs/KCoFI-Oakland-2014.pdf