> Java deserialization RCEs, while pernicious, are nowhere near as common as use-after-free and related bugs in C++ code.
Can you justify that? Actual exploits from Java deserialization RCEs are well known & published, but by contrast searching the CVE database reveals a rather small number for C++ or CPP. Use-after-free gets a large list, but the majority seem to be in C code not C++ code.
Re:Serious Chrome zero-day
by littlestymaar on Thursday March 07, 2019 @05:20AM
(#19326931)
UAF are the most common, and the most commonly exploited kind of security bugs in Microsoft products for the last decade [1]. And Microsoft products are way more C++ than C.
[1] https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
Which is why their security team is now pushing for C#, Rust and constrained C++ for new developments.
https://github.com/Microsoft/MSRC-Security-Research/tree/mas...
All I can say is that more or less the entire security community disagrees with you that RCEs in Java programs are as common as RCEs in C++ programs.
I'm not sure how you'd even search for those, because deserialisation doesn't have an exact, common equivalent in C land. There are almost no cases of arbitrary/named types being constructed from arbitrary inputs at runtime. You have to take into account the really low prior probability for the counts to make sense.
Right, and that's why the fact that the Rust compiler has bugs is irrelevant. The language is meaningfully more memory-safe than C++.
> But in terms of Java runtime's security it's not particularly stellar. The entire category of "Java deserialization" is the never ending fountain of remotely exploitable security bugs in Java apps that don't run untrusted code.
Java deserialization RCEs, while pernicious, are nowhere near as common as use-after-free and related bugs in C++ code. Furthermore, you can effectively mitigate them by statically banning OutputObjectStream and whatnot. There's no such easy foolproof static mitigation available for C++ UAF.