Re: Tracker as a security risks
On Mon, 5 Dec 2016 13:44:40 + Sam Thursfield <sss...@gmail.com> wrote: > The design of Tracker takes the risks into account. Metadata > extraction is isolated in its own process (tracker-extract) which can > crash without (theoretically) causing any harm. I don't see how that helps against security vulnerabilities. Having an isolated process probably helps in a way that a crash won't cause the whole tracker service to malfunction. Thus parsing broken files won't cause a service disruption. But as long as this process runs with normal user rights this doesn't protect in a security sense. > > I think there needs to be a wider discussion about this and the > > fundamental design choices done here need to be questioned. > > What questions do you have in particular? Quite frankly, I don't claim to have all the answers here, that's why I formulated it in an open "needs discussion" way. I think sandboxing the tracker parser (which you already indicated in your mail) is probably the most reasonable way to go forward. This isn't exactly my area of expertise, so I can't comment on which technique here is most promising. The other issue I think is that the quality of huge parts of the foss ecosystem needs to be improved. The good news here is that we got some powerful tools in terms of fuzzing (afl, libfuzzer) and memory safety bug detection (asan) in the past years. Ideally all free software devs should be aware of those tools and use them in their development process. I'm trying to help here where I can, see e.g. also my recent post on this list [1]. If our libraries would be better tested we could be more comfortable feeding it with untrusted inputs. [1] https://www.mail-archive.com/desktop-devel-list@gnome.org/msg28161.html -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Tracker as a security risks
Hi, I wanted to point out a recent blogpost by IT security export Chris Evans: https://scarybeastsecurity.blogspot.dk/2016/11/0day-poc-risky-design-decisions-in.html The short version: Chrome automatically downloads files without a file dialog, tracker (part of the GNOME desktop) subsequently automatically indexes these files with a wide variety of parsers (including gstreamer, but also others like imagemagick). While the bugs that evans points out have been fixed (and the gstreamer team has fixed a whole bunch of other potential security issues I reported in the past days, thanks!), the whole design of Tracker seems incredibly risky. It is certainly worthwhile trying to make the underlying software more secure, but having tried to do that before I find it unlikely that projects like gstreamer or imagemagick will ever be in a state where we can feel comfortable feeding them with untrusted files. The core problem here is that tracker automatically parses files of potentially unknown origin with parsers that haven't been built with security in mind. This happens without any sandboxing. I think there needs to be a wider discussion about this and the fundamental design choices done here need to be questioned. -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Testing for memory safety issues with Address Sanitizer
Hi, I recently reported a couple of bugs to GNOME-components that were easily discovered with a feature called Address Sanitizer (asan): https://bugzilla.gnome.org/show_bug.cgi?id=762417 (glib) https://bugzilla.gnome.org/show_bug.cgi?id=762493 (glib) https://bugzilla.gnome.org/show_bug.cgi?id=768441 (gnome-session) The first two are out of bounds reads in glib that get triggered by running the test suite with "make check". The third is a buffer overflow in gnome-session that gets triggered on every startup. Given that these bugs were there I can only assume that nobody has used address sanitizer in the past to test gnome components - which is unfortunate, because it's a really powerful tool to discover hard to find memory safety issues. It's part of the common compilers (gcc,clang) and can be enabled simply by passing -fsanitize=address in CFLAGS, CXXFLAGS and LDFLAGS. Most commonly it finds out of bounds memory access (global, stack and heap, both read and write) and use after free bugs. Things that could be done, by increasing complexity: * Run the existing test suites with address sanitizer This could be mostly automated, it's usually as simple as doing something like: ./configure CFLAGS="-fsanitize=address -g -fno-common -U_FORTIFY_SOURCE" CXXFLAGS="-fsanitize=address -g -fno-common -U_FORTIFY_SOURCE" LDFLAGS="-fsanitize=address -g -fno-common -U_FORTIFY_SOURCE" make ASAN_OPTIONS="log_path=/var/log/asan/asan-error" make check The additional flags (-fno-common -U_FORTIFY_SOURCE) help avoiding false negatives from asan. The -g adds debugging info. Using the asan log_path makes sure one finds the error messages asan produces later. * Run GNOME itself and its applications with asan enabled. Test suites are fine, but they don't replace real testing, i.e. actually running the software. Ideally one would built the full software stack with address sanitizer enabled to find bugs both in the applications themselve and in libraries. I created a Gentoo-based system where almost everything is compiled with asan, this could serve as a starting point: https://wiki.gentoo.org/wiki/AddressSanitizer However of course this could also be done on any other system. * Use Fuzzing. This is especially interesting for everything that is parsing complex data formats. There has been a lot of improvement in fuzzing techniques lately and advanced fuzzing tools like american fuzzy lop or libfuzzer can greatly help in improving and securing code. I have some introductions to these things on the fuzzing project webpage: https://fuzzing-project.org/tutorials.html I discussed this already with Tobias Mueller recently and he already started finding a couple of issues with asan: https://bugzilla.gnome.org/show_bug.cgi?id=771607 https://bugzilla.gnome.org/show_bug.cgi?id=771608 https://bugzilla.gnome.org/show_bug.cgi?id=771609 https://bugzilla.gnome.org/show_bug.cgi?id=771610 https://bugzilla.gnome.org/show_bug.cgi?id=771612 https://bugzilla.gnome.org/show_bug.cgi?id=771298 https://bugzilla.gnome.org/show_bug.cgi?id=771289 -- Hanno Böck https://hboeck.de/ mail/jabber: ha...@hboeck.de GPG: FE73757FA60E4E21B937579FA5880072BBB51E42 pgpzE4V8krr6m.pgp Description: OpenPGP digital signature ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
