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  PHC 
Open Source and information security mailing list archives
Hash Suite for Android: free password hash cracker in your pocket
[<prev] [next>] [day] [month] [year] [list]
Date: Wed, 19 Dec 2007 11:14:50 +0100
From: "Maciej GÄ…siorowski" <>
To: bugtraq <>
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
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.


Powered by blists - more mailing lists