COMMAND

    NFS

SYSTEMS AFFECTED

    most unices

PROBLEM

    Jefferson  Ogata  found  following.   He  discovered  (through bad
    code) that certain  NFS implementations will  allow you to  create
    files with a / in  their names.  Obviously, it's  pretty difficult
    to get rid of these files  after the fact.  All UNIX  system calls
    parse paths, and will always treat  a path like "a/b" as the  file
    "b"  in  the  directory  "a",  rather  than  the file "a/b" in the
    current directory.   Not even rm  -r on the  directory could clean
    this up.  This could be used  to create a pretty nasty DoS, if  an
    attacker has  write access  to your  NFS filesystem  (this is more
    common than you might think).

    What would happen  if one created  a file called  "/etc/passwd" in
    the current directory?  If  you created it in, say,  /var/tmp, and
    the system had a root-run cron job that did

        cd /var/tmp; find . -mtime +7 -print | xargs rm -f

    things would get interesting.  A quick scan through  ufs_readdir()
    (in  FreeBSD-current)  indicates  it  will  return  the file name,
    slashes  and  all.  Thus,  anything  calling  unlink() inside of a
    readdir() loop would be in for one hell of a surprise.

SOLUTION

    The only way to  get rid of these  files is by using  the same NFS
    client code that was used  to create them (whew!). Note  that this
    code has  to be  "buggy" in  the sense  that it  doesn't correctly
    parse paths.

    This is a bug in the NFS server implementation.  The NFS  protocol
    does not limit  the character set  that can be  used in filenames,
    but the NFS server MAY restrict it based on the native  filesystem
    it uses to store the files (see RFC 1813).