Discussion in 'Developers' Forum' started by Piega, May 7, 2006.
thank you for posting the information about the exploit.
First, i think this exploit will not affect any ISPConfig installation.
The Exploit tries to reach the file session.inc.php in a browser.
This is impossible because the file is not inside the web root.
The web root in every ISPConfig installation is:
The session.inc.php is located in:
You can try this with your ISPCOnfig installation:
You will get an 404 page not found error.
Nevertheless, we will add some code to the session.inc.php file
to prevent remote code inclusions even when the file is copied
inside the web root.
If you feel insecure until we release the update, you may add this
line as second line to the session.inc.php file:
Please send security related informations about ISPConfig first to
dev [at] ispconfig [dot] org and give the development team some time
to review them and relaese a patch if nescessary before you post them
to the forum.
I am going to agree with you guys on this one. I dont see how this exploit could work. I just played around with it to see if I can get anything. But, I could not get into my servers using this exploit. This is mostly because in the recent versions the filters are good and this file isn't in server space.
In sum, I studied and tested this exploit and I am going to say it doesnt work on the recent versions.
P.S. Falko or Till, message me if you want some of my friends to try to this exploit.
We've tested it, it doesn't work.
Since everything works from index.php, wouldn't be easier to add a simple
define( "_VALID_ISPC", 1 );
to the index.php and then every module or file etc would have something like
defined( '_VALID_ISPC' ) or die( 'Direct Access to this location is not allowed.' );
would this kind is protection help? I should stop direct access to files and only allow it included from index.php
That's wrong, not everything works from index.php. It's a frameset, and in the frameset other files are loaded.
ok fairys muff, but then in that case that direct accessed file would have the same tests because they really should be doing it anyway.
So only files that are dirctly accessed are allowed and any others are all blocked if they weren't loaded from index.php or any of the other directly accessed frameset files.
All files that shall not be called directly are not in the web root, so calling them is not possible. Also register_globals is off in ISPConfig, which also prevents the attack described in the exploit. Nevertheless I agree with you that securing these files in the PHP source is a good idea and I will add some "direct call" detection code.
I've added already some additional tests to session.inc.php
Separate names with a comma.