| 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
| ||
|
Date: Wed, 19 Dec 2007 11:14:50 +0100 From: "Maciej Gąsiorowski" <gonsiore@...il.com> To: bugtraq <bugtraq@...urityfocus.com> Subject: smbfs and apache+php source code disclosure Because of different filename handling in Posix and Windows there is an issue with resolving filenames with a backslash "\" character appended on a windows share. Consider you have a windows share mounted on a linux box with a php script on it - let's say info.php. Executing find info.php and find info.php\\ results with the same file - info.php (same with cat info.php\\). When using this share to serve PHP scripts with apache (from a linux box) you can use it to display php script content directly to your browser. In apache, scripts are mapped to engines using the AddType directive with file extension specified. Text files with extensions not handled by any AddType are considered as plain text. When visiting http://linuxbox/winshare/info.php - you get you script executed. When visiting http://linuxbox/winshare/info.php\ or http://linuxbox/winshare/info.php%5C - you get your script content displayed, revealing any details like database passwords etc. The reason is obvious, smbfs finds file info.php\, but apache doesn't have the extension php\ mapped to php engine. The same should apply to perl scripts with mod_perl. I don't know if this is something new, maybe it is some configuration mistake. I have just confirmed it on a freshly installed debian etch box with all security updates applied using default settings of apache and smbfs. Regards Maciej
Powered by blists - more mailing lists