Re: [Full-disclosure] MySQL (Linux) Stack based buffer overrun PoC Zeroday
Hi Kingcope, MySQL Server exploitable stack based overrun Ver 5.5.19-log for Linux and below (tested with Ver 5.1.53-log for suse-linux-gnu too) unprivileged user (any account (anonymous account?), post auth) as illustrated below the instruction pointer is overwritten with 0x41414141 bug found by Kingcope this will yield a shell as the user 'mysql' when properly exploited Out of curiosity, is this exploitable when using hardened toolchain settings? Specifically, -D_FORTIFY_SOURCES=2 and -fstack-protector-all? Jeff On Sat, Dec 1, 2012 at 4:26 PM, king cope isowarez.isowarez.isowa...@googlemail.com wrote: (see attachment) Cheerio, Kingcope ___ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
Re: [Full-disclosure] MySQL (Linux) Stack based buffer overrun PoC Zeroday
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 12/01/2012 02:26 PM, king cope wrote: (see attachment) Cheerio, Kingcope So normally for MySQL issues Oracle would assign the CVE #. However in this case we have a bit of a time constraint (it's a weekend and this is blowing up quickly) and the impacts are potentially quite severe. So I've spoken with some other Red Hat SRT members and we feel it is best to get CVE #'s assigned for these issues quickly so we can refer to them properly. If Oracle security has already assigned CVE's for these please let us and the public know so we can use the correct numbers. Also if Oracle can let the public know which versions of MySQL are affected (e.g. 5.0.x, 5.1.x, 5.5.x, etc.) that would be very helpful to everyone I am sure. I am also adding MySQL, Oracle, MariaDB, OSS-SEC, Steven Christey, cve-assign and OSVDB to the CC so that everyone is aware of what is going on. http://seclists.org/fulldisclosure/2012/Dec/4 - -- Kurt Seifried Red Hat Security Response Team (SRT) PGP: 0x5E267993 A90B F995 7350 148F 66BF 7554 160D 4553 5E26 7993 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBAgAGBQJQuu5zAAoJEBYNRVNeJnmTF8sP/10htpTkb298u/Szo3yOcRiE 8HgMwXPVGFhPh0d/avRgIocYeJxIH9oUf7xN/A53TXktgp7CZZUMhJAh4Hv5mrFn moVGxs3qBaTT8+zFa8Ea7VUqzYXUGdMNPBeyijyw18WRHu7ETrUg2pXREkr056ol GRt5BuMyzz7sdlLNCYWki+uMIxWtnyjw4ngkNCcAbDuPGdmIxwTiNQ8oOLWRgs/+ ybL0EXWIJgeBWBdsx0nlJNrL6gHqCsfZduKNl95MAdFHRMiOFrc/GQWfL81d+q86 upWQ+S7U8or/dpcD7eKInSmGvjgoFR+cF1S2lkDqBLXg2ER8aZzemaG/8p+m4ICH Cef7Zt7q5F+FaSC4wOeCmmR0SmeA1ZO1krY8Ur3oyuYr39Iegk1O48hAzAP4RbDS +m0pPFNanDuW2h9NSjAx19C2qgEMoMGCaTpJY1mfF3Zus5ctxXyYtNU1g/yIGr3f E2boYVOYW4CPJSRGkeF6n1Vf+c+Sov/0/enxJxUsf9tA58iQUSQNsI+aSj71oI3v 1Y0/Ce3FKAJRkgY374TD+K834ruhFAO9xJXdA1MSDdz4rJ1uQusIKufz3ubjHCWP KhgpV2Pp1Gq5+XGuNPKn06cNh8a/oYubMNpQBxeIbWYm6eFuUvwnSP9ki+hPLjvw fa9hdUARqamhayQbkNdH =sXhV -END PGP SIGNATURE-
Re: [oss-security] Re: [Full-disclosure] MySQL (Linux) Stack based buffer overrun PoC Zeroday
Hi, Kurt! This is CVE-2012-5579 that we've been discussing recently. A test case it different, but it triggers exactly the same code. MariaDB is not vulnerable as of 5.1.66, 5.2.13, 5.3.11, 5.5.28a. Latest released MySQL versions are still affected, but Oracle knows about this issue, so next versions won't be. Regards, Sergei MariaDB Security Coordinator On Dec 01, Kurt Seifried wrote: On 12/01/2012 02:26 PM, king cope wrote: (see attachment) Cheerio, Kingcope So normally for MySQL issues Oracle would assign the CVE #. However in this case we have a bit of a time constraint (it's a weekend and this is blowing up quickly) and the impacts are potentially quite severe. So I've spoken with some other Red Hat SRT members and we feel it is best to get CVE #'s assigned for these issues quickly so we can refer to them properly. If Oracle security has already assigned CVE's for these please let us and the public know so we can use the correct numbers. Also if Oracle can let the public know which versions of MySQL are affected (e.g. 5.0.x, 5.1.x, 5.5.x, etc.) that would be very helpful to everyone I am sure. I am also adding MySQL, Oracle, MariaDB, OSS-SEC, Steven Christey, cve-assign and OSVDB to the CC so that everyone is aware of what is going on. http://seclists.org/fulldisclosure/2012/Dec/4
Re: [oss-security] Re: [Full-disclosure] MySQL (Linux) Stack based buffer overrun PoC Zeroday
On 12/02/2012 11:30 AM, Kurt Seifried wrote: So normally for MySQL issues Oracle would assign the CVE #. However in this case we have a bit of a time constraint (it's a weekend and this is blowing up quickly) and the impacts are potentially quite severe. So I've spoken with some other Red Hat SRT members and we feel it is best to get CVE #'s assigned for these issues quickly so we can refer to them properly. If Oracle security has already assigned CVE's for these please let us and the public know so we can use the correct numbers. Also if Oracle can let the public know which versions of MySQL are affected (e.g. 5.0.x, 5.1.x, 5.5.x, etc.) that would be very helpful to everyone I am sure. So here are the CVEs which Kurt meant to assign, but somehow that mail never reached the lists. * CVE-2012-5611 MySQL (Linux) Stack based buffer overrun PoC Zeroday http://seclists.org/fulldisclosure/2012/Dec/4 https://bugzilla.redhat.com/show_bug.cgi?id=882599 * CVE-2012-5612 MySQL (Linux) Heap Based Overrun PoC Zeroday http://seclists.org/fulldisclosure/2012/Dec/5 https://bugzilla.redhat.com/show_bug.cgi?id=882600 * CVE-2012-5613 MySQL (Linux) Database Privilege Elevation Zeroday Exploit http://seclists.org/fulldisclosure/2012/Dec/6 https://bugzilla.redhat.com/show_bug.cgi?id=882606 * CVE-2012-5614 MySQL Denial of Service Zeroday PoC http://seclists.org/fulldisclosure/2012/Dec/7 https://bugzilla.redhat.com/show_bug.cgi?id=882607 * CVE-2012-5615 MySQL Remote Preauth User Enumeration Zeroday http://seclists.org/fulldisclosure/2012/Dec/9 https://bugzilla.redhat.com/show_bug.cgi?id=882608 -- Huzaifa Sidhpurwala / Red Hat Security Response Team
Re: [oss-security] Re: [Full-disclosure] MySQL (Linux) Stack based buffer overrun PoC Zeroday
Hi, Huzaifa! Here's the vendor's reply: On Dec 02, Huzaifa Sidhpurwala wrote: * CVE-2012-5611 MySQL (Linux) Stack based buffer overrun PoC Zeroday http://seclists.org/fulldisclosure/2012/Dec/4 https://bugzilla.redhat.com/show_bug.cgi?id=882599 A duplicate of CVE-2012-5579 Already fixed in all stable MariaDB version. * CVE-2012-5612 MySQL (Linux) Heap Based Overrun PoC Zeroday http://seclists.org/fulldisclosure/2012/Dec/5 https://bugzilla.redhat.com/show_bug.cgi?id=882600 Acknowledged. https://mariadb.atlassian.net/browse/MDEV-3908 * CVE-2012-5613 MySQL (Linux) Database Privilege Elevation Zeroday Exploit http://seclists.org/fulldisclosure/2012/Dec/6 https://bugzilla.redhat.com/show_bug.cgi?id=882606 Not a bug. MySQL manual specifies many times very explicitly: === * Do not grant the `FILE' privilege to nonadministrative users. Any user that has this privilege can write a file anywhere in the file system with the privileges of the *Note `mysqld': mysqld. daemon. To make this a bit safer, files generated with *Note `SELECT ... INTO OUTFILE': select. do not overwrite existing files and are writable by everyone. The `FILE' privilege may also be used to read any file that is world-readable or accessible to the Unix user that the server runs as. With this privilege, you can read any file into a database table. This could be abused, for example, by using *Note `LOAD DATA': load-data. to load `/etc/passwd' into a table, which then can be displayed with *Note `SELECT': select. === You should exercise particular caution in granting the `FILE' and administrative privileges: * The `FILE' privilege can be abused to read into a database table any files that the MySQL server can read on the server host. This includes all world-readable files and files in the server's data directory. The table can then be accessed using *Note `SELECT': select. to transfer its contents to the client host. === Additionally, MySQL (and MariaDB) provides a --secure-file-priv option that allows to restrict all FILE operations to a specific directory. Thus, CVE-2012-5613 is not a bug, but a result of a misconfiguration, much like an anonymous ftp upload access to the $HOME of the ftp user. * CVE-2012-5614 MySQL Denial of Service Zeroday PoC http://seclists.org/fulldisclosure/2012/Dec/7 https://bugzilla.redhat.com/show_bug.cgi?id=882607 Acknowledged. https://mariadb.atlassian.net/browse/MDEV-3910 * CVE-2012-5615 MySQL Remote Preauth User Enumeration Zeroday http://seclists.org/fulldisclosure/2012/Dec/9 https://bugzilla.redhat.com/show_bug.cgi?id=882608 This is hardly a zeroday issue, it was known for, like, ten years. But I'll see what we can do here. https://mariadb.atlassian.net/browse/MDEV-3909 Regards, Sergei MariaDB Security Coordinator
Re: [oss-security] Re: [Full-disclosure] MySQL (Linux) Stack based buffer overrun PoC Zeroday
On dim., 2012-12-02 at 21:17 +0100, king cope wrote: My opinion is that the FILE to admin privilege elevation should be patched. What is the reason to have FILE and ADMIN privileges seperated when with this exploit FILE privileges equate to ALL ADMIN privileges. Maybe because you might not want admins to have read/write access to the filesystem anyway? Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Re: [oss-security] Re: [Full-disclosure] MySQL (Linux) Stack based buffer overrun PoC Zeroday
Correct, I tell that from experience because I've seen many configurations where the least privileged user has file privs enabled. If we leave it that way the attackers will be more happy, it's not decision to patch it or not, just a hint . Regard, Kingcope 2012/12/2 Yves-Alexis Perez cor...@debian.org: On dim., 2012-12-02 at 21:17 +0100, king cope wrote: My opinion is that the FILE to admin privilege elevation should be patched. What is the reason to have FILE and ADMIN privileges seperated when with this exploit FILE privileges equate to ALL ADMIN privileges. Maybe because you might not want admins to have read/write access to the filesystem anyway? Regards, -- Yves-Alexis
Re: [oss-security] Re: [Full-disclosure] MySQL (Linux) Stack based buffer overrun PoC Zeroday
Hi, king cope! On Dec 02, king cope wrote: Hi, My opinion is that the FILE to admin privilege elevation should be patched. What is the reason to have FILE and ADMIN privileges seperated when with this exploit FILE privileges equate to ALL ADMIN privileges. I understand that it's insecure to have FILE privileges attached to a user. But if this a configuration issue and not a vulnerability then as stated above there must be something wrong with the privilege management in this SQL server. You've missed that part of my reply: Additionally, MySQL (and MariaDB) provides a --secure-file-priv option that allows to restrict all FILE operations to a specific directory. Normally, if a DBA wants to grant FILE privilege to users, the server will have something like secure-file-priv=/tmp/mysql (for example) specified in the configuration file. This way any operation allowed by the FILE privilege (like SELECT ... OUTFILE) will only be able to access files under the /tmp/mysql/ path. Regards, Sergei
