#216 PrivacyLeak in X-Enigmail-Version

fixed
nobody
None
1.6.0
Minor
All
1.7.0
2014-08-23
2013-11-24
No

It has been noted that there are some quite important privacy leak in the
"X-Enigmail-Version:" header that contain usually very sensitive
information regarding the software version used.

The X-Enigmail-Version is reported for ALL email being sent by thunderbird, being them encrypted or un-encrypted.

In the NSA XKEYSCORE's ages, those kind of information does provide a very
important weakness.

The Adversary capable of massively monitoring communications, profiling who
encrypt their email communications, can profile the exact version of encryption
software used waiting for a vulnerability to be found.

When a vulnerability is found for the exact version of the encryption software
used, the adversary can exploit the "exposure window" by having a prior
knowledge of the end-point encryption software weakness.

This ticket is to improve Enigmail not to insert any kind of header to enable an adversary to profile and monitor the end-user's used software.

A discussion on this issue started on liberationtech mailing list on https://mailman.stanford.edu/pipermail/liberationtech/2013-November/012239.html with early identification by Tramaci of OnionMail http://onionmail.info/ .

This issue has been fixed by Tor Project version of Thuderbird,TorBirdy that's hardening the security of Enigmail https://trac.torproject.org/projects/tor/wiki/torbirdy .

Discussion

  • Ludwig Hügelschäfer

    Sending of OpenPGP-Id-header and OpenPGP-key-URL can be disabled "via account settings -> OpenPGP Security -> Advanced". Deselect the checkboxes "Send OpenPGP key Id" and "Send URL for key retrieval". Do this for every OpenPGP enabled account.

    The sending of X-Enigmail-Version is controlled by a hidden preference, set by default. It can be controlled by the config-editor (Thunderbird Preferences -> Advanced -> Select Tab General, select button Config Editor). Quit and respect the warning. Type "extensions.enigmail.addHeaders" into the search box. Set to false.

    Sending of Enigmail comment in can be disabled in OpenPGP preferences:

    "Add Enigmail comment in OpenPGP signature". Remove the checkbox.

    All other version and comment strings can be disabled by adding
    "--no-emit-version --no-comments" into the "Additional parameters for GnuPG" box in the OpenPGP preferences -> advanced tab.

    Summary: Everything is controllable today, at least for an advanced user. The only arguable thing left in my eyes is moving "extensions.enigmail.addHeaders" from a hidden to a GUI preference or combining it with an existing GUI preference and maybe setting it to "false" per default.

    My personal opinion: I find it naive to believe that a big adversary will wait until a weakness of the crypto software is found. It will be first try the browser software, and especially the flash player plugin. Chances are MUCH higher to find a hole there, regarding the history of the recent years.

     
  • Patrick Brunschwig

    I fully agree with Ludwig. What advantage to you have by knowing that a mail was encrypted using a specific version of Enigmail? Enigmail does not contain any cryptographic algorithms, thus knowing the version number does not help you a lot.

    The Tor Project provides software for people who are specifically more concerned about the sensitivity of just any data than an average user. Therefore I don't see why the defaults in Enigmail should be different than they are today.

     
  • Fabio Pietrosanti (naif)

    Exposing the exact version of a security software is a very bad practice that enable an attacker to properly profile the targets in planning for remote exploit attacks.

    Any penetration tester carrying on a security audit on Enigmail would report this as a security weakness.

    For example security tools like nmap do provide the ability to scan for "software version" of server software, in order to gather intelligence on target to prepare for further attack: http://nmap.org/book/vscan.html

    It's commonly agreed in the security community that preventing target fingerprinting is an important step in order to make give less attack vectors / path to the attacker.

    So, it's a security bug to report the exact application version.

    GnuPG already fixed this issue,following my reporting, and now does not report anymore in the Comment: header the exact GnuPG version as documented here https://bugs.g10code.com/gnupg/issue1572 and in the release notes http://lists.gnupg.org/pipermail/gnupg-devel/2013-December/028102.html .

    In this ticket is documented an even serious issue, that Enigmail is adding the header that disclose it's presence in the sender's email client for every email that are being sent, also if not encrypted with Enigmail.

    A software is secure when it's default configuration is secure.

    So i suggest strongly to implement proper fixing of this ticket by:
    Stop reporting of Enigmail version in the header (by default)
    Stop sending Enigmail version header on non-encrypted email (by default)

    Waiting for yours

    Fabio

     
  • Matthijs R. Koot

    I have to agree with Fabio on this; the current default setting should be considered to be a low-risk security misconfiguration. Information about software configuration should be assumed to be of use to adversaries. The notion that other attack vectors/paths exist that are generally (?) more likely to be exploited does not justify the current default. To cite from Fabio's post to [liberationtech]: are those pieces of information really needed to make the Enigmail / GnuPG software working?

     
    Last edit: Matthijs R. Koot 2014-01-01
  • Sven Neuhaus

    Sven Neuhaus - 2014-02-06

    I would welcome it if Enigmail had safe defaults.
    There is no reason why a PGP signed email by default reveals the exact version of Thunderbird, Enigmail and GnupG used as well as operating system details (I know some of these headers are not enigmails fault).

     
  • Patrick Brunschwig

    fixed on trunk

     
  • Patrick Brunschwig

    • status: open --> fixed
    • Fixed in version: --- --> 1.6.1
     
  • Patrick Brunschwig

    • Fixed in version: 1.6.1 --> 1.7.0
     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks