Sembra un gioco, ma è il risultato di un’anomalia di rendering che abbiamo individuato con il team Forenser analizzando un documento PDF che si comportava in maniera diversa a seconda del software utilizzato per aprirlo.

Tutto è partito da alcune fotografie che, aprendo un PDF con Anteprima (Preview) su macOS, apparivano come semplici riquadri grigi. Lo stesso identico documento, aperto sullo stesso Mac con Foxit Reader, Acrobat Reader o con altri renderer proprietari (anche semplicemente con il browser se usa un suo renderer come ad esempio Google Chrome) mostrava invece correttamente le immagini.

Paradossalmente, aprendo il file su MacOS o iOS con un viewer che non utilizzi il renderer Apple si vede un’immagine nell’anteprima (quando si sfoglia il folder per cercare il file) e poi un’altra una volta aperta la stessa immagine nel viewer, con un evidente disorientamento dell’utente.

Analizzando progressivamente il problema siamo riusciti a circoscriverlo alla gestione di particolari immagini JPEG 2000 contenute in un container JPX da parte del renderer Apple utilizzato da Preview/PDFKit, usato ad esempio proprio in Preview/Anteprima su MacOS oppure su iOS su iPhone o iPad.

Due byte fanno la differenza

Il testcase più interessante è costituito da due PDF praticamente identici: stessa struttura, stesso /JPXDecode, stesso spazio colore CMYK e, soprattutto, lo stesso identico codestream JPEG 2000.

La differenza è di appena due byte nella File Type Box (ftyp) del container: con il valore JP2 nel campo ftyp l’immagine viene correttamente visualizzata da Preview, mentre con il valore JPX si ottiene un riquadro grigio in Preview: in sostanza, nelle due posizioni interessate abbiamo cambiato semplicemente il carattere 2 (0x32) nel carattere x (0x78) ma il codestream JPEG 2000 resta identico.

Questo ovviamente non significa che JPX sia un formato errato: JPX è previsto dallo standard JPEG 2000 Part 2 e il PDF contempla espressamente /JPXDecode, quindi non possiamo parlare di bug, è più corretto parlare – almeno fino a eventuali chiarimenti da parte di Apple – di una anomalia di interoperabilità/rendering riproducibile in Preview/PDFKit.

Parliamo quindi di una differenza di rendering riproducibile su questi file. Il testcase, da solo, non consente di attribuire una precisa violazione dello standard al renderer Apple, anche perché il solo brand non certifica la conformità del container.

Dal riquadro grigio al “PDF di Schrödinger”

A quel punto mi sono chiesto: se il comportamento è così prevedibile e controllabile, possiamo sfruttarlo per fare in modo che lo stesso PDF mostri due contenuti totalmente differenti a seconda del renderer? Che so, tipo un cane e un gatto?

La risposta è sì e siamo riusciti a fare qualcosa d’interessante anche per l’informatica forense e la pdf forensics: abbiamo costruito un PDF che contiene un cane e un gatto, ma che mostra soltanto o uno o l’altro come unica immagine del documento in base al sistema utilizzato per aprirlo.

Aprendolo con Preview/PDFKit nell’ambiente interessato dall’anomalia compare il cane, mentre utilizzando un renderer che gestisce correttamente l’oggetto JPX compare invece il gatto: niente JavaScript, niente rilevamento dello User-Agent e nessun contenuto scaricato da Internet.

In sostanza, la regola è:

• Renderer Apple (iOS/iPadOS/MacOS) –> cane
• Renderer autonomo (Foxit Viewer, Acrobat PDF Viewer, Browser, etc…) –> gatto

Stesso PDF, stessi byte, persino stesso valore hash ma due rappresentazioni visive differenti, da qui il nome, inevitabile, di “PDF di Schrödinger”: un pdf che contiene contemporaneamente cane e gatto.

