View Single Post
Old 7th February 2006, 11:25
till till is offline
Super Moderator
Join Date: Apr 2005
Location: Lüneburg, Germany
Posts: 35,509
Thanks: 815
Thanked 5,269 Times in 4,130 Posts

Originally Posted by webstergd
ehh better but still has a lot of holes.

I agree with Till on all his security points and he is a much better php programmer then I am. However, I do not feel his solution will patch all the holes in this statement.

for example:
if a users submits .../../../ he will still be able to transverse the directory. The system matches two .. not three. Called triple-dot vulnerablility.

If a hacker sends the command /var/www/.../../../../../etc/passwd you will have the password file.

Next example is that if hacker uses multiple alternate encodings for text in order to bypass the filters the filters will not flag.

/var/www/%25%25/%25%23/%25%25 ...... using URL
/var/www/%C0AE/%C0AE/%C0AF ......... using unicode

ok, I am tired so i will stop with the examples...

basicly my fear is that it is almost impossible to properly search for phrases that are not allowed. Using different encoding tricks or really just playing around you could eventully find a loophole. I am a firm believer on stating what a function can do verses what I function cannot do.

if I have time later tonight I will think of possible ways to do this that could solve your problem and make the program easier. Might not be as efficient as my original idea but should be just as secure and a hell of a lot easier to program.

I dont think that your examples will trick the filters i mentioned above:

If you have a hard coded path "/var/www/web[id]/cms" where [id] is checked / converted with the intval command or an regex and then it is passed to my filters, i dont see how this can be exploited easily. To the filters:

1) The double dot filter filters also three and mor dots when you search with stristr(...) function.

2) The filter for unallowed chars must list escape sequences too, like "%#" and others. I mentioned in my post only a few characters.

My solution was to use the solution you posted with web[id] as first "firewall" and then double check the string for malicious chars as second check before it is used in the exec statement.

The problem that i see is when we use only your type of path checking without a second "firewall", where do we get the string "/var/www/web[id]/joomla" from when the joomla package comes from an external package builder? The path string must be included in the package. If we want to have third party packages we either have to allow only "thrusted" packages where a developer from ISPConfig inspects every revision for malicoius code or we have to try to make even the installation from third party packages as secure as possible?
Till Brehm
Get ISPConfig support and the ISPConfig 3 manual from
Reply With Quote