Topics

GnuPG efail - researcher discussion failure

Luis R. Rodriguez <mcgrof@...>
 

As you may know there is tons of media coverage over efail:

https://efail.de/

The GnuPG team response seems to indicate that the researchers really
didn't properly engage or tune their message to avoid such hype over
such issues:

https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060315.html
https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060318.html

The tone should therefore have been more about tons of MUAs needing fixing. But
everything else seems hype.

Since CII started in part as a response to Heartbleed, and the badge program is
IMHO a success story considering the number of projects which have been shaping
up to meet the requirements, it has me thinking that despite the badge program
something is still missing here.

What could be done, from a community, or even CII perspective, to avoid further
cross channel miscommunication mishaps between security researchers and our broad
set of FOSS projects in the community?

Cc'ing two folks which I believe are not subscribed. Perhaps this is Off topic,
but, not sure where *else* could such a topic be discussed in a proactive
manner.

Luis

Werner Koch <wk@...>
 

Hi!

On Tue, 15 May 2018 01:35, mcgrof@... said:

The tone should therefore have been more about tons of MUAs needing fixing. But
everything else seems hype.
Below is a mail I just sent to the gnupg-users list. I hope it shows a
bit of that overhyped thing by having a table easy to read in a mail.
The table is from draft 0.9.0 which was published yesterday a efail.de.


Shalom-Salam,

Werner

--8<---------------cut here---------------start------------->8---
Doesn't CERT read the paper before produciong a report? The table of
vulnerable MUAs is easy enough to read. To better see what we are
discussing, here is the table in plain text format with the check marks
replaced by yes and no.

TABLE OF VULNERABLE MAIL CLIENTS

| OS | Client | S/MIME | PGP |
| | | | -MDC | +MDC | SE |
|---------+-----------------+--------+------+------+-----|
| Windows | Outlook 2007 | yes | yes | yes | no |
| | Outlook 2010 | yes | no | no | no |
| | Outlook 2013 | user | no | no | no |
| | Outlook 2016 | user | no | no | no |
| | Win. 10 Mail | yes | – | – | – |
| | Win. Live Mail | yes | – | – | – |
| | The Bat! | user | no | no | no |
| | Postbox | yes | yes | yes | yes |
| | eM Client | yes | no | yes | no |
| | IBM Notes | yes | – | – | – |
| Linux | Thunderbird | yes | yes | yes | yes |
| | Evolution | yes | no | no | no |
| | Trojitá | yes | no | no | no |
| | KMail | user | no | no | no |
| | Claws | no | no | no | no |
| | Mutt | no | no | no | no |
| macOS | Apple Mail | yes | yes | yes | yes |
| | MailMate | yes | no | no | no |
| | Airmail | yes | yes | yes | yes |
| iOS | Mail App | yes | – | – | – |
| | Canary Mail | – | no | no | no |
| Android | K-9 Mail | – | no | no | no |
| | R2Mail2 | yes | no | yes | no |
| | MailDroid | yes | no | yes | no |
| | Nine | yes | – | – | – |
| Webmail | United Internet | – | no | no | no |
| | Mailbox.org | – | no | no | no |
| | ProtonMail | – | no | no | no |
| | Mailfence | – | no | no | no |
| | GMail | yes | – | – | – |
| Webapp | Roundcube | – | no | no | yes |
| | Horde IMP | user | no | yes | yes |
| | AfterLogic | – | no | no | no |
| | Rainloop | – | no | no | no |
| | Mailpile | – | no | no | no |


- = Encryption not supported
no = Not vulnerable
yes = Vulnerable
user = Vulnerable after user consent

-MDC = with stripped MDC, +MDC = with wrong MDC, SE = SE packets

My conclusion is that S/MIME is vulnerable in most clients with the
exception of The Bat!, Kmail, Claws, Mutt and Horde IMP. I take the
requirement for a user consent as non-vulnerable. Most of the
non-vulnerable clients use GnuPG as their engine.

For OpenPGP I see lots of no and only a few vulnerable clients: Support
for Outlook 2007 has long been dropped and Gpg4win/GpgOL gives a big
warning when you try to use it with OL2007. All other Outlook versions
are not vulnerable. The case for Thunderbird/Enigmail is not that clear
because the researcher confirmed that Enigmail 2.0 is in general not
vulnerable; we don't know which version of Enigmail was tested. I don't
know Postbox, Apple mailers or Horde IMP.
--8<---------------cut here---------------end--------------->8---


