Subject: Re: [openpgp] Spoofing OpenPGP and S/MIME Signatures in Emails

From: Albrecht Dreß <[email-masked]>
Date: Sat, 04 May 2019 13:08:05 +0200

Hi,

thanks a lot for your great work!

Just an additional question regarding the “GPG Api” attacks – can we assume that all applications using gpgme (like Balsa, <https://pawsa.fedorapeople.org/balsa/>) to talk to gpg are not vulnerable regarding this attack class, as the lib handles cases G1 and G2 properly?

Thanks,
Albrecht.

On 30.04.19 14:29, ilf wrote:
> https://github.com/RUB-NDS/Johnny-You-Are-Fired
> https://raw.githubusercontent.com/RUB-NDS/Johnny-You-Are-Fired/master/paper/johnny-fired.pdf

---

From: Albrecht Dreß <[email-masked]>
Date: Sat, 04 May 2019 16:10:02 +0200

Hi,

> https://github.com/RUB-NDS/Johnny-You-Are-Fired

While testing the MUA Balsa <https://pawsa.fedorapeople.org/balsa/> using the proof-of-concept messages provided on Github, I noticed that many (most? all?) of the RFC 3156 message parts are not recognised by it.  Looking at the message source (e.g. “Attack Class 'MIME', Test 'M1' (PGP/MIME)”), it appears that the header

   Content-Type: multipart/signed; boundary="BOUNDARY"; protocol="application/pgp-signature"

is missing the “micalg” parameter.  However, RFC 3156, sect. 5 states that

> OpenPGP signed messages are denoted by the "multipart/signed" content type, described in [RFC1847]

which defines in sect. 2.1

> Required parameters: boundary, protocol, and micalg

Consequently, Balsa (and maybe other MUA's, too) simply ignores such multipart/signed parts as they don't comply with the standard.

Did you omit the parameter intentionally, i.e. did I miss something interpreting the standards (typically, the value is never used), or are these proof-of-concept messages broken?

Thanks in advance,
Albrecht.

---

From: Marcus Brinkmann <[email-masked]>
Date: Sat, 4 May 2019 21:48:56 +0200

Yes, GPGME does not conflate the status and logging output stream, and
thus is not vulnerable to this attack.

On 5/4/19 1:08 PM, Albrecht Dreß wrote:
> Just an additional question regarding the “GPG Api” attacks – can we
> assume that all applications using gpgme (like Balsa,
> <https://pawsa.fedorapeople.org/balsa/>) to talk to gpg are not
> vulnerable regarding this attack class, as the lib handles cases G1 and
> G2 properly?
> 
> Thanks,
> Albrecht.
> 
> _______________________________________________
> openpgp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/openpgp
> 

-- 
Dipl.-Math. Marcus Brinkmann

Lehrstuhl für Netz- und Datensicherheit
Ruhr Universität Bochum
Universitätsstr. 150, Geb. ID 2/461
D-44780 Bochum

Telefon: +49 (0) 234 / 32-25030
http://www.nds.rub.de/chair/people/mbrinkmann

---

From: Marcus Brinkmann <[email-masked]>
Date: Mon, 6 May 2019 13:49:37 +0200

On 5/4/19 4:10 PM, Albrecht Dreß wrote:
> While testing the MUA Balsa <https://pawsa.fedorapeople.org/balsa/>
> using the proof-of-concept messages provided on Github, I noticed that
> many (most? all?) of the RFC 3156 message parts are not recognised by
> it.  Looking at the message source (e.g. “Attack Class 'MIME', Test 'M1'
> (PGP/MIME)”), it appears that the header
> 
> is missing the “micalg” parameter.  However, RFC 3156, sect.. 5 states that
> 
> Consequently, Balsa (and maybe other MUA's, too) simply ignores such
> multipart/signed parts as they don't comply with the standard.
> 
> Did you omit the parameter intentionally, i.e. did I miss something
> interpreting the standards (typically, the value is never used), or are
> these proof-of-concept messages broken?

This is just because these are minimal test cases developed by hand.
Adding the parameter should be fine.

Thanks for your additional testing!  For everybody else: Albrecht posted
the test results on the balsa mailing list:
https://mail.gnome.org/archives/balsa-list/2019-May/msg00000.html

Thanks,
Marcus