Forum

Hi Hugo,

I have discovered a rather serious problem after placing a .Hiawatha file in the root (/) of my server (and I mean not the website root). Each site gave a 403 error after placing the Hiawatha file containing:

<code>AccessList = deny all</code>

I'm happy when it works recursive in directories, but this is a bit too exaggerated



Hiawatha version: 7.4
Operating System: Fortress Linux

It's not a 'serious problem', it's how Hiawatha was designed. If you don't want any user to have access to the system's root directory, Hiawatha will block access to that directory and all subdirectories.

There is no need to place a .hiawatha file in the system's root directory. Assuming that you don't have any WebsiteRoot setting pointing to that directory, there is no way that Hiawatha allows visitors to access that directory.

Hi Hugo,

Its clear to me now. So you say it's a 'feature' of Hiawatha?

I just simulated a server exploit by placing a symbolic link in the websiteroot to /etc. Now I can read and/or write every system configuration file (worldwide readable and/or writable files, and without using the FL Security System, chroot, grsec and containerization features of Fortress Linux).

And yes, after adding .hiawatha (containing "deny all") to my /etc directory it avoids any writing, editing and listing in /etc. Would it not be wiser to deny any reading/writing/listing (outside the webroot) by default?

Luckily this exploit is normaly prevented by the Fortress Linux Security system, but this could be an serious exploit possibility for every default Ubuntu, Debian, Suse, Slackware, Fedora etc. installation.

I though that preventing any possible (stack) exploitation should be the default behaviour of a secure webserver?

Hiawatha won't follow symlinks unless you add "FollowSymlinks = yes" to your Hiawatha configuration. So, users with only FTP access to upload their website and FollowSymlinks set to 'no' (=default) will not be able to make /etc world readable via Hiawatha.

Users with shell access can simply bypass any read restrictions outside the webroot by simply copying all the files in from such directory to a location inside the webroot directory. Restricting read access outside the webroot directory only gives a false sense of security.

Another reason why restricting users from reading files outside the webroot directory only gives false sense of security is that this can also be bypassed by using a CGI script which reads those files.

I choose to make this easy and clear, so system administrators are 'forced' to think this more through instead of making all sorts of wrong assumptions.

All options in the hiawatha.conf are (explicity) set to "FollowSymlinks = no".

You're right about those possible symlinks exploits. These types of exploits are unfortunatly the 'default' for Linux. I had a flamewar with Torvalds and other kernel developers about this 'feature' a few months ago. Your the developer of Hiawatha, so I leave it up to you.

Do you maybe know where I can find this behaviour in the sourcecode so I can write a 'patch' for it?

If there weren't so many "sitting ducks" servers and coffee drinking, keyboard bashing, ubunturangutans, I'll be out work

Are you saying that you said FollowSymlinks to 'no', but Hiawatha still showed a file via a symlink?

I hope you understand that I take security very seriously. But in my opinion, security should also be clear and transparent to avoid making mistakes. That's why I chose for an easy and simple approach in how Hiawatha handles .hiawatha files. But, I'm always open to new and good ideas, so if you a btter way of handling .hiawatha files, please share it with me.

Whether a symlink should be followed is decided in target.c (grep for 'follow_symlinks'). The reading of .hiawatha files in done in hiawatha.c, starting at line 1034.

Yes it did. Tested it three times. I could send you the config file by mail if you want (it's unsafe to publish it here), but I think you can reproduce it yourself. Just make a link from your website homedir to /etc with "FollowSymlinks=no".

I know you take security seriously just by looking at your source code. It's all about balacing between user friendlyness and security.

Tomorrow, I will put up a small list of my personal suggestions that could be easily deployed into Hiawatha. I've collected a lot of interesting information since the Fortress Linux server is under constant attack by scriptkiddies, spammers and 'hackers'.

What file where you testing? A CGI? Note that CGI scripts which are executed via FastCGI are not checked for symlinks, because Hiawatha is not able to look for symlinks on remote FastCGI servers. I've added this to the manual page.

Well I use UseFastCGI = php5-cgi and ExecuteCGI = yes with only .php files, no real CGI files here.
Hmm, Does this mean that fast-cgi is way to bypass Hiawatha rules, even if it's just a Linux symbolic link (ln -s), html or php?

I have posted my suggestions for hiawatha on my server since it's detected as "spam" on your forum. (doesn't re-capatcha work for you?)

http://www.fortresslinux.org/hiawatha-suggestions.txt


I'm going to test something...

Disabling fast-cgi completely doesn't make any difference. I still have access to /etc through the softlink.

Has the softlink been created by root?

Yes, I know that it doesn't work if you link /etc as another user without root priveleges. But if the symlink is created by root, it still ignores the "deny all" rule in the /etc/.hiawatha file and any other file access restriction in the hiawatha config file.

This means that if the hiawatha server is runned as root (yes it's s t u p i d, but many users do this) or if the admin failed by creating a symlink as root, an attacker could have easy access through the system just with his browser.

What do you think of the suggestions?

I've tested it myself: placed a "AccessList = deny all" in /etc/.hiawatha and created a symlink owned by root in a website. Access was denied (403 Forbidden). Are you sure it's not the browser cache that is fooling you?

Unless you change the code, Hiawatha will refuse to run as root. So, I don't agree that "many users do this".

About the suggestions: I'll get back to you about this as soon as possible. But, thanks for the feedback!

Ok, Now I remember it again. I confused it with another app, sorry.

What I did found out that placing a .hiawatha file in / works recursively even on the homedir (/flsrv) of Hiawatha. But this is not the case for /etc. if you follow the symbolic link. You have to place a .hiawatha file in /etc for a 403.

Just let me know if you want more info and take your time.

My answers to your suggestions: http://www.hiawatha-webserver.org/hiawatha-suggestions.txt

Hi Hugo, thank you for your answers.

I just hoped that you want to include support for all of this in Hiawatha.
Good thing that all these suggestion are already implemented in the Palatinux IDS which now provides a security framwork around Hiawatha

I'm just going to write a good manual, patch, config and tools to setup a secure version of HW in Fortress Linux with this new information.

Thank you very much for you're time.