FLIMP!

Watch Proof of Concept video

What's going on?

In 2014, when starting the Fuzzing Project, Hanno Böck did some primitive fuzzing on GIMP and reported two bugs. They weren't fixed and were forgotten in the public bug tracker.

Recently Tobias Stöckmann found one of these bugs (CVE-2017-17785) and figured out that it's easy to exploit.

Update: Shortly after this page went online most of the bugs were fixed quickly.

Uh... that's bad!

We think so, too.

What kind of bug is that?

It's a classic heap buffer overflow in the FLIC parser. FLIC is a file format for animations and was introduced by Autodesk Animator.

How does the exploit work?

Tobias has created a detailed writeup.

Why is the exploit for FreeBSD?

Modern Linux systems use Address Space Layout Randomization (ASLR), which makes exploiting buffer overflows much harder.

FreeBSD doesn't use ASLR by default.

Oh... That sounds bad, too?

We agree.

The exploit doesn't work for me!

We figured out it's unreliable and the memory addresses are depending on many circumstances. The exploit ZIP comes with two variations using different memory addresses.

Try both of them. We also noticed putting the files in a subdirectory sometimes made the exploit work.

Anything more to tell about the GIMP?

There's a wide variety of graphics formats. GIMP tries to support many of them, including many legacy formats that nobody is using any more today.

While this has obvious advantages - you can access the old images you may find on a backup CD from 1995 - it comes with risks. Support for many obscure file formats means many parsers that hardly anyone ever looks at.

So... what about the other parsers?

The second bug (CVE-2017-17786), which is a simple overread, was in the TGA parser. Furthermore we found buffer overreads in the XCF parser (CVE-2017-17788), the Gimp Brush (GBR) parser (CVE-2017-17784) and the Paint Shop Pro (PSP) parser (CVE-2017-17789).

We found another Heap buffer overflow in the Paint Shop Pro parser (CVE-2017-17787) which is probably also exploitable. Update: All these bugs have now fixes in GIMPs git code.

In other words: The GIMP import parsers are full of memory safety bugs.

How do you find these bugs?

With some effort it's possible to use american fuzzy lop - a state of the art fuzzing tool - together with Address Sanitizer to fuzz GIMP.

This is not straightforward. GIMP's import plug-ins are separate executables, crashing them doesn't crash the main process.

The fuzzing process is very slow, but we have some ideas on how to improve it.

We wanted to submit a fuzzing tutorial to the GIMP wiki. Unfortunately our attempts to get an account for the GIMP wiki were as successful as our attempts to get these bugs fixed. For now the tutorial lives here, but we still think it'd be better to have that hosted somewhere with the GIMP project.

So what now?

Our attempts to communicate with the GIMP developers have been met with silence. Some of the bugs reported have patches attached, most of them haven't been applied. We also tried contacting the GNOME security team. They tried to help, but weren't successful either.

We get the impression that security is no priority for GIMP. We think this needs to change.

What should happen?

First of all obviously all known memory safety bugs should be fixed.

Furthermore we believe the way GIMP plugins work is not ideal for security testing. The plug-ins are separate executables, however they can't be executed on their own, as they communicate with the main GIMP process.

Ideally either these plug-ins should be changed in a way that allows running them directly from the command line or - even better - they should be turned into libraries. The latter would also have the advantage of making the parser code useable for other software projects.

Finally it might be a good idea to sandbox the import parsers.

Anything else?

GIMP makes use of the exiv2 tagging library, which has its problems, too, and a couple of unfixed security bugs.

We also think GIMP should think about the security of their downloads. Update: This has been fixed now and all downloads are HTTPS by default.

FLIC... FLIC... is it possible I heard this story before?

Gstreamer recently also had a serious bug in the FLIC parser that was discovered by Chris Evans.

Who drew the logo and what's the license?

The original GIMP logo was drawn by Tuomas Kuosmanen. The modified version was created by Ludwig van Boltzmann.

The original logo was released under the GPL 2 or later, the modified version is released under the same license.

Who did this?

This is a project by Hanno Böck and Tobias Stöckmann.

Reactions

The BSD NOW podcast mentioned FLIMP (starting 01:08:17).