The Community Forums

Interact with an entire community of cPanel & WHM users!
  1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Is this cpanel's security bug?

Discussion in 'Security' started by chunpal, Jan 13, 2003.

  1. chunpal

    chunpal Member

    Joined:
    Dec 13, 2002
    Messages:
    23
    Likes Received:
    0
    Trophy Points:
    1
    Connect to SSH then log in, type cd .. =& ls -al =& server's home directory show up.

    or log in SSH, cd / =& can see all of the server.

    Using user's account, not ROOT.

    Any patch? or just using like this?

    What u guys think if u have dedicated server and have clients?
     
  2. Tim Greer

    Tim Greer Well-Known Member

    Joined:
    Aug 11, 2002
    Messages:
    62
    Likes Received:
    0
    Trophy Points:
    6
    It's not a security issue, unless users can find and view the contents of other user's files that contain sensitive information.

    If you run, for example, PHP scripts with mod_php or CGI scripts without SuEXEC, and need to put in a database password, you can have other user's view those files.

    This is not a Cpanel problem, this is a problem with shared servers. The best way around this is to force PHP scripts to run as CGI, and enforce the SuEXEC CGI wrapper for all CGI scripts.

    That will allow you to create a unique setting where you can set specific permissions and ownership on the user's home directories, so only the web server and root can access their files past their main (parent) account directory.

    This means that another user can't log into shell, nor FTP and view another user's files or even access their home directory. This also means that another user can't create a CGI or PHP script to access another user's directory via the web server.

    The problem with this is really only one thing - running PHP as CGI. Some people don't like that idea, but few people really write PHP scripts efficiently enough to make any difference between a module and CGI version. It will obviously be slower due to CGI spawning off processes and causing overhead.

    However, most PHP scripts take up so much resources anyway, that it doesn't seem to matter. Also, the big advantage to this, is that not only is it more secure, but that you can now control the processes and resource usage per user/virtual host. You can set how many processes they can run at once, how many files they can have open at once, as well as how much memory and CPU time. This helps prevent load and crash issues.

    So, there is every advantage other than the slowdown, and it's likely not going to be enough to notice, unless you get a script hit/accessed a lot and it is either inefficient or just hit so much that the fact it's running as CGI starts to take it's toll. At that point, a user should either have a custom script that will not cause such issues, or perhaps consider a dedicated server. After all, just because its CGI doesn't mean it's going to be that much slower. It can depend. A bad script is a bad script no matter what, at least this way you can keep things under control with limits.

    You can custom hack the PHP and Apache source with a few simple lines and modifications to make any file that ends in .php, etc. to automatically call to the PHP binary for CGI. Also, so it will ignore permissions on PHP files and make it so user's don't have top specify a different (i.e., .cgi) file extension to run it as CGI, nor have to put in the shebang line to the PHP binary as mentioned a moment ago. I.e., it will all work the same and be completely unnoticeable and seamless for the end-user, yet the system will be more secure and in control. This also prevents your server from being susceptible to the not so uncommon PHP module exploits that continue to be an issue.

    Users would notice if they looked at the API message, or if they get just so many hits that it's creating a slow down, but it honestly probably wouldn't result in that, since a properly coded CGI script will be just as fast as a PHP one (it has just as much chance of being faster), but that the CGI interface itself is what will ultimately take its toll. Again, I see so many slow PHP scripts that I don't think it's a bad idea to do this. Well, that's my thoughts on it anyway. Unless someone creates a wrapper for PHP itself when run as a module, this will be an ongoing problem, unless some other changes could be made as well to overcome this. There are some possibilities and there may even currently be some custom solutions out there if you look. Me, I still like the idea of CGI simply because of the security from the module based exploits PHP has faced, as well as that you can limit the resources and prevent a PHP script from wreaking havoc. Hopefully there will be a better solution to both without the need for a CGI based solution though.

    FTP already uses a chrooted solution. SSH can accomplish this as well, and you can also chroot/jail the users in this manner as well. That is not a perfect solution due to the environment, though. Apache can be chrooted, but this would not work well for this environment it's currently an issue in. So, even so, a CGI or PHP script either as a module or not, without SuEXEC and some unique settings will provide a solution, or be the cause of this problem until something better is implemented as a standard. I hope this helps clear up how this issue doesn't lie in Cpanel, but in shared servers and how they work. It's a problem many non-Cpanel hosts face and there are various solutions people have used, and most aren't even close to being a complete, solid solution.
     
  3. Tim Greer

    Tim Greer Well-Known Member

    Joined:
    Aug 11, 2002
    Messages:
    62
    Likes Received:
    0
    Trophy Points:
    6
    Oops, I pressed reload on my browser after switching application windows. The result was a double post (30 minutes after my original). Anyway, there are obviously other issues with a CGI/SuEXEC solution, such as WebDav, and other modules like mod_python, fastcgi and mod_perl, and others, and it's a lot of hassle, depending on what you offer. I'd take the initial step to at least inform and encourage users to not store their account or email passwords in scripts that can be viewed by other users due to the permissions.

    This includes using different passwords for databases, email, FTP, and so on, if you can help it, or to at least keep them out of files others can view. However, there's a good solution for that now. That is any file with sensitive information CAN be run as CGI with lower settings as the above solution would offer, but only in one directory (scgi-bin), the Simple CGI wrapper directory. Cpanel offers this and you can make use of it for any files that need it -- even if that means running some PHP scripts as CGI (with the permissions, file extension changed and the shebang line added, but it's better than nothing). That is a decent solution currently without the need to modify or try and get another more involved solution to work.
     
  4. Juanra

    Juanra Well-Known Member

    Joined:
    Sep 22, 2001
    Messages:
    777
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    Spain
    Tim, can you comment on this patch?
    http://luxik.cdi.cz/~devik/apache/
    Thanks.
     
  5. Tim Greer

    Tim Greer Well-Known Member

    Joined:
    Aug 11, 2002
    Messages:
    62
    Likes Received:
    0
    Trophy Points:
    6
    [quote:fa2b773160][i:fa2b773160]Originally posted by Juanra[/i:fa2b773160]

    Tim, can you comment on this patch?
    http://luxik.cdi.cz/~devik/apache/
    Thanks.[/quote:fa2b773160]

    I looked at that a long time ago, but I don't recall that the end result was a solution to this problem. I might be wrong about that, or wrong about how I remember it, though.

    You'll notice that the version of Apache that is for is for build .20, and that is pretty old. It looks like they didn't update it since then. They also stated Apache 2.x was still BETA. That has not been BETA for a while.

    However, the MPM module is the interesting factor and why I was personally excited about Apache 2.x, but I've not looked into that for a while myself since there was so many issues with building modules into 2.x due to many of them not being ready to work properly with it. My recommendation is to look into that module, since 2.x is a lot more stable and friendly now. I'm not sure of the status, and in fact, if it's even complete or ready.

    I've been slack on that due to all the servers I use and work on being Apache 1.x still. I'll check some of this out and see exactly how far along it is. If I remember to check back here and update this post, I will let you know what I find. Someone else may post here before then, or by then and fill us in on what they might know of any recent solutions, or in regards to this module. I'm not sure it can limit users resources, and that may be why I lost interest. However, I should check on that! :)
     
  6. chunpal

    chunpal Member

    Joined:
    Dec 13, 2002
    Messages:
    23
    Likes Received:
    0
    Trophy Points:
    1
    Will this work?

    http://www.gsyc.inf.uc3m.es/~assman/jail/

    Friend of mine, he knows about Linux but, he doesn't know anything about WHM/Cpanel.

    Does anyone know about this & Jail&?

    Thanks for the reply and very good document(?)...^_^
    I learn & think a lot...

    Thanks again...
     
  7. Tim Greer

    Tim Greer Well-Known Member

    Joined:
    Aug 11, 2002
    Messages:
    62
    Likes Received:
    0
    Trophy Points:
    6
    [quote:143f7d428e][i:143f7d428e]Originally posted by chunpal[/i:143f7d428e]

    http://www.gsyc.inf.uc3m.es/~assman/jail/

    Friend of mine, he knows about Linux but, he doesn't know anything about WHM/Cpanel.

    Does anyone know about this & Jail&?

    Thanks for the reply and very good document(?)...^_^
    I learn & think a lot...

    Thanks again...[/quote:143f7d428e]

    That is a chroot jail for services like FTP, telnet, SSH. Not the web server (not that I saw anyway).
     
  8. Juanra

    Juanra Well-Known Member

    Joined:
    Sep 22, 2001
    Messages:
    777
    Likes Received:
    0
    Trophy Points:
    16
    Location:
    Spain
    [quote:d7be950171][i:d7be950171]Originally posted by Tim Greer[/i:d7be950171]
    I'll check some of this out and see exactly how far along it is. If I remember to check back here and update this post, I will let you know what I find.[/quote:d7be950171]

    Thanks, that'd be great. All I can find about the perchild module is that nobody knows if it's stable enough yet... I guess it isn't.
     
Loading...

Share This Page