LWN: Comments on "GStreamer and the state of Linux desktop security"

GStreamer and the state of Linux desktop security

gerv — Mon, 19 Dec 2016 10:02:46 +0000

Works for me (latest Firefox, developer edition)...

Gerv

GStreamer and the state of Linux desktop security

Cyberax — Sun, 18 Dec 2016 20:39:15 +0000

AVs are mainly good at protecting clueless users against themselves. If your users have at least some clue than AVs are not really useful.

GStreamer and the state of Linux desktop security

joib — Sun, 18 Dec 2016 20:19:35 +0000

> 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.

Well, google apparently has some internal data suggesting AV isn't that useful: http://www.theregister.co.uk/2016/11/17/google_hacker_ple...

Bill Gates slipping malware under my mattress

robbe — Thu, 15 Dec 2016 09:05:25 +0000

> '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.

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.

GStreamer and the state of Linux desktop security

jwarnica — Tue, 13 Dec 2016 20:42:26 +0000

The incremental effort to get a user to *allow* a download to happen is pretty close to nothing.

GStreamer and the state of Linux desktop security

flussence — Mon, 12 Dec 2016 20:07:16 +0000

The difference between a silent drive-by exploit and a webpage producing a confirmation prompt for an unexpected download is pretty significant.

GStreamer and the state of Linux desktop security

MarcB — Mon, 12 Dec 2016 13:17:34 +0000

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.

back to basic bug bounties

JanC_ — Mon, 12 Dec 2016 00:29:34 +0000

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 & version), so it looks like it didn't show up in earlier fuzzing of ffmpeg.

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).

GStreamer and the state of Linux desktop security

hannob — Sun, 11 Dec 2016 21:12:57 +0000

It actually wasn't hundreds. It was around 10 memory safety violations (including oob reads, where exploitability is unlikely in something like tracker).

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

tpm — Sun, 11 Dec 2016 17:38:31 +0000

> 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.

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 :)

GStreamer and the state of Linux desktop security

tpm — Sun, 11 Dec 2016 17:23:54 +0000

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.

GStreamer and the state of Linux desktop security

tdz — Sun, 11 Dec 2016 11:23:56 +0000

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.

GStreamer and the state of Linux desktop security

Tobu — Sun, 11 Dec 2016 11:00:59 +0000

This is great.

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.
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

liam — Sun, 11 Dec 2016 10:21:25 +0000

Sure, but I wasn't as much referencing the article as this comment by ncm:

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

intgr — Sat, 10 Dec 2016 13:52:37 +0000

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.

GStreamer and the state of Linux desktop security

roc — Fri, 09 Dec 2016 20:50:31 +0000

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.

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".

GStreamer and the state of Linux desktop security

faramir — Fri, 09 Dec 2016 19:10:32 +0000

>If only I had a year free to spend on such a project...

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
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

mathstuf — Fri, 09 Dec 2016 14:13:26 +0000

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!

[1]https://bugzilla.redhat.com/show_bug.cgi?id=801981

GStreamer and the state of Linux desktop security

drh — Fri, 09 Dec 2016 13:48:06 +0000

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.

GStreamer and the state of Linux desktop security

cortana — Fri, 09 Dec 2016 13:35:51 +0000

That's fantastic!

GStreamer and the state of Linux desktop security

mathstuf — Fri, 09 Dec 2016 13:35:02 +0000

> But even Modern C++ or Rust allow for bypassing their protection mechanisms.

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.

GStreamer and the state of Linux desktop security

mathstuf — Fri, 09 Dec 2016 13:34:05 +0000

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.

back to basic bug bounties

Sesse — Fri, 09 Dec 2016 13:01:16 +0000

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.

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.

GStreamer and the state of Linux desktop security

tdz — Fri, 09 Dec 2016 12:41:27 +0000

I didn't like the alarmist tone of this article.

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.

GStreamer and the state of Linux desktop security

ovitters — Fri, 09 Dec 2016 09:43:44 +0000

Quoting the most important bit:

> First of all, I’m glad to tell that Tracker now sandboxes its extractors, so
> 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

pabs — Fri, 09 Dec 2016 06:42:05 +0000

https://blogs.gnome.org/carlosg/2016/12/08/oh-the-security/

GStreamer and the state of Linux desktop security

Cyberax — Fri, 09 Dec 2016 05:00:35 +0000

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.

Valgrind is also not an interpreter, it's a machine simulator that annotates RAM.

GStreamer and the state of Linux desktop security

JanC_ — Fri, 09 Dec 2016 04:43:21 +0000

That still doesn't say what antivirus techniques it uses…

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.

GStreamer and the state of Linux desktop security

roc — Fri, 09 Dec 2016 02:08:38 +0000

That's impressive, but even so, within the last couple of years AFL was able to find significant bugs in SQLite:
> 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

roc — Fri, 09 Dec 2016 01:58:08 +0000

Dealing with AV and other "security" software's impact on Firefox was/is an absolute nightmare.

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.

GStreamer and the state of Linux desktop security

spender — Fri, 09 Dec 2016 01:43:59 +0000

https://answers.microsoft.com/en-us/protect/forum/mse-pro...

-Brad

GStreamer and the state of Linux desktop security

JanC_ — Fri, 09 Dec 2016 01:41:05 +0000

(Or at least that's what it did a couple years ago.)

GStreamer and the state of Linux desktop security

JanC_ — Fri, 09 Dec 2016 01:30:01 +0000

Not all of these codecs were in -bad…

back to basic bug bounties

JanC_ — Fri, 09 Dec 2016 01:22:34 +0000

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.

So even for ffmpeg it's probably true that most of the fuzzing efforts go to the more common codecs?

GStreamer and the state of Linux desktop security

anselm — Fri, 09 Dec 2016 01:12:55 +0000

The SQLite developers already go to incredible lengths to make sure their code is correct. Read How SQLite Is Tested.

GStreamer and the state of Linux desktop security

JanC_ — Fri, 09 Dec 2016 00:56:53 +0000

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…

GStreamer and the state of Linux desktop security

clemensg — Fri, 09 Dec 2016 00:37:55 +0000

Thanks for pointing out LANGSEC. Great material!

GStreamer and the state of Linux desktop security

clemensg — Fri, 09 Dec 2016 00:34:23 +0000

@paulj
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

paulj — Thu, 08 Dec 2016 22:53:34 +0000

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.

GStreamer and the state of Linux desktop security

paulj — Thu, 08 Dec 2016 22:51:12 +0000

That's a different class of bug to overflows.

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...