--
# Please read: Daniel Ellsberg - The Doomsday Machine #
Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.

Tom Ritter
 

I think there's a discussion relating to CII here. I agree this isn't
the right place but since there's no general CII discussion list (nor
is there really enough traffic for one) - we hijack away!

One of the discussions I've had in the past as it related to CII is
how Open Source projects should handle patches for vulnerabilities.
I've pointed to OpenSSL as a model for example. They are very diligent
about developing fixes and not pre-releasing them; they give
notification of the day and approximate time for patches, and these
things give enterprises (I imagine, not actually in charge of patching
enterprise-deployments of OpenSSL) a lot of comfort and capacity
planning.

This type of coordinated disclosure is another situation where the
interests of affected vendors, affected consumers, and security
researches are not necessarily at odds - but are neither in alignment.
Security Researchers want (and sometimes need to justify their
position in orgs) big press coverage. Fancy websites, demos, and
'simplified' impact statements all work to their favor. (And when I
say 'simplified' I don't mean that derogatorily: "Attack leaks
contents of PGP/S/MIME Encrypted Email" is still accurate and much
simpler than "Poor Content Handling in certain Email Clients may leak
PGP/S/MIME contents")

Proposals that push on security researchers to avoid hype; avoid
trying to make a big impact with their work are doomed to failure. All
you're going to do is push them to coordinate with you less, to the
point where a disclosure date will come and they'll release a website
and exclusive on CNN and you won't have known either was coming.
Instead, i think the way to do it is to push Security Researchers to
coordinate with you _more_.

They've got a big attack on drupal? Hell give them
bigattack.drupal.com so you can lend it legitimacy and show you're
working with them. Work to crate a joint media message together and
provide quotes that can be used in stories about it. Instead of
silently identifying and fixing a variant of their attack you
discover; add to their paper/presentation. If it's significant enough,
you can ask to co-present/co-author. Some bugs are so simple there's
not much meat to the story, but as someone who has reviewed
submissions for security conferences, it's really rare and really
great when a researcher and the researched co-present and tell both
their sides of the story. There are a _lot_ of lessons to be learned
from those types of talks.

While all of this applies to FOSS and non-FOSS, I think (or hope) that
FOSS should be more open to it. I think (or hope) that there's less
ego in FOSS when it comes to projects and it's easier for open source
projects to say "Wow that's a really awesome find" or "That's a really
impressive chain that was built to exploit this" and congratulate and
appreciate researchers instead of seeing it as an us vs them
situation.

-tom

On 14 May 2018 at 18:35, Luis R. Rodriguez <mcgrof@...> wrote:
As you may know there is tons of media coverage over efail:

https://efail.de/

The GnuPG team response seems to indicate that the researchers really
didn't properly engage or tune their message to avoid such hype over
such issues:

https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060315.html
https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060318.html

The tone should therefore have been more about tons of MUAs needing fixing. But
everything else seems hype.

Since CII started in part as a response to Heartbleed, and the badge program is
IMHO a success story considering the number of projects which have been shaping
up to meet the requirements, it has me thinking that despite the badge program
something is still missing here.

What could be done, from a community, or even CII perspective, to avoid further
cross channel miscommunication mishaps between security researchers and our broad
set of FOSS projects in the community?

Cc'ing two folks which I believe are not subscribed. Perhaps this is Off topic,
but, not sure where *else* could such a topic be discussed in a proactive
manner.

Luis
_______________________________________________
CII-badges mailing list
CII-badges@...
https://lists.coreinfrastructure.org/mailman/listinfo/cii-badges

David A. Wheeler
 

Luis R. Rodriguez:
As you may know there is tons of media coverage over efail:

https://efail.de/
...
What could be done, from a community, or even CII perspective, to avoid further
cross channel miscommunication mishaps between security researchers and
our broad set of FOSS projects in the community?
I don't know what can be done, but it's definitely a worthy topic, because
media circuses and miscommunication are happening a lot. Unfortunately,
for many the economics encourage it. The researchers get quick (valuable) notoriety,
and the media get good clickbait (and many in the media don't
understand the issues anyway).

Cc'ing two folks which I believe are not subscribed. Perhaps this is Off topic,
but, not sure where *else* could such a topic be discussed in a proactive
manner.
That's a fair "scope of mailing list" question.

If we can somehow turn this into some kind of "best practice" kind of thing,
this is definitely on-topic for this mailing list. I don't know if we can,
but the discussion on *trying* to do so is definitely on-topic.
I don't know of any "generic CII" mailing list, but since many of us are involved in
the CII generally, and it's closely related, I think it's okay for now.

An alternative (and much larger) forum is the oss-security mailing list.

--- David A. Wheeler

Danny O'Brien <danny@...>
 

From: Tom Ritter <tom@...>
Subject: Re: [CII-badges] GnuPG efail - researcher discussion failure
Date: May 15, 2018 at 9:57:56 AM EDT
To: "Luis R. Rodriguez" <mcgrof@...>
Cc: cii-badges@..., Werner Koch <wk@...>,
Katitza Rodriguez <katitza@...>
I think there's a discussion relating to CII here. I agree this isn't
the right place but since there's no general CII discussion list (nor
is there really enough traffic for one) - we hijack away!
Kat passed on the thread --

