[Phpmyadmin-devel] Re: [Phpmyadmin-users] bugs recently published on securityfocus are true?
Hi
Hi:I just want to now..if the recently published bugs at securityfocus are true..sometimes te people lie on this list...thats my question...--Visita
You seem to mean http://www.securityfocus.com/archive/1/325641 ? I just found that by searching the site. Sadly though, that person has never contacted the team about that issue.
As far as I can tell, that ImportDocSQL security issue was fixed since 2.5.0 - I haven't looked into the other XSS issues, as the original poster doesn't exactly specify them. Most actions need a valid 'session' to execute cross-site scripting, which is not *that* serious. Storing cookies unencrypted is documented in some of our RFE trackers, why we don't encrypt the data currently.
But our team should definitely take some time to write a follow-up/response to that item...
Regards, Garvin.
Hi
On Wednesday 18 of June 2003 21:37, Garvin Hicking wrote:
Hi:I just want to now..if the recently published bugs at securityfocus are true..sometimes te people lie on this list...thats my question...--Visita
You seem to mean http://www.securityfocus.com/archive/1/325641 ? I just found that by searching the site. Sadly though, that person has never contacted the team about that issue.
As far as I can tell, that ImportDocSQL security issue was fixed since
I can still browse in phpMyAdmin directory - this should be fixed.
2.5.0 - I haven't looked into the other XSS issues, as the original poster doesn't exactly specify them.
There are some examples, you can try:
http://sql/read_dump.php3?db=nonexistent&sql_query=%3Cscript%3Ewindow.al...
Most actions need a valid 'session' to execute cross-site scripting, which is not *that* serious.
Maybe even worse, you can include javascript that will read cookies with login and password...
Storing cookies unencrypted is documented in some of our RFE trackers, why we don't encrypt the data currently.
The proposed solution for this seems like a joke :-)
- Second: Use a partial / secure encoding for athentication tokens like RadiX64 ( not very secure but an attacker can think that is a more secure algorithm , obscurity ;-D ) .
But our team should definitely take some time to write a follow-up/response to that item...
If noobody else will take this, I will look at some problems tommorow.
What I don't understand why didn't first contact developpers as is usual in security problems...
btw: I just looked for something on the net (only .cz, searched by jyxo.cz) and I found several publicly accessible installations with config stored passwords :-))
Hi Michal!
I can still browse in phpMyAdmin directory - this should be fixed.
Yes, the default docpath should point to the docSQL directory. But only because the base directory for DocSQL uploads has no own subdirectory and thereby starts in the phpMyAdmin root. We should thereby change the main docpath from this:
$docpath = $DOCUMENT_ROOT . dirname($PHP_SELF) . '/' . eregi_replace('..*', '.', $docpath);
into this:
$docpath = $DOCUMENT_ROOT . dirname($PHP_SELF) . '/docSQL/' . eregi_replace('..*', '.', $docpath);
But this has some follow-up issues and needs some looking-into. I'm too tired to do this today, so next time :)
Most actions need a valid 'session' to execute cross-site scripting, which is not *that* serious.
Maybe even worse, you can include javascript that will read cookies with login and password...
I don't know if I understand that correctly: You can only read your own cookies with JavaScript, and you know that password already. Because when others open a PMA page without a login, they only access their empty cookie, right?
What I don't understand why didn't first contact developpers as is usual in security problems...
I generally dislike the style of the author's 'report'. :)
btw: I just looked for something on the net (only .cz, searched by jyxo.cz) and I found several publicly accessible installations with config stored passwords :-))
Yes, funny thing to do *g*
Regards, Garvin.
On Wednesday 18 of June 2003 23:07, Garvin Hicking wrote:
Most actions need a valid 'session' to execute cross-site scripting, which is not *that* serious.
Maybe even worse, you can include javascript that will read cookies with login and password...
I don't know if I understand that correctly: You can only read your own cookies with JavaScript, and you know that password already. Because when others open a PMA page without a login, they only access their empty cookie, right?
You know that somebody is using phpMyAdmin with cookie auth (maybe also http, I'm not sure about JS possibilities in this way) on some url, you make him somehow click on link you've created (it is not as hard as it seems for most users) and you've got his login/password...
Hi!
Having looked into the bug report a bit more, I noticed that my code definitely had a bug since the 2.5.0 release. There's a line reading "if ($content != '')" which should read "if ($content != 'none')" to effectively disable the printout of all files in the directory.
But the basic thing the SecurityFocus report falsely states is that you can print out any directory structure. But since 2.5.0 you cannot escape out of the base phpMyAdmin installation, so this is not true. I wonder whether we have to disable the output of files in the phpMyAdmin directory. Because when a user can access the db_details_importsql.php file, he has to have a valid user account and thereby should have FTP access anyways and can see all of the files. The files stored in the SQL file upload area are accessibly from the SQL query box, so no secret in that area as well. That's why I haven't committed the above mentioned replacement of the line. Do we want to hide any file the importer is ignoring?
Regarding the directory disclore issue: The author means that PHP will print out the 'missing variable in file /ddd/xxx/eee/bla.php' and thereby showing the path. I guess we can only hide that part by pointing out to not letting PHP print out errors on a webpage in production environments. On our side, we can only reduce the PHP error output, I guess?
Concerning the cookie storage, I'm not very experienced in this area. But patch item http://sourceforge.net/tracker/index.php?func=detail&aid=705727&grou... and http://sourceforge.net/tracker/index.php?func=detail&aid=564793&grou... (all covered by robbat) may give some hints on that?
For those XSS issues...well, I never got the clue out of how that can be dangerous. Maybe someone can enlighten me on that? I guess we can escape all HTML-elements from GET/POST variables by htmlentitieing them, don't we?
Regards, Garvin.
On Wednesday 18 of June 2003 22:14, Garvin Hicking wrote:
Regarding the directory disclore issue: The author means that PHP will print out the 'missing variable in file /ddd/xxx/eee/bla.php' and thereby showing the path. I guess we can only hide that part by pointing out to not letting PHP print out errors on a webpage in production environments. On our side, we can only reduce the PHP error output, I guess?
We should avoid any php error message, and end with our error when something needed is not defined (eg. db/table...)
One more look into report:
http://localhost/mysql/db_details_importdocsql.php? submit_show=true&do=import&docpath=../../../BOOT.ini
this never worked, did it?
http://localhost/mysql/db_details_importdocsql.php? submit_show=true&do=import&docpath=../../../BOOT.ini
this never worked, did it?
No. The file would only get docSQL parsed, no content of the file would get revealed.
Regards, Garvin.
Garvin Hicking wrote:
Hi
Hi:I just want to now..if the recently published bugs at securityfocus are true..sometimes te people lie on this list...thats my question...--Visita
You seem to mean http://www.securityfocus.com/archive/1/325641 ? I just found that by searching the site. Sadly though, that person has never contacted the team about that issue.
As far as I can tell, that ImportDocSQL security issue was fixed since 2.5.0 - I haven't looked into the other XSS issues, as the original poster doesn't exactly specify them. Most actions need a valid 'session' to execute cross-site scripting, which is not *that* serious. Storing cookies unencrypted is documented in some of our RFE trackers, why we don't encrypt the data currently.
But our team should definitely take some time to write a follow-up/response to that item...
Yes. Maybe a link on phpmyadmin.net that points to a new FAQ entry about this security report? This way, we don't clutter the main site.
Marc Delisle
On 19.06.2003 08:49, Marc Delisle wrote:
Yes. Maybe a link on phpmyadmin.net that points to a new FAQ entry about this security report? This way, we don't clutter the main site.
Link should be okay... At least users will know, we know about it :-)
I'm sorry I won't surely have time to look at that till next week...
-
Garvin Hicking -
Marc Delisle -
Michal Cihar -
Michal Cihar