LinkBack URL
About LinkBacksOriginally Posted by ffeingol
grep =grep mysqladmin
grep =grep mysqladmin.orig
Are you getting matches on both?
grep =grep mysqladmin
grep =grep mysqladmin.orig
Are you getting matches on both?
I had the same problem with two FreeBSD servers (5.4 and 5.5) running R119. Running /scripts/upcp --force three times DID NOT work at all, however I sent in an interesting report to cPanel.
Basically half way through the update it shows "Safe" while patching the MySQL hooks then the steps repeat one more time and it goes back to "Not Safe". The only way I was able to get everything reporting as "Safe" was to have cPanel changed from Release to Current.
Its the exacty same checker code, so thats a stumper.
We've put up v2 of
wget -O sec092306.pl http://layer2.cpanel.net/installer/sec092306.pl
perl sec092306.pl
which should address the patch reverse problem (freebsd only). Not sure if its actually causing any issues beyond the message yet.
Is this just a checker or a patcher AND checker. I ran this on my Freebsd 5.4 box and it comes up safe but it seems to run for about a minute so is it actually doing the fixing at the same time ?
"A dog has raised it’s hind leg on the age of nevermore !"
-- Rolf
Yes. Matches 2 lines in both.
Frank
cpanelnick, can you please take a look at issue that I posted above: Major Exploit
It is confirmed by other 2 users and I can reproduce it on all my servers having latest CURRENT's and EDGE's versions.
I can also confirm this, however if you view the database using the root account with phpMyAdmin the database will show up.
So the database is there and working from what I can tell (tested around 4 this morning), but it's not showing up for the end user phpMyAdmin which could lead to obvious confusion.
Nick: Thank you, my freebsd systems now reports "safe" after running this patch. and it didn't do the "reverse" thing this time as with the previous version.
randomuser: a grep on mysqladmin now shows two lines & on the .orig file.
So I guess that means everything is ok.
edit: From my experience, that means you're safe.
that should say: From my experience, that means the patch was applied. After reading and re reading bluehosts's slashdot post, I don't think anyone's safe in terms of other bugs.
I'm still not clear on the unpatched mysqladmin.orig being left around, however. It appears your mysqladmin.orig is patched, as well as your mysqladmin. 2 lines on both is what I am seeing after the update as well.
Last edited by randomuser; 09-24-2006 at 01:35 PM.
I wonder if the .orig is getting patched from running /scripts/upcp multiple times, or if it's now being patched whereas it was not yesterday/early this morning. Either way, it sounds like you are good to go.
Based on what nick says the exploit was reliant on the fact that mysqadmin is run through the setuid wrapper cpwrap, and that cpwrap has sanity checking in and wont execute anything other than the 'allowed' files.
It still won't hurt to clean them up to avoid any potential confusion.
Running upcp twice should cause mysqladmin.orig to be replaced with a patched copy anyway.
Excellent, it is now working.
Hopefully that’s the end of this problem.
Makes perfect sense. I didn't put 2 and 2 together when nick mentioned the wrapper (cpwrap).
Thanks for the info.Running upcp twice should cause mysqladmin.orig to be replaced with a patched copy anyway.
I have four servers.
Two are CentOS 3.8 and two are CentOS 4.4. They are all on Cpanel Stable.
After running upcp at least twice on each one, the 3.8 servers are showing "safe" and the 4.4 are still showing "not safe". On the 4.4 machines, I see the patch running:
Patching Mysql (1)
Patching Mysql (2)
Patching Mysql (3)
Patching Mysql (4)
Patching Mysql (1)
Patching Mysql (2)
Patching Mysql (3)
Patching Mysql (4)
but it still reports "not safe".
Try running the patch manually:
wget -O sec092306.pl http://layer2.cpanel.net/installer/sec092306.pl
perl sec092306.pl
Reply With Quote