- 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.
This archive was generated by hypermail 2b30 : Wed May 08 2002 - 22:06:52 PDT