What’s The Deal With Chromium On Linux? Google At Odds With Package Maintainers

Linux users are more likely than most to be familiar with Chromium, Google’s the free and open source web project that serves as the basis for their wildly popular Chrome. Since the project’s inception over a decade ago, users have been able to compile the BSD licensed code into a browser that’s almost the same as the closed-source Chrome. As such, most distributions offer their own package for the browser and some even include it in the base install. Unfortunately, that may be changing soon.

A post made earlier this month to the official Chromium Blog explained that an audit had determined “third-party Chromium based browsers” were using APIs that were intended only for Google’s internal use. In response, any browser attempting to access features such as Chrome Sync with an unofficial API key would be prevented from doing so after March 15th.

To the average Chromium user, this doesn’t sound like much of a problem. In fact, you might even assume it doesn’t apply to you. The language used in the post makes it sound like Google is referring to browsers which are spun off of the Chromium codebase, and at least in part, they are. But the search giant is also using this opportunity to codify their belief that the only official Chromium builds are the ones that they provide themselves. With that simple change, anyone using a distribution-specific build of Chromium just became persona non grata.

Unhappy with the idea of giving users a semi-functional browser, the Chromium maintainers for several distributions such as Arch Linux and Fedora have said they’re considering pulling the package from their respective repositories altogether. With a Google representative confirming the change is coming regardless of community feedback, it seems likely more distributions will follow suit.

Continue reading “What’s The Deal With Chromium On Linux? Google At Odds With Package Maintainers”

This Week In Security: Discord, Chromium, And WordPress Forced Updates

[Masato Kinugawa] found a series of bugs that, when strung together, allowed remote code execution in the Discord desktop app. Discord’s desktop application is an Electron powered app, meaning it’s a web page rendered on a bundled light-weight browser. Building your desktop apps on JavaScript certainly makes life easier for developers, but it also means that you inherit all the problems from running a browser and JS. There’s a joke in there about finally achieving full-stack JavaScript.

The big security problem with Electron is that a simple Cross Site Scripting (XSS) bug is suddenly running in the context of the desktop, instead of the browser. Yes, there is a sandboxing option, but that has to be manually enabled.

And that brings us to the first bug. Neither the sandbox nor the contextIsolation options were set, and so both defaulted to false. What does this setting allow an attacker to do? Because the front-end and back-end JavaScript runs in the same context, it’s possible for an XSS attack to override JS functions. If those functions are then called by the back-end, they have full access to Node.js functions, including exec(), at which point the escape is complete.

Now that we know how to escape Electron’s web browser, what can we use for an XSS attack? The answer is automatic iframe embeds. For an example, just take a look at the exploit demo below. On the back-end, all I have to do is paste in the YouTube link, and the WordPress editor does its magic, automatically embedding the video in an iframe. Discord does the same thing for a handful of different services, one being Sketchfab.

This brings us to vulnerability #2. Sketchfab embeds have an XSS vulnerability. A specially crafted sketchfab file can run some JS whenever a user interacts with the embedded player, which can be shoehorned into discord. We’re almost there, but there is still a problem remaining. This code is running in the context of an iframe, not the primary thread, so we still can’t override functions for a full escape. To actually get a full RCE, we need to trigger a navigation to a malicious URL in the primary pageview, and not just the iframe. There’s already code to prevent an iframe from redirecting the top page, so this RCE is a bust, right?

Enter bug #3. If the top page and the iframe are on different domains, the code preventing navigation never fires. In this case, JavaScript running in an iframe can redirect the top page to a malicious site, which can then override core JS functions, leading to a full escape to RCE.

It’s a very clever chaining of vulnerabilities, from the Discord app, to an XSS in Sketchfab, to a bug within Electron itself. While this particular example required interacting with the embedded iframe, it’s quite possible that another vulnerable service has an XSS bug that doesn’t require interaction. In any case, if you use Discord on the desktop, make sure the app is up to date. And then, enjoy the demo of the attack, embedded below.

Continue reading “This Week In Security: Discord, Chromium, And WordPress Forced Updates”

The Google Chrome Dinosaur Game, In Real Life

[Ryan] wanted to hack the Google Chrome Dinosaur Game so he could control the dinosaur with his own movements. The game only requires two keyboard presses (up and down arrow keys), so controlling the game with the Arduino Keyboard library only requires a few simple function calls.

