How safe is it to compile a piece of source code from a random stranger? [closed]

Question

Suppose I'm reviewing code that job applicants send to prove their skills. Clearly I don't want to run executables they send. Not so clearly I'd rather not run the result of compilation of their code (just for example, Java allows to hide runnable code in comments).

What about compiling their code? I want compiler warnings if any but what if their code contains some clever character sequences which exploit my compiler and my compiler compromises my machine?

When I Google for "compiler vulnerabilities" the hits I get are all about compiler optimizations and code emission and whether emitted code is as secure as original source code was intended to be.

Are compilers typically validated to ensure they won't compromise the user machine when compiling some clever piece of code? How safe is it to compile a piece of code from a stranger?

Answer 1

It depends.

This piece of makefile could delete your home directory :

all:
    rm -rf ~

So, if you need to use a tool (like cmake or makefile system), then it is not safe. It just depends how malicious the coder is.

On the other side, compilers are programmed by people, therefore they got bugs. So, maybe it could be possible that someone found a way to execute malicious code during the compilation.

As suggested in the comments, if you want to be sure that no funny things is being done to your machine, use a virtual machine.

Answer 2

I am pretty sure somewhere in the business there are some clever guys who have already created such a hack for a specific language and compiler version. My favorite place to look for something like this would probably be the International Obfuscated C contest - (do not know if there is something comparable for Java). However, in reality, how high do you consider the risk, assumed that

• the applicant makes a plausible impression on you he really wants the job at your company (and not a lawsuit)

• the guy does not know how much reviewing is done at yours

• he / she does not know which exact compiler version you are using

• he / she does not know if you use a virtual environment or an online compiler, just to be safe

• you do not accept programs which are too large to be effectively reviewed

• you do not compile anything which looks suspicious to you

