Date: Mon, 6 Dec 2010 17:38:42 +0000
From: "Thor (Hammer of God)" <thor@...merofgod.com>
To: Dan Kaminsky <dan@...para.com>
Cc: "full-disclosure@...ts.grok.org.uk" <full-disclosure@...ts.grok.org.uk>
Subject: Re: verizon vs m$

Dan, as you well know, I'm intimately familiar with this body of research.  You also know I've done more than just "read" it.  Objects shared between LI and HI are architectural requirements. You and other security professionals know this, and you know that PM was obviously not designed as a boundary, but rather a risk mitigation control.  I don't understand why you are continuing to discuss security boundaries - again, that has nothing to do with the article.  Code run within the Intranet zone does not "bypass" PM by default because PM isn't enabled by default.  Now, if one wants to enable it, then just click the box.  When this is done, it mitigates risks as it was designed to, plain and simple.  Are you really worried about the fact that squatting on a kernel object might allow one to subsequently run a process from a trusted object?  I think time would be far better served by preventing the attacker from running code on your box that gives them access to kernel objects in the first place, don't you?  

Please stay on track with what the issue is as presented.  Driving the "not a boundary" bus through PM routes has all the stops it was scheduled to have.   The simple question was, what value is there in detailing a process by which an attacker can gain access to shared objects between access layers when a dependency exists for higher privileged code to be run before hand?  The required privilege of the initial code to execute is already at a level greater than the privilege that the vector could expose in the first place.  If someone controls a country, then the borders between states don't matter. 

Is this not obvious to all those concerned?  

t

-----Original Message-----
From: Dan Kaminsky [mailto:dan@...para.com] 
Sent: Monday, December 06, 2010 9:07 AM
To: Thor (Hammer of God)
Cc: full-disclosure@...ts.grok.org.uk; Georgi Guninski
Subject: Re: [Full-disclosure] verizon vs m$

> Did you read the Reg article?  It has nothing to do with the definition of a "security boundary."  It's not about that at all.  It's about a title tease of "bypassing protected mode" with associated inaccurate content when the whole thing could be summarized with "Protected Mode is not enabled by default in the Intranet zone."  The "boundary" conversation, while interesting, is irrelevant here.
>
> I know times are tough and click-throughs on ads need to be maximized, but I don't think misrepresentation of technical content is appropriate.  I can understand why the Reg would write the article, but I asked Guninski if the reason he posted it was because he considered Protected Mode being disabled by default in the Intranet zone some sort of security issue.

Read the actual research.

===
One vector is through name squatting attacks in the user's "BaseNamedObjects" (BNO) kernel object namespace. In this attack, an object with a fixed name can be created which is then opened by an application that trusts the object not to be malicious by virtue of it existing in the local namespace (which was previously a reasonable assumption). This issue has been given as an example of why Protected Mode is not a security boundary by Microsoft.

Another vector is through leaked or duplicated handles. Access control decisions are made at the point that an object is opened, so existing handles may provide access to resources that are only accessible to more privileged contexts if they are transferred between processes.
Handles in low integrity
processes which have write access rights to higher integrity objects can be considered privileged.
It was through this vector that Skywing escaped from Protected Mode using a leaked handle.

The last vector is through objects which are deliberately shared between low integrity processes and higher integrity processes. This includes the Window Station kernel object which is shared between all processes within the same interactive logon session. With full access to the Window Station, low integrity processes also have access to the Global Atom Table, Window Station properties, the user's clipboard and the "\Default" Desktop object. Such objects can be detected through a tool written as part of this research that locates objects open in low and higher integrity processes; to determine if two handles refer to the same object, the kernel mode pointers to the object's data structure are compared.

The Global Atom Table is used to store both integers and strings which are each indexed by an integer.
A simple fuzzer was created to fuzz this table, which only caused a null pointer dereference in "Process Explorer" and corruption of Internet Explorer UI elements. Dynamic Data Exchange (DDE) inter-process communication occurs through the Global Atom Table and this may be subject to more interesting attacks via malicious atom table manipulation.28 Internet Explorer also uses the Global Atom Table heavily, but it would seem mostly for User Interface related functionality.
===

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/

Powered by blists - more mailing lists