LWN: Comments on "GStreamer and the state of Linux desktop security" https://lwn.net/Articles/708196/ This is a special feed containing comments posted to the individual LWN article titled "GStreamer and the state of Linux desktop security". en-us Thu, 09 Oct 2025 07:13:16 +0000 Thu, 09 Oct 2025 07:13:16 +0000 https://www.rssboard.org/rss-specification lwn@lwn.net GStreamer and the state of Linux desktop security https://lwn.net/Articles/709614/ https://lwn.net/Articles/709614/ gerv <div class="FormattedComment"> Works for me (latest Firefox, developer edition)...<br> <p> Gerv<br> </div> Mon, 19 Dec 2016 10:02:46 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/709602/ https://lwn.net/Articles/709602/ Cyberax <div class="FormattedComment"> AVs are mainly good at protecting clueless users against themselves. If your users have at least some clue than AVs are not really useful.<br> </div> Sun, 18 Dec 2016 20:39:15 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/709601/ https://lwn.net/Articles/709601/ joib <div class="FormattedComment"> <font class="QuotedText">&gt; 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.</font><br> <p> Well, google apparently has some internal data suggesting AV isn't that useful: <a rel="nofollow" href="http://www.theregister.co.uk/2016/11/17/google_hacker_pleads_try_whitelists_not_just_bunk_antivirus_ids/">http://www.theregister.co.uk/2016/11/17/google_hacker_ple...</a><br> </div> Sun, 18 Dec 2016 20:19:35 +0000 Bill Gates slipping malware under my mattress https://lwn.net/Articles/709249/ https://lwn.net/Articles/709249/ robbe <div class="FormattedComment"> <font class="QuotedText">&gt; 'feel plagued' by the knowledge that Bill Gates on a whim could run whatever code on my system he </font><br> <font class="QuotedText">&gt; wants, perhaps because he got a big check or secret letter from Donald Trump.</font><br> <p> 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.<br> <p> 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.<br> <p> 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.<br> <p> </div> Thu, 15 Dec 2016 09:05:25 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/709022/ https://lwn.net/Articles/709022/ jwarnica <div class="FormattedComment"> The incremental effort to get a user to *allow* a download to happen is pretty close to nothing.<br> </div> Tue, 13 Dec 2016 20:42:26 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708892/ https://lwn.net/Articles/708892/ flussence <div class="FormattedComment"> The difference between a silent drive-by exploit and a webpage producing a confirmation prompt for an unexpected download is pretty significant.<br> </div> Mon, 12 Dec 2016 20:07:16 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708792/ https://lwn.net/Articles/708792/ MarcB <div class="FormattedComment"> What difference would it make if users were asked before creating files? Obviously they cannot know if the file they are about to save will trip up some indexing software.<br> </div> Mon, 12 Dec 2016 13:17:34 +0000 back to basic bug bounties https://lwn.net/Articles/708770/ https://lwn.net/Articles/708770/ JanC_ <div class="FormattedComment"> In this particular example case, FLIC was used, and FLIC seems to be supported with the help of ffmpeg (or libav, depending on what distro &amp; version), so it looks like it didn't show up in earlier fuzzing of ffmpeg.<br> <p> 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).<br> </div> Mon, 12 Dec 2016 00:29:34 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708767/ https://lwn.net/Articles/708767/ hannob <div class="FormattedComment"> It actually wasn't hundreds. It was around 10 memory safety violations (including oob reads, where exploitability is unlikely in something like tracker).<br> <p> Sure, quite a bunch, but the Gstreamer team was very quick on fixing those.<br> <p> 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.<br> </div> Sun, 11 Dec 2016 21:12:57 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708761/ https://lwn.net/Articles/708761/ tpm <div class="FormattedComment"> <font class="QuotedText">&gt; In the case of GStreamer, it is likely that before Evans's reports nobody</font><br> <font class="QuotedText">&gt; ever tried to use modern coverage-based fuzzing tools on the code base. </font><br> <p> 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 :)<br> </div> Sun, 11 Dec 2016 17:38:31 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708760/ https://lwn.net/Articles/708760/ tpm <div class="FormattedComment"> For what it's worth, GStreamer already has API to do this, applications can set plugin ranks according to their own whitelist or blacklist if so desired.<br> </div> Sun, 11 Dec 2016 17:23:54 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708755/ https://lwn.net/Articles/708755/ tdz <div class="FormattedComment"> Yes, having to 'unlock' the more dangerous operations is nice. And luckily it's not often needed. But safe code can be called from within unsafe context, and the results of unsafe operations can be used in safe context. That opens up plenty of opportunity for memory bugs in safe code. It might seem kind of obvious, but I think writing code that is idiomatic to the programming language is often the best way to avoid bugs.<br> </div> Sun, 11 Dec 2016 11:23:56 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708754/ https://lwn.net/Articles/708754/ Tobu <div class="FormattedComment"> This is great.<br> <p> Another thing I got from the article is the difference between a modular design and open-ended plugin loading.<br> <p> Tracker (tracker-extract) loads a closed set of plugins, which can be vetted.<br> 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.<br> </div> Sun, 11 Dec 2016 11:00:59 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708752/ https://lwn.net/Articles/708752/ liam Sure, but I wasn't as much referencing the article as this comment by ncm: <blockquote>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.</blockquote> 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). Sun, 11 Dec 2016 10:21:25 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708737/ https://lwn.net/Articles/708737/ intgr <div class="FormattedComment"> I guess what you're missing is that this article is about Linux user space security. Most Linux user space developers, especially ones working on desktop software, don't really listen to Linus.<br> <p> </div> Sat, 10 Dec 2016 13:52:37 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708686/ https://lwn.net/Articles/708686/ roc <div class="FormattedComment"> Apart from the issues you mention, projects like CCured and the "C interpreters" discussed in this thread have the problem that they require changes to the representation of C pointers and other data, so you can't mix code running with these projects with regular C code in the same address space, and you also have difficulty interfacing with the kernel. That makes these solutions very difficult to adopt incrementally, i.e., at all.<br> <p> 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".<br> </div> Fri, 09 Dec 2016 20:50:31 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708677/ https://lwn.net/Articles/708677/ faramir <div class="FormattedComment"> <font class="QuotedText">&gt;If only I had a year free to spend on such a project...</font><br> <p> You could start with this (apparently) defunct research project:<br> <p> <a href="http://web.archive.org/web/20040409193128/http://manju.cs.berkeley.edu/ccured/">http://web.archive.org/web/20040409193128/http://manju.cs...</a><br> <p> 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<br> 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.<br> <p> </div> Fri, 09 Dec 2016 19:10:32 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708630/ https://lwn.net/Articles/708630/ mathstuf <div class="FormattedComment"> Indeed. Looking back at it, the bug was, apparently, in glibc itself. The issue was 4.5 years ago[1] and considering that's the last (and first?) time I've had a sqlite error and I use it quite a bit, it's certainly one rock solid piece of software, thanks!<br> <p> [1]<a href="https://bugzilla.redhat.com/show_bug.cgi?id=801981">https://bugzilla.redhat.com/show_bug.cgi?id=801981</a><br> </div> Fri, 09 Dec 2016 14:13:26 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708623/ https://lwn.net/Articles/708623/ drh <p>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. <p>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. <p>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. Fri, 09 Dec 2016 13:48:06 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708622/ https://lwn.net/Articles/708622/ cortana <div class="FormattedComment"> That's fantastic!<br> </div> Fri, 09 Dec 2016 13:35:51 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708621/ https://lwn.net/Articles/708621/ mathstuf <div class="FormattedComment"> <font class="QuotedText">&gt; But even Modern C++ or Rust allow for bypassing their protection mechanisms.</font><br> <p> 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.<br> </div> Fri, 09 Dec 2016 13:35:02 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708619/ https://lwn.net/Articles/708619/ mathstuf <div class="FormattedComment"> Not to mention that I've found segfaults in sqlite before since I run my entire session under MALLOC_CHECK_=3 which isn't (wasn't?) used during the test suite run before.<br> </div> Fri, 09 Dec 2016 13:34:05 +0000 back to basic bug bounties https://lwn.net/Articles/708618/ https://lwn.net/Articles/708618/ Sesse <div class="FormattedComment"> Optionally doesn't help; the default is all that matters (because that's what is getting exposed in a security context). And it still has stuff like its own MP4 parser, so it's not just about obscure formats.<br> <p> 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.<br> </div> Fri, 09 Dec 2016 13:01:16 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708615/ https://lwn.net/Articles/708615/ tdz <div class="FormattedComment"> I didn't like the alarmist tone of this article.<br> <p> 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.<br> <p> 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.<br> <p> 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.<br> </div> Fri, 09 Dec 2016 12:41:27 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708613/ https://lwn.net/Articles/708613/ ovitters <div class="FormattedComment"> Quoting the most important bit:<br> <p> <font class="QuotedText">&gt; First of all, I’m glad to tell that Tracker now sandboxes its extractors, so </font><br> <font class="QuotedText">&gt; its only point of exposure to exploits is now much more constrained, </font><br> <font class="QuotedText">&gt; leaving very little room for malicious code to do anything harmful. </font><br> <font class="QuotedText">&gt; This fix has been backported to 1.10 and 1.8, and new tarballs rolled, </font><br> <font class="QuotedText">&gt; everyone rejoice.</font><br> </div> Fri, 09 Dec 2016 09:43:44 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708608/ https://lwn.net/Articles/708608/ pabs <div class="FormattedComment"> <a href="https://blogs.gnome.org/carlosg/2016/12/08/oh-the-security/">https://blogs.gnome.org/carlosg/2016/12/08/oh-the-security/</a><br> </div> Fri, 09 Dec 2016 06:42:05 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708604/ https://lwn.net/Articles/708604/ Cyberax <div class="FormattedComment"> No, Valgrind can't _always_ catch a use-after free. If you reallocate something on top of the free'd block it'll happily go on. It does try to make it less likely by hooking into memory management (--freelist-vol) and deferring reallocation but it can't guarantee it.<br> <p> Valgrind is also not an interpreter, it's a machine simulator that annotates RAM.<br> </div> Fri, 09 Dec 2016 05:00:35 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708601/ https://lwn.net/Articles/708601/ JanC_ <div class="FormattedComment"> That still doesn't say what antivirus techniques it uses…<br> <p> 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… :)<br> <p> In other words: it would be nice to see some actual documentation about how it works.<br> </div> Fri, 09 Dec 2016 04:43:21 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708596/ https://lwn.net/Articles/708596/ roc <div class="FormattedComment"> That's impressive, but even so, within the last couple of years AFL was able to find significant bugs in SQLite:<br> <font class="QuotedText">&gt; AFL has also found a fair number of crash bugs in SQLite, and even a few cases where SQLite computed incorrect results.</font><br> So there are probably still hidden bugs worth defending against.<br> </div> Fri, 09 Dec 2016 02:08:38 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708593/ https://lwn.net/Articles/708593/ roc <div class="FormattedComment"> Dealing with AV and other "security" software's impact on Firefox was/is an absolute nightmare.<br> <p> It's not uncommon for AV download monitoring to block software updates, thus making the browser less secure or completely unusable.<br> <p> 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.<br> <p> 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".<br> <p> 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.<br> </div> Fri, 09 Dec 2016 01:58:08 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708592/ https://lwn.net/Articles/708592/ spender <div class="FormattedComment"> <a href="https://answers.microsoft.com/en-us/protect/forum/mse-protect_scanning/what-is-the-difference-in-windows-defender-and/54cd144f-2957-4368-a2a4-f74d44595847">https://answers.microsoft.com/en-us/protect/forum/mse-pro...</a><br> <p> -Brad<br> </div> Fri, 09 Dec 2016 01:43:59 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708591/ https://lwn.net/Articles/708591/ JanC_ <div class="FormattedComment"> (Or at least that's what it did a couple years ago.)<br> </div> Fri, 09 Dec 2016 01:41:05 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708590/ https://lwn.net/Articles/708590/ JanC_ <div class="FormattedComment"> Not all of these codecs were in -bad…<br> </div> Fri, 09 Dec 2016 01:30:01 +0000 back to basic bug bounties https://lwn.net/Articles/708587/ https://lwn.net/Articles/708587/ JanC_ <div class="FormattedComment"> GStreamer already uses ffmpeg for a lot of codecs (either optionally or by default). A good example is the FLIC format, which according to the article contained several security flaws.<br> <p> So even for ffmpeg it's probably true that most of the fuzzing efforts go to the more common codecs?<br> </div> Fri, 09 Dec 2016 01:22:34 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708586/ https://lwn.net/Articles/708586/ anselm <p> The SQLite developers already go to incredible lengths to make sure their code is correct. Read <a href="http://sqlite.org/testing.html">How SQLite Is Tested</a>. </p> Fri, 09 Dec 2016 01:12:55 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708585/ https://lwn.net/Articles/708585/ JanC_ <div class="FormattedComment"> I think it doesn't, mostly because it doesn't do any analysis outside of simple pattern matching, meaning it can't detect unknown viruses or virus variants, or other suspicious program behaviour…<br> </div> Fri, 09 Dec 2016 00:56:53 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708582/ https://lwn.net/Articles/708582/ clemensg <div class="FormattedComment"> Thanks for pointing out LANGSEC. Great material!<br> </div> Fri, 09 Dec 2016 00:37:55 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708581/ https://lwn.net/Articles/708581/ clemensg <div class="FormattedComment"> @paulj<br> Would you recommend implementing FSM-based parsers (from scratch) instead of using parser generators like bison?<br> Can you point to articles/papers describing this method?<br> So far I only found www.cs.dartmouth.edu/~pete/pubs/LangSec-2014-fsm-parsers.pdf<br> </div> Fri, 09 Dec 2016 00:34:23 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708578/ https://lwn.net/Articles/708578/ paulj <div class="FormattedComment"> Oh, an interpreter can catch use after free and stop the process in a controlled manner. Valgrind certainly can. A controlled stop may still be a security issue, but then usually "just" a DoS - a worse, direct compromise is avoided at least.<br> <p> </div> Thu, 08 Dec 2016 22:53:34 +0000 GStreamer and the state of Linux desktop security https://lwn.net/Articles/708576/ https://lwn.net/Articles/708576/ paulj <div class="FormattedComment"> That's a different class of bug to overflows.<br> <p> 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. <br> <p> 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.<br> <p> 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...<br> </div> Thu, 08 Dec 2016 22:51:12 +0000