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