5 ms·

(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 do

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

runeks 5y ago
Agreed. Loading and running arbitrary Java byte code should not be possible from user code. Only the runtime system should have this ability.
- eMGm4D0zgUAVXc7 5y ago
  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?
  - PenguinCoder 5y ago
    > restart everything if they need a plugin Yes. Hopefully ensures that only people authorized to actually restart the service can add arbitrary code.
    - eMGm4D0zgUAVXc7 5y ago
      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.
      - MikeKusold 5y ago
        Restarting an operating system is completely different than restarting an application after you enable a plug-in.
      - lrem 5y ago
        Zero-downtime service restarts have been a thing for a very long time. It is a different story for operating systems.
  - jatone 5y ago
    a trivial false dichotomy. you can create plugin systems that do not allow modifying the runtime.
  - qalmakka 5y ago
    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.
  - laumars 5y ago
    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.
rightbyte 5y ago
Why? It is the equivalent thing to download elf-files for Java.
eMGm4D0zgUAVXc7 5y ago
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/java/net/Socket.html https://docs.oracle.com/en/java/javase/16/docs/api/java.base...
- hyperpape 5y ago
  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.
adambatkin 5y ago
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).
- lrem 5y ago
  But we're not talking about memory corruption bugs. We're talking about intentional features.
  - hu3 5y ago
    That was covered with eval() which is an intentional feature. > Perl/Python/Ruby/PHP and friends all have eval()...
    - qalmakka 5y ago
      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.
    - baq 5y ago
eternalban 5y ago
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!?")
- qalmakka 5y ago
  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.
kgeist 5y ago
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?

runeks 5y ago

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

eMGm4D0zgUAVXc7 5y ago
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?
- PenguinCoder 5y ago
  > restart everything if they need a plugin Yes. Hopefully ensures that only people authorized to actually restart the service can add arbitrary code.
  - eMGm4D0zgUAVXc7 5y ago
    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.
    - MikeKusold 5y ago
      Restarting an operating system is completely different than restarting an application after you enable a plug-in.
    - lrem 5y ago
      Zero-downtime service restarts have been a thing for a very long time. It is a different story for operating systems.
- jatone 5y ago
  a trivial false dichotomy. you can create plugin systems that do not allow modifying the runtime.
- qalmakka 5y ago
  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.
- laumars 5y ago
  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.

rightbyte 5y ago

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

eMGm4D0zgUAVXc7 5y ago

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/java/net/Socket.html https://docs.oracle.com/en/java/javase/16/docs/api/java.base...

hyperpape 5y ago
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.

adambatkin 5y ago

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

lrem 5y ago
But we're not talking about memory corruption bugs. We're talking about intentional features.
- hu3 5y ago
  That was covered with eval() which is an intentional feature. > Perl/Python/Ruby/PHP and friends all have eval()...
  - qalmakka 5y ago
    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.
  - baq 5y ago

eternalban 5y ago

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!?")

qalmakka 5y ago
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.

kgeist 5y ago

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?