Customising mysql.php debug?

Posted: Mon May 03, 2004 1:00 pm

Is there a way to edit /db/mysql.php so as to not disclose an error path? I've been running sql injection and xss attacks against one of my test sites using PHP-Nuke 7.2 with chatserv's patches and hackattempt.php. Everything failed against the site except one attack, which I won't post here.

I decided to try djmaze's union/uni0n fix (http://nukecops.com/postt27474.html) and that stopped it, but I got an sql error message that exposed the server path. I would like to prevent that from displaying on a production site.

My test sites mimick my production sites; same hosts, versions of apache/php/mysql, directory structure, ect..., so it's not critical to me in debugging to have the error messages display on production sites.

Site Admin/Owner Joined: Aug 27, 2002 Posts: 17088

In almost all cases if you do something like this you can nullify all displayed MySQL messages

Code:

$result = @mysql_query($sql) or die();

Or, actually,

Code:

$result = @mysql_query($sql);

That should give you enough to go on. If not, get back to me as MySQL is one of my forte's. You could, of course, do a redirect to index.php or display a message like die('no way') or whatever. Also, would you please PM me the attack that got through?

Posted: Mon May 03, 2004 2:10 pm

Thank you! Very Happy

I'll send you a PM on the exploit & info on my test site setup.

Posted: Mon May 03, 2004 3:53 pm

LS, I believe if you apply chatserv's 7.2 fixes (replace the modules/Private_Messages/index.php) that should stop it. I can't reproduce it Confused

Do you need to be logged in or do you try that as a visitor?

Posted: Mon May 03, 2004 5:00 pm

I wasn't logged in at the time. I didn't try the exploit with my usual browser, I was using Windows IE 6, if it makes a difference. Thanks for checking so quickly, and letting me know your results. As I'm writing this, I downloaded index.php from the private messages folder on my test site and ran a comparison between it and chatserv's fixed version and then cross-compared both of those to a fresh copy from 7.2 original. I wanted to see if I screwed up somehow and didn't upload the right index.php. The one I'm using matches chatserv's fixed version except for my modifications.

The two modifications I have in privates messages index.php are adding new colours to the forum posts with additional 'L_COLOR' lines, and email the full text of private messages if a user chooses to be notified on new private messages arrives. For the last, after line 1398 I added these two lines.

Code:

SENDER_USERNAME' => $userdata['username'],


                                        'PM_MESSAGE' => str_replace("\'", "''", $privmsg_message),

Could that have affected it in any way?

Posted: Mon May 03, 2004 5:11 pm

The simplest way to find out is to rename yours and just use Chat's. Did it stop it or not?

Posted: Mon May 03, 2004 5:37 pm

No, I just upload the original 7.2 mysql.php and replaced my index.php in private messages with chatserv's. I cleared the browser cache, deleted cookies, and destroyed the session to be try to be sure I didn't have anything that could be tapped into to give a false positive on the exploit. I still got in. I'm going to take a look through everything that could have an effect on Private Messages to see if I can find how this is getting through on my test site. It has to be something in my files there, if it's not getting through on other sites.

Thanks again for the information on nullifying the sql messages. Here is how I implemented it in djmaze's fix.

Code:

$query = eregi_replace('UNION','UNI0N', $query); 


$this->query_result = @mysql_query($query, $this->db_connect_id) or die('Improper request.');

This hid the debug message and path disclosure.

Posted: Mon May 03, 2004 5:42 pm

The only problem with his method is that I (and many others) presently am writing real applications using UNION. It is much faster than the 1.3.x MySQL work arounds. The real issue is the passing of UNION in variables that shouldn't have them. That's what needs to be addressed. Cleansing input Wink

Posted: Mon May 03, 2004 5:55 pm

I try never to rest on temporary solutions. Wink

I'll keep testing and looking for better mousetraps. I look forward to seeing what scripts you develop. Smile