He uses the Arduino MKR board in his build, but notes any number of other boards would work as well. A force sensor detects his jumps and a stretch sensor detects him ducking. Both the stretch and force sensors are resistive transducers, so two simple voltage divider circuits (one for each sensor) are needed to convert changes in force to a voltage. You may need to adjust the sensor threshold to ensure the code responds to your movements, but [Ryan] makes that pretty easy to do in software as both thresholds are stored as global variables.

It’s a pretty simple hack, but could make for some good socially-distanced fun. What other hackable Google Chrome extensions do you like?

Continue reading “The Google Chrome Dinosaur Game, In Real Life”

Copy And Paste Deemed Insecure

Back when Windows NT was king, Microsoft was able to claim that it met the strict “Orange Book” C2 security certification. The catch? Don’t install networking and remove the floppy drives. ¬†Turns out most of the things you want to do with your computer are the very things that are a security risk. Even copy and paste.

[Michal Benkowki] has a good summary of his research which boils down to the following attack scenario:

  1. Visit a malicious site.
  2. Copy something to the clipboard which allows the site to put in a dangerous payload.
  3. Visit another site with a browser-based visual editor (e.g., Gmail or WordPress)
  4. Paste the clipboard into the editor.

Continue reading “Copy And Paste Deemed Insecure”

Maxing Out Browser Tabs With 2TB Of Memory

Tabbed browsing was a gamechanger, allowing users to effectively browse multiple websites at once without losing context. It proved a better solution than using multiple windows, and was an efficiency boon celebrated by all. Many of us are tab fiends, opening great numbers at a time as a habitual part of our workflow. [Linus] decided to find out just how many he could open on a system armed with a full 2TB of RAM.

As may be obvious, setting up a system with 2TB of RAM is no mean feat. Special server-grade RAM modules were sourced, packing 128GB of RAM each, set up for ECC operation. Packing out 16 slots, there’s a performance penalty to addressing so much RAM with a single CPU, but for memory-intensive work, it’s worthwhile. The CPU in question is an AMD 64-core processor, providing plenty of grunt for the task at hand.

In testing, the machine began to slow down long before the RAM was full. Beyond 5000 tabs, things began to crawl. At 6000 tabs, it was simply impractical to open more, with the machine taking a full 26 seconds to respond to a single click. Memory usage at this point was just 200GB, suggesting that software limitations were getting in the way of opening yet more tabs.

While it’s not a useful measure of anything important, it’s fun to explore the limits nonetheless. We’ve seen their projects before,¬†such as this original Xbox casemod. Video after the break.

Continue reading “Maxing Out Browser Tabs With 2TB Of Memory”

This Week In Security: Chrome Bugs And Non-bugs, Kr00k, And Letsencrypt

Google Chrome minted a new release to fix a trio of bugs on Monday, with exploit code already in the wild for one of them. The first two bugs don’t have much information published yet. They are an integer-overflow problem in Unicode internationalization, and a memory access issue in streams. The third issue, type confusion in V8, was also fixed quietly, but a team at Exodus Intel took the time to look at the patches and figure out what the problem was.

The actual vulnerability dives into some exotic Javascript techniques, but to put it simply, it’s possible to change a data-type without V8 noticing. This allows malicious code to write into the header area of the attacked variable. The stack, now corrupted, can be manipulated to the point of arbitrary code execution. The researchers make the point that even with Google’s fast-paced release schedule, a determined attacker could have several days of virtual zero-day exploitation of a bug mined from code changes. Story via The Register.

The Chrome Problem that Wasn’t

A second Chrome story came across my desk this week: Chrome 80 introduces a new feature, ScrollToTextFragment. This useful new feature allows you to embed a string of text in a URL, and when loading that address, Chrome will scroll the page to make that text visible. For certain use cases, this is an invaluable feature. Need to highlight a specific bit of text in a big document online?

The following bookmarklet code by [Paul Kinlan] is the easy way to start using this feature. Paste this code into the URL of a bookmark, put it on the bookmark bar, highlight some text in a webpage, and then run the bookmarklet. It should open a new tab with the new URL, ready to use or send to someone.

javascript:(function()%7Bconst%20selectedText%20%3D%20getSelection().toString()%3Bconst%20newUrl%20%3D%20new%20URL(location)%3BnewUrl.hash%20%3D%20%60%3A~%3Atext%3D%24%7BencodeURIComponent(selectedText)%7D%60%3Bwindow.open(newUrl)%7D)()

