3. Memory Security Vulnerabilities > 자유게시판

We’ll begin our dialogue of vulnerabilities with one in every of the most typical kinds of errors - buffer overflow (also called buffer overrun) vulnerabilities. Buffer overflow vulnerabilities are a specific danger in C, and since C is an especially widely used programs programming language, you may not be shocked to hear that buffer overflows are one of the most pervasive type of implementation flaws around. Objective-C each undergo from these vulnerabilities as well. C is a low-degree language, meaning that the programmer is at all times exposed to the bare machine, one of the the reason why C is such a popular methods language. Furthermore, C can be a very old language, that means that there are a number of legacy programs, that are previous codebases written in C which might be nonetheless maintained and up to date. A specific weakness that we'll discuss is the absence of automated bounds-checking for array or pointer accesses. It's the programmer’s responsibility to rigorously test that every Memory Wave entry is in bounds.

This can get troublesome as your code will get increasingly complicated (e.g. for loops, person inputs, multi-threaded packages). It is thru this absence of automatic bounds-checking that buffer overflows benefit from. A buffer overflow bug is one the place the programmer fails to perform satisfactory bounds checks, triggering an out-of-bounds memory access that writes beyond the bounds of some memory area. Attackers can use these out-of-bounds memory accesses to deprave the program’s supposed conduct. Let us begin with a easy instance. If the enter comprises greater than eight bytes of knowledge, then will get() will write previous the top of buf, overwriting another a part of memory. This can be a bug. In C, static memory is stuffed in the order that variables are outlined, so authenticated is at the next deal with in Memory Wave Routine than buf (since static memory grows upward and buf was outlined first, buf is at a decrease memory address). Think about that elsewhere in the code, there is a login routine that sets the authenticated flag provided that the user proves knowledge of the password.

Unfortunately, the authenticated flag is saved in memory right after buf. Be aware that we use "after" here to mean "at a better Memory Wave address". If the attacker can write 9 bytes of data to buf (with the ninth byte set to a non-zero value), then this may set the authenticated flag to true, Memory Wave Routine and the attacker can be in a position to achieve access. The program above allows that to happen, because the gets function does no bounds-checking; it would write as much knowledge to buf as is equipped to it by the consumer. In other words, the code above is weak: an attacker who can control the input to this system can bypass the password checks. In memory, this can be a 4-byte worth that stores the deal with of a operate. In other phrases, calling fnptr will trigger the program to dereference the pointer and start executing directions at that deal with. Like authenticated in the earlier example, fnptr is stored instantly above buf in memory.

Suppose the function pointer fnptr is called elsewhere in the program (not shown). This allows a extra severe attack: the attacker can overwrite fnptr with any handle of their selecting, redirecting program execution to another memory location. Discover that in this assault, the attacker can select to overwrite fnptr with any handle of their choosing-so, as an illustration, they can select to overwrite fnptr with an deal with the place some malicious machine directions are stored. This is a malicious code injection attack. In fact, many variations on this assault are doable: the attacker could store malicious code anywhere in memory and redirect execution to that tackle. Malicious code injection assaults allow an attacker to grab control of the program. On the conclusion of the assault, the program is still operating, however now it is executing code chosen by the attacker, slightly than the original code. For example, consider a web server that receives requests from shoppers throughout the network and processes them.

If the net server accommodates a buffer overrun within the code that processes such requests, a malicious consumer can be able to grab management of the web server course of. If the net server is running as root, once the attacker seizes management, the attacker can do anything that root can do; for example, the attacker can depart a backdoor that allows them to log in as root later. At that point, the system has been "owned"1. The assaults illustrated above are solely potential when the code satisfies sure particular situations: the buffer that may be overflowed have to be adopted in memory by some security-important data (e.g., a perform pointer, or a flag that has a vital affect on the subsequent movement of execution of the program). As a result of these conditions happen solely not often in apply, attackers have developed simpler strategies of malicious code injection. One highly effective methodology for exploiting buffer overrun vulnerabilities takes benefit of the way native variables are laid out on the stack.