El informe completo de CISOC TALOS describe la vulnerabilidad con increíble detalle. El comentario de @dandavis ya respondió a la mayoría de sus preguntas, pero permítame repetir eso:
¿La vulnerabilidad es específica del software que aprovecha esta biblioteca?
Sí, solo libopenjp2.so.2.1.1 es vulnerable (y probablemente versiones más antiguas). Otras bibliotecas JPEG2000 no son vulnerables.
¿Se produce una vulnerabilidad al crear o ver este formato de imagen?
Ocurre cuando se ve una imagen ingeniosamente diseñada. La biblioteca analiza erróneamente el MCC (compensación de movimiento), es decir, no es lo suficientemente seguro. Puede crear un MC que resulte en un puntero arbitrario, y luego el siguiente MC escribe algo en ese puntero. En general, puede escribir en posiciones de pila arbitrarias.
¿Todos los espectadores son vulnerables?
En realidad, un número bastante limitado de espectadores es vulnerable porque JPEG2000 realmente nunca captó. Según el informe, los notables espectadores vulnerables son Poppler, MuPDF y Pdfium. El Poppler es el más notable, ya que se utiliza como biblioteca en varias aplicaciones de representación de PDF.
¿Cómo puedo identificar si mi espectador es vulnerable? (Adobe, Chrome-built in reader, etc)
Revisemos un par de formas de identificar binarios vulnerables.
Poopler es el paquete de software más notable, y su pdfinfo , pdftocairo , pdfimages (y otros) son claramente vulnerables. En 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
Sí, definitivamente usando el vulnerable openjp2 2.1.1.
Afortunadamente, la mayoría del software * de hoy utiliza las bibliotecas cairo en lugar de poppler , por ejemplo:
[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)
Los métodos anteriores usan ldd para verificar la dependencia en libopenjp2 . Pero eso no es un método a prueba de balas. El software carga bibliotecas compartidas en tiempo de ejecución, por ejemplo, el navegador del que publico esto no utilizará libopenjp2 para las imágenes JPEG2000:
[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
Pero utilizará libjpeg para todas las representaciones JPEG. Incluso para JPEG2000 (los átomos JPEG2000 son opcionales).
Nota adicional
libopenjp2 2.1.2 que corrige la vulnerabilidad ya está disponible. La divulgación pública de la vulnerabilidad ocurrió un día después de la publicación de esta versión, es decir, fue una divulgación responsable. (Acabo de actualizarlo en mi máquina hace un par de horas).
* El ejemplo utiliza GIMP, que no es un ejemplo particularmente bueno ya que usa complementos que pueden cargar bibliotecas adicionales (gracias @ MichaelSchumaher por recordarme eso.). Por otro lado, el complemento JPEG2000 para GIMP tampoco se detectó, al igual que la especificación JPEG2000 en sí. El complemento tuvo un uso menor en 2008-2010 pero se dejó de usar desde entonces.
GIMP también tiene un archivo-pdf-load que usa poppler . Y además, cualquier persona puede escribir complementos de GIMP que pueden incluir libopenjp2 , por lo tanto, puede cargar la biblioteca en la memoria y usarla para abrir un JPEG2000. Esto no es exclusivo de GIMP, pero cualquier aplicación que permita complementos que carguen bibliotecas compartidas adicionales.
En resumen: si está cargando explícitamente un complemento para usar libopenjp2 en su aplicación, entonces es vulnerable a CVE-2016-8332 (a menos que use la biblioteca actualizada, es decir)