If any host can pass the below test, please post the name of your host and what control panel they use. If hosts pass it, also post the name of your hosting company, and what control panel you use. Thanks.

<TEST & SCRIPT REMOVED by Chrisb> I decided it might not be a good idea for any inexperienced users that read this forum to try.

<EDIT>1000 posts. I really do need to get a life. :(

I prefer the "insult some script kiddies and see what happens" route :D Just find a message full of people claiming to be hackers (or rather |-|@C|<ers) and call them pathetic, including your IP in your sig. Then sit back and see what happens (Damn DOS attack! :mad: ). That soon finds the holes in your server.

Originally posted by ubergeek22
I prefer the "insult some script kiddies and see what happens" route :D Just find a message full of people claiming to be hackers (or rather |-|@C|<ers) and call them pathetic, including your IP in your sig. Then sit back and see what happens (Damn DOS attack! :mad: ). That soon finds the holes in your server. LMAO !!! :D

All I get is:
total 8
drwxr-xr-x 2 root root 4096 Aug 9 07:13 .
drwxr-xr-x 23 root root 4096 Aug 19 05:24 ..

Great. All this does is tell you if the directories in /home are world readable. (Actually, it only tells you if /home itself is world readable.)

So, say I get the directory listing in /home. What next? What could I possibly gain? Any information that should be protected in these directories should be restricted if the user takes the time to change the permissions.

:beer:

chrisb

I just noticed this was your one thousandth post, congrats!:)

If you can deleted "/" .. then you have problems :stickout

I'm curious about this, because I was hacked at Hypermart and VirtualAve way back, and their setup also allowed you to view other people's directories.

I'm wondering if the reason that I can view directories and files above my "/home" directory is because of:

1. the way Apache is set up
2. the Operating System
3. Other

I've had hosts in the past that didn't allow you to view above your home directory; but cannot remember who they were.

Any suggestions or more feedback would really be appreciated.

Originally posted by BeerBuddy
So, say I get the directory listing in /home. What next? What could I possibly gain? Any information that should be protected in these directories should be restricted if the user takes the time to change the permissions.



I agree, but if you set the permissions so that other users cannot see your directories or files, I think that also prevents those files and directories from been viewable on the web too, and I want them to be published on the web.

Originally posted by chrisb


I agree, but if you set the permissions so that other users cannot see your directories or files, I think that also prevents those files and directories from been viewable on the web too, and I want them to be published on the web.

Not necessarily.

We use Ensim which sets each site in its own chroot, with common utilities hardlinked from a common directory. This prevents users from seeing each others stuff in SSH and FTP. However, Apache does not run in a separate instance in each chrooted jail. So, this doesn't keep someone from potentially having access to another users directory. However, we take other safegaurds against this, PHP safe mode, and the actual permissions on site directories.

Mark
tqhosting.com

I agree, but if you set the permissions so that other users cannot see your directories or files, I think that also prevents those files and directories from been viewable on the web too, and I want them to be published on the web.

You are correct. However, if you want to publish content on the web, yet you are truly concerned about security surrounding that content (i.e. credit card info etc.) you should not be on a shared environment.

:beer:

Is it not possible to set up shared hosting so that users can't view others directories? I could've sworn I had that on a previous host somewhere.

So, are you're saying that it has little to do with the control panel; but that being able to see others directories is an Apache quirk or bug?

If so, are there any webservers for *nix that prevent this from happening?

I could have sworn my host didn't let me see my co-guests' files, either. Imagine the possibilities if they had...

Oh, wait! One actually *did* allow it! In fact, they still haven't cancelled my FTP access even though I exited them immediately when I found out the hole.

Does anyone know a good dictionary program to open the "shadow" or "passwords" file? :D Not that I intend to use it, of course...

Totally off topic, if I'm on a "host", what does that make me? A guest? Symbiote? Parasite?

Originally posted by chrisb
Is it not possible to set up shared hosting so that users can't view others directories? I could've sworn I had that on a previous host somewhere.

So, are you're saying that it has little to do with the control panel; but that being able to see others directories is an Apache quirk or bug?

If so, are there any webservers for *nix that prevent this from happening?

This is possible. Usually it's done by using suexec with apache for CGI stuff, safe mode or open basedir for PHP stuff, and proper file permissions for everything else.

Originally posted by bitserve


This is possible. Usually it's done by using suexec with apache for CGI stuff, safe mode or open basedir for PHP stuff, and proper file permissions for everything else.

Are you saying that suEXEC with apache will do this alone? I don't understand how PGP safe mode or open basedir would prevent viewing directories and files thru Apache. Please explain further.

If any host can pass the below test, please post the name of your host and what control panel they use. If hosts pass it, also post the name of your hosting company, and what control panel you use. Thanks. Ok, I pondered for a while whether or not I wanted to entertain this thread but here goes...

