Slashdot Mirror
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."
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.
What if they are used as a music server? And just because you are not vulnerable does not mean you can just ignore it.
Becquse YOU will be getting the spam send to your server costing you electrcity and time and efford and some will get through.
Don't fight for your country, if your country does not fight for you.
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.
still smug I fear, he didn't install the bad plugins...
I wonder what he'd have to say to Chris Evans.
That this is a bit disingenuous: the statement "GStreamer, a media framework that by default ships with many mainstream Linux distributions" is true, but the mentioned exploit does not requires just GStreamer, but a plugin from the "Bad" set, which is usually not installed by default in Linux distros.
actually it's the only way to be fully protected against local root (kernel/system daemons) vulnerabilities, keyloggers, data theft, etc.
I'm not entirely sure about the scope of what you're claiming here, but know that virtual machine escapes aren't uncommon. I'm not saying that virtualizing the browser is a bad idea (defense in depth and all that), but it won't get you perfect security. Also, in some cases, it's possible to attack the host OS without leaving the VM. Then there's the sensitive information within the VM (user credentials, session cookies, etc.), which doesn't require an escape.
It's has not been a question of which is safer anymore, MacOS notwithstanding, but of which you trust. It's either an OS that can be exploited by the vendor, or a 3-letter agency, by design, or trusting that someone will audit your open source software and look for exploits, unless you have the time and expertise to do it yourself. Moreover, Linux users have never felt safe by the lower market share, but by how hard it is to have anything running on a Linux system. It's has never been about not having 14,000 viruses to infect your computer, but about having to make it executable it to have it run. Now, if I felt threatened by this new exploit, I could make my computer super safe by uninstalling the piece of software it affects. These days, the main reason for people to switch to Linux, and not to switch back to Windows, is concerns about privacy and productivity. You said that, had the exploit been found on Windows, there would be an update; now remember that Windows updates shut down the system, while Linux ones are performed while the system is running and the user is working: a reboot is not usually necessary, and when it is, it doesn't take longer than usual to turn on the computer.
Linux is for people who don't mind RTFM.
I think that post was more about msft turning w10 into software version of Orwell's 1984, rather than it being simply full of bugs (as if linux isn't full of bugs). And the actual shithow part of w10 is that there are cases when you install a correct driver for any (particullary old) hardware, it get rolled over by yet another update, so you basically forced to unfuck the system wherever microsoft decides to "enchance your user expirience" (basically every 2-3 days or so). Not to mention all the obvious spyware bundle.
The idea that Linux might or does have security vulnerabilities is not anything remotely new. I sometimes file five bug reports a day on patches for things like this dealing with Debian, Rosa, Mageia, Fedora, and Suse. I just file the bugs, its up to the Distro Maintainers to read what I post and act on them. Sometimes they mark it as invalid, a Duplicate, already fixed, or Works for me.
Other times I get a patched, or upgraded package in 24-48 hours.
If you see a CVE of something, post it to your relevant bugzilla, and not just one, always provide the CVE and a URL to where you got the CVE From if at all possible. Don't stick your head in the sand and say its not your problem. Keep in mind the world we live in today.
"usually not installed by default in Linux distros" Really?
The Vanilla Ubuntu 16.04.1 desktop image I have at hand shows that it they are installed by default:
ubuntu@ubuntu16:~$ dpkg --get-selections | grep gstreamer | grep bad
gstreamer1.0-plugins-bad:amd64 install
gstreamer1.0-plugins-bad-faad:amd64 install
gstreamer1.0-plugins-bad-videoparsers:amd64 install
libgstreamer-plugins-bad1.0-0:amd64 install
Democracy is a sheep and two wolves deciding what to have for lunch. Freedom is a well armed sheep contesting the issue
Never reboot is a load of crap imo, kernel patches aside, you ought to reboot every now and then just to make sure whole thing is still booting properly after patching, or yet another systemd "improvement". So that you don't get stuck right after power outage when you really need the thing running. Linux *can* run for a long time without ever rebooting - true. But "can" is not "should".
They're usually installed through the ubuntu-restricted-addons package.
> 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.
You do not have a moral or legal right to do absolutely anything you want.
It sounds like these are known issues that just aren't fixed yet on some distributions. That's not a zero day.
https://scarybeastsecurity.blogspot.pt/2016/11/0day-exploit-advancing-exploitation.html
"A powerful heap corruption vulnerability exists in the gstreamer decoder for the FLIC file format. Presented here is an 0day exploit for this vulnerability.
This decoder is generally present in the default install of modern Linux desktops, including Ubuntu 16.04 and Fedora 24. Gstreamer classifies its decoders as “good”, “bad” or “ugly”. Despite being quite buggy, and not being a format at all necessary on a modern desktop, the FLIC decoder is classified as “good”, almost guaranteeing its presence in default Linux installs."
confirmation here:
https://bugzilla.redhat.com/show_bug.cgi?id=1397441
gstreamer-plugins-good: Heap buffer overflow in FLIC decoder
Sheesh, I thought you guys (the parent post and the ones who upvoted) were geeks and into factual information! Oh right, this is slashdot...
What if it's not just some server? It could easily be kodi and emulation station...
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.
Have you not considered the possibility that the developer wanted different runtime guarantees than the standard library sort provided?
There are very good reasons to use something other than the bog standard quicksort with a heap sort fallback (aka introsort) in a lot of scenarios, be they server services or even games.
No, I didnt think so, nor did you find out why the programmer did include his or her own sort, as evidenced by you stating assumptions about it.
For either games or server services, that standard library introsort would never be used if I was head of the development team. No chance in hell does it perform better than radix sort (for game scenarios) or has the best possible worst case runtime (for server services.) Its a complete no-no to use it.
"His name was James Damore."
You're retarded.
Dude!
Differently abled!
In the free world the media isn't government run; the government is media run.
"usually not installed by default in Linux distros" Really?
The Vanilla Ubuntu 16.04.1 desktop image I have at hand shows that it they are installed by default:
Did you check that box during install to install additional codecs that is unchecked by default?
How did these distributions get to the state where they include 80s CPU emulator by default? For users with decent Internet connection, base install should be something like ChromeOS, with only video/audio codecs widely used at present. Then have an easy way to install extra stuff as needed. It's not only for security, stability, memory/storage use and performance is also affected by having a boatload of crap installed by default. And don't forget the amount/frequency of high priority updates.
Good catch! I did indeed install the restricted addons but unless I'm mistaken, thats because the installer prompts that they are needed to have the MP3 decoder.
Democracy is a sheep and two wolves deciding what to have for lunch. Freedom is a well armed sheep contesting the issue
Have you not considered the possibility that the developer wanted different runtime guarantees than the standard library sort provided?
Yes, I have, and find it extremely unlikely that the programmer had any idea what he was doing. Mostly that analysis comes from the knowledge that the particular software package was an interface for a low-speed IO device, and could have probably have performed just fine if it relied on a bubble sort. Then again, I've also worked with the programmer responsible for that particular package, and it wouldn't surprise me to find that he had actually written his own bubble sort...
There are very good reasons to use something other than the bog standard quicksort with a heap sort fallback (aka introsort) in a lot of scenarios, be they server services or even games.
That's not really disputed, but there are third-party libraries that provide many sorting options, without having to write (and debug, and maintain) it yourself. If you have a very good reason to use a particular algorithm, find a library that provides it.
For either games or server services, that standard library introsort would never be used if I was head of the development team. No chance in hell does it perform better than radix sort (for game scenarios) or has the best possible worst case runtime (for server services.) Its a complete no-no to use it.
It sounds like you don't really know much about data processing scenarios. I once had a mentor who said something to the effect of "If you're thinking about your sorting, you're doing something wrong". The reality is that except for the most demanding applications (like rendering on the GPU), the programmer shouldn't need to think about what sorting algorithm is being used. Rather, the programmer's primary concern should be writing clean and maintainable software, and leave the exact implementation to someone else, who only needs to write according to an API specification. If that spec includes performance targets, then it will require particular algorithms. Otherwise, anything reasonably efficient will do the job, and it becomes a point of testing to compare different libraries for required functionality.
For example, let's consider the high-speed sorting used to render a 3D game world. The game programmer just needs to build the world in the game engine, and the engine will handle the sorting. The engine programmer only needs to worry about getting the data from the game library to the renderer, and the renderer will handle the sorting. The render engine programmer finally has to think about sorting algorithms... but his choices are driven primarily by the data structures present and the hardware optimization available, which may drastically change the run times of algorithms. With the appropriate hardware available, the render engine may pass off sorting to the GPU, using some of the SIMD processing capability to (for example) run a Batcher sort, rather than a radix sort on the CPU. I am told that's actually what nVidia's "game-ready" drivers do: They forcibly replace a game's poorly-optimized code with equivalents that use nVidia's hardware more effectively.
On the server side, I will refer to another aphorism: "Premature optimization is the root of all evil". If using a custom sorting method means moving data around outside of your database, you're not going to get a performance improvement. If you're concerned about worst-case performance because you might see it in real use, you should be thinking about security, not performance. If you're optimizing the application to improve user load performance, it's usually cheaper to just buy more hardware and run more back-end servers. In short, sorting is rarely the most effective target for optimization, so it's generally not worth the cost to improve, when efforts could be focused elsewhere.
You do not have a moral or legal right to do absolutely anything you want.
If sorting is occurring in a performance-critical part of your code, that's probably a good idea.
But it's also hard to deny that a lot of developers will write their own sorts, etc. based on an imagined need that isn't actually there, and likely introduce needless bugs and quite possibly performance losses into their program as a result. Because let's face it - it's seriously nontrivial to write a bug-free sorting library that can outperform the optimized quicksort (or whatever) that's probably included in your languages standard library.
Radix is possibly an exception as it's relatively straightforward to implement, but comes with rather abysmal memory overhead if you're not able to exploit the existing data list infrastructure. (For those unfamiliar - radix sorting a linked list can be done with very little (and O(1) ) memory overhead, *if* you can reuse the original list nodes to store the data within the intermediate bins). I can only assume that, along with the limitations of requiring a fixed-length key, explains the fact that it's not more commonly included in general-purpose libraries.
That, and perhaps the fact that virtually all descriptions I've seen show it using base ten digits, which severely hobbles its performance compared to using base 256 (or more) instead. You would hope such a large reduction of complexity constants would be obvious, but I've been dismayed at how many otherwise competent people have completely overlooked it - some even initially questioned whether it was actually a radix sort at all.
--- Most topics have many sides worth arguing, allow me to take one opposite you.
In some cases, a complete sort isn't needed either, just a pigeonholing routine with adjustable bucket sizes. Using a full sort routine can then be very much slower than needed.
But what the GP post alluded at is that the interdependencies of 3rd party libraries can be humongous. It may be easy to "just" link with a library that provides a small routine, but when that in turn pulls in 10 other libraries, which in turn pull in 20 more, it becomes both a dependency nightmare and bad bloat. .a, even if it means you have to recompile your code to fix security holes instead of automatically get it with a library. .so, at least you won't have to rebuild all, but just that ,so
So in some cases, it pays off to write your own equivalent or link with an
If you single it out in your own
A big reason for that is that most distros are designed around a minimalist base install. Anything beyond that is pulled in through comprehensive dependencies in packages. Sometimes packages do list dependencies that aren't actually necessary on the principle that an unnecessary dependency results in a working system but a missing one leaves things broken. You'll see that most frequently in GUI/desktop oriented packages.
It's a harder problem still if the software dynamically loads libraries as needed. Strictly speaking, it doesn't absolutely depend on libfoo to run and do some useful things, so you could argue that it's not a dependency, but then the user may want to do foo and get surprised that it fails with a missing library message.
If only there were a way to define a generic way to tell if two "things".... let's call them "objects".. relate to each other when doing sorting. Then, for each "object", you could compare it to another "object" and see if it is less than, greater than, or equal to the other.
I know, we can make a generic "function" of an "object", and call it.... "less". If you're in a sane language (sorry, Java), you could even use the "<" symbol to compare two "objects". Then, any sort algorithm can use this function to compare two "objects" and figure out where it should go in the list.
Then, we can put this algorithm in some sort of "library"... maybe a "standard library" in which sort algorithm developers can implement different sorting methods. Then the programmer uses this "standard library" to sort his/her list of "objects".
Apologies to anyone who's using C and actually DOES need to implement their own sort, but if you're using literally any language developed in the past 30 years, you have no business implementing your own sort function outside of a homework assignment. The only potential exception to this is if you are in fact a developer of sorting algorithms, and all 3 of them know who they are.