Web Hosting Talk







View Full Version : Able to see other's folder in FTP


ginakra
05-16-2001, 12:53 PM
Hi all,

I'm a web designer, and I just found something disturbing thing while using FTP on a shared server for one of my clients. I was uploading an update, and accidentally hit the "up directory" too many times. I stumbled into the entire user list directory. From
there I was able to get into as many directories as I clicked on, and downloaded a few jpg's just to see if I could. I did not do anything else, nor enter folders that looked private. I thought it might be a fluke, so I disconnected, and followed the same steps. I could repeat the process above..I didn't try to upload, just because of the ethics involved. I have screen shots of each step, including the download process of another user's stuff (just jpgs).

Before I go ranting off to the hoster-- (who as far as I know does not frequent this message board, and it's not my hoster), who has, or at least *had* 5 years ago when I set my client up with them, a very good reputation--is this a somewhat normal practice???

I have never seen a shared server that lets you into root allowing access to other users folders? What's up with this???

I'm thinking of getting with another user on the the server to see if I could upload or edit an html file. I will *not* do this without permission, but I'd love to know if this is possible, and how far the security can be breached here.

Thanks for any input.

ginakra
05-16-2001, 01:28 PM
As an update, since I've been fooling around more:

I can see these folders:

modules/
root/
sbin/
stand/
tmp/
dev/
etc/
lkm/
usr/

and a bunch more files and stuff. That's as deep as I can get. I can't click on modules/ or root/ without a permission denied message. I can get into bin/, dev/, etc/, lkm/, lost+found/, sbin/, usr/, var/, home/, usr/src/sys/, and a bunch of others. I can download from at least a few of these. This is a Linux system.

Anyone care to tell me if this is a real bad thing?

Mitz
05-16-2001, 02:44 PM
I too would be curious to hear what other hosting firms are doing.
We entered the hosting arena last year and continually struggle with FTP access. As much as you can lock it down, it is still extremely unsecure. Any thought by other ISPs would be greatly appreciated.
Thanks much.
Sorry I did not answer your questions Gin. :)
-Mitz

