[CVE-2008-5077] SLURM Security Flaw

[Pär Lindfors]

Hi,

There is a privilege escalation in that affects all versions of the "slurm-llnl" (universe) package in Ubuntu. See end of this mail for the announcement to the SLURM lists.

hardy: 1.2.20-1
intrepid: 1.3.6-1
jaunty: 1.3.13-1

The Debian maintainer have built fixed packages that are being uploaded to Debian:

lenny: 1.3.6-1lenny2 (not yet in the Debian archive)
sid: 1.3.15-1

As soon as the Lenny package is in the Debian archive that should be synced to Intrepid.

For Jaunty I suggest syncing the 1.3.15-1 package from Sid, to get them in Jaunty before it is released. The alternative would be to diverge from Debian and package 1.3.14 (1.3.14 is _only_ 1.3.13 + security fix), but this would be more work. As both a SLURM user, and SLURM code contributer I don't consider the changes in between 1.3.14 and 1.3.15 very big. A sync even this close to release should be safe, especially if the alternative is releasing with a known privilege escalation.

For Hardy you can use the nogroups.c apporach, or backport the patch to 1.2.20. Backporting should not be very hard, I could help if needed. However I don't think I will have the time until later this week.

Announcement sent to the SLURM lists:
The attached files will be attached to the bug-report.
======================================================================
Date: Wed, 15 Apr 2009 08:35:09 -0700
To: <email address hidden>, <email address hidden>
From: <email address hidden>
Subject: [slurm-dev] SLURM Security Flaw

A security flaw has been discovered in all releases of SLURM
versions 1.2 and 1.3. This flaw can be exploited by legitimate
users of a computer to increase their privileges based upon
the supplemental groups available to the SLURM daemons.

Description

A vulnerability exists in the current SLURM sbcast implementation.
The result of this flaw is that sbcast may not properly establish
user supplementary groups before opening files for writing, instead
inheriting the supplementary group list from the slurmd daemon,
which may contain system groups with elevated privileges.

Similar logic exists in support of the strigger command. If the
SlurmUser is configured to be root, unprivileged users may execute
a program inheriting the supplementary group list from the slurmctld
daemon, which may contain system groups with elevated privileges.

You can check the current list of supplementary groups that would be
inherited from these daemons by running the following command:

   grep ^Groups /proc/`pidof slurmd`/status
   grep ^Groups /proc/`pidof slurmctld`/status

Impact

A valid SLURM user may be able to write files in directories with
group write access for one of the inherited groups and/or may be able
to overwrite files with similar group write access. Depending upon
system configuration, this may allow a user to gain elevated privileges.

Solution

We are providing four options to fix this problem.

1. Apply the initgroups.patch2 to an existing SLURM version 1.3
   or 1.2 distribution.

2. Install the nogroups.c wrapper to start the SLURM daemons without
   any supplemental groups. This can be used with most configurations
   and no change in the installed SLURM code.

3. Install SLURM version 1.3.14, which is the same as version
   1.3.13 (a very stable release made on 13 January 2009) plus
   initgroups.patch2.

4. Install SLURM version 1.3.15, which includes initgroups.patch2
   plus support for BlueGene/P systems, an assortment of minor
   bug fixes and some minor enhancements.

After performing one of these changes, the SLURM daemons must be
restarted for the change to take effect.

SLURM version 1.4.0-pre12 was also released today for those working
with a beta version of the next major release.
======================================================================

[Pär Lindfors (paran)]

The fixed Debian packages was announced in DSA-1776-1.

The Lenny package apparently got its version bumped to 1.3.6-1lenny3.

[Pär Lindfors (paran)]

Made this bug private, since the DSA is available. (The previous mail to slurm-announce was also public)

[Pär Lindfors (paran)]

The attached debdiffs is between current versions in intrepid and jaunty, and the fixed versions in sid and lenny.

[Jamie Strandboge (jdstrand)]

Marked In Progress according to https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Submission

[Kees Cook (kees)]

Already fixed in Karmic, so I've marked that as closed. For the other releases, we need to have a debdiff against Ubuntu's releases, rather than diffs against Debian's versions. And these need to build and run tested before we can publish them into the archive. For more details: https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation#Patch

[Artur Rona (ari-tczew)]

slurm-llnl (1.3.6-1lenny3build0.8.10.1) intrepid-security; urgency=low

  * fake sync from Debian

slurm-llnl (1.3.6-1lenny3) stable-security; urgency=high

  * Add missing include to prevent ia64 build problems.

slurm-llnl (1.3.6-1lenny2) stable-security; urgency=high

  * Security patch to fix supplementary group flaw

slurm-llnl (1.3.6-1lenny1) testing-security; urgency=high

  * Non-maintainer upload by the Security Team.
  * Fix to crypto/openssl plugin that could result in job launch requests
    being spoofed through the use of an improperly formed credential. This bug
    could permit a user to launch tasks on compute nodes not allocated for
    their use, but will NOT permit them to run tasks as another user.
    This is related to CVE-2008-5077 and DSA 1701 (Closes: #511511)

 -- Jamie Strandboge < <email address hidden>> Wed, 07 Oct 2009 06:51:11 -0500