Your security boundary should extend beyond the device on which you are communicating with another. In other words, do the encryption/decryption on another device entirely and copy the encrypted text only from/to your communication device. PITA, but these flaws are just another collection that have been found after the last two sets found in the past.
Pretty wild that a malicious mailto: link might attach your secret keys and files from your PC to an outgoing message
Boffins testing the security of OpenPGP and S/MIME, two end-to-end encryption schemes for email, recently found multiple vulnerabilities in the way email client software deals with certificates and key exchange mechanisms. They found that five out of 18 OpenPGP-capable email clients and six out of 18 S/MIME-capable clients are …
Wednesday 19th August 2020 13:29 GMT Snake
Moving security boundaries
That only moves the target to another machine, a machine that is connected via a vulnerable transmission system. If you can't crack the encoding of the encryption engine of your proposed server/client topology, a worm that taps the network feed or a even a rootkit on the more vulnerable client will do just as well.
All this plan does is add more nodes thereby crafting a larger potential attack surface. At the least it is better to minimize your surface profile and keep unencrypted data on a single machine/user interface, rather than attempt to secure multiple machine vectors plus the vulnerable communications links between them.
Wednesday 19th August 2020 14:21 GMT David Shaw
exactly this. I was required to upload details of my "DUQU" attack from the usual suspects to my CERT. They required an encrypted email. I chose (randomly) one of our hundreds of offline PCs, in a random room. Composed the encrypted text and sent it.
cue: instantly vast numbers (twenty a week, up from zero) of 'spam' (stuff that pretended to be spam, containing lots of evil code), they carried on for weeks, also sent some, highly selectively, to just me & my boss, out of the thousands of staff at work. So obvious, you might have well have signed it Cheltenham & Gloucester Building Society.est1850 .#
My CERT was eventually satisfied; the 'masters of the internet' presumably now have my plaintext - guys/gals/inter: if you *really* need something, then just phone and ask - not everything needs to be put as highest priority in your plausibly-deniable-obfuscated-malware-SPAM-cannon
#other autocratic nations presumably similarly go after everything encrypted, but why don't I notice their attacks?
Wednesday 19th August 2020 09:24 GMT Sitaram Chamarty
hah! paranoia pays off
I've always been a paranoid bugger who runs the mail client in one userid, and 3 different browsers in 2 other userids.
If the malicious link appeared on a web page, it would hit a blank wall -- the userid that is running the browser won't find an email client running, and even if it starts one it's definitely not configured to do anything.
It's also fairly easy to setup this kind of separation in Linux; I imagine a lot of people may be doing similar things (if they're paranoid enough that is).
Wednesday 19th August 2020 12:11 GMT bombastic bob
Re: hah! paranoia pays off
yeah I generally don't trust 'mailto' links either, and always examine the e-mail before sending something. Having attachments pre-loaded [especially if it's something important from a known location] is obviously bad [what is /etc/shadow and my e-mail address book doing attached to this e-mail?] but I haven't directly clicked on links in e-mails in YEARS, if not even DECADES.
That is because I _ALWAYS_ view e-mail as plain text. It's amazing how many unsolicited e-mails have embedded links within them, sometimes to embedded attachments, but often long alphabet-soup links to web sites that can THEN track you or confirm you received their spam. And of course they hide it with a legit looking link inside the 'a' tag, which is obvious bogus when NOT viewed as HTML...
and a 'mailto' within an e-mail would show up the same way. web site links, however, are (obviously) still subject to trickery.
Wednesday 19th August 2020 14:42 GMT Mike 137
Getting it right
El Reg: "Pegasus Mail is said to be affected though it doesn't have a designated CVE – it may be that one of the unidentified CVEs applies here."
The paper: "Similar attacks were found in 2000 for Pegasus... " ref: CVE-2000-0930 (Pegasus Mail 3.12)"
There are no subsequent reports. Pegasus is now at V4.73 (2018) and uses entirely different transport security mechanisms.
Pegasus is, and always has been, generally very robust and bug free, so don't take the Reg's negative implication as gospel.
Wednesday 19th August 2020 18:24 GMT Paul Hovnanian
Lets see ...
My web page has a mailto link. But the web server that hands out that link runs as a relatively untrusted user on my machine*. And all of the private keys, security tokens and other detritus needed to support encryption/decryption/certificate signing reside outside of the scope of its permissions. How is it going to get hold of anything interesting?
*Actually, my web page is hosted on a completely different machine in a data center in a city far, far away from my e-mail clients. My MX record doesn't point to anything more interesting than a system that knows where to forward my stuff.
Wednesday 19th August 2020 20:26 GMT doublelayer
Re: Lets see ...
It has nothing to do with your server. That's as secure as it was before. It's your users who might have the problem if you decided to alter the content of the pages you are pushing out. Specifically, if you modified the link, they clicked the link, their mail client didn't block your change, they didn't see your modification, and they sent a message, you could get them to divulge a file from their system.