Add 'metadata/glsa/' from commit 'aacff3c55fb52643f95332002ecdb7d439b8e4df'

git-subtree-dir: metadata/glsa
git-subtree-mainline: 3149e13ab601ad3a8f925656fd88567d2626de47
git-subtree-split: aacff3c55fb52643f95332002ecdb7d439b8e4df

1 files changed, 93 insertions, 0 deletions

diff --git a/metadata/glsa/glsa-200404-01.xml b/metadata/glsa/glsa-200404-01.xml
new file mode 100644
index 000000000000..e852dcf39c4e
--- /dev/null
+++ b/metadata/glsa/glsa-200404-01.xml
@@ -0,0 +1,93 @@
+<?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>