Why are eval-like features considered evil, in contrast to other possibly harmful features?

Question

Most modern languages (which are somehow interpreted) have some kind of eval function. Such a function executes arbitrary language code, most of the time passed as the main argument as a string (different languages may add more features to the eval function).

I understand users should not be allowed to execute this function (edit i.e. take directly or indirectly arbitrary input from an arbitrary user to be passed to eval), especially with server-side software, since they could force the process to execute malicious code. In that way, tutorials and communities tell us to not use eval. However, there are many times where eval is useful and used:

• Custom access rules to software elements (IIRC OpenERP has an object ir.rule which can use dynamic python code).
• Custom calculations and/or criteria (OpenERP has fields like that to allow custom code calculations).
• OpenERP report parsers (yes I know I'm freaking you out with OpenERP stuff... but it is the main example I have).
• Coding spell effects in some RPG games.

So they have a good use, as long as they are used properly. The main advantage is that the feature allows admins to write custom code without having to create more files and include them (although most frameworks using eval features have also a way to specify a file, module, package, ... to read from).

However, eval is evil in the popular culture. Stuff like breaking into your system comes to mind.

However, there are other functions which could be harmful if somehow accessed by users: unlink, read, write (file semantics), memory allocation and pointer arithmetic, database model access (even if not considering SQL-injectable cases).

So, basically, most of the time when any code is not written properly or not watched properly (resources, users, environments, ...), the code is evil and can lead even to economic impact.

But there's something special with eval functions (regardless of the language).

Question: Is there any historical fact for this fear becoming part of the popular culture, instead of giving the same attention to the other possibly dangerous features?

Answer 1

An eval function by itself is not evil, and there is a subtle point that I do not believe you are making:

Allowing a program to execute arbitrary user input is bad

I have written code that used an eval type of function and it was secure: the program and parameters were hard-coded. Sometimes, there is no language or library feature to do what the program needs and running a shell command is the short path. "I have to finish coding this in a few hours, but writing Java/.NET/PHP/whatever code will take two days. Or I can eval it in five minutes."

Once you allow users to execute anything they want, even if locked down by user privilege or behind a "secure" screen, you create attack vectors. Every week, some random CMS, blogging software, etc. has a security hole patched where an attacker can exploit a hole like this. You are relying on the entire software stack to protect access to a function that can be used to rm -rf / or something else catastrophic (note: that command is unlikely to succeed, but will fail after causing a bit of damage).

Is there any historical fact for this fear becoming part of the popular culture, instead of putting the same attention to the other possibly dangerous features?

Yes, there is a historical precedent. Due to the numerous bugs that have been fixed over the years in various software that allow remote attackers to execute arbitrary code, the idea of eval has mostly fallen out of favor. Modern languages and libraries have rich sets of functionality that make eval less important, and this is no accident. It both makes functions easier to use and reduces the risk of an exploit.

There has been much attention paid to many potentially insecure features in popular languages. Whether one receives more attention is primarily a matter of opinion, but the eval features certainly have a provable security problem that is easy to understand. For one, they allow executing operating system commands including shell built-ins and external programs that are standard (e.g. rm or del). Two, combined with other exploits, an attacker may be able to upload their own executable or shell script then execute it via your software, opening the door for almost anything to happen (none of it good).

This is a difficult problem. Software is complex, and a software stack (e.g. LAMP) is multiple pieces of software that interact with each other in complex ways. Be careful how you use language features such as this, and never allow users to execute arbitrary commands.

Answer 2

Part of it is simply that nuance is hard. It easy to say thing like never use goto, public fields, string interpolation for sql queries, or eval. These statements shouldn't really be understood as saying there is never, under any circumstances, a reason to use them. But avoiding them as a general rule of thumb is good idea.

Eval is heavily discouraged because it combines several common issues.

Firstly, it is susceptible to injection attacks. Here it is like SQL injection in that when user controlled data is inserted into the code, its easily to accidentally allow arbitrary code to be inserted.

Secondly, beginners tend to use eval to get around badly structured code. A beginner coder might write code that looks like:

x0 = "hello"
x1 = "world"
x2 = "how"
x3 = "are"
x4 = "you?"
for index in range(5):
   print eval("x" + index)

This works, but is really the wrong way to solve this problem. Obviously, using a list would way better.

Thirdly, eval is typically inefficient. A lot of effort is spent speeding up our programming language implementations. But eval is difficult to speed up and using it will typically have detrimental effects on your performance.

So, eval is not evil. We might say that eval is evil, because well, its a catchy way to put it. Any beginner coder should strictly stay away from eval because whatever they are wanting to do, eval is almost certainly the wrong solution. For certain advanced use cases, eval makes sense, and you should use it, but obviously be careful of the pitfalls.

Answer 3

What it boils down to is that "arbitrary code execution" is tech-talk for "able to do anything." If someone is able to exploit arbitrary code execution in your code, this is literally the worst security vulnerability possible, because it means they are able to do anything that is possible for your system to do.

"Other possibly harmful bugs" may well have limits, which means that they are, by definition, capable of less harm than an arbitrary code execution being exploited.

Answer 4

There's a practical and a theoretical reason.

The practical reason is that we observe it frequently causes problems. It's rare that eval results in a good solution, and it often results in bad solution where you'd have got a better one in the end if you'd pretended eval didn't exist and approached the problem differently. So the simplified advice is to ignore it, and if you come up with a case where you want to ignore the simplified advice, well, let's hope you've thought it through sufficiently to understand why the simplified advice isn't applicable and the common pitfalls won't affect you.

The more theoretical reason is that if it's hard to write good code, it's even harder to write code that writes good code. Whether you're using eval, or generating SQL statements by sticking together strings, or writing a JIT compiler, what you're attempting is often harder than you expect. The potential for malicious code injection is one big part of the problem, but aside from that it is in general harder to know your code's correct if your code doesn't even exist until runtime. So the simplified advice is to keep things easier for yourself: "use parameterized SQL queries", "don't use eval".

Taking your spell effects example: it's one thing to build a Lua (or whatever) compiler or interpreter into your game in order to allow game designers an easier language than C++ (or whatever) to describe spell effects. Most of the "problems of eval" don't apply if all you're doing is evaluating code that has been written and tested and included in the game or in DLC or what-have-you. That's just mixing languages. The big problems hit you when you try to generate Lua (or C++, or SQL, or shell commands, or whatever) on the fly, and mess it up.

Answer 5

No, there is no obvious historical fact.

The evils of eval are plain to see from the beginning. Other features are mildly dangerous. People can delete data. People can see data they shouldn't. People can write data they shouldn't. And they can only do most of those things if you somehow screw up and not validate user input.

With eval, they can hack the pentagon and make it look like you did it. They can inspect your keystrokes to get your passwords. Assuming a Turing complete language, they can literally do anything your computer is capable of doing.

And you can't validate the input. It's an arbitrary free form string. The only way to validate it would be to build a parser and code analysis engine for the language in question. Best of luck with that.

Answer 6

I think it boils down to the following aspects:

• Necessity
• (Guarded) Usage
• Access
• Verifiability
• Multi-stage attacks

Necessity

Hi there, I've written this extremely cool image editing tool (available for $ 0.02). After you have opened the image, you can pass a multitude of filters over your image. You can even script some yourself using Python (the program I've written the application in). I'll just use eval on your input, trusting you to be a respectable user.

