Vulnerability Development mailing list archives

Buffer Overflow Discovery


From: "Brett Moore" <brett () softwarecreations co nz>
Date: Thu, 9 May 2002 12:45:08 +1200

-
I was going to write this up in a more formal manner. But I didn't.
Credit where due to eeye for the info on the overflows used in this text.

Credit also to a poster, whose name I can't recall. They wrote about the
number of
'undiscovered' bugs and types of bugs.
-
So today the MSN Messenger OCX Buffer Overflow is released and the overflow
occurs;
<param name="ResDLL" value="AAAAAAA[27,257 bytes is where the EIP starts]">

This would be an example of a Bof in its most simple form.
1) Send a large amount of characters
2) It overwrites EIP
3) Definite BoF.

The recent IIS .asp Bof did not overwrite eip. It however caused an error
when copying from
one memory location to another. The overflow code in that instance was

10
PADPADPADPADPADP
4
DATA
4
DEST
0

Which was probably discovered by capturing the format of a 'normal' posts
data, recognising the format as a structure seperated by \n. Then by
modifying the different structure portions.
or it could have been the old brute force attack, does not matter.

When working on this exploit and debugging the relevant code something
occurred to me.

If we are using AAAA as our data portion and AAAA as our dest portion.
Within our vulnerable program it reads AAAA into to ebx,ecx.

1) The program checks the ranges and discards the data as they are 'illegal'
references.
The result. An exploitable Bof goes undiscovered.

2) The program uses the ebx or ecx in calculations that 'by chance' result
in valid references.
The result. An exploitable Bof goes undiscovered.

Why are they still explotable? Because if we had inserted valid addresses
then we could have controlled data.

This can also be applied to the simple Bof.
<param name="ResDLL" value="AAAAAAA[27,257 bytes is where the EIP starts]">

3) The vulnerable program reads in the first 7 bytes and checks to make sure
that they are http:// before reading in the rest of the string and
overflowing EIP.
The result. Another exploitable Bof goes undiscovered.

Possiblities are endless. Vulnerable programs could go as far as checking
crc,packet length or ip sequence number values and discarding if not
correct.
-
I decided to put this theory to a test and so setup a fresh server and
installed a package on it. This package had a server that remote computers
used a client to connect to. It used a single port.

I have ommitted all the coffee, doubt and multiple wrong paths.

1) Throw multiple amounts of huge data at the open port. The result.
Nothing.
2) Capture data sent from client to server.
3) Randomly but systematically change data values with the captured packet
and replay to server. Nothing.
4) Debug the server. I want to know exactly what is happening. Set a
breakpoint on the recv function and replay the data.
5) Multiple hours and tracing of calls I came across the answer.

The answer?
The server had multiple checks within it to determine how much of the packet
it read in. It first read 4 bytes and checked these. It then read in another
16 bytes and checked a 4 byte value of that for validation. It then used
another 4 byte value from this 16 bytes to allocate memory for the remainder
of the data.

So the Bof exploit had to be in the correct format to be allowed through the
server code far enough to reach the code that allocated the memory. Then by
setting the 4 byte value that specified the memory to allocate to 'key
number' it threw the memory calculations and the rest of the packet got
shoved onto the stack.
-

Just a thought.









Current thread: