What is Buffer Overflow

Buffers are memory storage regions that temporarily hold data

while it is being transferred from one location to another. A buffer
overflow (or buffer overrun) occurs when the volume of data
exceeds the storage capacity of the memory buffer. As a result,
the program attempting to write the data to the buffer overwrites
adjacent memory locations.

For example, a buffer for log-in credentials may be designed to

expect username and password inputs of 8 bytes, so if a
transaction involves an input of 10 bytes (that is, 2 bytes more
than expected), the program may write the excess data past the
buffer boundary.

Buffer overflows can affect all types of software. They typically

result from malformed inputs or failure to allocate enough space
for the buffer. If the transaction overwrites executable code, it
can cause the program to behave unpredictably and generate
incorrect results, memory access errors, or crashes.

Buffer overflow example

What is a Buffer Overflow Attack

Attackers exploit buffer overflow issues by overwriting the
memory of an application. This changes the execution path of the
program, triggering a response that damages files or exposes
private information. For example, an attacker may introduce
extra code, sending new instructions to the application to gain
access to IT systems.

If attackers know the memory layout of a program, they can

intentionally feed input that the buffer cannot store, and
overwrite areas that hold executable code, replacing it with their
own code. For example, an attacker can overwrite a pointer (an
object that points to another area in memory) and point it to an
exploit payload, to gain control over the program.

Types of Buffer Overflow Attacks

Stack-based buffer overflows are more common, and leverage

stack memory that only exists during the execution time of a
function.

Heap-based attacks are harder to carry out and involve flooding

the memory space allocated for a program beyond memory used
for current runtime operations.

What Programming Languages are More

Vulnerable?

C and C++ are two languages that are highly susceptible to

buffer overflow attacks, as they don’t have built-in safeguards
against overwriting or accessing data in their memory. Mac OSX,
Windows, and Linux all use code written in C and C++.
 Languages such as PERL, Java, JavaScript, and C# use built-in
safety mechanisms that minimize the likelihood of buffer
overflow.

How to Prevent Buffer Overflows

Developers can protect against buffer overflow vulnerabilities via

security measures in their code, or by using languages that offer
built-in protection.

In addition, modern operating systems have runtime protection.

Three common protections are:

​ Address space randomization (ASLR)—randomly moves

around the address space locations of data regions.
Typically, buffer overflow attacks need to know the locality
of executable code, and randomizing address spaces makes
this virtually impossible.
​ Data execution prevention—flags certain areas of
memory as non-executable or executable, which stops an
attack from running code in a non-executable region.
​ Structured exception handler overwrite protection
(SEHOP)—helps stop malicious code from attacking
Structured Exception Handling (SEH), a built-in system for
managing hardware and software exceptions. It thus
prevents an attacker from being able to make use of the
SEH overwrite exploitation technique. At a functional level,
an SEH overwrite is achieved using a stack-based buffer
overflow to overwrite an exception registration record,
stored on a thread’s stack.
​
​
​
​ How Imperva Helps Mitigate Buffer Overflow Attacks
The Imperva security solution is deployed as a gateway to your
application and provide out-of-the-box protection for buffer
overflow attacks. It does so by blocking illegal requests that may
trigger a buffer overflow state, preventing them from reaching
your applications.

In addition to protecting against buffer overflow attacks, Imperva

provides multi-layered protection to make sure websites and
applications are available, easily accessible and safe. The Imperva
application security solution includes:

​ DDoS Protection—maintain uptime in all situations.

Prevent any type of DDoS attack, of any size, from
preventing access to your website and network
infrastructure.
​ Web Application Firewall—permit legitimate traffic and
prevent bad traffic. Safeguard your applications on-premises
and at the edge with an enterprise‑class cloud WAF.
​ Bot Management– get full visibility and control over
human, good bot, and bad bot traffic to your website and
API.
​ Account Takeover Protection—uses an intent-based
detection process to identify and defends against attempts
to take over users’ accounts for malicious purposes.
​ API Security—protects APIs by ensuring only desired traffic
can access your API endpoint, as well as detecting and
blocking exploits of vulnerabilities.
​
​ RASP—keep your applications safe from within against
known and zero‑day attacks. Fast and accurate protection
with no signature or learning mode.
​ Attack Analytics—mitigate and respond to real security
threats efficiently and accurately with actionable intelligence
across all your layers of defense.
Security measures in code and operating system protection are
not enough. When an organization discovers a buffer overflow
vulnerability, it must react quickly to patch the affected software
and make sure that users of the software can access the patch.

