• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 372
  • Last Modified:

Perl script in Linux allows users to spy on each other

I just did a little test and it scared me to death.  If I make a simple perl script that does "cat /etc/passwd" I can see a list of all the users on my system.  Of course I'm running this script from an unprivlidged user's cgi-bin and printing the output to the browser.  This also allows me to see their home directories.

If I make another script that will "ls -l" their directories, this would allow one user to browse the contents of another user's directories and see a listing of all their files.  This is horribly insecure and although I haven't tested, I suspect you could use a few more simple commands to gain access to scripts they may have uploaded to their cgi-bin.  In that case, a user on my system could exploit programming errors made by another user.

Is there anything I can do to stop this from happening???  I just want to prevent users on my server from creating scripts that will allow them to snoop around the system.
0
Donboy
Asked:
Donboy
  • 4
  • 3
  • 2
  • +1
2 Solutions
 
steveb3210Commented:
Hello,

The excute bit on a directory is what allows/disallows users/groups/world from listing its contents

if you do "chmod 700 <dir>"

Note:  If a user knows the file name they can still access the file even if the directory is chmod a-x

Best Regards,
Stephen


0
 
steveb3210Commented:
Two more things

If a file is set 600 then noone but the user can read/write it
If a file is set 700 then nonee but the user can read/write/execute it

Check out "man chmod" for more infomration

0
 
Rich RumbleSecurity SamuraiCommented:
While you can easily cat /etc/passwd for user names, it's a bit harder to get /etc/shadow where the salted passwords are.
You can use a number of ways to read or list files, ls, cat, du, dir, locate, which .... on and on
chmod and chown are very similar to the way windows NTFS permissions work, and you can keep even keep locate and which (cron jobs that index the FS) from viewing the files/folders.
here are some other tips
http://www.puschitz.com/SecuringLinux.shtml
http://www.securityfocus.com/infocus/1419]

As far as seeing their home dir's from the apache server, you can turn that setting off with ease
http://httpd.apache.org/docs/misc/FAQ.html#forbidden
and
<IfModule mod_userdir.c>
    #
    # UserDir is disabled by default since it can confirm the presence
    # of a username on the system (depending on home directory
    # permissions).
    #
    UserDir disable  <---- this turns off home dirs

Also look at .htaccess
http://httpd.apache.org/docs/misc/security_tips.html
-rich
0
What Security Threats Are We Predicting for 2018?

Cryptocurrency, IoT botnets, MFA, and more! Hackers are already planning their next big attacks for 2018. Learn what you might face, and how to defend against it with our 2018 security predictions.

 
ahoffmannCommented:
> Is there anything I can do to stop this from happening???
if you mean just "cat /etc/passwd", then short answer is no.
Long answer is that you have to eithert chroot each user and give him his own /etc, or you need to use ACLs to allow only special commands (hard work)

> I just want to prevent users on my server from creating scripts that will allow them to snoop around the system.
What users are you refering to? login users or users using URL with/on their web servers on your system?

Restricting login users is done with chroot (as said above).
A quick&dirty solution is to restrict acces to their home directories like:
  chown user:group ~user
  chmod 4700 ~user

For web server users we need more details.
0
 
DonboyAuthor Commented:
The users I mean are those logging into FTP and uploading CGI scripts that can be used to generate directory listings.  Not sure what details you want/need, but please let me know and I'll be happy to elaborate.

My FTP server uses actual system users (/etc/passwd & /etc/shadow) to authenticate.  I am also running apache with suexec.  Not sure what else you'd like to know.
0
 
ahoffmannCommented:
> My FTP server uses actual system users (/etc/passwd & /etc/shadow) to authenticate
see my chown/chmod suggestion

> .. apache with suexec ..
good.
Does this mean that you have one web server (no virtual hosts) which is used by all users and these users can start their own CGIs like:  http://www......./~user/cgi-bin/user.cgi
0
 
DonboyAuthor Commented:
Well, I have many virtual hosts.  Each user has their own cgi-bin under their home directories.  For example...

/home/user1/www/html/cgi-bin
/home/user2/www/html/cgi-bin
(etc)
0
 
ahoffmannCommented:
oops, made a mistake: my suggestion
  chmod 4700 ~user
should be
  chmod 2700 ~user

if you're using virtual hosts, then all CGIs are running as the same user, except you have configured suexec
I highly recommend suexec here 'cause otherwise every user can read/change all other user's data

I'd use permissions (for each user) as follows:
  chown -R user:group ~user
  find ~user -type d -exec chmod 2700 {} \;
  find ~user -type f -exec chmod 500 {} \;

then configure suexec for each user i nhttpd.conf
0
 
DonboyAuthor Commented:
Hmmm, those permissions you recommendded didn't work very well.  I wasn't able to view any of the pages on my site when I used them.  Changing the files to 544 seemed to work better, as it allowed me to view them at least.  540 would not even work. Using that,  I'd get an "403 access forbidden" error from apache when trying to view the pages.

I think the reason is, when the user isn't running any CGI scipts, like if a user is just trying to view the index.html page of a site, apache is serving this request as the "apache" user.  So the files on the server must be world-readable to include the apache user.
0
 
ahoffmannCommented:
then the user running httpd (probably apache) must be in the same group as al you users and the directories and files to be served by htpd must be og that group and permission 440
0

Featured Post

What Security Threats Are We Predicting for 2018?

Cryptocurrency, IoT botnets, MFA, and more! Hackers are already planning their next big attacks for 2018. Learn what you might face, and how to defend against it with our 2018 security predictions.

  • 4
  • 3
  • 2
  • +1
Tackle projects and never again get stuck behind a technical roadblock.
Join Now