Message-ID: <00e901c306de$45da0bd0$e62d1c41@basement>
Date: Sat, 19 Apr 2003 20:43:40 -0500
From: "Matthew Murphy" <mattmurphy@...rr.com>
To: "Full Disclosure" <full-disclosure@...ts.netsys.com>,
	"BugTraq" <bugtraq@...urityfocus.com>,
	"SecurITeam News" <news@...uriteam.com>,
	"VulnWatch" <vulnwatch@...nwatch.org>
Subject: Race in XP SCM Service Shutdown Mechanism


Race Condition in Windows XP Service Control Manager Service Shutdown
Mechanism

ABSTRACT

"The Windows XP Professional operating system is the best choice for
businesses of all sizes. Windows XP Professional integrates the strengths of
Windows 2000 Professional, such as standards-based security, manageability,
and reliability, with the best business features of Windows 98 and Windows
Millennium Edition, such as Plug and Play, simplified user interface, and
innovative support services. This combination creates the best desktop
operating system for business. Whether your business deploys Windows XP
Professional on a single computer or throughout a worldwide network, this
new operating system increases your computing power while lowering cost of
ownership for desktop computers."

(http://www.microsoft.com/windowsxp/pro/evaluation/features.asp)

"Windows XP Home Edition gives you the freedom to experience more than you
ever thought possible with your computer and the Internet. This is the
operating system home users have been waiting for-because it offers serious
speed and serious stability, so you can have serious fun."

(http://www.microsoft.com/windowsxp/home/evaluation/overviews/default.asp)

DESCRIPTION

"A service application conforms to the interface rules of the Service
Control Manager (SCM). It can be started automatically at system boot, by a
user through the Services control panel applet, or by an application that
uses the service functions. Services can execute even when no user is logged
on to the system."

(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/ba
se/services.asp&hidetoc=true)

The Service Control Manager dispatches several notifications to service
applications, including notifications of imminent system shutdown.  The SCM
reference page contains the following warning:

"The SERVICE_CONTROL_SHUTDOWN control code should only be processed by
services that must absolutely clean up during shutdown, because there is a
limited time (about 20 seconds) available for service shutdown. After this
time expires, system shutdown proceeds regardless of whether service
shutdown is complete. Note that if the system is left in the shutdown state
(not restarted or powered down), the service continues to run.

If the service needs more time to clean up, it should send STOP_PENDING
status messages, along with a wait hint, so the service controller knows how
long to wait before reporting to the system that service shutdown is
complete. However, to prevent a service from stopping shutdown, there is a
limit to how long the service controller will wait. To change this time
limit, modify the WaitToKillServiceTimeout value in the following registry
key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control"

(http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/ba
se/services.asp&hidetoc=true)

During system shutdown, a race condition occurs if service shutdown isn't
correctly completed in a desired time period.  Specifically, open files may
end up with apparently random cached data at the location of the last file
pointer under the service' control for a given file.  The cached data
included files (in my tests) that the given service did not have access to
(running as NT AUTHORITY \ LocalService).  The files included in the data
were file contents recently opened by system administrators.  The files each
had the following ACLs:

Read  Administrators,SYSTEM
Write  Administrators,SYSTEM
Execute  Administrators,SYSTEM
Full Control Administrators,SYSTEM

The service I observed had contents of some files in the Administrator's
home directory appended to log data.  This is an obvious security violation,
but is made worse by the fact that some of these files were readable by
Everyone.  By closely monitoring the contents of known service output files
immediately after a system reboot, sensitive information may be disclosed.

ANALYSIS

This vulnerability requires several concurrent factors for successful
exploitation:

 * Services with shutdown timing errors (found in a default install)
 * Untrusted users with interactive accounts (IUSR_machinename; Terminal
sessions)
 * Output files accessible to low-level users (found in a default install)
 * Cached files with sensitive system details (incidence varies)

WORKAROUND

There are several workarounds that can be implemented, at various levels, to
eliminate this exposure:

* Service developers

Verify that all services shut down appropriately, and send STOP_PENDING SCM
notifications if the service shutdown will not be complete in a given time
period.

* Perimeter security

As successful exploitation requires an interactive (or otherwise locally
privileged) account, privilege escalation can be prevented by blocking
external access by un-trusted users.

* NTFS ACLs

If output files of known vulnerable services can be protected from reading
by outside parties, any sensitive contents will not be disclosed.  For each
such file, set the following ACL:

Read  Administrators,SYSTEM
Write  [LocalService|NetworkService,]Administrators,SYSTEM
Execute  Administrators,SYSTEM
Full Control Administrators,SYSTEM

Systems that are not domain members may be set in a similar manner by
selecting the "Make This Folder Private" checkbox in the properties of any
folder containing potentially sensitive output.

* WaitToKillServiceTimeout Change

Set the service timeout to a larger interval to decrease the likelihood of a
timing error between services and the SCM in the event that services are not
being allotted sufficient time for shutdown.  That said, this requires that
the service properly synchronizes STOP_PENDING notifications ahead of the
timeout.

VENDOR RESPONSE

Microsoft was contacted on March 14, 2003.  This issue should be eliminated
in the up-coming release of Windows Server 2003.  To my knowledge, there are
no plans to backport the fix, presumably due to architectural concerns.

Microsoft's official stance is that sites running mission-critical services
should run the appropriate server operating system (Windows 2000 Server,
Advanced Server, or Datacenter Server), as XP is not designed for these
environments.

Powered by blists - more mailing lists