[Rt-announce] Security vulnerability in RT 3.0 and up

[Alex Vandiver]

All released versions of RT from 3.0.0 through 3.8.9rc1 use an
insecure hashing algorithm to store user passwords. If an attacker is
able to gain read access to RT's database, it would be possible for
the attacker to brute-force the hash and discover users' passwords.
CVE-2011-0009 has been assigned to this vulnerability.

This vulnerability may affect you even if your RT instance
authenticates against an external source. If your RT instance has ever
stored user passwords in the database, their presence is a risk.

For releases prior to RT 3.8.9, we've built an extension called
RT::Extension::SaltedPasswords to mitigate this.  This extension
alters RT's functionality to use salted SHA-256 to store passwords
instead of RT's current default.  It also includes a tool to detect
and upgrade all existing MD5 passwords to the new SHA-256 storage
format.  We've tested this extension with recent releases of RT 3.6
and RT 3.8.

You can download this extension from:
http://download.bestpractical.com/pub/rt/release/RT-Extension-SaltedPasswords-1.1.tar.gz
http://download.bestpractical.com/pub/rt/release/RT-Extension-SaltedPasswords-1.1.tar.gz.asc

sha1sums:
686882212e757d18c10455a0051c1f3fed0b0d9d  RT-Extension-SaltedPasswords-1.1.tar.gz
b95e3c3089fb27cf730be01bcf29dc57ecd3a32b  RT-Extension-SaltedPasswords-1.1.tar.gz.asc

RT 3.8.9rc2 and 4.0.0rc4, to be released today, also close this
vulnerability by moving to a password storage based on salted SHA
hashes.  The former uses SHA-256 with a four-byte salt, identical to
what the above extension provides; the latter extends the size of the
password field and uses SHA-512 with a 16-byte salt.  We are
additionally considering moving RT 4.0 to the same multiple-round
SHA-512 algorithm that modern Linux crypt() uses.

We wish to thank Chris Ball <cjb at laptop.org> for bringing this to our
attention in a diligent and professional manner.

If you need help resolving this issue locally, please contact us at
sales at bestpractical.com for more information.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <http://lists.bestpractical.com/pipermail/rt-announce/attachments/20110119/dd2103da/attachment.pgp>