Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Serious Chrome zero-day

nakedsecurity.sophos.com

Post reply on HN
Print view View original

151–160 of 377 posts

Re: Serious Chrome zero-day

#151

Post by amake »

munk-a wrote: post #74
uniformlyrandom wrote: post #51

Earlier quoted context omitted.

Not really, I have seen a lot of unneeded abbreviations. Thankfully we are (almost) out of the age of 140c messages and 40c editor lines. But more to the point, 'vulns' seems like a very unnatural abbreviation. I would go with v11n (similar to i18n).

Oh please _please_ don't. i18n is a terribly obscure term with no implicit link to the actual word. This is a place where "naming things is hard" but for big concept chose short concise terminology while letting the details get lost in the verbose verbiage. Whenever I see i18n I just weep over the fact they didn't use the term "lang", internationalization is complicated and hard to shorten due to other meaningful jar…

> Whenever I see i18n I just weep over the fact they didn't use the term "lang"

That's a bad idea because "lang" or "language" is already dangerously overloaded. People casually use it to mean any of (actual) language, locale (language + region (+ script, maybe)), script, or any combination of the above.

Re: Serious Chrome zero-day

#152

Post by pcwalton »

flukus wrote: post #111
staticassertion wrote: post #77

I'll be that guy. Chrome has probably invested > 1 billion dollars into their codebase at this point. Certainly >100million into security. They sandbox their code aggressively . They build this project with security in mind from day 1 - it's been architected for it. The Chrome security team(s) has a lot of power for a product security org. They fuzz. They invent new fuzzers. They cluster their fuzzers. They have a wo…

> According to the official release notes, this vulnerability involves a memory mismanagement bug in a part of Chrome called FileReader. That’s a programming tool that makes it easy for web developers to pop up menus and dialogs asking you to choose from a list of local files, for example when you want to pick a file to upload or an attachment to add to your webmail. It sounds like the bug occurs interacting with ext…

According to the patch, the problem involves memory management of DOM objects (specifically ArrayBuffers), not objects from native libraries.

Re: Serious Chrome zero-day

#153

Post by tedunangst »

kllrnohj wrote: post #134
staticassertion wrote: post #125

Earlier quoted context omitted.

I didn't say C++ was a bad choice and I've purposefully avoided making this another language war issue. What I'm saying is that Chrome is an example of a project with more security funding than just about any other project out there, and it still can't save users from the footguns of C++. I guess the question used the wording "should have written it in?", to which I said "a memory safe one", and that's not true. I'm…

> What I'm saying is that Chrome is an example of a project with more security funding than just about any other project out there, and it still can't save users from the footguns of C++. You can certainly make that argument but this doesn't seem to really be a compelling example. They had one security issue caused by a use-after-free over a decade. That's... a pretty fucking stellar track record and does not at all…

This is not the first chrome security issue in over a decade.

Re: Serious Chrome zero-day

#154

Post by kolme »

jsjohnst wrote: post #138
jlgaddis wrote: post #114

Earlier quoted context omitted.

... and Chrome in 2008.

Chrome wasn’t written from scratch in 2008. Chrome was a fork of WebKit, which was a fork of Konqueror, which was a fork of KHTML.

KHTML is the rendering engine for the Konqueror browser. Webkit is a fork of KHTML. And Chrome's engine is called Blink (it used to be Webkit, but they forked it).

Re: Serious Chrome zero-day

#155

Post by staticassertion »

kllrnohj wrote: post #146
staticassertion wrote: post #132

Earlier quoted context omitted.

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

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.

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.

Re: Serious Chrome zero-day

#156

Post by kllrnohj »

pcwalton wrote: post #147
kllrnohj wrote: post #142

Earlier quoted context omitted.

> 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 part…

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

> 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

#157

Post by chii »

Johnny555 wrote: post #129
nothrabannosir wrote: post #106

Earlier quoted context omitted.

The number of people required was a function of the "this complex" qualifier. I can write a safe C++ app on my own. I can't write Chrome on my own.

I can write a safe C++ app on my own But only if you don't use any external libraries, once you link in someone else's code, you can no longer be sure your program is "safe".

> I can write a safe C++ app on my own >> But only if you don't use any external libraries

using an external library is not "on your own"

Re: Serious Chrome zero-day

#158

Post by kllrnohj »

staticassertion wrote: post #155
kllrnohj wrote: post #146

Earlier quoted context omitted.

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.

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

#159

Post by tedunangst »

pcwalton wrote: post #149
beefsack wrote: post #148

Earlier quoted context omitted.

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 prac…

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

Re: Serious Chrome zero-day

#160

Post by staticassertion »

kllrnohj wrote: post #158
staticassertion wrote: post #155

Earlier quoted context omitted.

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/…

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.

Post reply on HN