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.
Created attachment 152431 [details, diff] mysql_udf.c http://www.secweb.se/mattias/private/mysql_udf.c
robbat2 / chtekk, please consider this vulnerability embargoed. If the issue is as severe as Mattias describes, we should do a responsible disclosure.
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.
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?
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.
Adding the upstream developer here now, lenz@grimmer.com.
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.
"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. """
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.
Any news on this one?
Nothing from upstream yet.
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)
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.
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.
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.
(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 .
I believe all arches have stabilized a fixed version through some combination of bug 303747 and bug 344987. Added to existing GLSA request.
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).
