Quale software client è influenzato da JPEG 2000 / TALOS-2016-0193 / CVE-2016-8332

Il rapporto completo CISOC TALOS descrive la vulnerabilità in modo incredibilmente dettagliato. Il commento di @davavis ha già risposto alla maggior parte delle tue domande, ma permettimi di ripeterlo:

Is the vulnerability specific to software that leverages this library?

Sì, solo libopenjp2.so.2.1.1 è vulnerabile (e probabilmente versioni precedenti di esso). Altre librerie JPEG2000 non sono vulnerabili.

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

Succede quando si guarda un'immagine intelligente. La libreria analizza erroneamente l'MCC (compensazione del movimento), cioè non abbastanza sicuro. Puoi creare un MC che si trasformerà in un puntatore arbitrario, e quindi il prossimo MC scrive qualcosa su quel puntatore. In generale puoi scrivere su posizioni heap arbitrarie.

Are all viewers vulnerable?

In realtà un numero piuttosto limitato di spettatori è vulnerabile perché JPEG2000 non è mai riuscito a catturarlo. Secondo il rapporto, i notabili spettatori vulnerabili sono Poppler, MuPDF e Pdfium. Poppler è il più notevole in quanto è utilizzato come libreria in diverse applicazioni di rendering PDF.

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

Esaminiamo un paio di modi per identificare i binari vulnerabili.

Poopler è il pacchetto software più notevole e il suo pdfinfo , pdftocairo , pdfimages (e altri) sono chiaramente vulnerabili. Su 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ì, sicuramente usando la vulnerabile openjp2 2.1.1.

Per fortuna, la maggior parte dei software * oggi usa le librerie cairo invece di poppler per esempio:

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

I metodi sopra riportati usano ldd per controllare la dipendenza su libopenjp2 . Ma questo non è un metodo a prova di proiettile. Il software carica le librerie condivise in fase di runtime, ad esempio il browser da cui sto postando non utilizzerà libopenjp2 per le immagini 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

Ma userà libjpeg per tutti i rendering JPEG. Anche per JPEG2000 (gli atomi JPEG2000 sono opzionali).

Nota aggiuntiva

libopenjp2 2.1.2 che corregge la vulnerabilità è già disponibile. La divulgazione pubblica della vulnerabilità è avvenuta un giorno dopo che questa versione è stata rilasciata, cioè era una divulgazione responsabile. (L'ho appena aggiornato sulla mia macchina un paio d'ore fa.)

_{* L'esempio usa GIMP, che non è un buon esempio dato che usa plugin che possono caricare librerie aggiuntive (grazie @ MichaelSchumaher per avermelo ricordato.). D'altra parte, il plug-in JPEG2000 per GIMP non è riuscito a catturarlo, proprio come la specifica JPEG2000 stessa. Il plug-in ha avuto un utilizzo in meno nel periodo 2008-2010 ma è andato in disuso da allora.}

_{GIMP ha anche file-pdf-load che usano poppler . Inoltre, chiunque può scrivere plugin GIMP che possono includere libopenjp2 , quindi è possibile caricare la libreria in memoria e usarla per aprire un JPEG2000. Questo non è esclusivo di GIMP ma di qualsiasi applicazione che consente plug-in che caricano librerie condivise extra.}