GDB UPX vulnerability not a UPX vulnerability at all
June 3rd, 2007 by danielp, Filed under: Commentary
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
-
scrimble
-
danielp
-
http://em386.blogspot.com chris rohlf



