Buffer Overflow

buffer overflow (buffer overrun)[2] . . . . . username: http://www.linuxsecurity.com/resource_files/documentation/hacking-dict.html http://www.linuxsecurity.com

this form limits input to 10 characters; the browser won't let you type more than that because the form was programmed with a maxlength=10 parameter. however, when this form is submitted, it will actually be sent as a url that looks something like http://www.robertgraham.com/pubs/test.html?username=robert. lazy programmers know that browsers will never submit more than 10 characters, and write code that will break if the user submits more. as a hacker, you could simply go to the top of your screen and edit the url to look something like http://www.robertgraham.com/pubs/test.html?username=robertxxxxxxxxxxxxxxxxxxxxxxxx xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx. this may crash the target system or allow you to bypass password checks.

a classic exploit that sends more data than a programmer expects to receive. buffer overflows are one of the most common programming errors, and the ones most likely to slip through quality assurance testing. analogy: consider two popular bathroom sink designs. one design is a simple sink with a single drain. the other design includes a backup drain near the top of the sink. the first design is easy and often looks better, but suffers from the problem that if the drain is plugged and the water is left running, the sink will overflow all over the bathroom. the second design prevents the sink from overflowing, as the water level can never get past the top drain. example: in much the same way, programmers often forget to validate input. they (rightly) believe that a legal username is less than 32 characters long, and (wrongly) reserve more than enough memory for it, typically 200 characters. the assume that nobody will enter in a name longer than 200 characters, and don't verify this. malicious hackers exploit this condition by purposely entering in user names a 1000 characters long. key point: this is a classic programming bug that afflicts almost all systems. the average system on the internet is vulnerable to a well known buffer overflow attack. many windows nt servers have iis services vulnerable to a buffer overflow in ".htr" handler, many solaris servers have vulnerable rpc services like cmsd, tooltalk, and statd; many linux boxes have vulnerable imap4, pop3, or ftp services. key point: programs written in c are most vulnerable, c++ is somewhat less vulnerable. programs written in scripting level languages like visualbasic and java are generally not vulnerable. the reason is that c requires the programmer to check buffer lengths, but scripting languages generally make these checks whether the programmer wants them or not. key point: buffer overflows are usually a denial-of-service in that they will crash/hang a service/system. the most interesting ones, however, can cause the system to execute code provided by the hacker as part of the exploit. defenses: there are a number of ways to avoid buffer-overflows in code: use programming languages like java that bounds-check arrays for you.

run code through special compilers that bounds-check for you. audit code manually audit code automatically key point: the noop (no operation) machine language instruction for x86 cpus is 0x90. buffer overflows often have long strings of these characters when attacking x86 computers (windows, linux). key point: in a successful buffer overflow exploit, the hacker forces the system to run his own code. since most network services run as "root" or "administrator", the exploit would give complete control over the machine. for this reason, more and more services are being configured to run with lower privileges.