Hacker News new | past | comments | ask | show | jobs | submit login

How many remotely exploitable bugs in Java apps (that don't run arbitrary Java code†) do you see that arise from Java compiler bugs? I can't think of a single one.

†I explicitly say "not running arbitrary Java code" to emphasize the difference between this scenario and JS engine vulnerabilities. JS engine vulnerabilities are a problem because JS engines execute untrusted code, but I'm talking about compiler bugs in trusted code that can nevertheless be exploited remotely.




> How many remotely exploitable bugs in Java apps (that don't run arbitrary Java code†) do you see that arise from Java compiler bugs? I can't think of a single one.

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.


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


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


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.


Here's a specific example for a C++ compiler: CVE-2019-0546

I have a feeling you could find Java ones too if you looked hard enough. Compilers are complex beasts.

[1]: https://nvd.nist.gov/vuln/detail/CVE-2019-0546


That seems to be this one: https://www.thezdi.com/blog/2019/2/28/finding-unicorns-when-...

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.


> If you’re still on the fence about deploying this update, we would consider it Important since it could allow for attacker-controlled code to execute at the level of the logged on user.

What does that even mean? I download some c++ code from the internet, compile it, run it, and... it runs as my user?


https://portal.msrc.microsoft.com/en-US/security-guidance/ad...

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


Yeah, I think it means just that.

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?


How many remotely exploitable bugs in Java apps (that don't run arbitrary Java code†) do you see that arise from Java compiler bugs? I can't think of a single one.

If enough of a complex system is written in a language or run on a managed runtime that eliminates entire classes of exploits, then the developers will wind up implementing some optimizations and/or a way to write applications/plugins/extensions in C/C++. These mechanisms will open the doors to those exploits again.

(At least for now. Going forwards, I think we might be able to solve this one.)


Depends on if you mean Java->Bytecode compilation or JIT. For the former, I don't recall ever seeing one, for the latter I've gotten one fixed.


Was that one remotely exploitable? If so, how would someone exploit it, specifically?




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: