The 2nd article in this series on the principle of least privilege examines privilege escalation and the related risks of users obtaining more or different privileges than the developer of an application intended possible. Vulnerabilities become exploits. Let's look at how this happens.
In Information Security theory the principle of least privilege states that users and processes should only have access to the least amount of information and functions required to do their job. "Vertical" escalation describes an ordinary user assuming the privileges of an administrator, service, or kernel. "Horizontal" escalation is also a concern, as user A might obtain the privileges of user B and gain access to user B's valuable data. De-escalation can also be a concern, where an administrative user that is otherwise segregated or separated from the data accessible to less privileged users obtains their privilege(s) needed to access their data.
Some applications act with the privilege of the user running them. This is usually as it should be. However, some applications such as services (on Windows) or daemons (on *nix systems) may have higher or different privilege levels. Some applications may need to temporarily assume a higher privilege level, then "drop privileges" to that of an ordinary user. Others may interact with a high-privilege level service or part of the OS or kernel.
In the case of an application while it has a higher privilege level, a bug or other vulnerability in the application code may allow a user to act as the application and use its higher privileges to access information that is restricted normally to that user. Often application or system crashes have been used in this way. Buffer overruns, for example, can allow code to be injected by a hacker and this custom code then executes with the higher privileges and accomplishes tasks the user otherwise could not.
In these cases the vulnerability is often discovered by hackers and a proof of concept exploit is created and shown to the developer(s). Hopefully then a patch will be forthcoming to remove the vulnerability.
Carefully architecting security groups and restrictions, segregating users, and isolating tiers or layers of access are design choices that can assist in preventing privilege escalation. Often the root of the problem, as we have seen, is in bugs or errors in operating systems and application coding. What to do about these problems? The simple answer is to test thoroughly, keep your patches current, and when problems are discovered deal with them ASAP. Then next article in the series examines prevention in detail.
The Principle of Least Privilege
This article series explains the Information Security and Computer Science concept of the principle of least privilege. We examine what privileges are, why they are an important concept in multi-user systems, and why this principle is a sound security concept. See examples and means of prevention.
- The Principle of Least Privilege
- Privilege Escalation
- Privilege Escalation Prevention in Practice