With dlopen() and libclang/libgccjit, you could argue C (on an OS that supports dynamic loading) has eval too ;)

You have system("gcc uploaded.c && ./a.out") too!

But that code doesn’t run in the memory space of the process.

Then compile it as a library, and dlopen() it after all. (I'm just guessing the gp's point was that JIT isn't really an essential modality.)

Only in programs that invoke it on hacker controlled data.

But if you only evoke eval() on non-hacker controlled data in a scripting language, it's probably fine too.

My personal career favorite use of eval was for an import system that "unrolled" the loop that went through the columns for each row, using eval. It was much faster, but obviously a huge security risk.

Today with modern JIT compilers its probably not much faster...

I saw a very similar thing with eval. There was an evaluation of a nested JSON object

    x["a"]["b"]["c"] 

And the developer decided that this was best evaluated by eval. During the code review phase I talked to them and asked why they were using eval, and they didn't know it could be evaluated directly as they were a little unclear if javascript supported that syntax.

How much longer did said dev continue working there?

Fire the dev, or educate the dev. Sure, eval is just a sure sign of a lot of lack of understanding, but I'd hope for something less vile as eval would be a little more understanding that everyone learns something sometime

It's gross negligence of the dev is only a Javascript dev, but maybe understandable if it's just one of the three languages he uses regularly. I probably wouldn't fire, but I also can't imagine any of my devs doing that.

err, no comment

that dev is now your manager? /s

He is the dev

LOL, no to both!

I was once tasked with creating a new frontend on an old project that had an API endpoint return something like this:

  var array = ["foo", "bar"]

I was expecting xml or json (like the rest of the endpoints), but I realized that they just served this as text, and then eval'd it on the frontend...

This was how you used to do it before JSON.parse was built into the browser.

it was literally a pseudo "standard":

https://en.wikipedia.org/wiki/JSONP

Right, but for it to be JSONP, the response should be injected into a script tag, I believe.

And it should be wrapped in a function call (most times, you can choose which function is called by a query parameter).

> avoid eval as much as possible

"eval is evil", if you will.

Okay, I'll bite. I have known for a long time that eval is evil. Then, last year I actually needed to evaluate a string (from a file). As the case was safe enough (input 100% controlled by me), I did not worry too much and just used eval. But what would be a safe way to evaluate things if you needed to do that in unsafe environment? Say, you would like to make a safe website that allows user type a python code snippet and that would be evaluated/executed server side? Is that even possible?

Sure, that's basically what services like AWS Lambda do. As a starting point, you'd want to run the code in a short-lived VM with little to no network access which is dedicated to just running untrusted code.

Yes, this is what I'm currently doing with a cloud-based website automated-testing system.

In my case, code supplied by the end user is compiled into a different language such that I think I can prevent intentionally-malicious activity.

Nonetheless, spinning up a VM to create an environment in which potentially untrustworthy code is executed before then destroying the VM seems the safest option.

This is a bad solution.

Lambda allows arbitraty network access and may allow access to your AWS resources.

If you have to do this, the best approach is to containerise it, use capabilities to enforce restrictions and run in a virtual machine as isolated as possible.

It's still not great though. Some languages (eg Java) have additional features that help with this though.

Yes, I was simplifying — the important part is keeping the untrusted code off of a trusted network. If you want to do the legwork of carefully segregating things then of course network access can work.

I didn’t mention containers since they don’t provide strong isolation and some people misuse them as though they do. There’s no harm in using them as another layer of defense, but hardware virtualization provides much better security.

Why not just not trust the network or host at all. Put private connectivity inside trusted code using an SDK. Then the trusted apps can only communicate to devices/apps defined and nothing else. Untrusted code cannot access the trusted network as the network is acutally inside the apps/system.

But lambda as presented here isn't so much as a way for you to sandbox code, but AWS sandboxes your code. If you're needing to execute untrusted code, you need to play the role of AWS in this scenario.

When people actually want just a subset of `eval` to permit some custom computation, the proper thing to do is to define that subset as a language and make an interpreter that will read only that language.

As for mostly-full-featured `eval`: iirc Perl itself has a facility to create restricted sub-interpreters and run scripts that can't do certain things. (Though I might be confusing Perl with PHP here.)

Almost all modern programming languages have parsers for that language either as a standard library feature or as a package available in the ecosystem. That means it's very easy to run a production quality parser over an input string and then validate and the interpret the resultant AST as you see fit.

Besides that approach, simply rolling your own parser using a parser combinator library is super simple. The word combinator makes it seem complicated, but it's actually the opposite, using parser combinators is a lot simpler than writing a parser the traditional way you might have learned in formal education.

Implementing a simple DSL like for example an event-filtering language should cost a competent but fully inexperienced programmer maybe 1 or 2 weeks for a proof of concept, and then 3-6 more weeks to get it production ready depending on the feature set of course.

Of course, that's more time than simply running the V8 interpreter over your input string, and maybe running the V8 interpreter over your input string is an awesome way to empower your (trusted) customers.

If the user is trusted but the environment isn’t, the user can sign the string and you can validate it pre execution. If the user is not trusted, you need to contain the execution as much as possible, e.g. container without file or network access to your resources. If there is a need to access specific resource, white list it.

Basically, just use this: https://github.com/judge0/judge0

Tcl's possibility to use a restricted child interpreter and the active file pattern come to mind.

Perl does ship a sandbox module called Safe as a standard module, though I don't know how strong it is.

"The Safe module does not implement an effective sandbox for evaluating untrusted code with the perl interpreter."

https://perldoc.perl.org/Safe

Yeah, though in this case, whitelisting opcodes probably would have at least avoided qx and ``(both exec()). Avoiding the eval() altogether would be the right path, of course.

Of course, we are Google. /s

Have you tried writing your own interpreter?

Public facing?

Handles user input data??

Uses ‘eval’???

The line existed in the 2014 commit which migrated the repo to git. It wasn't designed in the current era of mass automated abuse and internet connected everything.

2014 was very much that era, I'd accept this excuse maybe for 2007

The line wasn't written in 2014, that's just the earliest that the history goes back. Presumably it's no newer than the early 2000s.

Considering that initial commit contains 400k lines, I would say there is a very long history before git was used.

The comment in the code slightly above says:

    this doesn't work in perl 5.6.2! grrrr

So this code is at least 20 years old, and probably pre-2000.

https://exiftool.org/ancient_history.html

    Sept. 26, 2008 - Version 7.44
           - Added read support for DjVu images

There were probably enough systems running perl 5.6.2 around 2008 to cause bug reports, or the code was migrated from an older piece of code and added to ExifTool.

It was not uncommon to manually ./configure, make, make install tarballs locally in those days, especially not on systems like Slackware so I can see it being possible to have old packages installed that were not automagically updated.

I remember before 2007 seeing people using eval and thinking "what on earth is wrong with you?"

I'd accept this for maybe pre-2000, but people should really know better.

That line is in a Perl metadata cleaning library. Not in Gitlab itself. Gitlab, who prides themselves and sell the gospel of improving security, willfully chose to use that library which was obviously never designed for their use case.

I looked at the front-page of that library. It says it cleans metadata from a huge number of file format. Frankly it looks more like something you would use on your own, known safe, files before sharing them online.

I'm not sure the tool is presented as a sanitizer for untrusted input. At least, it does not claim to be.

Why does Gitlab need to clean metadata from DjVu files? Wtf are DjVu files?!

> Why does Gitlab need to clean metadata from DjVu files?

It doesn't. It needs to clean metadata from JPEG and TIFF files. They didn't properly check if the files were actually of those types, and Exiftool performed its own content type detection to end up in its DjVu code.

> Wtf are DjVu files?!

DjVu is basically an alternative to PDF.[1]

[1]: https://en.wikipedia.org/wiki/DjVu

I think they are like a very old version of jpeg 2000s that support pan and zoom / tiling of large image files. It needed a license to create and one to display iirc

>"avoid eval"

We are already avoiding / trying to avoid way too much interesting and useful things. All for the sake of security and only to encounter new ways to be attacked. Instead of "avoid" how about actually organizing worldwide intolerance and hunt for those attackers.