COMMAND

	File-lock handling

SYSTEMS AFFECTED

	 Win NT 4

	 Win 2000

	 Possibly others

PROBLEM

	3APA3A discusses about file locks  using  Microsofts  OSes,  leading  to
	local DoS - as published on BugTraq :
	

	

	 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) 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...
	

	...
	

	

	 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 

	

	

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

	

	

	------------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--

	

	

SOLUTION

	 -=-=- \"Microsoft Security Response Center\"  -=-=-

	

	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.
	

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