Voodoo Web
05-17-2001, 04:44 AM
You have FTP access based on the permission of the files and folders on this linux server. It is normal that a user can open /etc, /usr, bin and others because you need access to start programs or read config files.
I think your hoster should provide a more secure server (it's possible) and use a ftp server where you cannot go outside your home directory.

- domi

jtan15
05-17-2001, 05:45 PM
Like Voodoo Web said, you can only view what you have the permissions to view. the /root and /modules directories are most likely chmodded so that only root can read them. You won't be able to upload into another user's directory, because that user owns the directory, and you do not. If the user chowned the directory and gave you ownership permissions, you would then be able to upload into it. Or they could set the directory permissions to 777. Then you could upload into it. Otherwise, you won't be able to.

This isn't much of a security hazard, but I haven't seen many hosts recently who do this. Setting up safe chroots are awfully easy now with programs like proFTPD and others. We have a chroot setup on proFTPD and we have had no problems to date. Chroots are relatively very safe.

archangel777
05-20-2001, 03:13 AM
If you have your own server, it's pretty easy to setup. The setup is a bit different.. depending on which FTP program the server is using.

If you don't have your own server, and assuming you're on a Unix platform, then you might try to do a "chmod 707" on your home directory. This blocks other group users from stealing or accessing your files..

Tim Greer
05-20-2001, 04:34 AM
Originally posted by archangel777
If you have your own server, it's pretty easy to setup. The setup is a bit different.. depending on which FTP program the server is using.

If you don't have your own server, and assuming you're on a Unix platform, then you might try to do a "chmod 707" on your home directory. This blocks other group users from stealing or accessing your files..

Actually, 707 would allow *any* user on the system complete access (the last 7 being "world" having read, write and execute permissions).

cperciva
05-20-2001, 06:26 AM
Originally posted by Tim_Greer
Actually, 707 would allow *any* user on the system complete access (the last 7 being "world" having read, write and execute permissions).

Any user not in the same group, that is. If you have a single group for "users" (which is common on most UNIX systems but has lost popularity recently) that wouldn't be a problem.

At least, it wouldn't be a problem for that reason. Allowing user nobody/nogroup to rwx files is a recipe for problems (eg, finger, anonymous FTP). Apart from system binaries, no files should ever be o+x, and I can't think of any excuse for anything to be o+w.

Tim Greer
05-20-2001, 06:18 PM
Originally posted by cperciva


Any user not in the same group, that is. If you have a single group for "users" (which is common on most UNIX systems but has lost popularity recently) that wouldn't be a problem.

At least, it wouldn't be a problem for that reason. Allowing user nobody/nogroup to rwx files is a recipe for problems (eg, finger, anonymous FTP). Apart from system binaries, no files should ever be o+x, and I can't think of any excuse for anything to be o+w.

Okay, let me be more clear then;

707: 7 (user) = read, write, execute for your specific user. (full access). 0 (group) = no access for the group you belong to (shared by others or unique to you). 7 = (other) read, write, execute for "world" (full access). You might be the only "user" with full access to your account, and you might have no access granted to everyone in the same group as you -- but those user's are _still_ "other". The other user's might have their group denied (if they are in the same group), but their "user" is still "other" and therefore they are world and have full access, since they are not in that user's user and group both (they are still a different user). Hopefully, that will explain it better.

Tim Greer
05-20-2001, 06:27 PM
In addition to my last post, I'd like to add to the other poster's (chmod 707) suggestion. Instead of allowing "world" full access, which isn't needed on the home directory itself, use 701. That will not allow any user on the system to have such access, give your user full access and no access to the group you belong to (if that's even the case, which is unlikely), yet still give programs and the web server, etc. (other) access to your files. This doesn't protect people from being able to view the files in your directory if they know or guess file locations, but it will deny them from uploading and altering files on your account.
There are better solutions to this (that I would suggest) (but) that would require some cooperation from the web host that would only take a few moments to implement a very simple solution, without the effort of chroot, etc. -- which will even protect user's from other's viewing their files in a shell, FTP or using a script to do so. This was discussed in another thread, where I mentioned how this can be done. It's very simple to do, I'll try and locate that URL to post a link here, when I have a few minutes free, unless someone else beats me to it.

cperciva
05-20-2001, 07:53 PM
Originally posted by Tim_Greer
Okay, let me be more clear then;
[snip restatement of what TG wrote above]

Which operating system are you running? The following from FreeBSD 4.3

$ id -pn
uid cperciva
groups cperciva wheel
$ ls -l /tmp/tempfile
-rw----r-- 1 root wheel 15 May 20 23:49 /tmp/tempfile
$ cat /tmp/tempfile
cat: /tmp/tempfile: Permission denied

clearly shows that a user in the same group as the file owner uses the group permissions, even if the "other" permissions are more permissive.

Tim Greer
05-20-2001, 10:09 PM
You're right... I'm an idiot! This is true; that if the user's share the same group, that they are bound by the same permission restrictions on the other user's files and directories based then on the group they belong (in regards to the other user's files and directories within that same group) and the "world" doesn't matter. Thanks for pointing that out. However, I still stand by the contention (which I'm sure you'll agree) that allowing world read, write and execute is a bad idea, as user's not bound by that same group(s) and therefore not restricted to it (in regards to other user's files and same group(s), so to speak) can cause harm or do damage, among other things (and since it's fairly easy for people with a minimal amount of knowledge to utilize another user/group to make use of the "world" user).

AtlantaWebhost.com
05-21-2001, 11:41 AM
I know WuFTP (which came with Linux) allowed users to browse the entire system. However, we were able to easily fix the problem by switching to NcFTPd (which keeps users chrooted in their own home directory). NcFTPd is very easy to setup and configure. I believe ProFTPd can do the same thing, but we do not use it.

Best regards,
Frank Rietta

drhonk
05-22-2001, 02:52 PM
You can do the samething with wu-ftpd also... but .. the catch is .. you need to install bin, etc, shlib directories on all of your virtual host home directories.

I would go with proftpd.. it's easier to configure .. :)