Visual representation of keys in WinPT 1.2.0 is susceptible to a user ID spoofing attack using keys with large amount
of data in the user IDs. In several instances the key user IDs are displayed in a fixed size window and any excessive
user ID data are simply visually truncated. This allows an attacker to trick a target into using a key with additional
user IDs that are hidden during certain operations, including key importing, key signing, key editing, and signature
listing. This can in turn lead to unintentional encryption of sensitive information with the attacker's key instead
of the legitimate key.


Attack Scenario:

The attacker creates a key with one or more user IDs that the target is willing to import and sign, e.g. "Attacker
<attacker@foo.org>". If the objective is to obtain data normally encrypted for victim@bar.com then the attacker
adds a user ID that looks like:

    Attacker <attacker@foo.org>"SSSSMMMMSSSS<victim@bar.com>

where SSSS represents a large number of spaces (0x20) and MMMM is a bogus message described later. See file exhibit
1: attacker.asc.

During import the target user is not aware of the unusual key ID (see file exhibit 2: import.png). The target then proceeds
to sign the key, again oblivious of the spoofing (see file exhibit 3: keysigning.png). Note that the message "Are
you really sure that you want to sign this key with YOUR key?" in fact comes from the doctored user ID, not from
WinPT itself.

Listing the key signatures or inspecting the key editing window does not reveal the presence of the additional data
either (see file exhibits 4, 5, and 6: signaturetree.png, signaturelist.png, and keyedit.png).

Encrypting sensitive plaintext for victim@bar.com with GnuPG will use the attacker's key as long as it has been loaded
into the keyring before the legitimate key:

    C:\>echo This is a secret | gpg -r victim@bar.com -e | gpg
    gpg: encrypted with 1024-bit ELG-E key, ID 7F378BF7, created 2007-03-09
          "Attacker <attacker@foo.com>"
    gpg: decryption failed: secret key not available


Workaround:

Do not rely on WinPT to inspect and/or import keys; use GnuPG instead.

Date: 2008-07-20 19:47
Sender: Timo Schulz

I'm not sure why I did not respond to this one. 

But the scenario has several problems. First, it assumes that
the message is properly encoded according to the victims environment.
This is manageable, I agree.

But WinPT/gpgme uses the recipients key ID for encryption, not
the userid/email. Using the non-unique pattern for key selection
is a security risk anyway.

So if you major concern is that sensitive text could be encrypted
with the wrong key, WinPT was never vulnerable because the key
IDs are used.

And I don't want to be pedantic, but isn't it already public
when you post a security report to a tracker of a public website?

Date: 2007-06-05 15:54
Sender: NN Poster

Since I have not heard back I am planning to disclose the
vulnerability to the public in the next few days. Please let
me know if you would like to postpone the disclosure.

Date: 2007-05-18 16:32
Sender: NN Poster

Considering the "freeze" announcement from the beginning
of April, do you still plan to resolve this issue in a near
future?

I would like to publicly disclose the vulnerability but I have
no problem waiting for an updated WinPT for a month or two. On
the other hand, if your other commitments do not allow you to
work on WinPT then the users should be warned about this issue
even without WinPT getting fixed.

Date: 2007-03-10 11:22
Sender: Timo Schulz

In any case I need to change the display form for long user IDs
but display the entire user ID when it is very long is no solution
because it makes proper dialog handling impossible.

Thanks for your opinion, I might move this topic to a gnupg mailing
list to discuss this more in detail.
 

Date: 2007-03-09 22:12
Sender: NN Poster

Re communication:
No problem, you can reach me as nnposter324 at users.sourceforge.net
(remove 324).

Re two-email pattern:
Actually checking for the two-email pattern might not cover all
the cases. As an example, I could just pad the second UID with
spaces and add the victim as a properly formatted 3rd UID. This
way I have avoided the pattern while the victim UID is still
not visible during the import or key signing. It would of course
show up during key edit or signature listing.

Alternatively I could make the 2nd UID as
"AttackerSSSSSSSSS<victim@bar.com>", which would
also avoid the pattern and it would appear to the target as a
UID without any e-mail. The victim e-mail address would not get
disclosed during the import, key signing, and even signature
listing. It would still show up in the key edit window.

Probably one of the best approaches is to either (1) display
the entire UID text, regardless of size, and scale all the windows
accordingly or (2) show just the leading part, just like now,
but add a strong indicator of truncation, such as:

    Attacker <attacker@foo.org>...(352 hidden chars)

Date: 2007-03-09 20:57
Sender: Timo Schulz

Your attack is based on an user ID which contains more than
one email address and thus it would be easy to check for such
suspicious pattern, right?

Propably this could lead to problems with 'free form' user IDs
but IMHO they are seldom and they would only cause trouble if
they contain 2 email addresses.

Date: 2007-03-09 20:44
Sender: Timo Schulz

I see some scenarios are possible but first,

please do not use the tracker directly to post security
issues which could be exploited by some bad guys. This way I've
no chance to provide a fix and release a new version ASAP, without
the fear that some 'script kiddies' use the attack to compromise
systems with a vulnerable program version (!)

I don't say such things should be kept in secret, but as usual
the vendors (in this case it's me via PM) should be contacted
first.

I would prefer to continue this discussion via mail, ok?