Hi Brian
I do not think the plain output or XSS is the biggest problem. A bigger
problem is remote execution of arbitrary php code.
I think there are few ways to make this a big problem.
Make the transformation point to ../../../somepath/somefile
and then let that file actually contain <?php somenastycode();
Then you have remote execution on the host that have this phpmyadmin
installed.
The only problem is that the attacker need to have access to the host to
place a file somewhere. So this essentially just give an attacker
permission of the webserver instead of the user. It can be seen as some
kind of escalation though.
But maybe this is possible with some upload services that place things on
/tmp for some time.
Another way is to make somepath/somefile point to something already
installed on the system. This depends havily on what is already installed
on the system.
Maybe it is possible to trigger some futher problem if somepath/somefile
point to a binary that contain too much data. No clue is that can be an
issue.
I find it a little tricky to exploit this but I see some possibilities.
My conclusion however is about the same as you. I do not think many are
using the transformations so I think we can safely remove that.
Another option is to make a check for .. in the filename, because I think
we can safely assume an attacher do not have write permission in the
plugins directory, or can that be a problem too?
Best regards
// Ola
On Tue, 18 Dec 2018 at 07:41, Brian May <br...@linuxpenguins.xyz> wrote:
> Ok, so as far as I can tell, looking at the version in wheezy, the
> problem is that we load source files like so (there are two occurances
> in the code that I can see, both very similar):
>
> include_once $include_file;
>
> Where include_file comes from:
>
> $file = $mime_map[$meta->name]['transformation'];
> $include_file = 'libraries/plugins/transformations/' . $file;
>
> The problem being $mime_map is loaded from the database, and considered
> untrusted, I think this is the source here:
>
> PMA_getMIME($this->__get('db'), $this->__get('table'))
>
> I don't fully understand this function yet, but I think it is safe to
> say it generates filenames based on untrusted data from the database.
>
> I am not sure what an attacker can do with include_once, but my guess is
> that if you try to load a file that doesn't have a "<?php" marker, it
> will add the entire contents to the HTML being output to HTTP -
> e.g. send it to the attacker.
>
> However an attacker would need to be able to login and have write access
> to a database first before carrying out an attack.
>
> The upstream solution seems to be to completely remove the
> "include_once" statement and rely on the "autoloader" to load things. As
> far as I can tell, this creates a "autoload.php" file at install time
> which automatically lists all dependancies to be loaded without relying
> on untrusted inputs.
>
> Unfortunately, I don't think the wheezy version of phpmyadmin has this
> autoloader support... So if we blindly manually applied the same patch,
> I suspect we would end up disabling support transformations.
>
> There is a reference to autoload.php in CVE-2016-2039.patch, but that is
> documentation only.
>
> Here is the upstream documentation on transformations:
> https://docs.phpmyadmin.net/en/qa_4_2/transformations.html
>
> I am wondering how important it is that we continue to support
> transformations? I suspect not many users of phpmyadmin 4.2.12 would
> actually use or want them... If so the easiest fix may be to remove
> these lines.
> --
> Brian May <br...@linuxpenguins.xyz>
> https://linuxpenguins.xyz/brian/
>
>
--
--- Inguza Technology AB --- MSc in Information Technology ----
/ o...@inguza.com Folkebogatan 26 \
| o...@debian.org 654 68 KARLSTAD |
| http://inguza.com/ Mobile: +46 (0)70-332 1551 |
\ gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9 /
---------------------------------------------------------------