FutureQuest.net : Exclusive Control Panel ( CNC (http://www.FutureQuest.net/Services/CNC/) ) Passes the test.

With that said... FutureQuest has also had what we call "Domain Lockdown" for quite sometime (Even before the newer glibc libraries made it easy). e.g. the inability for users to browse other user's directories. None the less both of these "security features" are simply frosting on the cake, dubbed "Security through Obscurity". The inability to see something does not mean it isn't there. There should always be deeper security methods in place, some of which have already been noted in this thread.

Most importantly: DO NOT INSTALL THE SCRIPT POSTED IN THIS THREAD! You do not need it to run the test if you have Telnet or SSH access. This script provides telnet access to your account. In other words anyone who finds this script can do anything they want to your account. It would be much wiser to simply telnet, or better yet SSH, into your account and type:
ls -la /home
or
ls -la /

There is no need for the script to do this if you have telnet or SSH abilities.

The first person that innocently installs this script, and posts the url to it in this thread, will be the first person to find their web site missing :( Please don't do it...for your own security.

Passing or not passing this test isn't as big of a deal as installing this script and allowing someone else to find it.

Welp, as I understand it, PHP safe mode won't let you read any other files that are not under your username. There's one for the Ensim and other that do this. Now, while SuExec'd Apache won't let you excute other's CGI, it *may* let you view static files. A CHMOD 750 or 640 would take care of Apache reading their files. Of course they may lose some web functionality of that file limiting it to user and group readable only.

A RackShack user named madsere hacked suExec to provide a safe CHROOT enviroment for Ensim users. You can see that hack here:
http://ensim.webscorpion.com/modules.php?name=News&file=article&sid=8

Brian

Originally posted by Deb
Ok, I pondered for a while whether or not I wanted to entertain this thread but here goes...

Thanks, Deb. Your comments are always appreciated.


FutureQuest.net : Exclusive Control Panel ( CNC (http://www.FutureQuest.net/Services/CNC/) ) Passes the test.

Did you try the script, or were you just so sure that it would pass that you saw no need to try the specific script?


With that said... FutureQuest has also had what we call "Domain Lockdown" for quite sometime (Even before the newer glibc libraries made it easy). e.g. the inability for users to browse other user's directories.

That is some interesting info, and good to hear. I wonder why other hosts don't do this then?


None the less both of these "security features" are simply frosting on the cake, dubbed "Security through Obscurity". The inability to see something does not mean it isn't there.
I understand. However, not being able to see something does make it harder to be targeted by a cracker.


There should always be deeper security methods in place, some of which have already been noted in this thread.

I agree.

You do not need it to run the test if you have Telnet or SSH access. This script provides telnet access to your account.

I'd call it a command line script. It does not have all the functionality of telnet or SSH. If someone wants to use it on their site, they can either password protect it and/or set the low permissions; and I'd strongly suggested naming it something weird that search engines would not be inclined to find, etc.

I thought, before posting it, that maybe I shouldn't post it (I didn't write it, btw); but I assumed that most people know there are many scripts similar to that one around that are easily obtainable from the web.

UHT OH MY HOST PASSED :D no point in saying what it is as it's my friends hosting company and his site's not live yet...

Thanks, Deb. Your comments are always appreciated. :) Did you try the script, or were you just so sure that it would pass that you saw no need to try the specific script? To be complete, I did try the script. Didn't want to say we "passed the script test" w/o actually testing the script ;) I wonder why other hosts don't do this then? Good question. I assume it requires some knowledge beyond that of my own and likely beyond the admins of many others (though that's why I trust our skilled admins for these areas. Hopefully that'll get me some brownie points with them ;) ) and there may be some software issues depending on what they are running. However, not being able to see something does make it harder to be targeted by a cracker. Agreed, however I would replace "cracker" with "unskilled crackers aka script kiddie"... I thought, before posting it, that maybe I shouldn't post it (I didn't write it, btw); but I assumed that most people know there are many scripts similar to that one around that are easily obtainable from the web. Heh I learned a long time ago to assume nothing. I agree most 'should know' but felt the "Community Service Need" to post the reminder again.. just in case and for the sake of those that still may not know ;)

this type of stuff has been around, i remember the good old days when i crashed a couple of webservers by running

"lynx"

in it.

Also got some non shadow protected passwd files...

don't know whether i shoulda posted that info. hehe

It's good to be aware of security holes in your system in order to plug it. Perhaps the below sites will help understand it that provides attack scripts frequent by hackers/crackers.

www.insecure.org www.rootshell.com

Check your system is not vulnerable to attacks and also evaluate the new scripts as they are released especially the new Nmap security scanner.

Originally posted by uburgeek22
I prefer the "insult some script kiddies and see what happens" route Just find a message full of people claiming to be hackers (or rather |-|@C|<ers) and call them pathetic, including your IP in your sig. Then sit back and see what happens (Damn DOS attack! ). That soon finds the holes in your server.

Insulting them and hurting their egos is just asking for trouble. It's a fact and not bulls-h-i-t.

Especially if one should actually know what he/she is doing ;)

Originally posted by chrisb
Are you saying that suEXEC with apache will do this alone? I don't understand how PGP safe mode or open basedir would prevent viewing directories and files thru Apache. Please explain further.

Chris, I don't know why I humor you. :)

In a shared hosting environment (1), the apache web server runs as a user that can read most of the users' files. That means when you run CGI scripts that are handled by the apache web server, they are also run by the user that can read other users' files. This makes it so that you can read all of the files in their directory that the web server can read.

If you use suexec (2) with apache, then your CGI scripts are no longer running as the user that apache runs as. They are being run as you. You don't (3) have permission to read other users' files.

1. Usually, with a shared daemon (one instance of apache).
2. If you specify the user and group for the virtual host to run as you.
3. If your permissions are set up correctly.

