When I opened my laptop after finishing the build from last week, I tried to run the fuzzer only to find there was more errors.
So I had to go over everything once more and fix up a lot more things to get this thing to actually run. This took quite a bit longer. I'm also writing this a few days after doing it rather than updating the journal at the same time, so it's not going to be indepth.
Once I had finally done (this was during class) I gave the fuzzer a test run and it performed nicely.
The way it works is that there's two terminal windows you should open, one for doing the fuzzing and one is like an information broker that shows you the details of what it's doing.
To run:
taskset -c 4 ./fuzzer
for the broker
taskset -c 6 ./fuzzer
for the fuzzer
Once it causes some crashes, those files get generated in the timeouts folder.
Screenshot of it running
I'll also be using GDB to go over those files so I can prove that the correct vulnerability is the cause of crash, thereby achieving my project goal of building a fuzzer to target the CVE-2019-13288.
So to recap, this week I have been updating my journals for the weeks I missed writing about, fixing the fuzzer so it would run successfully, and with the next few days i'll run the corrupted files through GDB to verify the vulnerability, and start writing up my report.
I compiled xpdf again with debug info, so GDB can get a stack trace, at a different folder, since with the fuzzer it compiles xpdf itself within its script.
Commands for gdb:
gdb --args $HOME/MEGAsync/Lvl7II/rust/xpdf/install/bin/pdftotext $HOME/MEGAsync/Lvl7II/rust/xpdf-fuzz/timeouts/f8ad5203f73dca30 $HOME/MEGAsync/Lvl7II/rust/xpdf-fuzz/output
run
bt
Running the file f8ad5203f73dca30 through GDB shows that it crashes with a segmentation fault. Looking at the backtrace we can see multiple calls to Parser::getObj in it, which confirms the vulnerability.