Michal Zalewski wrote: > The First instance of chfn is still holding an open descriptor to > /etc/ptmptmp, which later became /etc/ptmp - and, if we send SIGCONT > to this process, will be renamed to /etc/passwd. Step 3 will fall > through because there is no error checking, and new information will > be written into a descriptor that will de facto become /etc/passwd. If I understand this correctly, ptmp and ptmptmp don't have anything to do with passwd before this rename(ptmp, passwd) call? So, technique of cutting second write of ptmp by killing first chfn process, will not work, not in way you described. chfn 1 will still be working on ptmp, and if you'll kill it, ptmp won't be renamed to passwd, so attack will fail - you'll get modificated ptmp and untouched passwd. But attack is still possible by sending SIGSTOP to second chfn before rename(), writting part of data by first chfn, killing it, and getting back to second chfn, which will rename ptmp to passwd. I'm curious if you were able to reproduce this bug - race condition is very strict here, I think real attack needs a lot of tries. Szemkel
This archive was generated by hypermail 2b30 : Tue Jul 30 2002 - 22:00:58 PDT