Re: verizon vs m$

["Thor (Hammer of God)" <thor () hammerofgod com>]

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 () doxpara com] 
Sent: Monday, December 06, 2010 9:07 AM
To: Thor (Hammer of God)
Cc: full-disclosure () lists 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/