

Return-Oriented Vulnerabilities in ARM Executables [pdf] - sabalaba
http://cryptome.org/2013/04/return-oriented-vuls-arm.pdf

======
lgeek
This is typical for techniques that try to automatically fix security
vulnerabilities or to add memory safety to native programs (so not a deal
breaker), but I can spot a few limitations:

* this implementation relies on static analysis which is not guaranteed to find all executable code and it doesn't protect dynamically generated code (think JIT compilers)

* the proposed algorithm doesn't detect sequences where the value loaded from the stack is modified in a predictable way:
    
    
           pop {R0}
           add r0, r0, #1
           pop {pc}
    

This code snippet loads a value from the stack into R0, adds 1 to R0 and then
branches to the next address on the stack. Obviously, the effect of the add
instruction can easily be accounted for, but the proposed algorithm wouldn't
consider the value of R0 as being 'controllable'. I don't know if a similar
code sequence is likely to be generated by a compiler, but I can definitely
imagine something similar appearing in hand written assembly. I guess a better
approach would be to tag data read from the stack as it flows through the
registers.

The name of 'vulnerable code sequence' is a bit misleading since this kind of
sequences are harmless on their own, if a stack buffer overflow isn't present.
My guess is that few functions that contain VCSs also contain stack buffer
overflow vulnerabilities, so manually fixing this relatively common sequence
might take unreasonably many engineer-hours. However, it would make much more
sense to check all executables if an automatic patching strategy would be
developed.

