Hacker News Reader

Comment by qalmakka | Hacker News Reader

(Maybe) Unpopular opinion: this whole ordeal is also due to the JRE being a clusterfuck of legacy and poor ideas. I understand it was the 90s but allowing to download arbitrary .class files from a server is _insane_, no matter how you spin it around.

View on HN

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).

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.

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?

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

The "poor idea" in the 90s was that developers were going to read specifications. Sun Micro specially suffered from this. Thus the "clusterfuck" of JRE, for example, offered something called a Security Manager, but it was "insane" to think commodity IT developers would use it ("wat's dat!?")

The fact that people don't read or use your specifications should ring a bell in someone's ears. I shouldn't have to care about the Security Manager unless I'm writing an app that might do stuff that covers its use cases. It makes no sense that JNDI is usable and loadable by Minecraft, it's just a dangerous API.

Agreed. Loading and running arbitrary Java byte code should not be possible from user code. Only the runtime system should have this ability.

How do you want to write software which supports plugins then?

Force the user to restart everything if they need a plugin?

Or do you want to force developers to only ever write monolithic software now?

> restart everything if they need a plugin

Yes. Hopefully ensures that only people authorized to actually restart the service can add arbitrary code.

Have a look at the forced restarts of Windows due to updates having become a well-hated meme to see how lucky you'll be in explaining that to the users.

Restarting an operating system is completely different than restarting an application after you enable a plug-in.

Zero-downtime service restarts have been a thing for a very long time. It is a different story for operating systems.

a trivial false dichotomy. you can create plugin systems that do not allow modifying the runtime.

It's simple, you simply implement some sort of code signing feature, or you only let people run arbitrary code in a sandbox or some sort of similarly limited environment. Letting people load code from a remote source into the same address space of a running program containing potentially sensitive data is intrinsically bad.

In fairness, Java has had capabilities to only let signed code run since its early days (it was fundamental for stuff like Applets or RMI), but like the rest of Java the whole specification is over engineered and quite complicate so nobody bothers with it. There are just too many old features lying around in the JRE that should be off by default. Like they shouldn't be possible to use unless you explicitly configure your environment to enable them. 99.999% of apps do not need and will never care about JNDI, and having it just lying around doing nothing just pointlessly increases the surface attack of your application for no good reason.

Plug-ins should be sandboxed anyway. Which means they shouldn’t be random Java classes with the same blast radius as your main application. And if you’ve done that right you’ve got a VM that can be restarted without having to restart the parent application.

Why? It is the equivalent thing to download elf-files for Java.

I think it's a perfectly OK idea, as long as you control the servers you are trying to access via this feature. The problem is about not sanitizing user inputs. You can achieve the same by forking a process whose file path is controlled by user input. Does it mean allowing a program to fork processes is also insane?

Do you want Java to do deep packet inspection on all network traffic?

Because Java supports naked sockets [1], so that is what you would have to do to block the network traffic from containing .class files.

(Or remove the capability of real networking. I suppose we can agree that a language which doesn't support networking is quite limited in its use nowadays?)

[1] https://docs.oracle.com/en/java/javase/16/docs/api/java.base...

I don't have a 100% settled opinion about what the JVM design should look like, so I'm not fully aggreeing with the parent poster. However, I don't think you're being fair to the spirit of the complaint. There's a difference between two scenarios:

1. You can write a raw socket, pull a class file, put it in the right place, and load it using classloaders (assuming they don't want to abolish dynamic class-loading)

and

2. The language has a conventional way of loading arbitrary classes over the network using the standard library.

Any turing complete language can download and execute code. Even if the language doesn't support it natively, you can write an interpreter that acts on some code/bytecode. However, some languages support hot-loading code over the network in a straightforward way, while others force you to do all the work yourself (with attendant limitations). In effect, those languages require you to take the gun, check that it is loaded, and very carefully point it at your own foot.

Reply on news.ycombinator.com