Version: KMail 1.8.2 (using KDE KDE 3.4.2) Installed from: SuSE RPMs OS: Linux Assume I have a public key for a user with an email of foo.bar@example.com and I'm trying to send a signed email to email an email address bar@example.com kmail claims there is a public key available and offers to encrypt the message, too. When following up on that by clicking sign&encrypt it will open a window offering to select the keys used, claiming that it picked a key for bar@example.com, but actually picked the key for foo.bar@example.com I can't think of any way this can be a security issue, but it's really annoying for sure.
Actually, I see a security issue very well: Imagine you have an account me@example.com, and since you don't trust the admin of your mailserver, you want all mail to you to be encrypted (you have the secret key on your secure machine). Now, you have all reason to be suspicious, because the admin generates a key for not.me@example.com and somehow manages to distribute the public key to some contacts of you. Now someone wants to send you a confidential mail, encrypts it (unfortunately with the not.me@example.com key....) and sends it to you. The admin of the mailserver can decrypt the mail using his private key, read it and re-send it to you encrypted with your correct key. You'll never find out (unless the admin fails to properly fix up the mail headers...) that someone is intercepting your mails... Cheers, Reinhold
I can confirm the bug! I tried sending a mail to kainhofer@tuwien.ac.at (which does not even exist, while I have the public key for reinhold.kainhofer@tuwien.ac.at in my keyring). I still got asked by kmail to use the key with the ID of reinhold.kainhofer@tuwien.ac.at for encrypting to kainhofer@tuwien.ac.at! Nasty security bug. Encrypting with a key that should not be used is always a security issue... Cheers, Reinhold
Created attachment 18804 [details] Dialog showing the wrong email address for the encryption key! Some further investigation indicates that Kleo::QGpgMEKeyListJob which is called from Kleo::KeyResolver::lookup (which in turn is called from Kleo::KeyResolver::getEncryptionKeys) does a substring match, not a string match. So all addressees that contain the receiver's email adress will be returned. If only one matches (even if it is not the correct receiver), that one will automatically be suggested (with the email adress of the receiver instead of the address of the key being shown in the selection dialog!!!). E.g. if you try to send a mail to k@kd, it will still use the encryption key for dirk@kde.org, as that's the only address that matches. However, the dialog shows that the key is for k@kde.org (screenshot attached)! Cheers, Reinhold
Actually the dialog shows that the key 0x2BB2D54A will be used for recipient k@kd. The dialog does not claim that the key belongs to k@kd. Of course, I agree that the difference is subtle. Moreover, I agree that a substring search is not a good idea in this particular case. I propose the attached patch.
Created attachment 18808 [details] proposed fix
Note, that with this patch KMail will fail to find keys where the uid is just a raw email address (I have a few of those keys in my keyring), but I think that's an acceptable drawback since the user can still manually search for a matching key.
I've asked upstream about what they think about establishing the addition of <> around patterns in search strings as a protocol to request matching only email addresses, and find matches even in the cases where the angle brackets would not normally be part of the original string (e.g. in the case Ingo described, and probably also in the case where an X.509 certificate has the email address in the DN instead of in the corresponding field. Let's see what they say.
Werner Koch mentions this is the correct fix. Ingo: Dis you test that this fails when name and comment are empty for a key, or did you just guess? Bottomline: This is the correct fix. It is established protocol in gpg. If it fails for some bugs, that's a bug in gpg, and should be filed against it.
I wasn't able to reproduce this bug with KDE 4.3 RC3. Anyone still having this problem?
I'm not currently in a position to test, as I'm still on a distro using KDE 3.5.10 with Kmail 1.9.10. at least in that setup it's still an issue. Once I have time to upgrade to KDE4 I'll give that a try.
we'll close this then. if anyone using KDE 4.3 or higher can still reproduce this bug then feel free to reopen.