3 ms·

After the log4j vulnerability, I’d say that despite having good memory safety I would say the JVM’s powerful serialization primitives make me pretty leery of it

After the log4j vulnerability, I’d say that despite having good memory safety I would say the JVM’s powerful serialization primitives make me pretty leery of it as far as security goes.

MattPalmer1086 2y ago
The log4j vulnerability was due to Java code, not in the JVM. But I get that people mostly conflate the two.
bruce343434 2y ago
The log4j vulnerability happened because the log4j programmers made an overly generalized "do anything and everything" software. The kind of architecture that is made to be so generic that the software accidentally gains emergent properties (=not thought of/realized/considered execution paths and interactions). Although the desire to write software like that might have arisen under the influence of the object oriented mindset, I'm sure it could have happened in any other language.
aeonik 2y ago
You can do the same thing in Rust as Log4J. I haven't tested this code, and definitely don't do this. This code is intended to lets attackers run any shell command by sending JSON with a "debug_command" field - similar to Log4J, it's a "feature" being misused rather than a memory bug that Rust would catch. ```rust use serde_json::Value; use std::process::Command; fn process_log_entry(log: &str) { // UNSAFE: Allows command injection if let Ok(json) = serde_json::from_str::<Value>(log) { if let Some(cmd) = json.get("debug_command") { Command::new("sh") .arg("-c") .arg(cmd.as_str().unwrap_or("")) .output() .unwrap(); } } } ```
- d3nj4l 2y ago
  That's not the same thing. You can call a shell command from any language. The log4j problem was that you could load arbitrary classes from the internet into the memory of the current process, which is a much more severe problem.
  - aeonik 2y ago
    I am aware, but I wanted to illustrate the higher level idea of architecture issue vs memory issue. To keep it concise, I had take some liberties. If you have more time than me, please feel free to reproduce Log4J more accurately in Rust.
  - GoblinSlayer 2y ago
    If you can run a shell command, it can do basically anything you want.
    - tialaramex 2y ago
      Sure, in a general purpose language, like Java, or Rust, or C++ you can indeed do "basically anything you want" that's why it's called general purpose, your purpose might be to run arbitrary code you found on the Internet, so, that's a thing you can do. If you can't it's not general purpose. In a number of applications this means you do not actually want a general purpose language which is why WUFFS makes sense. But, even when you don't have that constraint it's reasonable to ask: How easy was it to make a thing you didn't intend, by accident ?
- tcoff91 2y ago
  I feel like Rust has a different development culture than Java and Java devs are more likely to want to build some abstraction that does everything and loads classes from the network into the runtime.
naasking 2y ago
> I’d say that despite having good memory safety I would say the JVM’s powerful serialization primitives make me pretty leery of it as far as security goes. That's a sound deduction. The JVM had such a vulnerability because it's full of ambient authority and rights amplification patterns. More such vulnerabilities probably exist, they're just hard to see.

After the log4j vulnerability, I’d say that despite having good memory safety I would say the JVM’s powerful serialization primitives make me pretty leery of it as far as security goes.

MattPalmer1086 2y ago

The log4j vulnerability was due to Java code, not in the JVM. But I get that people mostly conflate the two.

bruce343434 2y ago

The log4j vulnerability happened because the log4j programmers made an overly generalized "do anything and everything" software. The kind of architecture that is made to be so generic that the software accidentally gains emergent properties (=not thought of/realized/considered execution paths and interactions). Although the desire to write software like that might have arisen under the influence of the object oriented mindset, I'm sure it could have happened in any other language.

aeonik 2y ago

You can do the same thing in Rust as Log4J. I haven't tested this code, and definitely don't do this. This code is intended to lets attackers run any shell command by sending JSON with a "debug_command" field - similar to Log4J, it's a "feature" being misused rather than a memory bug that Rust would catch. ```rust use serde_json::Value; use std::process::Command; fn process_log_entry(log: &str) { // UNSAFE: Allows command injection if let Ok(json) = serde_json::from_str::<Value>(log) { if let Some(cmd) = json.get("debug_command") { Command::new("sh") .arg("-c") .arg(cmd.as_str().unwrap_or("")) .output() .unwrap(); } } } ```

d3nj4l 2y ago
That's not the same thing. You can call a shell command from any language. The log4j problem was that you could load arbitrary classes from the internet into the memory of the current process, which is a much more severe problem.
- aeonik 2y ago
  I am aware, but I wanted to illustrate the higher level idea of architecture issue vs memory issue. To keep it concise, I had take some liberties. If you have more time than me, please feel free to reproduce Log4J more accurately in Rust.
- GoblinSlayer 2y ago
  If you can run a shell command, it can do basically anything you want.
  - tialaramex 2y ago
    Sure, in a general purpose language, like Java, or Rust, or C++ you can indeed do "basically anything you want" that's why it's called general purpose, your purpose might be to run arbitrary code you found on the Internet, so, that's a thing you can do. If you can't it's not general purpose. In a number of applications this means you do not actually want a general purpose language which is why WUFFS makes sense. But, even when you don't have that constraint it's reasonable to ask: How easy was it to make a thing you didn't intend, by accident ?
tcoff91 2y ago
I feel like Rust has a different development culture than Java and Java devs are more likely to want to build some abstraction that does everything and loads classes from the network into the runtime.

naasking 2y ago

> I’d say that despite having good memory safety I would say the JVM’s powerful serialization primitives make me pretty leery of it as far as security goes. That's a sound deduction. The JVM had such a vulnerability because it's full of ambient authority and rights amplification patterns. More such vulnerabilities probably exist, they're just hard to see.