If we must choose a particularly damaging vulnerability, it would most likely be arbitrary code execution, and even more so if it can be exploited remotely. In the first blog entry we introduced the issues that can be caused by a poorly managed memory. The second one was about double free, and the third one was focused on dangling pointers and memory leaks. Let’s close this set of blog posts with the use of uninitialized memory and the conclusions.

Use of Uninitialized Memory

For efficiency purposes, when we call ‘malloc’ or use the ‘new’ operator in C++, the memory area allocated is not initialized. What does this mean? That it doesn’t contain a default value, but data that will seem random to us and doesn’t make sense in the context of our process. Let’s see it:

We get a block of 10,000 integers, fill it with random integers and free it up. In theory, according to the standard of the C library, the memory coming from ‘malloc’ should not be initialized, but in certain systems (particularly modern ones) it is likely to be initialized to zero. That is, the whole reserved area is full of zeros.

In the program, we make use of a reserved memory area and then free it up. But when we use this type of memory again, the system returns that same block with the content it already had. This content probably does not make sense in the current execution context.

Let’s see the output:

What would happen if we used that data accidentally? Let’s see it, again, within code. We modify the program so that the second reserve is made for a structure that we have defined:

As we can see, we make use of ‘p’ by filling that area with random data. We free that block and now call one for a structure that should contain a pointer to a string and two integer values. Let’s check a series of executions:

As we see, the structure is initialized with “garbage”, and making use of this “garbage” is problematic, if not worrying, and completely unsecure. Imagine that these values are used for a critical application.

In addition to those already mentioned, the issues related to manual memory management do not end here. What we have seen is just a small sample and the list would be endless: pointer arithmetic, out-of-bounds write, and so on.

New Management Mechanisms

C++ has greatly improved manual management so that if already in the first steps of the language the need to use functions through operators (“new” and “delete”) was removed, the new standard extends and improves memory management through “smart” pointers. That is, memory containers that call their own destructor when they detect that they are no longer useful. For example, when an object goes out of a scope and is no longer referenced by any other variable or object.

Still, even with smart pointers, there is room for surprise and even for cases where we must use the traditional method, either for efficiency or for limitations in the libraries used by a given application.

Another method of memory management that does not require a collector is the system used by languages such as Swift or Rust. The first one uses an “immediate” type of memory collector that does not require pauses, ARC or Automatic Reference Counting. This is a method that relies on the compiler to insert into the code the appropriate instructions to free up memory when this one is no longer going to be used. Rust, a relatively modern language, uses a method based on the concepts of “borrowing” and “ownership” related to the objects created with dynamic memory. An intermediate commitment between not having to carry the burden of a memory collector and the inconvenience of the programmer having to worry minimally about the logic of “borrowing” an object to other methods.

Conclusions

It is clear that manual memory management causes a tremendous vortex of issues that can (and usually do) lead to serious security problems. On the other hand, it requires a good capacity, attention and experience from programmers who use languages like C or C++. This doesn’t mean that these languages should be abandoned because they are complex to use in certain aspects. As we said at the beginning, you can’t avoid using them in certain types of applications.

Don’t miss the previous entries of this post:

If we must choose a particularly damaging vulnerability, it would most likely be arbitrary code execution, and even more so if it can be exploited remotely. In the first blog entry we introduced the issues that can be caused by a poorly managed memory. The second one was on double free. Now we are going to see more examples. 

Dangling Pointers 

Manual memory management is complex so attention must be paid to the order of operations, where resources are obtained from and where we stop using them in order to free them under good conditions. 

It also requires tracking copies of pointers or references that, if freed too early, may cause pointers to become “dangling”. That is, making use of a resource that has already been freed. Let’s see an example:

Let’s run:

This leaves us with a pointer pointing to a memory area (heap) that is not valid (note that it does not print anything after “(p2) apunta a…”. Moreover, there is no way to know if a resource whose address has been copied is still valid, just as it is not possible to recover a memory leak if its reference is lost (we will see this later).

To tag that a pointer is not valid, we assign the NULL macro to that pointer (in “modern” C++ we would assign nullptr) to somehow warn that it is not pointing at anything. But if that NULL isn’t verified, this is useless. Therefore, for every pointer using a resource, its “non NULLity” must be verified. 

The good practice is, therefore: once we free up memory, we assign NULL or nullptr (in C++) to tag that the pointer is no longer pointing at anything valid. Also, before making use of it, both to copy it and to de-reference it, we must verify if it’s valid. 

Memory Leaks  

The opposite of using a memory area that is no longer valid is to have no pointer pointing at a valid memory area. Once the reference is lost, we can no longer free that reserved memory and it will occupy that space indefinitely until the program ends. This is a big issue if the program does not finish − such as a server that normally runs until the machine is shut down or some other unavoidable interruption occurs. 

An example (if you want to replicate it, do it in a virtualised system for testing):

The code on the right gets parts of memory until all the heap memory is used up. This causes the system to run out of RAM, start swapping and finally the OOM-killer will kill the process for overconsuming memory. 

What is the OOM-killer? It is a special kernel procedure (on Linux systems) to end processes in memory so that the system is not destabilised. In the screenshot we can see the output of the command ‘dmesg’, where the kill of our process is showed due to the cost of resources it represents to the system.

If we analyse the code, we see that we get into an endless loop where memory is reserved and the same pointer is reallocated to new blocks of that memory. Previous references are not freed and are lost, which triggers a relentless memory leak (exactly like a burst pipe) that ends drastically. 

This is obviously a dramatization of what would happen in a real program, but actually it occurs that way. The issue is that the reserved memory is not controlled at a point, so lost references are accumulated, and it ends up becoming a problem. It is possible that in applications with memory leaks that we only use for a few hours, we only notice a slowdown (this was more evident in times when the RAM was more limited) or a memory buildup. However, regarding servers the issue commonly leads to service drop. 

In the next post we will see the use of uninitialized memory.

Don’t forget to read the previous entries of this post: