5 ms·

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 st

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
    there is no eval_from_url(), though.
    - m12k 5y ago
      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.
qalmakka 5y ago
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.
- deleted 5y ago
  [deleted]
- HappyDreamer 5y ago
  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-evaluating-a-python-code-from-an-http-response-in-python-3-x 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?)
  - qalmakka 5y ago
    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.
fomine3 5y ago
LLs have eval() but they are normally must be called explicitly. Unlike Java's evel() equivalent everywhere.

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
  there is no eval_from_url(), though.
  - m12k 5y ago
    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.

qalmakka 5y ago

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.

deleted 5y ago
[deleted]
HappyDreamer 5y ago
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-evaluating-a-python-code-from-an-http-response-in-python-3-x 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?)
- qalmakka 5y ago
  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.

fomine3 5y ago

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