Linux Fu: The Chrome OS Flex Virtualization

The Flex Desktop is user-friendly and responsive

You’ve probably heard about Google Chromebooks. Like Android, Chrome OS is based on some variant of Linux, but it is targeted at the “cloud first” strategy so Chromebooks typically don’t have a huge amount of storage or compute power. If you have a real Chromebook, you can also use it to run certain other kinds of programs via virtualization. However, Google has recently pushed out Chrome OS Flex which is meant to install on a spare laptop you might happen to have hanging around. Seems attractive to take that only Windows 7 laptop and repurpose it to run Chrome OS, especially if you can run Linux apps on it. Unfortunately, Chrome OS Flex has a very different use case and I would only recommend installing it if you meet the exact use case it addresses.

The other option, of course, is to just install Linux on that old hardware. There are several distributions that are made for that purpose and, honestly, even most of the major distributions will work fine on older hardware with a little tweaking to turn off some of the more resource-costly features. That assumes you know how to install, tweak, and maintain Linux.

Continue reading “Linux Fu: The Chrome OS Flex Virtualization”

Web Serial Terminal Means It’s Always Hacking Time

Arguably one of the most important pieces of software to have in your hardware hacking arsenal is a nice serial terminal emulator. There’s plenty of choice out there, from classic command line tools to flashier graphical options, which ultimately all do the same thing in the end: let you easily communicate with gadgets using UART. But now you’ve got a new choice — instead of installing a serial terminal emulator, you can simply point your browser to the aptly-named serialterminal.com.

Well, maybe. As of this writing it only works on Chrome/Chromium (and by extension, Microsoft Edge), so Firefox fans will be left out in the cold unless Mozilla changes their stance on the whole Web Serial API concept. But assuming you are running the appropriate browser, you’ll be able to connect with your serial gadgets with a simple interface that should be familiar to anyone who’s worked with more traditional terminal software. In a quick test here at the Hackaday Command Center, we were able to bring up the Bus Pirate UI with no problems using Chrome on Linux. Continue reading “Web Serial Terminal Means It’s Always Hacking Time”

Google’s T-Rex Game Ported To The ESP32

Most Chrome users will have come across a neat little Easter egg when their Internet connection has gone down – a game known as “T-Rex” where a dinosaur must be jumped over cactii. Whether or not this is accurate in terms of the evolutionary timeline, it’s a bit of fun, and Volos Projects educator [Danko Bertović] decided to port the game to the ESP32.

The game runs on the LILYGO TTGO T-Display development board, which pairs the powerful microcontroller with a 1.14-inch color LCD. His clone goes as far as authentically replicating the “No Internet” page from within Google Chrome, before kicking into the game at the press of a tactile button.

The game is built using a sprite-based engine, which enables gameplay with a minimum of flickering on the screen. Transparency is included to stop the sprites from occluding other screen elements unnecessarily. [Danko] hasn’t yet released a full tutorial on using sprites on the ESP32, but code is available for your own digestion.

It’s not the first time we’ve seen [Danko]’s ESP32 games, as he’s developed a few over the years. Others have gone so far as coding 8-bit emulators for the platform. Video after the break.

Continue reading “Google’s T-Rex Game Ported To The ESP32”

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”