Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Network Security IT

MariaDB and MySQL Authentication Bypass Exploit 73

JohnBert writes "A security bug in MariaDB and MySQL has been revealed, allowing a known username and password to access the master user table of a MySQL server and dump it into a locally-stored file. By using a tool like John the Ripper, this file can be easily cracked to reveal text passwords that can provide further access. By committing a threaded brute-force module that abuses the authentication bypass flaw to automatically dump the password database, you can access the database using the cracked password hashes even if the authentication bypass vulnerability is fixed."
This discussion has been archived. No new comments can be posted.

MariaDB and MySQL Authentication Bypass Exploit

Comments Filter:
  • by Anonymous Coward on Monday June 11, 2012 @01:25PM (#40285897)

    Basically the password comparison routine uses a bad assumption about memcmp. This assumption fails with a probability of about 1 in 256 on some systems. You just use any random password, try a couple hundred times to log in and eventually it works. Yes, it is that bad.

  • Re:Like it matters! (Score:5, Informative)

    by tuffy ( 10202 ) on Monday June 11, 2012 @01:59PM (#40286355) Homepage Journal

    Firefox uses SQLite, which implements a database management system in a single file. It's not something anyone can connect to remotely.

  • by SteveAyre ( 209812 ) on Monday June 11, 2012 @02:25PM (#40286705)

    They say you can get in by making 300 connection attempts, which can be done within a fraction of a second. Which is true.

    They don't say that you have to do it within a fraction of a second.

    The memcmp function has a 1/256 chance of returning the required value that makes it treat any password as the correct password - there's no link between the connection attempts, each time you try to connect you have the same 1/256 chance. You could space the attempts out over seveal minutes, hours or days if you wanted to - it'd just slow down the time it'd take you to get in (and make it more likely they've patched their systems before you get in).

    Practically, this is slightly less newsworthy than it sounds. Yes the bug exists and yes it's serious, but it also depends on which memcmp version you're using on whether you're actually affected. The gcc builtin ones aren't affected or the libc ones, the glibc one is. That means whether it's exploitable depends on how your server was compiled. And it appears that the official versions from mysql.com aren't affected, and testing my debian systems today neither are they (but they're nicely firewalled anyway, just in case). Source: http://seclists.org/oss-sec/2012/q2/493 [seclists.org]

  • by SteveAyre ( 209812 ) on Monday June 11, 2012 @02:33PM (#40286809)

    Yes, it's exactly that. They assumed memcmp returned a value in the range -128..127 - so they've assumed a char was sufficient. And many implementations do indeed return that, but unfortunately not all.

    http://seclists.org/oss-sec/2012/q2/493 [seclists.org]:

    Whether a particular build of MySQL or MariaDB is vulnerable, depends on
    how and where it was built. A prerequisite is a memcmp() that can return
    an arbitrary integer (outside of -128..127 range). To my knowledge gcc
    builtin memcmp is safe, BSD libc memcmp is safe. Linux glibc
    sse-optimized memcmp is not safe, but gcc usually uses the inlined
    builtin version.

  • Comment removed (Score:5, Informative)

    by account_deleted ( 4530225 ) on Monday June 11, 2012 @03:22PM (#40287467)
    Comment removed based on user account deletion

You knew the job was dangerous when you took it, Fred. -- Superchicken

Working...