I don't know how serious this is but when a website is created a symlink to the "icon" directory for fancy indexing is made with permissions 777 and owned by user root group root.

When logged to the file manager (as an virtual server adminstrator) I was able to make a copy - this copy was made with the logged user instead of root. (this could be used after the original file was rename to something else).

The issue is that because of the 777 permissions of the symlink I was then able to rename the root owned symlink to something like httpd.conf and change the symlink pointer values to the assumed destination of the new filename value for the symlink.

The symlink always stays to the owner root unless the user decides to change it.

I didn't want to change it to the passwd file in the etc folder because I didn't want to spend hours correcting my system if I messed up something.

I did browse to the etc folder while under root login and made copies of a couple of different conf files and then pointed the link to them. When you bring up the link in a browser window the file is displayed. It will even display whole directories by changing it to point to simply "/var" or "/etc"

If I change the owner of the symlink file from root, then I am quite sure apache will not let me view the destination of the symlink file if it points to a root file with proper permissions.

The followsymlinks directive has something to do with this and I think it is used for the suexec. This "icon" symlink is in the public_html directory so is the follow symlinks directory only placed in per directory option section due to fancy indexes?

Still, I sure don't know what to think about having someone be able to just peruse the file system in this manner and look at config files, etc.

Plus... what about ssl logins via scp? The user is not jailed. They can look around the system. They can't change files unless they happen to have the wrong permissions but many files need to have read access for scripts and other programs.

You see... if someone logs in under scp and can change any symlink under root in directories that can be accessable to the internet it could cause problems because they can read/look at many files on the system under scp. Then decide "hey, I'll just change it to this one". Then call it in their browser.

Can I change the owner of this "icon" symlink? Is this really not an issue?

These two issues are bugging me and would like some feedback. Thanks.

Hey John,

I'm not seeing a security issue here. As far as I can tell, everything behaves as it is supposed to:

sh-3.1$ ln -s /etc/shadow icon
ln: creating symbolic link `icon/shadow' to `/etc/shadow': Permission denied
sh-3.1$ chown domain:domain icon/
chown: changing ownership of `icon/': Operation not permitted
sh-3.1$ ln -s /etc/passwd icon
ln: creating symbolic link `icon/passwd' to `/etc/passwd': Permission denied
sh-3.1$ ln -s /etc/httpd/httpd.conf icon
ln: creating symbolic link `icon/httpd.conf' to `/etc/httpd/httpd.conf': Permission denied

And in the file manager, I get:

You're not allowed to access /etc

When I try to do something nasty. I can copy it all I want within my home directory...but that doesn't matter.

If you're seeing some problem with the way things are actually behaving, give me the steps to reproduce the problem.

I should point out that just because the link can be screwed with, doesn't mean the file it points to can be screwed with:

sh-3.1$ mv icon httpd.conf
sh-3.1$ touch httpd.conf/temp
touch: cannot touch `httpd.conf/temp': Permission denied

And it doesn't matter what's it's called--it's still not going to let you break something (as far as I can tell).

I was then able to rename the root owned symlink to something like httpd.conf and change the symlink pointer values to the assumed destination of the new filename value for the symlink.

Actually, this bit sounds worrisome. But I don't see how you would have done what you're describing (and no amount of trying achieves what you've described for me). What exactly did you do to accomplish this?

Hello Joe,

It does not look like you were trying it the way I described or tried to describe.

You see... I spotted a symlink that was owned by someone else in my public_html folder. That someone else just happened to be "root". So... that file/symlink is the one I changed. (you're examples look as if you were trying to make new links instead of just change the values of one that already exists). I easily changed it with the file manager "info" link. As long as I did not change the owner of the file and left the permissions to 777; but only changed the pointer value to another file I wanted to see (e.g. "/etc/httpd/conf/httpd.conf") - I was then able to view/read entire file contents.

All I had to do was open another browser window and open it to the URL of the symlink... then the apache "followsymlinks" directive would allow the "changed" symlink to open "/etc/httpd/conf/httpd.conf" into a browser window.

I did not try it under ssh or scp.... but I don't see why it would not work just the same and also give them easier advantage so far as file execution.

Hey John,

Hehehe...That is interesting.

But I still don't think we're looking at a security issue. For example. I used the info button to point icon to /etc/shadow:

-sh-3.1$ ls -l
total 20
lrwxrwxrwx 1 domain domain 11 Mar 13 12:03 icon -> /etc/shadow
-rw-r--r-- 1 domain domain 698 Mar 3 16:37 index.html
-rw-r--r-- 1 domain domain 402 Mar 2 20:48 market.html
drwxr-xr-x 2 domain domain 4096 Mar 1 03:18 stats
-rw-r--r-- 1 domain domain 399 Mar 2 20:53 whatwedo.html

I've pointed to the most sensitive file on the system. Now, let's get at it somehow:

-sh-3.1$ cat icon
cat: icon: Permission denied

When I use Apache, with symlinks on, I get:

Forbidden

You don't have permission to access /icon on this server.
Apache/2.2.3 (Fedora) Server at domain.tld Port 80

Now, it's worth noting that httpd.conf, used in your example, is accessible in this way to Apache. But, it's available to Apache in a lot of other ways. PHP, when not run under mod_fcgid or as a CGI as the domain account owner, can see those files. SSI can see those files. Any mod_perl, mod_python, or mod_ruby, instance scripts can see those files.

My point about any file that isn't locked down by default on a UNIX system is that they simply don't contain sensitive information.

As far as execution goes, when I try to setuid:

-sh-3.1$ chmod o+sx icon
chmod: changing permissions of `icon': Operation not permitted

