Further it wasn't even a bug. It was the well defined behavior working as specified.

> and can be implemented in Rust without any difficulty.

Not really. You'd have to fight the language and pull in some crates, to be sure. There's no native object serialization in rust and it's not really a concept in the language or ecosystem - except perhaps in the future with wasm runtimes.

There are numerous details of log4j that, in general, just don't apply to rust code.

edit: Since perhaps people don't believe me...

Rust has no equivalent of JNDI, pickle, etc. There is no way to send rust 'code' except, perhaps, wasm. Certainly there's no well supported way with decades of history of being ingrained into libraries, or patterns that support it.

Loading and running a java class is only the most absurd exploitation possibility with log4j. Without that, you can still slurp any environment variables (or other process information) and send it to any host. And you can probably do yet other stuff too, it is quite flexible ...

> Loading and running a java class is only the most absurd exploitation possibility with log4j.

Uh, yeah, the RCE was very bad. And not a thing with Rust due to not having object serialization.

> you can still slurp any environment variables (or other process information) and send it to any host

Yeah, you can write a logger in rust that does really crazy things like adding environment variables through some sort of parsing of a language construct. That would still be a problem, but a lot less serious. It would probably also be really unidiomatic, but that's a separate story.

I think it would actually be pretty tricky to do that in Rust without realising what you'd done, as seemingly happened to log4j.

The root of the log4j problem is a failure to distinguish between log format strings and the formatted log string, beyond that what happens is that Java allows a lot of flexibility at runtime which simply doesn't exist in Rust. 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 - the types only existed at compile time. Indeed this is a key feature of Rust, because it means wrapper types are free at runtime, invaluable to the embedded firmware community who love type checking and other safety features but can't afford runtime overhead.

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

- https://crates.io/crates/libloading

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.

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.

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

I did not mean that the RCE of log4j is a memory safety issue, its just that, I would prefer to choose something where the probability of me having to wake up at the middle of the night and fix is less. Honestly, I would care less if it were memory safety or whatever, given I had to wake up at midnight :)

Just because it is written in Rust, it does not mean that you will have less bugs or whatever to fix. I could easily say that if it is written in Ada or Nim, then you will have way less bugs, as those languages are way easier to understand, and they are safe & fast & easy. Nim is just as easy as Python, and it is safe if you want it to.

>it does not mean that you will have less bugs or whatever to fix

But it does since you eliminate an entire class of bugs, and a class that's generally the source of most exploits out there (eg. heartbleed comes to mind as a similar level of exploit but was a result of memory errors).

JVM does the same with GC, and so do a lot of other languages, but when it comes to rewriting non-managed code Rust is a great choice over C in my book, I would feel better about introducing a Rust dependency over a C/C++ dependency just based on that.

As for ADA and Nim, if it's some black box docker service then sure, otherwise if I have to include it in my build pipeline that's a hard pass.

> But it does since you eliminate an entire class of bugs

As opposed to what language? C? x86 assembly? You may be right, but I was using Ada and Nim as an example, not C. I could have used D as well. Again, the fact that it is written in Rust and not Ada, Nim, or D does not mean that it has less bugs.

In fact, I would even argue that even if we do a C vs. Rust, it still does not follow that just because it is written in Rust and not C, it has less bugs. There are all sorts of other bugs that could outnumber the memory-related bugs you may have in C. Can you really not see this possibility?

>As opposed to what language? C? x86 assembly? You may be right, but I was using Ada and Nim as an example, not C. I could have used D as well. Again, the fact that it is written in Rust and not Ada, Nim, or D does not mean that it has less bugs.

Yes, C, the language memcached is written in. The fact that it's written in Rust means that it's more likely to work in the first place because more people are actually using that language in the real world vs. Ada, Nim and D.

>In fact, I would even argue that even if we do a C vs. Rust, it still does not follow that just because it is written in Rust and not C, it has less bugs. There are all sorts of other bugs that could outnumber the memory-related bugs you may have in C. Can you really not see this possibility?

I don't feel like just random googling for the sake of argument - it should be easy to find, there have been many analysis of this kind and pretty much any I've seen concludes the largest source of vulnerabilities have been memory errors (I remember FF, Linux, Microsoft, etc.). So yeah if you want to be pedantic for the sake of argument feel free to keep arguing about the semantics - real world experience motivated initial Rust development and it's gaining adoption in places like cloud provider infrastructure and drivers because people dealing with these issues know what their most common bugs are coming from.

I completely agree. My choice of words was not not right.

If log4j was implemented in Rust that feature would have never been implemented in the first place meaning th RCE wouldn't exist.

If Rust occupied the same market niche (better and easier than C++ for large companies!) as Java did in the early 2000s when such features were considered desirable by paying customers, it totally would have been implemented.

Rust is able to learn from the many mistakes that other languages before it have made. But pretending that this means Rust is inherently purer instead of just "has less baggage, but will soon implement its own", is naive.