I would explain the PHP and JAVA security measures, but I've run out of time. Buy my book, System Administration for those who can't afford a real sys admin or an IT education. :)

Thanks, Marc. I think I knew most of that part though. I would buy your book, but I don't have any more shelf space left next to the toilet. :)

I don't have any more shelf space left next to the toilet. :) Hmmm this must mean chrisb is one of those that strongly believes in the "Out with the old, in with the new" concept eh ;)

So what is the ratio between hosts that do and hosts that don't pass the 'test" chrisb brought up?

Hey chrisb a better suggestion, why not donate the old/useless books to some colleges or libraries. I remembered when I donated most my computer repair books years ago to a technical college and received a nice thank you letter and certificate.

Regards

Well, Deb, it looks to me like you are the only one that passed from where I'm sitting. I just wish I could afford "you". :) ... your hosting, I mean.

I posted another security thread in the right forum this time. Check out the thread on suEXEC & cgi-wrap in the "Technical & Security" forum if you have time.

I just wish I could afford "you". :) ... LOL...tis true... gals like me don't come cheap and we bring a lot of 'baggage' with us :stickout

I believe we would have past the test, although like Deb, I didn't run the script.

We use SuEXEC, openbasedir, and a custom user and group configuration serverwide (amongst others) to keep server security nice and tight.

Originally posted by voxtreme-matt
I believe we would have past the test, although like Deb, I didn't run the script.

We use SuEXEC, openbasedir, and a custom user and group configuration serverwide (amongst others) to keep server security nice and tight.

Deb said she ran the test. Good to hear, though, that you keep your security tight.

Yes, I did run the test.

You can do the same by simply telneting, or better yet SSH, into an account and type:
ls -la /home
or
ls -la /

If you see a directory listing you "fail"
If you don't you "pass"

Ahh - now that will teach me to read threads more slowly and carefully in future :rolleyes:

