full-disclosure - phpMyAdmin XSS Vulnerabilities, Transversal Directory Attack , Information Encoding Weakness and Path Disclosures

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <5.1.0.14.2.20030618191239.0636a250@yoshimo.webtechs.idg.nl>
From: msopacua at idg.nl (Melvyn Sopacua)
Subject: phpMyAdmin XSS Vulnerabilities,
  Transversal Directory Attack , Information Encoding Weakness and Path
  Disclosures

At 18:18 6/18/2003, Lorenzo Hernandez Garcia-Hierro wrote:

>phpMyAdmin XSS Vulnerabilities, Transversal Directory Attack , Information
>Encoding Weakness and Path Disclosures

[ ... ]

>The affected files of the XSS attack ( Cross Site Scripting ) and Path
>Disclosure are:
>
>  - sql.php / sql.php3   - Path Disclosure & XSS-

First of all - how are path disclosures even relevant?
phpMyAdmin is a tool to manage the database that drives the backend of
your website. Generally - you know which path it is in and access to
phpMyAdmin is restricted. Allowing access to such an application without
authentication is retarded.

Secondly - at least in version 2.3.3pl1 (which you list as vulnerable),
these path disclosures do not occur, because:

1) config.inc.php is loaded from libraries/common.lib.php
2) libraries/common.lib.php sets $old_error_reporting before loading the
    config file:
     $old_error_reporting = error_reporting(0);
     include($cfgfile_to_load);
3) config.inc.php only sets display_errors to 1 if $old_error_reporting is
    unset:

if (!isset($old_error_reporting)) {
     error_reporting(E_ALL);
     @ini_set('display_errors', '1');
     // This comment and the next line insert by me to see if there's any
     // envocation of this block.
     error_log("Display errors is: " . 
var_export(ini_get('display_errors'), TRUE));
}

At least in the following files, this is the case:
$ find . -type f -name "*.php" -print | xargs egrep -l \
"(require|include)\('./libraries/common.lib.php'" | sort -u

./chk_rel.php
./db_details_common.php
./db_details_qbe.php
./header.inc.php
./header_printview.inc.php
./index.php
./ldi_check.php
./left.php
./main.php
./pdf_pages.php
./pdf_schema.php
./phpinfo.php
./read_dump.php
./sql.php
./tbl_dump.php
./tbl_indexes.php
./tbl_move_copy.php
./tbl_properties_common.php
./tbl_relation.php
./tbl_rename.php
./tbl_replace.php
./tbl_select.php
./user_details.php
./user_password.php

This thus means, that the path disclosures are generated by a php
configuration which runs on display_errors being '1' by admin configuration.
That is a configuration 'choice', which doesn't have anything to do with
the phpMyAdmin package. Running display_errors 1 in production is a moronisism.

[ ... ]

>------------------
>| INFORMATION    |
>|   ENCODING     |
>|    WEAKNESS    |
>------------------
>
>phpMyAdmin doesn't use any encoding type like BASE64/RadiX64 , only saves
>the user data ( username and password too ) in plain text without any
>encoding.

And the difference being? That only morons that can't decode base64 will
regard this as 'encrypted'.

Secondly - there are other auth types which you can use depending on your
configuration requirements and environment. What good does encoding cookies
do on localhost anyways and even if you would use a one-way hash, anybody
being able to access the cookies can log in.

So also here - it is not a security issue, but a configuration choice.

Met vriendelijke groeten / With kind regards,

Webmaster IDG.nl
Melvyn Sopacua

<@JE> Hosting: $5 per month. Domain name: $15, your site being down twice a 
week: Priceless.
http://www.bash.org/?42663