2

A vulnerability in JPEG 2000 file formats has been discovered.

The articles seem to refer to OpenJPEG implementation when discussing this bug, however what's not clear is who is the vulnerable party.

  1. Is the vulnerability specific to software that leverages this library?
  2. Does the vulnerability occur when creating or viewing this image format?
  3. Are all viewers vulnerable? How can I identify if my viewer is vulnerable? (Adobe, Chrome-built in reader, etc)
makerofthings7
  • 50,090
  • 54
  • 250
  • 536
  • 1
    1. yes. 2. viewing. 3. no, most aren't, but it's hard to tell what's affected. – dandavis Oct 04 '16 at 21:10
  • note that "viewing" does not mean the image is displayed on screen. merely "handling" the image triggers the vulnerability, so preloading or creating a thumbnail from an image would trigger the vulnerability without trying to display the image. – Z.T. Oct 11 '16 at 00:55

1 Answers1

3

The full CISOC TALOS report describes the vulnerability in incredible detail. @dandavis comment already answered most of your questions but allow me to repeat that:

Is the vulnerability specific to software that leverages this library?

Yes, only libopenjp2.so.2.1.1 is vulnerable (and likely older versions of it). Other JPEG2000 libraries are not vulnerable.

Does the vulnerability occur when creating or viewing this image format?

It happens when viewing a cleverly crafted image. The library wrongly parses the MCC (motion compensation), i.e. not safely enough. You can craft an MC that will result into an arbitrary pointer, and then the next MC writes something to that pointer. In general you can write at arbitrary heap positions.

Are all viewers vulnerable?

Actually a rather limited number of viewers is vulnerable because JPEG2000 did never really catch. According to the report the notable vulnerable viewers are Poppler, MuPDF and Pdfium. Poppler being the most notable since it is used as a library in several PDF rendering applications.

How can I identify if my viewer is vulnerable? (Adobe, Chrome-built in reader, etc)

Let's go through a couple of ways of identifying vulnerable binaries.

Poopler is the most notable software package, and its pdfinfo, pdftocairo, pdfimages (and others) are clearly vulnerable. On Linux:

[root@haps ~]# ldd /usr/bin/pdfimages | grep libopenjp2
    libopenjp2.so.7 => /usr/lib/libopenjp2.so.7 (0x00007f0be0bfa000)
[root@haps ~]# ls -l /usr/lib/libopenjp2.so.7
lrwxrwxrwx 1 root root 19 Aug  4 21:08 /usr/lib/libopenjp2.so.7 -> libopenjp2.so.2.1.1

Yep, definitely using the vulnerable openjp2 2.1.1 .

Thankfully, most software* today use the cairo libraries instead of poppler for example:

[root@haps ~]# ldd /usr/bin/gimp | grep pop
[root@haps ~]# ldd /usr/bin/gimp | grep cairo
    libpangocairo-1.0.so.0 => /usr/lib/libpangocairo-1.0.so.0 (0x00007f4ce1d9f000)
    libcairo.so.2 => /usr/lib/libcairo.so.2 (0x00007f4ce110f000)

The methods above use ldd to check dependency on libopenjp2. But that is not a bullet proof method. Software loads shared libraries at runtime, for example the browser I'm posting this from will not use libopenjp2 for JPEG2000 images:

[root@haps ~]# lsof /usr/lib/libopenjp2.so.2.1.1
[root@haps ~]# lsof /usr/lib/libjpeg.so.8.1.2
COMMAND PID     USER  FD   TYPE DEVICE SIZE/OFF    NODE NAME
firefox 522 grochmal mem    REG    8,3   432880 3844022 /usr/lib/libjpeg.so.8.1.2

But will use libjpeg for all JPEG renders. Even for JPEG2000 (JPEG2000 atoms are optional).

Extra note

libopenjp2 2.1.2 which fixes the vulnerability is already available. The public disclosure of the vulnerability happened a day after this version was released, i.e. it was a responsible disclosure. (I have just updated it on my machine a couple of hours ago.)

* The example uses GIMP, which isn't a particularly good example since it uses plugins that may load extra libraries (thanks @MichaelSchumaher for reminding me of that.). On the other hand the JPEG2000 plugin for GIMP did not really catch either, just like the JPEG2000 spec itself. The plugin had a usage fewer around 2008-2010 but went into disuse since then.

GIMP has also file-pdf-load which use poppler. And moreover, anyone can write GIMP plugins that may include libopenjp2, therefore you may load the library into memory and use it to open a JPEG2000. This isn't exclusive to GIMP but any application that allows plugins that load extra shared libraries.

In summary: if you are explicitly loading a plugin to use the libopenjp2 into your application, then you are vulnerable to CVE-2016-8332 (unless you use the updated library, that is)

Community
  • 1
grochmal
  • 5,677
  • 2
  • 19
  • 30
  • 1
    Your assessment for GIMP is incomplete - it's not the gimp binary itself that loads files, but its plug-ins. – Michael Schumacher Oct 23 '16 at 12:07
  • 1
    @MichaelSchumacher - Thanks, you're correct, I've added a note about it. I use GIMP often and was not even aware of that plugin :) . After it was created in the google hackatron it was used for some time but the plugin went into disuse after that, it appears. Still there is a point about plugins that may load vulnerable libraries, so it is a good point. – grochmal Oct 23 '16 at 20:46
  • You might want to have a look at the file-pdf-load plug-in - this one uses libpoppler. And there is also a JPEG2000 loader plug-in in current GIMP 2.8, although that one uses libjasper. – Michael Schumacher Oct 23 '16 at 21:05
  • 1
    @MichaelSchumacher - It is useful to have one of the developers helping :). I've made a note about file-pdf-load but generalised the footnote to talk about any application that may load extra libraries through plugins. That should age better for people who google the question. – grochmal Oct 23 '16 at 21:51