(later)

Thanks for buying it. As you can see it functions exactly as I promised. Oh, You want to open an image? No, you can't. I won't use the read method as it is somewhat insecure. Saving? No, I won't use write.

What I'm trying to say is: You need read/write for almost the basic tools. Same for storing the high scores of your oh-so-awesome game.

Without read/write, your image editor is useless. Without eval? I'll write you a custom plugin for that!

(Guarded) Usage

A lot of methods can potentially be dangerous. Like, for instance the read and write. A common example is a web service allowing you to read images from a specific directory by specifying the name. However, the 'name' can in fact be any valid (relative) path on the system, allowing you to read all the files that the web service has access to, not just the images. Abusing this simple example is called 'path traversal'. If your app allows path traversal, it's bad. A read without defending against for path traversal can wel be called evil.

However, in other cases, the string for read is fully under the programmers control (maybe hardcoded?). In that case, it is hardly evil to use read.

Access

Now, another simple example, using eval.

Somewhere in your web-app, you want some dynamic content. You're going to allow the administrators to enter some code which is executable. Seeing as the admins are trusted users, this can theoretically be ok. Just make sure to not execute code submitted by non-admins, and you're fine.

(That is, until you fired that nice admin but forgot to revoke his access. Now your web-app is trashed).

Verifiability.

Another aspect that's important, I think, is how easy it is to verify user input.

Using user input in a read call? Just make (very) sure that the input for the read call does not contain anything malicious. Normalise the path, and verify the file that is opened is in your media directory. Now that's safe.

User input on a write call? Same!

SQL injection? Just escape it, or use parametrised queries and you're safe.

Eval? How are you going to verify the input that's used for the eval call? You can work very hard, but it's really really hard (if not impossible) to make it work securely.

Multi-stage attacks

Now, every time you use user input, you need to weigh the benefits of using it, against the dangers. Protect its usage as much as you can.

Consider again the evalable stuff in admin example. I told you that was sort-of ok.

Now, consider that there's actually a place in your web-app where you forgot to escape user-content (HTML, XSS). That's a lesser offence than user-accessible eval. But, using the unescaped user-content, a user can take over the web-browser of an admin, and add an evalable blob through the admins session, allowing again full system access.

(Same multi-stage attack can be done with SQL injection instead of XSS, or some arbitrary file writes replacing executable code instead of using eval)

Answer 7

In order for this feature to work at all, it means I need to keep a reflection layer around that enables full access to the entire program's internal state.

