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

321–330 of 377 posts

Re: Serious Chrome zero-day

#321

Post by staticassertion »

zetafunction wrote: post #234
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…

> Let's just collectively admit it, finally - you can't write safe C++ in a codebase this complex. I work on Chrome. The working assumption is there always exists a bug that allows remote code execution in the renderer.

Naturally, but I think maybe you missed my point.

I listed a subset of the things Chrome does to help mitigate the fact that C++ bugs will make it out. It's because they don't trust C++ that this is the case.

What is interesting is that, in the case of the first itw exploit, the root case appears to be memory safety. That despite the many millions invested, memory safety was still what an attacker went after and managed to leverage into an exploit against users.

That's all.

Re: Serious Chrome zero-day

#322

Post by [deleted] »

krageon wrote: post #306
SamBam wrote: post #300

Earlier quoted context omitted.

I'm amazed. Are there really, "conservatively," 1000 developers working on Chrome full-time, for years? That seems incredibly high to me, but maybe I just don't realize what it takes to build an app like Chrome.

As an estimate I think we can safely say it's not conservative. Especially if this is actually developers (ie straight up coders) and not also all of their supporting personnel.

[deleted]

Re: Serious Chrome zero-day

#323

Post by apta »

naikrovek wrote: post #316
kllrnohj wrote: post #136

Earlier quoted context omitted.

> Get more compiler people on Go and it will be even faster than it is now (really fast), and Go is written in Go so there's no reliance on C++, unlike Rust. You'll still be stuck with the fundamental tradeoffs that Go made like being GC'd and not having a fast FFI. Those tradeoffs make sense in the target audience of Go (servers), but it's not going to make sense in something like a web browser.

Go has a garbage collector, and it's the fastest garbage collector that currently exists, by a wide margin, I believe. When Go 1.8 released, it measured I don't believe that "it uses garbage collection" is a valid complaint against Go anymore, except in a real-time application, and I don't know of any real-time applications written in Go. I'm sure there are some, I just don't know of them.

> Go has a garbage collector, and it's the fastest garbage collector that currently exists, by a wide margin, I believe.

Fastest by what measure? I benchmarked some key value store implementation written in golang and ran into large (> 1 sec) latency spikes because the golang gc couldn't keep up with the large (10GB+) heap space. Java would have allowed me to select a GC algorithm that's best for my use case and I wouldn't have run into that issue.

golang's gc is tuned for latency at the expense of throughput, that's basically it. It's not some magic bullet that solved the gc issue, contrary to what the golang marketing team wants people to believe.

Re: Serious Chrome zero-day

#324

Post by staticassertion »

blub wrote: post #279
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…

Your claim that Chrome can be used a lesson in choosing programming languages is quite weak, because almost no one will build such a complex application and despite the risk all successful browsers still chose C++. An application that: a) has downloading and executing untrusted code as its main feature b) supports a ton of media formats, with DRM to boot c) is going through rapid changes, including adding very comple…

You've missed my point entirely. This is not a plea to Chrome to rewrite their browser. My post has nothing to do with browsers.

My claim is that Chrome is an interesting case study in the most hardened user-facing C++ codebase in the world being hacked because of memory unsafety.

I also think that the strawman argument you've made is extremely weak for other reasons. This whole "insecure by design" thing is nonsense - everyone stating this seems to not understand that multitenant systems have existed for ages, under far more difficult constraints. An example - AWS Lambdas colocate your code with other companies' on the same hardware - if this were such an impossible task, that wouldn't be possible.

But again, my argument is not about browsers, or even much about languages, and is merely me pointing out an interesting case where memory unsafety was the root cause of an attack, despite great efforts.

Re: Serious Chrome zero-day

#325

Post by busterarm »

short_sells_poo wrote: post #269
feanaro wrote: post #259

Earlier quoted context omitted.

So it's possible that t1 < t0? Because something might had been exploited before whatever time is taken as the official "discovery date".

I assume it is 0day irrespective of who discovered it. It remains 0day until an action is taken to mitigate it. So you have 0day exploits being traded on various markets - those are exploits which are known to certain groups, but the affected party hasn't yet taken action to mitigate them (most likely because they don't know).

That's correct.

Re: Serious Chrome zero-day

#326

Post by blub »