I checked out the thread when you first posted it (any thread with a title vague related to security - and I'm in there like a shot :) ) and a brief glance and your initial post looked to be the kind of thing that we had protected ourselves against - and re-read the thread just now, and noticed you'd removed the code.

If you could send me the code, I'd be happy to run it and hopefully prove my point ;)

Ok - results of the test.

We actually 'fail' in that the directories will be listed, however permissions are set as such that a user will not be able to enter any of the directories.

Matt

Originally posted by voxtreme-matt
Ok - results of the test.

We actually 'fail' in that the directories will be listed, however permissions are set as such that a user will not be able to enter any of the directories.

Matt

Matt,
Not sure, but i heared that is till bad. A user can still cd to teh directory and run a command or something. I am not sure, but I heared that it is teh best if people cannot get the listing.

Agreed - but our setup means that users can see directory listings, but not cd into other directories.

Matt

HEy all.. I just want to give you a small FYI..

please please please uninstall this script after use anyone can get in and view YOUR files if not. :) BTW, i think it's great that there's a way for everyone to test security (it's a wise move to make and settles everyone at a good piece of mind)

Thanks, Matt for posting your honest results. So far, we still just have ONE host. I think Deb at FutureQuest runs Linux w/apache like most hosts here, so it's hard to believe that that they are the only host that knows how to prevent this; but that's how it's looking.

Would (aimed at Deb and ChrisB) you consider it a security breach that users can get a directory listing? Our consensus is that you aren't gonna find out much - maybe you'll learn a little on the directory structure of a RedHat box, or see how many other domains there are on the box by looking at /home - but we have no problem with clients know this, we'll tell them if they ask, and they know the servers aren't overloaded from the loads they run at.

If people can look at other people's directories and files on the same server, I consider it a security breach. The more information people can get about your site, the more vulnerable you are... and that's just one more piece of information to help a script kiddie attack you.

Would (aimed at Deb and ChrisB) you consider it a security breach that users can get a directory listing? Quoted from my first post in this thread: Nonetheless both of these "security features" are simply frosting on the cake, dubbed "Security through Obscurity". The inability to see something does not mean it isn't there. There should always be deeper security methods in place, some of which have already been noted in this thread. As far as "Security" -- This offers the same amount of security as closing the curtains over the windows in your home. It just adds a little extra security when people can not see who or what is in there. It's not the same as locking the doors and/or having a guard dog, but it helps a bit on the surface. Our consensus is that you aren't gonna find out much - maybe you'll learn a little on the directory structure of a RedHat box, or see how many other domains there are on the box by looking at /home - but we have no problem with clients know this, we'll tell them if they ask, and they know the servers aren't overloaded from the loads they run at. Hiding how many clients are on a box isn't an issue and certainly should not be the reason for protecting their information. The issue is respecting those clients enough to help them remain anon and keep their info private as best you can and that means paying attention to the little things as much as you would the bigger things.

Many may not mind either way and this is probably why so many have left this area open for viewing, but for those that do mind, it's just some extra benefit to being on a server that took the time to close that window as well. I believe every little thing helps.

Quite honestly, I am surprised others have not posted that they also have this window closed. I find it highly unlikely that we're the only ones that took the time, I just can't think of another host with it closed off the top of my head.

In short: is this a major security breach? No, not at all. It's just nice to take the extra steps for the clients that do concern themselves with these "information leaks" especially if it's not too difficult to do so.

I ran the script, and it showed everything, even the user's passwords and stuff.

Wow, sure am glad I ran that script. Else, I wouldn't have known about that problem.

Whew!

Just kidding, of course. Sorry, didn't run it.

Originally posted by chrisb
Thanks, Matt for posting your honest results. So far, we still just have ONE host. I think Deb at FutureQuest runs Linux w/apache like most hosts here, so it's hard to believe that that they are the only host that knows how to prevent this; but that's how it's looking.

Tell me, do you honestly think that a host setting the permissions in the /home directory to 711 means anything at all? Do you really think that means a host isn't as qualified or qualified enough to have a secure system? I think you need to consider what you're saying. No offense, but based on your lack of knowledge in this area, that's a pretty sweeping statement. This "script" was by no means a security test. It simply showed one trivial aspect. For your information, setting the permissions to deny directory listings mean absolutely nothing, especially in regards to security. There are many reasons why this is so and there are even more ways to gather information from a local system. For example reading the passwd file to see what users are on the system and that will list their home directories anyway. That is a bit more challenging to deny people viewing the content of, without altering other things too. This "test" is silly. People can get information from the group files, process listing programs or anything that will list the environment, processes, etc. They can obtain information from the web server configuration and other similar files, log files in a web server log directory, etc. In fact, there are a great many ways to quickly get the listing of account names on the server and that one you are concerned about is very trivial.

While it's true that every piece of information helps to some (even if almost completely useless) degree, that should be the last step in the concern of what to secure or not, or how. As other's have mentioned a combination of ownership, permissions, and the like are the solution. Knowing what's there is pointless if you can't have access to view the contents. We all know there's a master password file, this is very desirable to a system cracker. However the fact that the ownership and permissions deny anyone other than the super user, means that it's not an issue. Denying a directory listing doesn't mean anything in that regard. Yes it can take a lame wanna-be system cracker more time to find a file to view and get the contents of it, but that's only if the server is poorly configured in the first place to make it so other user's can view those file contents in the first place. That is a real issue on a lot of shared servers, but that's not because it has to be. I for one wouldn't waste my time with a trivial test that means nothing, because I know my servers are secure and that's all there is to it. I'm not saying it's impossible to crack a system with all the faults in the design, but just that any decent host is not going to bother with this sort of thing because it's not an issue.

I too viewed this thread because it made a mention of security, but there's nothing outlining anything in regards to security in this thread. I'm not trying to offend or embarrass you and it's great to see you have this concern and want to try and actively try and resolve these things or be cautious, but trust me on this, this "test" and this "issue" are so very much not an indication of a host being secure or not -- not in any degree whatsoever. For the record we deny all of the means I mentioned above that people can get information from, but not because it's going to pose any security risks to see these things, since we deny access to any user other than the account owner (via CGI, PHP, shell, FTP, etc.), but just to really make the people that do pay attention to and care about these things feel safer about it and understand what we truly do take measures to actually secure the system and protect users from outside and local attacks and snooping. To be clear, some aspects of this are a real issue, but nothing that had to do with that script, and there are many of us that do actively take measures to ensure a secure environment, be it we bother to run a meaningless script or not. I don't need to run such a thing to wonder if the server is secure or not, because I know the limits and what can be done -- and this is not a concern for anyone with a decent system configuration (be it that it lists the files or not).

Hmm.. do you expect something like this?

bash-2.04$ ls -la /home
ls: /home: Permission denied
bash-2.04$ ls -la /
ls: /: Permission denied

Well, I don't think it's silly at all... but to each his or her own, I guess. I never said this minor hole was a major security risk; but I'd still call it a risk. JFYI, I've done much reading over the last few years about security including newsgroups so I do know a little bit about it. Of course, I don't claim to be a security expert.

Originally posted by Jedito
Hmm.. do you expect something like this?

bash-2.04$ ls -la /home
ls: /home: Permission denied
bash-2.04$ ls -la /
ls: /: Permission denied


Yes, Jedito. Did you get that from your servers? If so, who hosts them?

Yes, that's what I got, btw I host myself, take a look at my signature :)

Do you really think that means a host isn't as qualified or qualified enough to have a secure system? As noted a couple of times in this thread, I do backup the fact that 'failing' this 'test' does not mean a system is insecure. It just means the admins have taken the time to 'close a looking glass'. Closing the view enhances Security through Obscurity. Nothing more, nothing less. any decent host is not going to bother with this sort of thing because it's not an issue. I have to respectfully agree to disagree on this point. If a client prefers the inability to view for their own comfort level, then it is worth the time. (No one can get into a position to see through my bathroom window but I still keep the curtain closed just because I feel a bit more comfortable that way.) Especially since it only takes a tiny bit of time, providing the system is setup in such a way that will allow this tiny window to be closed. For the record we deny all of the means I mentioned above that people can get information from, but not because it's going to pose any security risks to see these things, since we deny access to any user other than the account owner (via CGI, PHP, shell, FTP, etc.), but just to really make the people that do pay attention to and care about these things feel safer about it and understand what we truly do take measures to actually secure the system and protect users from outside and local attacks and snooping. Out of curiousty, why wouldn't the same apply here then?

I've found it takes less time to close an InfoLeak and then educate the client as to what dangers it does or doesn't have...leaving the knowledge up to them to accept or not accept... than it does to leave it open which can leave them feeling uncomfortable regardless how much you try to explain it. Note: not all systems are able to close this and that is ok. Those are the reasons education must also be included in the explanations..

In the 'old days' clients could not only view the other directories but cd into them as well. Though they couldn't edit the files they could poke around and read them. This was accepted as "just the way it is" and is the reason we created "domain lockdown" on our servers. Domain lockdown was considered 'not really a big deal' back then but it wasn't much after our domain lockdown went into affect that PHP files with MySQL passwords in them started becoming more popular. Thankfully newer software has closed this window so we don't see the problem near as much today. The ability to get into those directories is something to concern yourself with far more than the ability to view the list. The inability to view the list does however help to slow down casual snooping as well as a "lame wanna-be system cracker". An example I gave earlier was closing the currents on a window in your home. It's not going to stop someone from walking in the door or breaking the window itself or any of a number of options but it does make it harder to be a peeping tom. e.g. It wont stop a burglar but it may stop little Johnny from peeping in on little Sally :P

Bottom line -- It's not seen as a big deal either way.. because it's not a big deal... but I think if a client 'feels better' having it closed, and if you have the ability to close it, what is the reason for leaving it open?

Originally posted by chrisb
Well, I don't think it's silly at all... but to each his or her own, I guess. I never said this minor hole was a major security risk; but I'd still call it a risk. JFYI, I've done much reading over the last few years about security including newsgroups so I do know a little bit about it. Of course, I don't claim to be a security expert.

I'm not trying to offend you, really. I'm simply saying someone knowledgeable in regards to these aspects would know it's not a risk, not a "minor hole" (it's not a hole at all) and not anything at all to worry about. There are no possible ways this can be a risk on any server that is properly configured. It's the least of your worries out of everything there is to worry about. I'm not trying to discredit you by saying this, but I feel compelled to state the facts of it, especially if you want to proclaim that any host that doesn't do such a simple, trivial and pointless task is not a secure web host (*or don't know how to properly secure it*).

