Periodically scan your web site with one or more of the commonly available scanners that look for buffer overflow flaws in your server products and your custom web applications. For your custom application code, you need to review all code that accepts input from users via the HTTP request and ensure that it provides appropriate size checking on all such inputs. This should be done even for environments that are not susceptible to such attacks as overly large inputs that are uncaught may still cause denial of service or other operational problems.
The following sample code demonstrates a simple buffer overflow that is often caused by the first scenario in which the code relies on external data to control its behavior. The code uses the gets function to read an arbitrary amount of data into a stack buffer. Because there is no way to limit the amount of data read by this function, the safety of the code depends on the user to always enter fewer than BUFSIZE characters. The code in this example also relies on user input to control its behavior, but it adds a level of indirection with the use of the bounded memory copy function memcpy.
This function accepts a destination buffer, a source buffer, and the number of bytes to copy. The input buffer is filled by a bounded call to read , but the user specifies the number of bytes that memcpy copies.
Note: This type of buffer overflow vulnerability where a program reads data and then trusts a value from the data in subsequent memory operations on the remaining data has turned up with some frequency in image, audio, and other file processing libraries.
This is an example of the second scenario in which the code depends on properties of the data that are not verified locally.
In this example a function named lccopy takes a string as its argument and returns a heap-allocated copy of the string with all uppercase letters converted to lowercase. If an attacker bypasses checks in the code that calls lccopy , or if a change in that code makes the assumption about the size of str untrue, then lccopy will overflow buf with the unbounded call to strcpy. The following code demonstrates the third scenario in which the code is so complex its behavior cannot be easily predicted.
This code is from the popular libPNG image decoder, which is used by a wide array of applications, including Mozilla and some versions of Internet Explorer. Although the code in this example is not the most complex we have seen, it demonstrates why complexity should be minimized in code that performs memory operations.
Buffer overruns are more easily exploited on platforms such as x86 and x64, which use calling conventions that store the return address of a function call on the stack. On x86, if a function uses an exception handler, the compiler injects a security cookie to protect the address of the exception handler. The cookie is checked during frame unwinding. A vulnerable parameter is allocated before the cookie and local variables.
A buffer overrun can overwrite these parameters. And code in the function that uses these parameters could cause an attack before the function returns and the security check is performed. To minimize this danger, the compiler makes a copy of the vulnerable parameters during the function prolog and puts them below the storage area for any buffers.
Functions that are marked with naked. A parameter is used only in ways that are less likely to be exploitable in the event of a buffer overrun. For example, if you have a buffer and a vtable in an object, a buffer overrun could corrupt the vtable. Open the project's Property Pages dialog box.
Skip to main content. This browser is no longer supported. Learn how to detect and prevent buffer overflow vulnerabilities, defend against attacks, and reduce your risk. Since the birth of the information security industry, buffer overflows have found a way to remain newsworthy.
This event launched cybersecurity to the forefront of computer science headlines for one of the first times in history. Nearly three decades later in , a buffer overflow vulnerability in the OpenSSL cryptography library was disclosed to the public. Impeding the next Heartbleed or Morris Worm first requires an understanding of buffer overflows and how to detect them.
Only once these are in place can a plan for buffer overflow prevention and mitigation be put into place. As the name implies, buffer overflow vulnerabilities deal with buffers, or memory allocations in languages that offer direct, low-level access to read and write memory. In the case of languages such as C and Assembly, reading from or writing to one of these allocations does not entail any automatic bounds checking. In other words, there is no check that the number of bytes to be written or read will actually fit in the buffer in question.
This results in data being written past its end and overwriting the contents of subsequent addresses on the stack or heap, or extra data being read. In fact, the latter is exactly what happened in the case of the Heartbleed bug. With this definition in mind, we can explore how to detect these flaws. When working with source code, the short answer to buffer overflows is just to pay special attention to where buffers are used, modified, and accessed.
Of particular note would be functions dealing with input supplied by a user or other outside source, as these would provide the easiest vector for exploitation of the overflow. Looking at the code, it is clear that no bounds checking is performed. This allows the user to force the program to exit the function at a different point in the code than originally intended, potentially causing the program to behave in dangerous and unintended ways. If the first step to detect buffer overflows in source code is understanding how they work, and the second step is knowing to look for external input and buffer manipulations, then the third step is to know what functions are susceptible to this vulnerability and can act as red flags for its presence.
As illustrated above, the gets function is perfectly happy writing past the bounds of the buffer provided to it. Anywhere one of these functions is used, there is likely to be a buffer overflow vulnerability. The ability to detect buffer overflow vulnerabilities in source code is certainly valuable. However, eliminating them from a code base requires consistent detection as well as a familiarity with secure practices for buffer handling.
The easiest way to prevent these vulnerabilities is to simply use a language that does not allow for them. C allows these vulnerabilities through direct access to memory and a lack of strong object typing.
Languages that do not share these aspects are typically immune. Java, Python, and. Completely changing the language of development is not always possible, of course.
0コメント