brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/16/90)
In article <271653D6.1CE8@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: > According to lml@cbnews.att.com (L. Mark Larsen): > >I never much cared for xargs since it limits you to an argument list of > >only 470 bytes. > For the most common use of xargs -- "find ... | xargs command" -- the > script below, called "many", does a good job. Since it doesn't spawn > a subshell, it isn't prone to metacharacter-caused security problems. But it's still susceptible to filenames with carriage returns, and will be until find has a -print0 option. Please, please, please don't claim that your xargs is by any means secure when a standard command like find / -name '#*' -atime +7 -print | xargs rm lets a malicious user remove every file on the system. Maybe it's unreasonable of me to want others to live up to my standard of security, but in my eyes no \n-parsing xargs qualifies as ``a good job.'' Sorry. ---Dan
tif@doorstop.austin.ibm.com (Paul Chamberlain) (10/16/90)
In article <4062:Oct1518:22:1290@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > find / -name '#*' -atime +7 -print | xargs rm >lets a malicious user remove every file on the system. If I understand, to do this a user would have to create a file with a '/' in its name. Is this possible on some systems? The most malicious thing I can do with the above command is remove a file that doesn't start with '#' that's in a writable directory. Twice (I think), you have asserted grave danger with find and xargs. I still don't see it. Paul Chamberlain | I do NOT represent IBM. tif@doorstop, sc30661 at ausvm6 512/838-7008 | ...!cs.utexas.edu!ibmaus!auschs!doorstop.austin.ibm.com!tif
tim@ggumby.cs.caltech.edu (Timothy L. Kay) (10/17/90)
tif@doorstop.austin.ibm.com (Paul Chamberlain) writes: >In article brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >> find / -name '#*' -atime +7 -print | xargs rm >>lets a malicious user remove every file on the system. >If I understand, to do this a user would have to create a file >with a '/' in its name. Is this possible on some systems? >The most malicious thing I can do with the above command is >remove a file that doesn't start with '#' that's in a >writable directory. Let me see. If I create a directory named directory\n and create a file in there called vmunix, then find will spit out a file .../directory\n/vmunix\n which xargs will see as .../directory and /vmunix Tim
tif@doorstop.austin.ibm.com (Paul Chamberlain) (10/19/90)
In article <tim.656101080@ggumby> tim@ggumby.cs.caltech.edu (Timothy L. Kay) writes: >tif@doorstop.austin.ibm.com (Paul Chamberlain) writes: >>In article brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >>> find / -name '#*' -atime +7 -print | xargs rm >>>lets a malicious user remove every file on the system. >> >>The most malicious thing I can do with the above command is >>remove a file that doesn't start with '#' that's in a >>writable directory. > >Let me see. If I create a directory [and file] named > .../directory\n/vmunix Okay, I've had this explained to me and I admit that this could be a problem. But I think it is contrived because the "find" command to pass this filename to xargs either doesn't check the name or allows "vmunix" to match it. I suppose I could create the above and then convince the administrator to do "find /u/tif -print | xargs chown tif". But, then again, wouldn't "ln /etc/passwd /u/tif/my_file" be easier. In any case, I've yet to see how "a malicious user [could] remove every file on the system." Paul Chamberlain | I do NOT represent IBM. tif@doorstop, sc30661 at ausvm6 512/838-7008 | ...!cs.utexas.edu!ibmaus!auschs!doorstop.austin.ibm.com!tif
greywolf@unisoft.UUCP (The Grey Wolf) (10/25/90)
In article <4062:Oct1518:22:1290@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: >In article <271653D6.1CE8@tct.uucp> chip@tct.uucp (Chip Salzenberg) writes: >> According to lml@cbnews.att.com (L. Mark Larsen): >> >I never much cared for xargs since it limits you to an argument list of >> >only 470 bytes. >> For the most common use of xargs -- "find ... | xargs command" -- the >> script below, called "many", does a good job. Since it doesn't spawn >> a subshell, it isn't prone to metacharacter-caused security problems. > >But it's still susceptible to filenames with carriage returns, and will >be until find has a -print0 option. Please, please, please don't claim >that your xargs is by any means secure when a standard command like > > find / -name '#*' -atime +7 -print | xargs rm > >lets a malicious user remove every file on the system. Maybe it's >unreasonable of me to want others to live up to my standard of security, >but in my eyes no \n-parsing xargs qualifies as ``a good job.'' Sorry. > >---Dan Having looked at the output of find and the input of xargs, there is definitely a hole ("NO SHIT, SHERLOCK!") (yeah, I saw the other posts). Just the same, xargs kind of loses functionality if you take away its ability to handle newlines. "find $fs -conditions ... -print | xargs cmd" certainly has more advantages to it than the hole can really offset. If you're worried about the above command running as root, then don't. Or don't use "xargs" in that case, use "-exec rm {} \;". It's that simple. Don't cripple an otherwise very useful command. -- "This is *not* going to work!" "Well, why didn't you say so before?" "I *did* say so before!" ...!{ucbvax,acad,uunet,amdahl,pyramid}!unisoft!greywolf
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (10/30/90)
In article <john.657158675@troch> john@sco.COM (John R. MacMillan) writes: > |find / -name '#*' -print | egrep -v '.*/#[^/]*' | xargs rm -f -- No! Think about links. > So now that we can all safely and automatically remove files I think > we should kill this thread before I embarass myself further. Perhaps people should think about their supposed solutions before posting them. Not to flame, but you're the eighth person to post an insecure pipeline in this thread. Folks, just don't use find | xargs as root until it has -0 to parse nulls and find has -print0 to match. You'll sleep better at night using -exec rm than somebody's supposedly secure pipeline from hell. ---Dan