[prev in list] [next in list] [prev in thread] [next in thread] 

List:       oss-security
Subject:    Re: [oss-security] Re: kwallet crypto misuse
From:       Daniel Kahn Gillmor <dkg () fifthhorseman ! net>
Date:       2014-01-02 16:32:40
Message-ID: 52C594A8.9090008 () fifthhorseman ! net
[Download RAW message or body]


On 01/02/2014 08:03 AM, cve-assign@mitre.org wrote:
>> http://gaganpreet.in/blog/2013/07/24/kwallet-security-analysis/
> 
>> KWallet uses QDataStream, which encodes QString objects (used in
>> KWallet maps) as UTF-16. So, the string "abcd" will be stored as
>> "\0a\0b\0c\0d", which gives four bytes of information per block.
> 
> Does anyone know whether the KWallet user interface could make it
> possible to enter passwords containing 16-bit characters (i.e.,
> characters that cannot be represented using 8 bits)? If that would not
> be possible, then this issue could potentially qualify for an
> additional CVE assignment.

according to its man page, kwalletcli itself assumes strings are input
at UTF-8.  This is not exactly "16-bit characters", but it's certainly
possible to input characters that are beyond unicode codepoint U+7f (or
U+ff if you prefer that limit).

kwalletaskpass also uses whatever keyboard entry mechanism your X11
session is configured for, and can easily accept whatever characters you
can generate with your keyboard -- much of the world uses keyboards
where at least some key combinations (e.g. €, which is U+20AC) generate
characters outside of the standard 7-bit ASCII range.  I had no trouble
entering a passphrase with ♥ (U+2665) just now.

Of course, none of this suggests that the cleartext of these strings is
evenly distributed bitwise (or byte-wise).  It clearly isn't.  That
said, very little cleartext *is* high-entropy in this way.  Do you think
MITRE or other folks should be recommending pre-whitening the strings
before encrypting them (e.g. by compressing them before encrypting)?
compressing before encryption smells like a possible gateway to
something like a CRIME attack in some circumstances, so i think this
proposal in general might be riskier than we'd like.

Regards,

	--dkg


["signature.asc" (application/pgp-signature)]

[prev in list] [next in list] [prev in thread] [next in thread]