404239 - nsISecretDecoderRing's methods encryptString/decryptString fail to handle characters above Latin-1 charset

Status: RESOLVED WONTFIX

(Core :: Security: PSM, defect)

Description

[Sebastian Tschan]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8) Gecko/20071022 Ubuntu/7.10 (gutsy) Firefox/2.0.0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.9) Gecko/20071025 Firefox/2.0.0.9

Using nsISecretDecoderRing's method encryptString on a string containing characters above the Latin-1 (ISO-8859-1) charset (e.g. chinese characters like 安全项目 or arabian characters like كلمة المرور) will return a string that you cannot decrypt to get the original string anymore.
Using nsISecretDecoderRing's method decryptString on that string will only return strange characters.
Both methods work well with Latin-1 characters (e.g. german characters like öäü are ecrypted/decrypted properly).

Reproducible: Always

Steps to Reproduce:
1. Use nsISecretDecoderRing's method encryptString on a string containing chinese characters (e.g. 安全项目)
2. Use nsISecretDecoderRing's method decryptString on the encrypted string.
3. Output the result.
Actual Results:  
The output doesn't contain the original string containing the chinese characters.

Expected Results:  
The output should display the original string containing the chinese characters.

Using encodeURI before encryption and decodeURI after decryption bypasses this problem.

Comment 1

[Kai Engert [:KaiE:]]

Sebastian, in the failing scenario, what encoding did you use for the input string?

The implementation of encryptString uses strlen on the input string (which should work with UTF-8 strings, but can fail on UCS2 strings), and then it will use PL_Base64Encode (which I assume works for any input bytes).

Comment 2

[Sebastian Tschan]

The strings I used were UTF-8 encoded.
I became aware of this issue by a bug report regarding the Autofill Forms extension, which uses nsISecretDecoderRing's methods encryptString/decryptString to store its ruleset encrypted:
http://forums.mozillazine.org/viewtopic.php?p=3142024#3142024

I tested this independently from the Autofill Forms extension by using hard-coded UTF-8 strings containing characters above the Latin-1 charset (chinese, arabian, etc.) inside a UTF-8 encoded JavaScript file.

Comment 3

[Honza Bambas (:mayhemer)]

Sebastian, as I see the interface it is clear that it doesn't support UTF-8 strings. See http://developer.mozilla.org/en/docs/XPCOM_string_guide#IDL_String_types. Solution for you is probably to have a native wrapper (C++ implementation with your own interface) that works with AUTF8String as in/out parameters, something like:

myIDecoderRingWrapper : nsISupports
{
  AUTF8String encode(in AUTF8String text);
  AUTF8String decode(in AUTF8String encrypted);
}

The input can be extracted using PromiseFlatCString(text).get(). The result then have to be passed through Assign method to the ACString _result C++ object. XPConnect will correctly convert values for you. You must use UTF-8 because mozilla SDR is working with null-terminated strings only. UCS16 are not null-terminated, UTF-8 are (are compatible with 8 bit ASCII). Problem is that with SDR from JS you can use ONLY 7 bit ASCII. The nsISecretDecoderRing interface is not very well designed.

I am not sure how to convert string directly in JS but there might be some way, maybe using "@mozilla.org/intl/scriptableunicodeconverter" (nsIScriptableUnicodeConverter). You can then omit the C++ code.

Other way is to change or enhance the SDR interface to be capable to work with UTF-8 directly. Kaie, Robert, your opinions?

Comment 4

[Honza Bambas (:mayhemer)]

No feedback for a long time, no work done, but this bug is not IMHO invalid -> WONTFIX.