Security

Mitigating the privilege escalation threat

Privilege escalation vulnerabilities are not often remotely exploitable, but they can still be among the nastiest vulnerabilities when combined with someone who has managed to gain system access.

Privilege escalation vulnerabilities are not often remotely exploitable, but they can still be among the nastiest vulnerabilities when combined with someone who has managed to gain system access.


My first encounter with privilege escalation vulnerabilities in the 1990s involved the Microsoft Windows NT 4.0 domain scheduler. Any standard user account on the domain could be used to create an instruction to be executed the next time the scheduler was triggered, because a file used to manage scheduler instructions had to be effectively world-readable for the scheduler to operate properly. Such instructions could include adding administrative privileges to an unprivileged user account.

Learning about this vulnerability was quite an eye-opening experience for me. Given the level of control a domain administrator could exercise over individual systems, the simplicity and scope of an exploit of this vulnerability was shocking. Ever since that day, the attitude some people have -- believing that any vulnerability that cannot be exploited remotely is no big deal -- has seemed like the very height of folly. Combine even a sandboxed remote code execution vulnerability with a privilege execution vulnerability, and something that at first seems relatively unimportant can turn into an unmitigated disaster.

The opportunities for privilege escalation are numerous and sometimes surprisingly subtle. While Microsoft Windows has certainly been plagued by such issues over the years, thanks to its nearly nonexistent privilege separation scheme, it is not the sole victim of privilege escalation vulnerabilities, either. In fact, any general purpose operating system offers opportunities for misconfigurations to open privilege escalation holes in the system's security model. One example is misuse of Unix setuid and setgid permissions.

Another example from the Unix world -- and of particular growing concern when dealing with novice-oriented Linux distributions like Ubuntu -- is the misuse of sudo. Executing the command sudo vim opens a text editor that can basically edit any file on the system, of course, but that generally means the program will only edit what you want edited. On the other hand, it might be conceivable that some infection picked up from the Web using your favorite browser could some day take advantage of sudo as a privilege escalation vulnerability in the system's configuration. Maybe the next time you execute sudo vim, the infection in question will make use of Vim's ability to execute shell commands (with root privileges in this case) and will prove the system's undoing.

I do not think this precise example is a likely danger now, but it could easily become a real danger in the future, particularly with the way that the pursuit of greater novice-friendly convenience tends toward misusing the security tools we have available to us and undermining the security benefits of simplicity. We should present security advice as convenience advice, to get people to use security tools to make security more convenient -- and not abuse security tools to try to make the system more convenient to use at the expense of security.

Some good advice for mitigating the threat of privilege separation includes:

  • Be extremely careful when writing new software or modifying existing software to ensure that it does not subvert the system's privilege separation scheme.
  • Run code without administrative privileges as much as possible.
  • Learn everything you can about security tools, how they work, and how they are intended to be used (and why), before using them. For instance, sudo is intended as a tool for making specific, tightly controlled capabilities available to specific users, and not as a root replacement.
  • Maintain as strict a separation between privilege areas as possible. If you can armor your user directory against other users' access, do so, and if you can keep access to the administrative account completely separated from your standard user account at all times, you should do that as well.
  • Use software that gets timely and effective security updates so that any newly discovered privilege escalation vulnerabilities will be fixed as quickly as they become apparent.

Many more possibilities apply as well, and I cannot reasonably attempt to catalog them all for you in this article. This is especially true because, as long as privilege separation is an effective security measure, there will likely be new approaches to privilege escalation attacks appearing from time to time. Understanding something about how privilege escalation can happen, and can make your life miserable, is an important first step toward whittling the danger down, however. Continuing to develop your knowledge of the threat of privilege escalation, and learning to think in terms of not just what your software was meant to do but also how it can be abused by a malicious security cracker, then becomes necessary for doing something useful with that knowledge.

Finally, taking steps to mitigate the consequences of a privilege escalation if it does occur can keep the damage to a minimum. One of the most important pieces of advice along these lines, in my considered opinion, is to treat systems that do not employ a good privilege separation scheme as little more than toys when it comes to protecting yourself against malicious security crackers.

Thinking you are safe just because typical viruses do not do much damage as long as you keep paying for your antivirus subscription misses whole worlds of security threats. The dangers can include cases where you are specifically targeted for whatever reason -- whether it be someone trying to use your server to host a child porn FTP archive or an ex-spouse's hireling or new love interest trying to access your financial records.

About

Chad Perrin is an IT consultant, developer, and freelance professional writer. He holds both Microsoft and CompTIA certifications and is a graduate of two IT industry trade schools.

3 comments
oldbaritone
oldbaritone

And all of the steps are ineffective if 1.the Administrator password is the same as the user password (default in most systems unless you change it) or 2. Low-quality or easily-guessed passwords are used on the Administrator account.

apotheon
apotheon

Password quality is indeed important. I've already written articles about using strong passwords, though, so I focused in other areas with this one. 1.the Administrator password is the same as the user password (default in most systems unless you change it) What do you mean by "most systems" in this case? 2. Low-quality or easily-guessed passwords are used on the Administrator account. Indeed. That certainly is a common problem.