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

81–90 of 159 posts

Re: Chrome 0-day exploit used in Operation WizardOpium

#81

Post by nicoburns »

lima wrote: post #78
nicoburns wrote: post #77

Earlier quoted context omitted.

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

In Rust code I audit, I typically have to jump through multiple layers of abstraction and cleverness, while Go code is straight forward and boring.

I guess it's a matter of preference. If something is abstracted, then you only have to audit it once (and often you can count on someone else having audited it). With Go code, everything is new and unique, so there are a lot more opportunities to introduce bugs.

Re: Chrome 0-day exploit used in Operation WizardOpium

#82

Post by dmos62 »

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.

Re: Chrome 0-day exploit used in Operation WizardOpium

#83

Post by rndgermandude »

cre-ker wrote: post #69
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.

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, as far as I know, most of the Go runtime is written in Go, it's not impossible, just a lot less likely.

Re: Chrome 0-day exploit used in Operation WizardOpium

#84

Post by ChrisCinelli »

Jyaif wrote: post #45

Funnily enough, looks like the vulnerability was introduced by a (korean?) samsung engineer. fix: https://chromium-review.googlesource.com/c/chromium/src/+/18... git blame: https://chromium.googlesource.com/chromium/src.git/+/e1fa6d4...

What a coincidence! =)

Re: Chrome 0-day exploit used in Operation WizardOpium

#85

Post by dmos62 »

sanbor wrote: post #59

This is why I started disabling js by default using ublock origin. I whitelist the websites that I'm interested in but at least I avoid a lots of exploits that requires js. This is in case if I'm unlucky and I land in one of those websites with malicious js. I discovered duckduckgo doesn't block websites as eagerly as Google and landed in a few tricky places.

If you want Google Search without Google, there's Startpage. It acts as a proxy between you and Google, protecting your privacy. I've been using it exclusively for maybe two years now. I am a bit upset at not supporting the more involved privacy-friendly projects, like DuckDuckGo or others (there are a quite a few); but, Startpage gives me the right mix of privacy, efficiency and social awareness at the moment.

Re: Chrome 0-day exploit used in Operation WizardOpium

#86

Post by roblabla »

m00dy wrote: post #61
MrBuddyCasino wrote: post #58

Earlier quoted context omitted.

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.

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

Re: Chrome 0-day exploit used in Operation WizardOpium

#87

Post by safercplusplus »

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.

Those interested can check out a (nascent) "borrow checker"[1] for enforcement of C++'s memory and data race safe subset.

[1] https://github.com/duneroadrunner/scpptool

Re: Chrome 0-day exploit used in Operation WizardOpium

#88

Post by bouncycastle »

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.

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 always come built in and every dev working on concurrent code should use one.

Re: Chrome 0-day exploit used in Operation WizardOpium

#89

Post by gok »

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.

Re: Chrome 0-day exploit used in Operation WizardOpium

#90

Post by hellcow »

dmos62 wrote: post #85
sanbor wrote: post #59

This is why I started disabling js by default using ublock origin. I whitelist the websites that I'm interested in but at least I avoid a lots of exploits that requires js. This is in case if I'm unlucky and I land in one of those websites with malicious js. I discovered duckduckgo doesn't block websites as eagerly as Google and landed in a few tricky places.

If you want Google Search without Google, there's Startpage. It acts as a proxy between you and Google, protecting your privacy. I've been using it exclusively for maybe two years now. I am a bit upset at not supporting the more involved privacy-friendly projects, like DuckDuckGo or others (there are a quite a few); but, Startpage gives me the right mix of privacy, efficiency and social awareness at the moment.

Startpage was recently acquired by an ad company.

https://www.reddit.com/r/privacy/comments/di5rn3/startpage_i...

Post reply on HN