MariaDB upstream reported a flaw in MySQL server's check_scramble() function that is used to check user passwords during authentication. The memcmp() function return value of type int was cast to my_bool (char) type, which could result in 0 being returned by check_scramble() in cases when memcmp() returned non-0.
On systems where system memcmp() implementation can return values that do not fit into an int type, this flaw could allow (possibly remote) attackers able to connect to mysql port or socket to easily bypass password authentication.
MySQL upstream bug report:
MariaDB upstream patch and bug report:
Fixed (MySQL) upstream in:
Bug #13934049: 64884: LOGINS WITH INCORRECT PASSWORD ARE ALLOWED
Fixed an improper type conversion on return that can make the server accept
logins with a wrong password.
Fix included in upstream versions 5.1.63 and 5.5.24:
This is now public via:
The MySQL bug (casting of the int to char, which may lead to truncation) exists in MySQL code base since 4.x versions. However, it only is an issue when used with memcmp() implementation that can return values out of the -255 .. 255 range.
memcmp() function is defined as:
int memcmp(const void *s1, const void *s2, size_t n);
It returns an integer less than, equal to, or greater than zero if the first n bytes of s1 is found, respectively, to be less than, to match, or be greater than the first n bytes of s2.
memcmp() implementations often return values that do not use full range of the int type and rather return one of the following:
- normalized values (-1/0/1)
- diff of the first non-equal bytes (this is a documented behavior of BSD libc
implementation, but also a behavior of the gcc builtin implementation used on x86 architectures)
A glibc x86_64 SSE4 optimized memcmp() implementation was identified as one that returns values out of the -255 .. 255 range. Depending on the position of the first non-equal byte, it often returns value that is multiple of 256, which results in non-0 memcmp() return value to be incorrectly converted to 0 after casting the value to char type. This optimized memcmp() version is only available in recent glibc versions. Red Hat Enterprise Linux 6 is the first Red Hat Enterprise Linux version that has this optimized implementation available.
However, mysql packages in Red Hat Enterprise Linux 6 do not use glibc optimized memcmp() version. A gcc builtin is used in check_scramble(), which do not trigger this problem (see above).
This problem was tested on all Red Hat Enterprise Linux 4, 5, and 6 architectures using the latest released mysql packages and was not found to affect any version. There is no plan for an immediate update correcting this issue, it will be corrected with future mysql packages updates.
In Fedora, glibc memcmp() function is called from check_scramble() and hence x86_64 SSE4 systems are known to be affected by this problem.
Created mysql tracking bugs for this issue
Affects: fedora-all [bug 830680]
This issue does not affect MySQL as shipped with Red Hat Enterprise Linux 4, 5, or 6. For a technical explanation please see https://bugzilla.redhat.com/show_bug.cgi?id=814605#c19
mysql-5.5.24-1.fc17 has been pushed to the Fedora 17 stable repository. If problems still persist, please make note of it in this bug report.
mysql-5.5.24-1.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
This issue has been addressed in following products:
Red Hat Enterprise Linux 5
Via RHSA-2013:0180 https://rhn.redhat.com/errata/RHSA-2013-0180.html
As explained in comment 19, this issue did not affect MySQL packages in Red Hat Enterprise Linux 4, 5 and 6. Due to the possible impact of the flaw, mysql packages in Red Hat Enterprise Linux 5 and 6 now include the fix to ensure no future builds (possibly done with different compiler or C library optimization) are affected by this problem.
In Red Hat Enterprise Linux 5, the fix was included in RHSA-2013:0180 as backported patch:
In Red Hat Enterprise Linux 6, mysql packages were updated to upstream version that includes the fix via RHSA-2012:1462: