Comment by qalmakka | Hacker News Reader

Comment by qalmakka | Hacker News Reader

Parent Full thread

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?

Reply on news.ycombinator.com