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