Since we’re talking about it in the security column, there must be more to the story. A privacy guru at Brave, [Peter Snyder], raised concerns about privacy implications of the feature. His argument has been repeated and misrepresented in a few places. What argument was he making? Simply put, that it’s not normal user behavior to immediately scroll to an exact position on the page. Because modern web pages and browsers do things like deferred loading of images, it could be possible to infer where in the page the link was pointing. He gives the example of a corporate network where DNS is monitored. This isn’t suggesting that the entire URL is leaked over DNS, but rather that DNS can indicate when individual components of a page are loaded, particularly when they are embedded images from other sites.

While this concern isn’t nonsensical, it seems to me to be a very weak argument that is being over-hyped in the press.

Whatsapp Groups Searchable on Google

It’s not new for search engines to index things that weren’t intended to be public. There is a bit of mystery surrounding how Google finds URLs to index, and StackExchange is full of plenty of examples of webadmins scratching their heads at their non-public folders showing up in a Google search.

That said, a story made the rounds in the last few days, that WhatsApp and Telegram group invites are being indexed by Google. So far, the official word is that all the indexed links must have been shared publicly, and Google simply picked them up from where they were publicly posted.

It appears that WhatsApp has begun marking chat invitation links as “noindex”, which is a polite way to ask search engines to ignore the link.

If it’s shown that links are getting indexed without being posted publicly online, then we have a much bigger story. Otherwise, everything is working as expected.

Letsencrypt Makes Attacks Harder

Letsencrypt has rolled out an invisible change to their validation process that makes a traffic redirection attack much harder. The new feature, Multi-Perspective Validation, means that when you verify your domain ownership, Letsencrypt will test that verification from multiple geographic regions. It might be possible to spoof ownership of a domain through a BGP attack, but that attack would be much harder to pull off against traffic originating from another country, or multiple countries simultaneously. Letsencrypt is currently using different regions of a single cloud, but plans to further diversify and use multiple cloud providers for even stronger validation.

Kr00k

Brought to us by the researchers at Eset, Krook (PDF) is a simple flaw in certain wireless chips. So far, the flaw seems to be limited to WPA2 traffic sent by Broadcom and Cypress chips. They discovered Kr00k while doing some followup research on KRACK.

Let’s talk about WPA2 for a moment. WPA2 has a 4-way handshake process that securely confirms that both parties have the shared key, and then establishes a shared Temporal Key, also known as a session key. This key is private between the two devices that performed the handshake, meaning that other devices on the same wireless network can’t sniff traffic sent by other devices.

When a device disconnects, or disassociates, that session key is reset to all 0s, and no packets should be sent until another handshake is performed. Here’s the bug: The packets already in the output buffer are still sent, but are encrypted with the zeroed key, making them trivially decrypted. As it’s simple to trigger deauthentication events, an attacker can get a sampling of in-the-clear packets. The ubiquity of TLS is a saving grace here, but any unencrypted traffic is vulnerable. Eset informed vendors about the flaw in 2019, and at least some devices have been patched.

Exchange

Microsoft Exchange got a security patch this past Tuesday that addressed a pair of bugs that together resulted in a remote code execution vulnerability. The first bug was an encryption key that is generated on Exchange server installation. That generation seemed to lack a good source of entropy, as apparently every Exchange install uses the the exact same key.

The second half of this bug is a de-serialization problem, where an encrypted payload can contain a command to run. Because the encryption key is known, any user can access the vulnerable endpoint. The process of exploitation is so trivial, be sure to patch your server right away.

TODO: Remove Vulnerabilities

This one is just humorous. An Intel virtualization feature appears to have been pushed into the Linux kernel before it was finished. Know what unfinished code tends to contain? Bugs and vulnerabilities. CVE-2020-2732, in this case. It’s unclear how exactly an exploit would work, but the essence is that a virtual guest is allowed to manipulate system state in unintended ways.

Bluetooth Control With Chrome

All the cool projects now can connect to a computer or phone for control, right? But it is a pain to create an app to run on different platforms to talk to your project. [Kevin Darrah] says no and shows how you can use Google Chrome to do the dirty work. He takes a garden-variety Arduino and a cheap Bluetooth interface board and then controls it from Chrome. You can see the video below.

The HM-10 board is cheap and could connect to nearly anything. The control application uses Processing, which is the software the Arduino system derives from. So how do you get to Chrome from Processing? Easy. The p5.js library allows Processing to work from within Chrome. There’s also a Bluetooth BLE library for P5.

Continue reading “Bluetooth Control With Chrome”