Comment by adambatkin | Hacker News Reader

Comment by adambatkin | Hacker News Reader

Parent Full thread

Maybe your opinion is unpopular for a reason. C and C++ has always suffered from the ability to corrupt some memory (like overrun a buffer) and jump into and start executing some user-provided arbitrary data. Perl/Python/Ruby/PHP and friends all have eval() which is even easier to exploit. Rust and maybe Go are much in this respect (because in most cases you need to deliberately mark a piece of code as unsafe before you'd be in too much trouble) but even then, the developer could always make a logic error and (for example) take a parameter from the user and use it to generate a filename and overwrite something on the system. And with this bug, the issue isn't something like a missing bounds check or off-by-one error, but a deliberate feature that someone wrote to work this way (yes there were some interactions they probably didn't think about, but it's obvious to everyone that it's never okay to decide the format string in the log message itself, that should be part of your static configuration).

The difference is that being pwned by a random memory corruption, while unfortunate, is an unintended feature. This on the other hand provides a deliberate, standardized and convenient way to allow anyone to download *any* arbitrary code into a running JVM. This is something that it is NEVER ok, not in any form or fashion, not even your own network unless you enable some huge debug flag, and it's WAY worse than eval().

This whole thing exists because Java has basically kept around a way of pulling off something akin to

    wget -O - someurl | sh

but with extra steps for more than 20 years. This is absolutely insane even from a '90s perspective, the whole idea is broken and it absolutely bewilders me that `com.sun.jndi.ldap.object.trustURLCodebase` was only set to false by default in 2018. This is utter rubbish; support for arbitrary URL codebases should have been canned decades ago, not 3 years ago.

The fact that JNDI can pull random code from a server like that is absolutely nonsensical trash, no matter how one spins it.

A bit hyperbole? Agreed that these features should be off by default, or removed -- maybe could be included only in a special JVM build,

Still, in Python you can GET and eval:

    r = urllib.request.urlopen(url).read()
    d = literal_eval(r.decode())

Here's someone "Fetching and evaluating Python code from an HTTP response":

https://stackoverflow.com/questions/28047761/fetching-and-ev...

Edit: Apparently `literal_eval` isn't so dangerous -- but one could replace it with `eval()`. /Edit

But you didn't start writing "absolutely insane" about Python ... Or maybe Python too is insane? And there should be a separate Python executable, with eval included?

What if Python shipped 2 executables?

    python   # there's no eval()
    python-with-eval    # danger! now you can use eval()

(And Java as well: `java` couldn't load any code dynamically, but `java-danger-dyn-code` could?)

The situation you describe is arguably different, if you eval() code you just fetched from an HTTP server you are deliberately, knowingly doing something very dangerous and it's only your fault. You are the one loading and cocking the gun.

By the way, you can do the same thing everywhere, nothing stops you from doing

    system("sh -c \"wget -O - someurl | gcc -x c - && ./a.out\"")

in C and allow the world to pwn you. What is arguable here is that in this case it is definitely not the language or the system's fault if their users are so dumb to invent a creative way to abuse a facility intended for a different use.

Viceversa, the JRE includes and standardizes facilities to potentially download and execute code without any reasonable sandboxing by default, out of the box, in the standard install. It's as if Python had mandated by standard to check if the data passed to `eval()` is an HTTP URL in order to download and eval() whatever resides at that address. It's not the same by any margin. One thing is to shoot yourself in the foot by mistake , one other is to have in your toolbox a device that by design chops your feet off. The thing that bewilders me is that the whole "let's download untrusted .class files from the Internet" thing was a deliberate design choice and it took people 25 years to realize how idiotic it was. There's a whole sea of difference between that and what you've described.

If I understand right, the equivalent in python wouldn't be

    r = urllib.request.urlopen(url).read()
    d = literal_eval(r.decode())

But rather:

    r = urllib.request.urlopen(url).read()
    logging.info(r.content)

Wouldn't that be pretty insane if the those two code fragments were functionally equivalent?

But we're not talking about memory corruption bugs. We're talking about intentional features.

That was covered with eval() which is an intentional feature.

> Perl/Python/Ruby/PHP and friends all have eval()...

There's a difference between providing a way to call the interpreter and giving people a convenient way to download code and execute it. No matter how you spin it, it's basically the same as standardizing `curl | sh`.

PS: eval() is also very bad per se, and IMHO it's a dangerous feature when used outside of a REPL or a debug environment. The fact that others already have bad features or are doing dubious things doesn't give you a free pass for doing them yourself. It never does, it's like saying that committing a crime is OK as long as everyone else does the same.

there is no eval_from_url(), though.

Oh that's neat - let's make a format string shorthand for eval_from_url() so it's easier to interface with, e.g. from a logging framework.

LLs have eval() but they are normally must be called explicitly. Unlike Java's evel() equivalent everywhere.

Reply on news.ycombinator.com