Libsafe Multi-threaded Process Race Condition Security Bypass Weakness implementations.
Latest change 6/2/2016: add legend to figure.
Libsafe will normally kill an application when certain types of memory corruption are detected, preventing exploitation of some buffer overflow and format string vulnerabilities. A weakness has been reported that may allow Libsafe security failsafe mechanisms to be bypassed.
This vulnerability is due to a race condition that may be exposed when Libsafe is used with multi-threaded applications. The result is that Libsafe security features may be bypassed and an attack that would ordinarily be prevented may succeed. It should be noted that this is an implementation error in Libsafe that does not present a security risk unless there is a memory corruption vulnerability in a multi-threaded application on an affected computer.
Libsafe only works on 32-bit architectures;
1) make build: Builds Libsafe, compiles the proof of concept exploit ‘thread’, and compiles the library interposition code ‘interpose.so’.
make random MAX_DELAY=x: Randomizes the interposed delays in ‘interpose.so’ with miximum delay MAX_DELAY per interposition.
2) bug.sh: Runs the PoC exploit ‘thread’ in an environment that preloads Libsafe.
3) repeatbug.py: Runs bug.sh 1000 times and reports the number of times that Libsafe worked properly.
4) bug-interpose.sh: Runs the PoC exploit in an environment that preloads Libsafe as well as the library interposition code ‘interpose.so’
5) repeatbug-interpose.py: Runs bug-interpose.sh 1000 times and reports the number of times that Libsafe worked properly.
6) gen_interpose.py: Generates interpose.c based off the function prototypes listed in ‘func_names.txt’.
git clone https://github.com/tagatac/libsafe-CVE-2005-1125
and run step by step.