Message-ID: <20101208092224.GA1918@sivokote.iziade.m$>
Date: Wed, 8 Dec 2010 11:22:24 +0200
From: Georgi Guninski <guninski@...inski.com>
To: Marsh Ray <marsh@...endedsubset.com>
Cc: full-disclosure@...ts.grok.org.uk, Valdis.Kletnieks@...edu
Subject: Re: verizon vs m$

interesting analysis of 'this thing called "Protected Mode" '

On Tue, Dec 07, 2010 at 02:51:08PM -0600, Marsh Ray wrote:
> On 12/07/2010 07:12 AM, Valdis.Kletnieks@...edu wrote:
> > On Tue, 07 Dec 2010 07:16:34 EST, Larry Seltzer said:
> >>>>> 2. some interpret it as a feature and some as a bug?
> >>
> >>> Does it have to be either?
> >>
> >> It sounds to me as if this is a deliberate design decision, and
> >> people are disagreeing over the severity of its implications.
> >
> > Some people refer to that as a "feee-tchure" or "Broken As Designed".
> > It's technically not a bug, but it does violate the Principle of
> > Least Surprise.
> 
> I say it's a bug.
> 
> See there's this thing called "Protected Mode". Now I don't know about 
> you guys, but that name could lead someone like me to think that it was
> supposed to give you some kind of protection. But whatever it is, it can
> be bypassed by this new Son-of-Stuxnet APT 3.0 exploit technology called
> a "socket".
> 
> > http://windows.microsoft.com/en-us/windows-vista/products/features/communication
> >  Internet Explorer
> > Browse the web with Internet Explorer 7. Protected Mode provides
> > security and data protection for Windows users.
> 
> > http://msdn.microsoft.com/en-us/library/bb250462%28VS.85%29.aspx
> > Understanding and Working in Protected Mode Internet Explorer Summary
> > In Windows Vista, Internet Explorer 7 runs in Protected Mode, which
> > helps protect users from attack by running the Internet Explorer
> > process with greatly restricted privileges.
> > Protected Mode is an important step forward in security for Internet
> > Explorer (IE); it helps protect users from attack by running an IE
> > process with greatly restricted privileges on Windows Vista. While
> > Protected Mode does not protect against all forms of attack, it
> > significantly reduces the ability of an attack to write, alter, or
> > destroy data on the user's machine or to install malicious code.
> 
> So if this thing allows any code running in "Protected Mode" to bridge 
> over to "not Protected mode" with just a local socket and other methods, 
> then what good is it? What then did "Protected Mode" ever protect you 
> from? Attackers who didn't know about local sockets or would never be 
> clever enough to figure it out?
> 
> Consider that Local Intranet Zone will usually do NTLMv2 authentication 
> without any user intervention. Even if he couldn't escape from 
> "Protected Mode", an attacker who can open listening sockets can 
> possibly grab NTLMv2 password hashes for offline cracking, or even 
> forward those authentications to get into lots of other devices which 
> will accept them, e.g. SSL VPNs.
> 
> This is just like UAC. Back when it came out, I thought UAC and the 
> elevation token scheme were the coolest new OS security feature since 
> W^X and ASLR. I gave props to Microsoft for enduring all the negativity 
> they got for UAC. But when I learned that they had exempted their own 
> executables from UAC with an "auto elevate" signature in the mainifest I 
> just couldn't believe it.
> 
> With trembling hands, I clicked on the microsoft.com product features 
> page and there it was: It was clearly promoting UAC and process 
> elevation as a security feature. A Microsoft product turned out not to 
> provide an effective security boundary after all. I was *shocked*.
> On that day, my innocence was forever lost.
> 
> This is, IMHO, disingenuous of them to promote something as a feature 
> which enhances security and then say later "No of course it's not a 
> security boundary, whatever would make you think that?".
> 
> What possible definition of the term "security boundary" would _not_ 
> encompass a facility for "running the Internet Explorer process with 
> greatly restricted privileges" such that it "significantly reduces the 
> ability of an attack to write, alter, or destroy data on the user's 
> machine or to install malicious code"?!
> 
> If process elevation is not a "security boundary", then what does it 
> elevate from, what does it elevate to, and what do you call the 
> difference between them?
> 
> I assume others have reported this by now, but last I checked a year or 
> so ago, some of these "auto elevate" processes in Vista were loading 
> DLLs by names obtained from registry values that were writable by 
> non-elevated tokens.
> 
> If you say something offers "protection" and people pay money to upgrade 
> to this security-as-a-feature, and this "protection" is trivially 
> bypassed, that's a security bug. You should fix it or give people their 
> money back. Don't then say "well we never actually said it was a 
> security boundary".
> 
> - Marsh
> 
> _______________________________________________
> Full-Disclosure - We believe in it.
> Charter: http://lists.grok.org.uk/full-disclosure-charter.html
> Hosted and sponsored by Secunia - http://secunia.com/

_______________________________________________
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