Auditing Memory Management
| Memory management is a core element of every program, whether it is performed explicitly by the developer or implicitly by the programming language and runtime. To complete your understanding of programming building blocks you need to examine the common issues in managing memory, and the security-relevant impact of mismanagement. The following sections explore these issues and present you with a few tools to help make you more productive in identifying memory management vulnerabilities. ACC LogsErrors in memory management are almost always the result of length miscalculations; so one of the first steps in auditing memory management is to develop a good process for identifying length miscalculations. Some miscalculations stand out, but others are quite easy to miss. So there's a tool help you identify even the most subtle length miscalculations, called allocation-check-copy (ACC) logs. An ACC log is simply intended to record any variations in allocation sizes, length checks, and data element copies that occur on a memory block. An ACC log is divided into three columns for each memory allocation. The first column contains a formula for describing the size of memory that's allocated, which can be a formula or a static number if the buffer is statically sized. The next column contains any length checks that data elements are subjected to before being copied into the allocated buffer. The third column is used to list which data elements are copied into the buffer and the way in which they are copied. Separate copies are listed one after the other. Finally, you can have an optional fourth column, where you note any interesting discrepancies you determined from the information in the other three columns. Look at a sample function in Listing 7-33, and then examine its corresponding ACC log in Table 7-5. Listing 7-33. Length Miscalculation Example for Constructing an ACC Log
Listing 7-33 shows some code that reads a packet from a fictitious protocol and allocates and reads different elements from the packet. A sample ACC log is shown is Table 7-5. In the ACC log, you record the specifics of how a buffer is allocated, what length checks are performed, and how data is copied into the buffer. This compact format quickly summarizes how dynamic memory allocations and copies are done and whether they are safe. Notice that the entry for the cipherlist variable mentions that ciphers are copied one at a time. This detail is important when you're determining whether an operation is safe. If this function did a single read of ciphers_count * sizeof(struct cipher), the allocation and copy lengths would be identical, so the code would be safe regardless of whether an integer overflow occurred. Checks sometimes happen before an allocation; if so, you might want to rearrange the first two columns to make the record easier to understand. ACC logs are intended to help you identify length checks that could cause problems; however, they aren't a complete assessment of the memory safety of an operation. To understand this point, look at the following example: ciphers_count = read_integer(sockfd); if(ciphers_count >= ((unsigned int)(~0)) /sizeof(struct cipher)) return -1; cipherlist = (struct cipher *) allocate(ciphers_count * sizeof(struct cipher)); if(cipherlist == NULL) return -1; This code has a length check that you would add to your ACC record, but does this mean you can conclude this memory copy is secure? No. This function doesn't use a system allocator to allocate cipherlist; instead, it uses a custom allocate() function. To determine whether this code is secure, you need to consult your allocator scorecard (a tool introduced later in this section) as well. Only then could you conclude whether this allocation is safe. The following sections present several examples of buffer length miscalculations you can use to test out your ACC logging skills. These examples help expose you to a variety of situations in which length miscalculations occur, so you're comfortable as you encounter similar situations in your own code assessments. Unanticipated ConditionsLength miscalculations can arise when unanticipated conditions occur during data processing. In the following example, the code is printing some user-supplied data out in hexadecimal: u_char *src, *dst, buf[1024]; for(src = user_data, dst = buf; *src; src++){ snprintf(dst, sizeof(buf) - (dst buf), "%2.2x", src); dst += 2; }This developer makes the assumption, however, that snprintf() successfully writes the two bytes into the buffer because the loop always increments dst by 2 (as shown in the bolded line). If no bytes or only one byte were left in the buffer, dst would be incremented too far, and subsequent calls to snprintf() would be given a negative size argument. This size would be converted to a size_t and, therefore, interpreted as a large positive value, which would allow bytes to be written past the end of the destination buffer. Data AssumptionsQuite often when auditing code dealing with binary data, you see that programmers tend to be more trusting of the content, particularly in applications involving proprietary file formats and protocols. This is because they haven't considered the consequences of certain actions or they assume that only their applications will generate the client data or files. Often developers assume that no one would bother to reverse-engineer the data structures necessary to communicate with their software. History has told a very different story, however. People can, and frequently do, reverse-engineer closed-source products for the purpose of discovering security problems. If anything, researchers are even more willing and prepared to scrutinize complex and proprietary protocols via manual analysis, blackbox testing, and automated fuzzing. Some of the simplest examples of data assumption errors are those in which developers make assumptions about a data element's largest possible size, even when a length is specified before the variable-length data field! Listing 7-34 shows an example from the NSS library used in Netscape Enterprise (and Netscape-derived Web servers) for handling SSL traffic. Listing 7-34. Buffer Overflow in NSS Library's ssl2_HandleClientHelloMessage
In Listing 7-34, the server takes a length field of challenge data supplied by the client, and then copies that much data from the packet into the ss->sec.ci.ClientChallenge buffer, which is statically sized to 32 bytes. The code simply neglects to check whether the supplied length is smaller than the destination buffer. This simple error is fairly commoneven more so in closed-source applications. Order of ActionsActions that aren't performed in the correct order can also result in length miscalculation. Listing 7-35 shows a subtle example of how this problem could occur. Listing 7-35. Out-of-Order Statements
Listing 7-35 contains an error where it writes the time string, returned from get_time_string(), into the buffer. The ptr variable is incremented to the end of the time string, and then the string length of ptr is subtracted from maxsize. These two operations happen in the wrong order. Because ptr has already been incremented, maxsize is decremented by zero. Therefore, maxsize fails to account for the time string, and a buffer overflow could occur when vsnprintf() is called with the incorrect length. Multiple Length Calculations on the Same InputA common situation that leads to length miscalculations in applications is data being processed more than once at different places in the programtypically with an initial pass to determine the length and then a subsequent pass to perform the data copy. In this situation, the auditor must determine whether any differences exist between the length calculation code fragment and the data copy code fragment. The following code from Netscape Enterprise/Mozilla's NSS library shows code responsible for processing UCS2 data strings. The function iterates through the string and calculates the amount of space needed for output, and if the destination buffer is large enough, the function stores it. Listing 7-36 shows the loop for this calculation. Listing 7-36. Netscape NSS Library UCS2 Length Miscalculation
Note that there's a small variance when the data copy actually occurs later in the same function, as shown in the following code: for( i = 0; i < inBufLen; i += 2 ) { if( (inBuf[i+H_0] == 0x00) && ((inBuf[i+H_1] & 0x80) == 0x00) ) { /* 0000-007F -> 0xxxxxx */ /* 00000000 0abcdefg -> 0abcdefg */ outBuf[len] = inBuf[i+H_1] & 0x7F; len += 1; } else if( inBuf[i+H_0] < 0x08 ) { /* 0080-07FF -> 110xxxxx 10xxxxxx */ /* 00000abc defghijk -> 110abcde 10fghijk */ outBuf[len+0] = 0xC0 | ((inBuf[i+H_0] & 0x07) << 2) | ((inBuf[i+H_1] & 0xC0) >> 6); outBuf[len+1] = 0x80 | ((inBuf[i+H_1] & 0x3F) >> 0); len += 2; ...Do you see it? When the length calculation is performed, only one byte of output is expected when a NUL byte is encountered in the character stream because the H_0 offset into inBuf is used twice in the length calculation. You can see that the developer intended to test the following byte to see whether the high-bit is set but uses H_0 instead of H_1. The same mistake isn't made when the actual copy occurs. During the copy operation, you can clearly see that if the following byte has the highest bit set, two bytes are written to the output buffer because a second check is in the bolded if clause. Therefore, by supplying data containing the byte sequence 0x00, 0x80, you can cause more data to be written to the output buffer than was originally anticipated. As it turns out, the vulnerability can't be exploited in Netscape because the output buffer is rather large, and not enough input data can be supplied to overwrite arbitrary memory. Even though the error isn't exploitable, the function still performs a length calculation incorrectly, so it's worth examining. Allocation FunctionsProblems can occur when allocation functions don't act as the programmer expects. Why would they not act as expected? You supply a size, and the function returns a memory block of that size. It's simple, right? However, code doesn't always behave exactly as expected; when dealing with memory allocations you need to be aware of the unusual cases. Larger applications often use their own internal memory allocation instead of calling the OS's allocation routines directly. These application-specific allocation routines can range from doing nothing except calling the OS routines (simple wrappers) to complex allocation subsystems that optimize the memory management for the application's particular needs. You can generally assume that system libraries for memory allocation are used extensively and are presumably quite sound; however, the same can't be said for application-specific allocators because they run the gamut in terms of quality. Therefore, code reviewers must watch for erroneous handling of requests instead of assuming these custom routines are sound. You should audit them as you would any other complex codeby keeping a log of the semantics of these routines and noting possible error conditions and the implications of those errors. Because allocation routines are so universal and try to achieve much the same purpose from application to application, the following sections cover the most common problems you should watch for. Is It Legal to Allocate 0 Bytes?Many code auditors know that requesting an allocation of 0 bytes on most OS allocation routines is legal. A chunk of a certain minimum size (typically 12 or 16 bytes) is returned. This piece of information is important when you're searching for integer-related vulnerabilities. Consider the code in Listing 7-37. Listing 7-37. Integer Overflow with 0-Byte Allocation Check
In this code, attackers can specify a length that's incremented and passed to my_malloc(). The call to my_malloc() will be passed the value 0 when the length variable contains the maximum integer that can be represented (0xFFFFFFFF), due to an integer overflow. String data of length bytes is then read into the chunk of memory returned by the allocator. If this code called the malloc() or calloc() system allocation routines directly, you could conclude that it's a vulnerability because attackers can cause a large amount of data to be copied directly into a very small buffer, thus corrupting the heap. However, the code isn't using system libraries directly; it's using a custom allocation routine. Here is the code for my_malloc(): void *my_malloc(unsigned int size) { if(size == 0) return NULL; return malloc(size); }Although the allocation routine does little except act as a wrapper to the system library, the one thing it does do is significant: It specifically checks for 0-byte allocations and fails if one is requested. Therefore, the get_string_from_network() function, although not securely coded, isn't vulnerable (or, more accurately, isn't exploitable) to the integer overflow bug explained previously. The example in Listing 7-37 is very common. Developers often write small wrappers to allocation routines that check for 0-byte allocations as well as wrappers to free() functions that check for NULL pointers. In addition, potential vulnerabilities, such as the one in get_string_from_network(), are common when processing binary protocols or file formats. It is often necessary to add a fixed size header or an extra space for the NUL character before allocating a chunk of memory. Therefore, you must know whether 0-byte allocations are legal, as they can mean the difference between code being vulnerable or not vulnerable to a remote memory corruption bug. Does the Allocation Routine Perform Rounding on the Requested Size?Allocation function wrappers nearly always round up an allocation size request to some boundary (8-byte boundary, 16-byte boundary, and so on). This practice is usually acceptable and often necessary; however, if not performed properly it could expose the function to an integer overflow vulnerability. An allocation routine potentially exposes itself to this vulnerability when it rounds a requested size up to the next relevant boundary without performing any sanity checks on the request size first. Listing 7-38 shows an example. Listing 7-38. Allocator-Rounding Vulnerability
The intention of the bolded line in this function is to round up size to the next 16-byte boundary by adding 15 to the request size, and then masking out the lower four bits. The function fails to check that size is less than the 0xFFFFFFF1, however. If this specific request size is passed (or any request size between 0xFFFFFFF1 up to and including 0xFFFFFFFF), the function overflows a 32-bit unsigned integer and results in a 0-byte allocation. Keep in mind that this function would not be vulnerable if size had been checked against 0 after the rounding operation. Often the difference between vulnerable and safe code is a minor change in the order of events, just like this one. Are Other Arithmetic Operations Performed on the Request Size?Although rounding up an unchecked request size is the most common error that exposes an allocation routine to integer vulnerabilities, other arithmetic operations could result in integer-wrapping vulnerabilities. The second most common error happens when an application performs an extra layer of memory management on top of the OS's management. Typically, the application memory management routines request large memory chunks from the OS and then divide it into smaller chunks for individual requests. Some sort of header is usually prepended to the chunk and hence the size of such a header is added to the requested chunk size. Listing 7-39 shows an example. Listing 7-39. Allocator with Header Data Structure
This simple addition operation introduces the potential for an integer overflow vulnerability that is very similar to the problem in Listing 7-37. In this case, the my_malloc3() function is vulnerable to an integer overflow for any size values between 0xFFFFFFFF and 0xFFFFFFFF - sizeof(struct block_hdr). Any value in this range will result in the allocation of a small buffer for an extremely large length request. Reallocation functions are also susceptible to integer overflow vulnerabilities because an addition operation is usually required when determining the size of the new memory block to allocate. Therefore, if users can specify one of these sizes, there's a good chance of an integer wrap occurring. Adequate sanity checking is rarely done to ensure the safety of reallocation functions, so code reviewers should inspect carefully to make sure these checks are done. Listing 7-40 shows a function that increases a buffer to make space for more data to be appended. Listing 7-40. Reallocation Integer Overflow
The bolded code in Listing 7-40 shows a potentially dangerous addition operation. If users can specify the bytes value, bytes + buf->alloc_size can be made to wrap, and realloc() returns a small chunk without enough space to hold the necessary data. Are the Data Types for Request Sizes Consistent?Sometimes allocation functions can behave unexpectedly because of typing issues. Many of the typing issues discussed in Chapter 6 are especially relevant when dealing with allocators, as any mistake in type conversions more than likely results in a memory corruption vulnerability that's readily exploitable. On occasion, you might come across memory allocators that use 16-bit sizes. These functions are more vulnerable to typing issues than regular allocators because the maximum value they can represent is 65535 bytes, and users are more likely to be able to specify data chunks of this size or larger. Listing 7-41 shows an example. Listing 7-41. Dangerous Data Type Use
The only thing you need to do to trigger a vulnerability is find a place in the code where my_malloc4() can be called with a value can be larger than 65535 (0xFFFF) bytes. If you can trigger an allocation of a size such as 0x00010001 (which, depending on the application, isn't unlikely), the value is truncated to a short, resulting in a 1-byte allocation. The introduction of 64-bit systems can also render allocation routines vulnerable. Chapter 6 discusses 64-bit typing issues in more detail, but problems can happen when intermixing long, size_t, and int data types. In the LP64 compiler model, long and size_t data types are 64-bit, whereas int types occupy only 32 bits. Therefore, using these types interchangeably can have unintended and unexpected results. To see how this might be a problem, take another look at a previous example. void *my_malloc(unsigned int size) { if(size == 0) return NULL; return malloc(size); }As stated previously, this allocation wrapper doesn't do much except check for a 0-length allocation. However, it does one significant thing: It takes an unsigned int parameter, as opposed to a size_t, which is what the malloc() function takes. On a 32-bit system, these data types are equivalent; however, on LP64 systems, they are certainly not. Imagine if this function was called as in Listing 7-42. Listing 7-42. Problems with 64-Bit Systems
The read_string() function specifically checks for integer overflows before calling the allocation routine. On 32-bit systems, this code is fine, but what about 64-bit systems? The length variable in read_string() is a size_t, which is 64 bits. Assuming that get_network_integer() returns an int, look at the integer overflow check more carefully: if(length + 2 < length) return -1; On an LP64 system both sides of this expression are 64-bit integers, so the check can only verify that a 64-bit value does not overflow. When my_malloc() is called, however, the result is truncated to 32 bits because that function takes a 32-bit integer parameter. Therefore, on a 64-bit system, this code could pass the first check with a value of 0x100000001, and then be truncated to a much smaller value of 0x1 when passed as a 32-bit parameter. Whether values passed to memory allocation routines are signed also becomes quite important. Every memory allocation routine should be checked for this condition. If an allocation routine doesn't do anything except pass the integer to the OS, it might not matter whether the size parameter is signed. If the routine is more complex and performs calculations and comparisons based on the size parameter, however, whether the value is signed is definitely important. Usually, the more complicated the allocation routine, the more likely it is that the signed condition of size parameters can become an issue. Is There a Maximum Request Size?A lot of the previous vulnerability conditions have been based on a failure to sanity check request sizes. Occasionally, application developers decide to arbitrarily build in a maximum limit for how much memory the code allocates, as shown in Listing 7-43. A maximum request size often thwarts many potential attacks on allocation routines. Code auditors should identify whether a maximum limit exists, as it could have an impact on potential memory corruption vulnerabilities elsewhere in the program. Listing 7-43. Maximum Limit on Memory Allocation
The allocator in Listing 7-43 is quite restrictive, in that it allows allocating only small chunks. Therefore, it's not susceptible to integer overflows when rounding up the request size after the size check. If rounding were performed before the size check rather than after, however, the allocator would still be vulnerable to an integer overflow. Also, note whether the size parameter is signed. Had this argument been negative, you could evade this maximum size check (and wrap the integer over the 0-boundary during the rounding up that follows the size check). Is a Different Size Memory Chunk Than Was Requested Ever Returned?Essentially all integer-wrapping vulnerabilities become exploitable bugs for one reason: A different size memory chunk than was requested is returned. When this happens, there's the potential for exploitation. Although rare, occasionally a memory allocation routine can resize a memory request. Listing 7-44 shows the previous example slightly modified. Listing 7-44. Maximum Memory Allocation Limit Vulnerability
The my_malloc6() function in Listing 7-44 doesn't allocate a block larger than MAX_MEMORY_BLOCK. When a request is made for a larger block, the function resizes the request instead of failing. This is very dangerous when the caller passes a size that can be larger than MAX_MEMORY_BLOCK and assumes it got a memory block of the size it requested. In fact, there's no way for the calling function to know whether my_malloc6() capped the request size at MAX_MEMORY_BLOCK, unless every function that called this one checked to make sure it wasn't about to request a block larger than MAX_MEMORY_BLOCK, which is extremely unlikely. To trigger a vulnerability in this program, attackers simply have to find a place where they can request more than MAX_MEMORY_BLOCK bytes. The request is silently truncated to a smaller size than expected, and the calling routine invariably copies more data into that block than was allocated, resulting in memory corruption. Allocator Scorecards and Error DomainsWhen reviewing applications, you should identify allocation routines early during the audit and perform a cursory examination on them. At a minimum, you should address each potential danger area by scoring allocation routines based on the associated vulnerability issuescreating a sort of scorecard. You can use this scorecard as a shorthand method of dealing with allocators so that you don't need to create extensive audit log. However, you should still search for and note any unique situations that haven't been addressed in your scorecard, particularly when the allocation routine is complex. Take a look at what these allocator scorecards might look like in Table 7-6.
This scorecard summarizes all potential allocator problem areas. There's no column indicating whether values are signed or listing 16-bit issues because you can instantly deduce this information from looking at the function prototype. If the function has internal issues caused by the signed conditions of values, list them in the Notes row of the scorecard. For simple allocators, you might be able to summarize even further to error domains. An error domain is a set of values that, when supplied to the function, generate one of the exceptional conditions that could result in memory corruption. Table 7-7 provides an example of summarizing a single error domain for a function.
Each allocator might have a series of error domains, each with different implications. This shorthand summary is a useful tool for code auditing because you can refer to it and know right away that, if an allocator is called with one of the listed values, there's a vulnerability. You can go through each allocator quickly as it's called to see if this possibility exists. The advantage of this tool is that it's compact, but the downside is you lose some detail. For more complicated allocators you may need to refer to more detailed notes and function audit logs. Error domain tables can be used with any functions you audit, not just allocators; however, there are some disadvantages. Allocation functions tend to be small and specific, and you more or less know exactly what they do. Allocator scorecards and error domain tables help capture the differences between using system-supplied allocation routines and application-specific ones that wrap them. With other functions that perform more complex tasks, you might lose too much information when attempting to summarize them this compactly. Double-FreesOccasionally, developers make the mistake of deallocating objects twice (or more), which can have consequences as serious as any other form of heap corruption. Deallocating objects more than once is dangerous for several reasons. For example, what if a memory block is freed and then reallocated and filled with other data? When the second free() occurs, there's no longer a control structure at the address passed as a parameter to free(), just some arbitrary program data. What's to prevent this memory location from containing specially crafted data to exploit the heap management routines? There is also a threat if memory isn't reused between successive calls to free() because the memory block could be entered into free-block list twice. Later in the program, the same memory block could be returned from an allocation request twice, and the program might attempt to store two different objects at the same location, possibly allowing arbitrary code to run. The second example is less common these days because most memory management libraries (namely, Windows and GNU libc implementations) have updated their memory allocators to ensure that a block passed to free() is already in use; if it's not, the memory allocators don't do anything. However, some OSs have allocators that don't protect against a double free attack; so bugs of this nature are still considered serious. When auditing code that makes use of dynamic memory allocations, you should track each path throughout a variable's lifespan to see whether it's accidentally deallocated with the free() function more than once. Listing 7-45 shows an example of a double-free vulnerability. Listing 7-45. Double-Free Vulnerability
In this example, you can see that the bolded code path frees data twice because when it doesn't identify a valid keyword. Although this error seems easy to avoid, complex applications often have subtleties that make these mistakes harder to spot. Listing 7-46 is a real-world example from OpenSSL 0.9.7. The root cause of the problem is the CRYPTO_realloc_clean() function. Listing 7-46. Double-Free Vulnerability in OpenSSL
As you can see, the CRYPTO_realloc_clean() function frees the str parameter passed to it, whether it succeeds or fails. This interface is quite unintuitive and can easily lead to double-free errors. The CRYPTO_realloc_clean() function is used internally in a buffer-management routine, BUF_MEM_grow_clean(), which is shown in the following code: int BUF_MEM_grow_clean(BUF_MEM *str, int len) { char *ret; unsigned int n; if (str->length >= len) { memset(&str->data[len],0,str->length-len); str->length=len; return(len); } if (str->max >= len) { memset(&str->data[str->length],0,len-str->length); str->length=len; return(len); } n=(len+3)/3*4; if (str->data == NULL) ret=OPENSSL_malloc(n); else ret=OPENSSL_realloc_clean(str->data,str->max,n); if (ret == NULL) { BUFerr(BUF_F_BUF_MEM_GROW,ERR_R_MALLOC_FAILURE); len=0; } else { str->data=ret; str->max=n; memset(&str->data[str->length],0,len-str->length); str->length=len; } return(len); }As a result of calling OPENSSL_realloc_clean(), the BUF_MEM_grow_clean() function might actually free its own data element. However, it doesn't set data to NULL when this reallocation failure occurs. This quirky behavior makes a double-free error likely in functions that use BUF_MEM structures. Take a look at this call in asn1_collate_primitive(): if (d2i_ASN1_bytes(&os,&c->p,c->max-c->p, c->tag,c->xclass) == NULL) { c->error=ERR_R_ASN1_LIB; goto err; } if (!BUF_MEM_grow_clean(&b,num+os->length)) { c->error=ERR_R_BUF_LIB; goto err; } ... err: ASN1err(ASN1_F_ASN1_COLLATE_PRIMITIVE,c->error); if (os != NULL) ASN1_STRING_free(os); if (b.data != NULL) OPENSSL_free(b.data); return(0); }This function attempts to grow the BUF_MEM structure b, but when an error is returned, it frees any resources it has and returns 0. As you know now, if BUF_MEM_grow_clean() fails because of a failure in CRYPTO_realloc_clean(), it frees b.data but doesn't set it to NULL. Therefore, the bolded code frees b.data a second time. Code auditors should be especially aware of double-frees when auditing C++ code. Sometimes keeping track of an object's internal state is difficult, and unexpected states could lead to double-frees. Be mindful of members that are freed in more than one member function in an object (such as a regular member function and the destructor), and attempt to determine whether the class is ever used in such a way that an object can be destructed when some member variables have already been freed. Double-free errors can crop up in other ways. Many operating systems' reallocation routines free a buffer that they're supposed to reallocate if the new size for the buffer is 0. This is true on most UNIX implementations. Therefore, if an attacker can cause a call to realloc() with a new size of 0, that same buffer might be freed again later; there's a good chance the buffer that was just freed will be written into. Listing 7-47 shows a simple example. Listing 7-47. Reallocation Double-Free Vulnerability
This code shows some typical buffer-management routines. From what you have learned about allocation routines, you can classify a couple of interesting characteristics about buffer_grow(). Primarily, it checks for integer overflows when increasing the buffer, but that rounding is performed after the check. Therefore, whenever new_size() and buf->used are added together and give a result between 0xFFFFFFF1 and 0xFFFFFFFF, the roundup causes an integer overflow, and the value 0 is passed to realloc(). Also, notice that if realloc() fails, buf->data isn't set to a NULL pointer. This is important because when realloc() frees a buffer because of a 0-length parameter, it returns NULL. The following code shows some potential implications: int process_login(int sockfd) { int length; buffer *buf; buf = buffer_new(); length = read_integer(sockfd); if(buffer_grow(buf, length) < 0){ buffer_free(buf); return 1; } ... read data into the buffer ... return 0; }The process_login() function attempts to increase the buffer enough to store subsequent data. If the supplied length is large enough to make the integer wrap, the buf->data member is freed twiceonce during buffer_grow() when a size of 0 is passed to realloc(), and once more in buffer_free(). This example spans multiple functions for a specific reason; often bugs of this nature are spread out in this way and are less obvious. This bug would be easy to miss if you didn't pay careful attention to how buffer_grow() works (to notice the integer overflow) and to the nuances of how realloc() works. |
EAN: 2147483647
Pages: 194
- Step 1.1 Install OpenSSH to Replace the Remote Access Protocols with Encrypted Versions
- Step 2.1 Use the OpenSSH Tool Suite to Replace Clear-Text Programs
- Step 3.3 Use WinSCP as a Graphical Replacement for FTP and RCP
- Step 3.4 Use PuTTYs Tools to Transfer Files from the Windows Command Line
- Step 4.7 Using Public Key Authentication for Automated File Transfers