The MITRE CVE database describes these CVEs as :

Revert is_a() behavior to php <= 5.3.6 and add a new new option (allow_string) for the new behavior (accept string and raise autoload if needed)

Use-after-free vulnerability in the substr_replace function in PHP 5.3.6 and earlier allows context-dependent attackers to cause a denial of service (memory corruption) or possibly have unspecified other impact by using the same variable for multiple arguments.

Stack-based buffer overflow in the socket_connect function in ext/sockets/sockets.c in PHP 5.3.3 through 5.3.6 might allow context-dependent attackers to execute arbitrary code via a long pathname for a UNIX socket.

The rfc1867_post_handler function in main/rfc1867.c in PHP before 5.3.7 does not properly restrict filenames in multipart/form-data POST requests, which allows remote attackers to conduct absolute path traversal attacks, and possibly create or overwrite arbitrary files, via a crafted upload request, related to a 'file path injection vulnerability.'

crypt_blowfish before 1.1, as used in PHP before 5.3.7 on certain platforms, does not properly handle 8-bit characters, which makes it easier for context-dependent attackers to determine a cleartext password by leveraging knowledge of a password hash.

PHP before 5.3.7 does not properly check the return values of the malloc, calloc, and realloc library functions, which allows context-dependent attackers to cause a denial of service (NULL pointer dereference and application crash) or trigger a buffer overflow by leveraging the ability to provide an arbitrary value for a function argument, related to (1) ext/curl/interface.c, (2) ext/date/lib/parse_date.c, (3) ext/date/lib/parse_iso_intervals.c, (4) ext/date/lib/parse_tz.c, (5) ext/date/lib/timelib.c, (6) ext/pdo_odbc/pdo_odbc.c, (7) ext/reflection/php_reflection.c, (8) ext/soap/php_sdl.c, (9) ext/xmlrpc/libxmlrpc/base64.c, (10) TSRM/tsrm_win32.c, and (11) the strtotime function.

The crypt(3) manpage was updated to also list the 2y prefix.

This update contains yast2 core changes to change the hash generation of new passwords to the new secure style.

Please read the general notes below :

The implementation of the blowfish based password hashing method had a bug affecting passwords that contain 8bit characters (e.g. umlauts).
Affected passwords are potentially faster to crack via brute-force methods (CVE-2011-2483).

SUSE's crypt() implementation supports the blowfish password hashing function (id $2a) and system logins by default also use this method.
This update eliminates the bug in the $2a implementation. After installing the update existing $2a hashes therefore no longer match hashes generated with the new, correct implementation if the password contains 8bit characters. For system logins via PAM the pam_unix2 module activates a compat mode and keeps processing existing $2a hashes with the old algorithm. This ensures no user gets locked out.
New passwords hashes are created with the id '$2y' to unambiguously identify them as generated with the correct implementation.

Note: To actually migrate hashes to the new algorithm all users are advised to change passwords after the update.

Services that do not use PAM but do use crypt() to store passwords using the blowfish hash do not have such a compat mode. That means users with 8bit passwords that use such services will not be able to log in anymore after the update. As workaround administrators may edit the service's password database and change stored hashes from $2a to $2x. This will result in crypt() using the old algorithm. Users should be required to change their passwords to make sure they are migrated to the correct algorithm.

FAQ :

Q: I only use ASCII characters in passwords, am I a affected in any way? A: No.

Q: What's the meaning of the ids before and after the update? A:
Before the update: $2a -> buggy algorithm

After the update: $2x -> buggy algorithm $2a -> correct algorithm $2y
-> correct algorithm

System logins using PAM have a compat mode enabled by default: $2x -> buggy algorithm $2a -> buggy algorithm $2y

-> correct algorithm

Q: How do I require users to change their password on next login? A:
Run the following command as root for each user: chage -d 0 <username>

Q: I run an application that has $2a hashes in it's password database.
Some users complain that they can not log in anymore. A: Edit the password database and change the '$2a' prefix of the affected users' hashes to '$2x'. They will be able to log in again but should change their password ASAP.

Q: How do I turn off the compat mode for system logins? A: Set BLOWFISH_2a2x=no in /etc/default/passwd

The implementation of the blowfish based password hashing method had a bug affecting passwords that contain 8bit characters (e.g. umlauts).
Affected passwords are potentially faster to crack via brute-force methods (CVE-2011-2483).

SUSE's crypt() implementation supports the blowfish password hashing function (id $2a) and system logins by default also use this method.
This update eliminates the bug in the $2a implementation. After installing the update existing $2a hashes therefore no longer match hashes generated with the new, correct implementation if the password contains 8bit characters. For system logins via PAM the pam_unix2 module activates a compat mode and keeps processing existing $2a hashes with the old algorithm. This ensures no user gets locked out.
New passwords hashes are created with the id '$2y' to unambiguously identify them as generated with the correct implementation.

Note: To actually migrate hashes to the new algorithm all users are advised to change passwords after the update.

Services that do not use PAM but do use crypt() to store passwords using the blowfish hash do not have such a compat mode. That means users with 8bit passwords that use such services will not be able to log in anymore after the update. As workaround administrators may edit the service's password database and change stored hashes from $2a to $2x. This will result in crypt() using the old algorithm. Users should be required to change their passwords to make sure they are migrated to the correct algorithm.

FAQ :

Q: I only use ASCII characters in passwords, am I a affected in any way? A: No.

Q: What's the meaning of the ids before and after the update? A:
Before the update: $2a -> buggy algorithm

After the update: $2x -> buggy algorithm $2a -> correct algorithm $2y
-> correct algorithm

System logins using PAM have a compat mode enabled by default: $2x -> buggy algorithm $2a -> buggy algorithm $2y

-> correct algorithm

Q: How do I require users to change their password on next login? A:
Run the following command as root for each user: chage -d 0 <username>

Q: I run an application that has $2a hashes in it's password database.
Some users complain that they can not log in anymore. A: Edit the password database and change the '$2a' prefix of the affected users' hashes to '$2x'. They will be able to log in again but should change their password ASAP.

Q: How do I turn off the compat mode for system logins? A: Set BLOWFISH_2a2x=no in /etc/default/passwd

ID	名称	产品	系列	发布时间	最近更新时间	严重程度
69566	Amazon Linux AMI : php (ALAS-2011-07)	Nessus	Amazon Linux Local Security Checks	2013/9/4	2016/1/27	high
75642	openSUSE Security Update : man-pages (openSUSE-SU-2011:0970-1)	Nessus	SuSE Local Security Checks	2014/6/13	2021/1/14	medium
75781	openSUSE Security Update : yast2-core (openSUSE-SU-2011:0921-2)	Nessus	SuSE Local Security Checks	2014/6/13	2021/1/14	medium
75852	openSUSE Security Update : glibc (openSUSE-SU-2011:0921-1)	Nessus	SuSE Local Security Checks	2014/6/13	2021/1/14	medium

检测

插件搜索

high

medium

medium

medium