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

61–70 of 159 posts

Re: Chrome 0-day exploit used in Operation WizardOpium

#61

Post by m00dy »

MrBuddyCasino wrote: post #58
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.

Go isn’t really a C++ replacement. I‘m not sure if that solves this particular issue, Rust is provably free of data races (excluding unsafe).

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

Re: Chrome 0-day exploit used in Operation WizardOpium

#62

Post by sfifs »

anovikov wrote: post #9

Tragedy of our generation is that people who are so smart and determined to find and exploit these vulnerabilities, can't find better uses for their talents.

Well the smartest talents of the previous generations built and exploded hundreds of nuclear weapons including a couple on innocent civilians, created ICBMs that can destroy civilization in a few minutes and created situations that brought the world to a brink several times, drove a massive population explosion anda fossil fuel consumption binge that may yet destroy civilization.

So I definitely think the smartest of more recent generations who are employing their skills in these software hacks and ad tracking are perhaps saintly in comparison :-)

Re: Chrome 0-day exploit used in Operation WizardOpium

#64

Post by nicoburns »

zozbot234 wrote: post #53
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.

> 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.

Re: Chrome 0-day exploit used in Operation WizardOpium

#65

Post by willtim »

zozbot234 wrote: post #60
willtim wrote: post #55

Earlier quoted context omitted.

What do you mean by memory unsafety? A stale read would be bad, but wouldn't lead to arbitrary code execution.

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 Erlang's Mnesia are both excellent examples of safely dealing with it.

Re: Chrome 0-day exploit used in Operation WizardOpium

#66

Post by zozbot234 »

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…

The issue wrt. Go is not with communication via channels in and of itself, but rather with using channels to share pointers to in-memory data. This is idiomatic in Go, people do it all the time even though it's what introduces unsafety.

Re: Chrome 0-day exploit used in Operation WizardOpium

#67

Post by zozbot234 »

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.

> It's memory safe due to the GC

That gets debatable as soon as you start using concurrency, like I said. There are idiomatic patterns in concurrent Go that are very much not safe.

Re: Chrome 0-day exploit used in Operation WizardOpium

#68

Post by willtim »

zozbot234 wrote: post #66
willtim wrote: post #65

Earlier quoted context omitted.

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…

The issue wrt. Go is not with communication via channels in and of itself, but rather with using channels to share pointers to in-memory data. This is idiomatic in Go, people do it all the time even though it's what introduces unsafety.

Yes, but my point is that it's a flaw in the language to allow this. Not all high-level languages share Go's problems. However, even Go would be a huge safety improvement over C++.

Re: Chrome 0-day exploit used in Operation WizardOpium

#69

Post by cre-ker »

zozbot234 wrote: post #53
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.

> 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.

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.

Re: Chrome 0-day exploit used in Operation WizardOpium

#70

Post by jbk »

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 this exploit.

The resulting complexity is huge, almost impossible to implement correctly in a cross-browser way, and a lot more code in C/C++ is written.

I do advocate simpler APIs for audio, low-level, and let JS or Wasm do the filtering, using the JS sandboxing model.

And, of course, this does not apply only to WebAudio, but I think WebAudio is a good symptom.

Post reply on HN