FW: [VulnWatch] [AppSecInc Advisory MYSQL05-V0003] Multiple Issues with MySQL User Defined Functions

Started by Magnus Haganderover 20 years ago2 messages
#1Magnus Hagander
mha@sollentuna.net

FYI, issue (1) applies to postgresql as well. It's fixed by
http://archives.postgresql.org/pgsql-patches/2005-07/msg00529.php.

//Magnus

Show quoted text

-----Original Message-----
From: Team SHATTER [mailto:shatter@appsecinc.com]
Sent: Tuesday, August 09, 2005 12:42 AM
To: bugtraq@securityfocus.com
Cc: vulnwatch@vulnwatch.org;
full-disclosure@lists.grok.org.uk; bugs@securitytracker.com;
security@lists.seifried.org
Subject: [VulnWatch] [AppSecInc Advisory MYSQL05-V0003]
Multiple Issues with MySQL User Defined Functions

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Multiple Issues with MySQL User Defined Functions

AppSecInc Team SHATTER Security Advisory MYSQL05-V0003
http://www.appsecinc.com/resources/alerts/mysql/2005-003.html
August 08, 2005

Risk level: LOW

Credits: This vulnerability was discovered and researched by
Reid Borsuk of Application Security Inc.

Affected Versions:
ALL

Background:
User-defined functions in MySQL allow a user in the database
to call binary libraries on the operating system. Creating a
user-defined function requires insert privileges on the
mysql.func table.

Details:
By using specially crafted CREATE FUNCTION requests it may be
possible for attackers to halt the system or execute remote
code on some systems. Two specific issues are detailed below.

1) If an attacker asks a Windows based MySQL server to load
an invalid library file the application will hang until a
dialog box is acknowledged on the server. By requesting one
of the many non-library files included in the PATH by default
on Windows installations a server will be effectively halted.
This is due to the fact that the Windows function
LoadLibraryEx() will block when loading an invalid library
file with the following message:

"The application or DLL XXXX is not a valid Windows image.
Please check this against your installation diskette."

It should be noted that this is a Windows specific issue;
other operating systems are not likely to be affected.

An attacker attempting to exploit this issue must have insert
privileges on the mysql.func table. This is a high level of
privilege that is not normally given to untrusted users.

2) MySQL attempts to filter execution of arbitrary libraries
by requiring any UDF libraries to have either XXX_deinit() or
XXX_init() functions defined. This is intended to prevent an
attacker from including any libraries that were not
specifically programmed to work with MySQL. Unfortunately
this function naming convention is relatively common and
default libraries may have these functions defined.

For instance, the "jpeg1x32.dll" and "jpeg2x32.dll"
libraries, included by default with Windows 2000 have these
functions defined.
This allows an attacker to load the jpeg_cmp() function from
"jpeg1x32.dll" and the jpeg_decmp() function from
"jpeg2x32.dll". When either of these functions is called, the
MySQL daemon will crash due to improper argument passing.

Both the jpeg_cmp_init() and jpeg_decmp_init() functions
assumes there are 6 arguments waiting for it on the stack.
One of these, Arg 6
(EBP+0x1C) is assumed to be a pointer to a memory location.
Areas of the memory past this pointer are later overwritten
by other arguments passed to this function. Due to the fact
that Arg 4 (EBP+0x14) through Arg 6 (EBP+0x1C) are not used
prior to this call, it may be possible to pollute the stack
and overwrite arbitrary memory locations with attacker
supplied values.

Although this is a Windows specific example, it is possible
that other operating systems are affected.

Exploiting this vulnerability would require the ability to
create user-defined functions. This is not typically granted
to untrusted users, however given this vulnerability you
should understand the ramifications of granting the ability
to create user-defined functions.

Workaround:
Restrict access to create user-defined functions.

Vendor Status:
Vendor was contacted and declined to produce a patch.

Fix:
None is available.

Links:
Application Security, Inc advisory:
http://www.appsecinc.com/resources/alerts/mysql/2005-003.html

- --
_____________________________________________
Application Security, Inc.
www.appsecinc.com
AppSecInc is the leading provider of database security
solutions for the enterprise. AppSecInc products proactively
secure enterprise applications at more than 300 organizations
around the world by discovering, assessing, and protecting
the database against rapidly changing security threats. By
securing data at its source, we enable organizations to more
confidently extend their business with customers, partners
and suppliers. Our security experts, combined with our strong
support team, deliver up-to-date application safeguards that
minimize risk and eliminate its impact on business.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (MingW32)

iD8DBQFC99+2/0w1dSVRt4URAojuAKCq878ITG4qdH7yy9BCLfvV7SUotACgxjUX
RG9CbBZAo3R3eOdktV73g7I=
=0sOE
-----END PGP SIGNATURE-----

#2Tom Lane
tgl@sss.pgh.pa.us
In reply to: Magnus Hagander (#1)
Re: FW: [VulnWatch] [AppSecInc Advisory MYSQL05-V0003] Multiple Issues with MySQL User Defined Functions

"Magnus Hagander" <mha@sollentuna.net> writes:

FYI, issue (1) applies to postgresql as well. It's fixed by
http://archives.postgresql.org/pgsql-patches/2005-07/msg00529.php.

Note that the equivalent exploit in Postgres would require superuser
privilege (since it requires creating a C function). It's a bit hard
to see it as a credible "security threat" since you already have the
keys to the kingdom if superuser.

I'm not totally certain about the security model in MySQL --- do they
have a distinction between trusted and untrusted function languages?
The document only talks about "insert privilege on mysql.func" which
sounds like a one-level design...

regards, tom lane