3 ms·

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

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

kllrnohj 8y ago
> 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.
- pcwalton 8y ago
  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.
- viraptor 8y ago
  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.
- littlestymaar 8y ago
  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-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
  - pjmlp 8y ago
    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/master/presentations/2019_02_BlueHatIL https://github.com/Microsoft/MSRC-Security-Research/tree/mas...

kllrnohj 8y ago

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

pcwalton 8y ago
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.
viraptor 8y ago
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.
littlestymaar 8y ago
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-security-bugs-are-memory-safety-issues/ https://www.zdnet.com/article/microsoft-70-percent-of-all-se...
- pjmlp 8y ago
  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/master/presentations/2019_02_BlueHatIL https://github.com/Microsoft/MSRC-Security-Research/tree/mas...