4 Aug
2011
4 Aug
'11
3:10 p.m.
Hi Tyron
your changes include unprotected (does not require user being logged in
and no token check) file file_echo.php, which allows to download
arbitrary data. This could be easily used by attacker to pretend data
is coming from safe location (where phpMyAdmin is running), while it
would actually come from attacker.
I've removed defining of PMA_MINUMUM_COMMON (which does skip all the
checks) from this file. As you already seem to pass token with the
request, no other change should be needed, but please take care of such
dangerous code in future.
--
Michal Čihař | http://cihar.com | http://blog.cihar.com
4 Aug
4 Aug
3:47 p.m.
On Thu, Aug 4, 2011 at 3:10 PM, Michal Čihař <michal(a)cihar.com> wrote:
Hi Tyron
your changes include unprotected (does not require user being logged in
and no token check) file file_echo.php, which allows to download
arbitrary data. This could be easily used by attacker to pretend data
is coming from safe location (where phpMyAdmin is running), while it
would actually come from attacker.
I've removed defining of PMA_MINUMUM_COMMON (which does skip all the
checks) from this file. As you already seem to pass token with the
request, no other change should be needed, but please take care of such
dangerous code in future.
From what I can see, the token is being checked
independent of what
value PMA_MINUMUM_COMMON is set to. Looking at the other parts
of
common.inc.php I also cannot see any security related functions not
being executed if PMA_MINUMUM_COMMON is set. Also defining
PMA_MINUMUM_COMMON I had added in the very first version of the file
(when it was named chart_export.php), and from what I remember you
overlooked that file there too.
And I just tested that on the gsoc-tyron demo. It returns 'Invalid
request' if no valid token is set.
Apart from that, please elaborate, how can an attacker do harm to a
user with my changes? And how is the user protected with
PMA_MINUMUM_COMMON removed? Looking at common.inc.php, I fail to find
any possible attack vector.
My added file echo for the monitor config forces the file name
'monitor.cfg', so even if the token is not checked, and an attacker is
be able to trick a user to download a file no harm can be made, since
.cfg Files are not executable or viewable by standard programs.
And the import-echo I added uses $_FILES which can only be set with an
actual file upload. I wouldn't know how that could be exploited by an
attacker.
--
Michal Čihař | http://cihar.com | http://blog.cihar.com
------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
4:17 p.m.
Hi
Dne Thu, 4 Aug 2011 15:47:59 +0300
Tyron Madlener <tyronx(a)gmail.com> napsal(a):
From what I can see, the token is being checked
independent of what
value PMA_MINUMUM_COMMON is set to. Looking at the other parts of
common.inc.php I also cannot see any security related functions not
being executed if PMA_MINUMUM_COMMON is set. Also defining
PMA_MINUMUM_COMMON I had added in the very first version of the file
(when it was named chart_export.php), and from what I remember you
overlooked that file there too.
And I just tested that on the gsoc-tyron demo. It returns 'Invalid
request' if no valid token is set.
Apart from that, please elaborate, how can an attacker do harm to a
user with my changes? And how is the user protected with
PMA_MINUMUM_COMMON removed? Looking at common.inc.php, I fail to find
any possible attack vector.
Defining PMA_MINUMUM_COMMON skips MySQL authentication, so it might be
easier to exploit any possible issue, but you seem to be right that
token is checked.
My added file echo for the monitor config forces the
file name
'monitor.cfg', so even if the token is not checked, and an attacker is
be able to trick a user to download a file no harm can be made, since
.cfg Files are not executable or viewable by standard programs.
This one looks pretty safe.
And the import-echo I added uses $_FILES which can
only be set with an
actual file upload. I wouldn't know how that could be exploited by an
attacker.
This one definitely allows XSS (though still protected by token, so
pretty harmless unless there is some other issue). Is the echo service
for HTML really needed?
--
Michal Čihař | http://cihar.com | http://blog.cihar.com
4:47 p.m.
Forgot again to write to pma-dev list
On Thu, Aug 4, 2011 at 4:17 PM, Michal Čihař <michal(a)cihar.com> wrote:
The only way I could see how this can be used for an XSS attack
(whether protected by token or not) is when the user himself uploads a
malicious chart config file.
We could counteract this by adding a notice "Do not use chart config
files from untrusted sources!" at the chart config import dialog.
And/Or I verify if the file really is pure json on the server side,
before echoing it back. I guess doing 'echo
json_encode(json_decode(file_get_contents(...)))' should do the trick.
[Edit:] Actually verify the json wont help. One could still hide html
code within a string.
Hi
Dne Thu, 4 Aug 2011 15:47:59 +0300
Tyron Madlener <tyronx(a)gmail.com> napsal(a):
Do you have an example how the skipping of the MySQL authentication
could be abused?
From what I can see, the token is being checked
independent of what
value PMA_MINUMUM_COMMON is set to. Looking at the other parts of
common.inc.php I also cannot see any security related functions not
being executed if PMA_MINUMUM_COMMON is set. Also defining
PMA_MINUMUM_COMMON I had added in the very first version of the file
(when it was named chart_export.php), and from what I remember you
overlooked that file there too.
And I just tested that on the gsoc-tyron demo. It returns 'Invalid
request' if no valid token is set.
Apart from that, please elaborate, how can an attacker do harm to a
user with my changes? And how is the user protected with
PMA_MINUMUM_COMMON removed? Looking at common.inc.php, I fail to find
any possible attack vector.
Defining PMA_MINUMUM_COMMON skips MySQL authentication, so it might be
easier to exploit any possible issue, but you seem to be right that
token is checked. My added file echo for the monitor config forces
the file name
'monitor.cfg', so even if the token is not checked, and an attacker is
be able to trick a user to download a file no harm can be made, since
.cfg Files are not executable or viewable by standard programs.
This one looks pretty safe.
And the import-echo I added uses $_FILES which
can only be set with an
actual file upload. I wouldn't know how that could be exploited by an
attacker.
This one definitely allows XSS (though still protected by token, so
pretty harmless unless there is some other issue). Is the echo service for HTML really needed?
It is used for the chart config import part of the monitor. There you
can upload a config file, which is within an iframe. Once submitted
and echo'd back my js code reads the config and applies it to the
monitor.
It might be possible to read local files with a HTML5 feature, or
maybe flash, but certainly will not work in all cases.
--
Michal Čihař | http://cihar.com | http://blog.cihar.com
8:37 p.m.
Just a question about the code :
$extension = $allowed[$_REQUEST['type']];
$valid_match = '/^[^\n\r]*\.' . $extension . '$/';
if (! preg_match($valid_match, $_REQUEST['filename'])) {
if (! preg_match('/^[^\n\r]*$/', $_REQUEST['filename'])) {
/* Add extension */
$filename = 'dowload.' . $extension;
} else {
/* Filename is unsafe, discard it */
$filename = $_REQUEST['filename'] . '.' . $extension;
}
1) Shouldn't the two comments in the then/else be switched?
2) 'dowload', is this a typo?
Kind regards,
Dieter
2011/8/4 Tyron Madlener <tyronx(a)gmail.com>om>:
Forgot again to write to pma-dev list
On Thu, Aug 4, 2011 at 4:17 PM, Michal Čihař <michal(a)cihar.com> wrote:
The only way I could see how this can be used for an XSS attack
(whether protected by token or not) is when the user himself uploads a
malicious chart config file.
We could counteract this by adding a notice "Do not use chart config
files from untrusted sources!" at the chart config import dialog.
And/Or I verify if the file really is pure json on the server side,
before echoing it back. I guess doing 'echo
json_encode(json_decode(file_get_contents(...)))' should do the trick.
[Edit:] Actually verify the json wont help. One could still hide html
code within a string.
--
Groetjes,
Dieter Adriaenssens
Hi
Dne Thu, 4 Aug 2011 15:47:59 +0300
Tyron Madlener <tyronx(a)gmail.com> napsal(a):
Do you have an example how the skipping of the MySQL authentication
could be abused?
From what I can see, the token is being checked
independent of what
value PMA_MINUMUM_COMMON is set to. Looking at the other parts of
common.inc.php I also cannot see any security related functions not
being executed if PMA_MINUMUM_COMMON is set. Also defining
PMA_MINUMUM_COMMON I had added in the very first version of the file
(when it was named chart_export.php), and from what I remember you
overlooked that file there too.
And I just tested that on the gsoc-tyron demo. It returns 'Invalid
request' if no valid token is set.
Apart from that, please elaborate, how can an attacker do harm to a
user with my changes? And how is the user protected with
PMA_MINUMUM_COMMON removed? Looking at common.inc.php, I fail to find
any possible attack vector.
Defining PMA_MINUMUM_COMMON skips MySQL authentication, so it might be
easier to exploit any possible issue, but you seem to be right that
token is checked. My added file echo for the monitor config forces
the file name
'monitor.cfg', so even if the token is not checked, and an attacker is
be able to trick a user to download a file no harm can be made, since
.cfg Files are not executable or viewable by standard programs.
This one looks pretty safe.
And the import-echo I added uses $_FILES which
can only be set with an
actual file upload. I wouldn't know how that could be exploited by an
attacker.
This one definitely allows XSS (though still protected by token, so
pretty harmless unless there is some other issue). Is the echo service for HTML really needed?
It is used for the chart config import part of the monitor. There you
can upload a config file, which is within an iframe. Once submitted
and echo'd back my js code reads the config and applies it to the
monitor.
It might be possible to read local files with a HTML5 feature, or
maybe flash, but certainly will not work in all cases.
--
Michal Čihař | http://cihar.com | http://blog.cihar.com
------------------------------------------------------------------------------
BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA
The must-attend event for mobile developers. Connect with experts.
Get tools for creating Super Apps. See the latest technologies.
Sessions, hands-on labs, demos & much more. Register early & save!
http://p.sf.net/sfu/rim-blackberry-1
_______________________________________________
Phpmyadmin-devel mailing list
Phpmyadmin-devel(a)lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/phpmyadmin-devel
8:45 p.m.
Hi
Dne Thu, 4 Aug 2011 19:37:43 +0200
Dieter Adriaenssens <dieter.adriaenssens(a)gmail.com> napsal(a):
Just a question about the code :
$extension = $allowed[$_REQUEST['type']];
$valid_match = '/^[^\n\r]*\.' . $extension . '$/';
if (! preg_match($valid_match, $_REQUEST['filename'])) {
if (! preg_match('/^[^\n\r]*$/', $_REQUEST['filename'])) {
/* Add extension */
$filename = 'dowload.' . $extension;
} else {
/* Filename is unsafe, discard it */
$filename = $_REQUEST['filename'] . '.' . $extension;
}
1) Shouldn't the two comments in the then/else be switched?
2) 'dowload', is this a typo?
Both fixed, thanks for spotting it.
--
Michal Čihař | http://cihar.com | http://phpmyadmin.cz
8:51 p.m.
Hi
Dne Thu, 4 Aug 2011 16:47:58 +0300
Tyron Madlener <tyronx(a)gmail.com> napsal(a):
The only way I could see how this can be used for an XSS attack
(whether protected by token or not) is when the user himself uploads a
malicious chart config file.
It can be posted from completely different place and not intentionally
by user. Though you also should correctly handle situation when user
chooses absolutely wrong file to load.
I still don't see why you need to pass HTML here, the configuration is
json, isn't it?
--
Michal Čihař | http://cihar.com | http://phpmyadmin.cz
Forgot again to write to pma-dev list
On Thu, Aug 4, 2011 at 4:17 PM, Michal Čihař <michal(a)cihar.com> wrote:
This is just limiting access to file_echo.php to users who are allowed
to use phpMyAdmin (and thus have login to MySQL). I see no reason
having publicly available echo service in phpMyAdmin.
Hi
Dne Thu, 4 Aug 2011 15:47:59 +0300
Tyron Madlener <tyronx(a)gmail.com> napsal(a):
Do you have an example how the skipping of the MySQL authentication
could be abused? From what I can see, the token is being checked
independent of what
value PMA_MINUMUM_COMMON is set to. Looking at the other parts of
common.inc.php I also cannot see any security related functions not
being executed if PMA_MINUMUM_COMMON is set. Also defining
PMA_MINUMUM_COMMON I had added in the very first version of the file
(when it was named chart_export.php), and from what I remember you
overlooked that file there too.
And I just tested that on the gsoc-tyron demo. It returns 'Invalid
request' if no valid token is set.
Apart from that, please elaborate, how can an attacker do harm to a
user with my changes? And how is the user protected with
PMA_MINUMUM_COMMON removed? Looking at common.inc.php, I fail to find
any possible attack vector.
Defining PMA_MINUMUM_COMMON skips MySQL authentication, so it might be
easier to exploit any possible issue, but you seem to be right that
token is checked. My added file echo for the monitor config forces the
file name
'monitor.cfg', so even if the token is not checked, and an attacker is
be able to trick a user to download a file no harm can be made, since
.cfg Files are not executable or viewable by standard programs.
This one looks pretty safe.
And the import-echo I added uses $_FILES which
can only be set with an
actual file upload. I wouldn't know how that could be exploited by an
attacker.
This one definitely allows XSS (though still protected by token, so
pretty harmless unless there is some other issue). We could counteract this by adding a notice "Do
not use chart config
files from untrusted sources!" at the chart config import dialog.
And/Or I verify if the file really is pure json on the server side,
before echoing it back. I guess doing 'echo
json_encode(json_decode(file_get_contents(...)))' should do the trick.
[Edit:] Actually verify the json wont help. One could still hide html
code within a string.
If you don't need any HTML code inside, htmlspecialchars will help
here. Also if you set content type to JSON, browser will not process it
as HTML.
Is the echo
service for HTML really needed?
It is used for the chart config import part of the monitor. There you
can upload a config file, which is within an iframe. Once submitted
and echo'd back my js code reads the config and applies it to the
monitor.
It might be possible to read local files with a HTML5 feature, or
maybe flash, but certainly will not work in all cases.
4792
days inactive
4792
days old
6 comments
3 participants
participants (3)
-
Dieter Adriaenssens -
Michal Čihař -
Tyron Madlener