For interpreted languages, I can simply use the interpreter state, which is easy, but in combination with JIT compilers it still significantly increases complexity.

Without eval, the JIT compiler can often prove that a thread's local data is not accessed from any other code, so it is perfectly acceptable to reorder accesses, omit locks and cache often-used data for longer times. When another thread executes an eval statement, it may be necessary to synchronize the running JIT compiled code against that, so suddenly the JIT generated code needs a fallback mechanism that returns to unoptimized execution within a sensible timeframe.

This kind of code tends to have lots of subtle, hard to reproduce bugs, and at the same time it also places a limit on optimization in the JIT compiler.

For compiled languages, the tradeoff is even worse: Most optimizations are forbidden, and I need to keep extensive symbol information and an interpreter around, so the additional flexibility is generally not worth it -- it is often easier to define an interface to some internal structures, e.g. by giving a scripting view and controller concurrent access to the program's model.

Answer 8

I reject the premise that eval is considered more evil than pointer arithmetic or more dangerous than direct memory and file system access. I don't know of any sensible developer who would believe that. Furthermore, languages supporting pointer arithmetic/direct memory access typically does not support eval and vice-versa, so I'm note sure how often such a comparison would even be relevant.

But eval might be a more well known vulnerability, for the simple reason that it is supported by JavaScript. JavaScript is a sandboxed language without direct memory or file system access, so it simply does not have these vulnerabilities barring weaknesses in the language implementation itself. Eval is therefore one of the most dangerous features of the language, since it open the possibility of arbitrary code execution. I believe many more developers develop in JavaScript than in C/C++, so eval is simply more important to be aware of than buffer overflows for the majority of developers.

Answer 9

No serious programmer would consider Eval to be "Evil". It's simply a programming tool, like any other. The fear (if there is a fear) of this function has nothing to do with popular culture. It's simply a dangerous command which is often misused, and can introduce serious security holes, and degrade performance. From my own experience I would say that it's rare to encounter a programming problem which cannot be solved more safely and efficiently by some other means. The programmers who are most likely to use eval, are those who are probably least qualified to do so safely.

Having said that, there are languages where the use of eval is appropriate. Perl comes to mind. However I personally find it's very rarely needed in other, more modern languages, which natively support structured exception handling.

Answer 10

I think you cover it quite well in the following part of your question (emphasis mine):

they have a good use, as long as they are used properly

For the 95% who might use it properly it's all well and good; but there will always be people who don't use it properly. Some of those will be down to inexperience and lack of ability, the rest will be malicious .

There will always be people who want to push boundaries and find security holes - some for good, some for bad.

As for the historical fact aspect of it, eval type functions essentially allow Arbitrary code execution which has previously been exploited in popular web CMS, Joomla!. With Joomla! powering over 2.5 million sites worldwide, that's a lot of potential damage not only to visitors to those sites, but potentially to the infrastructure it's hosted on and also the reputation of the sites/companies which have been exploited.

The Joomla! example might be a simple one, but it's a one which has been recorded.

Answer 11

There are some good reasons to discourage the use of eval (although some are specific to certain languages).

• The environment (lexically and dynamically) used by eval is frequently surprising (that is, you think eval(something here) should do one thing, but it does another, possibly triggering exceptions)
• There is frequently a better way of accomplishing the same thing (concatenation of constructed lexical closures is sometimes a better solution, but that may well be Common Lisp-specific)
• It is far too easy to end up with unsafe data being evaluated (although this can mostly be guarded against).

I would, personally, not go as far as saying that it's evil, but I will always challenge the use of eval in a code review, with wordings along the line of "have you considered some code here?" (if I have time to make at least a tentative replacement), or "are you sure an eval really is the best solution here?" (if I don't).

Answer 12

In Minsky's Society of Mind, Chapter 6.4, he says

There is one way for a mind to watch itself and still keep track of what's happening. Divide the brain into two parts, A and B. Connect the A-brain's inputs and outputs to the real world - so it can sense what happens there. But don't connect the B-brain to the outer world at all; instead connect it so that the A-brain is the B-brain's world!

When one program (B) writes another program (A) it is functioning as a meta-program. B's subject matter is program A.

There is a C program. That's the one in your head that writes program B.

The danger is there can be somebody (C') with evil intent, who can interfere in this process, so you get things like SQL-injection.

The challenge is to make software smarter without also making it more dangerous.

Answer 13

You have a lot of good answers here and the main reason is clearly that arbitrary code execution is bad mmmkay but I will add one other factor that others have only touched on the edge of:

It is really hard to troubleshoot code that is being evaluated out of a text string. Your normal debugging tools are pretty much straight out of the window and you are reduced to very old-school tracing or echoing. Obviously that doesn't matter so much if you have a fragment in a one-liner which you want to eval but as an experienced programmer you can probably find a better solution for that, whereas larger-scale code generation may be somewhere that an evaluation function becomes a potentially useful ally.