Re: gzip TOCTOU file-permissions vulnerability

From: Dmitry Yu. Bolkhovityanov (bolkhov_at_sky.inp.nsk.su)
Date: 04/16/05

  • Next message: Pavel Kankovsky: "Re: ================================ GNU Core Utilities race condition file-permissions vulnerability ================================ Software: mkdir, mknod, mkfifo Version: Part of GNU Core Utilities 5."
    Date: Sat, 16 Apr 2005 19:06:14 +0700
    To: bugtraq@securityfocus.com
    
    

    On Thu, 14 Apr 2005 devnull@Rodents.Montreal.QC.CA wrote:

    > >> The open() call is at fault here. If instead of being called with a
    > >> mode of RW_USER, it is called with the final intended access mode,
    > >> there is no need to later call chmod(), and the problem is averted.

            Doing open(,,RW_USER) is not a solution: the resulting file's mode
    will be (mode & ~umask), but NOT just `mode'.

            So, either fchmod(,RW_USER) just after open()/creat() is required
    (which seems to be the best practice), or some umask trickery will be
    necessary.

    > > One wrinkle - if the file is not intended to have user write
    > > permission on it, and gzip (unzip/cpio/pax...) initially created it
    > > with the intended permissions, there would be no way to then write
    > > the file.
    >
    > This is not how most Unix variants work: provided you have an
    > open-for-write descriptor on a file, you can write to it as long as the
    > descriptor survives even if the file's permissions deny you write
    > access.
    >
    > In particular, creating a file for write with a mode forbidding writing
    > is not at all impossible.
    >
    > Now, if you're not on a Unix variant, or for all I know even some of
    > the more variant Unix variants, this may not be true. But it certainly
    > is common for this to work fine. Indeed, it's arguably better because
    > it helps prevent others from writing to the file by mistake even during
    > a brief time between open()ing and fchmod()ing.

            Yes, writing to a just-created file with permissions 000 WILL work
    under most Unices. But think about NFS -- since NFS doesn't have
    "sessions"/"states"/"open descriptors", the checks will (or at least can,
    at least in some versions of NFS) be performed upon each write. Thus,
    write() may fail.

            _________________________________________
              Dmitry Yu. Bolkhovityanov
              The Budker Institute of Nuclear Physics
              Novosibirsk, Russia


  • Next message: Pavel Kankovsky: "Re: ================================ GNU Core Utilities race condition file-permissions vulnerability ================================ Software: mkdir, mknod, mkfifo Version: Part of GNU Core Utilities 5."
  • Quantcast