From: mvp at joeware.net (joe)
Subject: MS Windows Screensaver Privilege Escalation

This vector has been out there since Windows NT has had screen savers, it
isn't quite as easy to take advantage of though. Not sure why this is being
published now like it is a new discovery as it has been extremely well known
in Windows circles for years and years and well years and years. I think I
first saw it mentioned in a trade rag probably in 1996 or 1997. I guess it
is good to have it "officially" documented within securityfocus... Heh.


Anyway...

> with a specially crafted version designed to execute programs

The screensavers shipped with Windows are handled by WFP. While this isn't a
security mechanism, it can slow someone down since they can't just replace
the files with an arbitrary piece of code without defeating WFP. One method
is to use some other WFP file in its place as that won't get updated, say
CMD. 


> This level is not accessible even to administrators.

This is incorrect, it isn't that it isn't accessible, it is that an admin
running in admin context can't normally access some info localsystem can
unless ACL's have been modified/relaxed to allow that access. At any point
in time, there are multiple ways that an admin can elavate into localsystem
context. Actually as you see below, it doesn't take admin to elevate into
localsystem and it doesn't take waiting for a screen saver exploit to do it.


> by default, any user with the exception of guest can replace 
> the login screensaver file with a modified version.

Well this isn't really correct unless your file system perms are dorked up.
Default ACLs should give power users the ability to modify these files but
not normal users, they are maintained in the system32 folder. And again, if
the SCR is the one from the main dist, well you have WFP to deal with. 

I agree that is still too wide open. You could lock down the permissions on
the file system so that PU can't do this pretty easily. However MS has
already admitted in KB that power users can escalate their perms. There are
multiple vectors for it, anyone with an understanding of how Windows works
and takes a moment to look at ACLs could find at least three vectors within
15 minutes to get an elevation. You could probably go through and lock all
of those ACLs down but at that point, you might as well just make someone
run as a user instead of a poweruser. Faster, easier, better.

http://support.microsoft.com/?kbid=825069


I am not playing down that this isn't the best default configuration/design,
but this certainly isn't some new thing that anyone needs to get hopped up
about. I don't see or expect any worms coming around the corner having to do
with anything about this.


  joe



-----Original Message-----
From: full-disclosure-admin@...ts.netsys.com
[mailto:full-disclosure-admin@...ts.netsys.com] On Behalf Of Matthew Walker
Sent: Wednesday, November 24, 2004 12:36 PM
To: full-disclosure@...ts.netsys.com
Subject: [Full-Disclosure] MS Windows Screensaver Privilege Escalation

To Whom it May Concern;
The Original Post is http://www.securityfocus.com/bid/11711

On Windows XP all releases, when you replace, or change the screensaver
displayed on the login screen with a specially crafted version designed to
execute programs, those programs are launched under the SYSTEM SID, IE: they
are given automatically the highest access level avalible to Windows.  This
level is not accessible even to administrators.

This flaw is important because while one would need Power User privledges or
above to change the Login Screensaver, by default, any user with the
exception of guest can replace the login screensaver file with a modified
version.  In theory, any determined user could execute ANYTHING with SYSTEM
privledges.  A similar flaw exists in Win2K, but Microsoft has ignored it.

Sincerly;
Matt Walker

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.netsys.com/full-disclosure-charter.html

Powered by blists - more mailing lists