metadata/glsa/glsa-200404-01.xml

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE glsa SYSTEM "http://www.gentoo.org/dtd/glsa.dtd">

<glsa id="200404-01">
  <title>Insecure sandbox temporary lockfile vulnerabilities in Portage</title>
  <synopsis>
    A flaw has been found in the temporary file handling algorithms for the
    sandboxing code used within Portage. Lockfiles created during normal Portage
    operation of portage could be manipulated by local users resulting in the
    truncation of hard linked files; causing a Denial of Service attack on
    the system.
  </synopsis>
  <product type="ebuild">Portage</product>
  <announced>April 04, 2004</announced>
  <revised>April 04, 2004: 01</revised>
  <bug>21923</bug>
  <access>local</access>
  <affected>
    <package name="sys-apps/portage" auto="yes" arch="*">
      <unaffected range="ge">2.0.50-r3</unaffected>
      <vulnerable range="lt">2.0.50-r3</vulnerable>
    </package>
  </affected>
  <background>
    <p>
    Portage is Gentoo's package management system which is responsible for
    installing, compiling and updating any ebuilds on the system through the
    Gentoo rsync tree. Under default configurations, most ebuilds run under a
    sandbox which prevent the build process writing to the &quot;real&quot;
    system outside the build directory - packages are installed into a
    temporary location and then copied over safely by Portage instead. During
    the process the sandbox wrapper creates lockfiles in the /tmp directory
    which are vulnerable to a hard-link attack.
    </p>
  </background>
  <description>
    <p>
    A flaw in Portage's sandbox wrapper has been found where the temporary
    lockfiles are subject to a hard-link attack which allows linkable files to
    be overwritten to an empty file. This can be used to damage critical files
    on a system causing a Denial of Service, or alternatively this attack may
    be used to cause other security risks; for example firewall configuration
    data could be overwritten without notice.
    </p>
    <p>
    The vulnerable sandbox functions have been patched to test for these new
    conditions: namely; for the existance of a hard-link which would be removed
    before the sandbox process would continue, for the existance of a
    world-writable lockfile in which case the sandbox would also remove it, and
    also for any mismatches in the UID ( anything but root ) and the GID (
    anything but the group of the sandbox process ).
    </p>
    <p>
    If the vulnerable files cannot be removed by the sandbox, then the sandbox
    would exit with a fatal error warning the adminstrator of the issue. The
    patched functions also fix any other sandbox I/O operations which do not
    explicitly include the mentioned lockfile.
    </p>
  </description>
  <impact type="normal">
    <p>
    Any user with write access to the /tmp directory can hard-link a file to
    /tmp/sandboxpids.tmp - this file would eventually be replaced with an empty
    one; effectively wiping out the file it was linked to as well with no prior
    warning. This could be used to potentially disable a vital component of the
    system and cause a path for other possible exploits.
    </p>
    <p>
    This vulnerability only affects systems that have /tmp on the root
    partition: since symbolic link attacks are filtered, /tmp has to be on the
    same partition for an attack to take place.
    </p>
  </impact>
  <workaround>
    <p>
    A workaround is not currently known for this issue. All users are advised
    to upgrade to the latest version of the affected package.
    </p>
  </workaround>
  <resolution>
    <p>
    Users should upgrade to Portage 2.0.50-r3 or later:
    </p>
    <code>
    # emerge sync
    
    # emerge -pv ">=sys-apps/portage-2.0.50-r3"
    # emerge ">=sys-apps/portage-2.0.50-r3"</code>
  </resolution>
  <references>
  </references>
  <metadata tag="submitter">plasmaroo</metadata>
</glsa>