[Phpmyadmin-devel] Problems with Garvin's Patches

[robbat2 at orbis-terrarum.net]

On Tue, Feb 25, 2003 at 03:03:55PM +0100, Garvin Hicking wrote:
> > Looking at the HTML for that page, I see you are passing filenames for
> > the field_transformation variable. Take out the .inc.php3 part and go
> > and double check that code for security holes, as it may be susceptible
> > to data injection.
> I got a grip of that problem on the other side. I don't do any input validation, but
> rely on the dropdown-input. Because when evaluation the columns in browse mode,
> there's a check to only allow a transformation, if it fits certain rules
> (<mimetype>_<subtype>__<transformation>.inc.php3), and only in the
> libraries/transformations directory. Because data is passed via a select field I
> surely think we could trust user data there.
This is where a malicous input can be made, and it's not as difficult as
a custom POST/GET even, just copying the HTML page, and changing a few
URLS.

> Warning shouldn't be an issue, because you can only trick false data
> in by using your own POST/GET-requests, so in this case the user
> already knows, he is hacking into our application and may get false
> results.  But even if he gets an invalid transform into the table, it
> simply isn't used in the output.
In this case, evil user is a malicuos user that has access to a database
or table already, and wants to root the system.
evil user adds a tranform that reads a piece of data from the server as
a root user, somewhere else on the file system, say /tmp (using the
docSQL bug). the fix can conform to your naming requirements or not.
Now evil user makes his own table, and puts in a value of '/etc/shadow'
or any file he wants.  he then gets the exact transform he wants to run
on the '/etc/shadow' string. He's now got your entire /etc/shadow file,
with your passwords or worse.

> Any objections to this approach, which is already coded this way and thereby takes
> no coding-time to keep it that way (*broad hint* ;-))
The fix shouldn't be hard. Just remove the .inc.php3 part off the data
that is passed to the browser, and add it back in when the data comes
back, along with making sure all the input data is properly escaped to
prevent the user getting out of the specific directory.

> > Here is an idea for the quickbox, give it three mini-tabs:
> Maybe it is a bit complicated to make a three-part query window, so I'll see what
> can be done there. Worst thing would be to have input-buttons as TAB-icons instead
> of text links, or to rely on javascript for that, again.
Just seperate the code for the different parts of the tab window into
different files maybe? or is the bug JS related?

> > behaviour:
> > on login and logout or a large number of rows existing, run a query on
> How to you get to know, if a user "logs in" or "logs out", without session
> management? You mean, everytime a user makes a call to main.php3?
logout - the logout link in the left frame
login - on load of the frameset 

-- 
Robin Hugh Johnson
E-Mail     : robbat2 at orbis-terrarum.net
Home Page  : http://www.orbis-terrarum.net/?l=people.robbat2
ICQ#       : 30269588 or 41961639
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 232 bytes
Desc: not available
URL: <http://lists.phpmyadmin.net/pipermail/developers/attachments/20030225/3bb1542d/attachment.sig>