Online compilers are a handy tool to save time and resources for coders, and are freely available for a variety of programming languages. They are useful for learning a new language and developing simple programs, such as the ubiquitous “Hello World” exercise. I often use online compilers when I am out, so that I don’t have to worry about locating and downloading all of the resources myself.
Since these online tools are essentially remote compilers with a web interface, I realized that I might be able to take remote control of the machines through command injection. My research identified a common weakness in many compilers: inadequate sanitization of user-submitted code prior to execution. My analysis revealed that this lack of input filtration enables exploits that an hacker can use to take control of the machine or deliberately cause it to crash.
A clever attacker can exploit built-in C functions and POSIX libraries to gain control over the computer hosting the online compiler. Commands like execl(), system(), and GetEnv() can be used to probe the target machine operating system and run any command on its built-in shell.
I wanted to write this article to remind how sandboxed environment are important when shipping an application such as this!
Vulnerability description
In this section, I will introduce the reader to the vulnerability explaining both theory and practice processes.
Gaining access
In several of the C/C++ compilers that I analyzed, the GetEnv(), system(), functions allow an attacker to study and execute any command on the remote machine. The GetEnv() function allows a hacker to learn information about the machine that is otherwise concealed from the web interface, such as the username and OS version.
Once this information is revealed, the attacker can begin testing various exploits to achieve privilege escalation and gain access to a root shell. For example, the system() command can be used to execute malicious code and access sensitive data such as logs, website files, etc.
Since the exploit I discovered involves inserting hostile commands to gain control of an unwitting machine, this attack vector is classified as a code injection vulnerability.
Maintaining control
If hacker tries to run the online compiler every time they want to
send a new command, the attack would leave an obvious trace, and the
resource use might draw attention to the suspicious activity. These
obstacles can be conveniently sidestepped by using the execl() function,
which allows the user to specify any arbitrary program to replace the
current process. An attacker can gain access to the machine’s built-in
shell by invoking the execl() function to replace the current process
with /bin/sh, with catastrophic implications.
Many compilers allow input from the browser, in which case the hacker
can craft a program to relay input commands to the shell of the
compromised machine. Once the hacker uses execl() to open a shell via browser, they can simply operate the remote machine using system()
to inject various instructions. This avoids the need to run the
compiler each time the attacker wishes to explore or exploit the
compromised machine.
Implications
A hacker that obtains shell access in this way gains access to files and services typically protected from outside users. The attacker now has many options at their disposal for exploiting the machine and/or wreaking havoc; how they proceed will depend on their tools and motives.
If the attacker wishes to crash the target machine, they can achieve this by (mis)using the fork() function, which creates a new cryptocurrency
clone of the current process. A fork() function placed within a while
(true) loop will execute indefinitely, repeatedly cloning the process to
greedily consumed precious RAM memory. This rapid uncontrolled use of
resources will overwhelm the machine, causing a self-DOS (denial of
service attack).
Instead of maliciously crashing a machine, an attacker may wish to monetize their illicit access. This can be accomplished by injecting a cryptocurrency miner, which will generate funds for the attacker at the expense of the victim’s computational resources and electric bill. My analysis showed that this maneuver allows useful exploitation of online compilers that successfully stymied other attacks by sandboxing the environment or adopting more advanced techniques to limit file access.
Theory
This section documents the commands used to gain and maintain access to the online compiler. These functions require the unistd.h and stdlib.h libraries.
execl()
Declaration
int execl(const char *pathname, const char *arg, ...);Parameters:
-
pathname - char*, the name of the program
-
arg - char*, arguments passed to the program, specified by pathname
Description
The execl() function replaces the current process with a new process. This is the command exploited to maintain control over the remote machine without having to repeatedly use the online compiler. Reference the underlying execve() function for more details.
system()
Declaration
int system(const char* command);Parameters:
- command - char* command name
Description
The C system function passes the command name, specified by command, to the host’s built-in shell (/bin/sh for UNIX-based systems) which executes it. This function is based on execl(), so system() will be called by executing:
execl(, "sh", "-c", command, (char *)0);This function returns the output of the command after it has been executed. If the shell encounters an error while executing the command, it will return the numeric value -1.
GetEnv()
Declaration
char *getenv(const char *name)Parameters:
- name - const char* variable name.
Description
Retrieves a string containing the value of the environment variable whose name is specified as an argument ( name ). The function returns the contents of the requested environment variable as a string. If the requested variable is not part of the list of environments, the function returns a null pointer.
Proof of Concepts
#include "stdio.h"
#include "unistd.h"
int main(){
execl("/bin/sh",NULL,NULL); // Open the shell
return 0;
}#include "stdio.h"
#include "stdlib.h"
int main(){
system("whoami"); // Find username
system("cd / && ls"); // Lists all files and directories on /
return 0;
}Solutions: sandboxed environment
Thankfully, most of the risks highlighted above can be mitigated relatively easily. Access to protected files and services can be prevented by creating a secure sandbox for the application. This minimizes the potential for collateral damage and inappropriate data access, but will not prevent some attacks such as cryptocurrency miner injection. In order to avoid these “mining” attacks, the sandbox should have limited resources and it should be able to reboot itself every 10 minutes.
To eliminate the underlying weakness, the libraries could be recompiled without the particular exploitable functions. An attacker cannot gain a foothold if the execl() and system() are removed or disabled by recompiling libraries.
In addition to this, tools such as Docker might be used to create a sandboxed environment. A sandbox is a mechanism to run applications in a limited space. It usually provides a restricted and controlled set of resources to the program that needs to be tested, such as a restricted area of memory or a set of limited system calls; normally, network access, the ability to inspect the host system or read from input devices, are disabled or highly restricted.
At the time of my search, I found at least two compilers with a non-sandboxed environment. I contacted the managers and they resolved in less than a week. For others I verified that they were actually under a sandboxed environment. Injected scripts were immediately identified and the “malicious” user was banned.
Comments
Post a Comment