Hi, one of my clients, send me this today:

Code used:

<PRE>
<!--#exec cmd="uname -a" -->
<!--#exec cmd="cat /etc/passwd" -->
<!--#exec cmd="cat /etc/passwd | grep bash" -->
</PRE>

He says, that using SSI, he obtained this:

Linux rh-01-ar.wavenet.com.ar 2.4.2-2smp #1 SMP Sun Apr 8 20:21:34 EDT 2001
i686 unknown

root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:
daemon:x:2:2:daemon:/sbin:
adm:x:3:4:adm:/var/adm:
lp:x:4:7:lp:/var/spool/lpd:
sync:x:5:0:sync:/sbin:/bin/sync
shutdown:x:6:0:shutdown:/sbin:/sbin/shutdown
halt:x:7:0:halt:/sbin:/sbin/halt
mail:x:8:12:mail:/var/spool/mail:
news:x:9:13:news:/var/spool/news:
uucp:x:10:14:uucp:/var/spool/uucp:
operator:x:11:0:operator:/root:
games:x:12:100:games:/usr/games:
gopher:x:13:30:gopher:/usr/lib/gopher-data:


And the list continues, is this a problem of standard WHM/CPANEL configuration, or it is a configuration problem of my Linux redhat????

Any help, will be strongly appreciated.

Thanks,
Ricardo

the way I see it, it is and isent a problem. Its a problem because now someone can know the users and attempt to exploit it, its not a real problem unless they can also get the shadow file

If its possible to open the passwd file thne he can open any file.
What does cpanel have to do with this problem?

If its possible to open the passwd file thne he can open any file.

Actually this is not true; the passwd file is readable by all on most *nix systems, as many user-land programs need to read it. This is the primary reason most *nix's come with shadow passwords now.

Used to be, you obtain the passwd file, then run a cracker against the encrypted passwords locally. Now, only root can read /etc/shadow, where the passwords are stored, thus decreasing the risk.

However, just having a user list is bad. Plus, there are plenty of other world-readable files you don't necessarily want joe-hacker reading arbitrarily, so this is still bad. Just allowing joe-hacker to execute arbitrary commands on the system is bad...

Personally, I would disable the 'exec cgi' and 'exec cmd' SSI commands, allowing only includes. You can 'include' a CGI program in Apache, so the 'exec' ones present an unnecessary security risk.

PS - if a user on your system is the one doing this, it really isn't so much a security risk, as he could just as easily telnet or FTP in for this information, if he has that sort of access. In any case, giving someone a user account on a system opens that system up for that user, regardless of their access method.

Thanks for your information, i dont really like giving shell accounts to my clients, because accesing by ssh, they can read tons of files on my server, and i did not found a way to limiting the shell clients to a specific directory, does anybody knows how to limit that?

Thanks,
Ricardo

Ricardo, a veces, con un chmod 750 al /home funciona que no puedan listar al menos los directorios.
Pero vi, que con algunas box con WHM funciona y con otras te da un 403 en los sitios. y para ser honesto, no se cual es que lo causa.

Originally posted by Jm4n
If its possible to open the passwd file thne he can open any file.

Personally, I would disable the 'exec cgi' and 'exec cmd' SSI commands, allowing only includes. You can 'include' a CGI program in Apache, so the 'exec' ones present an unnecessary security risk.



How do you disable the 'exec cgi' and 'exec cmd' SSI commands?

To do this, you need to edit the /usr/local/apache/conf/access.conf file


For example, mine says....
======================
<Directory />

Options Indexes FollowSymLinks ExecCGI Includes
AllowOverride All

order allow,deny
allow from all

</Directory>
======================

The word "Includes" needs to be changed to "IncludesNOEXEC"

That is the part I know. What I don't know is if I also need to remove the "ExecCGI" and if so will maiking any of these changes affect Cpanel.

As people pointed out already, this has nothing to do with Cpanel. You can allow or disallow SSI or control it, as a user above mentioned, by altering your web server configuration. The /ec/passwd file is only useful to a system cracker for a few reasons -- to see what accounts are on the server to try and log into or to get the path to their home directory (and that's a given anyway most of the time). This file is not a threat at all really, even though every file like this can possibly give someone some type of information -- but nothing dangerous -- no file that is readable by every user on the system would be anything that contains anything serious.

Disabling SSI or certain SSI commands in the web server will only do so much. PHP, CGI and other methods work just as easily and to prevent user's from seeing other user's files, you'd have to remove things like PHP or run PHP as CGI (which takes the point out of PHP -- from a server administrator and server resources perspective anyway). With CGI, you can enforce SuEXEC (CGI wrapper) set certain permissions and ownership on files and user directories, chroot them, etc. and solve most of the real problems (like users opening up other user's PHP or CGI files with passwords (for MySQL DB's, email, etc.), but currently not with PHP, unless it's a CGI -- because how it's built.

This is also just the most obvious stuff, since user's can certainly make use of anything from email services, to cron jobs and other common tools and programs to gather information on the system -- but the one you mentioned only illustrates a common problem that can get worse -- the /etc/passwd file isn't a big deal, it's the fact that Cpanel servers make it difficult to use SuEXEC without errors on mailing losts and global scripts -- and even without that issue and without Cpanel, it still doesn't solve the PHP issue. There's a lot more to this and I would outline a few things, but if the fact they displayed the passwd file freaked you out this much, you don't want to know how bad it gets.

I don't know why but people started to point out their servers as what control panel they use.

As others have pointed out, disabling 'exec cgi' and 'exec cmd' only do so much. Personally, here's what I do:

- Keep permissions at the minimum. /etc only needs to be mode 0711. Quite a few other directories work just fine here. /home should be 0711, while each user's home directory should be 0750, with the 'group' owner being the user your webserver runs as (which should *NOT* be 'nobody', but 'apache' or something similar).

- Run suEXEC. CGIs run under the user's permission.

There are hundreds of other things that should be done to a server before allowing public access (SUID audit, security updates, replace Sendmail with Qmail, Bind with TinyDNS, and so on). Security is never a matter to be taken lightly, and I don't know of any system that's secure enough out of the box (IMHO), Even (especially?) RaQ and other CP-based systems...

Disabling SSH access to keep people from reading files on the server isn't the best approach. If it's world readable, and you give someone *any* level of access, they'll read the file if they want to. That's what file permissions are all about. But some files (/etc/passwd for example) do need to be readable by non-priveledged processes.

Just my 2 cents... I may be a bit overly-paranoid, but I take security very seriously...