On Jul 18, 1:06 am, Jesper <Jes...@discussions.microsoft.com> wrote:
> This is probably because of IE Protected Mode, not UAC. The two are related
> in that some of the UAC components provide the plumbing for IE Protected
> Mode, and hence is why it works when UAC is disabled.
>
> What are you trying to accomplish? There may be another way to do it.
> ---
> Your question may already be answered in Windows Vista Security:http://www.amazon.com/gp/product/0470101555?ie=UTF8&tag=protectyourwi-20
>
> "zanbi...@gmail.com" wrote:
> > I have a VB6 app which subclasses the IE7 main window. Works when UAC
> > is disabled, otherwise it fails.
>
> > * Running the app as administrator does NOT fix the problem, oddly
> > enough.
> > * I can subclass any other app under Vista, it's just IE7 that won't
> > work.
>
> > Any thoughts?
>
> > TIA
Just for the record, I found this:
http://blogs.msdn.com/ie/archive/2006/02/09/528963.aspx
* User Interface Privilege Isolation (UIPI) blocks lower-integrity
from accessing higher-integrity processes. For example, a lower-
integrity process cannot send window messages or hook or attach to
higher priority processes This helps protect against "shatter
attacks." A shatter attack is when one process tries to elevate
privileges by injecting code into another process using windows
messages.
Internet-facing applications such as browsers are inherently at a
higher security risk than other applications because they can download
untrustworthy content from unknown sources. IE7's Protected Mode
leverage's Windows Vista's UAC, MIC and UIPI features to boost browser
security. In IE7's Protected Mode-which is the default in other than
the Trusted security zone-the IE process runs with Low rights, even if
the logged-in user is an administrator. Since add-ins to IE such as
ActiveX controls and toolbars run within the IE process, those add-ins
run Low as well. The idea behind Protected Mode IE is that even if an
attacker somehow defeated every defense mechanism and gained control
of the IE process and got it to run some arbitrary code, that code
would be severely limited in what it could do. Almost all of the file
system and registry would be off-limits to it for writing, reducing
the ability of an exploit to modify the system or harm user files. The
code wouldn't have enough privileges to install software, put files in
the user's Startup folder, hijack browser settings, or other
nastiness.
###