buffer overflow (buffer overrun)[2] . . . . .

username:

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.