Ubuntu 12 exploit through NES ROM hacking
November 14, 2016 9:39 PM   Subscribe

A new 0day vulnerability has been discovered for an older version of Ubuntu, exploitable through unexpected means, by using a specially-constructed NES ROM, in conjunction with the NSF audio format, leading an emulator to escape its expected memory region and execute outside instructions.
posted by JHarris (38 comments total) 26 users marked this as a favorite
 
I'm just sitting here blankly, incapable of comprehending this because of how improbable it sounds.

It's like finding out that you can set your house on fire by putting a Calvin & Hobbes collection between two slices of the right kind of bread.
posted by DoctorFedora at 9:44 PM on November 14, 2016 [74 favorites]


"It's like finding out that you can set your house on fire by putting a Calvin & Hobbes collection between two slices of the right kind of bread."

Fire departments everywhere hate this one weird trick!
posted by I-baLL at 10:08 PM on November 14, 2016 [19 favorites]


Bread made of white phosphorus works fine for me.
posted by benzenedream at 10:38 PM on November 14, 2016 [2 favorites]


There's literally not a file format I know of that hasn't been exploited, many many times. The difference between 6502 and GIF is computationally interesting (Turing Complete or not), but commands to copy are commands to copy.
posted by effugas at 10:45 PM on November 14, 2016 [3 favorites]


Basically:
  • Ubuntu uses the library gstreamer if it's installed with mp3 support.
  • gstreamer plays a lot of audio formats, and doesn't need to be directly invoked to run, as it's configured to run as part of creating a thumbnail in the file browser.
  • One of these formats is NSF, which has the unusual property of actually being an NES emulator that runs 6502 code to produce almost exactly the sound real hardware would have (depending on fidelity to the hardware).
  • NESes are tricky beast to emulate because of the existence of customer mappers, ways to get around the hardware's limited addressing space. Mappers are custom silicon that ships inside nearly every game cartridge. By storing certain values in certain registers, depending on the mapper included, different regions of the cartridge's chips become visible to the processor.
  • Because every mapper is its own thang, a good emulator has to support all of them. The emulator in gstreamer doesn't perform some bounds checking that allows memory to be mapped to and seen by the processor that isn't actually part of the ROM. Therein lies the exploit.
posted by JHarris at 11:59 PM on November 14, 2016 [81 favorites]


I honestly thought this was going to be the opening to an experimental format sci-fi story.
posted by lumpenprole at 12:26 AM on November 15, 2016 [4 favorites]


The moral of this story is never use computers
posted by aubilenon at 12:49 AM on November 15, 2016 [22 favorites]


Thanks JHarris for the explanation - I get it now.
posted by motdiem2 at 1:56 AM on November 15, 2016


Part of the problem is that sandboxing dangerous code is incredibly difficult. It's a thing being worked on, but effectively it's trivial to do badly but highly undocumented how to do mildly effectively.
posted by effugas at 1:58 AM on November 15, 2016 [3 favorites]


This is a very JHarris post and I love it.
posted by Pope Guilty at 2:22 AM on November 15, 2016 [14 favorites]


> It's like finding out that you can set your house on fire by putting a Calvin & Hobbes collection between two slices of the right kind of bread.

This is a large part of why I love doing security.
posted by l_zzie at 2:29 AM on November 15, 2016 [7 favorites]


Oh, so libgstreamer lives in some kernel modules? Ouch! That seems like an architectural mis-step.

I've long thought that video card drivers are the scariest untrustworthy privileged code, after OS kernels (l4.verified excepted). Their sheer size and closed-source nature seems like a great place to find exploitable errors (or hide malicious payloads).
posted by dylanjames at 3:17 AM on November 15, 2016 [2 favorites]


JHarris -- Very good and thorough rundown of the exploit. I do security and software engineering, so I had a pretty solid guess about some of the exploit's features simply by mentioning the fact of an emulator, but I sometimes struggle to do layman's explanations. A clear and concise explanation like you gave goes a long way.

This kind of exploit is one of the major reasons why most security-minded people -- *especially* those working in computer security in particular -- have long ago abandoned the idea of trying to figure out every possible security "threat." There's simply too many of them -- perhaps a truly unlimited amount. Instead, we tend to focus on "vulnerabilities," the weak-points in the armor that are actually exploited by the unpredictable threat models.

You can't necessarily predict that an NES emulator's memory mapping procedure in particular is going to be where the threat comes from, but you can reasonably predict the fact that emulators in general are encapsulating unknown code, and that memory management within the emulator should therefore be done carefully.

