Major Exploit

[nyjimbo]

This is the same thing we are getting on our servers. FreeBSD, WHM 10.8.0 cPanel 10.8.2-R119.

Run upcp and then the check script and reports not safe.

Run the patch and reports safe.

Run the check script again and reports unsafe :S

I hope this isnt going to be another in a list of 100 other problems where they say "thats a Freebsd problem" and put it on hold.

[randomuser]

After this upgrade to current 21 phpmyadmin not showing databases created after this upgrade. Please fix this in next relase as this is serious bug. I can reproduce this on all of my 15 servers.
I thing that all of you that upgraded to this current 21 will have tha samme issue, please confirm. And also please open ticket at bugzilla.

You need to be the one to open a ticket with cPanel and/or submit a bugzilla report which includes:

1. cPanel/WHM version
2. exact steps to reproduce/locate the issue


The cPanel forums are here for the community to help each other, and it's not often that cPanel staff address issues posted here, as that's not what the forums are for.

[cinusik]

After this upgrade to current 21 phpmyadmin not showing databases created after this upgrade. Please fix this in next relase as this is serious bug. I can reproduce this on all of my 15 servers.
I thing that all of you that upgraded to this current 21 will have tha samme issue, please confirm. And also please open ticket at bugzilla.

[cinusik]

randomuser: I think that my info is helpfull, and I don't have a bugzilla account and I'm using my pda now so it is hrd to post this ticket and register to bugzilla so I asked someone to confirm this and open bugzilla ticket. And steps to reproduce are very simple:
1) create new DB
2) open phpmyadmin from cpanel and you'll see that newly created database is not listed.

[randomuser]

randomuser: I think that my info is helpfull, and I don't have a bugzilla account and I'm using my pda now so it is hrd to post this ticket and register to bugzilla so I asked someone to confirm this and open bugzilla ticket. And steps to reproduce are very simple:
1) create new DB
2) open phpmyadmin from cpanel and you'll see that newly created database is not listed.

Yep, wasn't trying to come off like a jerk, just wanted to emphasize that someone else opening a bugzilla report any time soon may not be likely, unless perhaps it's a widespread issue. Definitely good to see people posting issues they're having. If someone else could confirm and post a report that would be great. edit: works fine on 10.8.2-STABLE_120

Here's a tip for those who are still getting "not safe" after patching:

grep =grep /usr/local/cpanel/bin/mysqladmin

If there's a match, you may be ok. I imagine nick's script is accurate on all platforms, but just in case, you may want to try the command above.

[JamesSmith]

I have submitted a support ticket, number: 155811

If I get a response / resolution from cPanel I'll post it here.

Edit: I can see that a cPanel tech is currently logged into the box, should get a response fairly soon.

[Dillard]

I hope this isnt going to be another in a list of 100 other problems where they say "thats a Freebsd problem" and put it on hold.

It shoudn't be, because all my servers are on FreeBSD 5 and went over to safe the first try (with /scripts/upcp), I'm running S120 btw

[serversphere]

1) create new DB
2) open phpmyadmin from cpanel and you'll see that newly created database is not listed.

Confirmed. Forced update of mysql no help, nor /scripts/cleanupmysqlprivs. Checking mysql console you can see that the database was created. Root phpmysql shows databases as well, and shows them belonging to correct user.

[philb]

OK, there's a slight problem here.

Because of the way patching works, and because at least one of the patches doesnt apply cleanly on every given distribution (looks like four patches - different ones for each distro perhaps, the idea being apply them all and the main file will then get made safe in the end) if your distro does not patch cleanly with every patch file there is a significant risk that you will end up with an unsafe mysqladmin.orig file that HAS THE SAME PERMISSIONS AS THE ORIGINAL MYSQLADMIN FILE, depending on the order the patches were applied/failed in.

You should remove the mysqladmin.orig file in /usr/local/cpanel/bin to be sure as when I modified nicks tester script to check the .orig files on my box it was shown to be unsafe and because it has the same permissions as the original script is still exploitable. Running upcp twice should also remove the issue as the mysqladmin.orig file will get replaced with the now safe file when the patches fail to apply cleanly (as the file the patches are attempting to apply against is already safe - in theory).

[randomuser]

The wrapper won't exec the .orig file so its nothing to worry about.

And if an attacker executes the .orig directly, this isn't an issue, correct?

[nyjimbo]

Couldnt this fix have been done outside the normal "upcp" run ?

I mean is it a script we could be running that does a few things and thats all or do we have to keep running upcp, because sometimes going to the newest edge/current/whatever brings in new bugs and if we just needed to run a quick fix it would be better to run just that.

I'm guessing those few patch lines at the start are the fix, so why do we need to do the whole upcp ?

[cpanelnick]

OK, there's a slight problem here.

Because of the way patching works, and because at least one of the patches doesnt apply cleanly on every given distribution (looks like four patches - different ones for each distro perhaps, the idea being apply them all and the main file will then get made safe in the end) if your distro does not patch cleanly with every patch file there is a significant risk that you will end up with an unsafe mysqladmin.orig file that HAS THE SAME PERMISSIONS AS THE ORIGINAL MYSQLADMIN FILE, depending on the order the patches were applied/failed in.

You should remove the mysqladmin.orig file in /usr/local/cpanel/bin to be sure as when I modified nicks tester script to check the .orig files on my box it was shown to be unsafe and because it has the same permissions as the original script is still exploitable. Running upcp twice should also remove the issue as the mysqladmin.orig file will get replaced with the now safe file when the patches fail to apply cleanly (as the file the patches are attempting to apply against is already safe - in theory).

The wrapper won't exec the .orig file so its nothing to worry about.

[ffeingol]

ok, I'm getting a fuzz nervous here. We ran the sec092306.pl and it did not say safe. we ran upcp --force and then re-ran sec092306.pl and it says safe. Now if I diff the mysqladmin and mysqladmin.orig they are the same.

Is there a definitive way to insure that we're patched?

Thnx

[cinusik]

JamesSmith - thankyou,
Webtiva - you're absolutelly correct, database is only invisible to user's cpanel's phpmyadmin. The root whm phpmyadmin is showing database under correct user. Tried EDGE 496 and the same issue appear. I don't want go back to relase or stable so I hope that cPanel guys will work around this issue soon.

[robjs]

ok, I'm getting a fuzz nervous here. We ran the sec092306.pl and it did not say safe. we ran upcp --force and then re-ran sec092306.pl and it says safe. Now if I diff the mysqladmin and mysqladmin.orig they are the same.

Is there a definitive way to insure that we're patched?

Thnx

I'm sat with philb at the moment, and noticed the issue once we'd run the security check script on one of the old files, and decoded what the script does. If your .orig files and the mysqladmin files are identical, then you should be fine - however, if a normal user calls the .orig file - I'd imagine you're open to the same bug as there was originally. Since I don't know what the original issue was, it's difficult to tell how it'd be exploited.

Nick, can you give us some more information as to what the wrapper you referred to?