![]() ![]() A chunk is not in used if the corresponding memory has been freed (by a call to free). If it's not set the previous chunk is not in use. If it's set it means that the previous chunk is in use. ![]() Only the first ( least significant) bit is important for us. This means that the last 3 bits of the size field can be used for other purposes (these 3 bits would always be zero otherwise). And to simplify memory management the size of chunks is always a multiple of 8 bytes. Also surprising is that the prev_size field isn't used by allocated chunks! In a minute we will see that an unallocated (free) chunk does use the additional fields.Īnother important observation is that in glibc chunks are always 8-bytes aligned. This means an allocated chunk always has 8 bytes of metadata, after which the actual buffer starts. The buffer returned to the program starts at the fd field. For example, the only metadata present in an allocated chunk are the prev_size and size fields. The interpretation of the chunk structure depends on the current state of the chunk. If the top chunk is not large enough to fulfill the memory allocation, the program asks the operating system to expand the top chunk (making the heap grow in size). When a new memory request is made, the top chunk is split into two: the first part becomes the requested chunk, and the second part is the new the top chunk (so the "top chunk" shrunk in size). Well, the top chunk represents the remaining available memory on the heap, and it is the only chunk that can grow in size. Anyway, you're probably wondering why I included the meta data of the "top chunk" in the layout. The dash line "-" is an imaginary boundary between the chunks, in reality they are placed right next to each other ( example program illustrating the layout). The 1024 bytes of memory return by malloc Meta-data of chunk created by malloc(1024) Meta-data of chunk created by malloc(512) Meta-data of chunk created by malloc(256) So if a program were to call malloc(256), malloc(512), and finally malloc(1024), the memory layout of the heap is as follows: A chunk is defined in the glibc source as follows:Īssuming no memory chunks have been freed yet, new memory allocations are always stored right after the last allocated chunk. Similarly, the heap can shrink once a certain amount of memory has been freed. All these chunks are saved on the heap, which is a memory region capable of expanding when new memory is requested. A chunk consists of metadata and the memory returned to the program (i.e., the memory actually returned by malloc). First we need to know how the heap is managed (we focus on Linux).Įvery memory allocation a program makes (say by calling malloc) is internally represented by a so called "chunk". There's a blatant buffer overflow in line 10 which we will be exploiting. We assume we have non-root access to a computer but are able to run the following program as root (meaning it's a suid binary): This post will begin with a high level description of the heap and slowly builds up untill you able to write your own heap-based exploits. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |