494428 - Broken byte-swapping in nsPKCS12Blob::unicodeToItem mangles non-ASCII PKCS#12 passwords on all little-endian platforms

Status: RESOLVED DUPLICATE of bug 1082346

(Core :: Security: PSM, defect)

Description

[Michele Cicciotti]

User-Agent:       Opera/9.64 (Windows NT 6.0; U; it) Presto/2.1.1
Build Identifier: 

In source file security/manager/ssl/src/nsPKCS12Blob.cpp (nsPKCS12Blob::unicodeToItem):

 513     item->data[2*i  ] = (unsigned char )(uni[i] << 8);

The function erroneously shifts to the left, instead of the right. Therefore, (unsigned char )(uni[i] << 8) is always zero, and this mangles all passwords containing codepoints above U+00FF

Reproducible: Always

Steps to Reproduce:
1. Export a key pair in PKCS#12 format from another application (for example, the Windows certificate manager), using a password that contains characters above U+00FF (for example: "黒い")
2. Attempt to import the key pair in any Mozilla application, using the same password
Actual Results:  
Importing the key pair fails because of a password error

Expected Results:  
Importing the key pair succeeds

This is a security issue, since it effectively halves the password strength, although luckily it's the highest 8 bits that are lost. It affects Mozilla 1.8 as well (the code is identical). It's a sneaky issue because the same, broken algorithm is used both to encrypt and decrypt, so roundtripping works fine

Technically, this is easy to fix. In source file security/manager/ssl/src/nsPKCS12Blob.cpp (nsPKCS12Blob::unicodeToItem), replace this line:

 513     item->data[2*i  ] = (unsigned char )(uni[i] << 8);

with the following:

 513     item->data[2*i  ] = (unsigned char )(uni[i] >> 8);

For backwards compatibility with broken PKCS#12 containers generated by previous releases, the broken behavior could be kept as another "flavor" of password in the PKCS#12 importer (like there already are two flavors of empty passwords)

Comment 1

[Marcia Knous [:marcia]]

Michele: Would be helpful to know which version of Firefox you are running here - is it Firefox 3.0.0.10? Thanks.

Comment 2

[Michele Cicciotti]

Tried and verified on:

Mozilla/5.0 (Windows; U; Windows NT 6.0; it; rv:1.9.0.10) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729)
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2
Mozilla/5.0 (Windows; U; Windows NT 6.0; it; rv:1.8.1.21) Gecko/20090302 Thunderbird/2.0.0.21

Further proof: I tried exporting a key pair from Mozilla using the password "黒い" (U+9ED2 U+3044), and then I tried importing it in Windows. The correct password doesn't work in Windows, but the mangled form "ÒD" (U+00D2 U+0044) does, both in Windows and all Mozilla applications above (i.e. to Mozilla, "黒い" and "ÒD" are identical as far as PKCS#12 is concerned)

Comment 3

[Honza Bambas (:mayhemer)]

I tried to test the proposed fix but there is still a problem. Interchange of certs still doesn't work between windows and ff when there is a unicode password. I will investigate further.

Comment 4

[:Cykesiopka]

AFAICT this was fixed in Bug 1082346.