The PostgresChecker: Hunting Use-after-free Bugs in PostgreSQL (1)
[1] Use-after-free - Problem Description
This blog series is structured in six parts, starting with the fundamental problem of use-after-free bugs and gradually moving toward the implementation and application of the PostgresChecker.
[1] Use-after-free – Problem Description
[2] Static Program Analysis – Approaches to Handle Use-after-frees
[3] Analyzing PostgreSQL – Extracting Information from the Codebase
[4] Implementing a Custom Static Analysis Tool – The PostgresChecker
[5] Applying the Checker – Finding Bugs in PostgreSQL
[6] Conclusio – Lessons Learned
In this blog series I am going to present the PostgresChecker: a static analysis tool that is able to detect use-after-free bugs in source code using the PostgreSQL API. In this first blog post I am going to discuss potential problems related to memory management in the C programming language in general and in the PostgreSQL API in particular. So grab a cup of coffee and let’s dig in.
Memory Management in C
Unlike other programming languages like Java, C does not have garbage collection. This means that developers themselves are responsible for allocating and releasing memory and most importantly doing it properly. A simple program (let’s call it ‚Hello Memory‘) handling memory in C might look like this:
In C, you have to be very explicit: In line 7 we request memory by calling the function malloc. The allocator then goes ahead and allocates a new block of memory for us and returns its address. This address is then stored in the pointer str. In line 9 we pass that pointer and a string to the strcpy function which writes the string to memory:
We can access the string stored in memory by passing the pointer to a function, i.e. printf in our example in line 11:
Printf looks at the address the pointer is pointing to and outputs anything it finds there, in our case „Hello World“.
In line 13 we free the allocated memory again, which means it is given back to the allocator to be reused. This is important in order to avoid costly memory leaks.
If we compile the program and run it, „Hello World“ is printed to the output, which is exactly what we wanted:
Use-after-free
However, what would happen if we accidentally called free on our pointer before we used it? Here is an example where the free and printf statements are switched:
If we compile and run the code now, we suddenly get garbage values:
This is not what we wanted at all. What happened here? As discussed in the previous example, with the call to free in line 11 the memory was returned to the allocator, which decided to overwrite our data:
Our printf statement is reading whatever it finds there. This is a classical use-after-free bug. But the worst part is that we cannot even be sure what the allocator is going to do with the returned memory. The old data might still be there and in 999 out of 1000 runs we don’t even notice the bug. Furthermore, the allocator may have unmapped the memory region entirely, meaning our program is no longer permitted to access it and will crash. Therefore, the behaviour is undefined and our program is not deterministic anymore, which is not something we want in a production system.
Use-after-free bugs can lead to garbage outputs and program crashes. If we were to not only read but also write to regions we are not supposed to they can even lead to data corruption and security breaches. Hence, they are to be avoided at all cost.
In summary, our scenario could lead to a number of problems including:
- Garbage values are returned
- The program crashes, because the memory does not belong to the process anymore (segmentation fault)
- If we write to the freed area, data might get corrupted
- Bad actors may gain access to sensitive data
- The program runs as expected, until it suddenly doesn’t
Memory Management in PostgreSQL
Adding to the issues faced above, the PostgreSQL API also complicates our lives by introducing custom functions that handle allocation and release of memory internally. Consider the following function, which is used for integrating SQL statements into C source code:
It basically takes a pointer stmt to an SQL statement and outputs the statement to the generated C source file. However, in line 9 we see that the pointer is always freed before the function returns. This might not be intuitive to a developer and using stmt after a call to the function would constitute a case of use-after-free. The following little program exemplifies this:
As we have seen in our first example above, memory is allocated in line 7 and the pointer stored in str. However, in line 10 output_simple_statement was called with str. When the function returns the memory has already been freed, making the access to it by the printf function in line 12 a case of use-after-free. To the developer this might not be obvious because the function is ‚hiding‘ the call to free.
In the next blog post we are going to look at tools that can be used to address the problems discussed here.
