Talk:Shatter attack

Whether a "shatter attack" represents an inherrent design flaw in the Windows API

The below text was removed because it is not a neutral viewpoint.

How is it not NPOV? If someone points out a property of your software which you then go to a great deal of trouble to fix, then you're acknowledging that it needed to be fixed. It's absolutely clear (from postings on the various Microsoft security blogs, for example) that Microsoft's view about the significance of shatter attacks has changed since they said it was "not a flaw in Windows". DavidHopwood 15:11, 8 May 2007 (UTC)

"The introduction of UIPI in Windows Vista could be interpreted as an implicit acknowledgement that Microsoft's earlier viewpoint, that the possibility of shatter attacks was "not a flaw in Windows", was mistaken."

A larger issue to me is that the flaw is an issue only on a program-by-program basis. If a program uses the default message handler, DefWndProc(), for messages like WM_TIMER whose default behavior is to call the passed function pointer, those programs are vulnerable. However, if that program has no need to process that given message, it may well be written by someone wise enough to ignore the message, or flag an error. Further, a given callback pointer can be checked for whether it falls within a program's code space (instead of within data area which it shouldn't be executing in most cases), or just against a list of valid callbacks.

That would not be sufficient. It has to be the right callback. DavidHopwood 15:17, 8 May 2007 (UTC)

It may be argued that the default windows message processing behavior, calling an unchecked code pointer, is undesirable, but any program can defend itself against this. That is, the default behavior is suboptimal, but overridable. So this is certainly a flaw, but is not "broken" as the author of the original exploit claims. If someone knows a way to concisely say the same thing, please add it to the article. — OldMiner 23:17, 22 February 2007 (UTC)

This shouldn't be added to the article because it is wrong. Microsoft did not consider updating every program that could be attacked to be an appropriate fix, and I know of noone else who understands the issue who thinks that it would be an appropriate fix. DavidHopwood 15:17, 8 May 2007 (UTC)

Microsoft's reply was effectively a snarky "it's working as designed" response, and they're right: the Windows UI was designed with the idea that processes cooperate to give an integrated user experience. Only later (with the NT line) were the benefits of proper isolation recognized, but the UI was not updated to this paradigm, since cross-process message passing had become well ensconced.

It's true that to some extent, applications can take measures themselves, but the basic issue is a violation of the principle of least privilege: by default, process A has no business sending messages to process B, certainly not if process B is critical. And even if it does have business sending a message to process B, it still has no business to send arbitrary messages, least of all messages containing pointers. The defense that applications could in theory check some messages does not validate the design, as nobody is seriously suggesting applications should implement their own security layer against an open-ended class of attacks (checking callback pointers in WM_TIMER is all well and good, but it doesn't even begin to cover the problems an application can get into if it's being sent messages it does not expect and cannot distinguish from the messages it does expect).

The fact that Microsoft has closed off some avenues of exploit (in particular with regard to system services) does not imply a reversal of their original point of view: that it's working as designed. They just acknowledged that in particular cases, the design can do with some refinement. That is, shatter attacks are a natural consequence of the design, but while shatter attacks are undesirable, making them altogether impossible requires a completely new design, and that is in itself not desirable. Microsoft's own fixes go so far as to isolate system processes from shatter attacks; that they're doing that doesn't imply they agree that the whole design is flawed, just that it was lacking in execution. 194.151.6.70 08:49, 16 August 2007 (UTC)

---

Second, a new feature called "User Interface Process Isolation" (UIPI), a form of Mandatory Access Control, was introduced, whereby processes can be further protected against shatter attacks by assigning a "privilege level" to each process.

UIPI is not a form of Mandatory Access Control (and Microsoft does not claim it to be such). It is clearly discretionary; there is no serious attempt to prevent the user from overriding it. I've deleted ", a form of Mandatory Access Control" --DavidHopwood 23:37, 4 September 2007 (UTC)

• There's a newer article here. LittleBen (talk) 11:26, 22 January 2013 (UTC)

This attack was dicussed in 1997

In the Microsoft System Journal of March 1997, this attack against NT 4.0 was presented by Matt Pietrek.

http://www.microsoft.com/msj/0397/hood/hood0397.aspx 7eggert (talk) 01:15, 26 February 2013 (UTC)