• there are not many people in the world who actually know how to technically accomplish such a task (and googling alone won't give you a "quick ref" or tutorial on this, as you have already found out by yourself).

So though compiling is not "totally safe" in theory, IMHO in reality the risk is extremely low that your "compiler gets pwned".

Answer 3

We have to distinguish several cases:

1. A bug in the compiler. Like every complex program, a compiler might have bugs, and one of those bugs might be exploitable.
2. A Trojan Horse. The attacker may get you to execute some arbitrary code as part of the compilation process. A Makefile, a build.xml, a configure shell script etc. Technically, this is not due to compiling the attacker's code but rather setting up the compile environment.
3. Languages allowing arbitrary code to run at compile time. Scala's macro language is Scala, Common Lisp's macro language is Common Lisp, Template Haskell's macro language is Haskell. Scala also has compiler plugins, which are again arbitrary Scala code that runs at compile time. F# has type providers.
4. Languages which allow Turing-computation at compile time. Scala's and Haskell's type systems are Turing-complete, as are C++'s Templates. You can get the compiler to perform arbitrary Turing-computation at compile time, including but not limited to infinite loops. Note that Turing-complete only means that you can compute every Turing-computable function, it does not mean that you can access the filesystem or something like that. But, you can make a program that will take infinitely long to compile.
5. Very long compile times. For example, C#'s rules for overload resolution are so complex that you can encode any 3-SAT problem as C# overload resolution. 3-SAT is, of course, famously NP-complete. In other words, according to our current knowledge, it is impossible to find an efficient algorithm for overload resolution in C#. You can't make compilation take infinitely long, but it doesn't take a big program to make compilation take longer than the lifetime of the universe, which is practically the same thing.

#4. and #5. will at the most result in a denial of service. Practically, C++ and Scala compilers limit the amount of recursion you can do, so that it is not actually possible to write an infinite loop. In Scala, that's just an implementation constraint, but in C++, it's explicitly allowed by the spec, I believe.

#2. is technically out of scope of the question because the question was about compiling code not running it (OTOH, there's the deep philosophical question: if type-checking a Haskell program can perform arbitrary Turing-computation, is that compilation or running a program?)

#1. is unlikely. On the one hand, production compilers are very complex, so the likelihood of bugs is high. On the other hand, they are rigorously tested, after all, handling ill-formed input gracefully is part of the job description of a compiler. Even if they are not tested, they will be bombarded with ill-formed code anyway … just look at some StackOverflow questions for examples of what junk people throw at their compilers!

This leaves us with 3. Some compilers may limit the kind of access the compile time code has to the system, but for some of the use cases, having full access is unavoidable. The purpose of F#'s type providers, for example, is to "fake" synthetic types for data whose type system doesn't match F#'s, so that you can interact with, say, a web service that has a WSDL schema in a strongly-typed fashion. However, in order to do this, the type provider needs to have access to the WSDL schema resource either on the filesystem or on the web, so it needs to have filesystem and network access.

So, is it safe? Technically, no. Is it risky? Not really.

Answer 4

There shouldn't be any risk just compiling the code. In theory there could be a bug in the compiler that a clever hacker could take advantage of but is sounds extremely unlikely.

Be aware that building may be unsafe. For example in C# 'build event' allows you to specify arbitrary command lines to execute before and after building, which is obviously dangerous, and a lot easier to exploit than say buffer overflows in the compiler code.

Answer 5

Instead of speculating, I actually bothered to do some research on this topic before answering, going to the most authoritative resource I could think of (CVE Details). This comprehensive list of publicly disclosed security exploits is probably the best that one could do to assess the threat levels of various types of software.

I didn't take time to read all of the available material, of course, but I selected a few "primary" compilers, IDEs, and text editors to come up with a sample threat assessment. If you're serious about running any software at all, you should at least see what threats are out there. Also note that older software is generally buggier than newer software, so running the latest of whatever you're running is ideal.

First, we can take a look at various text editors. It seems the best editors are the most simple. Vi if you're using a Linux shell, or Notepad if you're in Windows. Something with no formatting capabilities, no parsing, just straight-forward viewing of data and automatic termination of parsing if a single character is outside of the current encoding scheme. Even Notepad++ has had a handful of vulnerabilities. Avoid anything complex when viewing untrusted files.

Second, we can look at IDEs. If you choose to open the file in an IDE, you should be aware that some IDEs have had reported bugs. Apparently Visual Studio has had exploits available through the extensions mechanism, so opening a solution might be problematic. Avoiding IDEs avoids an entire class of problems between you and the untrusted code. Sticking with VI seems a lot safer.

Third, we can look at actual compilers. I browsed a few, including Adobe, Microsoft, Java, and GNU's C/C++, and found that generally speaking, compiling code (and even building, assuming no custom make-file) is relatively safe, but each of those compilers do or did have security exploits that could arise from actually running the compiled binaries. In other words, they couldn't take your system over simply by compiling, but they could by running code.

So, in conclusion, assuming the delivery method didn't already hijack your system (e.g. your email client got hacked, or the USB drive it came on was infected...), reading the source code and compiling the source code is probably safe. By researching your specific software, you could make it even safer by, say, validating the file is in the correct code page, etc. Running the code should only be done on hardware you simply don't care about. Not a VM, but an entire physically different computer with no network access and no sensitive files or external devices. Even if you think you understand the code, simple research shows that even compilers have bugs which might allow a hidden buffer overflow exploit to sneak up from behind and execute arbitrary code, but only if you choose to run or debug the program. Actual compilation should be safe.

Answer 6

Well, I would start with "reviewing their code". Why is there a need to actually run the code?

Apart from that, there are a lot of online compilers where you can just put in the code and compile and/or run it. You can make that a requirement: it compiles in this and that online compiler.

Here's an example of a page with online compilers: Online compilers

Code for review for a job interview shouldn't be so large anyhow as for you not to understand what's going on.

Answer 7

Are compilers typically validated to ensure they won't pwn the user machine when compiling some clever piece of code?

In general they're too complex and often written using languages in which it's not practical to prove this property.

Possibly not with this specific intent, but the notion of fuzz testing compilers is at least known (LLVM can now fuzz-test itself). Tests intended to catch input that crashes the compiler due to compiler bugs will tend to also turn up exploitable flaws.

Naturally you'd have to look into whether the specific compiler you're interested in is tested or fuzz-tested to find potential crashes, and whether the bugs so found are actually fixed. Rule of thumb is that if there are crashes any worse than uncaught out of memory exceptions, then without investigating the details further you have to consider a serious possibility they could be leveraged into exploits.

How safe is it to compile a piece of code from a stranger?

Unfortunately, how long is a piece of string. In principle the email might exploit your mail client, or the source code might exploit your text editor or cppcheck, before it even reaches your compiler. Sebastian's suggestion in comments to use an online compiler is a pretty good one, but of course the code has to be in a form the compiler will accept.

Any language or compiler with facilities for compile-time execution of general code is of course highly suspect. C++ templates are functionally complete but don't have (intended) access to the system, so they're relatively low-risk. BЈовић mentions make as extremely high-risk (since it's executing the stranger's code, it's just that the code happens to be written in the make language, not in C++). If the compiler will run system then you're in the same boat. I used to work with an assembler that, if I remember rightly, could do arbitrary compile-time code execution. It was intended for computing look-up tables, but I don't think anything prevented you making system calls.

In practice, if the code looks OK to me and I think I understand it, then I'd consider it extremely low risk to compile it, far lower risk than say "browsing the internet with a locked-down browser". I do riskier things routinely on my general-purpose machine, but many of them I wouldn't do e.g. inside a virus lab or on a critical server. If the code is funny-looking or evidently obfuscated then I might not risk compiling it because, aside from the risk it could contain an exploit hidden in the unreadable garbage, it's rubbish code. Underhanded code is difficult but possible. Underhanded code that pwns the machine via a compiler exploit needs to contain a non-trivial executable payload, so is extremely difficult.

If you want to look into this further, try asking the folks who host online compilers. If it hasn't been done to them then (barring you coming to the attention of the NSA or equivalent) you can reasonably assume it won't be done to you. They put some effort into running their compiler in a proper sandbox, which might be more effort than you're willing to go to, but they might at least be able to tell you how often that sandbox saves them trouble.

Answer 8

Although this is generally a concern, I think the issue is non-existent due to the setup.

The applicant sent you some source code. How or why did that happen?

Well obviously there are only three possibilities:

1. You gave the applicant an assignment to solve a particular (well-defined) problem to assess his skills.
2. The applicant wants to show off something cool he wrote.
3. The applicant is a jerk or a spy or an otherwise malicious person and not actually interested in being hired. All he hopes for is you being stupid enough to run his code.

About 2) and 3)

