Google Publishes Exploit Code Threatening Millions of Chromium Users (arstechnica.com) 36
An anonymous reader quotes a report from Ars Technica: Google on Wednesday published exploit code for an unfixed vulnerability in its Chromium browser codebase that threatens millions of people using Chrome, Microsoft Edge, and virtually all other Chromium-based browsers. The proof-of-concept code exploits the Browser Fetch programming interface, a standard that allows long videos and other large files to be downloaded in the background. An attacker can use the exploit to create a connection for monitoring some aspects of a user's browser usage and as a proxy for viewing sites and launching denial-of-service attacks. Depending on the browser, the connections either reopen or remain open even after it or the device running it has rebooted.
The unfixed vulnerability can be exploited by any website a user visits. In effect, a compromise amounts to a limited backdoor that makes a device part of a limited botnet. The capabilities are limited to the same things a browser can do, such as visit malicious sites, provide anonymous proxy browsing by others, enable proxied DDoS attacks, and monitor user activity. Nonetheless, the exploit could allow an attacker to wrangle thousands, possibly millions, of devices into a network. Once a separate vulnerability becomes available, the attacker could use it to then compromise all those devices.
"The dangerous part here is that you can just have a lot of different browsers together that you can in the future run something on that you figure out," said Lyra Rebane, the independent researcher who discovered the vulnerability and privately reported it to Google in late 2022 in an interview. He said using the exploit code Google prematurely published would be "pretty easy," although scaling it to wrangle large numbers of devices into a single network would require more work. In the thread of Rebane's disclosure to Google, two developers said in separate responses that it was a "serious vulnerability." Its severity was rated S1, the second-highest classification.
Since its reporting 29 months ago, the vulnerability remained unknown except to Chromium developers. Then on Wednesday morning, it was published to the Chromium bug tracker. Rebane initially assumed the vulnerability was finally fixed. Shortly thereafter, he learned that, in fact, it remained unpatched. While Google removed the post, it remains available on archival sites, along with the exploit code. Google representatives didn't immediately respond to an email asking how and why it published the vulnerability and if or when a fix would become available. The exploit works by abusing Chromium's Browser Fetch API to open a service worker that remains persistently active. A malicious website can trigger it through JavaScript, creating a connection that can be used "for monitoring some aspects of a user's browser usage and as a proxy for viewing sites and launching denial-of-service attacks," reports Ars.
Depending on the browser, those connections "either reopen or remain open even after it or the device running it has rebooted," effectively turning the device into part of a "limited botnet."
The unfixed vulnerability can be exploited by any website a user visits. In effect, a compromise amounts to a limited backdoor that makes a device part of a limited botnet. The capabilities are limited to the same things a browser can do, such as visit malicious sites, provide anonymous proxy browsing by others, enable proxied DDoS attacks, and monitor user activity. Nonetheless, the exploit could allow an attacker to wrangle thousands, possibly millions, of devices into a network. Once a separate vulnerability becomes available, the attacker could use it to then compromise all those devices.
"The dangerous part here is that you can just have a lot of different browsers together that you can in the future run something on that you figure out," said Lyra Rebane, the independent researcher who discovered the vulnerability and privately reported it to Google in late 2022 in an interview. He said using the exploit code Google prematurely published would be "pretty easy," although scaling it to wrangle large numbers of devices into a single network would require more work. In the thread of Rebane's disclosure to Google, two developers said in separate responses that it was a "serious vulnerability." Its severity was rated S1, the second-highest classification.
Since its reporting 29 months ago, the vulnerability remained unknown except to Chromium developers. Then on Wednesday morning, it was published to the Chromium bug tracker. Rebane initially assumed the vulnerability was finally fixed. Shortly thereafter, he learned that, in fact, it remained unpatched. While Google removed the post, it remains available on archival sites, along with the exploit code. Google representatives didn't immediately respond to an email asking how and why it published the vulnerability and if or when a fix would become available. The exploit works by abusing Chromium's Browser Fetch API to open a service worker that remains persistently active. A malicious website can trigger it through JavaScript, creating a connection that can be used "for monitoring some aspects of a user's browser usage and as a proxy for viewing sites and launching denial-of-service attacks," reports Ars.
Depending on the browser, those connections "either reopen or remain open even after it or the device running it has rebooted," effectively turning the device into part of a "limited botnet."
Web APIs have become too complex and overreaching (Score:5, Insightful)
Re: Web APIs have become too complex and overreach (Score:2)
I'm still angry that the most secure browser ever, MS IE 5.5, in its infinite wisdom, decided to drop Gopher support.
29 months ago? (Score:5, Insightful)
I hope nobody's complaining that it got publicly disclosed because "they only had two and a half years to fix it but hadn't gotten around to it yet"
IMO, "responsible disclosure" taps out after six months. Anything that happens after that is entirely on the devs for not bothering to plug holes that they were privately notified about.
Re:29 months ago? (Score:5, Interesting)
Re: (Score:2)
This wasn't even the security researcher disclosing though. This was all on the Chromium folks fumbling in multiple ways.
I am guessing that the Chromium folk made the same presumption as the security researcher initially did, that the bug was already fixed years ago (two years for a S1, it *must* have gotten fixed a long time ago), so was just closing the issue. The egg on the face of the Chromium folk will take some time to wash off, and probably add in some new internal process to opening other bug reports.
Re:29 months ago? (Score:5, Informative)
The issue id is 40062121 [chromium.org] and the latest one is 515156127. So they weren't adding it, but just accidentally marked the a 4+ year old original S1 vuln as public.
Hard to find an explanation besides just being a very embarrassing oopsie daisy. Lucky the researcher was watching it and excited to show off their work. [infosec.exchange]
Re: (Score:3)
Fucking hell. What is the problem preventing this from being fixed?
Is it unfixable? no? THEN FIX IT.
Unacceptable incompetence.
Re: 29 months ago? (Score:2)
Re: (Score:2)
The summary says "late 2022" and "29 months ago", so some editor somewhere has made a mistake. 29 months ago would be late December 2023.
Right (Score:5, Informative)
>"vulnerability in its Chromium browser codebase that threatens millions of people using Chrome, Microsoft Edge, and virtually all other Chromium-based browsers."
Right. Pretty much all browsers except Firefox and Safari.
>"The dangerous part here is that you can just have a lot of different browsers together that you can in the future run something on that you figure out," said Lyra Rebane"
Right. What many of us have been saying for years. That there is very little actual browser diversity now and it is extremely dangerous. Dangerous not just for security, but also robust true standards, and even privacy. Safari is only Apple stuff; for multiplatform there are essentially only two "browsers" left now, Chrom* and Firefox-ish. And Firefox is struggling, most of which isn't Mozilla's fault and bashed often based on inaccurate information.
Re: (Score:2)
I think it's easy to recognize this problem, but a lot harder to solve it.
Developing a modern browser is a ridiculous amount of work. Too much to be developed out of free time of volunteers. Which comes back to open source competitors that have perennial problems with funding or direction and commercial competitors facing a huge barrier to entry against multi-billion dollar giants. (Noting that several of those giants even have had rulings against them for abusing their monopoly position.)
Re:Right (Score:5, Insightful)
Agreed that there is no easy solution, especially at this point. All I can do is encourage people to support, use, and test against the only non-Chrom* multiplatform browser left (Firefox or Firefox-based). At a time when we desperately need MORE than just two browsers, we are at great risk of it essentially becoming just one.
Every time some site "recommends Chrome" or tech support says "we only test on Chrome" or "we only support Chrome [or whatever Chrome variant]" it is another nail in our collective coffin. I want Chrome and its children to prosper, but not in a vacuum, not unchallenged, not without usable alternatives.
Re: (Score:2)
> Every time some site "recommends Chrome" or tech support says "we only test on Chrome" or "we only support Chrome [or whatever Chrome variant]" it is another nail in our collective coffin. I want Chrome and its children to prosper, but not in a vacuum, not unchallenged, not without usable alternatives.
Chrome is the IE6 of today.
Re: (Score:1)
I think it's easy to recognize this problem, but a lot harder to solve it.
Developing a modern browser is a ridiculous amount of work. Too much to be developed out of free time of volunteers. Which comes back to open source competitors that have perennial problems with funding or direction and commercial competitors facing a huge barrier to entry against multi-billion dollar giants. (Noting that several of those giants even have had rulings against them for abusing their monopoly position.)
Yep. Modern browsers have to be ridiculously complex.
Because modern HTML, JS, and CSS are ridiculously complex. They do ridiculously cool stuff, so I'm not saying that they shouldn't be. But they are, and therefore the browsers have to be as well.
Re: (Score:2)
Serious question: what can html, js and css do today that they couldn't 10 or even 15 years ago, at least for the user? I think the only cool, new, user-friendly innovation I have seen in that timeframe is passkeys. Granted, I don't run across random sites like I used to.
Re: (Score:2)
Re:Right (Score:5, Informative)
WebAssembly is technically an answer as it first appeared about nine years ago, but it was widely discussed before that. WebRTC dates back to 2011. Can't find a date on flexboxes but I see blog articles from 2013(!) on that. CSS grid is more recent, as are CSS variables - long after SCSS became standard because everyone got fed up of waiting - but I agree with the GP, is any of the actually more recent stuff actually necessary?
Of all of the above, WebAssembly is kinda useful, (and WebRTC fills a hole but is pretty old now.) The rest? They're just different ways to achieve things you could already achieve.
I think there's a case for arguing the core web standards went wrong at some point in the late 1990s, and became more and more bloated without adding significant functionality with each generation. A web browser has roughly a subset of the functionality as Microsoft Word - it's a rich text viewer with scripting and network connectivity. Yet Microsoft Word requires a maximum of tens of megabytes of RAM per document. And arguably Word is more powerful.
Maybe it's time we reset and started again. Freeze the standard for HTML, and create a new format (WPDL - web page description language?) that's lighter and less confusing to render. Browsers might even start being consistent if we did that.
Re: (Score:2)
web assembly is useful, but not for a browser. WebAssembly is a part for an application platform and there is nothing a usual website should do with that. Why would they want it? So I can't see the source of the website? So they can do numerical computations while I look at the site? I see what cool things people do with it, but none of these things should run when I read Slashdot. Or visit Google. Or read any other site. If I want to run a cool visualization, the browser can ask me "Open WebAssembly Viewer
Re: (Score:3)
The modern browser was a mistake and google has not been a good custodian of it. Browsers should probably not have any of the components being used in this exploit in the first place.
Re: (Score:3)
Re: (Score:3)
Depends what you mean by "modern browser." The OP is complaining about the lack of diversity in browsers, not the lack of diversity in browser engines. You can write a browser using your engine of choice, i.e. not Chrome's Blink, in a few hours. It will support all the CSS, Javascript, yadda yadda. There are even some projects around that will let you build an app around whatever browser engine happens to be available on the system. That app could b
Re: (Score:2)
Chrome, Microsoft Edge, and virtually all other Chromium-based browsers."
Safari is only Apple stuff; for multiplatform there are essentially only two "browsers" left now, Chrom* and Firefox-ish.
I have a hard time reading talking about classes of "browsers" not really meaning or including the engines. So then I didn't jump into the weeds about engines in my comment (and if we want to get into the weeds, Blink isn't the Chrome JS engine that's V8). But yes, the engines are of course the harder part.
Re: (Score:2)
>"The OP is complaining about the lack of diversity in browsers, not the lack of diversity in browser engines."
Incorrect. I was specifically talking about browser engines, which is the core of a browser and what sets the standards. For multiplatform, there are essentially only two (as I described) in significant use. There are lots of browsers, almost all of them are Chrom*. Adding yet more Chrom* browsers doesn't help much with standards, controlling Google's power, or security.
Re: (Score:3)
Webkit (what Safari uses) is open source. It runs on Windows, Linux and a bunch of other UNIX-like OSs. It's also used by the browsers in Playstations, Nintendos, and Kindles. If you're using Linux you can use Gnome's default browser, which is Webkit. If you're using Windows your options are limited, but you could try the Orion port.
Re: (Score:2)
>"Webkit (what Safari uses) is open source. It runs on Windows, Linux and a bunch of other UNIX-like OSs."
Correct, but Safari is only Apple stuff, like I said. You can take all other browsers based on Webkit and it wouldn't amount to even a tiniest bit of actual browser activity on the web. So insignificant that it doesn't help with pushback or effective diversity. Firefox is now a small fraction of activity now, but even that would be thousands of times more activity than non-Safari Webkit.
Another point for Firefox and against Google (Score:5, Interesting)
Re:Another point for Firefox and against Google (Score:5, Insightful)
Thank goodness for the NoScript plugin in Firefox.
It takes some diligence to selectively whitelist each site; totally worth it.
Re: (Score:2)
Background fetch. Such a "useful" concept (Score:3, Insightful)
Simple solution (Score:1)
I'll just have AI write me a new browser every couple of days. By the time the numbers of bugs are found I'll be on AI browser #9. If the backend of every program was a spaghetti mess that fit the API's these exploits wouldn't be possible.
Service Workers are the problem (Score:2)
I think it is very intransparent how they work. I had sites that were permanently broken until I got into the developer tools and uninstalled a server worker, what requires you to open the devtools and then find the right tab, find the right list of things the website stores and then know you want to uninstall that thing. How should average joe manage to do that? And why aren't I asked before such a thing is installed? Everything that does not stop running when I close the site and everything that is not de