Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 220813 - dev-db/mysql: arbitrary shell command execution
Summary: dev-db/mysql: arbitrary shell command execution
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Security
Classification: Unclassified
Component: Vulnerabilities (show other bugs)
Hardware: All All
: High major (vote)
Assignee: Gentoo Security
URL: http://bugs.mysql.com/bug.php?id=37428
Whiteboard: B1 [glsa]
Keywords:
Depends on: CVE-2009-4484
Blocks:
  Show dependency tree
 
Reported: 2008-05-07 20:49 UTC by Christian Hoffmann (RETIRED)
Modified: 2012-01-05 22:46 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
mysql_udf.c (mysql_udf.c,1.71 KB, patch)
2008-05-08 07:42 UTC, Robert Buchholz (RETIRED)
no flags Details | Diff
mysql_udf.c (mysql_udf.c,1.80 KB, text/plain)
2008-05-08 22:25 UTC, Robert Buchholz (RETIRED)
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Christian Hoffmann (RETIRED) gentoo-dev 2008-05-07 20:49:28 UTC
Mattias Bengtsson <mattias@secweb.se> reported that he found a vulnerability which allows for privilege escalation in mysql (mysql users being able to run arbitrary shell code under certain circumstances, if I got it right).
This issue has not yet been reported to upstream and hasn't been published anywhere else (therefore the restriction of that bug).

He can probably better explain it than me, so here goes the (stripped) irc log:

22:25:20 <mattiasb> i wrote an exploit for the create function-thing some time ago which i realized had bigger inpact than i first tought.
22:26:03 <@hoffie> create function?
22:29:46 <mattiasb> yep, you know raptors exploit for create function? mysql restricted that to only load things in /usr/lib and required xxx() and xxx_init() . what i did was just to scan my /usr/lib-category, loaded libssl.so and replaced a fptr to run my own code.
22:31:09 <@hoffie> has that been reported it?
22:31:15 <mattiasb> no.
22:31:34 <@hoffie> so someone who is able to create mysql functions is able to execute arbitrary shell code, right?
22:31:41 <mattiasb> yep.
22:33:13 <mattiasb> why i diden't report it was due the fact you need write permissions to mysql.func. At first i diden't think it was that common as it seems to be :D
22:36:16 <@hoffie> hm, why would one have write permissions to that table?
22:36:38 <@hoffie> are they granted by default if the user has CREATE FUNCTION privs?
22:37:59 <mattiasb> i think it was something like that, wonder if it wasen't the stored producers that needed access to that table also.
22:39:51 <mattiasb> i can give you the code so you can see what it does.

22:40:33 <mattiasb> http://www.secweb.se/mattias/private/mysql_udf.c


robbat2 / chtekk, can you take that upstream please? Mattias seems to be under time constraints and I don't have an understanding about that at all.
Comment 1 Robert Buchholz (RETIRED) gentoo-dev 2008-05-08 07:42:14 UTC
Created attachment 152431 [details, diff]
mysql_udf.c

http://www.secweb.se/mattias/private/mysql_udf.c
Comment 2 Robert Buchholz (RETIRED) gentoo-dev 2008-05-08 07:46:12 UTC
robbat2 / chtekk, please consider this vulnerability embargoed. If the issue is as severe as Mattias describes, we should do a responsible disclosure. 
Comment 3 Robert Buchholz (RETIRED) gentoo-dev 2008-05-08 22:25:49 UTC
Created attachment 152523 [details]
mysql_udf.c

The previous version had an error in the SQL statement, and this has little more verbose error messages.
Comment 4 Robert Buchholz (RETIRED) gentoo-dev 2008-05-08 22:29:20 UTC
I could reproduce this issue and crash the mysql server. However, from what I understand, any exploiter basically needs root access to the mysql daemon -- to create a function one needs INSERT privileges to the mysql database, and CREATE FUNCTION privileges.

See this for details:
http://dev.mysql.com/doc/refman/5.0/en/create-function.html

I believe this still qualifies for a security bug though, luckily it limits the scope. Robin, do you want to escalate this upstream or shall we take care of that while you are gone?
Comment 5 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-05-21 21:53:51 UTC
To clarify the requirements on the attacker (for mysql 5.0):
GRANT CREATE ROUTINE ON (anything) TO 'attacker'@'host';
GRANT INSERT ON mysql.func to 'attacker'@'host';

or find some existing mysql user that has the ability to CREATE ROUTINE somewhere, and has the INSERT priv on the mysql.func table.

