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

101–110 of 159 posts

Re: Chrome 0-day exploit used in Operation WizardOpium

#101

Post by Jyaif »

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.

> Not even Google can write safe C++.

Technically it was a samsung engineer that introduced the vuln.

Re: Chrome 0-day exploit used in Operation WizardOpium

#102

Post by saagarjha »

baybal2 wrote: post #100
est31 wrote: post #98

Earlier quoted context omitted.

wasm is only a new phenomenon and those APIs were designed without wasm in mind. Note that wasm is also slower and thus more resource (battery) consuming than a native C++ implementation. Also, Chrome is already adding audioworklets to WebAudio so it will become customizeable. Last but not least, browsers are at least a central place that can be patched. Compare this to a possible future where vulnerable wasm librari…

Long story short, WASM must be removed from browsers before it reaches wider adoption. And along with other completely unneeded APIs. Parties opposing that must be expelled from standard bodies. P.S. Just look at completely outrageous effort to push payment APIs into the browser and stuff they want to bundle along https://www.w3.org/2019/09/15-wpwg-minutes.html

No.

Re: Chrome 0-day exploit used in Operation WizardOpium

#103

Post by Thaxll »

nicoburns wrote: post #64
zozbot234 wrote: post #53

Earlier quoted context omitted.

> This is why C++ needs to be retired; and why we need to use safer languages. These problems can easily happen in a language like Go, unfortunately. Go is memory safe for sequential code, but that guarantee does not extend to in-process concurrency - Goroutines can access shared state without synchronization, and create memory unsafety.

But not in Rust. Go isn't exactly a bastion of safety. It's memory safe due to the GC, but it has a weak type system, so logic bugs are not well guarded against.

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.

Re: Chrome 0-day exploit used in Operation WizardOpium

#104

Post by saagarjha »

rndgermandude wrote: post #83
cre-ker wrote: post #69

Earlier quoted context omitted.

No they can't. UaF is impossible in memory safe languages like Go. Concurrency doesn't matter here. Only thing you would get is logical errors resulting in crashes or weird behavior.

Javascript, that the exploit uses, is a memory safe language too, at lest in theory... None of the languages around, that are in major production use, are really completely memory safe in practise. There is always a runtime lurking under it, most times a libc (not in Go tho, IIRC) and assortment of various libraries written in memory unsafe languages and always a kernel. While it's probably harder to exploit Go, as,…

Go depends on libc on certain platforms, such as macOS.

Re: Chrome 0-day exploit used in Operation WizardOpium

#105

Post by saagarjha »

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.

It would add significant limits on what an optimizer bug would allow an attacker to do, though.

Re: Chrome 0-day exploit used in Operation WizardOpium

#106

Post by saagarjha »

cjbprime wrote: post #46
lovelearning wrote: post #26

As I understand these RCEs (in general; perhaps not this particular one), a frequent root cause seems to be saving instruction pointer on the stack adjacent to untrustworthy data which may have propagated down the call chain. Are there no initiatives being attempted to change this convention? Like not save the IP on the stack? Perhaps at the CPU architecture level or at the compiler level?

There are already many modern mitigations present to defeat the kind of stack overflow control of the instruction pointer that you're imagining -- stack canaries, DEP, ASLR, NX, and others. Simply gaining control of the instruction pointer through a stack overflow as you describe stopped working a decade or so ago due to these mitigations.

DEP and NX are essentially the same thing, FYI.

Re: Chrome 0-day exploit used in Operation WizardOpium

#107

Post by pcwalton »

Thaxll wrote: post #103
nicoburns wrote: post #64

Earlier quoted context omitted.

But not in Rust. Go isn't exactly a bastion of safety. It's memory safe due to the GC, but it has a weak type system, so logic bugs are not well guarded against.

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.

Re: Chrome 0-day exploit used in Operation WizardOpium

#108

Post by pcwalton »

roblabla wrote: post #86
m00dy wrote: post #61

Earlier quoted context omitted.

is it possible to have arbitrary code execution in Go? I'm just curious.

Go has a few escape hatches like the unsafe package, but outside from that, I'm pretty sure arbexec isn't achievable in Go. The compiler inserts bounds check to prevent overflows, UAF isn't really achievable thanks to the GC, etc...

You can have UAF in Go due to slicing in the presence of concurrency: the implementation doesn't use multi-word atomics to update fat pointers like slices and interfaces. That said, it's not easy to do so.

Re: Chrome 0-day exploit used in Operation WizardOpium

#109

Post by SolarNet »

bouncycastle wrote: post #88
zozbot234 wrote: post #53

Earlier quoted context omitted.

> This is why C++ needs to be retired; and why we need to use safer languages. These problems can easily happen in a language like Go, unfortunately. Go is memory safe for sequential code, but that guarantee does not extend to in-process concurrency - Goroutines can access shared state without synchronization, and create memory unsafety.

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 in well written C++ code as google tends to do.

Re: Chrome 0-day exploit used in Operation WizardOpium

#110

Post by pcwalton »

willtim wrote: post #65
zozbot234 wrote: post #60

Earlier quoted context omitted.

A 'stale' read of atomic data may be fine (it wouldn't really be "unsynchronized" in that sense), but as soon as you're dealing with stuff that's not completely atomic in-hardware and need actual synchronization, there's a potential of breaking expected invariants and creating further unsafety as a consequence of that.

I agree a stale read is bad. And I am surprised that the Go designers have repeated many past mistakes. It is possible to design a concurrent high-level language that does not have such issues, despite the hardware. For example, if all communication is done via channels, then synchronisation can be automatically performed during channel read/write. For shared mutable state, Haskell's software transactional memory and…

You don't need to go that far. Go could have been memory-safe if slices were one word instead of three (like Java's arrays), and interfaces were one word instead of two (like Java's interfaces).
Post reply on HN