SANS Top 25 Software Errors (Part 1 of 25): CWE-787 Out-of-bounds Write

Secpy Community
InfoSec Write-ups
Published in
4 min readSep 26, 2022

--

Photo by ThisisEngineering RAEng on Unsplash

It is a type of software vulnerability which is listed under the ID: CWE-787. An out-of-bounds write vulnerability can lead to arbitrary code execution or a crash in software, caused by a program writing outside an allocated area of memory. Data can be written to an incorrect location in the memory area when its size exceeds the allocated memory area leading to buffer overflow or when the program is calculating the data size or location incorrectly.

An attacker can exploit Out-of-Bounds Write vulnerabilities to execute arbitrary code or crash a program. This vulnerability can sometimes lead to the overwriting of critical program data structures, such as heap control blocks, which could cause a denial-of-service. A software out-of-bounds write vulnerability occurs when the software writes data outside of the buffer or before it, causing data corruption. In addition to overwriting function pointers and return addresses on the stack, an attacker can also use an out-of-bounds write to modify program execution flow.

It is possible to directly address memory locations in certain languages, but these locations are not automatically checked to ensure that they are valid for the memory buffer being referenced. A read or write operation can result in reading or writing to memory locations that are related to other variables, data structures, or internal program data.

Memory Corruption

When something other than a sequential copy of excessive data from a fixed starting point is causing the root cause of memory corruption, the term “memory corruption” is often used to describe the consequences. C or C++ are some of the programming languages that are most likely to experience memory corruption bugs. The problem of memory corruption has existed for more than 30 years when it comes to computer security. Due to the lack of memory safety (or type safety) in these languages, attackers can alter the program’s behavior or even take full control of it by exploiting memory bugs.

The memory allocation and deallocation of memory is handled by blocks in the C/C++ programming languages along with the malloc()/calloc() methods. Accessing array elements outside the array limit can lead to many problems, such as setting unpredictable values to the next memory element or setting invalid pointers. Even dynamic memory allocators can be corrupted, leading to crashes in the application process. In order to stop exploitations, stack overflows, heap overflows and integer overflows should be prevented. The most widely exploited memory corruption flaws are stack overflows. Java, Ada, SML and other programming languages are much safer than C/C++ and buffer overflows cannot be performed on them.

Security attacks can be defeated in several ways. Type-safe programming languages, formal methods and compiler analyses are among the ways that can be used to prevent programs from being written in an insecure way. This does not solve every security problem, but does help solve most of them.

Stack-based Buffer Overflow

An execution stack typically contains several security-critical data that can be exploited to execute arbitrary code. One such data is the stored return address, at which execution should continue after the current function has successfully completed. It is possible for the attacker to overwrite this value with arbitrary code that can be run with full privileges of the vulnerable program, as long as the attacker has write access to that memory address as well. In addition, the attacker may supply arguments to an important call, for example POSIX system().

As a result, the attacker forces the program to jump into an interesting routine in the C standard library (libc) at return time, making it often called a return into libc exploit. It is also common for stack pointers and frame pointers to be on the stack, which indicate the offsets for computing memory addresses on the stack. When those values are modified, “write-what-where” conditions can often be derived.

Heap-based Buffer Overflow

When a heap overflow occurs, a buffer overflow occurs when an overwritten buffer is allocated in the heap portion of memory. This generally means that a routine such as malloc() was used to allocate the buffer.

Conclusion

Rather than a sequential copy of excessive data from a fixed starting location, the root cause may be something else. There may be errors in the arithmetic of pointers, or invalid pointers being accessed due to incomplete initialization or memory release, for instance. In general, this type of attack occurs during the implementation phase of software. It is most often observed in software written in C or C++.

If find() returns a negative value to indicate that ch is not found in srcBuf, it can cause a buffer underwrite. The following code may result in a buffer underwrite:

int main() 
{
...
strncpy(destBuf, &srcBuf[find(srcBuf, ch)], 1024);
...
}

It is an arbitrary write-what-where condition if the index to srcBuf is under user control. This problem can be found both manually and automatically using static and dynamic analysis.

From Infosec Writeups: A lot is coming up in the Infosec every day that it’s hard to keep up with. Join our weekly newsletter to get all the latest Infosec trends in the form of 5 articles, 4 Threads, 3 videos, 2 GitHub Repos and tools, and 1 job alert for FREE!

--

--

SecPy Community aims to change whole environment of Cyber Security and Ethical Hacking with the help of curious minds & build ground-breaking solutions