This is not security, it's not a risk, it's not a hole. If you don't want to list the home directories, you don't have to, but it won't matter either way (unless a host is not properly set up, then yes it could make it potentially easier for a script kiddie). Again, there are many other very simple ways (just as simple as listing the home directories) that you can obtain this information. Perhaps I'm not explaining myself well enough, if you are going to take offense, but I'm just telling it how it is. I'm sure you'll learn more and understand what I mean as you gain more knowledge. If you have any questions, please feel free to message me and I'll be glad to help you out.

I agree with robert, and so far, I'll say that chris is conscious of information security, but not sure if he has posted anything noteworthy regarding it.

Going on what robert said, here's a script that even most hosts that have the /home directory not readable will "allow". Not that everyone even put's their user's home directories in /home.


#!/usr/bin/perl -w

print "Content-type: text/plain\n\n";

if (open(FILE, "/etc/passwd")) {
while (<FILE>) {
print $_;
}
close(FILE);
}

exit;


Like robert said, if you allow this, what's the diff if you don't allow reading of /home?

Originally posted by Deb
As noted a couple of times in this thread, I do backup the fact that 'failing' this 'test' does not mean a system is insecure. It just means the admins have taken the time to 'close a looking glass'. Closing the view enhances Security through Obscurity. Nothing more, nothing less.


Exactly. It's just cosmetic, you can get a listing of the user directories in too many other ways just as quickly anyway.


I have to respectfully agree to disagree on this point.


If you read my post, you can see that I said clearly that I do deny directory listings. Not because I think it provides better protection, but for the sake that the users can see that every step is taken for their benefit and to make them feel safer. I would assume anyone that cared enough about that aspect would inquire further and express their concerns about real issues, and maybe that's a start. They can say "Good, I see you don't allow people to see a listing of the accounts". We can then explain how they also can't access any files in another users account and why.


If a client prefers the inability to view for their own comfort level, then it is worth the time.


I agree, I never opposed that, which is why we do it ourselves. I simply said it's not a security measure as that is not a risk at all. We take it many steps further just to deny information to any user from obtaining other user's information. This includes them not being able to view the web server configuration, passwd, group files, directory or file listings, log files, and so on. That doesn't provide much other than people don't know who else has an account, what it's called, what sites there are, and so on. It's one trivial step that is taken to make them feel better and because yes it does help to make things more difficult to take away any system information from a local account holder with intentions to snoop around or try and do damage, etc.

However, just denying directory listings is one of the most trivial and pointless things out of all of those things that are trivial. In other words without a lot of other steps, that one step is too trivial. I don't like anyone seeing anything they shouldn't or have no reason to, and we've taken measures to prevent all of those things. We of course take more measures to provide the real heart of the security, and yes we do take these more trivial steps too. I stated this isn't a security risk and that it's trivial and the script (or test) was pointless and provides no insight or proof of an insecure system. I don't like people claiming it means something. Comfort level is important, yes. If you assume I meant to say since you also take this measure that you are not genuinely providing a secure server environment, then you misunderstood me and that wasn't what I said or meant, nor was it in response to you. Again, I said we do it as well, but this is grossly inaccurate to assume it means that a server is a risk simply for not denying those directories from being listed, as again there are far too many other ways to just get the information just as simply and quickly.


(No one can get into a position to see through my bathroom window but I still keep the curtain closed just because I feel a bit more comfortable that way.) Especially since it only takes a tiny bit of time, providing the system is setup in such a way that will allow this tiny window to be closed. Out of curiousty, why wouldn't the same apply here then?