I teach defensive programming concepts to my junior developers as a default method of operation specifically because of these problems. Yes, defensive development can increase the complexity of the program if not done right, and yes it can increase the physical resource use of the program at run-time, but since it's never safe to completely assume the environment on which your code will run I see it as the only way to limit the likelihood of disaster that is within my ability to control.
posted by mystyk at 4:04 AM on November 15, 2016 [9 favorites]


dylanjames: no, there is no gstreamer in the Linux kernel. They won't even put anything for the GUI in there, not to mention file format decoders / media playback.
posted by idiopath at 4:28 AM on November 15, 2016


Maybe the assumption was that the file browser was in the kernel - anyway, Linux devs don't like anything for the UI layer to be in the kernel.
posted by idiopath at 4:32 AM on November 15, 2016


It's a bit of a stretch to call something a 0day when you find it 830 days after the distro's release. There have been two LTS releases since then, and this only works on a pristine Ubuntu 12.04.5 x86_64 that has never had an update since mid-2014.

Since Ubuntu bugs you incessantly to update, you'd either have to be very patient or have no network to be affected.
posted by scruss at 6:06 AM on November 15, 2016 [2 favorites]


I honestly thought this was going to be the opening to an experimental format sci-fi story.

I'll bet that Neil Stephenson or Cixin Liu is already working on this.
posted by NoMich at 6:43 AM on November 15, 2016



It's a bit of a stretch to call something a 0day when you find it 830 days after the distro's release.


That's not what "0day" means. It means that the day it's discovered, it's never been seen by the vendor before, so there's no patch/countermeasures available. Doesn't matter how long it's been hanging out unnoticed, and there have been 0days found in *much* older code.
posted by kjs3 at 6:52 AM on November 15, 2016 [5 favorites]


If anyone has or maintains Ubuntu 12.04 Desktop stuff (I do), it looks like you can remove the gstreamer NSF plugin by removing the gstreamer0.10-plugin-bad package.
posted by thefool at 8:05 AM on November 15, 2016


Also official Ubuntu security fixes (not unfixed issues) are announced at https://www.ubuntu.com/usn/ and via mailing list for future reference. (With links to CVE info for details)

Unfortunately "cheese" depends on gstreamer0.10-plugins-bad... would be nice to change that to suggests or something maybe...
posted by thefool at 8:08 AM on November 15, 2016


anyway, Linux devs don't like anything for the UI layer to be in the kernel.

Doesn't the X11 server still run with root privilege in order to directly access the graphics hardware? That's not quite in the kernel, but pretty close.
posted by acb at 8:12 AM on November 15, 2016


“Shoulda been a farmer. Since the day I was born, I should have been a farmer. I love chickens. Pigs. Ducks. I'm kinda fond of nanny goats, I am.”—Me, contemplating my job in the 21st century, by way of Pop Fisher in The Natural.
posted by ob1quixote at 8:34 AM on November 15, 2016 [1 favorite]


Look shut up about the kernel everyone. This isn't a privilege escalation exploit, it's a code execution exploit. That is, when you LOOK at a media file in your filesystem browser, it runs code. The code runs as whatever user ran the program that opened (or thumbnailed) the media file, and it's up to that code to use other holes if it wants to run as the kernel or do things the user can't do. Or it can just do quite a number of bad things with your regular permissions.

So basically this is a security hole of exactly the same sort that keep showing up in Flash or Acrobat Reader. Which is plenty bad. But it's not because of some idiotic decision to thumbnail media files in the kernel.
posted by aubilenon at 8:44 AM on November 15, 2016 [4 favorites]


> "shut up about the kernel..."

Making me feel bad there. I brought up the kernel because of language like this in the linked paper: "If the victim downloads and opens the file, they are compromised." Sounds like describing a kernel exploit to me. However, reading more closely (and your nice description), it's just the file manager that's been compromised. Annoying, but not a privilege escalation. I'll crawl back into my hole now.
posted by dylanjames at 8:51 AM on November 15, 2016 [1 favorite]


Less eyepopping, but quite similar under the hood, the Dolphin Wii emulator can be exploited to run arbitrary code on the host.
posted by figurant at 8:55 AM on November 15, 2016 [1 favorite]


Actually it is worse than the flash or pdf ones, because you don't have to open to file for it to run code.

On the other hand it's better because it only affects desktop linux and hahaha
posted by aubilenon at 9:03 AM on November 15, 2016 [3 favorites]


