SoylentNews is people
SoylentNews
from the all-fun-n-games-until-someone-gets-cracked dept.
A fascinating article on how to compromise a Linux desktop using Super Nintendo Entertainment System (SNES) processor opcodes:
TL;DR: full reliable 0day drive-by exploit against Fedora 25 + Google Chrome, by breaking out of Super Nintendo Entertainment System emulation via cascading side effects from a subtle and interesting emulation error.
The fault is built around the fact that the Linux gstreamer media playback framework supports playback of SNES music files by.... emulating the SNES CPU and audio processor, and the processor emulation has some exploitable vulnerabilities. The author (Chris Evans) then describes the process of working out how to escalate this into a full exploit in complete (and fascinating) detail.
Also, to quote from the article:
As always, the general lack of sandboxing here contributes to the severity. I think we inhabit a world where media parsing sandboxes should be mandatory these days. There's hope: some of my other recent disclosures appear to have motivated a sandbox for Gnome's tracker.
The processor in question is The Ricoh 5A22, a derivative of the 6502 processor, built specifically for the SNES the Sony SPC700 audio processor, not the Ricoh 5A22. [Ed: thanks KritonK for the update]
(Score: 0) by Anonymous Coward on Wednesday December 14 2016, @09:05AM
It *was* designed with malicious actors in mind. The author missed two clamps on a couple of opcodes.
(Score: 4, Interesting) by jmorris on Wednesday December 14 2016, @04:15PM
Well more like the clamps were required to make it properly wrap around 8bit values stored in 32bit ints. And it looks like the problems largely came from the implementation of the custom opcodes for that specific processor instead of the generic 6502 emulation it was based on.
The longterm solution is adding a switch like --untrusted_content that browser plugins and other sources of untrusted content can set which would disable any codec marked as untrusted from being selected. If somebody explicitly downloads one of those files and invokes it from a player then that is on their head. Navigating to a webpage that autoplays a media file should be only be allowed to use codecs that have had serious vetting.
(Score: 0) by Anonymous Coward on Monday December 19 2016, @08:35PM
If only. Multiple things are at play here, but they all come down to programmers trying to be (overly) helpful.
First instance is that a browser tries to automatically download a file it can't interpret itself.
Another is that it tries to autoplay a media file it either has a built in or third party codec for.
third is that DEs have search systems now that try to index every new file out there, to the point that they will call third party libs to extract metadata.
All in all this is Autorun level drooling puppy "helpfulness". Yes it brought in the newspaper, but now its so soaked in slobber it needs to be treated as a biological hazard zone.
(Score: 2) by bob_super on Wednesday December 14 2016, @06:52PM
At least, it is designed to execute machine code.
What drives me nuts is how many hackable flaws still show up in software designed to open text documents, or pictures... How easily they jump from reading data to surrendering execution has always blown my mind.
(Score: 0) by Anonymous Coward on Wednesday December 14 2016, @08:49PM
1) That's because they use programming languages like C or C++ where simple and common mistakes often don't merely make the program crash but can let "an attack run arbitrary code of the attacker's choice". With safer languages you have to make a bigger screw up, e.g. there's stuff like SQL injection but it's a lot easier to avoid that with parameterized queries.
2) Also it seems popular to mix the code/call and data stacks. They aren't kept separate. When you pass parameters they go on the call stack. https://en.wikipedia.org/wiki/Call_stack#Security [wikipedia.org]
(Score: 0) by Anonymous Coward on Monday December 19 2016, @08:38PM
Welcome to the Von Neumann architecture.
It does not separate between executable code and data.
Thus any data can also be a command to the computer, its just a matter of what register to feed it to.
Any attempt at building security and privilege separation on top of that is bound to be flawed.