Message-ID: <200412230258.30181.thomas.greene@theregister.co.uk>
Date: Thu, 23 Dec 2004 02:58:30 -0500
From: "Thomas C. Greene" <thomas.greene@...register.co.uk>
To: bugtraq@...urityfocus.com
Subject: Inexcusable weakness in Kmail / GnuPG


This might well affect more than Kmail on Linux, but i don't do windows so i 
wouldn't know.  I'm dealing with GnuPG 0.9.5, Kmail 1.5.1, KDE 3.1.1, and 
kernel 2.4.20, all patched within the past week. 

I do hope that this problem has been discussed previously, because if i'm the 
first person to notice it, heaven help us.  But if it *has* been discussed 
previously, well, we've got some useless developers designing e-mail clients.

Here's the deal: i'm using GnuPG with Kmail, replying to an encrypted memo 
from an anonymous source, and i've naturally got my paranoia level up.  Being 
a journo, i can't take any chances, so i don't keep my passphrase in memory.  
It's a small inconvenience, but i don't mind.  Of course it's a bloody long 
passphrase, with plenty of special characters, numerals and spaces (or maybe 
not, lol), and i get it wrong way more than half the time (hi Feds); but i 
figure, hey, if someone wants to contact the press in confidence, they 
deserve every possible precaution.  

So i decrypt the incoming message (enter passphrase), and then i reply to it 
(enter passphrase again).  After numerous tries, i'm there, because, as i 
said, i'm very much apt to forget this discombobulated passphrase, which i'm 
sure i would forget permanently if there was any serious pressure on my weak 
mind to remember it (hi again Feds).

At this point, i'm favorably impressed with Kmail's paranoia level.  Really, 
that's the kind of thing i like to see.

So i compose my reply, and i'm just about to click the Send button, when i 
notice, quite by chance, that the reply is *not* encrypted by default, and i 
am not warned about this fact.  My reply, and my entire past exchange with 
the source, is about to go out in fscking clear text!  

I confirmed this behavior by sending encrypted memos between several of my own 
e-mail accounts.  You can indeed decrypt a memo and reply to it -- with 
everything going out in clear text -- without *any* warning.  

If you forward an encrypted memo as an attachment, the problem doesn't exist.  
You have to enter the passphrase to decrypt the original, before and after 
sending.  Which is as it should be.  If you forward it inline, there's no 
option to decrypt the memo whether you want to or not: only the cyphertext is 
reproduced, and there's no prompt to decrypt it.  Which sucks, but is, at 
least, not obviously insecure.  (Note that these inconsistencies in behavior 
imply a basically flawed design.)

But when you reply to an encrypted memo, there is a ludicrous snafu.  (Of 
course, you don't have to decrypt a memo to reply to it, and if you fail out 
of the pw prompt, only the cyphertext of the original, and the clear text of 
the reply, will be sent -- although without any warnings or options.  Which 
is not great, but not horrible.)

However, if you reply to a decrypted memo, and enter your passphrase when 
prompted, you'll receive no warnings about the fact that everything will go 
out in clear text automatically after that point.  

Well, i'm sorry, but that just won't do.  It's simply not good enough.  
Fortunately, i caught it, but what if i hadn't?

If the Kmail team can't design a client that knows when decrypted text is 
included in a reply, and encrypt it by default, or at least throw up a 
warning, well, naive users are going to get hosed.  I'm not even close to a 
naive user, and i almost got hosed -- and more to the point, my *source* 
almost got hosed.

I hope that fellow list members will try this with their crypto product of 
choice and e-mail client of choice, and report back.  Let's see how 
widespread the problem is.  There's no excuse for this behavior.  It can 
certainly be fixed, and, indeed, it should have been fixed ages ago -- 
unless, by some freak chance, i really am the first person to notice it, 
which i very strongly doubt.  I assume that this behavior has been observed 
many times in the past.  So why is it still happening on a recently-patched 
system?  

While it's always good for us to be paranoid, we shouldn't *have* to be 
paranoid when using so-called "security" products.  The *tool* should be 
paranoid for us, and we should be the ones telling it to slack off.

with palpable disgust,
tom

===============
Thomas C. Greene
Associate Editor
The Register
http://www.theregister.co.uk

Powered by blists - more mailing lists