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: 5, Insightful) by jmorris on Wednesday December 14 2016, @06:09AM
First we should note that there is a downside to willy-nilly stuffing in support for obsolete formats that have implementations that likely have not had a lot of attention paid to them.
Second we really need to start designing everything with a hostile actor in mind. Even if we accept that gstreamer should support every known format, the user might have explicitly installed that format to play local files for example, we should be marking codecs as to security audit status and browsers should at least warn before automatically invoking a less trustworthy one.
(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.
(Score: 0) by Anonymous Coward on Wednesday December 14 2016, @09:06AM
Yes, but remember that worse is better.
An end user is not that likely to be a victim of an exploit, and even if they are compromised, it is often too hard to identify which component led to the eventual malware infection. And once You are being blackmailed for decryption keys for Your stuff, it is often small consolation to know which software part has broken security (and then understanding that it's actually all of them).
Developing software with good security is hard, and requires thought and time to implement features which are unseen by the user. On the other hand, features such as playing snes audio are visible (or rather: audible in this case) and might be preferable to unnoticeable security.
Hence, software that provides noticeable features at the cost of security, will probably triumph over software that provides security over noticeable features.
(Score: 2) by Bot on Wednesday December 14 2016, @09:57AM
But the philosophy of recent desktop linux says
ONE Desktop
ONE Configuration
ONE User experience
therefore
ONE Zero day for all.
You are advocating a return to the long list of configuration menus, or to booting gentoo. I agree.
Account abandoned.