Bug 489808 (CVE-2009-0784) - CVE-2009-0784 systemtap: race condition leads to privilege escalation
Summary: CVE-2009-0784 systemtap: race condition leads to privilege escalation
Keywords:
Status: CLOSED ERRATA
Alias: CVE-2009-0784
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Frank Ch. Eigler
QA Contact:
URL:
Whiteboard:
Depends On: 489969 489970 489978 489979
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-03-11 23:06 UTC by Vincent Danen
Modified: 2023-05-11 13:25 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-03-31 06:56:47 UTC
Embargoed:


Attachments (Terms of Use)
Not a sufficient patch for this bug. (3.09 KB, patch)
2009-03-11 23:36 UTC, Frank Ch. Eigler
no flags Details | Diff
Patch for RHEL5.3 and git/upstream systemtap. (732 bytes, patch)
2009-03-12 00:53 UTC, Frank Ch. Eigler
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2009:0373 0 normal SHIPPED_LIVE Moderate: systemtap security update 2009-03-26 16:01:50 UTC

Description Vincent Danen 2009-03-11 23:06:43 UTC
Erik Sjölund reported a race condition in systemtap where a user in the stapusr group can effectively elevate privileges to group stapdev or root by allowing for the execution of kernel objects outside of the root-owned /lib/modules/$VERSION/systemtap/ directory.  This is due to checkpath() checking the path (the module_realpath variable), but not later using the path to open the file.  Because of this, a user could tell stap to load a kernel module in the current directory that is a symlink to a valid kernel object, and, if able to quickly replace that symlink with one pointing to a malicious kernel object, execute the kernel object outside of the directory they should be restricted to.

Acknowledgements:

Red Hat would like to thank Erik Sjölund for reporting this issue.

Comment 3 Frank Ch. Eigler 2009-03-11 23:36:50 UTC
Created attachment 334872 [details]
Not a sufficient patch for this bug.

This patch forces the canonicalization of the module directory
to be done early, so that only the canonicalized path name is
used for both permission checking and for actual module loading.

Comment 4 Frank Ch. Eigler 2009-03-11 23:42:45 UTC
Comment on attachment 334872 [details]
Not a sufficient patch for this bug.

Note that this patch applies to upstream and recent systemtap versions. I'll post another one against RHEL5.3.

Comment 5 Frank Ch. Eigler 2009-03-12 00:06:33 UTC
Comment on attachment 334872 [details]
Not a sufficient patch for this bug.

Sorry, a simpler patch will fix just this bug; we'll clean up this general area later.

Comment 6 Frank Ch. Eigler 2009-03-12 00:53:33 UTC
Created attachment 334879 [details]
Patch for RHEL5.3 and git/upstream systemtap.

Comment 8 Frank Ch. Eigler 2009-03-12 12:28:55 UTC
RHEL4 (systemtap-0.6.2-1.el4 RPM) is also potentially affected.
The same fix looks like it should fit there too.

Comment 10 Vincent Danen 2009-03-12 14:41:06 UTC
Just to note some factors that need to be in place before this can be exploited (aside from controlling the race condition itself):

- the user must be in the stapusr group
- the /lib/modules/$VERSION/systemtap directory must exist (does not by default)
- there must be a kernel object inside this directory to use to perform the race with

None of these conditions are default, even with systemtap installed.

Comment 20 Tomas Hoger 2009-03-26 07:34:38 UTC
Lifting embargo.

Comment 21 Jan Lieskovsky 2009-03-26 11:48:18 UTC
Common Vulnerabilities and Exposures assigned an identifier CVE-2009-0784 to
this vulnerability:

Race condition in the SystemTap stap tool 0.0.20080705 and
0.0.20090314 allows local users in the stapusr group to gain
privileges via unknown vectors.

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2009-0784
http://www.debian.org/security/2009/dsa-1755

Comment 22 errata-xmlrpc 2009-03-26 16:01:29 UTC
This issue has been addressed in following products:

  Red Hat Enterprise Linux 4
  Red Hat Enterprise Linux 5

Via RHSA-2009:0373 https://rhn.redhat.com/errata/RHSA-2009-0373.html

Comment 23 Tomas Hoger 2009-03-31 06:56:47 UTC
Fedora updates to fixed upstream version 0.9.5:

  https://admin.fedoraproject.org/updates/F9/FEDORA-2009-3106
  https://admin.fedoraproject.org/updates/F10/FEDORA-2009-3152


Note You need to log in before you can comment on or make changes to this bug.