Can Your Applications Jeopardize Your Security?

Third-party products might allow privilege elevation.

In last week's Security UPDATE Special Edition, I discussed Microsoft's plan to implement a hardware-level security system code-named Palladium. In the commentary, I quoted Chairman and Chief Software Architect Bill Gates' statement that it's "the growth of the Internet and the advent of massive computing systems built from loose affiliations of services, machines, communications networks and application software that have helped create the potential for increased vulnerabilities."

Although Gates' statement seemed to pass the buck to some extent—without admitting in the same breath to his own company's shortcomings—another Microsoft executive let the cat out of the bag. In May, "eWeek" reported that a top Microsoft executive, Jim Allchin, admitted that parts of the company's software contained flaws so dangerous that making those sections of program code public could be a severe blow to Windows security. Both statements leave it to readers to discern that loose affiliations are the necessary nature of current computing—that is, unless we want to let a couple of companies dominate the industry.
http://www.eweek.com/article2/0,3959,5264,00.asp

To facilitate third-party application development, Windows allows considerable flexibility. When third parties develop applications, it's safe to say that they don't have nearly as much information about APIs as Microsoft does. The companies' limited knowledge leads to security-related problems. However, even when Microsoft offers sound advice to third parties, the parties might incompletely register or only partially understand the information offered.

Operational security contexts for system services and desktop applications offer a good case in point. Last week, Chris Paget published a white paper that details how misused security contexts can lead directly to unauthorized elevation of user privileges. In many cases, users—even guest users—can elevate their privileges to those of the built-in System account, which, as you know, is all-powerful.

Paget describes the steps a user can take that lead to the System account security context. The process works as follows: A user first uses a simple program to obtain the windows handle of an application that's operating under the Local System account. The user uses the handle to modify the application's window parameters so that the window will accept a large amount of text from the Windows clipboard. The user then uses the clipboard to paste command-shell code into the window and sends a message to the window that executes the code. After the code executes, the user has access to a command shell running under the Local System account from which the user can perform any desired action. To use Paget's technique, the user must usually have either the ability to coax a user into running a malicious program or physical access to the user's computer. However, Paget said that he could use the technique to gain control over a remote Terminal Server system because the remote server drives those desktops.

Before he published the white paper, Paget notified Microsoft about his findings and his intent to publish them. Microsoft's response noted that the company was aware of the circumstances that could cause the vulnerability and had offered advice that helps mitigate them. Microsoft had previously published an essay titled "The Ten Immutable Laws of Security," in which laws 1 and 3 offer modest advice for third-party developers, but only indirectly. Law 1 states, "If a bad guy can persuade you to run his program on your computer, it's not your computer anymore," and Law 3 states, "If a bad guy has unrestricted physical access to your computer, it's not your computer anymore."

Although both laws state truths and apply to the techniques Paget outlines, they do little to inform developers about the extreme risks associated with running desktop applications and user services under the context of the System account. Unless developers fully realize the risks, they unnecessarily place systems in jeopardy. Paget tested the process of privilege elevation that he describes by exploiting Network Associates' (formerly McAfee's) VirusScan 4.5.1, which opens windows on the desktop under the Local System account.

You can help mitigate the risk of such an exploit by "attacking" your own systems. From the Web page that contains Paget's white paper, you can link to a small application called Shatter, which obtains an application's window handles. You can use Shatter with Netcat, a hexadecimal editor, and a Windows debugging application (also linked in the white paper) to test various applications on your desktop to see whether you can gain elevated privileges.

If you succeed in elevating privileges, you can respond in one of three ways. You can ignore the fact that a given application jeopardizes your security. You can notify the vendor about the situation and insist that the vendor change the application's behavior. Or you can stop using that particular software altogether. You must police applications on your own systems—unless you want Palladium to do it for you.