I didn't say it didn't. I reiterate; I stated this alone, this so-called risk, is not a risk, it is not a hole of any kind, it is not a security issue. Knowing my age doesn't let you know my postal address, for example. It's not a risk, but I'm not going to pretend that means knowing my age doesn't help you know something about me. Perhaps that better equates to a better example? Everything contributes, but since you can get my age 100 different ways, I don't think trying to hide my age will make me anymore of less anonymous to people wanting to know where I live.


I've found it takes less time to close an InfoLeak and then educate the client as to what dangers it does or doesn't have...leaving the knowledge up to them to accept or not accept... than it does to leave it open which can leave them feeling uncomfortable regardless how much you try to explain it.


I completely agree, which is why I, as you do, provide that comfort zone. I'm simply trying to educate the original poster about this to explain to them, the one who posted the script an the one
who claimed it meant one provider is more secure than another and other hosts must "not know how", that it's because it's not an issue, not a risk and not a hole and that it makes absolutely no difference (unless you manage to find a way to deny someone from obtaining said information 100 other quick, simple ways). We do that, so I can't mock it and I don't intend to, but just testing to see if one directory allows file listings is by no means a risk or a security issue. I attempted to put it into perspective, I guess I failed. :0)


Note: not all systems are able to close this and that is ok. Those are the reasons education must also be included in the explanations..


Any host can deny file listings for their /home directory, so I assume you mean something else in the above comment. I'm not sure what you mean though.


In the 'old days' clients could not only view the other directories but cd into them as well.


And they still can on most servers today, actually.


Though they couldn't edit the files they could poke around and read them.


Yes, and that is where directory listings can be a problem. However, there are still too many ways back then and currently that still allow them just as many ways. So this is why I said "any provider that has a decent configuration wouldn't see this as an issue or risk".


This was accepted as "just the way it is" and is the reason we created "domain lockdown" on our servers.


I think there's a lot of providers that still think in those terms and say it's a shared environment, so what do they expect. Those of us that know better, know better. It's good to see you're one that knows better.


Domain lockdown was considered 'not really a big deal' back then but it wasn't much after our domain lockdown went into affect that PHP files with MySQL passwords in them started becoming more popular.


Exactly, that is the heart of the problem, and directory listing isn't even needed to exploit that problem.


Thankfully newer software has closed this window so we don't see the problem near as much today.


This issue exists in most software still, unless you take on the administrative task of removing that problem. I assume this is what you did with your domain lockdown.


The ability to get into those directories is something to concern yourself with far more than the ability to view the list.


Exactly. Since no one can on a server that's configured decently, it's not an issue.


The inability to view the list does however help to slow down casual snooping as well as a "lame wanna-be system cracker".


Not if they can't access another user's directory to view the contents of said file. This is why I said, it can be a risk, but only on a server that's not set up well. If that's the case, denying any file listing will not make any difference anyway.


An example I gave earlier was closing the currents on a window in your home. It's not going to stop someone from walking in the door or breaking the window itself or any of a number of options but it does make it harder to be a peeping tom. e.g. It wont stop a burglar but it may stop little Johnny from peeping in on little Sally :P


Yes, but if you have an army out side of your home keeping people away, you don't have to worry about what someone walking by wants to see, because they can't get close enough and they can't get in anyway. Trying to camouflage your house to hide it, isn't going to help and it's not a risk for people to know it's there, since they can't access your property anyway. If you don't have an army, sure it can matter.


Bottom line -- It's not seen as a big deal either way.. because it's not a big deal... but I think if a client 'feels better' having it closed, and if you have the ability to close it, what is the reason for leaving it open?

I can't think of any reason why you would leave it open, even if it doesn't matter, which is why I explained in my posting that I do take those measures too. It doesn't hurt, even if it doesn't help. This is the same reason why we buy SSL certificates from vendors, even if we can create our own that would serve the same purpose. I'm up for providing clients with whatever makes them feel safe, but I want them to know that I'm experienced enough to do what really needs to be done and show them they truly are, rather than just hiding things (even if it doesn't hurt to). I'm of the opinion by your post that you are the same way, and I guess I didn't express my reasons well enough previously about what I meant and why. I hope this is more clear.

I can't think of any reason why you would leave it open, even if it doesn't matter, which is why I explained in my posting that I do take those measures too. It doesn't hurt, even if it doesn't help. Gotcha ;) I did misunderstand your first post as I thought you were saying you didn't block the listing because "it didn't matter". Second clue bat helped :D

Originally posted by Deb
Gotcha ;) I did misunderstand your first post as I thought you were saying you didn't block the listing because "it didn't matter". Second clue bat helped :D

I fear my original resposne wasn't clear enough. I think we are on the same wave here. :o)

I think we are on the same wave here. : o ) Scary huh :o

Thanks Robert for the education. I thought you were just out to criticize. Maybe, our terms vary, but I don't want other people to be able to look on the server and see my username and others, or files. To me, it's better security to have the "looking ability" turned off if possible.

My own host allows me to ls -la /home, which shows every client on the same server. I can live with that. After trying 3 or 4 usernames such as ls -la /home/bobc, /home/sallygen, etc. and getting permission denied, I feel safe enough, since it does deny me from seeing anything further than the user names. Previous hosts have allowed me to go further and get into their directories, etc. If that were the case at this host, I may have changed hosts.

