Shatter attack

In computing, a shatter attack is a programming technique employed by hackers on Microsoft Windows operating systems to bypass security restrictions between processes in a session. A shatter attack takes advantage of a design flaw in Windows's message-passing system whereby arbitrary code could be injected into any other running application or service in the same session, that makes use of a message loop. This could result in a privilege escalation exploit.[1]

Overview

Shatter attacks became a topic of intense conversation in the security community in August 2002 after the publication of Chris Paget's paper titled, "Exploiting design flaws in the Win32 API for privilege escalation".[2] The paper, which coined the term "shatter attack", explained the process by which an application could execute arbitrary code in another application. This could occur because Windows allows unprivileged applications to send messages to message loops of higher-privileged application - and some messages can have the address of a callback function in the application's address space as its parameter. If an attacker manages to put his own string into the memory of the higher-privileged application (say by pasting shellcode to an edit box) at a known location, they could then send WM_TIMER messages with callback function parameters set to point to the attacker's string.

A few weeks after the publication of this paper, Microsoft responded, noting that: "The paper is correct that this situation exists, and it does correctly describe its effect. ... Where the paper errs is in claiming that this is a flaw in Windows. In reality, the flaw lies in the specific, highly privileged service. By design, all services within the interactive desktop are peers, and can levy requests upon each other. As a result, all services in the interactive desktop effectively have privileges commensurate with the most highly privileged service there."[3]

Solutions

In December 2002, Microsoft issued a patch for Windows NT 4.0, Windows 2000, and Windows XP that closed off some avenues of exploitation.[4] This was only a partial solution, however, as the fix was limited to services included with Windows that could be exploited using this technique; the underlying design flaw still existed and could still be used to target other applications or third-party services.[5] With Windows Vista, Microsoft aimed to solve the problem in two ways: First, local users no longer log into Session 0, thus separating the message loop of a logged-in user's session from high-privilege system services, which are loaded into Session 0. Second, a new feature called User Interface Privilege Isolation (UIPI) was introduced, whereby processes can be further protected against shatter attacks by assigning an Integrity Level to each process.[6] Attempts to send messages to a process with a higher Integrity Level will fail, even if both processes are owned by the same user. However, not all interactions between processes at different Integrity Levels are prevented by UIPI.[6] Internet Explorer 7, for example, uses the UIPI feature to limit the extent to which its rendering components interact with the rest of the system.

The way sessions are instantiated was redesigned in Windows Vista and Windows Server 2008 to provide additional protection against shatter attacks. Local user logins were moved from Session 0 to Session 1, thus separating the user's processes from system services that could be vulnerable.[7][8]

The Interactive Services Detection service in Windows Server 2008.

This creates backward compatibility issues, however, as some software was designed with the assumption that the service is running in the same session as the logged-in user. To support this view, Windows Vista and Windows Server 2008 introduced a Windows service called "Interactive Services Detection" that enables access to dialogs created by interactive services when they appear. The interactive user is shown a dialog box and is offered the ability to switch to Session 0 to access the dialog box.[9] This capability was removed in the Windows 10 Creators Update.[10]

See also

References
  1. "Exploiting design flaws in the Win32 API for privilege escalation. Or... Shatter Attacks - How to break Windows". Retrieved 2011-12-29.
  2. Chris Paget (August 2002). "Exploiting design flaws in the Win32 API for privilege escalation". Archived from the original on 2006-09-04.
  3. "Information About Reported Architectural Flaw in Windows". TechNet. Microsoft. September 2002.
  4. "Microsoft Security Bulletin MS02-071 – Flaw in Windows WM_TIMER Message Handling Could Enable Privilege Elevation (328310)". Microsoft. December 11, 2002. Retrieved 2006-07-18.
  5. "Shatter-proofing Windows" (PDF). Retrieved 2011-12-29.
  6. "PsExec, User Account Control and Security Boundaries". Retrieved 2007-10-08.
  7. "Larry Osterman's WebLog – Interacting with Services". Larry Osterman. September 14, 2005. Retrieved 2007-04-03.
  8. "Why Vista? Changes to services part 2 (Security, Stability, System Integrity)". Ken Schaefer. August 5, 2006.
  9. Cyril Voisin (February 23, 2007). "Services isolation in Session 0 of Windows Vista and Longhorn Server". Cyril Voisin (aka Voy) on security. MSDN Blogs. Retrieved 2008-04-23.
  10. "Features that are removed or deprecated in Windows 10 Creators Update". Microsoft.


This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.