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

91–100 of 159 posts

Re: Chrome 0-day exploit used in Operation WizardOpium

#91

Post by CoolGuySteve »

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…

MacOS’s media framework uses sandboxes so even if media gets exploited it wouldn’t be able to write to disk or launch processes like in this example.

There’s really no excuses in this case for WebAudio, of all things, to be able to write to disk. And it’s dubious that Chrome should be able to launch any processes outside of the few specific child jobs it needs for process isolation.

Re: Chrome 0-day exploit used in Operation WizardOpium

#92

Post by baybal2 »

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 wholly agree with you. Somebody must push back on companies trying to push useless APIs

Re: Chrome 0-day exploit used in Operation WizardOpium

#94

Post by baybal2 »

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

Indeed, the first google search gives his Linkedin in the first position

Re: Chrome 0-day exploit used in Operation WizardOpium

#95

Post by dmos62 »

hellcow wrote: post #90
dmos62 wrote: post #85

Earlier quoted context omitted.

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

Wow. Thanks for the heads up.

Re: Chrome 0-day exploit used in Operation WizardOpium

#96

Post by throw55443h »

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 bought by an ad company. Better not use it.

https://news.ycombinator.com/item?id=21371577

Re: Chrome 0-day exploit used in Operation WizardOpium

#98

Post by est31 »

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…

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 libraries are being used in web apps, allowing third parties to run cross site wasm based exploits. Websites can't even switch off sms based 2fA, would you expect them to keep their wasm libraries up to date?

Re: Chrome 0-day exploit used in Operation WizardOpium

#99

Post by baybal2 »

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.

> can't find better uses for their talents.

Why would they. People who break DRMs for fun and profit look with disdain at their whitehat counterparts.

Same with ad fraud. People in that particular business take pride at being able to fool boatload of best and brightest computer scientists who work at bot detection

As for people in good old browser exploit scene, I think they have good time laughing at vain efforts, and ineptness of their counterparts too

I think people are wrong thinking of it as a money thing

Re: Chrome 0-day exploit used in Operation WizardOpium

#100

Post by baybal2 »

est31 wrote: post #98
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…

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

Post reply on HN