SecurityReason.com - Our Reason is

Security

Register | Forget Password | Login
SecurityReason
WLB
Services
RSS
Corporate
Note

If you have found a vulnerability, please send to our SecurityAlert Database :
secalert()securityreason()com

Also if you have new ( 0-day ) exploit, please send to our ExploitAlert Archive :
exploit()securityreason()com

Home arrow SecurityAlert Database

Arrow  Topic :

Windows XP Task Scheduler Local Privilege Escalation (Advisory)


Arrow  SecurityAlert : 1137
Arrow  CVE : CVE-2006-3209
Arrow  SecurityRisk : Medium  Security Risk Medium  (About)
Arrow  Remote Exploit : No
Arrow  Local Exploit : Yes
Arrow  Exploit Available : No
Arrow  Credit : zipk0der
Arrow  Published : 28.06.2006

Arrow  Affected Software : Windows XP Task Scheduler



Arrow  Advisory Content :  

From the article:

"Access to the at command varies, on some installations of Windows,
even the Guest account can access it, on others it's limited to
Administrator accounts."

But it's limited to members of the Administrators group by default.
Anyone who is an administrator can make their system insecure by
degrading the permissions to make them less restrictive than the
vendor intended them to be. On any operating system, built on any
security model, ever.

On a system where the administrator either knows what he/she is doing,
or doesn't mess with things that he/she doesn't understand, this does
not appear to be exploitable. And no security model can combat an
incompetent administrator. Consequently, this does not appear to be a
real vulnerability--unless you are saying that there is a bug in
Windows that causes it to sometimes be installed, out of the box, with
the guest user able to use the at command? (That would certainly merit
an advisory, if true, but the paper focuses on how to use the at
command, i.e., on what to do *once* you have obtained SYSTEM access.
Can you give more detailed information about cases where
non-administrative users are able to use the at command?)

I also think that it is misleading to say that SYSTEM can do things
that an administrator can't, since any administrator can execute code
as SYSTEM by installing a service to run as SYSTEM. Even if the task
scheduler is disabled, someone with administrative privileges can
still install system services. All the behavior that the article
describes seems to be by design and none of it seems to constitute a
security threat. Am I wrong?

By the way, on a related note, if the goal is to obtain a SYSTEM
desktop for administrative purposes, a more elegant way to do it is to
install a service that runs cmd.exe as SYSETM (using Microsoft's
instsrv.exe and srvany.exe utilities, search MS Knowledge Base for
more info), and then quit explorer.exe and related applications and
launch explorer.exe from the command prompt. (Or if you are running
Server 2003, I think you can actually run programs as SYSTEM with
RunAs.) This is essentially the same as the method described in the
article, but it doesn't use the task scheduler for a purpose not
relating to the scheduling of tasks, and works even if the task
scheduler is disabled or run with reduced priviledges.

-Eliah

On 6/11/06, zipk0der wrote:
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-=-=
> = Advisory: Windows XP Task Scheduler Local Privilege Escalation
> =
> = Author: Daniel Hückmann (zipk0der) zipk0der (at) pandora-security (dot)
com [email concealed]
> =
> = Released at: http://www.pandora-security.com
> =
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-=-=
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-=-=
>
> 1. Overview.
>
> In Windows XP, the task scheduler service runs as "SYSTEM" (local
service);
> this is akin to running cron as root. Any processes spawned by the
> task scheduler
> inherit "SYSTEM" permissions. Using command line tools, we can kill the
Windows
> desktop (explorer.exe) and restart it running under "SYSTEM". Once
running under
> "SYSTEM" we have full control of the machine, and can do things even
> Administrators
> can't. Also included is a recommended fix. Read the full paper at the
> link below.
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-=-=
>
> Direct link to the original paper discussing this issue in detail...
>
> http://www.pandora-security.com/forum/viewtopic.php?t=2093
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
=-=-=-=
>
> Sincerely,
>
> Daniel Hückmann - R&D Director, Pandora Security





Arrow  Feedback :

If you have additional information or notice any errors regarding this security advisory, please use contact form or email us at info()securityreason()com.
Alert

libc/fnmatch(3) DoS

Security Risk Medium- 2011-05-13

Allow attacker to denial of service apache 2.2.17 server

Apache RSS Apache Alert

» Apache HTTP Server Denial
   of Service Vulnerability

» Multiple Vendors
   libc/fnmatch(3) DoS (incl
   apache poc)

» Apache Continuum
   cross-site scripting
   vulnerability

» Apache Tomcat DoS
   Vulnerability

PHP RSS PHP Alert

» PHP Hashtables Denial of
   Service

» PHP 5.3.6 multiple null
   pointer dereference

» PHP 5.3.6 ZipArchive
   invalid use glob(3)

» libzip 0.9.3
   _zip_name_locate NULL
   Pointer Dereference (incl
   PHP 5.3.5)

ADT

Protect your family and valuables with Home Security Systems

Copyright © SecurityReason.com. All Rights Reserved.