Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.
Sign upFix GnuPG parsing (re: Johnny You Are Fired) #2217
Comments
This comment has been minimized.
This comment has been minimized.
|
Progress: GnuPG supports a flag More soon. |
This comment has been minimized.
This comment has been minimized.
|
@BjarniRunar Sorry for not letting you know before publication! Somehow it slipped through the cracks, given that we found the Mailpile issue over half a year after disclosing the same vulnerabilities in other mail clients and gpg. It's good to protect against older gpg versions in the wild of course. Here are the strategies I give in my blog:
Using --no-verbose and --status-file would be a fine solution! |
This comment has been minimized.
This comment has been minimized.
|
I'm just quite grateful we were included in the review! Testing all those different mail clients is lots of work. So thanks (again) for that. I have working code using the |
This comment has been minimized.
This comment has been minimized.
|
Note: This fix is not super well tested. I am pretty confident it addresses the root problem, but it would still be nice if it were better tested. I'm soliciting help with that here, we'll see how that goes: https://community.mailpile.is/t/johnny-you-are-fired-gnupg-bug-fix/143 |
Regarding: https://github.com/RUB-NDS/Johnny-You-Are-Fired
Mailpile currently combines GnuPG's stderr and status-fd output streams into one. It has been demonstrated that the stderr stream can be manipulated to inject random data, thus confusing our parser and in some cases tricking the parser into thinking we got a valid signature from someone, when in fact it we did not.
This is a security issue for anyone relying on OpenPGP signatures, and I consider this a blocking issue for a 1.0 release.
The obvious solution here, is to separate the streams. This should be relatively easy on Linux (and the Mac), but there are cross-platform concerns since Windows treats forking and file descriptors differently, and Python's
subprocess.Popendoesn't natively give us a third file descriptor to work with.