Closed
Bug 494428
Opened 16 years ago
Closed 8 years ago
Broken byte-swapping in nsPKCS12Blob::unicodeToItem mangles non-ASCII PKCS#12 passwords on all little-endian platforms
Categories
(Core :: Security: PSM, defect)
Tracking
()
RESOLVED
DUPLICATE
of bug 1082346
People
(Reporter: m.cicciotti, Unassigned)
References
Details
(Keywords: sec-low, Whiteboard: [sg:low][psm-cert-manager][psm-logic][psm-backlog])
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)
Reporter | ||
Updated•16 years ago
|
Version: unspecified → trunk
Comment 1•16 years ago
|
||
Michele: Would be helpful to know which version of Firefox you are running here - is it Firefox 3.0.0.10? Thanks.
Reporter | ||
Comment 2•16 years ago
|
||
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)
Assignee: nobody → kaie
Component: Libraries → Security: UI
Product: NSS → Core
QA Contact: libraries → ui
Version: trunk → 1.9.0 Branch
Updated•16 years ago
|
Group: core-security
Status: UNCONFIRMED → NEW
Component: Security: UI → Security: PSM
Ever confirmed: true
QA Contact: ui → psm
Whiteboard: [sg:low]
![]() |
||
Comment 3•16 years ago
|
||
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.
Updated•15 years ago
|
Assignee: kaie → nobody
Whiteboard: [sg:low] → [sg:low][psm-cert-manager][psm-logic]
![]() |
||
Updated•9 years ago
|
Whiteboard: [sg:low][psm-cert-manager][psm-logic] → [sg:low][psm-cert-manager][psm-logic][psm-backlog]
![]() |
||
Comment 4•8 years ago
|
||
AFAICT this was fixed in Bug 1082346.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•