This Week in Security: GhostWrite, Localhost, and More [Hackaday]

View Article on Hackaday

You may have heard some scary news about RISC-V CPUs. There’s good news, and bad news, and the whole thing is a bit of a cautionary tale. GhostWrite is a devastating vulnerability in a pair of T-Head XuanTie RISC-V CPUs. There are also unexploitable crashes in another T-Head CPU and the QEMU soft core implementation. These findings come courtesy of a group of researchers at the CISPA Helmholtz Center for Information Security in Germany. They took at look at RISC-V cores, and asked the question, do any of these instructions do anything unexpected? The answer, obviously, was “yes”.

Undocumented instructions have been around just about as long as we’ve had Van Neumann architecture processors. The RISC-V ISA put a lampshade on that reality, and calls them “vendor specific custom ISA extensions”. The problem is that vendors are in a hurry, have limited resources, and deadlines wait for no one. So sometimes things make it out the door with problems. To find those problems, CISPA researchers put together a test framework is called RISCVuzz, and it’s all about running each instruction on multiple chips, and watching for oddball behavior. They found a couple of “halt-and-catch-fire” problems, but the real winner (loser) is GhostWrite.

Now, this isn’t a speculative attack like Meltdown or Spectre. It’s more accurate to say that it’s a memory mapping problem. Memory mapping helps the OS keep programs independent of each other by giving them a simplified memory layout, doing the mapping from each program to physical memory in the background. There are instructions that operate using these virtual addresses, and one such is vs128.v. That instruction is intended to manipulate vectors, and use virtual addressing. The problem is that it actually operates directly on physical memory addresses, even bypassing cache. That’s not only memory, but also includes hardware with memory mapped addresses, entirely bypassing the OS. This instruction is the keys to the kingdom.

So yeah, that’s bad, for this one particular RISC-V model. The only known fix is to disable the vector extensions altogether, which comes with a massive performance penalty. One benchmark showed a 77% performance penalty, nearly slashing the CPU’s performance in half. The lessons here are that as exciting as the RISC-V is, with its open ISA, individual chips aren’t necessarily completely Open Sourced, and implementation quality may very wildly between vendors.

0.0.0.0 Day Vulnerability

We’ve come a long way since the days when the web was young, and the webcam was strictly for checking on how much coffee was left. Now we have cross-site scripting attacks and cross-site request forgeries to deal with. You might be tempted to think that we’ve got browser security down. You’d be wrong. But finally, a whole class of problems are getting cleaned up, and a related problem you probably didn’t even realize you had. That last one is thanks to researchers at Oligo, who bring us this story.

The problem is that websites from the wider Internet are accessing resources on the local network or even the localhost. What happens if a website tries to load a script, using the IP address of your router? Is there some clever way to change settings using nothing but a JS script load? In some cases, yes. Cross Origin Resource Sharing (CORS) fixes this, surely? CORS doesn’t prevent requests, it just limits what the browser can do after the request has been made. It’s a bit embarrassing how long this has been an issue, but PNA finally fixes this, available as an origin trial in Chrome 128. This divides the world into three networks, with the Internet as the least privileged layer, then the local network, and finally the local machine and localhost as the inner, most protected. A page hosted on localhost can pull scripts from the Internet, but not the other way around.

And this brings us to 0.0.0.0. What exactly is that IP address? Is it even an IP address? Sort of. In some cases, like in a daemon’s configuration file, it indicates all the network devices on the local machine. It also gets used in DHCP as the source IP address for DHCP requests before the machine has an IP address. But what happens when you use it in a browser? On Windows, nothing much. 0.0.0.0 is a Unixism that hasn’t (yet) made its way into Windows. But on Linux and MacOS machines, all the major browsers treat it as distinct from 127.0.0.1, but also as functionally equivalent to localhost. And that’s really not great, as evidenced by the list of vulnerabilities in various applications when a browser can pull this off. The good news is that it’s finally getting fixed.

PLCs Sleuthing

Researchers at Claroty have spent some time digging into Unitronics Programmable Logic Controllers (PLCs), as those were notably cracked in a hacking campaign last fall. This started with a very familiar story, of rigging up a serial connection to talk to the controller. There is an official tool to administrate the controller over serial, so capturing that data stream seemed promising. This led to documenting the PCOM protocol, and eventually building a custom admin application. The goal here is to build tooling for forensics, to pull data off of one of those compromised devices.

You Don’t Need to See My JWT

Siemens had a bit of a problem with their AMA Cloud web application. According to researchers at Traceable ASPEN, it’s a surprisngly common problem with React web applications. The login flow here is that upon first visiting the page, the user is redirected to an external Single Sign On provider. What catches the eye is that the React application just about fully loads before that redirect fires. So what happens if that redirect JS code is disabled? There’s the web application, just waiting for data from the back end.

That would be enough to be interesting, but this goes a step further. After login, the authenticated session is handled with a JSON Web Token (JWT). That token was checked for by the front-end code, but the signature wasn’t checked. And then most surprisingly, the APIs behind the service didn’t check for a JWT either. The authentication was all client-side, in the browser. Whoops. Now to their credit, Siemens pushed a fix within 48 hours of the report, and didn’t drop the ball on disclosure.

(Hackaday’s parent company, Supplyframe, is owned by Siemens.)

Bits and Bytes

If you run NeatVNC, 0.8.1 is a pretty important security update. Specifying the security type is left up to clients, and “none” is a valid option. That’s not great.

Apparently we owe Jia Tan a bit of our thanks, as the extra attention on SSH has shaken loose a few interesting findings. While there isn’t a single glaring vulnerabiltiy to cover, HD Moore and Rob King found a bunch of implementation problems, particularly in embedded devices. This was presented at Black Hat, so hopefully the presentation will eventually be made available. For now, we do have a nifty new tool, SSHamble, to play with.

In 2023, the Homebrew project undertook an audit by Trail of Bits. And while there weren’t any High severity problems found, there were a decent handful of medium and lower issues. Those have mostly been fixed, and the audit results have now been made public. Homebrew is the “missing package manager for MacOS”, and if that sounds interesting, be sure to watch for next week’s FLOSS Weekly episode, because we’re chatting with Homebrew about this, their new Workbrew announcement, and more!