Allego qui si seguito il “PDF di Schrodinger”, confermando che è sicuro da aprire perché non contiene javascript, action, codifiche, automatismi ma semplicemente due immagini JPG con due codifiche diverse, anticipando che è probabile che sl sito web vediate comunque un gatto, ma una volta scaricato (su MacOS/iPhone) vediate invece un cane.

Il pdf con la doppia immagine produce valore hash MD5 a62b826ada901ee1e13b1940d37255e5, SHA256 bc7e7bbb478e9f082d265e27cc43b286f7a5f4dde42a6a5ab37bc6702f25c714 e – per i più attenti alla sicurezza informatica – ha le seguenti caratteristiche:

Title:           Il PDF di Schrodinger - Cane o gatto?
Author:          Paolo Dal Checco
Creator:         Paolo Dal Checco
Custom Metadata: no
Metadata Stream: yes
Tagged:          no
UserProperties:  no
Suspects:        no
Form:            none
JavaScript:      no
Pages:           1
Encrypted:       no
Page size:       700 x 700 pts
Page rot:        0
File size:       256358 bytes
Optimized:       no
PDF version:     1.5

Perché è interessante per la digital forensics?

La curiosità tecnica nasconde un problema tutt’altro che teorico: in una perizia informatica, due consulenti potrebbero verificare di avere esattamente lo stesso documento, con il medesimo hash, e tuttavia visualizzare contenuti differenti perché utilizzano software o sistemi differenti.

L’hash dimostra l’identità della sequenza di byte, non l’identità della rappresentazione prodotta dal renderer, questa è una cosa di cui in digital forensics si deve tenere conto e l’esperimento del cane e del gatto rende semplicemente macroscopico questo concetto.

Implicazioni su contratti, immagini nascoste, truffe

Le implicazioni possono riguardare non soltanto la PDF Forensics, ma potenzialmente anche documenti contrattuali, firme digitali, verifiche documentali e scenari malevoli nei quali la diversa rappresentazione di uno stesso documento potrebbe essere sfruttata intenzionalmente.

Non è difficile immaginare come una simile anomalia possa essere sfruttata per truffe, per contratti che vengono mostrati in modo diverso al destinatario rispetto al contenuto “nascosto”, all’invio d’immagini nascoste che si vedono solo con una particolare codifica.

Ad esempio, abbiamo sperimentato l’apposizione di una firma digitale e di una marca temporale al documento e, come si può immaginare, la rappresentazione grafica della firma può comparire insieme al cane oppure al gatto, a seconda del renderer.

Questo non significa che la firma digitale selezioni una delle due immagini e firmi quella: la firma riguarda i dati della revisione firmata, cioè l’intero documento, non i pixel mostrati sullo schermo, ma il punto critico è un altro: la verifica dell’integrità del documento non dimostra, da sola, quale rappresentazione il firmatario abbia effettivamente visto prima di firmare, perché… dipende da quale sistema ha utilizzato per la firma.

Per chi svolge analisi forensi, la conseguenza pratica è semplice: non bisogna dare per scontato che ciò che mostra un singolo viewer coincida necessariamente con tutto ciò che il PDF contiene. Nei casi dubbi è opportuno documentare software, versione e ambiente utilizzati e confrontare il documento attraverso renderer indipendenti.

Come evitare il problema

Nella coppia di test bastano due byte differenti per cambiare la visualizzazione dell’immagine nel PDFKit verificato. Nel PDF di Schrödinger, invece, non cambia neppure un byte tra un’apertura e l’altra: lo stesso documento mostra il cane o il gatto a seconda di come viene renderizzato.

In attesa di un eventuale intervento sul renderer Apple, per chi produce PDF destinati a essere visualizzati su piattaforme differenti la soluzione prudenziale è evitare container JPX quando le funzionalità specifiche di JPEG 2000 Part 2 non sono necessarie, preferendo JP2 o formati maggiormente interoperabili e verificando sempre il PDF finale con più renderer.