4 ms·
Return-Oriented Vulnerabilities in ARM Executables [pdf]
- lgeek 14y agoThis 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.