Despite the general public’s hijacking of the word “hacker,” we don’t advocate doing disruptive things. However, studying code exploits can often be useful both as an academic exercise and to understand what kind of things your systems might experience in the wild. [Code Explainer] takes apart a compiler bomb in a recent blog post.
If you haven’t heard of a compiler bomb, perhaps you’ve heard of a zip bomb. This is a small zip file that “explodes” into a very large file. A compiler bomb is a small piece of C code that will blow up a compiler — in this case, specifically, gcc. [Code Explainer] didn’t create the bomb though, that credit goes to [Digital Trauma].
We aren’t sure what practical use this would have, but it did illustrate a few interesting points. First, the code itself is simple and probably surprises you that it would even work:
main[-1u]={1};
The linker apparently doesn’t care that main is actually a function. You could argue that it doesn’t work because it blows up the compiler, but if you restrict the size to fit in your available memory, it will create an executable. Of course, that executable won’t actually run, but still.
To us, this seems less of an exploit as a strange bug in the linker. The reason it works is that the compiler runs out of memory during the link phase. We didn’t try it, but we wondered if –no-keep-memory or some other option could help. After all, you could imagine the linker being smart enough to initialize the static array in a “streaming” way and not trying to build it all in memory. It just doesn’t.
If you are more interested in making gcc produce smaller executables, we don’t blame you.
Source:: Hackaday