On a recent hunt for bugs, I came across a buffer overflow condition in TallSoft’s newly released Quick TFTP Server 2.2. I thought I’d write a short guide as to how the bug was identified and how the denial of service was constructed against the application. Unfortunately for us, the application was compiled with ‘/GS’ which makes exploitation significantly more difficult. In short, at the start of each function, the compiler inserts a special ‘cookie’ value after the allocated buffer space. When the function returns, if the cookie is intact and matches the expected value, all is good, if not, we can assume that the buffer has been overrun and the application crashes. We can’t predict the expected value and just include it as part of our exploit as it is generated dynamically at runtime. Exploits already exist for previous versions of this application, and it seems that instead of patching the bugs, the vendor has simply recompiled with /GS enabled. Anyway, on to the bug – the first step was to fuzz the application.
The RFC and protocol description for TFTP is pretty simple – it’s a UDP service that runs over port 69. This allows us to build a template for SPIKE fuzzer. In the template, we are specifying bytes that must remain consistent, and then ‘variable’ bytes.
This is our SPIKE template. Here, we specify two fixed binary bytes ‘\x00\x02’ followed by a fuzz point i.e. the filename. We then require another fixed null binary byte ‘\x00’, followed by another fuzz point. Lastly, we terminate the payload with a final ‘\x00’ byte. This should maintain the integrity of the protocol whilst we examine how the application will handle different types and length of input placed at the two fuzz points. The next step is running SPIKE against our application and seeing if we observe anything interesting
Read the rest of this entry »