I've read this twice now and I'm confused. Is there privilege escalation in this bug, to root? Or is it simply a means for the NSF file to subvert process memory as the user who is running?

I think it's the latter, which is still bad but not quite rewt. But at the end of the article he mentions Windows font rendering being in the kernel and how scary that is.
posted by Nelson at 10:20 AM on November 15, 2016


It's an exploit, not an escalation. Still, having an exploit "rm -rf ~/" would ruin your day just as much as an escalation "rm -rf /" would. Especially a driveby.
posted by Kyol at 10:23 AM on November 15, 2016


This is great in a weird, magical way.

But if some Hollywood movie or CSI episode explained a hack like this, we'd all be groaning about how ridiculous and impossible it is.
posted by rokusan at 10:45 AM on November 15, 2016


2016 - year of the linux desktop
posted by lescour at 11:51 AM on November 15, 2016 [3 favorites]


this only works on a pristine Ubuntu 12.04.5 x86_64 that has never had an update since mid-2014. ...Since Ubuntu bugs you incessantly to update, you'd either have to be very patient or have no network to be affected.

It seems like it would be trivial for someone appropriately motivated to modify the exploit to work on updated versions:
If you take all the updates, you’ll get a new glibc, which changes some code offsets and the exploit will crash. The crash is of course deterministic and it would be possible to code the exploit to cater for arbitrary glibc binaries; this is left as an exercise for the reader.
posted by sparklemotion at 12:17 PM on November 15, 2016


  That's not what "0day" means.

Ah; one lives and learns. I thought it meant an exploit known by the community on or before the day of release but included in software by the vendor.
posted by scruss at 12:20 PM on November 15, 2016


TL;DR: Turing Machines.

You are living one in one right now.


I don't think this is meaningfully settled -- hypercomputation within our universe seems pretty implausible, but that doesn't necessarily mean that the universe itself is computable. This paper by UMSL philosopher Gualtiero Piccinini about the physical Church-Turing Thesis digs into the distinction.
posted by invitapriore at 12:28 PM on November 15, 2016 [2 favorites]


the pirate community often uses 0day to mean the release of something prior to the commercial release being made available

Traditionally 0 day refers to the speed at which the release has arrived at the source you are getting it from counting from its release date. 0 day means you are in the first tier of distributors/receivers. Back in modem days you were the elitist of the elite if you had access to 0 day warez. You were getting them pretty much direct from the original pirates. 7 day wares was still pretty good. After 14 days you were one of the joes and would have hard time getting download credit for anything you had to share. It didn't have anything to do when the actual software was released by developers. Only when it was released by a warez group (and being first warez group to release was status).

Speed was a currency muliplier in the piracy world.

These days the currency is whether exploits are unpatched. The newer they are the less likely they are to be patched. The number of days is really pretty meaningless compared to whether or not a patch is available. (Patches also don't matter that much given how many systems on the net are unpatched unless your goal is to target savvier users).
posted by srboisvert at 1:52 PM on November 15, 2016


If it had been an old Windows - it would have been all over the media....
posted by Burn_IT at 1:53 PM on November 15, 2016


I've read this twice now and I'm confused. Is there privilege escalation in this bug, to root? Or is it simply a means for the NSF file to subvert process memory as the user who is running?

There is no privilege escalation. It's "merely" a way for a music file to run arbitrary code when the user either plays the file or literally even just looks at the file the wrong way (i.e., using the filesystem browser). I think the main reason this isn't an enormously huge deal is it only affects old versions of Ubuntu.
posted by aubilenon at 1:59 PM on November 15, 2016


Reminds me of that time when WinAmp had a nasty security issue because there was a bug in libmikmod. Which was weird. Pieces of software rarely mentioned in same sentence.

Supporting demoscene/emulator file formats in multimedia frameworks is neat as hell, but might lead to some problems. Feature creep makes programs bigger. Bigger programs have bigger potential for bugs. Blah blah.
posted by wwwwolf at 2:56 PM on November 15, 2016 [1 favorite]


I think the main reason this isn't an enormously huge deal is it only affects old versions of Ubuntu.

Welllll, it remains to be seen if someone can bring this exploit forward to modern versions of any of the tools involved or if this is just a perfect combination of exploit chains. The implication is that at least one of the updates merely changes the address randomization, so a new hunt for exits is necessary, but other than that.. Eh? Maybe?

It probably won't get a cute media friendly name, in any case.
posted by Kyol at 3:35 PM on November 15, 2016


« Older Democracy suffers if our news environment...   |   Hang On To Yourself Newer »


This thread has been archived and is closed to new comments