New feature SymLinksifOwnerMatch

Please see also this (while waiting for a response from the virtualmin folks)

https://www.virtualmin.com/node/24267

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

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 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:

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.

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

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

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.

@eric I don't see 3.97 at http://software.virtualmin.com/gpl/universal/?