Buffer Overflows and Buffer Overflow Attacks
A buffer overflow occurs when an application receives more input, or different input, than it
expects. The result is an error that exposes system memory that would otherwise be protected and
inaccessible. Normally, an application will have access only to a specific area of memory, called a
buffer. The buffer overflow allows access to memory locations beyond the application’s buffer,
enabling an attacker to write malicious code into this area of memory.
As an example, an application may be expecting to receive a string of 15 characters for a
username. If input validation is not used and it receives more than 15 characters, it can cause a buffer
overflow and expose system memory. The following HTTP GET command shows an example of
sending a long string to the system to create a buffer overflow: GET /index.php?
username=ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
The buffer overflow exposes a vulnerability, but it doesn’t necessarily cause damage by itself.
However, once attackers discover the vulnerability, they exploit it and overwrite memory locations
with their own code. If the attacker uses the buffer overflow to crash the system or disrupt its
services, it is a DoS attack.
More often, the attacker’s goal is to insert malicious code in a memory location that the system
will execute. It’s not easy for an attacker to know the exact memory location where the malicious
code is stored, making it difficult to get the computer to execute it. However, an attacker can make
educated guesses to get close.
A popular method that makes guessing easier is with no operation (NOP, pronounced as “noop”)
commands, written as a NOP slide or NOP sled. Many Intel processors use hexadecimal 90
(often written as x90) as a NOP command, so a string of x90 characters is a NOP sled. The attacker
writes a long string of x90 instructions into memory, followed by malicious code. When a computer is
executing code from memory and it comes to a NOP, it just goes to the next memory location. With a
long string of NOPs, the computer simply slides through all of them until it gets to the last one and
then executes the code in the next instruction. If the attacker can get the computer to execute code from
a memory location anywhere in the NOP slide, the system will execute the attacker’s malicious code.
The malicious code varies. In some instances, the attackers write code to spread a worm through
the web server’s network. In other cases, the code modifies the web application so that the web
application tries to infect every user who visits the web site with other malware. The attack
possibilities are almost endless.
Remember this
Buffer overflows occur when an application receives more data than it can
handle, or receives unexpected data that exposes system memory. Buffer
overflow attacks often include NOP instructions (such as x90) followed by
malicious code. When successful, the attack causes the system to execute
the malicious code. Input validation helps prevent buffer overflow attacks.
A buffer overflow attack includes several different elements, but they happen all at once. The
attacker sends a single string of data to the application. The first part of the string causes the buffer
overflow. The next part of the string is a long string of NOPs followed by the attacker’s malicious
code, stored in the attacked system’s memory. Last, the malicious code goes to work.
In some cases, an attacker is able to write a malicious script to discover buffer overflow
vulnerabilities. For example, the attacker could use JavaScript to send random data to another service
on the same system.
Although error-handling routines and input validation go a long way to prevent buffer overflows,
they don’t prevent them all. Attackers occasionally discover a bug allowing them to send a specific
string of data to an application causing a buffer overflow. When vendors discover buffer overflow
vulnerabilities, they are usually quick to release a patch or hotfix. From an administrator’s
perspective, the solution is easy: Keep the systems up to date with current patches.
Source: Darril Gibson Book Sec+
A buffer overflow occurs when an application receives more input, or different input, than it
expects. The result is an error that exposes system memory that would otherwise be protected and
inaccessible. Normally, an application will have access only to a specific area of memory, called a
buffer. The buffer overflow allows access to memory locations beyond the application’s buffer,
enabling an attacker to write malicious code into this area of memory.
As an example, an application may be expecting to receive a string of 15 characters for a
username. If input validation is not used and it receives more than 15 characters, it can cause a buffer
overflow and expose system memory. The following HTTP GET command shows an example of
sending a long string to the system to create a buffer overflow: GET /index.php?
username=ZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZZ
The buffer overflow exposes a vulnerability, but it doesn’t necessarily cause damage by itself.
However, once attackers discover the vulnerability, they exploit it and overwrite memory locations
with their own code. If the attacker uses the buffer overflow to crash the system or disrupt its
services, it is a DoS attack.
More often, the attacker’s goal is to insert malicious code in a memory location that the system
will execute. It’s not easy for an attacker to know the exact memory location where the malicious
code is stored, making it difficult to get the computer to execute it. However, an attacker can make
educated guesses to get close.
A popular method that makes guessing easier is with no operation (NOP, pronounced as “noop”)
commands, written as a NOP slide or NOP sled. Many Intel processors use hexadecimal 90
(often written as x90) as a NOP command, so a string of x90 characters is a NOP sled. The attacker
writes a long string of x90 instructions into memory, followed by malicious code. When a computer is
executing code from memory and it comes to a NOP, it just goes to the next memory location. With a
long string of NOPs, the computer simply slides through all of them until it gets to the last one and
then executes the code in the next instruction. If the attacker can get the computer to execute code from
a memory location anywhere in the NOP slide, the system will execute the attacker’s malicious code.
The malicious code varies. In some instances, the attackers write code to spread a worm through
the web server’s network. In other cases, the code modifies the web application so that the web
application tries to infect every user who visits the web site with other malware. The attack
possibilities are almost endless.
Remember this
Buffer overflows occur when an application receives more data than it can
handle, or receives unexpected data that exposes system memory. Buffer
overflow attacks often include NOP instructions (such as x90) followed by
malicious code. When successful, the attack causes the system to execute
the malicious code. Input validation helps prevent buffer overflow attacks.
A buffer overflow attack includes several different elements, but they happen all at once. The
attacker sends a single string of data to the application. The first part of the string causes the buffer
overflow. The next part of the string is a long string of NOPs followed by the attacker’s malicious
code, stored in the attacked system’s memory. Last, the malicious code goes to work.
In some cases, an attacker is able to write a malicious script to discover buffer overflow
vulnerabilities. For example, the attacker could use JavaScript to send random data to another service
on the same system.
Although error-handling routines and input validation go a long way to prevent buffer overflows,
they don’t prevent them all. Attackers occasionally discover a bug allowing them to send a specific
string of data to an application causing a buffer overflow. When vendors discover buffer overflow
vulnerabilities, they are usually quick to release a patch or hotfix. From an administrator’s
perspective, the solution is easy: Keep the systems up to date with current patches.
Source: Darril Gibson Book Sec+
No comments:
Post a Comment