A Linux Exploit That Uses 6502 Code

With ubiquitous desktop computing now several decades old, anyone creating an operating system distribution now faces a backwards compatibility problem. Each upgrade brings its own set of new features, but it must maintain compatibility with the features of the previous versions or risk alienating users. If you are a critic of Microsoft products for their bloat, this is one of the factors behind that particular issue.

As well as a problem of compatibility, this extra software overhead creates one of security. A piece of code descended from a DOS word processor of the 1980s for example was not originally created with any idea that it might one day be hiding in a library on a machine visible to the entire world by the Internet. Our subject today is a good example, just such a vulnerability hiding in an old piece of code whose purpose is to maintain an obscure piece of backward compatibility. [Chris Evans] has demonstrated a vulnerability in an Ubuntu version by playing an NES music file that contains exploit code emulated by the player on a virtual 6502 processor.

The NES Sound Format is a music file standard that packages Nintendo game music for playback. It contains a scripting language, and it is this that is used to trigger the vulnerability. When you open an NSF file on the affected Ubuntu system it finds its way via your music player and the gstreamer multimedia framework to libgstnsf.so, a gstreamer plugin for playing NSF files.

Rather unbelievably, his plugin works by emulating a real 6502 as found in a NES to derive the musical output, and it is somewhere here that the vulnerability exists. So not only do we have layer upon layer of backward compatibility to play an obscure music file format, there is also a software emulation of some 8-bit silicon from the 1970s. [Chris] comments “Is that cool or what?“, and while we agree that a 6502 emulator buried in a modern distro is cool, we can’t help thinking something’s been lost along the way.

A proof-of-concept is provided for Ubuntu 12.04. It’s an older version, but he points out that while he thinks the most recent releases should not contain exactly the same vulnerability, it certainly exists in more than one still-supported version. There’s also a worrying twist in that due to the vagaries of Ubuntu’s file manager it auto-opens when its folder is accessed from the GUI. The year 2000 called, they want their auto-opening Windows ME worms back.

Sadly we suspect the 6502 lurking in this music player can’t be put to more general-purpose use. If you manage it, please do share it with us! But if emulated 6502s are your thing, take a look at this 150MHz 6502 co-processor for an Acorn BBC Micro that someone made using a Raspberry Pi.

[via r/hacking]

6502 image, Dirk Oppelt, (CC BY-SA 3.0) via Wikimedia Commons.

22 thoughts on “A Linux Exploit That Uses 6502 Code

      1. Definitely not less space unless you also add a layer of compression like gzip… and then it won’t work all that well on a 8-bit micro.

        NSFs compress really well, too, through gzip, so I’m really not certain whether “here’s the machine code for the audio data, gzipped” or “here’s the logged register writes, gzipped” would be net win.

        BTW, emulating the 2A03 and its sound hardware [i]is[/i] within the computational power of a 16MIPS PIC18 — https://forums.nesdev.com/viewtopic.php?t=7453

    1. Comment got through before I finished typing. Anyway, What I meant to say: This is basically the way ALL retro music players work. There isn’t a standardised music format like MIDI or MP3 on those old systems, just an audio chip being controlled by the software at specific intervals. So a retro audio player really is a full emulation of all the things required for audio (CPU, audio chip, RAM), and the audio files are really save-states. Small exceptions are systems like the SNES, which have a pretty well defined audio subsystem with its own CPU (though you’ll still have to emulate that CPU.)

      1. Genesis/Megadrive is probably even easier. As far as I understand it uses a variant of the same type of operator sound synth chip as the Adlib/Soundblaster and old arcade machines.

        1. The SNES main CPU was a 65816, a kind of horrible, mutated 6502 with an extra 8 bits stapled on here and there to make it an 8 / 16-bit CPU. I’m convinced this was for an intended NES back-compatible game adaptor, the Megadrive had one that used it’s Z80 to play Master System games.

          The Megadrive has Master System compatible graphics modes, and similarly the SNES has NES modes.There were cheap Chinese adaptors available in the day, that let you run NES games on a SNES. I imagine Nintendo abandoned the idea because the NES was an embarassment by then, truly awful hardware that looked it’s age. Even when the NES was new it was pretty old fashioned in hardware. Nintendo scraped by, and did likewise with the SNES, by squeezing more powerful processors into the cartridges. Terrible architecture!

          The SNES’s sound processor was a Sony one and I think fully custom. It was a true processor but tied closely to it’s job.

      1. I’m glad my audio subsystem is broken on my system.

        Using gstreamer in my audio player gets a cannot open device error.
        I play audio direct to ALSA as that is the only audio route working.

        Can’t remember how I solved the issue of sharing the audio device between applications.

  1. “When the Downloads folder is later viewed in a file manager such as nautilus, an attempt is made to auto thumbnail files with known suffixes (so again, call the NSF exploit something.mp3). The exploit works against the thumbnailer.”

    — starts to make me consider turning off auto-thumbanails.

  2. One of my favorite Linux features is it’s ability to support all sorts of formats and hardware both old and new. A ‘Linux Box’ is like a Rosetta Stone of computers. I like that when somebody pulls some crusty floppy or dusty hardware out of a closet I can say.. sure, I can make that work for you. Even if it only is to play it once, converting it to a more modern format in the process. It’s like being able to save somebody’s old 8mm videos to a USB stick.

    Lately and sadly, there has been a move to clean up kernel code by removing support for some older hardware. Likewise it makes me nervous when the security people notice holes in something that is “obsolete” or even unpopular as I fear it will be another thing to be removed.

    Do the deletionists have a point? Sure, security and ease of maintenance are important but there are a lot of operating systems out there. If they are all chasing the same set of goals then they aren’t going to be very unique or serve any unique purposes are they? How about leaving as much esoteric support in Linux as possible?!

    What happens when old-stuff support gets removed regularly? I bought my daughter a set of Lego Mindstorms from a thrift shop. She had used the more modern ones in a kids robotics class and really liked it. They are expensive though! This old set with an RCX was a good deal. I ended up setting up a Windows 98 computer for her. Really.. in 2016 I’m installing Windows 98? Now she is going to have two computers on her desk. It’s a waste of space. I didn’t want to go for dual booting as she might want to use the internet while building. That isn’t very good on 98 anymore! I’ll set her up with a raspi and a kvm eventually.

    I did try wine. It seemed a bit flakey although I might revisit that. I know people did use these things with XP. After SP1 it required a DLL hack. After SP3 it just plain doesn’t work. Also.. I do know there are alternative programming environments which do build on a modern Linux. My six year old is probably not ready for ‘Not Quite C’ yet. It’s too bad there is no Lego-like visual block programming environment for us to use. Or at least I haven’t found one.

Leave a Reply to gregkennedyCancel reply

Please be kind and respectful to help make the comments section excellent. (Comment Policy)

This site uses Akismet to reduce spam. Learn how your comment data is processed.