[olug] Buffer overflow attacks (was: Security Vulnerability Disclosures)

Daniel G. Linder dlinder at iprevolution.com
Wed Mar 26 16:51:29 UTC 2003


On a similar vein to Eric's note, I was wondering if anyone has seen a document describing buffer overflow attacks?  I know "what" they are, and I have a good idea of the steps involved, but I was wondering if someone with actual experience :O had ever documented his/her steps?

>From my perspective, this is the process:
	Create a program to "feed" bogus data into a variable (i.e. via the network using NetCat, or via an automated script using 'expect' or other utility.
	a: This bogus could be a simple repeated character ("AAAAAAA....AA") or it might have to be a special string to further open the exploit hole.
	b: At the end of this bogus data, send a small snippet of code (assembly? a.out? elf? win32?) that "sends up a flag".  By a flag, I mean do something that is visible to the tester (send a ping back to a sniffer, reboot the system, beep the system bell, etc).

	Once the exploit is found, peruse the source code to determine the cause (un-checked loops, mis-matched buffer to input sizes, etc), or contact the vendor with code to reproduce the above test.

Early in the Linux development (i.e. around the 1.0 stage), I remember a program ("crash"???) that would send pseudo-random (i.e. reproducable) data to a program you specified.  In this way, you could test simple programs for hours without having to do any real work.  It would bookmark how far it had progressed so if it did crash the system, you could refer to the file (or printout) to see what "random" input caused the crash.  I am sure there is some program out there that someone has written (public or not) that is the modern equivalent to this.

>From a programming standpoint, I believe there are various debugging/compiler flags that can be used to help catch these errors.  Has anyone tried compiling their kernel and/or utilities with these flags?  There was a project being done by a University back east that was using custom code to step through the source code of the kernel to check for buffer overflows and other programming no-no's...  Sure wish we could set that up in a distributed.net fashion to have people use their spare CPU cycles to check snippets of code (both OpenSouce and potentially closed source).

Just my $0.02...

Dan


More information about the OLUG mailing list