In this talk, he uses the controller interface on the SNES to send commands to a Super GameBoy, which is running a real Pokemon Red cartridge. Commands are sent to Pokemon Red to activate an arbitrary code execution bug to write a bootloader that receives the rest of the attack program at high speed. Then - form inside the GameBoy environment - he takes over the Super GameBoy and gains arbitrary code execution on the SNES proper.
(for a finish, a Twitch chat client is written into RAM on the SNES that uses a custom network protocol to send requests over the controller port, so the livestream audience can ask questions live through the SNES).
Not only is there a bug consistent enough to get arbitrary code execution in the game, but to also be able to reliably breakout of the emulator and literally reprogram the current game all in RAM to something completely different.
I can't seem to think of words that would do what he did justice. It's amazing.
IMO this is what the word "pwned" was meant to describe. When someone has not only exploited a machine, but has literally become it's master to such an extent that they are playing games at that point, abusing the original purpose of the console into this tormented, bastardized version to display memes from a twitch chat, or play a clone of a shitty phone game.
It was definitely impressive but as a software person I'm more impressed by the ones who came up with the hack itself.
> Right now there is what I can only describe as a conspiracy to connect something called gstreamer-plugins-bad to the internet. I do not want something called gstreamer-plugins-bad to be connected to the internet because that doesn’t sound like a good idea, but apparently somebody decided to call it a feature, and just like that it had to happen. It’s as if somebody looked at the UML diagram for my browser and realized that the boxes labeled malicious input and gstreamer-plugins-bad weren’t yet connected, and in their utopian vision of the internet, all of the boxes must be connected.
This is probably the only reason I can somehow understand Google's draconian approach to the NDK APIs, versus what iOS and UWP allow for.
After seeing that and seeing this article, I'm thinking this might be the start of a whole new era of finding security holes in emulators that allow PCs to be compromised by running something shady in an emulator.
 Seriously, if you're still using ZSNES to emulate SNES games, don't. That's a really scary vulnerability, it still hasn't been patched, and ZSNES has been horrendously inaccurate and buggy since even before that. Do yourself a favor and use Snes9X (or if you can, try something based on a bsnes core, like Higan, bsnes-classic, or RetroArch configured with a bsnes core; they're the most accurate, but the system requirements are high, and Higan's UI isn't user-friendly).
I agree this will probably catch on as a popular new vector, especially given the popularity of emulators on mobile devices.
Indeed. People acquire ROMs for emulators illegally from wherever they can get them anyway. Given what you say about ZSNES, I'd be surprised if no one has yet built a botnet by spreading a ROM attacking ZSNES.
Nintendo's hit most of the big personal computing CPU architectures through the course of their history-- 6502 in NES and SNES, MIPS on the N64, PPC on Gamecube/Wii/Wii U, and ARM on GBA/DS/3DS/Switch. The only ones they really missed were 68k and x86.
When I had to write some 6502 code for a lab class in college I didn't like the debugging options in most of the emulators I found and did write my own mini-emulator in JS (or maybe it was PHP; it has been a while) to debug some of the specific parts of code I was working on in that lab class.
EDIT it's both: https://gstreamer.freedesktop.org/documentation/splitup.html , http://askubuntu.com/questions/468875/plugins-ugly-and-bad
The issue here is that distributions should offer more granularity with on demand codec installation. Does it make sense that to play an mp3 (not that sure this is the case) I get also the NSF decoder?
I read it as "an zero day", and that feels wrong.
edit: I even think it's more natural. "Zero day" are two real words that could be a sentence fragment, "oh-day" feels like a new word. Saying "that's a zero day" feels like an incorrect sentence to me (uncanny valley), whereas "that's an oh-day" only sounds weird if you don't accept "oh-day" as a word. To me, "oh-day" is similar to most slang, where it feels natural to say/hear even when you don't know what it means.
Its only one step removed from Zorro. Now I have a cape on and am slashing stuff with a sword. All right!
This same thing happens with "MVP" I think. "An MVP" sounds good, but "An Minimal Viable Product" doesn't. So I use a/an depending on whether using the abbreviation or not, but I have no idea if there's a rule for this or not.
In your example "MVP", the first syllable starts with an "em", so a vowel. In "Minimal Viable Product" the first syllable starts with the consonant sound.
I had a major pain with this rule when dealing with auto-generation of some API documentation. It ended up just being an issue of detecting/guessing if the text was an abbreviation or some weird CamelCase thing.
As such, I would only use them to give elven advice (that is, intentionally ambiguous advice). In the context of software vulnerabilities, an aught-day would either be a 0-day, or one with an indeterminate nonzero number of days lead time to patch. So, maybe something the vendor knows about, but it would take rare expertise crossed with obscure motive to exploit?
TIL some people pronounce 0 as "oh" and some people pronounce it as "zero".
Take this fact with you as you read all the other comments about pronunciation on this page. ...See? :)
"One oh four, zero one eighty"
(Not to say that TC itself is bad, but unexpected/accidental TC is normally a sign of bad omen)
> NSF music files, on the other hands, are played by actually emulating the NES CPU and sound hardware in real time. Is that cool or what? The gstreamer plug-in creates a virtual 6502 CPU hardware environment and then plays the music by running a bit of 6502 code for a little while and then looking at the resulting values in the virtualized sound hardware registers and then rendering some sound samples based on that.
That was surprisingly simple, if a bit mind-bending.
I think just looking at that hurt my brain.
Maybe once I've got a grip on assembler?
You could get access to their email. You could steal their private SSH keys. Steal the browser's cookie cache. Get access to their password manager. Pull API keys out of private code bases. etc.
So I wouldn't shrug it off.
There are many parallels here to the libstagefright media codec vulnerabilites that were big news in the Android world back in 2015 - the primary problem seems to be remote code execution, not privilege escalation.
That probably wouldn't be too hard. Local privilege escalation seems to be a lot easier to accomplish. It's harder to secure a system from code running on it than from data coming in from the outside. It's sort of a bigger version of the article's suggestion to "watch out for scripting in unexpected places!"
You also don't necessarily need privilege escalation to do a lot of damage. If the media player isn't sandboxed in some way, then it'll have full privileges to access all your user's files. Traditional UNIX permissions means that you need special access in order to write to the kernel, but not to read your e-mails or that spreadsheet you have with your bank account details.
Bear in mind the victim doesn't need to OPEN the .mp3 file... See the part of the article about the 'auto thumbnail' feature.
I would guess that a crafty attacker could package additional content inside the mp3 file, perhaps some local privilege escalation code...
But for practical purposes, running a botnet as a user and running a botnet as root end up accomplishing about the same thing.
i'm loath to download and execute the test file though.
while i'm almost completely sure this post is legit, i also don't want to delete the gstreamer-0.1 in case it trashes something important. think of trolls recommending the deletion of system32 to speed up the system and free disk space.
can i remove this safely? is there more information from another credible source?
Don't delete gstreamer-0.10, because many things rely on it. It is however safe to delete libgstnsf.so.
Any different version of Ubuntu (such as 14.04.anything), will have a different glibc binary. Among other issues, the exploit has a hard coded offset of the delta between the memset() and system() functions inside glibc. This offset will only be valid against the glibc binary for 12.04.5. With more work, the exploit could be modified to dynamically calculate the correct offset for almost any version of glibc.
If the offset is invalid, you're likely to still get a crash, just no calculator. So the presence of a crash or not can be used to determine trouble vs. ok.
That said, Ubuntu 14.04 isn't too badly affected. It does come with gstreamer-0.10, but it does not appear to be used for much. As far as I could tell, gstreamer-1.0 is used for the most important stuff (totem, totem-video-thumbnailer, etc.).
sudo rm /usr/lib/x86_64-linux-gnu/gstreamer-0.10/libgstnsf.so
gstreamer0.10-plugins-bad gstreamer0.10-plugins-bad-multiverse gstreamer1.0-plugins-bad gstreamer1.0-plugins-bad-faad gstreamer1.0-plugins-bad-videoparsers libgstreamer-plugins-bad0.10-0 libgstreamer-plugins-bad1.0-0
Next you'll be telling me mplayer is riddled with vulnerabilities too...
2) Why suggest a prompt that doesn’t give the user an understanding of what they are being asked and why it matters?
People think in ways of making things simple and easy, but you end up harming people. It's a leaky abstraction of trust.
This would fall into the same category. You don't expect risk from a MP3. But then it's not an MP3, it's a NSF.