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

Chrome 0-day exploit used in Operation WizardOpium

securelist.com

Post reply on HN
Print view View original

111–120 of 159 posts

Re: Chrome 0-day exploit used in Operation WizardOpium

#111

Post by pcwalton »

gok wrote: post #89
willtim wrote: post #44

> "The exploit used a race condition bug between two threads due to missing proper synchronization between them. It gives an attacker a Use-After-Free (UaF) condition that is very dangerous because it can lead to code execution scenarios" This is why C++ needs to be retired; and why we need to use safer languages. Not even Google can write safe C++. Thankfully Mozilla have already realised this.

Web browsers are unfortunately a case where even memory safe-ish languages are really an incomplete solution. Writing a JavaScript JIT in Rust won't prevent optimizer bugs.

While this is true, a lot of exploitable bugs attributed to the JS engines are actually in implementations of built-in methods (String.split, Array.join, etc.). These can benefit from memory-safe languages.

Occasionally you do just end up with straight-up exploitable optimizer bugs, though. The literature has some powerful techniques to let us get rid of those too over time, but it's not as simple as rewrite-it-in-Rust. One thing that might help is simple layering: if the JIT could compile to something like wasm as an intermediate target, then you would have an extra layer of defense against optimizer bugs. This is something that's been talked about, but I don't know if anyone has seriously looked into how practical it is.

Re: Chrome 0-day exploit used in Operation WizardOpium

#112

Post by Thaxll »

pcwalton wrote: post #107
Thaxll wrote: post #103

Earlier quoted context omitted.

Rust is not safer than Go, people thinking otherwise misunderstand borrow checker vs GC. Furthermore you're talking about memory safety vs business logic bugs, two different things.

Go is not memory-safe in the presence of concurrency. Interfaces and slices (i.e. fat pointers) are not written atomically, which can cause undefined behavior. I haven't heard of this causing a problem in practice, though.

I never heard undefined behavior in Go like your example. This would means that not synchronizing a slice would lead to memory corruption.

Please give us a code example.

Re: Chrome 0-day exploit used in Operation WizardOpium

#113

Post by Quekid5 »

nicoburns wrote: post #77
lima wrote: post #76

Earlier quoted context omitted.

On the other hand, Go code is a lot easier to audit. The kind of logic bug that the Rust compiler prevents due to stronger typing is typically a crash in Go, not a security issue.

Disagree on this. In Rust I can read most of the information I need to know straight from the function signatures. In Go I have to go through every line of code (and there are often a lot of lines due to Go's lack of expressive power).

Not to be argumentative, honestly, that sound pretty laughable if you don't have an equivalent of an algebraic effect system (or similar).

A "function" in Rust can do a whole bunch of stuff that is not signaled by its type signature.

Re: Chrome 0-day exploit used in Operation WizardOpium

#114

Post by Avamander »

CoolGuySteve wrote: post #91
jbk wrote: post #70

I know this is a bit a pet peeve of mine, (and not a very popular opinion) but I think the browsers are doing too much, and WebAudio is a very good example of that. Instead of standardizing something low-level to input/output audio and query the hardware, like an OS; it standardizes soooo many things and filters, including downmixers, panners, quadfilters and Convolution (for reverbs); which is where the issue is in…

MacOS’s media framework uses sandboxes so even if media gets exploited it wouldn’t be able to write to disk or launch processes like in this example. There’s really no excuses in this case for WebAudio, of all things, to be able to write to disk. And it’s dubious that Chrome should be able to launch any processes outside of the few specific child jobs it needs for process isolation.

We need something like `pledge` from BSD available across all platforms. Would mitigate quite a few of these exploits. Though, shipping good SELinux policy could solve the problem as well, maybe even better.

Re: Chrome 0-day exploit used in Operation WizardOpium

#115

Post by Thaxll »

SolarNet wrote: post #109
bouncycastle wrote: post #88

Earlier quoted context omitted.

My bullshit detector is at 3.6 Go has a garbage collector (i.e memory safety) & race detection tooling built in. https://golang.org/doc/articles/race_detector.html Even if a race condition bug does sneak in, it won't be as catastrophic as C/C++. Writing concurrent code is hard in any language. There's no magic bullet & Go or Rust are not immune to concurrency bugs. If anything, tools like the race detector should alw…

GC does not provide memory safety at a system level, it has the same issues as C++ in poorly programmed code once compiled. Also C++ has "memory safety" idioms similar to garbage collection through reference counting and RAII. Google has a C++ race detector based on the Go one and it did not detect this issue (or was ignored). Neither of those things you listed reduce the severity of the bug, and both are available i…

What do you mean? If you don't use unsafe package you can't have the same problem as C/C++ so it is memory safe. The bug in Chrome can't happen in Go without unsafe usage.

Re: Chrome 0-day exploit used in Operation WizardOpium

#116

Post by SolarNet »

Thaxll wrote: post #115
SolarNet wrote: post #109

Earlier quoted context omitted.

GC does not provide memory safety at a system level, it has the same issues as C++ in poorly programmed code once compiled. Also C++ has "memory safety" idioms similar to garbage collection through reference counting and RAII. Google has a C++ race detector based on the Go one and it did not detect this issue (or was ignored). Neither of those things you listed reduce the severity of the bug, and both are available i…

What do you mean? If you don't use unsafe package you can't have the same problem as C/C++ so it is memory safe. The bug in Chrome can't happen in Go without unsafe usage.

That is categorically not true.

Go compiles down to machine code, it has a stack and heap, it has structures on that stack and heap, and it has data races; those are all of the required components for a use after free. You can have data races compiled by the stock go compiler without the use of unsafe (also, why have race detector tooling if this is false?). It would probably be easier to exploit than here even because one wouldn't even need to bother with the ASLR pointer exfiltration they had to do here.

It may be harder to write exploitable code, but memory safety does not guarantee runtime memory safety. Especially in the face of concurrency.

Re: Chrome 0-day exploit used in Operation WizardOpium

#117

Post by skybrian »

Thaxll wrote: post #112
pcwalton wrote: post #107

Earlier quoted context omitted.

Go is not memory-safe in the presence of concurrency. Interfaces and slices (i.e. fat pointers) are not written atomically, which can cause undefined behavior. I haven't heard of this causing a problem in practice, though.

I never heard undefined behavior in Go like your example. This would means that not synchronizing a slice would lead to memory corruption. Please give us a code example.

Slice values are normally copied so it's not an issue. The slice would need to be stored in a global or a struct's field and then changed while some other goroutine is reading it.

(I haven't seen this happen, though.)

Post reply on HN