I just hope that if my host notices this that they will realize what I was doing, and not think I was trying to hack someone.

NOTE: I have received many PM's asking me to send them the script that I removed. Please do not PM me for the script. I do not have time to send it to you, and you can do the same thing with SSH anyway. Thanks.

Originally posted by bitserve
I agree with robert, and so far, I'll say that chris is conscious of information security, but not sure if he has posted anything noteworthy regarding it.

Going on what robert said, here's a script that even most hosts that have the /home directory not readable will "allow". Not that everyone even put's their user's home directories in /home.


#!/usr/bin/perl -w

print "Content-type: text/plain\n\n";

if (open(FILE, "/etc/passwd")) {
while (<FILE>) {
print $_;
}
close(FILE);
}

exit;


Like robert said, if you allow this, what's the diff if you don't allow reading of /home?
I'd hope that THAT was blocked too.

Good to hear Jedito. So let's see we have DowntownHost, Futurequest, and 2host.com so far that say they block the list of usernames AND directories/files within a shared environment.

Even if I didn't consider it a leak of security, like Robert mentions, it makes it appear to your clients that you care and have taken an extra step AND if you did that, you probably are going to take the extra security steps needed.

Originally posted by chrisb
Thanks Robert for the education. I thought you were just out to criticize. Maybe, our terms vary, but I don't want other people to be able to look on the server and see my username and others, or files. To me, it's better security to have the "looking ability" turned off if possible.

My own host allows me to ls -la /home, which shows every client on the same server. I can live with that. After trying 3 or 4 usernames such as ls -la /home/bobc, /home/sallygen, etc. and getting permission denied, I feel safe enough, since it does deny me from seeing anything further than the user names. Previous hosts have allowed me to go further and get into their directories, etc. If that were the case at this host, I may have changed hosts.

I just hope that if my host notices this that they will realize what I was doing, and not think I was trying to hack someone.


Really, if I offended you in any way, I apologize. I agree that even if it's cosmetic, it can make people feel safer (after all, I said many times we provide this as well). Recognizing these things will only make you gain more interest and learn more and that's always a great thing. As for snooping around, you can always try to do an "ls -la /home/username/public_html" or you can go to their web site and find a file and just type in that location after public_html for their document root.

Further, even if you can't list the file or see it, if you know it's there, you can still view it with less, cat, etc. (if the permissions and/or ownership don't protect it). That would be if a provider didn't protect users from that sort of thing (which was my point). I'm just saying that things that look cosmetically safe don't necessarily mean they are, and if they are, those things won't matter. I don't want to make any suggestions to have someone get any further ideas, but to simply illustrate that I agree it can be an issue, if things aren't how they should be.

Originally posted by chrisb

I'd hope that THAT was blocked too.

That's a problem right there though. It can be but it's rather difficult to provide that being denied to open and viewed as this file houses all the information that a user would need to log into shell, or for Apache to read it to use SuEXEC. I won't get into details, but trying to deny people from viewing the passwd file without a great deal of other altercations to many things, would be very difficult. This illustrates one of my points about the trivial nature of the above concerns, as with things like the passwd file, the rest is moot.

As I stated, we changed many things around to protect these such files as well, but I don't expect very many hosts at all have altered so many things to deny people seeing such information, and yet still allow everything else to function as it should. You can use a chroot jail to control things like that and keep a user in their own area, but chroot jails are not fail safe and can be broken out of. Therefore other measures need to be taken. I can't go into details and I probably will avoid it for the sake of nondisclosure. Sorry if that sounds cheap of me, but it's a big market out there. :-)

Originally posted by chrisb
Good to hear Jedito. So let's see we have DowntownHost, Futurequest, and 2host.com so far that say they block the list of usernames AND directories/files within a shared environment.

Even if I didn't consider it a leak of security, like Robert mentions, it makes it appear to your clients that you care and have taken an extra step AND if you did that, you probably are going to take the extra security steps needed.

Chris, I appreciate the way you worded that. I can agree with that view.

I just tested "ls -la /" and I can see a list of root files? Is that anything to concern myself with?

I don't know if I'll go any further and try an ls -la /home/another_user/public_html My host might get the wrong idea, when all I'm trying to do is to check out their security.

Thanks again, Robert for the additional info. The password comments were specifically interesting. I had no idea how difficult it was to block a etc/password file.

That means you / they fail the test. Can you cd into any of the directories you see?

Matt

Well, I must have misunderstood, as I thought you were testing on a server you had or a reseller account with your own clients. I don't suggest you try and snoop around, and that was my suggestion earlier, but only in the capacity which I thought you were involved. I concur that it wouldn't be a good idea and could be seen the wrong way. Let's just put it this way, if their home directory account /home/username and/or /home/username/public_html were 711, that would not make any difference other than denying file listing, as again the files can still be viewed. it really depends on how your host has things set up.

I'm not sure I'd feel comfortable posting anymore, as even if it's not a concern or issue for some hosts set ups, it could lead people to understand how to snoop for passwords and such and I don't want to explain how or encourage anyway, even if it's pretty simple, obvious stuff that is involved (and they probably already know anyway). I'm not saying your host has a poor set up, just that I don't want to give anyone any ideas of how to exploit a poor set up. I'll zip it about now. ;-) Perhaps you can inquire about your concerns to your host and see what they have to say. Perhaps it will get them more active (just in case they might not have a solid set up). Point them to this thread if need be. If they are reasonable people, they will understand your concerns and might even make some changes (if they need to).