I won't hijack this thread any more than it has been, but EFF would be
happy to join any discussion for making this better. God knows we
learned (and re-learned) a lot in this, and I'm pushing for writing up a
public post-mortem to help others in similar situations.

Anyway, just wanted to stick my name here for those of you who don't
have a contact with us.

d.


One of the discussions I've had in the past as it related to CII is
how Open Source projects should handle patches for vulnerabilities.
I've pointed to OpenSSL as a model for example. They are very diligent
about developing fixes and not pre-releasing them; they give
notification of the day and approximate time for patches, and these
things give enterprises (I imagine, not actually in charge of patching
enterprise-deployments of OpenSSL) a lot of comfort and capacity
planning.

This type of coordinated disclosure is another situation where the
interests of affected vendors, affected consumers, and security
researches are not necessarily at odds - but are neither in alignment.
Security Researchers want (and sometimes need to justify their
position in orgs) big press coverage. Fancy websites, demos, and
'simplified' impact statements all work to their favor. (And when I
say 'simplified' I don't mean that derogatorily: "Attack leaks
contents of PGP/S/MIME Encrypted Email" is still accurate and much
simpler than "Poor Content Handling in certain Email Clients may leak
PGP/S/MIME contents")

Proposals that push on security researchers to avoid hype; avoid
trying to make a big impact with their work are doomed to failure. All
you're going to do is push them to coordinate with you less, to the
point where a disclosure date will come and they'll release a website
and exclusive on CNN and you won't have known either was coming.
Instead, i think the way to do it is to push Security Researchers to
coordinate with you _more_.

They've got a big attack on drupal? Hell give them
bigattack.drupal.com so you can lend it legitimacy and show you're
working with them. Work to crate a joint media message together and
provide quotes that can be used in stories about it. Instead of
silently identifying and fixing a variant of their attack you
discover; add to their paper/presentation. If it's significant enough,
you can ask to co-present/co-author. Some bugs are so simple there's
not much meat to the story, but as someone who has reviewed
submissions for security conferences, it's really rare and really
great when a researcher and the researched co-present and tell both
their sides of the story. There are a _lot_ of lessons to be learned
from those types of talks.

While all of this applies to FOSS and non-FOSS, I think (or hope) that
FOSS should be more open to it. I think (or hope) that there's less
ego in FOSS when it comes to projects and it's easier for open source
projects to say "Wow that's a really awesome find" or "That's a really
impressive chain that was built to exploit this" and congratulate and
appreciate researchers instead of seeing it as an us vs them
situation.

-tom

On 14 May 2018 at 18:35, Luis R. Rodriguez <mcgrof@...> wrote:

As you may know there is tons of media coverage over efail:

https://efail.de/

The GnuPG team response seems to indicate that the researchers really
didn't properly engage or tune their message to avoid such hype over
such issues:

https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060315.html
https://lists.gnupg.org/pipermail/gnupg-users/2018-May/060318.html

The tone should therefore have been more about tons of MUAs needing
fixing. But
everything else seems hype.

Since CII started in part as a response to Heartbleed, and the badge
program is
IMHO a success story considering the number of projects which have been
shaping
up to meet the requirements, it has me thinking that despite the badge
program
something is still missing here.

What could be done, from a community, or even CII perspective, to avoid
further
cross channel miscommunication mishaps between security researchers and
our broad
set of FOSS projects in the community?

Cc'ing two folks which I believe are not subscribed. Perhaps this is
Off topic,
but, not sure where *else* could such a topic be discussed in a
proactive
manner.

Luis
_______________________________________________
CII-badges mailing list
CII-badges@...
https://lists.coreinfrastructure.org/mailman/listinfo/cii-badges