Anyway, a chroot jail isn't all that difficult to achieve--technically, it's not a major problem, as there are a few tools out there to generate the chroot with relative ease--but, and this is a huge but: chrooting ssh breaks several major security features of ssh, because it has to spawn it's serving process as root. It's all a balance...but having a full-feature chroot ssh environment (with programming languages and such) is pretty scary to me from a security standpoint. Users seeing httpd.conf isn't so scary (and they could still see httpd.conf, even with the chroot, because Apache wouldn't be subject to the chroot, and couldn't be in a shared hosting environment).

I do think there's probably some room for improvement, at least in the sense that we'd all like to see some additional protections for things that are sensitive. Things like SSL certificate keys--they can be locked down now, but I suspect there are still some ways someone dedicated to mischief could locate and view them. But the existence of a symbolic link isn't a contributing factor to this problem, even one owned by root. Though, if it'll make you feel better, we could make it owned by the domain account holder--but then they would have just one more way to easily break their AWStats reports. They could not only move the file, they could also delete it. ;-)

Oh, yeah, I believe if you disable AWStats in your server templates, they won't get the icon link at all.

Anyway, I believe the tools that allow real granular control of users and their actions are coming along nicely on Fedora and Red Hat Enterprise. SELinux is still a nightmare to configure and use, but the management tools are getting better, and we have begun adding bits of management for SELinux to Virtualmin. On Solaris, there's POSIX ACLs, which I think are actually nicer to use than SELinux (though less powerful)...we'll probably also be adding some support for that, as the number of large hosts using Virtualmin on Solaris increases.

Hello Joe,

There are so many things I could think of just spending a few minutes.

I mentioned... You can change the symlink to point to a directory... for instance... "/etc"

Then... you can browse at your leisure a great part of the entire etc folder. Including many files and folders in the webmin folder.

You can change the symlink to point to /etc/webmin/uninstall.sh - and it'll uninstall webmin. I don't want someone hosting with me to uninstall webmin...

You can change it to point to /usr/bin/userpasswd - won't that let someone change the root password or the password of any user they want? The permissions of this file are 755

There are a myriad of things people could dream up by perusing the file system and even if we don't let them ssh they can still peruse it with their web browser as I have demonstrated.

There are way too many files that an inexperienced user like me can keep up with... I don't know half this stuff... I really have no idea how to button down file permissions and file ownership in a way that some mean guy would not be able to mess with... and when a guy upgrades, add a new program, etc... it might just add a file that has the right permissions for a root 777 symlink to do a wah-too-ee to it.

I don't think letting people look all over your system is wise... especially if you're a guy like me and don't even know for sure what you're letting them see.

I am quite sure with my little bit of experience I could wreak havoc with a system if they let me have a hosted account and I had the infamous symlink I was pointing out to you... but there are other 777 root symlinks on the standard fedora system... I've seen some before just browsing from the command console in gnome. So... If a person knows them, they could easily browse to them and use them in ssh.

What I mean is... It'd be real smart to make this "icon" symlink install.sh with better ownership and permissions. And also figure out a way where people cannot look at all the files in ssh - so that if they are wise to a root 777 symlink or other file owned by root that has 777 - that they cannot find a way to get at it when using ssh/scp.

Hey John,

Now I see why you're so worried! You're thinking that symlinks work differently than they actually do.

All of the nefarious things you're suggesting (except the things that aren't really nefarious) simply can't be done. So let's run through them, one at a time:

I mentioned... You can change the symlink to point to a directory... for instance... "/etc"

Then... you can browse at your leisure a great part of the entire etc folder. Including many files and folders in the webmin folder.

This symbolic link is not what enables this. This is possible whether that symbolic link exists or not. But not the /etc/webmin directory (or any other sensitive directory or files):

[[virtualmin@www investors]]$ ls /etc/webmin
ls: /etc/webmin: Permission denied

[[virtualmin@www investors]]$ ls icon
ls: icon: Permission denied

You can change the symlink to point to /etc/webmin/uninstall.sh - and it'll uninstall webmin. I don't want someone hosting with me to uninstall webmin...

Nope:

[[virtualmin@www public_html]]$ ./icon/uninstall.sh
/bin/sh: ./icon/uninstall.sh: Permission denied

Apache with symlinks on can't do it either...just get a forbidden.

You can change it to point to /usr/bin/userpasswd - won't that let someone change the root password or the password of any user they want? The permissions of this file are 755

[[virtualmin@www public_html]]$ ./icon root
icon: Only root can specify a user name.

