A flaw in John the Ripper and crypt_blowfish was reported [1],[2],[3] where passwords with 8-bit characters were mishandled. A password containing a single character with the 8th bit set have 1 to 3 characters immediately preceding the 8-bit character ignored (approximately 3 in 16 passwords). With more than one 8-bit character in the password, there may be more ignored characters. This can result in passwords being even easier to crack than expected. This is due to a char signedness bug in crypt_blowfish. Other programs, such as PHP Suhosin, PHP 5.3.x, and PostgreSQL's pgcrypt module, contain the vulnerable crypt_blowfish code. A fix for this flaw [4], as well as 8-bit tests [5] and a self-test at runtime [6] have been committed upstream. [1] http://www.openwall.com/lists/oss-security/2011/06/20/2 [2] http://www.openwall.com/lists/john-dev/2011/06/20/3 [3] http://www.openwall.com/lists/john-dev/2011/06/20/5 [4] http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/glibc/crypt_blowfish/crypt_blowfish.c.diff?r1=1.9;r2=1.10 [5] http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/glibc/crypt_blowfish/wrapper.c.diff?r1=1.9;r2=1.10 [6] http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/glibc/crypt_blowfish/crypt_blowfish.c.diff?r1=1.10;r2=1.11
Created php-suhosin tracking bugs for this issue Affects: fedora-all [bug 715035] Affects: epel-all [bug 715036]
Created php tracking bugs for this issue Affects: fedora-all [bug 715033]
Created postgresql tracking bugs for this issue Affects: fedora-all [bug 715034]
I've pushed a fix for this into postgresql's git repo. It's a bit more than just the upstream patch, as there's a routing function that has to be taught about the new $2x$ prefix.
(In reply to comment #4) > I've pushed a fix for this into postgresql's git repo. It's a bit more than > just the upstream patch, as there's a routing function that has to be taught > about the new $2x$ prefix. http://git.postgresql.org/gitweb?p=postgresql.git;a=commitdiff;h=ca59dfa6f727fe3bf3a01904ec30e87f7fa5a67e
Upstream PHP commit in (unreleased) 5.4 and trunk SVN: http://svn.php.net/viewvc?view=revision&revision=312505 There are concerns regarding how to fix in released 5.3, given the backwards incompatibility of the fix: http://marc.info/?l=php-internals&m=130912430403265&w=2
Further analysis from Solar Designer: http://seclists.org/oss-sec/2011/q2/678 To quote from what he wrote, as respecting the impact of the flaw: "Initially, I thought that only lengths n*4-1 and very large lengths were at risk of easy collisions. And, for small lengths, I estimated that roughly 3 out of 16 passwords containing one 8-bit character were at risk. After more thorough analysis, it turns out that other odd lengths are also at risk, and that "very large" starts at length 20. Thus, I have to revise my "3 of 16" estimate. The new estimate for risky passwords with one 8-bit character is 30% for lengths up to 20 inclusive. Like before, this assumes uniform distribution of lengths and positions for the 8-bit character, which is obviously not the case in practice, yet it works as an estimate. Lengths that are _not_ at risk: 1, 2, 4, 6, 8, 10, 12, 14, 16, 18. The rest are at risk (meaning that 8-bit chars in _some_ positions result in 1 to 3 preceding chars being ignored)."
Patch to update to crypt_blowfish 1.2 in PHP: http://news.php.net/php.internals/54000
(In reply to comment #8) > Patch to update to crypt_blowfish 1.2 in PHP: > > http://news.php.net/php.internals/54000 http://svn.php.net/viewvc?view=revision&revision=313406 Upstream archive (news.php) does not seem to offer direct links to other replies in the thread. Adding equivalent marc.info link for convenience: http://marc.info/?l=php-internals&m=131092736909655&w=2 Additional test suite changes were proposed by Solar, which are not committed in upstream SVN yet.
(In reply to comment #9) > http://svn.php.net/viewvc?view=revision&revision=313406 Alexander also pointed out this is required: http://svn.php.net/viewvc?view=revision&revision=313999
This is corrected in upstream 5.3.7: http://www.php.net/archive/2011.php#id2011-08-18-1
(In reply to comment #11) > This is corrected in upstream 5.3.7: > http://www.php.net/archive/2011.php#id2011-08-18-1 This may be a better permalink: http://www.php.net/releases/5_3_7.php A regression was introduced to crypt() in 5.3.7, which caused MD5 hashes not to be computed correctly, resulting in only salt part of the hash to be returned. This regression is corrected in 5.3.8: https://bugs.php.net/bug.php?id=55439 http://www.php.net/releases/5_3_8.php
(In reply to comment #12) > A regression was introduced to crypt() in 5.3.7, which caused MD5 hashes not to > be computed correctly, resulting in only salt part of the hash to be returned. > This regression is corrected in 5.3.8: > https://bugs.php.net/bug.php?id=55439 > http://www.php.net/releases/5_3_8.php That regression got CVE-2011-3189, see bug #732795.
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 5 Red Hat Enterprise Linux 4 Via RHSA-2011:1377 https://rhn.redhat.com/errata/RHSA-2011-1377.html
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2011:1378 https://rhn.redhat.com/errata/RHSA-2011-1378.html
External References: http://www.php.net/security/crypt_blowfish.php
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Red Hat Enterprise Linux 6 Via RHSA-2011:1423 https://rhn.redhat.com/errata/RHSA-2011-1423.html