The main risk is distinguishing between 2) and 3). Chances are high that if whatever he wrote is worth looking at, it's something that you can either get the source code for online (from a "neutral" source) and that you may even be familiar with already, or it's something that you actually don't want to look at because you would infringe a competitor's (former employer's) intellectual property. The latter would mean that you wouldn't want to hire that person anyway.
If you can get the source online, do so. If you can verify the applicant's contribution to a well-known software (including proprietary software) by his name somewhere in the credits, do so.
In every other case, simply ignore whatever he sent you. It's either not worth looking at, or illegal, or high risk.

About 1)

The applicant sent you something because you gave him an assignment. If you have any competence (which I assume you do!), then for a typical programming assignment (...that you even chose yourself!), you will be able to tell whether it's a plausible solution that looks as if it might work by looking at the source code for less than 30 seconds (more likely 10 seconds).

If you cannot tell that the program will probably work (or what it's doing at all) within 30 seconds, the one who wrote it not the kind of person you want to hire, fullstop. You want people who write code that other humans can understand and maintain. You do not want someone who is trying to get smart at you, nor someone who regularly wins the obfuscated C contest. It doesn't even matter whether the program works. As soon as another person cannot understand the code, it never "works".
If the program looks like it will probably work, but you find anything that looks "weird" (say, Java unicode escape sequences, C++ raw string literals, stuff that looks like trigraphs, whatever), treat the assignment as "fail", move on to the next applicant. It's not necessary to include anything the like in 99% of all programs (and, sure enough, not in your assignment -- I should hope). So if you find anything "weird" like that, the applicant is not someone you will want to hire.

If the code passes that first triage, you may want to spend another 2-3 minutes looking at it more thoroughly. If you are still pleased with what you see after that, you may run it through a static analyzer and compile it in a virtual machine at a high warning level.

That should bring up issues that you may have missed while reading the source (such as invoking undefined behavior or narrowing conversion).
Compiling will first and foremost tell you whether the applicant has the necessary diligence and attention to detail, not so much whether he has programming skill. Much like writing the employer's name correctly on your application and spellchecking your CV before handing it in, it is best practice that you make sure whatever source code you hand in compiles without errors (and preferrably without warnings). If someone fails to do that, you do not want to hire him.

The risk of evil things happening at this point (exploiting the compiler and breaking out of the VM) is neglegible, seeing how you have already run a plausibility check over the code. Not going to happen.

Answer 9

If the possibility worries you, take an older machine (don't most of us have a few sitting around?), install current version of Linux and compiler &c, copy the source code to it, unplug the network cable (or turn off WiFi), and do the compiles. If anything nasty does happen, it won't* affect anything else.

And for malware in the Makefile, run it with the -n flag (IIRC, RTMF) to see what it will do without actually doing it.

*Unless of course your programmer coded the malware so that it waits for a reconnection, but in that case you a) wipe the machine; and b) forward the guy's resume to the NSA, 'cause he's wasted in the commercial world :-)

