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.
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.
[1] https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
https://github.com/Microsoft/MSRC-Security-Research/tree/mas...
I have a feeling you could find Java ones too if you looked hard enough. Compilers are complex beasts.
It's a straightforward miscompilation. I'm not sure why they even classify it as a vulnerability.
From Microsoft, per the article: "The said vulnerability is about downloading and running untrusted code, which has always existed in all releases prior VS2017 Update 9 that supported lambdas. The scenario is not common coding practice and considering we've always had this in all our prior releases and have not seen any evidences of exploit it would not make sense to port the change as hotfix from 15.9 to prior VS releases."
In other words, it's never made into a product in an exploitable way. I'd just call this a miscompilation.
What does that even mean? I download some c++ code from the internet, compile it, run it, and... it runs as my user?
> Exploitation of the vulnerability requires that a user open a specially crafted file which was compiled with an affected version of Visual Studio. In an email attack scenario, an attacker could exploit the vulnerability by sending a specially crafted project, or resource file, to the user and convince the user to open the file.
So yeah sure looks like a basic code execution results in code execution. Surprised this even got a CVE.
I guess there is some conceivable exploit where you compile some hostile code written in a safe language to C++ with MSVC and then run it, and the attacker could exploit this bug somehow? But who does that?
Seems like an odd restriction to impose here. How many C++ exploitable bugs arose from a C++ compiler bug? I think the answer to that is also zero. Doesn't really seem like a useful thing to consider?
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.