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

191–200 of 377 posts

Re: Serious Chrome zero-day

#191

Post by IX-103 »

naikrovek wrote: post #126
kllrnohj wrote: post #117

Earlier quoted context omitted.

Back when Chrome was getting started there were no memory safe languages that did not come with huge downsides. Now one could argue for Rust, but let's not pretend that C++ was a bad choice. C++ was the overwhelmingly best choice at the time.

That doesn't mean that they (or anyone) should still be using it. The choice of language 15 years ago has nothing to do with the languages that could be in use today on the same project. Rust has `unsafe` all over the place; it's no more safe if you use that keyword to do the same things that are done in C++. Get more compiler people on Go and it will be even faster than it is now (really fast), and Go is written in…

Sorry. Until Go gets its head out of its ass and gets proper generics Go will still be painful to use and slow. Not to mention with all the extra code complexity from writing everything with interface{}{} and reflection there are bound to be plenty of exploitable vulnerabilities. I honestly think it is worse than pre-generic Java because switching over the type of the variable is encouraged. Most sane type-checked languages kinda expect you to know what type you're working with at compile time.

Re: Serious Chrome zero-day

#193

Post by 13of40 »

pcwalton wrote: post #135
bla3 wrote: post #124

Earlier quoted context omitted.

If there's ever a project as large as Chrome written in a non-C++ language, I guarantee you it will have these bugs as well -- due to use of `unsafe`, or bugs in the compiler, or what have you.

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

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.

Re: Serious Chrome zero-day

#194

Post by ciphergoth »

ru999gol wrote: post #104
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…

if you think C or C++ programmers are ever going to admit this, you must never have met one

What is a C/C++ programmer? I've written fairly large amounts of C/C++ over the course of my career and I continue to do so. I totally concur with this and am eager to see Rust take its place over time.

Re: Serious Chrome zero-day

#195

Post by euske »

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…

I think it's a time that we should get rid of this notion of "perfectly safe code in the perfect world". It might be possible if the code doesn't change for million years, but that's not how the world works - things keep changing, the specs, the requirements and the users. Bugs are created every day. It's not about safety as a static property, but it is about the safety in an ever-changing world. As Bruce Schneier put it, it's a process. And yes, C++ might be bad for it, but that's only a part of the whole picture. We should look at the process rather then the code itself.

Re: Serious Chrome zero-day

#196

Post by xfs »

saagarjha wrote: post #8
apendleton wrote: post #2

This is a blog post that seems to just be reporting on this tweet: https://twitter.com/justinschuh/status/1103087046661267456 which in turn is referencing this new release from this past Friday: https://chromereleases.googleblog.com/2019/03/stable-channel... which seems to have been motivated by "CVE-2019-5786: Use-after-free in FileReader. Reported by Clement Lecigne of Google's Threat Analysis Group on 2019-02-27".…

From the code referenced, it seems like this might be the commit that fixes this issue: https://github.com/chromium/chromium/commit/ba9748e78ec7e9c0...

This interface raw_data_->ToArrayBuffer() sometimes returns a copy of its internal buffer and sometimes returns a smart pointer to its internal buffer. See https://github.com/chromium/chromium/blob/ba9748e78ec7e9c0d5...

But DOMArrayBuffer::Create() here takes ownership of the memory from ToArrayBuffer(), so in the latter case of a smart pointer, the internal buffer of raw_data_ is immediately invalidated and its value becomes undefined after creating the DOMArrayBuffer. This is fine if file loading is finished at this point because raw_data_ is reset to nullptr, but if the load is partial, then the undefined value in raw_data_ will be reused to create another DOMArrayBuffer which is then accessible in javascript. Hence the use after free.

I'll attribute the root cause of this bug to unclear memory ownership passing in interface design.

Re: Serious Chrome zero-day

#197

Post by pcwalton »

13of40 wrote: post #193
pcwalton wrote: post #135

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. †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 t…

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?

Re: Serious Chrome zero-day

#199

Post by pcwalton »

wahern wrote: post #181
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…

Without knowing more there's zero reason to blame C++. This looks like it implicates (a) a questionable but quite intentional performance optimization and (b) possibly a V8 GC race or otherwise an issue with reference consistency between the C++ code and the JIT'd JavaScript runtime. Both of those issues would exist regardless of the language chosen--D, Erlang, Java, Python, Rust, w'ever. Remove V8's JIT and GC and t…

> 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?) are the only languages I know of that have any attempts to solve it. It requires both language and library support. There are several competing solutions in the community: luster [1], shifgrethor [2], and josephine [3] come to mind. All of them allow this kind of code to be implemented safely.

[1]: https://github.com/kyren/luster

[2]: https://github.com/withoutboats/shifgrethor

[3]: https://github.com/asajeffrey/josephine

Re: Serious Chrome zero-day

#200

Post by bestnameever »

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.

It was helpful enough for me to look for more information.

https://twitter.com/justinschuh/status/1103087046661267456

Post reply on HN