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

301–310 of 377 posts

Re: Serious Chrome zero-day

#301

Post by jrochkind1 »

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) included in browsers to allow web applications to read the contents of files stored on a user's computer." Some further digging by Catalin Cimpanu over at ZDNet suggests that there are malicious PDF files in the wild that are being used to exploit this vulnerability. "The PDF documents would contact a remote domain with information on the users' device --such as IP address, OS version, Chrome version, and the path of the PDF file on the user's computer" Cimpanu says. These could just be used for tracking purposes, but there is also the potential for more malicious behavior. The 'use-after-free' vulnerability is a memory corruption flaw that carries the risk of escalated privileges on a machine where a threat actor has modified data in memory through exploiting it.

Re: Serious Chrome zero-day

#302

Post by latexr »

why_only_15 wrote: post #225
latexr wrote: post #186

Earlier quoted context omitted.

I’d like to use Firefox, but their lack of AppleScript supports makes that unfeasible. I could get past its atrocious performance, but not past a missing feature I require multiple times a day. I don’t use Safari because it lacks other features. I can’t disable JavaScript on a per-site basis, and the content blockers are a joke compared to uBlock Origin. Most other browsers are Chromium based, so might as well use Ch…

What do you do that requires AppleScript support?

I need the title and URL of the frontmost tab, as well as to send JavaScript to the page.

Amongst other things, these are invaluable in dealing with the barrage of daily issues and PRs on Github.

Re: Serious Chrome zero-day

#303

Post by throwawaymath »

fooker wrote: post #258
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…

That's a weird and dishonest point to make here. You can't write safe $ANYTHING for a codebase this complex. I am yet to see someone who has worked on a codebase this complex disagree. Security issues and crashes in general result from your program interacting with the outside world and something behaving in a way you did not account for.

What’s dishonest? No one has said language choice is a silver bullet for all classes of security vulnerabilities. The point under contention is that we have better options for memory corruption vulnerabilities in particular.

In other words we’re not talking about whether or not something will be totally safe, but rather safer. Perfect is the enemy of good.

Re: Serious Chrome zero-day

#304

Post by throwawaymath »

sureaboutthis wrote: post #287
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…

> you can't write safe C++ in a codebase this complex. And yet they did. And it worked great for more than a decade. Until just today when someone found...one.

A cursory look at Chrome security disclosures shows many memory corruption vulnerabilities.

The most recent release fixed twelve use after free vulnerabilities: https://chromereleases.googleblog.com/2019/01/stable-channel....

Go take a look at how many have been found in previous releases.

Re: Serious Chrome zero-day

#305

Post by krageon »

throwaway12iii wrote: post #247
pcwalton wrote: post #199

Earlier quoted context omitted.

> Both of those issues would exist regardless of the language chosen--D, Erlang, Java, Python, Rust, w'ever. Not necessarily. If the language provides a way to ensure memory management of DOM objects is correct across language boundaries, it would provide an effective defense against these issues. Safe memory management across a combination of managed and unmanaged code is a tough problem, and Rust (and perhaps Swift…

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.

Re: Serious Chrome zero-day

#306

Post by krageon »

SamBam wrote: post #300
sciurus wrote: post #298

Earlier quoted context omitted.

"Chrome has probably invested > 1 billion dollars into their codebase at this point. Certainly >100million into security." Let's conservatively say Google pays 1,000 developers to work on Chrome, and on average those developers cost Google $300k each. That's $300 million a year just in payroll. Google has invested far more than a billion in Chrome by this point.

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.

Re: Serious Chrome zero-day

#307

Post by setr »

sureaboutthis wrote: post #288
pjmlp wrote: post #246

Earlier quoted context omitted.

Linux is another good example how C doesn't cut it, even among top developers. They have a very strict patch review process in place. They have kernel static analysers. The kernel has been adding security gates through the years. Yet 68% of 2018 CVE's were caused by memory corruption bugs, with the others ones left out being UB, numeric conversions, and very tiny fraction remaining of the logic error kind that are bo…

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.

A monopoly is naturally self-sustaining. It's absurd to think there couldn't possibly be a "better way", that C is somehow perfect in its niche (that all-encompassing niche, that once covered anything and everything that wasn't grabbed by perl); But major experience in developing OS's is with C.. the knowledge, experience, tooling, etc depends on C, because C already has complete and total dominance in the area.

It's difficult to consider working on OS's in not-C, because C owns the market and ecosystem, and everything revolves around it.

But that's certainly a different reason than the absurd imagination that it's impossible to produce a language with stronger guarantees on bug-prone programming tasks (there are many languages that do, some with GC, some with stricter typing, some with static lifetime tracking, and so it goes on). That our CS theorists are so utterly incompetent that they couldn't manage to come up with even a single useful improvement to the divine language, 50 years after the great wizard Thompson etched its wisdom into a core dump

Let's quit pretending that (continued) market dominance correlates to (continued) quality.

Re: Serious Chrome zero-day

#308

Post by qrbLPHiKpiux »

scrollaway wrote: post #231
qrbLPHiKpiux wrote: post #92

Earlier quoted context omitted.

Caveat: if something’s “free,” you’re the product. Google wants to pull as much metadata from you as possible. I don’t trust anyone who gives me something for free. I therefore limit how I use it.

Firefox is free as well. You're not making your point very well.

I know, but you can donate to them. Chrome, you can’t.

Re: Serious Chrome zero-day

#309

Post by pcwalton »

throwaway12iii wrote: post #247
pcwalton wrote: post #199

Earlier quoted context omitted.

> Both of those issues would exist regardless of the language chosen--D, Erlang, Java, Python, Rust, w'ever. Not necessarily. If the language provides a way to ensure memory management of DOM objects is correct across language boundaries, it would provide an effective defense against these issues. Safe memory management across a combination of managed and unmanaged code is a tough problem, and Rust (and perhaps Swift…

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.

Re: Serious Chrome zero-day

#310

Post by MivLives »

C4stor wrote: post #271
runn1ng wrote: post #261

Why is this blogspam with no information upvoted in the first place? Does anyone enjoy reading this?

The post was awful, but I hadn't heard of this exploit before, and I wasn't patched, so, thanks for that !

That and it has update instructions which makes it easier to link non technical people too.
Post reply on HN