IT Security

Main menu

Tag Archives: buffer overflow

There has been a lot of afl fuzzing going on, a lot of image libraries were targeted, I also fuzzed some libraries, for example libtiff. I sent around 10 to 20 crash files for the different tools to the maintainer that seemed to be kind of unique crash cases, although I didn’t analyze a lot of the crashes in-depth. Others found similar issues and CVEs like CVE-2014-8129, CVE-2014-8128, CVE-2014-8127 and CVE-2014-9330 were assigned, additionally I got CVE-2015-8870.

Here’s the example that I analyzed a little bit more closely (and that got the identifier CVE-2015-8870) in libtiff version 4.0.3 (until this month the last stable). It’s one of the errors in the bmp2tiff command line tool. Here’s what happens when you run it with one of my crash files (bmp2tiff crash-file.bmp outfile.tiff).

First, width and length variables are read from the bmp file header. Then the needed memory for the uncompressed image is calculated and allocated (line 595 in bmp2tiff.c):

Where 524289 is (65536 * 65544) % MAX_INT. However, later on the width and length is used to calculate offsets on the uncomprbuf buffer, which results in pointers that are far off (heap buffer overflow).

Although I didn’t check the entire code, I think this is not easily exploitable, as it can only be used to read (more or less) arbitrary memory regions and write them to the output file. While this might be interesting in scenarios where you look for memory leaks, I doubt that it’s useful in any realistic attack scenario. Drop me a comment if I’m wrong. So the fix was to check if an integer overflow occurs on line 595 in bmp2tiff.c, which is done in the new version according to the maintainer.

Take a second and think about how many projects are probably using libtiff.

Looking into another crash file with an arbitrary WRITE and turning it into a fully weaponized exploit is still on my TODO list… we’ll see.

It took a while to do PoC changes, port from python to ruby, port from ruby to a metasploit module, change the used library in ruby, divide into two files (a tincd protocol library and an exploit module), write ROP chains for x86 and ARM architecture, support various operating systems and make all the necessary changes to make ruby people happy. But it was really a good experience.

Generates a venetian shellcode alignment stub which can be placed directly before unicode shellcode.
Arguments:
-a <address> : Specify the address where the alignment code will start/be placed
Optional arguments:
-l : Prepend alignment with a null byte compensating nop equivalent
(Use this if the last instruction before the alignment routine 'leaks' a null byte)
-b <reg> : Set the bufferregister, defaults to eax
-t <seconds> : Time in seconds to run heuristics (defaults to 15)
-ebp <value> : Overrule the use of the 'current' value of ebp,
ebp/address will be used to calculate offset to shellcode

Instead of “!mona unicodealign” you can use the short version “!mona ua”. Here’s a short video on how the new feature can be used:

A friend of mine wrote a Proof of Concept exploit for the tincd server (a VPN software) for authenticated peers (post-auth), the original blog post about it can be found here. I turned the PoC crash into a weaponized exploit for Windows XP, Windows 7 and FreeBSD. I think very often the exploits on exploit-db.com do not contain a lot of information to reproduce the exploit development and a lot of “reversing” of “some hex bytes” is necessary to fully understand it. Therefore I provide several more detailed scripts in different programming languages with comments here. The vulnerability/my exploit/the software has the following characteristics:

No DEP, ASLR or other security mechanisms for the three OS. It’s the same setup file for both Windows (tinc-1.1pre6-install.exe). FreeBSD is compiled from the ports.

memcpy_chk protection introduced by gcc for Ubuntu. Seems to be non-exploitable (pretty sure it’s the same for Debian). gcc can easily do that because the buffer size is known at compile time.

Straight forward (memcpy) saved return pointer overwrite.

The second value on the stack when EIP is overwritten is a pointer to the start of our payload. Convenient.

I authored the exploiting part and changed the logic part to remove some issues. First, I wrote everything in python. Second, ported the entire thing to ruby with eventmachine. Then I decided to port the thing to metasploit and removed the eventmachine dependency. At that point I decided that improvements regarding reliability were necessary. The Metasploit module works for every of my test machines on the first try.

Ok, so everybody who just wants to see the outcome, go to my github page and download it. I also made a pull request and after some feedback it should end up in Metasploit (so maybe just check your Metasploit installation).

For everyone more interested in the “how”, the python script and the ruby script at the end of this post. The scripts are not as reliable, flexible, advanced, maintained and convenient as the Metasploit module. But they should provide everybody with enough information on how to exploit such a buffer overflow vulnerability.

Right now I’m writing the ROP chain for the exploitation on Fedora 19 (has NX enabled). Interesting and I’m already executing code, but not release ready yet. I hope I’ll be able to update the Metasploit module. There are so many other combinations that would be interesting too (ARM, x64, systems with ASLR…)