UDFs are reasonably rare, and allowing any user to create them even more so, thus while this wouldn't be widespread, it is still a valid security issue in my opinion - you wouldn't even have to do it with libssl, i'm sure you could use the same trick on quite a few other libs.
Comment 6 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-05-27 15:26:08 UTC
Adding the upstream developer here now, lenz@grimmer.com.
Comment 7 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-06-05 17:09:17 UTC
Upstream folks say this is not a severe problem, with the permissions required in MySQL to execute it, you could do far worse. A fix is forthcoming nevertheless.
Comment 8 Christian Hoffmann (RETIRED) gentoo-dev 2008-06-06 13:27:17 UTC
"proxy comment" as Mattias is not able to comment on this bug (see bug 214413):

"""
I can see why something like deleting all the data can be seen as "far worse". But we all have backups, right?
Let's say someone actually tries to secure a backend mysql server and disable ssh and such. With this issue they can easily backdoor the whole system. All they need is the mysql root or dev password (or a privilege escape). And what i know of there is no legal way to execute system commands in mysql.
Why even use LD_LIBRARY_PATH and not something like LD_MYSQL_UDF_PATH? The only way to disable UDF, that i know of is to compile mysql static.
I don't like when a vendor rates an issue without looking at it from a hackers view.
"""
Comment 9 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-06-16 17:41:43 UTC
Update on this.

Upstream was originally going to not fix it, because the logical fix of using a separate path was going to break backwards compatibility, which they said was a no-no for any changes to the 5.0 branch (the 5.1 branch already uses a separate path).

However, I pointed out that they could make the load path configurable, and manage to add power while having the same default.

Rough plans are for a new option: plugin-dir, which may be empty, $LD_LIBRARY_PATH (new upstream default), or an explicit directory. For Gentoo, I'm going to make sure that it's configured to an explicit directory.

They have a bug for it too now, but it's locked to me even, I link it here for when it gets opened. They are applying for a CVE as well.
Comment 10 Christian Hoffmann (RETIRED) gentoo-dev 2008-10-13 16:49:22 UTC
Any news on this one?
Comment 11 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2008-11-14 01:13:02 UTC
Nothing from upstream yet.
Comment 12 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2009-05-04 18:55:01 UTC
security:
Upstream says they've just fixed it in 5.0.81, however it is NOT fixed in enterprise yet.
     * Security Enhancement: To enable stricter control over the
       location from which user-defined functions can be loaded,
       the plugin_dir system variable has been backported from  
       MySQL 5.1. If the value is non-empty, user-defined     
       function object files can be loaded only from the 
       directory named by this variable. If the value is empty,
       the behavior that is used prior to the inclusion of     
       plugin_dir applies: The UDF object files must be located
       in a directory that is searched by your system's dynamic
       linker. (Bug#37428: http://bugs.mysql.com/37428)
Comment 13 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2009-05-04 18:55:40 UTC
lenz: the security fix is going into Enterprise right? If it's not, I hereby expressly request that it is, even if I have to port it myself.
Comment 14 Lenz Grimmer 2009-05-27 08:39:05 UTC
Hi,

sorry for the late reply.

(In reply to comment #13)
> lenz: the security fix is going into Enterprise right? If it's not, I hereby
> expressly request that it is, even if I have to port it myself.

Yes, of course it will go into the next enterprise release as well. In fact, the 5.0 community and enterprise source trees have been merged - there will be no more separate releases of 5.0 from now on.
Comment 15 Robin Johnson archtester Gentoo Infrastructure gentoo-dev Security 2010-03-25 19:22:02 UTC
this was fixed a while ago upstream, but for now, the latest stabilization is happening in 303747

It's also public elsewhere now, so unlocking this.
Comment 16 Paweł Hajdan, Jr. (RETIRED) gentoo-dev 2011-01-10 11:48:10 UTC
(In reply to comment #15)
> this was fixed a while ago upstream, but for now, the latest stabilization is
> happening in 303747

Should we update the status of this bug? All security-supported arches have done the stabilization from bug #303747 .
Comment 17 Tim Sammut (RETIRED) gentoo-dev 2011-05-14 20:17:21 UTC
I believe all arches have stabilized a fixed version through some combination of bug 303747 and bug 344987. Added to existing GLSA request.
Comment 18 GLSAMaker/CVETool Bot gentoo-dev 2012-01-05 22:46:15 UTC
This issue was resolved and addressed in
 GLSA 201201-02 at http://security.gentoo.org/glsa/glsa-201201-02.xml
by GLSA coordinator Tim Sammut (underling).