4 ms·

> In Java it's fine to, at runtime pull in classes you've never used before and run them, you can't do that in Rust... Of course you can. Rust would be a seve

> In Java it's fine to, at runtime pull in classes you've never used before and run them, you can't do that in Rust... Of course you can. Rust would be a severely limited systems language if it couldn't support dynamic loading. E.g. see - https://michael-f-bryan.github.io/rust-ffi-guide/dynamic_loading.html https://michael-f-bryan.github.io/rust-ffi-guide/dynamic_loa... - https://crates.io/crates/libloading https://crates.io/crates/libloading

tialaramex 5y ago
Notice that no classes come in here, the Rust Plugin trait used in that first page actually exists in the Rust code at compile time, as expected. You get to pull in machine code, by explicitly telling Rust that's what you wanted to do, but you don't get to conjure any types at runtime, because exactly as I said they simply don't exist at runtime. The Log4j "lookup" behaviour was, first of all, a really dumb design decision even in Java but it's just wrong to pretend that it would be equally easy for it to be so catastrophic in most languages, not just Rust, even in C++ I think you'd probably realise you'd screwed up while developing a way for the log framework to run arbitrary code.
- tptacek 5y ago
  This whole discussion seems kind of overblown. Every mainstream systems language is capable of having this kind of vulnerability, Rust included. But runtime pluggability is part of the culture of Java code (and some Python projects, and Ruby, &c) and isn't part of Rust or Go's culture. So every Java project is potentially exposed to this kind of thing, but only the plugin-styled Rust and Go programs are. You're much less likely to see a deserialization bug in Rust or Go than in Java. There is nothing intrinsic to Rust or Go that prevents deserialization bugs; they're just not encouraged by idiom like in Java.
  - gmfawcett 5y ago
    > every Java project is potentially exposed to this kind of thing Many Java projects, but not all. Class-loading permissions in a Java program are subject to the security-manager policy for the program; class loading can be moderated or even fully disabled (once the main program is loaded, of course). The default is to allow anything to be loaded, however.

tialaramex 5y ago

Notice that no classes come in here, the Rust Plugin trait used in that first page actually exists in the Rust code at compile time, as expected. You get to pull in machine code, by explicitly telling Rust that's what you wanted to do, but you don't get to conjure any types at runtime, because exactly as I said they simply don't exist at runtime. The Log4j "lookup" behaviour was, first of all, a really dumb design decision even in Java but it's just wrong to pretend that it would be equally easy for it to be so catastrophic in most languages, not just Rust, even in C++ I think you'd probably realise you'd screwed up while developing a way for the log framework to run arbitrary code.

tptacek 5y ago
This whole discussion seems kind of overblown. Every mainstream systems language is capable of having this kind of vulnerability, Rust included. But runtime pluggability is part of the culture of Java code (and some Python projects, and Ruby, &c) and isn't part of Rust or Go's culture. So every Java project is potentially exposed to this kind of thing, but only the plugin-styled Rust and Go programs are. You're much less likely to see a deserialization bug in Rust or Go than in Java. There is nothing intrinsic to Rust or Go that prevents deserialization bugs; they're just not encouraged by idiom like in Java.
- gmfawcett 5y ago
  > every Java project is potentially exposed to this kind of thing Many Java projects, but not all. Class-loading permissions in a Java program are subject to the security-manager policy for the program; class loading can be moderated or even fully disabled (once the main program is loaded, of course). The default is to allow anything to be loaded, however.