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

RESOLVED DUPLICATE of bug 1082346

Status

()

RESOLVED DUPLICATE of bug 1082346
10 years ago
2 years ago

People

(Reporter: m.cicciotti, Unassigned)

Tracking

({sec-low})

1.9.0 Branch
sec-low
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [sg:low][psm-cert-manager][psm-logic][psm-backlog])

(Reporter)

Description

10 years ago
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

10 years ago
Version: unspecified → trunk
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

10 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)

Updated

10 years ago
Assignee: nobody → kaie
Component: Libraries → Security: UI
Product: NSS → Core
QA Contact: libraries → ui
Version: trunk → 1.9.0 Branch
Group: core-security
Status: UNCONFIRMED → NEW
Component: Security: UI → Security: PSM
Ever confirmed: true
QA Contact: ui → psm
Whiteboard: [sg:low]
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

9 years ago
Assignee: kaie → nobody
Whiteboard: [sg:low] → [sg:low][psm-cert-manager][psm-logic]

Updated

4 years ago
See Also: → bug 1082346
Whiteboard: [sg:low][psm-cert-manager][psm-logic] → [sg:low][psm-cert-manager][psm-logic][psm-backlog]

Comment 4

2 years ago
AFAICT this was fixed in Bug 1082346.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1082346
You need to log in before you can comment on or make changes to this bug.