Again, a symbolic link doesn't do what you're thinking it does. It's just a link to a file--the file it links to is what determines who can look at, run, etc. that file.

There are a myriad of things people could dream up by perusing the file system and even if we don't let them ssh they can still peruse it with their web browser as I have demonstrated.

The symbolic link is not what allows this to occur. Apache has access to significant portions of the filesystem--regardless of this symbolic link. The good news is that it doesn't have access to anything that it can screw up.

I understand your desire to hide things, if you're not sure what things are sensitive, but the symbolic link is entirely harmless. UNIX permissions are quite a bit stronger than you think, and a system that you can "see" is not at any more particular risk than one you can't. As long as your services and kernel are kept up to date, your users aren't going to be able to cause too much trouble. They don't have write access to anything that would allow them to cause trouble.

I am quite sure with my little bit of experience I could wreak havoc with a system if they let me have a hosted account and I had the infamous symlink I was pointing out to you... but there are other 777 root symlinks on the standard fedora system... I've seen some before just browsing from the command console in gnome. So... If a person knows them, they could easily browse to them and use them in ssh.

I'm quite confident you couldn't. Write me privately, and I'll create an account for you on one of our boxes, and we'll report back here after you break the system or find some interesting secrets about our ongoing projects. ;-)

What I mean is... It'd be real smart to make this "icon" symlink install.sh with better ownership and permissions. And also figure out a way where people cannot look at all the files in ssh - so that if they are wise to a root 777 symlink or other file owned by root that has 777 - that they cannot find a way to get at it when using ssh/scp.

install.sh doesn't create that symlink. It's created by the AWStats module (and only used for AWStats). Regardless, it doesn't matter who owns the symlink. And, interestingly enough, the permissions are not what determines who can change it.

For example:

[[virtualmin@www public_html]]$ cd /etc/httpd/conf
[[virtualmin@www conf]]$ ls -l
total 128
-rw-r--r-- 1 root root 55091 Mar 11 00:42 httpd.conf
-rw-r--r-- 1 root root 12958 Oct 24 15:37 magic
lrwxrwxrwx 1 root root 37 Jan 29 21:53 Makefile -> ../../../usr/share/ssl/certs/Makefile
[[virtualmin@www conf]]$ mv Makefile Notmakefile
mv: cannot move `Makefile' to `Notmakefile': Permission denied

The containing directory determines who can fiddle with a symbolic link. Pretty weird, huh? But, it means you don't need to worry about the rest of the links on the filesystem, since nobody can do anything nasty with them. (Since I'm having trouble convincing you that no one can do anything nasty with the icon symlink, I'll move on to others!) ;-)

There are certainly ways to unwittingly expose a system to exploit...but this symbolic link is not one of them.

go to

http://www.sethford.com/icon/webmin/

go to

http://www.sethford.com/icon

once at these locations it is just a matter of file permission as to whether or not you can read or execute and I do not see why it would be different only better for execute if I was in ssh as the bash would do better than apache... but if I give someone the ability to change their apache directive I think they can decide how to excute from the command line of their browser.

I don't really want to mess up anyone's system but will give it a try if you want. I just don't want people messing up mine... You can too go into the /etc/webmin folder on mine and look at a number of files and folders.

I just logged in as the user sethford and typed /etc/webmin/uninstall.sh and it said... Are you sure you want to uninstall webmin?

your system must be buttoned up better than mine or we are doing two entirely different things.

sethford is the user name of a hosted account and that's all it is...

please remember... all I did was install basic server fedora and run install.sh.

you are right... I was thinking that the symlink ran as the user that owned the symlink... I tried setting the umask and could not. however the mere fact that someone who I do not want to be able to look at what files and folders reside in the etc folder and merely change that symlink and look in there is distressing.

Maybe just having the follow symlinks directive is what needs to be taken away. maybe with the follow sysmlinks directive they can do what I am saying regardless of the icon symlink... like they could make their own.

It is how I found this file...

uninstall.sh in the /etc/webmin folder... and it has file permissions of 755 and I can too run it when logging in with ssh. So, what I am trying to say is that letting someone look around the file system and try/test files to see what happens is not a real bright idea.

You think letting someone go to an url like those above is unworrisome security practice?

I am sorry Joe, I know that the install.sh did not make the symlink. I mentioned it so that maybe you'd force the install.sh to change it.

I did not change the permissions or any of the file ownership of the webmin and virtualmin files in the etc folder. Yet on my system some competitor hosting firm could sneak in as a new user and uninstall webmin at the very least.

when I do a ls /etc/webmin (when logged under ssh as a non priviledged user or as you can see by going to the browser link above) I get a listing of files/folders.

I really am trying to figure this stuff out and thank you for your patience.

ok... I'm turning it off... I had three people already just going here and going there in my etc and etc/webmin folders.

they looked at the yum.conf the repos.d they tried to get into the securetty folder and many others.

they saw my webmin/virtual-server/config and last config. They saw my virutalmin-license. they saw a bunch of stuff they have no business seeing and i'm turning it off now.