Re: [Full-disclosure] verizon vs m$

["Thor (Hammer of God)" <thor@xxxxxxxxxxxxxxx>]

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