This article is rated B-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||||||||||||
|
The below text was removed because it is not a neutral viewpoint.
"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."
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.
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)
This article is rated B-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||||||||||||||
|
The below text was removed because it is not a neutral viewpoint.
"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."
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.
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)