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
| ||
|
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
Powered by blists - more mailing lists