tl;dr: This vulnerability affects GnuPG and several plugins and wrapper
libraries, including
Vinay Sajip’s
“python-gnupg” which I
rewrote many years ago after
finding a shell injection vulnerability in his code. His code is vulnerable
to SigSpoof; mine isn’t.
Markus Brinkmann, a NeoPG developer,
wrote about a recent signature spoofing vulnerability
in GnuPG which carried over into several downstream plugins and wrapper
libraries—largely due to GnuPG’s interface design which uses file descriptors,
and only file descriptors, to speak a custom, potentially binary but often
ascii, order dependent line protocol, whose line order, keywords, number of
fields, and other details are subject to change between minor point versions of
GnuPG. If that sounds like a special hell invented by some sort of unholy
crossing between RMS and a rabid howler monkey: welcome to working with (or
rather, more likely, around) the Terrible Idea Generator known as the GnuPG
development team.
As previously mentioned, while working with Riseup¹ folks on a project, we found
a shell injection vulnerability in
Vinay Sajip’s python-gnupg module
(the one that installs if you do pip install python-gnupg; mine installs with
pip install gnupg). The fix was not merely to remove shell=True argument
passed to a call to subprocess.Popen() as Vinay believed (and continues to
believe)—but instead, to
sanitise all inputs
and
whitelist available options.
There are hundreds of flags to the gnupg binary. Some flags and options are
safe. Others can be, if you carefully sanitise their arguments. Others must be
disallowed entirely.
--no-options is passed by default. So if you’ve got something stupid in
your gpg.conf file, you’ll still be fine while using my Python module.
--verbose is not passed. This means that my library doesn’t have to wade
throught a mixture of strange stderr and GnuPG status-fd messages on the same
file descriptor. You could pass --verbose to it manually, as it is in
the list of allowable, whitelisted options, but the exploit still won’t work,
which brings us to our next point:
All inputs to, and outputs from, the gnupg binary are sanitised and then
forced to conform to whitelists. This means that, even if you did pass
--verbose manually, the filename trick won’t work because there’s no way to
safely sanitise a filename, because filenames may be arbitrary bytes.
Amusingly, the front page of Vinay’s
current documentation states:
Which beautifully demonstrates that Vinay still doesn’t understand the
original bug report. Additionally, not a single line of his original
code remains unchanged, as the bulk of it was badly written and
contained hidden landmines.
At the time I pointed out the vulnerability, Vinay argued that it wasn’t a bug
until a working exploit for a Bitcoin exchange C&C server, which was
unfortunately running his code, was released. Vinay released several versions
of his library at the time,
without making the version controlled repo …
This post is not about those positive changes. This post is about people and
organisations which haven’t changed, such as the Chaos Computer Club (CCC), who
have attempted to save face in public, while privately working to undermine
positive change and enable rapists.
In June 2016,
I and
others spoke up about serial rapist and abuser,
Jacob Appelbaum. Unlike other organisations — such as The Tor Project, or The
Cult of the Dead Cow — the CCC delayed for more than a month in responding.
Eventually, their hand was forced by
a parody “@chaosupdales” Twitter account
announcing that the CCC had expelled Jake. First,
the CCC clarified that they had not expelled Jake. Then, the CCC posted a vague
statement that “all are welcome”. Finally, the CCC claimed that their statement
had, “of course”, referred to Jake all along. Of course, they only clarified
this on Twitter and never updated their statement. In English, this is called “gaslighting”.
There were no Tor talks last year at 33C3, because every Tor talk submitted was
silently removed by the CCC to “avoid controversy”. Before the congress, the
CCC requested a meeting with their selection of representatives from Tor to
discuss a way forward. I requested to attend the meeting, and was forbidden
from attending by the CCC organisers, who said that the meeting would not occur
if I were present.
Two other members of the Tor community were expelled for their participation in
River’s brutal assault.
The CCC continued their pattern of feigning interest in making progress, while
privately showing no interest in learning about what had happened from the survivors.
One of those expelled was
7a573b399812f3260385bd1790cd3e22612fad1b02ad8d95946bd096f1c8455d (hereafter
truncated to “7a573b39”), the second
participant in River’s account, which describes a horrific assault while she was
intoxicated to the point of being non-responsive. Unlike my coworkers, 7a573b39 was
given a talk at 33C3. (Ironically, on a project I helped design and implement.)
This was the CCC’s idea of the way forward.
Survivors of Jacob’s abuse had collectively agreed to give 7a573b39 a second
chance: he said he had been manipulated by Jake into participating in the rape;
he did not appear to have committed any similar abuse; he expressed remorse and
apologised to River; he claimed to have taken a class on not only recognising,
but enacting bystander intervention in sexual harassment.
Here is 7a573b39 nine months later, in September 2017, standing next to Jake:
This photo was taken in Cuba at ASCrypto, a self-described school for “graduate
students in cryptography” aiming to “build cryptologic research capacity in the
region”. 7a573b39 explained to others within the Tor Project that he hadn’t
intended to run into Jake, and that Jake had “followed” him around “harassing …
