86639 2002-12-12 19:49 /162 rader/ Stefan Esser <s.esser@e-matters.de>
Importerad: 2002-12-12 19:49 av Brevbäraren
Extern mottagare: full-disclosure@lists.netsys.com
Mottagare: Bugtraq (import) <2728>
Ärende: Advisory 04/2002: Multiple MySQL vulnerabilities
------------------------------------------------------------
e-matters GmbH
www.e-matters.de
-= Security Advisory =-
Advisory: Multiple MySQL vulnerabilities
Release Date: 2002/12/12
Last Modified: 2002/12/12
Author: Stefan Esser [s.esser@e-matters.de]
Application: MySQL <= 3.23.53a, <= 4.0.5a
Severity: Several vulnerabilities within (lib)MySQL could
allow (remote) compromise of client and/or server.
Risk: Medium to critical
Vendor Status: Vendor released MySQL 3.23.54
Reference: http://security.e-matters.de/advisories/042002.html
Overview:
We have discovered two flaws within the MySQL server that can be
used by any MySQL user to crash the server. Furthermore one of the
flaws can be used to bypass the MySQL password check or to execute
arbitrary code with the privileges of the user running mysqld.
We have also discovered an arbitrary size heap overflow within the
mysql client library and another vulnerability that allows to
write '\0' to any memory address. Both flaws could allow DOS
attacks against or arbitrary code execution within anything linked
against libmysqlclient.
Details:
While auditing the MySQL sourcetree we discovered several bugs
within the MySQL client and server that are listed below:
+++ SERVER +++ COM_TABLE_DUMP - Signed Integer Vulnerability
When handling the COM_TABLE_DUMP package MySQL < 4.x takes two
chars from the packet, casts them directly to unsigned integers
and uses them as length parameters for memcpy. Obviously negative
values within the chars will turn into very big unsigned
numbers. Because this is a heap to heap copy operation and there
is no memory allocating function within the SIGSEGV handler we
strongly believe this bug can only be used for denial of service
attacks. Depending on the packet mysqld will directly crash or
hang in an endless loop of segmentation faults. This was tested
against Windows, Linux and FreeBSD systems.
+++ SERVER +++ COM_CHANGE_USER - Password Length Vulnerability
In February 2000 Robert van der Meulen discovered a flaw within
the main password authentication system of MySQL: The MySQL
challenge response algorithm creates an expected response with
exactly the length of the response provided by the client. So if
the client sends only a one char response MySQL will check only
one byte. But this means it is possible to give the correct
response with only 32 tries (because the charset is only 32 chars
big). When this bug was fixed in 2000 the MySQL authors simply
added a check in the server that the response must be 8 chars
long. However they forgot to add this check to the COM_CHANGE_USER
command, too. So it is still possible for an attacker with a valid
mysql-account to compromise the other accounts that are allowed to
login from the same host. For a local user this means he can break
into the mysql root account and so compromise all databases. This
is especially dangerous in a shared environment or if the root
user is allowed to login from other hosts than localhost. While
the attacker can supply a one byte response to break into the
other accounts he can also send an oversized one. If the response
is longer than 16 chars the internal created expected answer
overflows a stack buffer. If the response is long enough it is
possible to overwrite the saved instruction pointer with bytes
that are generated by the random number generator of the password
verification algorithm. While this sounds hard or impossible to
exploit, we successfully exploited this bug on our linux
maschines. Due to the fact that mysql restarts on crash you have
unlimited tries. Because of the limited set of characters
generated by the random number generator we strongly believe that
this bug is not exploitable on Windows, because it is not possible
to overwrite the instruction pointer with valid controllable
addresses.
+++ CLIENT +++ libmysqlclient read_rows Overflow
When the MySQL client library receives answer rows from the server
it wants to copy the answers into another buffer. Therefore it
loops through the returned fields and copies them to the other
location. This is done without actually checking if the stored
field sizes are within the destination buffer
boundaries. Additionally there is also a terminating '\0' added to
the end of all fields without checking for enough space within the
destination buffer. Due to the fact that this bug gets already
triggered by a simple SELECT query anything that is linked against
libmysql is potentially vulnerable. Due to the nature of this bug
it is trivial to use it as denial of service attack against the
client applications (A negative fieldsize will do the job). If it
possible to use this overflow to execute code on the client system
is different from application to application. It depends mainly on
the fact if malloc() overflows are exploitable on that particular
system and if the application allows enough control over the heap
structure by triggering different execution paths.
+++ CLIENT +++ libmysqlclient read_one_row Byte Overwrittes
When the MySQL client library fetchs one row from the MySQL server
it loops through the fields to remember pointers to the field
values. The field sizes are trusted and not checked against out
of boundary conditions. After remembering the pointer the previous
field gets zero terminated. A malformed packet can supply any
field size and so overwrite some arbitrary memory address with a
'\0'. An invalid address will of course crash the client. Because
the address that is written to is arbitrary (maybe hard to supply
because it must be supplied as delta) all clients that make use of
fetching the answer row by row are most probably vulnerable to
arbitrary code execution exploits.
Finally it must be mentioned that an attacker can of course use a
combination of the described attacks to break into a system or to
get access to privileges he normaly does not own. f.e. it is
possible for a local user to crash the server with the
COM_TABLE_DUMP bug (if he cannot takeover the root account with
the COM_CHANGE_USER bug) and then bind a fake server to the MySQL
port 3306. And with a fake server he can exploit the
libmysqlclient overflow. Another scenario would be an attacker
that tries to exploit his favourite mod_scripting language to
takeover the webserver by connecting to an external fake server...
Proof of Concept:
e-matters is not going to release an exploit for these
vulnerabilities to the public.
Vendor Response:
03. December 2002 - Vendor was contacted via email.
04. December 2002 - Vendor informs me that bugs are fixed and that
they started building new packages.
12. December 2002 - Vendor has released MySQL 3.23.54 which fixes these
vulnerabilites.
Recommendation:
We suggest anyone using MySQL to upgrade to a new or patched
version as soon as possible.
GPG-Key:
http://security.e-matters.de/gpg_key.asc
pub 1024D/75E7AAD6 2002-02-26 e-matters GmbH - Securityteam Key
fingerprint = 43DD 843C FAB9 832A E5AB CAEB 81F2 8110 75E7 AAD6
Copyright 2002 Stefan Esser. All rights reserved.
(86639) /Stefan Esser <s.esser@e-matters.de>/(Ombruten)