Re:Serious Chrome zero-day
by staticassertion on Wednesday March 06, 2019 @06:55PM
(#19324237)
To be clear, I'm not saying "Chrome should be rewritten in a memory safe language", I'm saying that Chrome is an excellent project to point to, say "Wow, no one does as much to secure a codebase as them", and to follow that up with "and they still got owned".
[ Parent
| on HN ]
But to what end? Pure-java apps get owned all the time, too. If you look over there you'd just give up on ever trying to transmit data, as the number of Java de-serialization exploits is nothing short of stunning.
The only semi-proven way to not get owned at this point is to never go online.
Re:Serious Chrome zero-day
by staticassertion on Wednesday March 06, 2019 @07:33PM
(#19324525)
I'm not really interested in having a language shootout but I will say that I think you may be misunderstanding Java's history of serialization vulnerabilities.
> I think you may be misunderstanding Java's history of serialization vulnerabilities.
Can you elaborate? https://github.com/GrrrDog/Java-Deserialization-Cheat-Sheet is just one example compendium. The number of vulnerabilities in this area is huge, across a wide range of libraries. It really is an entire category of exploits at this point, and it's still ongoing (eg, from last year: https://nvd.nist.gov/vuln/detail/CVE-2018-4939 )
Re:Serious Chrome zero-day
by staticassertion on Wednesday March 06, 2019 @07:48PM
(#19324610)
You're right that it's a real footgun, the major issues that I'm aware of are in the native serializer, but yeah even the big libraries like Jackson have had issues.
I don't consider those on the same level as memory unsafety, personally, but it's not really a meaningful comparison because I'm not going to dig around for numbers and mitigation techniques.