eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
One of the scarier things Ive read about in security circles is what are called “shatter attacks.” These are software-based attacks that take advantage of a basic architectural flaw in Windows. They utilize flaws in the basic window communications in Windows either for buffer overflows or for privilege escalation.
At a very basic level, GUI events in Windows happen when windows on the screen send messages to each other.(Capital “Windows” means the operating system, small “windows” refers to a window in Windows or any other operating system.) For the most part, windows arent normally programmed any more by application developers. Windows also sends messages to these windows, for instance telling them to redraw themselves when they have been moved around on the screen.
All windows running in the Windows GUI are peers, which means that at the level of window management they are all equal in Windows view, and that they can send messages to each other. Theres no authentication behind these messages, so theres no way to control who can send messages to whom.
Some of these messages can invoke commands; for example, to expand the size of an Edit Control. Heres how someone might invoke a buffer overflow and shatter the window: First the Edit Control is grown by sending data to it, which then overflows the buffer for that Control. Remember, the buffer was sized to the original, smaller version of the Edit Control.
A more scary shatter attack (that has been fixed by Microsoft) uses the WM_TIMER message. This common message has an optional parameter for a callback function, so that the window receiving the message should execute the code pointed to by the message. Any unprivileged process could send a WM_TIMER message to a privileged interactive process and capture its privilege level just by having it call back.
Despite being around for well over a year, shatter attacks havent been much of a real-world problem. Shatter attacks presume an intrusion of attack code on the system, or in other words, a hacker needs to already have an interactive attack program installed and executed on your system in order to begin his or her shatter attack. By the time they can do this, they probably dont need to do the shatter attack in order to have their way with the system, although it could be useful for privilege escalation at that time.
Many industry observers believe that shatter attacks can be solved, at least for the most part, by good programming practices. This means that programmers should be checking buffers. In addition, interactive programs should run at the minimum privilege level necessary. More privileged operations of a program can be run in a background, non-GUI process, such as a Windows service.
At the same time, thats not the end of the line for shatter attacks. A PDF paper from iDefense lists several other ways to exploit windows in a manner similar to the old WM_TIMER method.
Fixing the shatter attack problem at its core would mean making basic changes to Windows. This would end up breaking a large number of existing programs, and we all know thats a no-no. Microsoft can endeavor to fix the callback vulnerabilities over time (really, the bigger problem) and hope that no vulnerability comes along that encourages accompanying shatter attacks. Because if hackers see that opening, weve got a big problem.
Security Center Editor Larry Seltzer has worked in and written about the computer industry since 1983.
More from Larry Seltzer