notable that in the top exploited vulnerability list are RCEs against generally-more-safe runtimes, .net and java, at deserialization boundaries. I can only assume those boundaries contain badly behaved code, for speed. They shouldn't need to drop to an exploitable level though.
Conversation
Replying to
The issue for Java, Python (pickle), etc. is they include arbitrary code execution as part of their regular serialization approach instead of actually making a proper format. YAML has this same issue, among other formats. It's a really bad design. Typical dynamic code exec bugs.
1
Replying to
sure, bad formats have had bad behavior, but iirc, these were xml and json respectively. neither of those formats have any such native behavior, the closest native spec behavior is xml schema resolution, but that wasn't even the vector, and shouldn't be an RCE path either
1
Replying to
One of the few nice things about Go is the language has a culture of not using C libraries for things, largely because FFI is very slow and doesn't fit into the threading approach.
Java has gradually trended away from using lots of C and C++ libraries underneath though.
The main issue that I see for Java is people using the standard overly complex serialization support. It will happily let you serialize a closure in a field and run it after deserializing it. The reflection deeply built into the language makes it way too magical/powerful.
1
Also, stuff like dynamic class loading which easily turns into remote code execution if there's a file write vulnerability. Java isn't really worse than this regard than C and C++ though. It's just memory corruption is so common we don't think about dlopen plugin system bugs, etc