[CVE-2008-5077] SLURM Security Flaw

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.
======================================================================