oss-security - Re: CVE Request -- oprofile -- Local privilege escalation via crafted opcontrol event parameter when authorized by sudo

Openwall GNU/*/Linux 3.0 - a small security-enhanced Linux distro for servers

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Tue, 03 May 2011 00:42:40 +0200
From: Stephane Chauveau <stephane.chauveau@...s-entreprise.com>
To: William Cohen <wcohen@...hat.com>
CC: oss-security <oss-security@...ts.openwall.com>, 
 Jan Lieskovsky <jlieskov@...hat.com>,
 "Steven M. Christey" <coley@...us.mitre.org>, 
 Maynard Johnson <maynardj@...ibm.com>,
 Robert Richter <robert.richter@....com>
Subject: Re: CVE Request -- oprofile -- Local privilege escalation via crafted
 opcontrol event parameter when authorized by sudo

On 05/01/2011 04:00 AM, William Cohen wrote:
> On 04/29/2011 02:16 PM, Jan Lieskovsky wrote:
>> Hello Josh, Steve, vendors,
>>
>>    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
>> [2] https://bugzilla.redhat.com/show_bug.cgi?id=700883
>>
>> Could you allocate a CVE id for this?
>>
>> Thank you&  Regards, Jan.
>> -- 
>> Jan iankko Lieskovsky / Red Hat Security Response Team
>>
>> P.S.: Oprofile is not encouraged to be run under sudo, but still
>>        should not allow escalation of privileges.
> I don't know if this is the best way to fix this issue, but attached is a patch that filters out all but alpha numeric characters and '_'. Feedback on the patch would be appreciated.
>
> -Will
Hello,

unless I am missing something, the problem is only with the eval of $2 
in set_event.

$1 is fine because it always contains a number that cannot be modified 
by the user. If so, a simple patch could be to escape $2:

set_event()
{
    eval "CHOSEN_EVENTS_$1=\$2"
}

Stephane (the original bug reporter)

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.