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

131–140 of 159 posts

Re: Chrome 0-day exploit used in Operation WizardOpium

#131

Post by nicoburns »

Quekid5 wrote: post #113
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).

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.

Mutability / immutability is in the function signatures, and that goes a long way. It's not as good as an effect system of course. But along with global variables barely being a thing in Rust, it goes a long way to cutting out the common course of bugs.

Re: Chrome 0-day exploit used in Operation WizardOpium

#133

Post by staticassertion »

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 disagree. By having the browser implement these features we gain security. Chrome's sandbox is extremely powerful, and they can isolate and restrict all of those features you're describing very deliberately, in a way that a more generalized OS provided tool may not be able to.

Re: Chrome 0-day exploit used in Operation WizardOpium

#134

Post by staticassertion »

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.

Here you go: https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

What's even worse is that Go code is not (outside of Linux/ some distros) compiled with ASLR.

Re: Chrome 0-day exploit used in Operation WizardOpium

#135

Post by staticassertion »

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

Javascript is used to perform the exploit. The renderer, where the vulnerable code exists (I assume), is C++.

The problem with protecting a C++ codebase like a JS renderer is that the attacker has HUGE amounts of control. They can literally already execute arbitrary code in the renderer, making information leaks and other techniques much easier. ASLR was never intended to protect against an attacker with such a level of control.

Re: Chrome 0-day exploit used in Operation WizardOpium

#136

Post by psanford »

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.

Here's a blog post from Russ Cox (Go core team) explaining it: https://research.swtch.com/gorace

Re: Chrome 0-day exploit used in Operation WizardOpium

#138

Post by staticassertion »

svenfaw wrote: post #50
stinos wrote: post #43

Earlier quoted context omitted.

This wasn't literally the first one I think?

Far from it. Here's an older one this year: https://chromereleases.googleblog.com/2019/03/stable-channel...

"Far from it", as you link to literally the only other case.

Re: Chrome 0-day exploit used in Operation WizardOpium

#139

Post by dmix »

bureaucrat wrote: post #73
londons_explore wrote: post #17

The attack code wasn't in an advert, suggesting the Korean news organisation had either previously been attacked, or had an insider plant this code.

This attack was done by North Koreans. The site is a North Korean propaganda advertising site, which is visited a lot by South Korean researchers.

That would explain the strange/weak infrastructure and the economic targets in APAC.

Re: Chrome 0-day exploit used in Operation WizardOpium

#140

Post by dstaley »

ChrisSD wrote: post #74
dstaley wrote: post #6

I wonder if this exploit would be possible if Chrome was packaged using the UWP Desktop Bridge on Windows 10. I doubt the sandbox prevents UAF, but surely it would have prevented executing an EXE file.

Desktop Bridge applications aren't sandboxed.

Ah so it seems. The webpage for Desktop Bridge says that it features "no malware injection", so I took that to mean it was sandboxed.
Post reply on HN