Answer 10

The bottom line is that there is risk. The risk is fairly small as other answers note, but there is a risk. That means you need to ask two questions:

1. What can I do to mitigate the risk?
2. Is the risk high enough that I should care?

The second is what you've posited here in this question, but it's the wrong focus for this particular case. The answer to mitigating the risk is clear and readily available: don't compile the code on your machine. You have two obvious ways of compiling it without using your machine:

1. Use a virtual machine (as @FlorianMargaine pointed out immediately in the comments). You simply snapshot it before compiling and then restore the snapshot when you're done.
2. Use a hosted service (such as an online compiler).

These ways of mitigating your risk are so obvious, cheap, and easily accessible that it's not worth spending a lot of time trying to analyze how big the risk is. Just do one of them and be done with it.

Answer 11

Visual Studio actually warns you if you open a project from an untrusted location (e,g, downloaded or network share).

One example how this could be exploited would be with a WPF project: You can reference .NET classes from XAML, and to provide IntelliSense, VS loads and executes the referenced classes at design time.

That means an attacker can drop a malicious .dll into the bin directory, replace the source code with non-malicious one, and at design time, the DLL is executed. After your first build, every trace of the malicious binary is gone.

So even though all provided code is "clean", the compiler is bug-free and you, of course, never manually execute any provided .EXE, malicious code could still be executed in the background. (To be safe from that specific attack, you can just make sure that there are NO binaries in the directory tree before opening the solution. VS will then prompt you to build the solution before providing IntelliSense at design-time.)

Similar vectors probably exist with other languages / OSes.

Answer 12

Reading source code: totally safe. Compiling source code: totally safe. Executing compiled binaries: well... that depends.

Compiling is just the computer reading the source code and writing its equivalent in binary form. After compilation, you just have 2 documents: one human-readable, and another computer-readable. Unless you get the computer to read (ie run) the 2nd document, nothing is going to happen.

Answer 13

I think you're worried about one of two flavors:

• sophisticated, exploit-driven malware: unlikely, especially because these are targeted at very specific hardware and/or software and [based on your question] your attacker probably doesn't have that level of system knowledge.
• things that screw with your environment: malicious prank directives (e.g. deleting your home directory) or inconsiderate/incompetent directives which change your system behavior (e.g. rewriting PATH or LIBRARY environment variables)

Some people have suggested virtual machines or old systems, but I offer a much easier solution: Compile as a different user with reduced/different permissions. Much easier than setting up a virtual machine or a dedicated computer.

If in the unlikely even that your system gets pwned by compile-time exploits, restore from backups (you have those, right?).