Hi,
Recently I've read about your competitor on http://milw0rm.com/exploits/8880. After this lecture I started to think about how these things are handled in VM/WM/UM/CM (that's not totally true, I started much earlier). I tried almost all panels available on the market for managing hosting environment to finally stick with Virtualmin. IMHO it's the most flexible and secure solution from all available at the moment. However I would like to hear from the vendor how these specific flaws applys to xM? I know you're busy now guys but maybe you'll find some time to reply to this post and make me and all the rest sleep well;-)
According to http://milw0rm.com/exploits/8880:
#1 uid/gid reuse
Does xM prevents uid/gid reuse? Does it make sure that nothing will be left in the system after the user who is going to be removed?
#2 unprivileged port use
Is there any mechanism which is responsible for "reserving" xM ports and forbids other applications from listen on these ports? I would love to see it, otherwise:
Run this script as unprivilaged user via browser:
<?php
$address = '0.0.0.0';
$port = 10000;
$sock = socket_create(AF_INET, SOCK_STREAM, 0);
while (!socket_bind($sock, $address, $port)) {
;
}
socket_listen($sock);
sleep(30);
socket_close($sock);
?>
Restart the webmin server:
# /usr/local/etc/rc.d/webmin.sh restart
Webmin can't be restarted and it fails with the following message:
# tail /var/webmin/miniserv.error
[19/Jun/2009:09:35:53 +0200] miniserv.pl started
Failed to bind to port 10000 : Address already in use
Could not listen on any ports at /usr/local/webmin/miniserv.pl line 447.
#3 default passwords
How many such default passwords are there in xM (or its module/script/component) if any? Does xM force somehow admin to change these default password(s)? Isn't reasonable to limit root access to xM only from 127.0.0.1 out-of-the-box?
#4 useradd string in the process list
Definitely it depands on operating system how new accounts are created in it. However I must ask. Is there any possibility that unprivilaged user can see plain text password passed as parameter to pw/useradd etc. via e.g. ps command (where seeing other users processes is possible)?
#5 XSS
Do you guys take care about appropriate input data validation to prevent XSS and CSRF attacks? The "referers_none=1" feature seems to be ok and useful but many may want to disable it for any reason and what then?
https://127.0.0.1:10000/left.cgi?mode=eaqq&dom='>alert(document.cookie);
https://127.0.0.1:10000/virtual-server/link.cgi/%3Ci%3E%3Cscript%3Ealert(document.cookie);%3C/script%3E
Unfortunately there are more of them.
#6 remotely create partially user controlled file names and directories. Locally append uncontrolled data to any file
Unknown. Unfortunately I haven't time to reasearch this one.
#7,#8,#10,#13,#17,#18,#22,#23 local users can take control of any file or directory
Generally above numbers reffers to the same type of attack so I grouped them as one. Ufortunately VM/WM is prone to the symlink attacks. However successfull attack depends on user access to the vulnerable modules/features. Detailed information won't be disclosed here because severity of this attack is very high. Details were send to Joe and Jamie.
#9 local users can overwrite any file on the box
After some research it seems that "Install Scripts" feature doesn't allow overwriting symlinked files with the following error:
Failed to install script : FormMail or some other program already exists at the selected location.
Call Stack Trace
File Line Function
/usr/local/webmin/virtual-server/script_install.cgi 53 WebminCore::error
(eval 52) 6 (eval)
/usr/local/webmin/miniserv.pl 2143 (eval)
/usr/local/webmin/miniserv.pl 751 miniserv::handle_request
#11,#14 metachar injection, local command execution as root
Well, I must sux, haven't found any;-) However I would recommend you to audit all system(), execute_command(), safe_process_exec(), foreign_call() etc. calls.
#12 web stats world readable password hashes
Unknown. Unfortunately I haven't time to reasearch this one.
#15 remotely block any - or every - IP addr in hosts.deny
How it's handled in xM? Is it possible to shoot yourself in the foot? Are users blocked on IP or login basis?
#16 remote CPU and mem usage DoS
From what I see this one doesn't apply to xM.
#19,#20,21 file manager, view and edit any file
After some research it seems that VM/WM Java File Manager hasn't got these problems.
Other security related issues not coverd above were found, and information about them were send to Joe and Jamie.
Best regards,
Filip Palian
Below are my comments on the types of security flaws you listed above :
1) UIDs may be re-used if a domain is deleted and a new one created. However, all files belonging to that old domain should be cleaned up .. if not, that's a bug.
2) This shouldn't ever be an issue, as Webmin doesn't get restarted during normal use. But there is nothing stopping port 10000 from being used by another application. You can change the port to something below 1024 to provide additional protection against this though.
3) There are no default passwords. The only initial password is whatever the system's root password is.
4) Passwords should never be visible in the process list. When users are added, this is done by writing directly to /etc/shadow
5) Referer checking is the main defence against XSS attacks, and is on by default. We don't recommend turning it off.
6) I'm still auditing the code for this kind of issue..
9) Script installs are generally done with the permissions of the domain owner, so shouldn't be able to overwrite other files.
11) I've been careful to use quotameta to defend against this, but if you find a case where it is possible, please let me know!
12) These should be in a directory outside the web root.
15) Webmin has its own IP access control files, settable globally or on a per-user basis. I guess you could lock yourself out if you really tried, but there is some protection against this.
16) This may be an issue. Virtualmin has the ability to apply process and memory limits on a per-domain basis, but if they are not enabled a fork bomb or other DOS attack may be possible.
''