Decifrare in modo sicuro un messaggio PGP non richiesto / non attendibile

Pericoli di stampa di testo non attendibile

The encrypted message could contain any sort of untrusted/malformed data that could try to exploit my bash environment, my terminal emulator, etc.

Quando si esegue l'output di testo arbitrario su un terminale, come per impostazione predefinita di GnuPG, si rischia lo exploitation del proprio emulatore di terminale. Le nuove vulnerabilità relative alla gestione del testo non sicuro in fase di stampa si trovano sempre e mentre le vulnerabilità più gravi sono state eliminate, sono ancora un problema. Una soluzione sarebbe quella di reindirizzare l'output non attendibile attraverso un comando che rimuove i caratteri non stampabili. Puoi utilizzare cat -v per questo scopo. Dalla sezione 3.1 della pagina Info GNU coreutils:

-v
--show-nonprinting
    Display control characters except for LFD and TAB using ^ notation
    and precede characters that have the high bit set with M-.

Stampare testo non affidabile mentre si estrae caratteri non stampabili dovrebbe impedire lo sfruttamento del proprio emulatore di terminale attraverso codici di controllo errati o qualsiasi altra tipica via di attacco.

$ gpg -d untrusted.gpg | cat -v

Pericoloso decrittografare i messaggi non attendibili

Any potential vulnerabilities in GnuPG or whatever PGP client I am using could also be exploited by the untrusted data.

Anche questo è un rischio. GnuPG è incredibilmente complesso e qualsiasi parsing di dati complessi può portare allo sfruttamento. L'unica soluzione sarebbe quella di eseguire GnuPG airgapped, o in una sandbox stretta o in una macchina virtuale opportunamente isolata. GnuPG v2 ha migliorato la sua architettura, consentendo la decodifica in un processo che non ha accesso alla tua chiave privata, ma questa è lontana da una sandbox completa. In generale, dovresti sempre presumere che un aggressore sufficientemente competente sarà in grado di sfruttare GnuPG per fornire un messaggio crittografato maliziosamente malformato.

Durante gli ultimi 10 anni, una rapida ricerca ha rilevato diverse vulnerabilità errate in GnuPG:

• CVE-2008-1530 - Corruzione della memoria tramite chiavi duplicate dai server di chiavi che consentono esecuzione del codice.
• CVE-2010-2547 - Vulnerabilità use-after-free nel certificato parsing permettendo l'esecuzione del codice.
• CVE-2013-4242 - Attacco del canale laterale che rivela informazioni chiave private ai processi locali.
• CVE-2013-4576 - Attacco del canale laterale che consente la crittoanalisi acustica durante Decrittazione RSA.
• CVE-2016-6313 - RNG rotto che perde 160 bit di materiale casuale , indebolendo alcuni tipi di chiave.

Ma qual è il rischio attuale?

Am I going too far with this risk or should I use an air-gapped single-use offline machine to decrypt each individual message, and securely erase it afterwards? What other security controls or practises can I put in place to help?

Una macchina con aria compressa farebbe bene, ma potrebbe non essere sempre un'opzione. Non è necessario cancellare in modo sicuro i messaggi in seguito, poiché un messaggio non collegato (eliminato) non presenta alcun rischio. L'unica ragione per provare a eliminare in modo sicuro qualcosa è se non vuoi che sia disponibile attraverso l'analisi forense.

Nel complesso, il rischio effettivo dovrebbe essere piuttosto basso. Lo sfruttamento di un programma popolare richiede un certo livello di esperienza che è improbabile che possa essere usato per comprometterti attraverso il tuo sito web a meno che tu non sia di alto profilo o molto sfortunato. Ci sono modi più semplici per essere compromessi attraverso un exploit che tramite i messaggi di GnuPG (ad esempio i collegamenti ipertestuali per compromettere il browser, le immagini per compromettere i parser di immagini, ecc.). Anche così, ci sono alcune cose che puoi fare per ridurre questo rischio riguardo a GnuPG:

• Decrittografa i messaggi utilizzando un utente non privilegiato o, meglio ancora, dedicato.
• Controlla i codici di controllo dall'output decifrato. Non visualizzare mai l'output non elaborato con vim , less , ecc.
• Tieni sempre aggiornato GnuPG in modo che le vulnerabilità note vengano corrette sul tuo sistema.
• Utilizza il terminale virtuale e non un emulatore di terminale. Non utilizzare mai xterm o forks correlati.
• Usa AppArmor o simili su GnuPG. Non eseguirlo sotto un utente con accesso X11.

Questa è solo una parte di una risposta, perché la foresta copriva già molto terreno.

It's the outputting untrusted text that I am most worried about.

È possibile evitare facilmente la gestione del testo non attendibile nel terminale. Innanzitutto, nel tuo client di posta, archivia il blocco gpg crittografato in un file, ad esempio /tmp/encrypted_message.txt

Quindi, nel terminale, esegui

$ gpg ... -o /tmp/decrypted_message.txt ...

Quindi ora hai il messaggio decrittografato in /tmp/decrypted_message.txt senza avere mai dati non fidati che toccano il terminale / shell. Apri il file decrittografato in qualsiasi applicazione che ritieni affidabile per visualizzarlo, o spediscilo via e-mail (poiché lo usi già per visualizzare il testo non attendibile ogni volta che ricevi un messaggio non richiesto, quindi non aumenti la superficie di attacco). / p>

Dovresti preoccuparti di altre cose

L'esecuzione di comandi di shell nascosti nell'input dell'utente è in realtà un probabile vettore di attacco, poiché molti e molti sistemi sono vulnerabili a questo, quindi dal punto di vista dell'attaccante paga per sviluppare i necessari carichi malvagi e dal tuo punto di vista è intelligente rimuovere la shell dalla pipeline quando si gestisce l'input dell'utente ogni volta che è possibile. Ma memorizzando l'input non crittografato in un file e avendo gnupg in output il testo decrittografato in un altro file, hai già eliminato tutti i contatti tra i dati non fidati e la shell.

Invece, dovresti ora preoccuparti dei difetti nel resto delle applicazioni della tua pipeline. gpg potrebbe contenere un difetto che consente a un utente malintenzionato di eseguire codice macchina arbitrario (di solito codice che fornisce a un utente malintenzionato una shell) sul tuo computer. Ma gpg è presente in molto meno pipeline di, ad esempio, un browser o un client di posta, quindi sembra improbabile che un hacker scelga GnuPG per cercare difetti che gli permettano di eseguire shellcode, invece dei browser e della posta molto più usati clienti, (a meno che non si rivolga agli utenti di GnuPG o a te specificatamente, ovviamente qualcuno potrebbe bersagliare gli utenti di GnuPG, ma ci sono così tanti pacchetti software ad alta esposizione che sembrano bersagli migliori che penso che dovresti principalmente preoccuparti di qualcuno che effettivamente bersaglia te o il tuo sito web, individualmente).

Airgapping per leggere i messaggi che gli utenti del tuo sito web ti trasmettono è troppo cauto nei miei confronti a meno che tu non stia conducendo la prossima Silk Road e temono che le forze dell'ordine statunitensi ti perseguano, nel qual caso potrei capire perché ti preoccupi. Ma se vuoi isolare gpg , puoi usare software come firejail . Ciò significa che un attaccante che ha trovato un difetto in GnuPG che gli permette di eseguire un codice arbitrario dovrà anche trovare un difetto nel kernel di Linux prima che possa scappare dalla prigione nel tuo sistema attuale e fare più danni.

(Modifica: cambia la risposta per riflettere la discussione nei commenti / chat)