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

71–80 of 159 posts

Re: Chrome 0-day exploit used in Operation WizardOpium

#71

Post by coleifer »

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…

Where did you see the reference to webaudio? Link to any other relevant details about the vulnerability, specifically?

Re: Chrome 0-day exploit used in Operation WizardOpium

#72

Post by cre-ker »

willtim wrote: post #68
zozbot234 wrote: post #66

Earlier quoted context omitted.

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

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 write and read. That's the cost of safety. For kernel or browser engine - that's the compromise people are willing to take. For other applications - better use something else.

Re: Chrome 0-day exploit used in Operation WizardOpium

#73

Post by bureaucrat »

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.

Re: Chrome 0-day exploit used in Operation WizardOpium

#74

Post by ChrisSD »

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.

Re: Chrome 0-day exploit used in Operation WizardOpium

#75

Post by dexen »

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.

Security bugs are unavoidable, Rust/Java or not. This calls for architectural defense in depth.

A lot of the exploits would be rendered harmless by employing well established technique of splitting one huge monolithic app into processes with limited capabilities and communicating via simple and narrow channels. Qmail[1] is a good example of such architecture. The architectural support is already present in common OSes.

--

https://en.wikipedia.org/wiki/Qmail

Re: Chrome 0-day exploit used in Operation WizardOpium

#76

Post by lima »

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.

On the other hand, Go code is a lot easier to audit.

The kind of logic bug that the Rust compiler prevents due to stronger typing is typically a crash in Go, not a security issue.

Re: Chrome 0-day exploit used in Operation WizardOpium

#77

Post by nicoburns »

lima wrote: post #76
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.

On the other hand, Go code is a lot easier to audit. The kind of logic bug that the Rust compiler prevents due to stronger typing is typically a crash in Go, not a security issue.

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

Re: Chrome 0-day exploit used in Operation WizardOpium

#78

Post by lima »

nicoburns wrote: post #77
lima wrote: post #76

Earlier quoted context omitted.

On the other hand, Go code is a lot easier to audit. The kind of logic bug that the Rust compiler prevents due to stronger typing is typically a crash in Go, not a security issue.

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.

Re: Chrome 0-day exploit used in Operation WizardOpium

#79

Post by altfredd »

Santosh83 wrote: post #24
tannhaeuser wrote: post #21

Earlier quoted context omitted.

Or, maybe downloading arbitrary code from the internet without even a same-origin check, and being able to dynamically construct executable JavaScript from downloaded binary data masked as image and then have a whole generation of developers depend on this model wasn't so good an idea after all.

It enables SaaS and makes economic sense and sadly the latter is the only thing that matters when it comes to mass human behaviour.

eval() has no economic purpose. It hasn't been removed by browsers purely because that would break backward compatibility.

Non-same origin Javascript does not have economic purpose either. I believe, that it will be completely eradicated from browsers within this century (if not in couple of decades).

Re: Chrome 0-day exploit used in Operation WizardOpium

#80

Post by willtim »

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

Earlier quoted context omitted.

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

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 correct concurrent software.

Post reply on HN