How can low privilege bugs lead to a server compromise?

To address a large number of security concerns, it is often recommended that web applications make effective use of “the principle of least privilege“. The idea is that one should only grant the privileges on the basis that they are needed. In a previous post, I suggested that Kaspersky’s database compromise would not have been so bad if they made better use of separation of privileges on their databases. The fact that the same database user apparently had access to so many SQL tables is what caused concerns for some security professionals. Similarly, correct server permissions might be able to prevent a server compromise when an attacker tries to execute custom PHP or Perl scripts through a vulnerable upload script.

However even with these precautions, a skilled attacker may be able to compromise a server through an SQL injection vulnerability. The truth is that most backend software has traditional security flaws such as buffer overflows. PHP 5.2.8 fixed various buffer overflow bugs that could affect scripts on the server to run arbitrary code in memory. Most database servers have previously issued fixes for memory corruption, for example in 2007, MySQL issued patches for privilege escalation issues. Oracle and MSSQL had their fair share of similar issues.

This leads us to the conclusion that web application security is a process that involves different people. In the case of a custom application, developers need to make it easy for the administrator to implement the principle of least privilege. They also need to test their code to reduce the chances that attackers will not be able to find security flaws in their code. However security does not stop there. The systems administrators need to keep the backends abreast the latest threats. They would also do well to test their servers with security scanners (such as Acunetix) to identify system flaws and to confirm that the web applications were carefully audited. Finally, those making business decisions need to make sure that their options do not jeopardize the security efforts of those designing and implementing their systems.