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

121–130 of 159 posts

Re: Chrome 0-day exploit used in Operation WizardOpium

#121

Post by pjc50 »

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

Those are two genuinely useful things, without the hardware API issues of the others.

Re: Chrome 0-day exploit used in Operation WizardOpium

#122

Post by cle »

willtim wrote: post #80
cre-ker wrote: post #72

Earlier quoted context omitted.

Go is actually one of the best in terms of design. Not every language has to be so complex. Go is easy to use and that's the point. Concurrency in it is best in class in many regards and that's what allowed the language to pretty much became THE language for backend, infrastructure and other web related things. Rust is in completely different spectrum and doesn't compete with Go. It's much more complex, harder to wri…

> Go is actually one of the best in terms of design. I respectfully disagree. Go's primary goal was to be (superficially) easy to use and familiar. Because of this, it fails to tackle the big issue with doing concurrency in most prior mainstream languages. Go has mutable state deeply baked into the language and makes it difficult to work with immutable data. Go is not necessarily easy to use if ones goal is to build…

Go's call-by-value semantics give you similar benefits. Just different tradeoffs (because there are downsides to immutable data structures).

My understanding of Go's design aesthetic is that it prefers to be explicit about things that could impact performance, which is probably why it prefers simple data structures with explicit synchronization.

Re: Chrome 0-day exploit used in Operation WizardOpium

#123

Post by cwzwarich »

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.

Are all Go fat pointers two words? If so, it would be pretty trivial to make them atomic on AArch64 using LDP/STP.

Re: Chrome 0-day exploit used in Operation WizardOpium

#124

Post by csande17 »

dmos62 wrote: post #82
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…

It's not just you. Browsers are systems-within-systems. They're gigantic, illustrated by the fact that the number of implementations that are well maintained can be counted on one hand. A lot of people take issue with that.

The Web platform is now so gigantic and complex that even Microsoft has decided it's impossible to write a browser!

Re: Chrome 0-day exploit used in Operation WizardOpium

#125

Post by pcwalton »

cwzwarich wrote: post #123
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.

Are all Go fat pointers two words? If so, it would be pretty trivial to make them atomic on AArch64 using LDP/STP.

Unfortunately slices are 3 words. (Besides, AArch64 isn't a common target for Go. On x86 you'd need cmpxchg16b or something.)

Re: Chrome 0-day exploit used in Operation WizardOpium

#126

Post by pcwalton »

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.

Yes, not synchronizing a slice can lead to memory corruption in Go.

Re: Chrome 0-day exploit used in Operation WizardOpium

#127

Post by threatofrain »

csande17 wrote: post #124
dmos62 wrote: post #82

Earlier quoted context omitted.

It's not just you. Browsers are systems-within-systems. They're gigantic, illustrated by the fact that the number of implementations that are well maintained can be counted on one hand. A lot of people take issue with that.

The Web platform is now so gigantic and complex that even Microsoft has decided it's impossible to write a browser!

Or Microsoft did a back of the napkin calculation and realised that the potential increase in user base for Microsoft products wasn’t worth the money.

Their users are already on Windows and Microsoft already has telemetry on them. And we’re talking about the browser guts and not the surface, which is where most of UX lives. But none of this means that Microsoft is browser incompetent.

Re: Chrome 0-day exploit used in Operation WizardOpium

#128

Post by tziki »

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…

I completely disagree. I think we've already seen with the JS-framework-of-the-day culture, flash, java applets and whatnot what happens when a browser doesn't provide the right level of abstraction for the developers. The developer tools are still years behind what developers need and if the browser doesn't provide them, a million npm dependencies will.

Re: Chrome 0-day exploit used in Operation WizardOpium

#129

Post by unlinked_dll »

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…

The issue is that a lot of the use cases for the processes you mention have soft real time requirements where GC pauses are unacceptable, and the underlying OS's have differing world views when it comes to dealing with audio (even on the same OS, there may be different driver APIs with fundamentally different approaches to audio I/O!).

So having a simple audio API + ability to do pro-audio like things in JS is not really possible in a browser. They have to expose a complex framework with a nuanced API to the underlying engine to make some of this stuff even possible in a web browser.

Re: Chrome 0-day exploit used in Operation WizardOpium

#130

Post by bouncycastle »

SolarNet wrote: post #116
Thaxll wrote: post #115

Earlier quoted context omitted.

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

The race condition exploits you're thinking of are not trivial and need specific code to pull off, unlikely to be a mistake like in C/C++. You just don't find them in normal Go programs.

Source (scroll down to the conclusion section): https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

Post reply on HN