Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

Will sabotaging a shared web hosting account threaten the security of sibling accounts being that they are shared on the same server?

Whether it it be through htaccess setups, posting login credentials and configuration specifics publicly, or the like, what are the main vulnerabilities a client on shared hosting can face from malicious sibling accounts? Or by their complete noob mistakes.

share|improve this question

3 Answers 3

It depends on the degree of isolation between accounts. Simplifying what would otherwise be a quite broad topic:

No isolation worth the name

The webserver runs as, say, wwwrun:wwwdata, all the websites are group readwritable, accounts are ftp-chrooted into their own webroots. A malicious script on site A is then running as group wwwdata, and may read and write files on other webroots. You could say that such accounts are born compromised.

Still, some small firms that maintain websites for customers (complete outsourcing) might choose to operate this way, since "we're the only ones to access the server". Poor maintenance, disgruntled employees and installation of vulnerable third-party frameworks, usually not in this order, are the main risks. I.e. if customer A wants to not upgrade a heavily firm-customised version of MyNiceBlog 1.0 to security-fixed 1.5 because porting the customizations would be expensive, he's actually endangering all the other sites on the same machine.

Minimum isolation

The webserver runs as above but there are limitations ("safe modes") that try preventing a script from exiting its web jail. The problem is that the process is voluntarily refraining from using some of the rights and powers that it still has. So you need also to remove some functions and features (e.g. executing a shell script) which could lead a malicious script to being able to use again those powers. The site is only marginally more secure, and loses several features and performances in the bargain.

Reasonable isolation

The webserver runs with full permissions, then for each request it receives, it spawns a copy of itself with reduced permissions. Each webroot is then also owned by a specific user with a group of his own, and there is no cross-read access. The user is chrooted into the web site. If everything works as it should, this setup is reasonably secure -- so you must be wary of privilege escalation exploits that might make thing work as they shouldn't. Depending on the platform and software installed, the attack surface may be quite large. Some functions (e.g. loading dynamic modules) might still require blocking.

Also, the processes are not isolated at the network level; so for example any request from site A would be seen from site B as coming from the same host, which can be bad for (say) database servers. If site A has a GRANT ALL PRIVILEGES ON mydb.* TO root@localhost, site B may connect to that database on the same "localhost" with full access and A none the wiser.

Strong isolation

Each webserver instance runs in what amounts to a virtual machine of its own, with independent networking. The sites can't see each other and, if they do, they do so with external IP addresses, so DB server A can't mistake a login request from site B for a request from inside itself. Still, resource contention might be an issue, and connections to the outside might be NATted so that they are indistinguishable. Site A might then send emails pretending to be site B, for example, or it could try and reclaim all available memory, bandwidth or disk I/O slots to negatively affect site A. Some low-level functions might be shared between machines and can be used to mount attacks, e.g. clock and randomness-source reading to defeat authentication schemes.

share|improve this answer
    
There was a an interesting talk about the difficulties of isolating VMs against each other on the Chaos Communication Congress in Germany last December. Virtually Impossible: The Reality Of Virtualization Security. Too long; didn't watch: Virtualization is a lot more complex than it seems. Complexity means room for bugs. Bugs mean attack surface for breaking out of the VM. –  Philipp Feb 27 at 12:45

This is mostly down to the company that provides the shared hosting as obviously the ways that these companies have setup the shared hosting can be different. One potential avenue for attack lies within the filesystem and accounts.

Filesystem Security

A proper multi-user operating system such as Linux is built upon a fundamentally secure approach to user permissions. Files a set of permissions for each file. This is achieved by assigning each file both user and group ownership as well as a set of privileges for three groups of people:

  • User
  • Group
  • Other

As a user on a shared host web server, chances are you won't be able to read, let alone write outside of your home directory. You certainly shouldn't be able to browse the home directory or document root of other users. However there is a fundamental risk in the use of app accounts. Take for example the nobody account to run apache, if someone were to gain the priviliges of nobody, they would have access to the entire servers apache setups. So everyones sites, etc.

share|improve this answer
1  
Your remarks about the nobody account are false. The purpose of the nobody account is to have minimal permissions, and by default the apache configuration files will not be writable by this user –  Slicedpan Feb 27 at 15:15

Often, yes, this is the case.

Depending on the mechanism for account separation in use, attackers may be able to circumvent the protection provided by the host and attack other sites. The security in this area is typically poor enough that most attackers will attempt lateral movement between sites on the same server. It works often enough for them to make it part of their strategy. Here are some of the isolation tiers in use today and the protection they provide. I'll assume apache, since that's what's common. Though these same principles apply with other server software.

Default Setup

If no security customizations are made, the web server will run a a single user ("apache" or "nobody" or "www-data") shared between all sites, while files will be owned by specific FTP users. The intention is to restrict what sort of access the public (apache) has by making sure it doesn't have write access to your files. Unfortunately, this arrangement isn't compatible with most of today's web applications which expect users to be able to upload files, including executable code, allowing the site to self-update, install extensions, and other administrative tasks as performed through the site.

In this configuration, the code running on any one site has the same access to another site's files as that site itself would. This configuration easily leads to compromise for many web applications.

SuExec / FastCGI

With SuExec, CGI applications run under the permissions of the site owner rather than using Apache's own permissions. suPHP and suhosin both extend this behavior to PHP as well (which traditionally does not run as a CGI executable). FastCGI including fcgid also typically provide this same behavior.

Under this regime, files are typically still readable by Apache's user account, but only writable by the site owner's account. This limits most types of lateral moves, but still allows for a limited set of attacks.

One such attack I've observed happens such that the attacker creates symbolic links to the configuration files for other sites on the server, like so:

/home/user1/public_html/foo.txt -> /home/user2/public_html/wp-config.php

The user then browses that file directly, and the configuration it contains (including database passwords) gets displayed to the attacker.

RUID2

A new, experimental Apache module called mod_ruid2 by Kees Monshouwer runs the apache process itself under the user's permissions. This module is now available on cPanel servers, which means it's fairly widely deployed by shared hosting environments. This protects against the attack described above, but does not protect in the face of improper permissions and management, privilege escalation vulnerabilities, and other system-level issues. It's also not compatible with a number of common features and extensions.

Custom isolation setups

It's possible to run the server under an isolation regime using chroot and similar features (such as cgroups) to offer additional isolation and security without the expense of virtualization. This option hasn't traditionally been pursued very far, though.

Virtualization

Without giving each user his own server, giving each user his own virtual server is the next best thing. This is the core of "cloud" hosting, and it offers relatively strong security, but at a pretty high cost.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.