3

Anti-exploitation technologies (DEP, ASLR, stack protector, etc.) do not provide complete protection. One reason for this is performance; these technologies are designed to work with a low performance overhead.

For a system that has high security needs, but low performance needs, are there techniques that can provide more reliable protection against buffer overruns (and other memory corruption flaws)? As a rule of thumb a 10x slow down would be no problem, although a 100x slow down would probably be unacceptable.

I'm interested in both theoretical techniques and practical systems.

Edit: To be clear, I'm talking about a system that needs to run an existing code base in a non-memory-safe language. So Java, .Net, etc. won't help.

paj28
  • 32,736
  • 8
  • 92
  • 130
  • Have you looked at language interpreters such as those mentioned [here](https://stackoverflow.com/questions/69539/have-you-used-any-of-the-c-interpreters-not-compilers)? I'm not familiar with any specific one, but an interpreter with full error-checking enabled should be able to detect out-of-bounds memory accesses with high reliability. – Neil Smithline Nov 17 '15 at 18:47
  • @NeilSmithline - I haven't, but that is exactly the kind of thing I was looking for. You could make your comment an answer. Thanks :-) – paj28 Nov 17 '15 at 19:52

3 Answers3

2

Language interpreters such as those mentioned here should be able to detect out-of-bounds memory accesses with high reliability. In exchange for this higher reliability the interpreters will run your application slower (I have no stats but saw numbers saying 5x) and will likely introduce incompatibilities with the compiled code. These incompatibilities may be due to interpreter bugs or just looseness in the language spec. You should check the settings on the compiler you use as they may have options to enable extra memory checks at a performance cost.

Neil Smithline
  • 14,621
  • 4
  • 38
  • 55
  • Following your suggestion, I have now found [this](http://clang.llvm.org/docs/AddressSanitizer.html) which seems to be exactly what I need – paj28 Nov 17 '15 at 20:09
0

If the OS supports it, using guard pages between program memory segments can help. If a buffer overflow occurs and happens to go too far the guard page will be accessed causing a segmentation fault for that process.

The gcc compiler also implements stack-smashing protection by placing 'canaries' or protective variables with known values. If they change the process aborts.

Both of these solutions have a negligible performance impact.

In the academic realm there seems to be two competing ideologies to prevent execution redirection:

  1. Binary rewriting (Compile time modification of the binary)
  2. Mitigating buffer overflows at run time (BinArmor: https://www.usenix.org/system/files/conference/atc12/atc12-final44.pdf)

Run time mitigation has the most significant performance repercussions.

Whome
  • 1,231
  • 11
  • 21
  • 1
    I think this is what the OP means when they say `stack protector`. As you point out, neither of these are perfect. Guard pages need you to overflow the page and canaries need you to overflow the local variables. I think the OP is looking for a (near-)perfect solution, even if it is very costly. – Neil Smithline Nov 17 '15 at 18:43
0

Clang AddressSanitizer can do this. From the documentation:

AddressSanitizer is a fast memory error detector. It consists of a compiler instrumentation module and a run-time library. The tool can detect the following types of bugs:

  • Out-of-bounds accesses to heap, stack and globals
  • Use-after-free
  • Use-after-return (to some extent)
  • Double-free, invalid free
  • Memory leaks (experimental)

Typical slowdown introduced by AddressSanitizer is 2x.

paj28
  • 32,736
  • 8
  • 92
  • 130
  • Detect and prevent are quite different words. – domen Nov 18 '15 at 10:55
  • @domen - when it detects an overrun, it crashes the process, which prevents exploitation. Good enough for me – paj28 Nov 18 '15 at 10:57
  • Apparently the detection is somewhat limited: https://dl.packetstormsecurity.net/papers/general/BreakingAddressSanitizer.pdf – domen Nov 18 '15 at 12:03
  • 1
    @domen - thanks for the link, seems it is more limited than I hoped - I'd have thought with compiler instrumentation it could protect adjacent blocks. Anyway, your link pointed me towards Watchman which is another example of the thing I'm looking for. Hunt goes on :-) – paj28 Nov 18 '15 at 12:18
  • @domen - the author of that paper just mailed me and says he abandoned development of his own framework because AddressSanitizer is better... the plot thickens – paj28 Nov 18 '15 at 15:01