[Phpmyadmin-devel] Re: [Phpmyadmin-users] bugs recently published on securityfocus are true?
18 Jun
2003
18 Jun
'03
3:39 p.m.
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.
18 Jun
18 Jun
4:13 p.m.
Hi
On Wednesday 18 of June 2003 21:37, Garvin Hicking wrote:
I can still browse in phpMyAdmin directory - this should be fixed.
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.
There are some examples, you can try:
http://sql/read_dump.php3?db=nonexistent&sql_query=%3Cscript%3Ewindow.a…
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 :-))
--
Regards
Michal Cihar
nijel at users dot sourceforge dot net
http://cihar.liten.cz
5:08 p.m.
New subject: [Phpmyadmin-devel] Re: [Phpmyadmin-users] bugs recently published on securityfocus are true?
Hi Michal!
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?
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... 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.
5:32 p.m.
New subject: [Phpmyadmin-devel] Re: [Phpmyadmin-users] bugs recently published on securityfocus are true?
On Wednesday 18 of June 2003 23:07, Garvin Hicking wrote:
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...
--
Regards
Michal Cihar
nijel at users dot sourceforge dot net
http://cihar.liten.cz
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...
4:16 p.m.
New subject: [Phpmyadmin-devel] Re: [Phpmyadmin-users] bugs recently published on securityfocusare true?
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&gro…
and
http://sourceforge.net/tracker/index.php?func=detail&aid=564793&gro…
(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.
4:24 p.m.
New subject: [Phpmyadmin-devel] Re: [Phpmyadmin-users] bugs recently published on securityfocusare true?
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...)
--
Regards
Michal Cihar
nijel at users dot sourceforge dot net
http://cihar.liten.cz
4:26 p.m.
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?
--
Regards
Michal Cihar
nijel at users dot sourceforge dot net
http://cihar.liten.cz
5:09 p.m.
New subject: [Phpmyadmin-devel] Re: [Phpmyadmin-users] bugs recently published on securityfocus are true?
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.
19 Jun
19 Jun
8:51 a.m.
New subject: [Phpmyadmin-devel] Re: [Phpmyadmin-users] bugs recently published on securityfocus
Garvin Hicking wrote:
Hi
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
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... 
9:08 a.m.
New subject: [Phpmyadmin-devel] Re: [Phpmyadmin-users] bugs recently published on securityfocus
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...
--
Regards
Michal Cihar
http://cihar.liten.cz
7763
days inactive
7764
days old
9 comments
4 participants
participants (4)
-
Garvin Hicking -
Marc Delisle -
Michal Cihar -
Michal Cihar