https://img.rasset.ie/001babea-1600.jpg
Introduction
Linux users often take pride in their ability to compile their own code. In spite of this, a subtle yet critical attack vector has existed for over 20 years with high potential impact when exploited. Cleverly disguised within the configure.ac file, this attack vector allows malicious actors to execute code on your system before the compilation process even begins.
While the absence of known exploits may lull users into a false sense of security, it is precisely this lack of awareness that makes this attack vector dangerous, increasing the chances of successful and large-scale exploitation.
The security concern that I am referring to is the ability to execute arbitrary code through autoconf.
What is Autoconf?
Traditionally, developers have used a build system in order to distribute software packages that are easy for clients to compile. These build steps are specified in a Makefile.
Different systems have different requirements. Sometimes, they require different flags to be set during compilation and sometimes the compiler is referred to by a different name. With such a diverse array of systems and configurations to cater to, Autoconf was offered as a solution.
Autoconf is a crucial part of the GNU Autotools project and it ensures that packages are portable across different systems. It accomplishes this through macros from the M4 programming language to create a shell script that configures software source code packages for the respective system (see the README for more information).
How Does Autoconf Work?
Autoconf is one of the first commands executed when building a package that follows GNU Coding Standards (which is a lot of packages). If not called directly, it is often included in an autogen.sh script. The program uses instructions from a configure.ac file to generate a dynamic configurebash script that is responsible for matching the libraries on the system to those required in the program.
The Security Concern
Because Autoconf interprets user-controlled input through the configure.ac file, it is possible to insert malicious code that gets executed upon the running the generated configure file.
Furthermore, and increasingly concerning, is the possibility of obtaining code execution upon execution of the autoconf command- before the generated configure file is even ran. This means one less step in order to pwn a computer.
For example, hackers can embed a malicious payload within the configure.ac file and when an unsuspecting Linux user begins building the package, the attacker-controlled code would be executed on the system.
This can be abused to perform targeted cyberattacks on developers, general Linux users, security researchers, and more if the supply chain is compromised. Additionally, because this is not well-known, modern code-scanning and SAST solutions often fail to include checks for malicious code within configure.ac, decreasing the chance of detection.
I discuss exactly how to exploit this in my Proof-of-Concept on GitHub, which was published after receiving permission from the Autoconf maintainers to publicly disclose my concerns.
How Hard Was This To Find?
I want to briefly explain the ease with which I was able to uncover this potentially dangerous functionality. First, I identified the programming language being used was M4, so I read core notes for approximately 30 minutes to get a high-level overview of the language.
After experimenting with the functionality and realizing that it was possible to embed bash code in the created configure script, I wondered if I could take it a step further and get code execution from running autoconf alone.
Within 2 hours of combing through the source code to learn how the application works, I identified 3 potential locations for code to be executed. I then created a PoC to submit in a bug report to the Autoconf maintainers.
My findings were low-hanging fruits and I suspect they have only gone this long without being abused because of the learning curve to understand M4. As you will see in the next segment, I am far from the first to know of this functionality.
Autoconf’s Response
Since 2/3 of my concerns came from a segment of legacy code that has been unused since the year 2000, one of the maintainers removed the macro in this commit and thanked me for bringing the unused code snippets to their attention.
They explained to me that there were plenty of opportunities to execute code when using Autoconf and that the ability to invoke macros such as m4_syscmd, allowing for code execution, was a conscious design decision as many of their users rely on that functionality. In fact, it is common for m4_syscmd to be used to run commands such as git describe.
Another of the points in my PoC was that they included a macro that executed the cat command without an absolute path. This made the program vulnerable to the modification of a $PATH environmental variable which could lead to execute arbitrary code execution and privilege escalation under the correct circumstances.
The maintainers explained that adding an absolute path to the binary would break Nix, Guix, and more. They made the assumption that Autoconf is being run in an environment with a secure $PATH within a sandbox, which is consistent with best practices. However, I have strong doubts that the majority of users actually follow these precautions.
Implications
I want to be clear that I respect the maintainers and the effort and time they have put into creating a tool that we have all benefited from. The ability to execute OS commands is not inherently dangerous, but when abused it can certainly have security implications.
Given the reliance on m4_syscmd by Autoconf’s clientele, it is clear to me that the maintainers have no plans of removing the functionality. The ability to execute arbitrary code upon running autoconf will remain in the foreseeable future, making it an even more attractive attack vector for adversaries.
In fact, the manner in which this functionality is built-in is reminiscent of attack techniques displayed in GTFObins, which are often used for privilege escalation.
Conclusion
The ability to run commands from Autoconf is a feature, not a bug. However, it is a feature that can be abused in a way that very few people are aware of. And when exploited strategically, this can lead to the infection or damage of thousands of devices.
I hope that in writing this, I was able to bring awareness to open-source users on the potential dangers of configuring untrusted applications. If you have any questions, concerns, or criticisms on this article, feel free to message me on LinkedIn and I will be happy to discuss them with you.
Thanks for reading!