Un PDF interattivo pericoloso!

Il bug a cui facciamo riferimento in questo articolo appartiene a uno dei programmi più diffusi sui PC (soprattutto quelli dotati di Windows) di tutto il mondo: Adobe Reader. Quando un utente scarica un PDF, c’è buona probabilità che lo apra automaticamente con questo programma. Per capire meglio come funziona, bisogna capire come funzionano i PDF. Il loro “progenitore”, il formato PostScript, è una sorta di linguaggio di programmazione vero e proprio, che contiene le istruzioni per la stampa. Queste istruzioni devono poi essere interpretate dalle stampanti (e dai programmi che visualizzano l’anteprima). Un po’ come un programma in Python. Invece, i PDF sono una sorta di versione già compilata, come un programma binario. Ciò non toglie che debbano essere “interpretati” per poterli visualizzare sullo schermo, ma con la differenza che l’interpretazione parte proprio da un binario. È più simile a una emulazione, come quando si usa una macchina virtuale per far girare un programma scritto per una architettura diversa da quella nativa del processore del proprio PC.

[figura #1] – Il codice di Adobe Acrobat Reader non è pubblico, ma con un debugger è possibile vedere le porzioni in cui l’indirizzo di memoria viene liberato e nonostante questo il programma continua a usarlo (FONTE: https://zscaler.com)

Il cuore del problema

Nel corso degli anni il formato PDF è diventato uno standard indiscusso, ma gli utilizzi dell’informatica sono cambiati negli ultimi 30 anni, e da un po’ di tempo i PDF hanno iniziato a supportare i form, per consentire una semplice compilazione dei moduli. Non soltanto: hanno anche iniziato a supportare JavaScript (https://opensource.adobe.com/dc-acrobat-sdk-docs/acrobatsdk/pdfs/acrobatsdk_jsapiref.pdf) per automatizzare la gestione dei form stessi. Ed è qui che si annida il problema: se un PDF di per sé non contiene del codice da interpretare o eseguire, il codice JavaScript deve essere eseguito, e questo può dare spazio di manovra a qualche malintenzionato. Nel caso specifico, Adobe ha sviluppato alcune apposite API che permettono al codice JavaScript di accedere a determinate parti della pagina. Per esempio, la funzione print stampa un subset di pagine del documento PDF. Questa funzione ha una serie di parametri opzionali: nStart e nEnd indicano il numero di inizio e fine del range di pagine da stampare, bShrinkToFit indica se sia necessario ridimensionare le pagine per adattarle all’area di stampa, eccetera. In particolare, da Acrobat 6 in poi i vari parametri sono supportati per retrocompatibilità, ma è disponibile un nuovo elemento: printParams. Questo oggetto dovrebbe contenere tutte le impostazioni necessarie per la stampa e se è specificato tutti gli altri parametri vengono ignorati. Questa comodità prevista da Adobe, che in teoria facilita queste attività perché si può creare l’oggetto con le preferenze di stampa una volta sola e poi usarlo quando si vuole, ha in realtà un problema di implementazione. L’oggetto printParams viene infatti utilizzato senza prima verificare che contenga qualcosa di legittimo. Quindi per un malintenzionato è possibile creare un PDF che contenga questo codice:

/OpenAction <<
/JS (
fthis = this;
try {
uAnwU19 = new Object(unescape(‘%EA7%DF’));
} catch(e) {};
try {
fthis.print({
bUI: true,
nStart: 1,
nEnd: 2,
bSilent: true,
bPrintAsImage: true,
bReverse: true,
bAnnotations: true,
printParams: uAnwU19
});
} catch(e) {};
fthis.resetForm();)
/S /JavaScript
>>

L’interprete JavaScript di Adobe Reader eseguirà la funzione print, ignorando i vari parametri legittimi, e utilizzando per le preferenze di stampa soltanto l’oggetto uAnwU19. Questo è per JavaScript un oggetto corretto, ma in realtà non contiene alcuna informazione utile per la stampa. Quanto accade, quindi, è che Acrobat Reader scarta l’oggetto ma poi, per un bug nella programmazione, cerca di usarlo comunque per continuare la stampa. Questo è un errore detto use after free: si tratta di un accesso non autorizzato a un’area di memoria, perché ovviamente prima poteva anche accedervi ma ora non più. Inserendo un adeguato shellcode nell’oggetto incriminato è possibile sovrascrivere un’area di memoria che poi verrà eseguita, dando la possibilità al malintenzionato di ottenere, per esempio, un terminale remoto sul PC della vittima.

Entità della vulnerabilità

Questa vulnerabilità è piuttosto seria, non soltanto perché il programma colpito è uno dei più diffusi sui computer di tutto il mondo, ma anche perché è piuttosto semplice da sfruttare. Per un malintenzionato è sufficiente creare un PDF malevolo e caricarlo su un sito web, o inviarlo via email. La vittima, ignara, finirebbe con l’aprire il file e innescare l’esecuzione del codice. Al momento non abbiamo segnalazioni di PC crackati con questo meccanismo, ma è anche abbastanza palese che un utente potrebbe essere stato colpito e non rendersene conto. Il bug si presenta in buona parte dei casi come un crash di Adobe Reader, la maggior parte degli utenti tende a ignorare questi eventi, al massimo bollandoli come un difetto del file. Va detto che è anche un bug difficile da identificare, perché il pdf è del tutto legittimo, quindi anche eseguendo una scansione del file non c’è un modo semplice per capire se sia “infetto”.

[figura #2] – La documentazione ufficiale di Adobe spiega come funzionano le API JavaScript dei PDF (FONTE: https://opensource.adobe.com/dc-acrobat-sdk-docs/acrobatsdk/pdfs/acrobatsdk_jsapiref.pdf)

La soluzione

Gli scopritori del bug hanno contattato Adobe, e l’azienda ha rilasciato dei bugfix per tutte le principali versioni di Acrobat Reader. È importante ricordare che questo non è un bug nel formato PDF, ma nel modo in cui Acrobat Reader gestisce JavaScript all’interno del PDF. Quindi chi sta utilizzando qualche altro visualizzatore di PDF non è colpito dal problema, e non deve adottare particolari contromisure. Gli utenti di Acrobat Reader, invece, devono semplicemente aggiornare il programma all’ultima versione disponibile.