Zero-Days Hitting Fedora and Ubuntu Open Desktops To a World of Hurt (arstechnica.com)

An anonymous reader writes: It's the year of the Linux desktop getting pwned. Chris Evans (not the red white and blue one) has released a number of linux zero day exploits, the most recent of which employs specially crafted audio files to compromise linux desktop machines. Ars Technica reports: "'I like to prove that vulnerabilities are not just theoretical -- that they are actually exploitable to cause real problems,' Evans told Ars when explaining why he developed -- and released -- an exploit for fully patched systems. 'Unfortunately, there's still the occasional vulnerability disclosure that is met with skepticism about exploitability. I'm helping to stamp that out.' Like Evans' previous Linux zero-day, the proof-of-concept attacks released Tuesday exploit a memory-corruption vulnerability closely tied to GStreamer, a media framework that by default ships with many mainstream Linux distributions. This time, the exploit takes aim at a flaw in a software library alternately known as Game Music Emu and libgme, which is used to emulate music from game consoles. The two audio files are encoded in the SPC music format used in the Super Nintendo Entertainment System console from the 1990s. Both take aim at a heap overflow bug contained in code that emulates the console's Sony SPC700 processor. By changing the .spc extension to .flac and .mp3, GSteamer and Game Music Emu automatically open them."

Comments

That's why they're called BAD

[ilguido]

GStreamer can run SPC file only if the GStreamer Bad Plugins (and libgme) are installed: they're called "bad" for a reason, e.g. they lack a good code review.

This is great work.

[Anonymous Coward]

Still... that shows why security has to be half education and half technology. The last one, which was especially bad because a drive-by, combined Chrome ("I download by default to ~/Downloads"), stupid Desktop behavior ("I index everything I see -- oh, shiny! a media file: I'll throw that over to gstreamer") and gstreamer... see TFA.

The users expecting the system to "do everything automatically" is no different than Windows of yore running AUTORUN.INF whenever you inserted a removable medium. If there is no pushback on that front there won't be a secure system, ever [1]

[1] secure for the user, that is. If your definition of "secure" is "secure for some collusion of hardware vendor, software vendor, media companies, advertising cartels, search engines and state agencies, then perhaps.

Re:So where's that smug Linux dude?

[Anonymous Coward]

still smug I fear, he didn't install the bad plugins...

Re: Play Audio on Linux?

[Sarten-X]

> That's one of my criticisms of FOSS developers, they can be a bit crazy with their dependencies.

You know that because you can see them.

My day job involves creating itemized lists of dependencies for a very large project. I can assure you that both open- and closed-source software is horrible, though I do have to admit that open-source tends to be a bit worse on the unexpected-dependency front, for a few reasons.

In closed software, there is a lot of effort spent recreating common elements. I cringed when I found a file named "sort.dll", but it's probably exactly what it looks like: A developer didn't want to depend on outside code, so they wrote a sorting function as a library. Without an audit like mine, nobody would ever notice the silly practice of rewriting what's probably built into their language, and readily available in other third-party libraries.

Open-source software, then, is more transparent. If a FOSS project reimplements a sort, it will eventually be discovered and mocked until it uses the third-party library. This is fine, as it also reduces the complexity and size of the FOSS project. However, it does then lead to a bit of shock to see that the "widget" package depends on 53 other packages including "libfoo", "libbar-dev", "libbaz-ng-perl-1.03-sparc", and so on. Compounding that, it's also trivial for the FOSS project to actually use that library, because the library itself is likely FOSS, with a compatible license. Even if all your project needs is a single function, there's no cost to depend on an entire library... and a different one for a different small part, and so on.

The tendency to include a long list of dependencies makes my job worse for FOSS, because I can't just shrug my shoulders and give up after listing the one software package without any named dependencies. On the whole, however, it does ultimately lead to a smaller (and more traceable, and higher-quality) codebase for a final system, which is why the hardware requirements for a FOSS system tend to be much lower than an equivalent system based on closed-source packages.