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.
It depends on the degree of isolation between accounts. Simplifying what would otherwise be a quite broad topic:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
