|
Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com |
Re: [suse-security] Solved (?): mysql_connect: Access denied
From: by way of Thomas Roth (thomas.roth
physik.tu-darmstadt.de)
Date: Fri Oct 24 2003 - 13:22:18 CDT
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Hi Steffen,
I don't quite understand all you wrote.
On Friday 24 October 2003 09:03, Steffen Dettmer wrote:
> > 1) I found that the PHP-script was actually read: supplying
> > some special characters instead of the said parameters to
> > mysql_connect() resulted in a parse error at that line of the
> > script.
>
> How could you manipulate your script to use special characters in
> mysql_connect? By changing the sources?
Yes, I wrote the script in the first place, why shouldn't I be able to put
something like
mysql_connect(

)
into it? Doesn't make sense, of course, but produces a parse error which in
turn tells me that I edited the right script and the right
connect()-statement: the most primitive way of debugging your programs: put
write()-statements whereever you think there might be problems ;-)
>Of course you have to
> make sure that this isn't possible by passing malformed data on
> the external interfaces. I think there are conditions where
> variables can be taken from the CGI environment somewhat
> automatically. I think that is a big pitfall as you might find
> yourself in using not-sanitized data from untrusted source
> (browser).
Well, I at least hope the said script is not directly accessible to the
outside, short of cracking the system and the like... There is a html-form to
put in data, processsing the data is done by some other script, checking
these data, and so on.
> > 2) However, sensible values seemed never to be used for the
> > connection attempt. (PASSWORD: NO in the error message)
>
> You cannot process sensible values with PHP, except if you have a
> dedicated (logical) server for each user - at least when using
> mod_php instead of CGI mode. The reason is the mod_ stuff -
> performant but insecure: every script runs in the same
> environment as the same user. PHP may try to put some security
> from top-level, but this cannot work well because of the
> complexity.
Oh, sorry, I did not mean something that sophisticated, but
mysql_connect(

) = nonsense
mysql_connect($host,$name,$pass) = sensible
> > 3)The trick was to switch off the sql.safe_mode in php.ini.
> > (And that is not connected to the setting of php safe_mode )
>
> Yep, another drawback of mod_php is the global configuration :)
> Again, if you have one script (-system), then it's no problem of
> course. Why did you need to set sql.safe_mode off? What does this
> mean exactly? I would expect that you want sql.safe_mode plus a
> possibility to connect (however, this seems to be *really*
> secure :-)).
After having found that the problem was with sql.safe_mode, it was of course
easy to google for it.There seems to be basically only one explication:
http://www.n3rd.net/ZendInformationCenter/ZendServerCenter/sql_safe_mode.htm
Synopsis: If the SQL Safe Mode option is enabled the MySQL and Ingres
extensions will ignore the supplied host, user and password information
and will use only the default ones.
It's also nice to read: (if I only had done it some weeks ago ;-<)
http://www.phpbuilder.com/mail/php-install/2001091/0131.php
The php-manual hasn't improved since - maybe people where then distracted
from reading that posting by something else...
Greetings
Thomas
--
Check the headers for your unsubscription address
For additional commands, e-mail: suse-security-help
suse.com
Security-related bug reports go to security
suse.de, not here
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]