Re: /etc/crontab.daily and the security hole in find | xargs
Scott K. Ellis [EMAIL PROTECTED] writes: [snip] The only solution is to come up with a program that never follows syslinks, and checks that the i-node of the file it is removing remains the same. Actually, i-nodes can be recycled, so it isn't a good idea to depend on that: % cd /tmp % touch foo % ls -li foo 14 -rw-rw-r-- 1 careycarey 0 Aug 9 17:47 foo % rm foo % touch foo % ls -li foo 14 -rw-rw-r-- 1 careycarey 0 Aug 9 17:48 foo If a program will be creating a file (like /tmp/.X0-lock) but another creates and deletes a file in the same file system just before this, it will probably have the same i-node. -- Carey Evans * [EMAIL PROTECTED] [UNIX] appears to have the inside track on being the replacement for CP/M on the largest microcomputers (e.g. those based on 68000...) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: /etc/crontab.daily and the security hole in find | xargs
-BEGIN PGP SIGNED MESSAGE- On 9 Aug 1997, Carey Evans wrote: The only solution is to come up with a program that never follows syslinks, and checks that the i-node of the file it is removing remains the same. Actually, i-nodes can be recycled, so it isn't a good idea to depend on that: The perl program that the discoverer of this security hole proposed will take care of this. It uses a lot of checks to make sure, the files to be deleted are the ones intended, and checking the inode number is only one of many tests. Unfortunately I forgot the URL where I read about this Nils - -- \ /| Nils Rennebarth --* WINDOWS 42 *-- | Schillerstr. 61 / \| 37083 Göttingen | ++49-551-71626 Micro$oft's final answer | http://www.nus.de/~nils -BEGIN PGP SIGNATURE- Version: 2.6.3i Charset: noconv iQB1AwUBM+xqzVptA0IhBm0NAQFjDQL/ew6F2xXKldFd4jGNfopEyXDcxPmbtmLD SCp8l0zTmb+efcqWeSQx0W/tvZjhq0VEpvYIFoWYtwqXnGaYuZ9X5l6bhzxxsij2 n0Xyc4rSi4hoDbLaL8bpb2qPTWSHz0TW =N8PX -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
/etc/crontab.daily and the security hole in find | xargs
[Sorry if this question has been adressed a zillion times but the search function of the archive seems broken] [Sorry again: I am reading this list through the web-archives and august hasn't appeared yet. Could you CC me] First of all let me thank everybody who has worked on Debian 1.3.1 for all their efforts. It is greatly appreciated. (Using a distribution does make one feel as if somebody else has tinkered with your system though :-)). I was checking out the files in /etc/crontab.daily and there it says above the standard find old tmp files | xargs rm lines something to the effect of These lines commented out because of the obvious security hole. What security hole? The only one I think I can see would be that xargs actually passes it's command line to the shell without properly escaping the filenames it puts in. Regardless of the nature of the hole: Is this fixed somehwere? The above hole would be fixed by making xargs call rm directly I think. Thanks again, Jan -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
Re: /etc/crontab.daily and the security hole in find | xargs
-BEGIN PGP SIGNED MESSAGE- On 7 Aug 1997, Jan Vroonhof wrote: I was checking out the files in /etc/crontab.daily and there it says above the standard find old tmp files | xargs rm lines something to the effect of These lines commented out because of the obvious security hole. What security hole? The only one I think I can see would be that xargs actually passes it's command line to the shell without properly escaping the filenames it puts in. Regardless of the nature of the hole: Is this fixed somehwere? The above hole would be fixed by making xargs call rm directly I think. The problem is that there is a race condition involving running a find | xargs rm or similar command on any world-writable directory. A malicious person could construct a extremely long directory path, and then between the time that find passes the name of the path and the time rm gets around to removing the file, replacing some component of the path with a symlink. This provides the potential to remove any file on the system. This isn't changed by makeing find call rm directly, that only shortens the race. The only solution is to come up with a program that never follows syslinks, and checks that the i-node of the file it is removing remains the same. - -- |Your friends will know you better in the Scott K. Ellis | first minute you meet than your acquaintances [EMAIL PROTECTED] | will know you in a thousand years. | -- Illusions -BEGIN PGP SIGNATURE- Version: 2.6.3a Charset: noconv iQCVAwUBM+oUt6Ck2fENdzpVAQElTgP+KO5TVrpgZpGoIf+sgQ62kklVfzLiqfha YHSoDkFrqpNeFv6eToMBDSL6p9+ccHQD617aSbf3+Tmh4yWIa7J8zqpZoJ17Xzvp p9JWpkDMhFBTAsEvVilUQEyoNYJhR5eEoVVwfDvDa10fBt/9xI5qQZyC1GkBMDaG /8Ixx+YGbnY= =Lpxh -END PGP SIGNATURE- -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word unsubscribe to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] .