staticassertion wrote: post #324
blub wrote: post #279

Earlier quoted context omitted.

Your claim that Chrome can be used a lesson in choosing programming languages is quite weak, because almost no one will build such a complex application and despite the risk all successful browsers still chose C++. An application that: a) has downloading and executing untrusted code as its main feature b) supports a ton of media formats, with DRM to boot c) is going through rapid changes, including adding very comple…

You've missed my point entirely. This is not a plea to Chrome to rewrite their browser. My post has nothing to do with browsers. My claim is that Chrome is an interesting case study in the most hardened user-facing C++ codebase in the world being hacked because of memory unsafety. I also think that the strawman argument you've made is extremely weak for other reasons. This whole "insecure by design" thing is nonsense…

The culmination of your message was "Let's just collectively admit it, finally - you can't write safe C++ in a codebase this complex.", that's your point. It's probably correct, but also meaningless as I mentioned, because:

a) most codebases aren't even nearly this complex

b) no one will likely write such a codebase again

So the entire "point" is just trivia. It can't be used to decide whether to program something in C++, it can't be used to decide whether to use Chrome, it's not actionable at all.

Frankly I'm peeved that a superficial comment triggered such a long discussion and monopolised the top spot in the thread instead of making space for technical explanations or more interesting discussion.

Re: Serious Chrome zero-day

#327

Post by throwaway12iii »

pcwalton wrote: post #309
throwaway12iii wrote: post #247

Earlier quoted context omitted.

From the rust Oxidization page (hip name): - "Crossing the C++/Rust boundary can be difficult." - "For components that are relatively standalone, with small and simple APIs." - "This minimizes the C++/Rust boundary layer issues." Not only does Rust not have a good JavaScript integration story, it doesn't have a good C++ integration story. Most of Firefox is still (8 years later) not written in Rust. Chrome with C++ h…

None of this is responsive to my points.

Rust is bad at managing DOM memory in Firefox.

Re: Serious Chrome zero-day

#328

Post by zenexer »

jrochkind1 wrote: post #301
paulpauper wrote: post #37

This write-up is not helpful and says nothing about how one would be infected. it just says it can do code execution but no evidence anyone has been infected in any way or how would would be infected. The worst 0day possible is un-sandboxed code execution that is activated by merely visiting a webpage or clickinig.

This article has a bit more information, including suggestions by some that there are indeed exploits active in the wild. https://www.forbes.com/sites/daveywinder/2019/03/07/google-c... > Although information regarding CVE-2019-5786 remains scarce currently, Satnam Narang, a senior research engineer at Tenable, says it is a "Use-After-Free (UAF) vulnerability in FileReader, an application programming interface (API)…

That's conflating two unrelated issues. The issue reported by EdgeSpot is much less severe, and a Google engineer hinted that it may not even be a vulnerability. CVE-2019-5786 has nothing to do with PDF files.

Re: Serious Chrome zero-day

#329

Post by throwaway12iii »

krageon wrote: post #305
throwaway12iii wrote: post #247

Earlier quoted context omitted.

From the rust Oxidization page (hip name): - "Crossing the C++/Rust boundary can be difficult." - "For components that are relatively standalone, with small and simple APIs." - "This minimizes the C++/Rust boundary layer issues." Not only does Rust not have a good JavaScript integration story, it doesn't have a good C++ integration story. Most of Firefox is still (8 years later) not written in Rust. Chrome with C++ h…

You make a lot of points about Rust and mention Firefox in your conclusion, right after saying Firefox is by and large not Rust. I think your logical argument would be better served by using clear language and a single subject. After you have those two things you can think about coming up with examples.

Thanks for your contribution. It's really good. Your sentences are definitely not too long. You definitely understand the difference between a comment and an essay.

Re: Serious Chrome zero-day

#330

Post by pjmlp »

Eldt wrote: post #294
sureaboutthis wrote: post #288

Earlier quoted context omitted.

And almost every operating system in the world is written in C by top developers who are in the know. If there was a better way, everyone would do it, but they don't. Let's quit pretending that any software written in any other language would be more secure and have less bugs.

Humans are fallible. Relying on them to make the same safety decisions afforded by languages such as Rust is asinine.

That is exactly why we need safety rails.
Post reply on HN