Innanzi tutto l'attacco ha successo non solo su Windows (che � il pi� diffuso SO per PC al mondo), ma anche con altri SO come Linux/KDE, free BSD/KDE e MacOSX. In secondo luogo l'attacco infatti "sfrutta" una caratteristica comune a molti SO (in quelli Unix-like la cosa dipende dal window manager) per la quale il tipo di file viene riconosciuto attraverso l'estensione. Di per s� essa non � ritenuta una vulnerabilit� n� in contesto scientifico n� in contesto commerciale.

Non si pu� quindi affermare che ci� che documentiamo nel lavoro sia una vulnerabilit� dei SO (men che meno solo di Windows). 

Infatti un sistema software � sicuro se non � possibile sfruttare sue debolezze intrinseche o sfruttare caratteristiche dell'ambiente in cui � eseguito per determinarne un comportamento malicious. 

La vulnerabilit� che abbiamo rilevato riguarda il sistema di firma, in quanto sfruttando le (lecite) caratteristiche dei Sistemi Operativi (l'ambiente in cui � eseguito) � possibile determinare un comportamento malicious.

E� interessante considerare la seguente metafora: 

Se il 99.99% delle strade del mondo presenta dossi (o buche), e viene progettata un'autovettura che appena incontra un dosso esplode, e per evitare questo sarebbe sufficiente una minima modifica nel progetto dell'autovettura, il problema riguarda la strada o l'autovettura?

La risposta � immediata.

Le strade, nella metafora, sono i SO su cui sono elaborati i documenti. Quelli che ho elencato sopra coprono forse pi� del 90% dei PC in uso. L'autovettura � il sistema di firma. Che si intende non soltanto gli algoritmi, ma il modo con cui li usiamo. Perci� busta, sw di generazione e verifica, etc.

Cio� ci� che rende diversa la teoria dalla pratica, che alla fine � quella che riguarda tutti.

In senso tecnico la firma non viene falsificata con questo attacco. Possono per� essere realizzati dei documenti informatici �falsi�, cio� alterati. Non abbiamo mai affermato nella nostra ricerca che abbiamo falsificato la firma digitale, cio� che la debolezza individuata riguardi gli algoritmi di firma (hash inclusi) .
Tuttavia essa � una debolezza degli strumenti di firma compliant alla normativa europea (nella quasi totalit�). E' un problema di rilevanza pratica perch� l'attacco riesce, e questo � indiscutibile.

Fino ad Aprile 2008, e cio� fino al momento in cui il lavoro � stato messo a disposizione del CNIPA e inviato a conferenza, non risulta alcuna documentazione che dimostri tale affermazione.

Certamente no. Quel tipo di attacco, che opera per esempio sui file di Word attraverso le macro-istruzioni, comporta la modifica di ci� che viene presentato all�utente, in funzione della modifica di variabili esterne (per es., la data del sistema). Quell�attacco � ben noto e ampiamente documentato, vi � anche letteratura scientifica circa le strategie di contrasto. Tuttavia, sebbene gli effetti di questo attacco siano simili a quelli del nostro, quest�ultimo agisce attraverso una tecnica profondamente diversa, in quanto nel documento compromesso � presente solo html con comportamento totalmente statico, compliant anche con la normativa europea pi� stringente (che � quella Slovena).

Infatti, nel documento sloveno "Specifying the content and formal specifications of  document formats for QES" � richiesto per l�HTML:
"A document in HTML and XHTML shall contain only static objects and all necessary document components shall be directly in HTML and XHTML document, i.e. it shall not contain references on external resources that might change visualization. HTML and XHTML shall not contain other document types than defined in [19] and pictures which visualization is not unambiguous, i.e. animations and pictures with used lossy (irreversible) compression.".
Inoltre la normative tecnica Europea pi� stringente rispetto alle minacce basate sulla presenza di codice nei documenti � il documento CWA 14170:2004, che, prevede come �Security Requirement� "An SDP capable to make the signer sign only a static document format�.
Il nostro attacco agisce anche su formati totalmente statici. Quindi anche se formalmente l�HTML incluso nel BMP del nostro attacco pu� essere denotato come �codice� presente nel documento, essendo esso STATICO, non riguarda le minacce fino ad oggi note.
Che i due attacchi siano profondamente differenti dal punto di vista della modalit� di funzionamento lo si comprende anche dal fatto che la nostra soluzione (inclusione di nome + estensione) negli �authenticated attributes� della busta PKCS#7, che � risolutiva nel nostro caso, non � efficace per gli attacchi basati sulla presenza di codice. Viceversa, la disattivazione dai formati che lo consentono dei meccanismi che prevedono l'inclusione di istruzioni al fine di dare al documento un comportamento dinamico (es. disattivazione delle macro di Word, javascript in pdf o html, etc.), lascerebbe inalterata la possibilit� di condurre a termine con successo il nostro attacco.
Una implicazione pratica di quanto detto prima � che, rispetto al rischio derivante dalla presenza di codice nei documenti, fino ad oggi nessuno avrebbe reputato pericoloso un documento sottoposto a firma di tipo bitmap (che, di fatto, non pu� avere contenuti dinamici, non ha riferimenti a risorse esterne, animazioni e immagini con compressione lossy), visualizzabile correttamente con un viewer di immagini. D'altra parte i formati immagine e i formati txt sono stati considerati gli unici totalmente esenti dal rischio di comportamento dinamico fino ad oggi.

Non direi trascurabile, anche se sicuramente non � alto. Tutto dipende dall�uso della firma, dalla quantit� di documenti firmati gestiti dal singolo utente, dal fatto che la firma venga usata nel contesto del commercio elettronico o meno, dal livello di alfabetizzazione delle vittime, da tanti fattori. Se firmo un form Web, e magari non visualizzo neppure le estensioni, e poi �uploado� il form (html) firmato, se la parte con cui opero � l�attaccante, pu� successivamente modificare l�estensione e poi contestarmi un pagamento con un contratto BMP� Magari dopo molti mesi. Conoscere l�attacco pu� aiutare a contrastare le minacce.

Ci� � tipico delle alterazioni di documenti (sia cartacei che informatici). Non per questo non dobbiamo preoccuparci di contrastare il rischio.