Originally posted by chrisb
The password comments were specifically interesting. I had no idea how difficult it was to block a etc/password file.

We haven't done anything to prevent the viewing of the /etc/passwd file by users, and I'd bet that except for those offering virtual server services or not offering CGI, none of the hosts on here have prevented it, except for robert who claims to have, but is not yet offering services.

There are only two ways that I know of doing it.

1. With chroot and stub /etc/passwd files.
2. With group permissions and set gid, which is quite difficult to set up. You need to set gid on every program that needs to read the /etc/passwd file. Any program that needs to determine uids and gids is going to require it, including ls, apache, php, suexec, quota. Well, pretty darn near everything.

I don't claim to know everything about this though. I'm sure there are ways that I don't know about.

If you argued this on slashdot, I'm sure that everyone would say that reading the /etc/passwd file isn't an issue, as there are other ways of determining the information in it that would also need to be protected. But robert claims to have done this as well.

So of course I'd be interested to learn what method robert is using, but he seems pretty tight lipped. Perhaps ordering an account from him will be in order to test this out.

Just kidding, but it seems like if robert is going through all of these pains, that just using a virtual server solutions would have been easier. :)

Originally posted by bitserve


We haven't done anything to prevent the viewing of the /etc/passwd file by users, and I'd bet that except for those offering virtual server services or not offering CGI, none of the hosts on here have prevented it, except for robert who claims to have, but is not yet offering services.

There are only two ways that I know of doing it.

1. With chroot and stub /etc/passwd files.
2. With group permissions and set gid, which is quite difficult to set up. You need to set gid on every program that needs to read the /etc/passwd file. Any program that needs to determine uids and gids is going to require it, including ls, apache, php, suexec, quota. Well, pretty darn near everything.

I don't claim to know everything about this though. I'm sure there are ways that I don't know about.

If you argued this on slashdot, I'm sure that everyone would say that reading the /etc/passwd file isn't an issue, as there are other ways of determining the information in it that would also need to be protected. But robert claims to have done this as well.

So of course I'd be interested to learn what method robert is using, but he seems pretty tight lipped. Perhaps ordering an account from him will be in order to test this out.

Just kidding, but it seems like if robert is going through all of these pains, that just using a virtual server solutions would have been easier. :)

I'm not sure I understand what you mean by "all these pains". I imagine it might seem more trouble than it's worth if you're not familiar with how to accomplish these things and I can understand that, but it's not that difficult. It's true that denying access (even to just the user) will result in problems, with them logging in, etc., but it's not impossible to get around. I figured out some ways to solve this problem a few years ago. I can't disclose (yet, and I don't know if I will) the methods I use. Sorry to have to be tight lipped, but I doubt it would be a very easy thing to explain all the how's and why's anyway, and answer all the "but..." questions to explain how it would still fully work, yet have everything else work.

I'm going to have a guy try and crash the server soon, which I've set up an account for him for FTP, web and shell access, so _perhaps_ after I let him try and example what he thinks will crash the server, I can give you or someone else an account and show you that you can't obtain any of this information (since I don't have any client accounts on there yet anyway). (And yes, I'd be watching what he (or you) did while you do it, because I want to demonstrate these things to people wondering, before I put clients on the server and have my merchant stuff all ready, etc. After that, it might be better/easier to explain anyway.

Basically, it's just to example that you can control access and control processes, etc. to where a client can do anything they want or need to on a shared server environment without risk of them obtaining information, compromising the server or services or being able to create large loads, etc. I just need to get the time to do this (demonstrate) while I'm busy with my other projects (I have been outsourcing support and admin work -- which we will be offering when it's ready to launch for clients), so I'll perhaps get back to you and see if I can demonstrate this (I've simply been busy and haven't ben making this the priority (which is why I'm not accepting clients yet)).

Robert, will users be able to compile C programs without having to install their own compiler? I might be willing to help you determine if you're indeed protecting all of the information that you're trying to protect, with some temporary shell access.

I don't know if you realize how easy it is to install virtual server technology. For me at least, it seems like it would have been easier.

Originally posted by bitserve
Robert, will users be able to compile C programs without having to install their own compiler? I might be willing to help you determine if you're indeed protecting all of the information that you're trying to protect, with some temporary shell access.

I don't know if you realize how easy it is to install virtual server technology. For me at least, it seems like it would have been easier.

Users are allowed access to the compilers by request. Few to none usually want to use them anyway, and anyone that wanted to crack a system with shell access would mainly want to compile some exploits. Of course you can always upload a binary, even if it's not compiled on the server, but you can remove access to other things that those binaries would need when ran (stuff a user wouldn't have any need for).

Another idea which seems a little odd and ridiculous (and I'm not sure I'm going to implement), would be to additionally force all files uploaded to be in ASCII, other than Java applets, shock wave, mpg, png, jpg, gif, etc. and all other valid file types and then check the file itself to make sure it's not a compiled program. How's that for extreme?

Anyway, there can be ways to deny local compiling and also deny any compiled program from being uploaded, unless a user requests it. (Not that I'd really do that, but you get what I mean.) Part of this solution is actually a virtual server method, but since that is not fool proof other, more interesting measures were taken. I'll let you know. Thanks.