force mode (Was: RE: more thoughts on Samba permissions manip

David Collier-Brown davecb at canada.sun.com
Mon Jun 21 12:16:00 GMT 1999


ejajko at corp.auspex.com [SMTP:ejajko at corp.auspex.com] wrote:
> > And this sounds like the biggest security hole yet ;)
  [In reference to saving and recreating the file]

 Cole, Timothy D. wrote:
 >       I'm not exactly sure how exploitable that would in fact be; at
> worst, if the other party won the race, the rename would either nuke their
> link, or fail.  And of course the permissions would remain the same, so they
> wouldn't exactly get access to anything that they didn't have before.  In
> any case, some NFS implementations do something like this anyway (for
> different reasons).

	Agreed: we're looking for a race-condition attack in
	delete p 
	create p

	where delete p::=
		link  p q
		actually delete p
	and create p ::=
		if p identically equal q
		mv p q

	There is no new window within the operations of delete and create,
	so the risk is where you'd expect it, between them.

	The attack is to move a new file , r, into the place of p
	However, to have the permissions to do that means you have 
	permissions to do "mv r p".  

	This reduces it to a quality-of-implementation problem, ensuring
	that the deleted file isn't placed into some more general trachcan
	where someone might inadvertently grab q during the window, causing
	an unintentional deletion of all the permissions and links.

--dave
[Pretending to be my "evil twin", an academic colleague with a similar
name who insists on working gall problems out from first principles
every
time they're raised]
-- 
David Collier-Brown,  | Always do right. This will gratify some people
185 Ellerslie Ave.,   | and astonish the rest.        -- Mark Twain
Willowdale, Ontario   | http://java.science.yorku.ca/~davecb
Work: (905) 477-0437 Home: (416) 223-8968 Email: davecb at canada.sun.com


More information about the samba-technical mailing list