|Summary:||dev-db/mysql: arbitrary shell command execution|
|Product:||Gentoo Security||Reporter:||Christian Hoffmann (RETIRED) <hoffie>|
|Component:||Vulnerabilities||Assignee:||Gentoo Security <security>|
|Severity:||major||CC:||lenz, mattias, mysql-bugs|
|Package list:||Runtime testing required:||---|
|Bug Depends on:||303747|
Description Christian Hoffmann (RETIRED) 2008-05-07 20:49:28 UTC
Mattias Bengtsson <email@example.com> 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) 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) 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) 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) 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 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 2008-05-27 15:26:08 UTC
Adding the upstream developer here now, firstname.lastname@example.org.
Comment 7 Robin Johnson 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) 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 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) 2008-10-13 16:49:22 UTC
Any news on this one?
Comment 11 Robin Johnson 2008-11-14 01:13:02 UTC
Nothing from upstream yet.
Comment 12 Robin Johnson 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 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 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) 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) 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 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).