Shattering Windows: Is a Disaster Lurking?

By Larry Seltzer  |  Posted 2003-10-15 Print this article Print

How big a deal are shatter attacks? They attack Windows at the core of its architecture and fixing them may be impractical. But Security Center Editor Larry Seltzer thinks (hopes?) they're ill-suited to a major attack.

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
Larry Seltzer has been writing software for and English about computers ever since—,much to his own amazement—,he graduated from the University of Pennsylvania in 1983.

He was one of the authors of NPL and NPL-R, fourth-generation languages for microcomputers by the now-defunct DeskTop Software Corporation. (Larry is sad to find absolutely no hits on any of these +products on Google.) His work at Desktop Software included programming the UCSD p-System, a virtual machine-based operating system with portable binaries that pre-dated Java by more than 10 years.

For several years, he wrote corporate software for Mathematica Policy Research (they're still in business!) and Chase Econometrics (not so lucky) before being forcibly thrown into the consulting market. He bummed around the Philadelphia consulting and contract-programming scenes for a year or two before taking a job at NSTL (National Software Testing Labs) developing product tests and managing contract testing for the computer industry, governments and publication.

In 1991 Larry moved to Massachusetts to become Technical Director of PC Week Labs (now eWeek Labs). He moved within Ziff Davis to New York in 1994 to run testing at Windows Sources. In 1995, he became Technical Director for Internet product testing at PC Magazine and stayed there till 1998.

Since then, he has been writing for numerous other publications, including Fortune Small Business, Windows 2000 Magazine (now Windows and .NET Magazine), ZDNet and Sam Whitmore's Media Survey.

Submit a Comment

Loading Comments...
Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel