GStreamer and the state of Linux desktop security
Recently Chris Evans, an IT security expert currently working for Tesla, published a series of blog posts about security vulnerabilities in the GStreamer multimedia framework. A combination of the Chrome browser and GNOME-based desktops creates a particularly scary vulnerability. Evans also made a provocative statement: that vulnerabilities of this severity currently wouldn't happen in Windows 10. Is the state of security on the Linux desktop really that bad — and what can be done about it?
From Chrome via Tracker to GStreamer
The scenario Evans described allows exploiting security vulnerabilities in a wide variety of applications by drive-by downloads by the Chrome browser without any user interaction. By default, Chrome automatically saves downloaded files in the "Downloads" subdirectory of the user's home directory. This particular behavior is unique to Chrome. Other browsers show a dialog on downloads and let the user choose a location to save a file. With this behavior a web page can automatically cause downloads. No user interaction is required, even the click on a download link can be triggered via JavaScript. Chromium, which is the free-software variant of Chrome and is usually the one packaged by Linux distributions, behaves in the same way.
Chrome's behavior isn't unique to Linux, but in combination with another feature it becomes dangerous: on GNOME desktops a service called Tracker automatically indexes all new files. (KDE has an analogous tool called Baloo that has similar problems.) Tracker uses a variety of tools and libraries to extract metadata from files. For media files Tracker uses the GStreamer framework. Images are parsed with ImageMagick and PDF files with Poppler. Thus we end up in a situation where downloads automatically triggered by a potentially malicious web page are directly passed to various parsers of complex file formats. Most of these parsers are written in C, which makes them susceptible to the typical memory-corruption vulnerabilities. Tracker is enabled by default, though it can be controlled by running tracker-preferences.
GStreamer is a multimedia framework that includes support for a wide variety of file formats, including some obscure and rare ones. Evans pointed out bugs in the parsers for Nintendo Sound Files (from NES games), for a VMware screen-capture format, and for FLIC animations, the file format of the DOS Software Autodesk Animator, which had its last release 21 years ago. The codecs for the latter two are part of the default GNOME installations on both Fedora and Debian.
GStreamer plays almost every media file ever created
GStreamer has a noble goal: it tries to allow users to play almost every audio or video file ever created. From a usability perspective, this is certainly valuable and often considered a strength of free and open-source software. For almost every file format out there, there's some software that is able to access it. Having software available to play arcane media files also plays an important role in keeping the history of the digital age accessible. But these projects come with a cost when it comes to security. Parsing complex binary file types in a secure way is an incredibly difficult task. It's not surprising that many parsers have memory-corruption vulnerabilities.
Thus the decision of GNOME's Tracker software to use these parsers is a questionable design choice. GStreamer is not the only problematic software used by Tracker. ImageMagick has a purpose similar to that of GStreamer. It supports reading 177 different image formats and it has seen a constant flow of vulnerability reports over the years. Many other libraries that Tracker uses to identify ISO images, extract MP3 tags, or parse playlists look at least potentially problematic. Again, from a usability perspective, the choices made by Tracker make sense. For a desktop search, being able to parse the metadata of a wide variety of different file types is a desirable feature. But security-wise it looks like a recipe for disaster.
It is no secret that many libraries were never written with security in mind. In the past few years the availability of increasingly powerful fuzz testing tools like american fuzzy lop (afl) has shed a light on this. There's a small number of libraries where security vulnerabilities are relatively rare and hard to find. Usually these are the libraries used by the large browser vendors. The generous bug bounties paid by browser makers give security researchers an incentive to investigate vulnerabilities. Also the browser vendors themselves have an interest in securing the code they are exposing and often use their own infrastructure to test them or fund audits for key libraries.
The situation for other, less exposed libraries is much more dire. When looking at a random library that parses complex file formats, it is likely that one can find crashes caused by memory-corruption vulnerabilities within seconds. To help combat this problem, I started the Fuzzing Project two years ago. The Fuzzing Project is a concentrated effort to wipe out the many bugs that can easily be found with fuzz testing in popular free and open-source software.
In the case of GStreamer, it is likely that before Evans's reports nobody ever tried to use modern coverage-based fuzzing tools on the code base. After Evans's post, though, I ran afl on GStreamer and found several bugs that the GStreamer team quickly fixed. But even if the GStreamer code base could be secured, which itself is a huge challenge, the problem goes deeper: GStreamer doesn't only contain its own parser, it makes use of a wide variety of libraries for different file formats. Properly testing and fixing all of them is an enormous task.
Prevention techniques
The prevalence of memory-corruption vulnerabilities in software written in C and C++ has recently fueled a debate on whether a switch to safer programming languages could avoid many of these problems. The programming language Rust, which is developed by Mozilla, is often cited as the most likely alternative to C. GStreamer has recently started to investigate the ability to write plugins in Rust. While these are worthy efforts, rewriting software in another programming language takes time. Realistically, most of the software underpinning the Linux desktop will stay as C code for a very long time.
In the IT security world, most people agree that it's not realistic to avoid all security bugs. Therefore a lot of effort has been put into mitigation techniques that make it hard or impossible to exploit security vulnerabilities. Various sandboxing efforts try to separate processes from each other and limit the impact of security vulnerabilities.
According to Evans, a tool like Tracker is an almost ideal target for sandboxing:
On Linux, the generic sandboxing framework provided by the kernel is seccomp. There's an open bug in the GNOME bug tracker about sandboxing the Tracker data collection process. A preliminary patch using libseccomp to sandbox that process has been posted in the bug.
Operating systems and compilers also try to make exploitation harder with mitigation techniques that avoid typical exploit paths for memory-corruption vulnerabilities. Stack canaries and non-executable memory pages are widely used on all modern operating systems. However the Linux community has been slow in adopting one of the strongest mitigation techniques available: address space layout randomization or ASLR. Exploitation techniques like return-oriented programming (ROP) rely on the fact that an attacker can jump to existing code in memory. However, in order to do that the attacker needs to know the address of that code. Thus modern operating systems can place code at randomized addresses in memory.
ASLR was originally invented by the PaX project as a patch to the Linux
kernel in 2001. The mainstream kernel got ASLR support in version
2.6.12, released in 2005. However, to properly randomize all of the code, the
executable files need to be compiled as position-independent executables
using the -pie compiler flag. For a long time, most Linux distributions
didn't use position-independent executables by default. Fedora started
switching on -pie by default in version 23, released in 2015. Both
Debian
and Ubuntu still enable -pie only for selected packages. [Update: As pointed out in the comments, Ubuntu 16.10 does enable -pie by default for several architectures, including amd64.] However,
recently
there have been some
efforts to push
enabling the flag by default in Debian. Recent GCC
versions will make the transition to position-independent executables
easier. Since version 6,
GCC's configure script has an option --enable-default-pie that allows
changing the compiler's default. While this is welcome news, ASLR is no
panacea: Evans was able to write multiple exploits ([1],
[2])
for GStreamer bugs that work even on Fedora systems with ASLR enabled.
More advanced exploit mitigations are currently being discussed under the umbrella term of "control-flow integrity". Modern versions of the clang compiler support such features, but they haven't been widely adopted.
Has Linux desktop security rotted?
Evans had some unpleasant thoughts for the Linux community:
The free-software community is often proud that switching to a Linux desktop is an almost surefire way to avoid many of the security issues that plague users of the Windows operating system. Malware for Linux desktops practically doesn't exist. However a lot of that added security may simply be attributable to the fact that fewer people use Linux and thus it is a less attractive target for malware authors. If the Linux desktop wants to stay a secure choice for users it needs to strengthen its security. Bug finding techniques, safer programming languages, sandboxes, and additional exploit mitigation techniques can all play a role in this.
| Index entries for this article | |
|---|---|
| Security | Desktop |
| GuestArticles | Böck, Hanno |
Posted Dec 7, 2016 20:49 UTC (Wed)
by ncm (guest, #165)
[Link] (34 responses)
It seems worth noting that Raph Levien has implemented, and is further developing, a font renderer in Rust that is substantially faster than the C alternatives, and inherently safer. For the same reasons as for media, browsers probably should render fonts in a sandbox. In my browser I have turned off permission to use page-specified fonts, partly for this reason, and partly because page-specified fonts are almost uniformly ugly. But if you're going to download fonts from random places, it seems fantastically unwise to feed them into untrustworthy renderers.
The value of randomized placement of code in memory ("ASLR") has, I think, been overestimated. Malware is already adapting. Code written to be inherently secure, by whatever means, is better than passive avoidance.
Posted Dec 7, 2016 21:17 UTC (Wed)
by Cyberax (✭ supporter ✭, #52523)
[Link] (13 responses)
Posted Dec 8, 2016 12:18 UTC (Thu)
by paulj (subscriber, #341)
[Link] (12 responses)
It can't cut out higher-level logical errors, but it can cut out a class of some of the worst C/C++ errors. Such an abstraction is _trivial_ to write. It is *amazing* we're still writing C/C++ parsers of network supplied input that don't use them.
Posted Dec 8, 2016 12:55 UTC (Thu)
by Karellen (subscriber, #67644)
[Link] (11 responses)
It would be entirely possible to create a new virtual architecture/ABI for any given existing real architecture, such that all int/float handling is done "natively", but all pointers are represented as fat pointers which know the bounds of what they point to, and all pointer accesses are checked for validity before they are executed. Voila! Suddenly you can compile all your currently existing code either for speed, or for security, depending on your needs, without rewriting any of it.
If only I had a year free to spend on such a project...
Posted Dec 8, 2016 13:05 UTC (Thu)
by paulj (subscriber, #341)
[Link]
Note, you can achieve it already by running programmes under valgrind. We just need a kind of valgrind optimised for "run things safely, as fast as possible" rather than for debugging?
Posted Dec 8, 2016 14:19 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (3 responses)
This really requires a special language, C doesn't really cut it. One early attempt was Cyclone with simple region inference, but it was pretty pessimistic with lifetimes as it pretty much always assumed the worst case. The newest attempt is , of course, Rust.
Posted Dec 8, 2016 19:53 UTC (Thu)
by thestinger (guest, #91827)
[Link] (2 responses)
Posted Dec 8, 2016 21:05 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (1 responses)
char * str2 = str+10;
str2[1] = 1; //Ooops
Posted Dec 8, 2016 22:51 UTC (Thu)
by paulj (subscriber, #341)
[Link]
Wrt handling of untrusted input and the correct management of the lifetime of objects that arise from the input, this class of bug can still be removed by making that management be determined by the parsing of the input, in a well-structured manner. If the parser reads input that needs a "foo" object, the parser creates that object, and generally creates an over-arching structure that describes the input.
Yes, there's lots of other bugs that are possible, that's true in all languages. However, it is definitely within the ken of CS to write well-behaved, robust parsers, to take untrusted input and turn it into a correct (no use-after-free bugs), abstract representation if well-formed, or safely raise an error - ideally at the logical parser level, otherwise as an assertion of some kind at a lower bounds checking level. Even with "unsafe" languages like C.
Certainly, we can do a lot better than we're doing. We just need to collectively start saying "No!" to hand-rolled pointer-twiddling parsers, that people still insist on writing...
Posted Dec 8, 2016 14:48 UTC (Thu)
by epa (subscriber, #39769)
[Link] (3 responses)
Posted Dec 8, 2016 21:34 UTC (Thu)
by Cyberax (✭ supporter ✭, #52523)
[Link] (2 responses)
// possibly other malloc()
There's nothing here that is an invalid C. Interpreter will still happily corrupt the memory, perhaps giving the attacker ability to overwrite sensitive data. They might not be able to actually use the regular "overwrite the stack pointer" exploits but there are still lots of other ways to do damage.
Posted Dec 8, 2016 22:53 UTC (Thu)
by paulj (subscriber, #341)
[Link] (1 responses)
Posted Dec 9, 2016 5:00 UTC (Fri)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Valgrind is also not an interpreter, it's a machine simulator that annotates RAM.
Posted Dec 9, 2016 19:10 UTC (Fri)
by faramir (subscriber, #2327)
[Link] (1 responses)
You could start with this (apparently) defunct research project:
http://web.archive.org/web/20040409193128/http://manju.cs...
from over a decade ago. The problem isn't that we don't know how to make even our legacy code more secure, it is that we aren't willing to pay the performance penalty to
Posted Dec 9, 2016 20:50 UTC (Fri)
by roc (subscriber, #30627)
[Link]
One of the most exciting things about Rust is that it doesn't have this problem. It's actually more compatible with C than these "safe versions of C".
Posted Dec 7, 2016 23:42 UTC (Wed)
by roc (subscriber, #30627)
[Link] (16 responses)
More code operates on untrusted input than you think. For example, a user might download a SQLite database from somewhere on the Internet and expect to be able to read its contents without handing control to malicious code. Therefore SQLite databases should be treated as untrusted.
For most libraries and applications, it's very difficult to be sure they will now and forever operate only on trusted input. Thus, it is irresponsible to write code in languages that are prone to bugs allowing untrusted input to execute with higher privileges.
Posted Dec 8, 2016 12:39 UTC (Thu)
by paulj (subscriber, #341)
[Link] (8 responses)
The rest of the programme then acts on that abstract representation.
The logical layers of the parser can further be made robust against logical errors by specifying the lower, regular portions of the parser as FSMs. This can make it easier to ensure that invalid inputs always result in an error, and further that such error conditions are then handled by shared, common error handling code. Shared error handling code is better tested error handling code. Further, an FSM can be checked programmatically to ensure that all paths through it always reach a terminal (success/error) state given finite input.
We do know how to protect ourselves against bugs and write robust parsers, even in 'unsafe' languages. The tragedy is so often we don't use those techniques.
Instead we go for hand-rolled parsers that directly twiddle buffer pointers based on input, with ad-hoc error checks sprinkled in. Then we're surprised when it blows up in interesting ways. Even the latest, shiniest, high-profile Linux system daemons are using that style of programming...
Posted Dec 8, 2016 12:43 UTC (Thu)
by paulj (subscriber, #341)
[Link]
Protect ourselves better against classes of bugs around low-level handling of input, which are catastrophic in 'unsafe' langs like C/C++. We _can_ pretty much make them just as safe as Java, if we'd just use a decent 'safe' input abstraction... It's not even difficult.
That is.
Posted Dec 8, 2016 12:56 UTC (Thu)
by spender (guest, #23067)
[Link] (1 responses)
I mentioned weird machines in the context of the current state of the art in exploitation (mostly happening currently in private or for profit for various corporations/governments, but which will become the public standard in the future) in my SSTIC keynote this year:
-Brad
Posted Dec 9, 2016 0:37 UTC (Fri)
by clemensg (guest, #94377)
[Link]
Posted Dec 8, 2016 19:22 UTC (Thu)
by roc (subscriber, #30627)
[Link] (3 responses)
For example, the GStreamer vulnerability which is the basis for this very article would not have been prevented by those approaches. It did not rely on an overflow reading the input buffer, nor on a syntactically malformed input file.
Posted Dec 8, 2016 20:05 UTC (Thu)
by kh (guest, #19413)
[Link] (2 responses)
Posted Dec 8, 2016 20:13 UTC (Thu)
by alankila (guest, #47141)
[Link]
But programs written in Java are still safe, in ways that C programs are not.
Posted Dec 8, 2016 21:01 UTC (Thu)
by roc (subscriber, #30627)
[Link]
Also, "the panacea that some seem to think it is" is a straw-man distraction. No-one here has talked of a panacea.
Posted Dec 9, 2016 0:34 UTC (Fri)
by clemensg (guest, #94377)
[Link]
Posted Dec 8, 2016 15:58 UTC (Thu)
by drh (guest, #65025)
[Link] (6 responses)
Just to be clear, the SQLite developers are fully aware that applications often read SQLite databases obtained from untrusted sources, and so SQLite is designed
and tested to be rebust in the face of maliciously malformed database files. There is a lot of sanity checking going on inside of SQLite's file format parsing, some if it inside of performance-critical loops. SQLite would be measurably faster if it were allowed to assume that all database files are well-formed. But safety must come first.
A lot of testing goes into ensuring that SQLite is robust when reading malformed database files. There are specific tests for developer-devised corner cases. And there are many home-grown fuzz tests. Last year, we started running AFL on SQLite database files and found several new problems that way (mostly assertion faults).
I challenge you to find any database file that will cause problems for SQLite - where "problem" is defined as a buffer overwrite, segfault, use-after-free, signed integer overflow or other UB, or even just an unreasonable performance delay. Any such findings will be considered a high-priority bug and fixed expeditiously - usually within 24 hours.
Posted Dec 8, 2016 19:11 UTC (Thu)
by roc (subscriber, #30627)
[Link] (5 responses)
It sounds like you're doing good things. It might be worth investigating process sandboxing as well, i.e. making it easy to isolate database file parsing and I/O into a process running with low privileges and communicating with the client via a restricted protocol. It would be better to be writing the code in a different language, but I understand the practicalities of legacy code.
Posted Dec 9, 2016 1:12 UTC (Fri)
by anselm (subscriber, #2796)
[Link] (4 responses)
The SQLite developers already go to incredible lengths to make sure their code is correct.
Read How SQLite Is Tested.
Posted Dec 9, 2016 2:08 UTC (Fri)
by roc (subscriber, #30627)
[Link] (3 responses)
Posted Dec 9, 2016 13:34 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (2 responses)
Posted Dec 9, 2016 13:48 UTC (Fri)
by drh (guest, #65025)
[Link] (1 responses)
We often get reports of malloc-related segfaults in SQLite. This is almost always due to the application (not SQLite) corrupting the heap and then SQLite just being the first unlucky library to stumble over the damage. This is a hazard of running the SQL engine in the same address space as the application.
We run the 100% MC/DC test suite of SQLite under valgrind and UBSan and using various debug versions of malloc, all with no errors or warnings. SQLite does not have problems related to memory allocation.
If, on the other hand, you have a test case, then I will eat my words and quickly fix the problem. Until then, I stick by my assertion: malloc-related problems in SQLite are the fault of the application.
Posted Dec 9, 2016 14:13 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link]
Posted Dec 8, 2016 4:35 UTC (Thu)
by liam (guest, #84133)
[Link] (2 responses)
Posted Dec 10, 2016 13:52 UTC (Sat)
by intgr (subscriber, #39733)
[Link] (1 responses)
Posted Dec 11, 2016 10:21 UTC (Sun)
by liam (guest, #84133)
[Link]
Posted Dec 7, 2016 21:03 UTC (Wed)
by mrshiny (subscriber, #4266)
[Link]
Posted Dec 7, 2016 21:28 UTC (Wed)
by davidstrauss (guest, #85867)
[Link] (10 responses)
I don't even have to go back six months to find the last major virus scanner vulnerability:
Posted Dec 8, 2016 17:01 UTC (Thu)
by cortana (subscriber, #24596)
[Link] (9 responses)
Posted Dec 8, 2016 18:00 UTC (Thu)
by davidstrauss (guest, #85867)
[Link]
Many OEMs ship a different scanner that doesn't sandbox its analysis. The question of whether Microsoft would allow a similar attack surface in Windows 10 should also come down to whether (1) Microsoft allows/encourages use of vulnerable alternatives and (2) what the majority of machines run by default or intentional configuration. Otherwise, I could argue that Linux desktops don't inherently run Tracker, even if most distributions do run it (or equivalent).
Posted Dec 8, 2016 21:14 UTC (Thu)
by flussence (guest, #85566)
[Link] (3 responses)
On the other hand, a lot of similar software is just a giant trash fire. I don't have the twitter conversation link to hand, but some AV mouthpiece was throwing an abusive tantrum in public just a few days ago at a Chrome security person, all because the browser uses ASLR and sandboxing responsibly making it too hard to backdoor at runtime. This massive sense of entitlement these self-styled “security industry professionals” have is completely f'ing insane.
Posted Dec 9, 2016 1:58 UTC (Fri)
by roc (subscriber, #30627)
[Link] (2 responses)
It's not uncommon for AV download monitoring to block software updates, thus making the browser less secure or completely unusable.
AV software likes to patch the browser in arbitrary ways, so from time to time you get crashes when changing something internal they depend on. This is of course is treated by users as a Firefox crash, not an AV software crash. Good luck finding someone competent at the AV company to help.
There was (probably still is) some German "banking" "security" software that relied on a PE parser to dissect the Firefox executable. Some trivial change in the Firefox binary hit an edge case in their PE parser causing it, and consequently Firefox, to crash on startup, making Firefox completely unusable. Mozilla devs looked for a way to disable this invasion, and got scolded by the vendor for daring to consider "disabling security".
Given the inability of AV software to detect modern threats until it's too late, and the general demonstrated incompetence of their developers and extra attack surface AV software introduces, I suspect real-world users might be safer disabling their AV software (other than Windows Defender probably). I'd love to know if anyone credible has good data on that.
Posted Dec 18, 2016 20:19 UTC (Sun)
by joib (subscriber, #8541)
[Link] (1 responses)
Well, google apparently has some internal data suggesting AV isn't that useful: http://www.theregister.co.uk/2016/11/17/google_hacker_ple...
Posted Dec 18, 2016 20:39 UTC (Sun)
by Cyberax (✭ supporter ✭, #52523)
[Link]
Posted Dec 9, 2016 0:56 UTC (Fri)
by JanC_ (guest, #34940)
[Link] (3 responses)
Posted Dec 9, 2016 1:41 UTC (Fri)
by JanC_ (guest, #34940)
[Link] (2 responses)
Posted Dec 9, 2016 1:43 UTC (Fri)
by spender (guest, #23067)
[Link] (1 responses)
Posted Dec 9, 2016 4:43 UTC (Fri)
by JanC_ (guest, #34940)
[Link]
Based on Wikipedia, MSE got basic heuristics in 2010 (something that many other antivirus had around or even before the time the first linux release happened) but not an emulator, and it doesn't really list any essential improvements since then. If that's true, its anti-virus/anti-malware technology is about 25 years out of date by now… :)
In other words: it would be nice to see some actual documentation about how it works.
Posted Dec 7, 2016 22:10 UTC (Wed)
by SLi (subscriber, #53131)
[Link] (2 responses)
Posted Dec 8, 2016 21:28 UTC (Thu)
by flussence (guest, #85566)
[Link]
I had plenty of headaches from it a few months back, trying to run a home server for a group of friends and the ones using Firefox simply couldn't connect no matter what I tried. The dumbed-down error messages all browsers present to the user certainly don't help matters.
Posted Dec 19, 2016 10:02 UTC (Mon)
by gerv (guest, #3376)
[Link]
Gerv
Posted Dec 7, 2016 23:04 UTC (Wed)
by sjj (guest, #2020)
[Link] (2 responses)
Looking at dconf: org/freedesktop/tracker/miner/files, it may be that you can add to "ignored-directories" or put a .trackerignore file into a directory. I added .trackerignore to ~/Downloads, FWIW.
Posted Dec 8, 2016 0:05 UTC (Thu)
by ocrete (subscriber, #107180)
[Link] (1 responses)
Posted Dec 8, 2016 1:02 UTC (Thu)
by sjj (guest, #2020)
[Link]
Posted Dec 8, 2016 2:27 UTC (Thu)
by joey (guest, #328)
[Link]
Seems like both a problem with granularity (cheese should be able to depend on only the codecs it actually makes sense for it to use), and a problem that installing the codecs for one program can affect the attack surfaces of other programs.
Posted Dec 8, 2016 4:30 UTC (Thu)
by liam (guest, #84133)
[Link]
The only group who seem to care, IMHO, are the distros.
Posted Dec 8, 2016 6:39 UTC (Thu)
by Garak (guest, #99377)
[Link] (5 responses)
Posted Dec 8, 2016 8:36 UTC (Thu)
by Sesse (subscriber, #53779)
[Link] (3 responses)
(From experience with debugging both, FFmpeg's code seems to be of significantly higher quality, too. I'm not at all surprised that GStreamer is the chosen target here.)
Posted Dec 9, 2016 1:22 UTC (Fri)
by JanC_ (guest, #34940)
[Link] (2 responses)
So even for ffmpeg it's probably true that most of the fuzzing efforts go to the more common codecs?
Posted Dec 9, 2016 13:01 UTC (Fri)
by Sesse (subscriber, #53779)
[Link] (1 responses)
If you look at the FFmpeg CVEs, it seems it gets fuzzed basically everywhere. Same with Wireshark; most of the CVEs are in dissectors for protocols I've never heard of.
Posted Dec 12, 2016 0:29 UTC (Mon)
by JanC_ (guest, #34940)
[Link]
So, GStreamer should get a similar treatment and be fuzzed to hell, but clearly that isn't enough, and applications like that should always run in a way that the rest of the system is protected from whatever leftover bugs are still around (because otherwise one bug in one obscure format is enough to abuse it).
Posted Dec 15, 2016 9:05 UTC (Thu)
by robbe (guest, #16131)
[Link]
Not to paint too nice a picture of Mr Gates here, but he would probably point out that he does not have any executive power in the company anymore, and prefer not getting his hands dirty.
The more likely scenario is that one of the nameless people responsible for signing updates will get a National Security Letter compelling her to sign a special update. Anybody who by necessity notices this will also be silenced via NSL. Note that this works equally well whether the software vendor is RedHat, Apple, or Microsoft.
It works less well, or at least less surreptitiously, if the vendor has the people who would notice spread to different jurisdictions. Is any company doing this? If not, why not? Companies incorporate in favourable tax-regimes all the time.
Posted Dec 8, 2016 9:59 UTC (Thu)
by ballombe (subscriber, #9523)
[Link] (7 responses)
Posted Dec 8, 2016 12:53 UTC (Thu)
by jtaylor (subscriber, #91739)
[Link]
Ideally all code would be secure and sandboxing not necessary, but this is just an unrealistic goal and you can never be sure you are done.
I like apparmor for this, it is quite easy to setup profiles for your common desktop applications (browser, email, messengers, media players, ...) which can at least protect you against some untargeted attacks.
Posted Dec 8, 2016 13:09 UTC (Thu)
by mcatanzaro (subscriber, #93033)
[Link] (1 responses)
Anyway, of course the real problem here is GStreamer. I guess distros are going to have to separate the -bad plugins into individual subpackages if they want to be robust to such issues.
Posted Dec 9, 2016 1:30 UTC (Fri)
by JanC_ (guest, #34940)
[Link]
Posted Dec 8, 2016 22:50 UTC (Thu)
by rgmoore (✭ supporter ✭, #75)
[Link]
Pointing the finger at somebody else is a terrible way of dealing with security. Even if chromium (and Chrome) patch their projects to stop unintended downloads, that still leaves a gigantic security hole in GNOME waiting to be exploited by the next person who can figure out how to get a file onto your system. Every identified security bug needs to be patched, even if there's no obvious way of exploiting it. Once the vulnerability is known to exist, somebody will find a way to exploit it.
Posted Dec 12, 2016 13:17 UTC (Mon)
by MarcB (subscriber, #101804)
[Link] (1 responses)
Posted Dec 12, 2016 20:07 UTC (Mon)
by flussence (guest, #85566)
[Link]
Posted Dec 13, 2016 20:42 UTC (Tue)
by jwarnica (subscriber, #27492)
[Link]
Posted Dec 8, 2016 13:19 UTC (Thu)
by mdeslaur (subscriber, #55004)
[Link]
That's inaccurate. As of Ubuntu 16.10, pie is the default on amd64, ppc64el and s390x.
Posted Dec 9, 2016 6:42 UTC (Fri)
by pabs (subscriber, #43278)
[Link] (4 responses)
Posted Dec 9, 2016 9:43 UTC (Fri)
by ovitters (guest, #27950)
[Link] (1 responses)
> First of all, I’m glad to tell that Tracker now sandboxes its extractors, so
Posted Dec 9, 2016 13:35 UTC (Fri)
by cortana (subscriber, #24596)
[Link]
Posted Dec 11, 2016 11:00 UTC (Sun)
by Tobu (subscriber, #24111)
[Link] (1 responses)
Another thing I got from the article is the difference between a modular design and open-ended plugin loading.
Tracker (tracker-extract) loads a closed set of plugins, which can be vetted.
Posted Dec 11, 2016 17:23 UTC (Sun)
by tpm (subscriber, #56271)
[Link]
Posted Dec 9, 2016 12:41 UTC (Fri)
by tdz (subscriber, #58733)
[Link] (2 responses)
Regarding memory safety, it's usually a question of software design. In a well-designed program, it is harder to accidentally create the typical out-of-bounds or use-after-free problems. Some languages, such as Modern C++ or Rust, provide the building blocks for implementing such designs.
But even Modern C++ or Rust allow for bypassing their protection mechanisms. As soon as they get used more often, I expect that 'the bad programmers' will work around the languages' memory-safety features; for convenience or ignorance.
Another problem, which the article mentioned, is that software isolation often isn't very good. I don't know the specifics of tracker and it's helpers, but it should be trivial to run each helper tool in a separate process with minimal permissions; and then let tracker pipe the data into this process.
Posted Dec 9, 2016 13:35 UTC (Fri)
by mathstuf (subscriber, #69389)
[Link] (1 responses)
Yeah, but at least in Rust, it's called `unsafe` which is pretty blatent when it gets used (personally, I've only needed it in my own code for FFI bindings). C++ has more subtle escape hatches.
Posted Dec 11, 2016 11:23 UTC (Sun)
by tdz (subscriber, #58733)
[Link]
Posted Dec 11, 2016 17:38 UTC (Sun)
by tpm (subscriber, #56271)
[Link] (1 responses)
Not sure why that is "likely". I think that if that was actually the case, you would likely have found hundreds of crashes and other critical issues all over the place within seconds :)
Posted Dec 11, 2016 21:12 UTC (Sun)
by hannob (guest, #104551)
[Link]
Sure, quite a bunch, but the Gstreamer team was very quick on fixing those.
What I find important here: This is not a totally lost cause. One can make these things much more resilient and we have the tools to do so.
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
--
char * str = (char*)malloc(100);
//fill in str
free(str);
--
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
--
char *str1 = malloc(100);
//fill-in str1
char *str2 = str1 + 16;
free(str1);
str2[1] = 123;
--
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
do so. As long as features, performance, backward compatibility, and (more recently) data collection for advertisers are goals that are valued more highly than security; I see truly making our software systems secure to be an impossible goal.
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
http://www.cs.dartmouth.edu/~sergey/langsec/
https://grsecurity.net/SSTIC2016.pdf
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
https://heimdalsecurity.com/blog/java-biggest-security-ho...
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
Would you recommend implementing FSM-based parsers (from scratch) instead of using parser generators like bison?
Can you point to articles/papers describing this method?
So far I only found www.cs.dartmouth.edu/~pete/pubs/LangSec-2014-fsm-parsers.pdf
GStreamer and the state of Linux desktop security
> a user might download a SQLite database from somewhere on the Internet and
> expect to be able to read its contents without handing control to malicious code.
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
> AFL has also found a fair number of crash bugs in SQLite, and even a few cases where SQLite computed incorrect results.
So there are probably still hidden bugs worth defending against.
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
As a result, it would seem that any efforts to reduce bugs of any type (well, probably......) are worthwhile.
GStreamer and the state of Linux desktop security
Sure, but I wasn't as much referencing the article as this comment by ncm:
GStreamer and the state of Linux desktop security
The comments about Rust as an alternative seem to miss that the overwhelming majority of software at risk does not need to be rewritten. Mainly it is the code that operates on untrusted input -- media and fonts, in particular -- that needs a rewrite.
ncm then went on to specify that we need to focus on the code that handles foreign data (so, mostly a parsing issue).
My point was to simply reiterate Linus' stance because, aiui, the reason "a bug is a bug" is because it's far from obvious that bugs which aren't tagged as security issues can't be used by malicious actors to help them achieve their goal.
So, it's not that I expect people to obey Linus but simply I thought it worth recalling his thoughts on this matter (again, aiui).
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
https://www.wired.com/2016/06/symantecs-woes-expose-antiv...
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
Certainly not the major enterprise corps, or they would invest more than a token into the area.
Although you can install, for the most part (looking at you,Unity), any DE on any distro, "Most Distro Users Run With Their Default DE"(TM).
back to basic bug bounties
The free-software community is often proud that switching to a Linux desktop is an almost surefire way to avoid many of the security issues that plague users of the Windows operating system.
Microsoft probably noticed this a decade ago, learned from it, and has taken as much advantage of that newfound wisdom as they can. It's time for the FOSS side to realize that temporary tactical advantage, to the extent it ever really existed, may well be gone for good. Or rather, the only way to get it back will be for the Linux Desktop to achieve at least 50% or so of Total World Domination. I still have long term hopes that the *other important fundamental benefits of FOSS* will lead to this, but I'm not at all optimistic about this front in the coming few years(*).
For a desktop search, being able to parse the metadata of a wide variety of different file types is a desirable feature. But security-wise it looks like a recipe for disaster.
Right, if you want more security, minimize the amount of code in the system. Back to basics folks.
This was too easy. It should not be possible to find a serious memory corruption vulnerability in the default Linux desktop attack surface with just a few minutes of looking.
The solution to this is the same as it has ever been- bug bounties. Whatever you managed to do in a few minutes, put a $100USD bounty up, along with budget to satisfy the first 100 takers. Then learn from that experience and take it from there. I've been waiting decades to see more of that going on. When we see code that successfully defends piles of spendable money from the entire nation or world's worth of tinkerers, then I'll trust it. Until then I'll assume it's bug ridden, however also realizing that bug-ridden FOSS code is still extremely valuable for many, but certainly, certainly not all tactical situations.
(*) adding for nuance that 'plague' is a broad term. I'm willing to admit that were I a windows user, I would 'feel plagued' by the knowledge that Bill Gates on a whim could run whatever code on my system he wants, perhaps because he got a big check or secret letter from Donald Trump. OTOH I also understand how in the modern world, the NSA can probably have the same relative dominance over the vast majority if not all FOSS zealots that aren't fabbing their own processors on their island estates or underground bunkers/dungeons.
back to basic bug bounties
back to basic bug bounties
back to basic bug bounties
back to basic bug bounties
Bill Gates slipping malware under my mattress
> wants, perhaps because he got a big check or secret letter from Donald Trump.
GStreamer and the state of Linux desktop security
Allowing webpage to create files without the user consent is a major security issue by itself.
(it is a general security principle that arbitrary file creation is arbitrary code execution).
GStreamer and the state of Linux desktop security
Restricting what a program that reads untrusted data can do is somewhat more scalable and should always be done in addition to fixing the actual bugs in these programs.
In this case restricting the tracker application does seem trivial. It should only need a very restricted set of capabilities to function.
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
It i a bit unfair to call this a GNOME vulnerability where this is squarely a chromium bug.
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
> its only point of exposure to exploits is now much more constrained,
> leaving very little room for malicious code to do anything harmful.
> This fix has been backported to 1.10 and 1.8, and new tarballs rolled,
> everyone rejoice.
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
But the Gstreamer tracker plugin seems to load an open-ended set of gstreamer plugins, which includes parsers for ridiculously unpopular formats. Gstreamer needs to provide an api to reduce this set. Not at the package level, otherwise installing a random application would indirectly reduce the security of Chrome downloads, but through some kind of file or plugin name or mime whitelist.
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
GStreamer and the state of Linux desktop security
> ever tried to use modern coverage-based fuzzing tools on the code base.
GStreamer and the state of Linux desktop security