Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 21 Jun 2011 16:34:41 +0200
From: Ludwig Nussel <ludwig.nussel@...e.de>
To: oss-security@...ts.openwall.com
Cc: Michael Matz <matz@...e.de>, Thorsten Kukuk <kukuk@...e.de>,
	Andreas Jaeger <aj@...e.de>
Subject: Re: CVE request: crypt_blowfish 8-bit character
 mishandling

Solar Designer wrote:
>Returning to the crypt_blowfish topic, I am considering keeping 
>support
>for the broken hashes under another prefix - say, "$2x$" (where the "x"
>would stand for "sign eXtension bug") instead of the usual "$2a$".  For
>typical passwords, they'd be the same (except for this one letter in the
>prefix).  Their potential use would be by a sysadmin wishing to avoid
>any service disruption for anyone (even if that means potentially
>staying with weaker passwords than what some users might have expected;
>maybe password changes would then be recommended or forced over time).
>That sysadmin would replace "$2a$" with "$2x$" in existing hashes on the
>system right before upgrade to corrected software (such as PHP or glibc
>with crypt_blowfish).  Alternatively, say, a custom web app could be
>making this replacement for crypt() calls only, on hashes created before
>upgrade date.

I wonder whether it would make sense to patch pam_unix (resp 
pam_unix2 in our case) to detect the problem and activate the 
workaround automatically. pam_unix has the clear text password so 
knows when it contains 8bit characters. It also has the shadow entry 
which tells when the password was set. If that date is before the 
update was installed the 2x method could be tried if 2a failed and a 
warning could be logged to syslog.

cu
Ludwig

-- 
  (o_   Ludwig Nussel
  //\
  V_/_  http://www.suse.de/
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imend├Ârffer, HRB 16746 (AG N├╝rnberg) 

Powered by blists - more mailing lists

Your e-mail address:

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Powered by Openwall GNU/*/Linux - Powered by OpenVZ