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

I created a Gentoo-based system where almost everything is compiled
with asan, this could serve as a starting point:

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

I discussed this already with Tobias Mueller recently and he already
started finding a couple of issues with asan:


Hanno Böck

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42

Attachment: pgpzE4V8krr6m.pgp
Description: OpenPGP digital signature

desktop-devel-list mailing list

Reply via email to