-
Notifications
You must be signed in to change notification settings - Fork 10
User Manual
LFI works by intercepting selected calls made by applications to libraries. Depending on conditions specified by the tester, a choice is made between returning an error code to the application and forwarding the call to the original library function. The main concepts that you should be familiar with in order to use LFI are Triggers, Faults and Injection Scenarios.
After installing LFI, you can run it as
./libfi scenarios/sampleplan.xml [-t "/path/to/target target-arguments"]
The first argument is the injection scenario to use, while the second is the program that should be tested. If the second argument is omitted, only the stub library intercept.stub.so is created. It can be loaded manually or from test suites via
LD_PRELOAD=/path/to/intercept.stub.so /path/to/target
For example, with one of the example injection scenarios shipped with LFI you can use these commands:
./libfi scenarios/sampleplan.xml -t "/bin/ls -l"
or
./libfi scenarios/sampleplan.xml
LD_PRELOAD=/path/to/intercept.stub.so /bin/cat
Note: MacOS requires different environment variables to be set for loading the stub library. LFI does this automatically; manually running the program is discouraged.
For more details see
Currently, LFI can modify a function's return value and the value of the errno variable. These changes are collectively referred to as fault injection. When a fault is injected, the original library function is not called.
Determining reasonable faults to inject is an important topic. One alternative is to use the library profiler shipped with LFI, another is to consult the library documentation.