Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
reading through the message my yellow lamp came on when they said to "use Signal instead"
there's been trouble with the program that reads the GPG passphrase and holds it ( "pinentry" ? ) -- the question being -- how long should the passphrase be held ?
One should hit the lock sequence on the keyboard before stepping away from a workstation.
I've had trouble from time to time with Thunderbird/Enigmail. This seems to be related to the use of the OpenPGP interface rather than the GPGME as used in CLAWS
CLAWS seems to be a much more stable platform; I prefer that to T-Bird although I've yet to finish converting my various receive rules.
There's been a lot of chatter on the GnuPG mail list this morning suggesting the folks at EFF are causing needless panic and ultimately sent this press release:
Quote:
From: Gnupg-users [mailto:gnupg-users-bounces+jlightner=dsservices.com@gnupg.org] On Behalf Of Robert J. Hansen
Sent: Monday, May 14, 2018 8:28 AM
To: GnuPG-Users
Subject: Efail press release
Over the last few hours, Werner, Andre, and I have been working on an
official statement about the Efail paper. Without further ado, here it is.
An Official Statement on New Claimed Vulnerabilities
== ======== ========= == === ======= ===============
by the GnuPG and Gpg4Win teams
(This statement is only about the susceptibility of OpenPGP, GnuPG, and
Gpg4Win. It does not cover S/MIME.)
Recently some security researchers published a paper named "Efail:
Breaking S/MIME and OpenPGP Encryption using Exfiltration Channels".
The EFF has gone so far as to recommend immediately uninstalling
Enigmail. We have three things to say, and then we're going to show you
why we're right.
1. This paper is misnamed.
2. This attack targets buggy email clients.
3. The authors made a list of buggy email clients.
In 1999 we realized OpenPGP's symmetric cipher mode (a variant of cipher
feedback) had a weakness: in some cases an attacker could modify text.
As Werner Koch, the founder of GnuPG, put it: "[Phil Zimmermann] and Jon
Callas asked me to attend the AES conference in Rome to discuss problems
with the CFB mode which were on the horizon. That discussion was in
March 1999 and PGP and GnuPG implemented a first version [of our
countermeasure] about a month later. According to GnuPG's NEWS file,
[our countermeasure] went live in Summer 2000."
The countermeasure Werner mentions is called a Modification Detection
Code, or MDC. It's been a standard part of GnuPG for almost eighteen
years. For almost all that time, any message which does not have an MDC
attached has caused GnuPG to throw up big, clear, and obvious warning
messages. They look something like this:
gpg: encrypted with 256-bit ECDH key, ID 7F3B7ED4319BCCA8, created
2017-01-01
"Werner Koch <wk@gnupg.org>"
[GNUPG:] BEGIN_DECRYPTION
[GNUPG:] DECRYPTION_INFO 0 7
[GNUPG:] PLAINTEXT 62 1526109594
[GNUPG:] PLAINTEXT_LENGTH 69
There is more to life than increasing its speed.
-- Mahatma Gandhi
gpg: WARNING: message was not integrity protected
[GNUPG:] DECRYPTION_FAILED
[GNUPG:] END_DECRYPTION
GnuPG also throws large warning messages if an MDC indicates a message
has been modified. In both cases, if your email client respects this
warning and does the right thing -- namely, not showing you the email --
then you are completely protected from the Efail attack, as it's just a
modern spin on something we started defending against almost twenty
years ago.
If you're worried about the Efail attack, upgrade to the latest version
of GnuPG and check with your email plugin vendor to see if they handle
MDC errors correctly. Most do.
You might be vulnerable if you're running an ancient version of GnuPG
(the 1.0 series; the current is 2.2), or if your email plugin doesn't
handle GnuPG's warning correctly. You might also have had some exposure
in the past if back then you used a pre-2000 version of GnuPG, and/or an
email plugin which didn't handle the warning correctly.
We made three statements about the Efail attack at the beginning. We're
going to repeat them here and give a little explanation. Now that we've
explained the situation, we're confident you'll concur in our judgment.
1. This paper is misnamed. It's not an attack on OpenPGP. It's an
attack on broken email clients that ignore GnuPG's warnings and do silly
things after being warned.
2. This attack targets buggy email clients. Correct use of the MDC
completely prevents this attack. GnuPG has had MDC support since the
summer of 2000.
3. The authors made a list of buggy email clients. It's worth looking
over their list of email clients (found at the very end) to see if yours
is vulnerable. But be careful, because it may not be accurate -- for
example, Mailpile says they're not vulnerable, but the paper indicates
Mailpile has some susceptibility.
The authors have done the community a good service by cataloguing buggy
email email clients. We're grateful to them for that. We do wish,
though, this thing had been handled with a little less hype. A whole
lot of people got scared, and over very little.
the more i read about this the brighter that yellow lamp gets. the red lamp is likely to come on,-- RSN
evidently this whole "bug" depends on malicious code delivered in an HTML document. Probably using java to connect the HTML "message document" to additional remote servers -- and then using a corrupted document such as flash, or word macros|scripts, or pdf documents containing similar garbage.
the immediate question is then: what does this have to do with PGP/GPG ?
any received e/mail could contain that sort of attack code
the advantage of PGP/GPG is that -- when the message is signed -- you may have a pretty good idea who sent it ( if you're doing PGP/GPG right you do ) -- and -- that the message has not been altered en route.
if I understand PGP/MIME properly -- PGP/MIME acts as a container -- similar to .zip: when a message is "MIMED" the e/mail text and any attachments are collected and put into this pgp/mime "container". It is the container then that is encrypted and signed.
i see a lot of emphasis on encryption. and that's All Good although the AUTHENTICATION -- that comes with the SIGNATURE is likely more important. a lot of fraud -- digital or otherwise -- depends on fake identities. the whole of the key model in PGP/GPG was designed to address this problem -- in the digital environment.
this being the case then when the pgp/mime container has been decrypted the content is then presented to the HTML rendering engine. And if the rendering engine hits that malicious code fragment then that's where the trouble hits.
but this is NOT DIFFERENT from reading any ordinary HTML base e/mail.
which brings us to an important question: in what manner is e/mail being used? for protected traffic it should be used with PGP/GPG -- using encryption and signatures. yes-- you'll have to validate the keys -- but: you need to do that in this crazy world today.
any system receiving and processing e/mail inputs from the public -- should be using a CONTAINER
interestingly I've seen now another web post directing readers to "use Signal". This is what switches on the yellow light and now 2 yellow lights. is this whole bug-a-marole just a push for this signal app? Signal is fine -- but this ain't the way to promote it.
Last edited by mike acker; 05-15-2018 at 07:29 AM.
Signal is fine -- but this ain't the way to promote it.
No. Signal is not. The EFF just decided not to promote worry or hysteria about it's bugs like it has with the not-PGP bug. There were some major holes in it during the last year that were a bigger deal than this not-PGP hole. Further, unlike e-mail (IMAPS+SMTP) the architecture of Signal is centralized and resides on servers in the US. If that is not enough, there are proprietary dependencies in part of it. Oh and I wouldn't trust most of the platforms it is marketed for, even if the baseband OS were not also an issue.
The cynic in me says to follow the money and see who is using the EFF for influence *cough*omidyar*cough* and see who turns up and what their agenda is. RIP John Perry Barlow.
But I agree, what the EFF did was not the right way to promote signal.
the immediate question is then: what does this have to do with PGP/GPG
That was the main point of the discussion by the GnuPG folks. They're saying the issue has all to do with badly configured MTAs but the EFF allowed the authors to post as if it is a bug in OpenPGP/GPG in their title even though the detail that follows in the post indicates it is only an issue in specific MTAs.
I do give the GnuPG folks a bit of knock though. They admit someone asked to have a call with them after they responded to an early draft but they never scheduled the call, apparently thinking the authors would.
if I understand the process correctly: when an e/mail is signed and/or encrypted using pgp/mime: First the message text and any attachment(s) are packed into the pgp/mine container. like .zip -- this results in a single file. the pgp/mime container is then hashed and the hash is then signed using the sender's pgp secret key.
if encryption was also selected then the pgp/mine container will also be encrypted for the recipient(s) public key(s)
once this is complete the message can be sent
if the message is intercepted en route ( not very likely ) -- then -- if so much as 1 bit is changed in the pgp/mine container -- the sender's signature will fail when the recipient checks it. inserting a malicious code fragment ? maybe but it would be necessary to adjust the container such that the identical hash is developed. possible I suppose but the cost would put this well out of the realm of probable.
now if the message is encrypted but not signed then this attack might be more practical -- except for that modification blocker that was installed some time back -- what was it called ??
I can see sending a message in plain text -- but signed. but WHY would anyone send one encrypted but not signed ?????
too many good folks today focus way too much on encryption and not nearly enough on AUTHENTICATION.
Last edited by mike acker; 05-15-2018 at 10:06 AM.
if the message is intercepted en route ( not very likely ) -- then -- if so much as 1 bit is changed in the pgp/mine container -- the sender's signature will fail when the recipient checks it. inserting a malicious code fragment ? maybe but it would be necessary to adjust the container such that the identical hash is developed. possible I suppose but the cost would put this well out of the realm of probable.
The problem is that the attacker can remove the signature completely, and then send an unsigned modified message. Now, even if you get a warning that the message is unsigned, you're email client might still decrypt and display the HTML automatically. If "display HTML" includes rendering <img> tags or similar, then it accesses URL's chosen by the attacker, meaning you've sent them all your secret data.
The problem is that the attacker can remove the signature completely, and then send an unsigned modified message. Now, even if you get a warning that the message is unsigned, you're email client might still decrypt and display the HTML automatically. If "display HTML" includes rendering <img> tags or similar, then it accesses URL's chosen by the attacker, meaning you've sent them all your secret data.
thanks--
to intercept -- and then to re-process a e/mail en-route -- is no simple task. One might think about getting some malware into an eMail server someplace.
but in this scenario -- if, as the attacker, I'm going to strip the signature -- why should i bother to intercept a message? I can easily generate a message, spoof the sender's name, and encrypt it using your public key
let's say I spoof the sender's name to be your boss' name
so now you receive an encrypted -- but unsigned message that appears to be from your boss
so far this looks like an ordinary phishing attack. ordinary folks just rushing along with the day's business may well click an infected message without giving it any further thought
this is latest gig then seems more like a new twist to an existing problem: phishing.
the real problem here leads back to what I like to describe as executable documents: documents that have program-like capabilities: macros, scripts, flash, ...
I'm interested in the container concept as possible help for this problem. I've played with Firejail a bit but I need to learn to edit the configuration file.
to intercept -- and then to re-process a e/mail en-route -- is no simple task.
It doesn't have to be en-route, taking an old message and re-sending could also work. Which is also not necessarily easy.
Quote:
but in this scenario -- if, as the attacker, I'm going to strip the signature -- why should i bother to intercept a message?
The idea is that there is some secret data in that message that the attacker can trick your mail client into revealing.
The attacker modifies the message in such a way that when the email client decrypts and renders the HTML, the decrypted data ends up in an image URL, so that the email client sends the decrypted data to the attacker's web server. Note that you don't have to respond to the message, just read it.
It doesn't have to be en-route, taking an old message and re-sending could also work. Which is also not necessarily easy.
The idea is that there is some secret data in that message that the attacker can trick your mail client into revealing.
The attacker modifies the message in such a way that when the email client decrypts and renders the HTML, the decrypted data ends up in an image URL, so that the email client sends the decrypted data to the attacker's web server. Note that you don't have to respond to the message, just read it.
"modifies the message"
??
He's gonna have to decrypt it first and if he's got that done why bother with anything further? He'd just be risking detection unnecessarily.
this while "EFAIL" report looks a little weak to me. perhaps this is meant to deliver malware that then conducts general surveillance of the target.
Last edited by mike acker; 05-16-2018 at 06:57 AM.
if you modify the .asc -- the message won't decrypt:
like so:
~/Documents/1 Workareas/Workarea34$ gpg --decrypt Chromebook_Analysis-X.html.asc
gpg: CRC error; B109E1 - 79DE47
gpg: encrypted_mdc packet with unknown version 255
there's a pretty good explanation of what's actually going on in this -- HERE
the attack is on the e/mail program and the standard for message processing and this appears to leverage messages which are only partially encrypted/signed. if i recall -- Thunderbird issues a warning note for this condition.
I generally did like CLAWS better, anyway
Last edited by mike acker; 05-16-2018 at 04:39 PM.
if you modify the .asc -- the message won't decrypt:
It will still decrypt if you update the CRC accordingly, and don't mangle the message too badly. It does show a warning "gpg: WARNING: encrypted message has been manipulated!", but if your mail client ignores the warning, or doesn't ignore it but still renders the HTML, then that doesn't help so much.
Now, you might object that I haven't actually changed the message. Which is true, I only modified the MDC. Changing the message to something readable it is tricky because of the compression. I don't have time to research the techniques to get around this and come up with an example, unless... could you give me a million dollars so I can quit my job and devote myself full-time to the task?
$ gpg Chromebook_Analysis-XX.html.asc
gpg: WARNING: no command supplied. Trying to guess what you mean ...
gpg: encrypted with 4096-bit RSA key, ID 6A40F7DB2F7E3BAA, created 2015-09-02
"Mike Acker <mike_acker@charter.net>"
gpg: WARNING: encrypted message has been manipulated!
Having read the efail.de message page -- I think I have a better understanding of this issue. as noted elsewhere I've been drifting away from T-Bird; I like CLAWS better. I think their approach is better and their program seems to run better as well.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.