GPG: Deprecated hash + local "game over" exploit
Greetings, A couple of days ago Shawn pointed out offlist that my GPG installation was using SHA1 when signing messages. Although seven hash functions are included in GnuPG 1.4.16, SHA1 is still the default. For most purposes this is no cause for panic, but it's "untidy" at best and might occasionally bite someone in the ass. The simple cure is to append this to gpg.conf: personal-digest-preferences SHA256 SHA512 digest-algo SHA256 I wonder when the gpg guise will get around to updating the default hash... On a related note, gnupg-agent stores typed pass phrases for 10 minutes, as a convenience when reading or signing multiple files or documents. Only one little thing: It stores typed pass phrases until the machine is powered off, regardless of configuration settings per the gnupg-agent man page. Last time I checked, this bug was dismissed by Debian as a non-issue, saying that exploiting it would require physical access to the machine and "physical access is game over." That's an excuse to leave the bug in place, not a reason. I am sure present company can provide several examples of cases where the presence of gnupg-agent in its present broken condition "is game over" for the user. Four years ago I noticed this problem, exhausted "sane" remedies, and found an effective work-around that denies gnupg-agent access to pass phrases when using Enigmail or GPG itself. http://pilobilus.net/gnupg-agent_work_around_for_linux_mint.html :o)
On 07/01/2017 03:17 PM, Steve Kinney wrote:
Last time I checked, this bug was dismissed by Debian as a non-issue, saying that exploiting it would require physical access to the machine and "physical access is game over." That's an excuse to leave the bug in place, not a reason. I am sure present company can provide several examples of cases where the presence of gnupg-agent in its present broken condition "is game over" for the user.
Are you sure you didn't accidentally save your passphrase to your GNOME password manager (seahorse)? I thought I had the same problem where passphrases were being cached far longer than they should be, until I found this "helpful" remembering of my passphrase (which I have since fixed). I'm going to do some further testing; I have explicitly added the supposed default TTL values to gpg-agent.conf and I will see if I still have issues. -- Shawn K. Quinn <skquinn@rushpost.com> http://www.rantroulette.com http://www.skqrecordquest.com
On 07/01/2017 07:30 PM, Shawn K. Quinn wrote:
On 07/01/2017 03:17 PM, Steve Kinney wrote:
Last time I checked, this bug was dismissed by Debian as a non-issue, saying that exploiting it would require physical access to the machine and "physical access is game over." That's an excuse to leave the bug in place, not a reason. I am sure present company can provide several examples of cases where the presence of gnupg-agent in its present broken condition "is game over" for the user.
Are you sure you didn't accidentally save your passphrase to your GNOME password manager (seahorse)? I thought I had the same problem where passphrases were being cached far longer than they should be, until I found this "helpful" remembering of my passphrase (which I have since fixed).
Quite sure: Taking measures to specifically deny the passphrase to gnupg-agent fixed the problem at once. Also, I was using KDE4 at the time, on a system where Cinnamon is the default desktop.
I'm going to do some further testing; I have explicitly added the supposed default TTL values to gpg-agent.conf and I will see if I still have issues.
I created gpg-agent.conf and put it in the right directory per the man page, because it was not there... and it had no effect. Especially disturbing because, although I never have a reason to type a GPG pass phrase as an administrator, logging out of my user account did not remove the pass phrase from memory. Nothing short of powering off did the job. :o/
On Sat, Jul 01, 2017 at 04:17:29PM -0400, Steve Kinney wrote:
A couple of days ago Shawn pointed out offlist that my GPG installation was using SHA1 when signing messages. Although seven hash functions are included in GnuPG 1.4.16, SHA1 is still the default.
It was funny when someone (likely you) signed inline with SHA1 email about SHA1 collisions and the choice of hash was obvious :)
On 07/02/2017 03:13 AM, Georgi Guninski wrote:
On Sat, Jul 01, 2017 at 04:17:29PM -0400, Steve Kinney wrote:
A couple of days ago Shawn pointed out offlist that my GPG installation was using SHA1 when signing messages. Although seven hash functions are included in GnuPG 1.4.16, SHA1 is still the default.
It was funny when someone (likely you) signed inline with SHA1 email about SHA1 collisions and the choice of hash was obvious :)
I don't recall doing that, but I can't rule it out. :o)
participants (3)
-
Georgi Guninski -
Shawn K. Quinn -
Steve Kinney