The goals of these principles are to identify and to highlight the most
important objectives developers should keep in mind when designing and
building a secure system from Viega and McGraw’s perspective.

1. Secure the weakest link.

2. Practice defense in depth.
3. Fail securely.
4. Follow the principle of least privilege.
5. Compartmentalize.
6. Keep it simple.
7. Promote Privacy.
8. Remember that hiding secrets is hard.
9. Be reluctant to trust.
10. Use your community resources.
1. Secure the weakest link.

The software security system is only as secure as its weakest components.

Attackers will attack the weakest parts of your system because they are the
parts most likely to be easily broken. Identifying the weakest component of
a system falls directly out of a good risk analysis. Given good risk analysis
data, addressing the most serious risk first, instead of a risk that may be
easiest to mitigate. Deal with one or two major problems, and move on to
the remaining ones in order of severity. Of course 100% security is never
attainable and it is ok to stop addressing risks when all components appear
to be within the threshold of acceptable risk for the business.

2. Practice Defense in Depth.

The idea behind the defense in depth is to manage risk with diverse
defensive strategies, so that if one layer of defense turns out to be
inadequate, another layer of defense hopefully prevents a full breach. The
difference between this principle and the one before is that this principle
here handles on taking defense as a whole, thinking of redundant security
measures. The idea is that having a sum of protection is far greater than
the protection offered by any single component.

3. Fail Securely.

Failure is unavoidable and should be planned for. What is avoidable are

security problems related to failure. The problem is that when many
systems fail in any way, they exhibit insecure behavior. In such systems,
attackers only need to cause the right kind of failure or wait for the right
kind of failure to happen. The main lesson here is that the developers
should think that if their software will fail, make sure it does so securely!
4. Follow the Principle of Least Privilege.

This principle states that only the minimum access necessary to perform an
operation should be granted, and that access should be granted only for
the minimum amount of time necessary. When you give out access to parts
of a system, there is always some risk that the privileges associated with
that access will be abused. Sometimes more privileges than necessary are
requested during coding to make developing task easier, for example, one
might say: "Someday I might need to write this object, and it would suck to
have to go back and change this request". Insecure defaults may lead to a
violation here too. This problem is nowadays more common because many
legacy systems were intended to run in a restricted environment.

5. Compartimentalize.

The basic idea behind the compartmentalization is to minimize the amount

of damage that can be done to a system by breaking up the system into a
few units as possible while still isolating code that has security privileges.
The classic example of poor compartmentalization is the standard UNIX
privilege model, in which interesting operations work on all-or-northing
basis. If you have root privileges, you can do anything you want anywhere
on the system. Given a device driver, if an attacker exploits a buffer
overflow in the code, the attacker make raw writes to disk and mess with
any data in the kernel's memory.
6. Keep it simple Complexity increases the risk of problems.

For example, the compartmentalization principle must be used in

moderation. If you segregate each little bit of functionality, then your system
will become completely unmanageable. Complex design is never easy to
understand, and is more likely to include subtle problems that will be
missed during analysis, and more bugs will be bypassed at the testing
phase. Consider reusing components whenever possible, as long as the
components to be reused are believed to be of good quality. Of course,
there is always the possibility of problems even in widely used components,
but it's reasonable to suspect that there's less risk involved in the known
quantity.

7. Promote Privacy.

There is often no quicker way to lose customer respect than to abuse user
privacy. Therefore, developers should be as diligent as possible in
protecting any personal user information. One of the things privacy most
often trades off against is usability. For example, it is better that a webpage
forgets the credit card numbers as soon that they are used, than to risk
being compromised information. Leaving any sort of information around
can help potential attackers. The main advice here is to promote privacy for
your users, systems, and for your code.

8. Remember That Hiding Secrets is Hard.

This principle assumes that even the most secure systems are amenable to
inside attacks. Several studies show that the most common threat to
companies is the insider attack, therefore, the potential for serious misuse
and abuse is a very real risk.
9. Be reluctant to Trust.

There are hundreds of products from security vendors with gaping security
holes. Therefore, instead of making assumptions that need to hold true, the
developers should be reluctant to extend trust. Trust is for example, often
extended far to easily in the area of customer support, just because "it
makes their jobs easier".

10. Use Community Resources.

There are many websites and sources of information for "known threats"
and vulnerabilities in software components and systems. It is far better to
trust security libraries that have been widely scrutinize and used. Still, there
are many examples of security bugs in widely used pieces of software that
have gone unnoticed for years. So not always it is the safest to use, but at
least it is possible to leverage the experience of others.