Bug#96144: [Mutt] #580: mutt stores PGP passphrase insecurely
#580: mutt stores PGP passphrase insecurely -+-- Reporter: Marco d'Itri m...@linux.it | Owner: mutt-dev Type: defect | Status: reopened Priority: trivial | Milestone: Component: crypto | Version: 1.5.19 Resolution: |Keywords: -+-- Comment(by petr_p): I looked through the code how passwords are processed. Whereas PGP and SMIME code are straightforward and the password is stored in static buffer only, the ACCOUNT password (used for SASL, SMTP etc.) is really one big mess where the buffer is copied and copied. I can't see any easy way how to catch all password occurrences and to get balanced mlock-munlock dance around them. To have things worse, the code (even the PGP and SMIME) is written in a fashion to get the password and sometimes erase password buffer just before getting new password. That means the password is practically `never' removed, even after password life time elapses. So it's reasonable to mlock buffers for PGP and SMIME on mutt start and never unlock them. Thus we will have possibly 2 pages (8 kB on x86) locked forever. However I don't know what to do with the rest of password buffers. If somebody interests I wrote simple counting memory page locking manager solving problems described in my previous comment (address alignment, page sharing). However due to mutt style, it's unusable in this situation. -- Ticket URL: http://dev.mutt.org/trac/ticket/580#comment:20 Mutt http://www.mutt.org/ The Mutt mail user agent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#96144: [Mutt] #580: mutt stores PGP passphrase insecurely
#580: mutt stores PGP passphrase insecurely
-+--
Reporter: Marco d'Itri m...@linux.it | Owner: mutt-dev
Type: defect | Status: reopened
Priority: trivial | Milestone:
Component: crypto | Version: 1.5.19
Resolution: |Keywords:
-+--
Comment(by Werner Koch):
{{{
On Mon, 27 Jul 2009 17:42, fl...@mutt.org said:
Unless you use set crypt_use_gpgme in which case gpg-agent takes care
of everything.
FWIW, the latest gpgme release 1.2.0 allows direct access to gpg-agent
and thus you can make use of the gpg-agent's passphrase caching feature.
Shalom-Salam,
Werner
}}}
--
Ticket URL: http://dev.mutt.org/trac/ticket/580#comment:
Mutt http://www.mutt.org/
The Mutt mail user agent
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#96144: [Mutt] #580: mutt stores PGP passphrase insecurely
#580: mutt stores PGP passphrase insecurely
-+--
Reporter: Marco d'Itri m...@linux.it | Owner: mutt-dev
Type: defect | Status: reopened
Priority: trivial | Milestone:
Component: crypto | Version: 1.5.19
Resolution: |Keywords:
-+--
Changes (by pdmef):
* component: mutt = crypto
Old description:
{{{
Package: mutt
Version: 1.3.15-2
[NOTE: this bug report has been submitted to the debian BTS as Bug#96144.
Please Cc all your replies to 96...@bugs.debian.org.]
From: Brian Ristuccia br...@ristuccia.com
Subject: mutt stores PGP passphrase insecurely
Date: Thu, 3 May 2001 01:44:50 -0400
When caching passphrases, mutt uses memory that's not locked. The
passphrase
can be recovered if that part of mutt's address space is swapped to disk.
In
order for the secret key to remain secure in the event that the machine
is
lost or stolen, the memory area occupied by the passphrase must be locked
to
prevent the swap file from being contaminated with the passphrase. Note
that
mutt zeros out the passphrase when it times out, but there's no guarantee
that any old blocks on the swap space will be overwritten before the
machine
is shut down or stolen. This issue is of particular importance with
laptop
computers, since PGP encryption is the only thing standing between an
unauthorized reader and your email should the machine get stolen.
Since Linux 2.2.x and 2.4.x don't seem to allow ordinary users to lock
even
small amounts of memory, one potential solution would be to have mutt
executed by a wrapper program that passes it a locked shared memory
segment
just big enough to hold the passphrase. Swap over an encrypted loopback
filesystem initialized with a throwaway key at each reboot is a
workaround.
But using an encrypted loopback filesystem is computationally intensive
and
might drain batteries prematurely, especially on smaller laptops. A
kernel
level swap cleaner daemon that overwrites recently freed swap blocks
would
also work, but with a similar battery life penalty.
--
Brian Ristuccia
br...@ristuccia.com
brist...@cs.uml.edu
How-To-Repeat:
Fix:
}}}
New description:
{{{
Package: mutt
Version: 1.3.15-2
[NOTE: this bug report has been submitted to the debian BTS as Bug#96144.
Please Cc all your replies to 96...@bugs.debian.org.]
From: Brian Ristuccia br...@ristuccia.com
Subject: mutt stores PGP passphrase insecurely
Date: Thu, 3 May 2001 01:44:50 -0400
When caching passphrases, mutt uses memory that's not locked. The
passphrase
can be recovered if that part of mutt's address space is swapped to disk.
In
order for the secret key to remain secure in the event that the machine is
lost or stolen, the memory area occupied by the passphrase must be locked
to
prevent the swap file from being contaminated with the passphrase. Note
that
mutt zeros out the passphrase when it times out, but there's no guarantee
that any old blocks on the swap space will be overwritten before the
machine
is shut down or stolen. This issue is of particular importance with laptop
computers, since PGP encryption is the only thing standing between an
unauthorized reader and your email should the machine get stolen.
Since Linux 2.2.x and 2.4.x don't seem to allow ordinary users to lock
even
small amounts of memory, one potential solution would be to have mutt
executed by a wrapper program that passes it a locked shared memory
segment
just big enough to hold the passphrase. Swap over an encrypted loopback
filesystem initialized with a throwaway key at each reboot is a
workaround.
But using an encrypted loopback filesystem is computationally intensive
and
might drain batteries prematurely, especially on smaller laptops. A kernel
level swap cleaner daemon that overwrites recently freed swap blocks would
also work, but with a similar battery life penalty.
--
Brian Ristuccia
br...@ristuccia.com
brist...@cs.uml.edu
How-To-Repeat:
Fix:
}}}
--
--
Ticket URL: http://dev.mutt.org/trac/ticket/580#comment:18
Mutt http://www.mutt.org/
The Mutt mail user agent
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#96144: [Mutt] #580: mutt stores PGP passphrase insecurely
#580: mutt stores PGP passphrase insecurely -+-- Reporter: Marco d'Itri m...@linux.it | Owner: mutt-dev Type: defect | Status: reopened Priority: trivial | Milestone: Component: mutt| Version: 1.5.19 Resolution: |Keywords: -+-- Changes (by anto...@dyne.org): * version: = 1.5.19 -- Ticket URL: http://dev.mutt.org/trac/ticket/580#comment:17 Mutt http://www.mutt.org/ The Mutt mail user agent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#96144: [Mutt] #580: mutt stores PGP passphrase insecurely
#580: mutt stores PGP passphrase insecurely -+-- Reporter: Marco d'Itri m...@linux.it | Owner: mutt-dev Type: defect | Status: reopened Priority: trivial | Milestone: Component: mutt| Version: Resolution: |Keywords: -+-- Comment(by anto...@dyne.org): Hi, with the 2.6 kernels mlock() is available, that will allow a non-root user to perform what wasn't possible before. Back in the debian bugtracker a patch was provided for this: http://bugs.debian.org/cgi- bin/bugreport.cgi?msg=102;filename=patch-1.5.13.pw.pgpmlock.1;att=1;bug=96144 Do you think that this patch can be included in the next release(s) or do you prefer to update your doc? -- Ticket URL: http://dev.mutt.org/trac/ticket/580#comment:16 Mutt http://www.mutt.org/ The Mutt mail user agent -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#96144: mutt/580: mutt stores PGP passphrase insecurely
Patch forwarded upstream, let's see what happens Cheers Antonio -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#96144: mutt/580: mutt stores PGP passphrase insecurely
On Thu, Sep 21, 2006 at 06:50:06PM -0400, David Shaw wrote:
At least on Linux, mutt can do the right thing with storing
passphrases securely. This may be true on other systems as well, but
I can only say for sure about Linux,
A quick experiment seems to show that's true. The attached patch seems to
work for me (in the sense of no errors returned, rather than
actually checking the contents of swapfiles).
It doesn't do anything except log a debug message if it can't lock/unlock
memory, which to me seems harmless but it's possible other systems might
take exception to a non-root process trying to mlock. Could people using
*BSD, Solaris etc. test this out please?
We might also want to raise the debuglevel from 3 to something higher once
it's tested...
--
Paul
diff -r a47e56ccd99d PATCHES
--- a/PATCHES Fri Sep 08 18:29:12 2006 +
+++ b/PATCHES Fri Sep 22 13:17:10 2006 +0100
@@ -0,0 +1,1 @@
+patch-1.5.13.pw.pgpmlock.1
diff -r a47e56ccd99d main.c
--- a/main.cFri Sep 08 18:29:12 2006 +
+++ b/main.cFri Sep 22 13:17:10 2006 +0100
@@ -964,6 +964,9 @@ int main (int argc, char **argv)
if (Context)
FREE (Context);
}
+#ifdef CRYPT_BACKEND_CLASSIC_PGP
+pgp_void_passphrase ();
+#endif
#ifdef USE_IMAP
imap_logout_all ();
#endif
diff -r a47e56ccd99d pgp.c
--- a/pgp.c Fri Sep 08 18:29:12 2006 +
+++ b/pgp.c Fri Sep 22 13:17:10 2006 +0100
@@ -64,10 +64,19 @@
char PgpPass[LONG_STRING];
time_t PgpExptime = 0; /* when does the cached passphrase expire? */
+int mlocked = 0;
void pgp_void_passphrase (void)
{
memset (PgpPass, 0, sizeof (PgpPass));
+ if (mlocked)
+ {
+ if (munlock(PgpPass, sizeof(PgpPass)))
+ dprint (3, (debugfile, Couldn't unlock passphrase in memory.\n));
+ /* If we couldn't unlock it just now, probably never going to be able to.
+ * Doesn't seem much point in continuing to try. */
+ mlocked = 0;
+ }
PgpExptime = 0;
}
@@ -90,6 +99,10 @@ int pgp_valid_passphrase (void)
if (mutt_get_password (_(Enter PGP passphrase:), PgpPass, sizeof
(PgpPass)) == 0)
{
PgpExptime = time (NULL) + PgpTimeout;
+ if (mlock(PgpPass, sizeof(PgpPass)))
+ dprint (3, (debugfile, Couldn't lock passphrase in memory.\n));
+ else
+ mlocked = 1;
return (1);
}
else
signature.asc
Description: Digital signature
Bug#96144: mutt/580: mutt stores PGP passphrase insecurely
On Fri, Sep 22, 2006 at 13:21:19 +0100, Paul Walker wrote: It doesn't do anything except log a debug message if it can't lock/unlock memory, which to me seems harmless but it's possible other systems might take exception to a non-root process trying to mlock. Could people using *BSD, Solaris etc. test this out please? We might also want to raise the debuglevel from 3 to something higher once it's tested... + if (mlock(PgpPass, sizeof(PgpPass))) + dprint (3, (debugfile, Couldn't lock passphrase in memory.\n)); While you're at it, you might want to evaluate the return code of mlock()/munlock(). My manpage (old Linux 2.4.20 system) has the return values ENOMEM, EPERM, EINVAL. Moritz -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#96144: mutt/580: mutt stores PGP passphrase insecurely
On Fri, Sep 22, 2006 at 01:21:19PM +0100, Paul Walker wrote: On Thu, Sep 21, 2006 at 06:50:06PM -0400, David Shaw wrote: At least on Linux, mutt can do the right thing with storing passphrases securely. This may be true on other systems as well, but I can only say for sure about Linux, A quick experiment seems to show that's true. The attached patch seems to work for me (in the sense of no errors returned, rather than actually checking the contents of swapfiles). It doesn't do anything except log a debug message if it can't lock/unlock memory, which to me seems harmless but it's possible other systems might take exception to a non-root process trying to mlock. Could people using *BSD, Solaris etc. test this out please? For portability, it might be good to make the address being locked land on a page boundary as the POSIX spec for mlock allows this to be an optional requirement. Linux doesn't require this (actually it internally transforms the lock to be on a page boundary), but it might be needed on other systems. On those systems mlock would fail and set errno to EINVAL if the address isn't on a boundary. David pgplfcyJqVzgW.pgp Description: PGP signature
Bug#96144: mutt/580: mutt stores PGP passphrase insecurely
On Fri, Sep 22, 2006 at 09:03:17AM -0400, David Shaw wrote: For portability, it might be good to make the address being locked land on a page boundary as the POSIX spec for mlock allows this to be an optional You're probably right, but I'm afraid I don't know how you do this from user-space. All my knowledge of that kind of thing is kernel-side. :-) If you know how to ensure boundary alignments for global BSS data elements, add it to the patch. -- Paul signature.asc Description: Digital signature
Bug#96144: mutt/580: mutt stores PGP passphrase insecurely
Earlier in this bug it was stated that a process must be root to mlock() memory under Linux. That was true back then (this is a long-lived bug), but it is no longer true in more modern kernels. These days, any process can mlock() however much memory the user chooses to allow it to lock (set via ulimit like the other limits). At least on Linux, mutt can do the right thing with storing passphrases securely. This may be true on other systems as well, but I can only say for sure about Linux, David -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#96144: mutt/580: mutt stores PGP passphrase insecurely
Synopsis: mutt stores PGP passphrase insecurely Comment added by paul on Fri, 22 Sep 2006 00:07:57 +0200 This one's going nowhere fast. Nobody's come up with an effective (and practical) way of securing mutt, and tamo's demo only really proves that insecure memory is written to swap (which we already knew). If a note is added to the documentation to make this clear, does anyone involved object to closing this one? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#96144: mutt/580: mutt stores PGP passphrase insecurely
* Sun Oct 9 2005 Derek Martin [EMAIL PROTECTED] On Fri, Oct 07, 2005 at 02:42:51PM +0200, Thomas Roessler wrote: On 2005-10-07 04:35:02 +0200, Derek Martin wrote: Admittedly this is not a severe issue, but it is a legitimate security concern. I think this really ought to be re-opened. I disagree, unless someone can actually demonstrate (a) a realistic attack model against which mutt is vulnerable, and (b) a defense against this attack model that could be implemented. Still, I'd like to hear what others with more experience than I have to say about this issue. I don't think both (a) and (b) are satisfied. But I want to share the result of my experiment. I did: 0: run mutt and decrypt a PGP message. 1: run another mutt and decrypt the same PGP message. 2: run a script which uses a lot of memory. 3: (as root) cat /dev/hda3 (my swap) | strings | grep -5 some-of-my-passwd | tee /tmp/pgppasswd.txt 4: reboot without swap 5: (as root) cat /dev/hda3 | strings | grep -5 some-of-my-passwd | tee /tmp/pgppasswd.2.txt pgppasswd.txt: = PGP message successfully decrypted. ]9;1130148457 mutt mutt /home/tamo/.mutt/pgp password /home/tamo/.terminfo [%i%p1%d;%p2%dr [%i%p1%dG [%i%p1%d;%p2%dH [?25l -- ja_JP.EUC-JP ja_JP.EUC-JP mutt ja_JP.EUC-JP /home/tamo/.mutt/pgp password /usr/lib/gconv/EUC-JP.so /usr/lib/gconv/EUC-JP.so /usr/lib/gconv/EUC-JP.so /usr/lib/gconv EUC-JP.so = pgppasswd.2.txt: = 1234567890 1234567890 1234567890 1234567890 1234567890 password /home/tamo/.terminfo [%i%p1%d;%p2%dr [%i%p1%dG [%i%p1%d;%p2%dH [?25l -- charset iso-2022-jp x-action pgp-encrypted plain password /usr/lib/gconv/EUC-JP.so /usr/lib/gconv/EUC-JP.so /usr/lib/gconv/EUC-JP.so /usr/lib/gconv EUC-JP.so = So, if the machine you are running mutt is stolen, the disc may contain your plain passphrase. Is this realistic? I don't know. But it was so easy that I could demonstrate. If the thief knows a part of your passphrase, he can grep it like I did. -- tamo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#96144: mutt/580: mutt stores PGP passphrase insecurely
The following reply was made to PR mutt/580; it has been noted by GNATS. From: TAKAHASHI Tamotsu [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: mutt/580: mutt stores PGP passphrase insecurely Date: Mon, 24 Oct 2005 23:13:49 +0900 * Sun Oct 9 2005 Derek Martin [EMAIL PROTECTED] On Fri, Oct 07, 2005 at 02:42:51PM +0200, Thomas Roessler wrote: On 2005-10-07 04:35:02 +0200, Derek Martin wrote: Admittedly this is not a severe issue, but it is a legitimate security concern. I think this really ought to be re-opened. I disagree, unless someone can actually demonstrate (a) a realistic attack model against which mutt is vulnerable, and (b) a defense against this attack model that could be implemented. Still, I'd like to hear what others with more experience than I have to say about this issue. I don't think both (a) and (b) are satisfied. But I want to share the result of my experiment. I did: 0: run mutt and decrypt a PGP message. 1: run another mutt and decrypt the same PGP message. 2: run a script which uses a lot of memory. 3: (as root) cat /dev/hda3 (my swap) | strings | grep -5 some-of-my-passwd | tee /tmp/pgppasswd.txt 4: reboot without swap 5: (as root) cat /dev/hda3 | strings | grep -5 some-of-my-passwd | tee /tmp/pgppasswd.2.txt pgppasswd.txt: = PGP message successfully decrypted. ]9;1130148457 mutt mutt /home/tamo/.mutt/pgp password /home/tamo/.terminfo [%i%p1%d;%p2%dr [%i%p1%dG [%i%p1%d;%p2%dH [?25l -- ja_JP.EUC-JP ja_JP.EUC-JP mutt ja_JP.EUC-JP /home/tamo/.mutt/pgp password /usr/lib/gconv/EUC-JP.so /usr/lib/gconv/EUC-JP.so /usr/lib/gconv/EUC-JP.so /usr/lib/gconv EUC-JP.so = pgppasswd.2.txt: = 1234567890 1234567890 1234567890 1234567890 1234567890 password /home/tamo/.terminfo [%i%p1%d;%p2%dr [%i%p1%dG [%i%p1%d;%p2%dH [?25l -- charset iso-2022-jp x-action pgp-encrypted plain password /usr/lib/gconv/EUC-JP.so /usr/lib/gconv/EUC-JP.so /usr/lib/gconv/EUC-JP.so /usr/lib/gconv EUC-JP.so = So, if the machine you are running mutt is stolen, the disc may contain your plain passphrase. Is this realistic? I don't know. But it was so easy that I could demonstrate. If the thief knows a part of your passphrase, he can grep it like I did. -- tamo -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#96144: mutt/580: mutt stores PGP passphrase insecurely
On 2005-10-09 11:03:25 -0400, Derek Martin wrote: Well, this is very far from my area of expertise; but we all know someone for whom this kind of issue is near and dear... Does Werner have anything to say about this? I could do some research, but I think it would be better to get input from someone with more experience. FWIW, how does GPG handle this problem? You can run gpg setuid root so the memory that is used for sensitive information is locked. That helps against having the sensitive information in your swap partition. I admit, at first glance methods of solving this seem... yucky. For example, locking memory (so that it does not swap to disk) requires root privileges on most platforms... making mutt SUID root seems like a very bad idea. But perhaps mutt could have its own passphrase agent. In that case, why not re-use gpg's? In the end, you have a point; methods of attacking the passphrase in memory require the ability to either assume the user's privileges, or assume root privileges. If an attacker can do that, most likely all bets are off anyway. For example, if a rogue sysadmin were so inclined, he could install a trojaned mutt which collects private key passphrases. Still, I'd like to hear what others with more experience than I have to say about this issue. I think it would be somewhat reassuring for users who don't control the system(s) on which they use mutt, and don't have access to gpgagent, if some attempt at solving this was made. If you don't control a system and don't trust the people who control it, then, please, don't process sensitive information on it. This also applies, by the way, to running gpg-agent or gpg on such systems. Regards, -- Thomas Roessler · Personal soap box at http://log.does-not-exist.org/. pgpow6Swdr9Dm.pgp Description: PGP signature
Bug#96144: mutt/580: mutt stores PGP passphrase insecurely
The following reply was made to PR mutt/580; it has been noted by GNATS. From: Thomas Roessler [EMAIL PROTECTED] To: [EMAIL PROTECTED], Mutt Developers [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: Subject: Re: mutt/580: mutt stores PGP passphrase insecurely Date: Mon, 10 Oct 2005 12:27:54 +0200 --PuGuTyElPB9bOcsM Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On 2005-10-09 11:03:25 -0400, Derek Martin wrote: Well, this is very far from my area of expertise; but we all know someone for whom this kind of issue is near and dear... Does Werner have anything to say about this? I could do some research, but I think it would be better to get input from someone with more experience. FWIW, how does GPG handle this problem? You can run gpg setuid root so the memory that is used for sensitive information is locked. That helps against having the sensitive information in your swap partition. I admit, at first glance methods of solving this seem... yucky. For example, locking memory (so that it does not swap to disk) requires root privileges on most platforms... making mutt SUID root seems like a very bad idea. But perhaps mutt could have its own passphrase agent. In that case, why not re-use gpg's? In the end, you have a point; methods of attacking the passphrase in memory require the ability to either assume the user's privileges, or assume root privileges. If an attacker can do that, most likely all bets are off anyway. For example, if a rogue sysadmin were so inclined, he could install a trojaned mutt which collects private key passphrases. Still, I'd like to hear what others with more experience than I have to say about this issue. I think it would be somewhat reassuring for users who don't control the system(s) on which they use mutt, and don't have access to gpgagent, if some attempt at solving this was made. If you don't control a system and don't trust the people who control it, then, please, don't process sensitive information on it. This also applies, by the way, to running gpg-agent or gpg on such systems. Regards, --=20 Thomas Roessler =B7 Personal soap box at http://log.does-not-exist.org/. --PuGuTyElPB9bOcsM Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.3-cvs (GNU/Linux) iIAEARECAEAFAkNKQio5FIAAFQAbcGthLWFkZHJlc3NAZ251cGcub3Jncm9l c3NsZXJAZG9lcy1ub3QtZXhpc3Qub3JnAAoJEMrVFmL0y4amtHMAn3VpuIUCwPsV HQqMTsEa9Q0oqI9jAJ93HccUs1d9DrtO8rQxY/MzCXqwfQ== =88YE -END PGP SIGNATURE- --PuGuTyElPB9bOcsM-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#96144: mutt/580: mutt stores PGP passphrase insecurely
On Fri, Oct 07, 2005 at 02:42:51PM +0200, Thomas Roessler wrote: On 2005-10-07 04:35:02 +0200, Derek Martin wrote: Er, well, come on... just because Mutt *can* use an auxiliary program to handle encryption passphrases securely doesn't mean mutt itself should completely ignore the issue. As shipped, mutt is vulnerable. Admittedly this is not a severe issue, but it is a legitimate security concern. I think this really ought to be re-opened. I disagree, unless someone can actually demonstrate (a) a realistic attack model against which mutt is vulnerable, and (b) a defense against this attack model that could be implemented. Hint: Encrypting the pass phrase with a symmetric key that is kept in memory is *not* a solution to an attack that is based on reading the pass phrase from memory, since the attack is now shifted to the equivalently complex reading of the symmetric key from memory. Well, this is very far from my area of expertise; but we all know someone for whom this kind of issue is near and dear... Does Werner have anything to say about this? I could do some research, but I think it would be better to get input from someone with more experience. FWIW, how does GPG handle this problem? I admit, at first glance methods of solving this seem... yucky. For example, locking memory (so that it does not swap to disk) requires root privileges on most platforms... making mutt SUID root seems like a very bad idea. But perhaps mutt could have its own passphrase agent. In the end, you have a point; methods of attacking the passphrase in memory require the ability to either assume the user's privileges, or assume root privileges. If an attacker can do that, most likely all bets are off anyway. For example, if a rogue sysadmin were so inclined, he could install a trojaned mutt which collects private key passphrases. Still, I'd like to hear what others with more experience than I have to say about this issue. I think it would be somewhat reassuring for users who don't control the system(s) on which they use mutt, and don't have access to gpgagent, if some attempt at solving this was made. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail. Sorry for the inconvenience. Thank the spammers. pgpmfk3W3feHG.pgp Description: PGP signature
Bug#96144: mutt/580: mutt stores PGP passphrase insecurely
Synopsis: mutt stores PGP passphrase insecurely State-Changed-From-To: closed-chatting State-Changed-By: tamo State-Changed-When: Fri, 07 Oct 2005 10:54:07 +0200 State-Changed-Why: Derek complains. Comment added by tamo on Fri, 07 Oct 2005 10:54:07 +0200 reopen as a doc-bug (chatting) despam Mutt can use gpg-agent, OpenBSD has swap-encryption, mutt himself can't do anything without zero-uid. But we can document some warnings anyway. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#96144: mutt/580: mutt stores PGP passphrase insecurely
On 2005-10-07 04:35:02 +0200, Derek Martin wrote: Er, well, come on... just because Mutt *can* use an auxiliary program to handle encryption passphrases securely doesn't mean mutt itself should completely ignore the issue. As shipped, mutt is vulnerable. Admittedly this is not a severe issue, but it is a legitimate security concern. I think this really ought to be re-opened. I disagree, unless someone can actually demonstrate (a) a realistic attack model against which mutt is vulnerable, and (b) a defense against this attack model that could be implemented. Hint: Encrypting the pass phrase with a symmetric key that is kept in memory is *not* a solution to an attack that is based on reading the pass phrase from memory, since the attack is now shifted to the equivalently complex reading of the symmetric key from memory. -- Thomas Roessler · Personal soap box at http://log.does-not-exist.org/.
Bug#96144: mutt/580: mutt stores PGP passphrase insecurely
The following reply was made to PR mutt/580; it has been noted by GNATS. From: Thomas Roessler [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Mutt Developers [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: mutt/580: mutt stores PGP passphrase insecurely Date: Fri, 7 Oct 2005 14:42:51 +0200 On 2005-10-07 04:35:02 +0200, Derek Martin wrote: Er, well, come on... just because Mutt *can* use an auxiliary program to handle encryption passphrases securely doesn't mean mutt itself should completely ignore the issue. As shipped, mutt is vulnerable. Admittedly this is not a severe issue, but it is a legitimate security concern. I think this really ought to be re-opened. I disagree, unless someone can actually demonstrate (a) a realistic attack model against which mutt is vulnerable, and (b) a defense against this attack model that could be implemented. Hint: Encrypting the pass phrase with a symmetric key that is kept in memory is *not* a solution to an attack that is based on reading the pass phrase from memory, since the attack is now shifted to the equivalently complex reading of the symmetric key from memory. --=20 Thomas Roessler =B7 Personal soap box at http://log.does-not-exist.org/. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#96144: mutt/580: mutt stores PGP passphrase insecurely
On Wed, Oct 05, 2005 at 05:55:17AM +0200, Brendan Cully wrote: Synopsis: mutt stores PGP passphrase insecurely State-Changed-From-To: open-closed State-Changed-Why: Mutt can use gpg-agent, which pushes this problem outside of mutt's domain. Er, well, come on... just because Mutt *can* use an auxiliary program to handle encryption passphrases securely doesn't mean mutt itself should completely ignore the issue. As shipped, mutt is vulnerable. Admittedly this is not a severe issue, but it is a legitimate security concern. I think this really ought to be re-opened. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail. Sorry for the inconvenience. Thank the spammers. pgp4Kv3wS0Vnp.pgp Description: PGP signature
Bug#96144: mutt/580: mutt stores PGP passphrase insecurely
The following reply was made to PR mutt/580; it has been noted by GNATS. From: Derek Martin [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: Mutt Developers [EMAIL PROTECTED], Marco d'Itri [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Re: mutt/580: mutt stores PGP passphrase insecurely Date: Thu, 6 Oct 2005 22:27:50 -0400 --2oS5YaxWCcQjTEyO Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline On Wed, Oct 05, 2005 at 05:55:17AM +0200, Brendan Cully wrote: Synopsis: mutt stores PGP passphrase insecurely State-Changed-From-To: open-closed State-Changed-Why: Mutt can use gpg-agent, which pushes this problem outside of mutt's domain. Er, well, come on... just because Mutt *can* use an auxiliary program to handle encryption passphrases securely doesn't mean mutt itself should completely ignore the issue. As shipped, mutt is vulnerable. Admittedly this is not a severe issue, but it is a legitimate security concern. I think this really ought to be re-opened. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail. Sorry for the inconvenience. Thank the spammers. --2oS5YaxWCcQjTEyO Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQFDRd0mHEnASN++rQIRApDeAJ0YWRLNxZO+2t3pnqhy6QIynUemiACfWKqd TMrjy3W680O1x1yH+EGTm5s= =cbWN -END PGP SIGNATURE- --2oS5YaxWCcQjTEyO-- -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#96144: mutt/580: mutt stores PGP passphrase insecurely
Synopsis: mutt stores PGP passphrase insecurely State-Changed-From-To: open-closed State-Changed-By: brendan State-Changed-When: Wed, 05 Oct 2005 05:55:17 +0200 State-Changed-Why: Mutt can use gpg-agent, which pushes this problem outside of mutt's domain. Comment added by brendan on Wed, 05 Oct 2005 05:55:17 +0200 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
