Bug 157451

Summary:	CVE-2005-1263 Linux kernel ELF core dump crash vulnerability
Product:	Red Hat Enterprise Linux 3	Reporter:	Mark J. Cox <mjc>
Component:	kernel	Assignee:	Ernie Petrides <petrides>
Status:	CLOSED ERRATA	QA Contact:	Brian Brock <bbrock>
Severity:	high	Docs Contact:
Priority:	medium
Version:	3.0	CC:	anderson, davej, jparadis, peterm, petrides, tao, tburke, woodard
Target Milestone:	---	Keywords:	Security
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:	public=20050511,reported=isec,reported=20050510,impact=important
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-05-25 16:42:39 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:
Bug Blocks:	156321

Description Mark J. Cox 2005-05-11 18:32:00 UTC

"A locally exploitable flaw has been found in the Linux ELF binary format
loader's core dump  function  that  allows  local  users  to  gain  root
privileges and also execute arbitrary code at kernel privilege level."

For the full description see
http://www.securityfocus.com/archive/1/397966/2005-05-08/2005-05-14/0

For the proposed patch see bug #157450 (not backported)

Comment 1 Ernie Petrides 2005-05-11 22:14:06 UTC

Associated RHEL4 bug is 157450.

Comment 2 Ernie Petrides 2005-05-11 23:03:11 UTC

Note that RHEL3 (and I believe other RHEL versions) are *not* vulnerable
to privilege escalations because kernels crash when there is an oops.

I have reproduced the crash on RHEL3.  Revised shell archive is in elfbug.sh
(in ~petrides/tests/elfbug.sh).

Comment 3 Ernie Petrides 2005-05-12 00:26:15 UTC

Patch posted for review on 11-May-2005.

Comment 4 Mark J. Cox 2005-05-12 09:54:48 UTC

Note that a sucessful mitigation to this issue is to limit the production of
core files, "ulimit -c 0" placed early during system startup (say from
rc.sysinit) will remove the risk of this issue.

Comment 11 Arjan van de Ven 2005-05-13 19:36:53 UTC

So at minimum we need to warn against changing the setting until there is an
erratum out (which is fair enough)

The stacks issue is true by accident in rhel3 (it wouldn't be true due to there
being GFP_DMA memory below the kernel but.. in rhel3 we don't allow stacks in
GFP_DMA memory). 32 bit wrapping is tricky and probably somewhat hard to pull
off (but in 4g/4g mode it's actually a problem; if the stack is at the top end
of the address range the kernel text is at teh bottom.. .and then copy_from_user
wraps to overwrite kernel memory).

The SMP issue is real though still I think (not in the way the paper describes,
we disabled lcall, but there are countless other issues this way).

The general stack overflow method is also not pretty.
(and before you say it's impossible in practice, I've seen production grade
exploits where they could *reliably* find where the kernel caused a certain
allocation from userspace, since then I no longer consider the "can't find it"
argument real for kernel side things ;( )

Comment 13 Ernie Petrides 2005-05-14 05:24:22 UTC

A fix for this problem has just been committed to the RHEL3 U6
patch pool this evening (in kernel version 2.4.21-32.4.EL).

Comment 16 Ernie Petrides 2005-05-17 22:16:06 UTC

A fix for this problem has also been committed to the RHEL3 E6
patch pool this evening (in kernel version 2.4.21-32.0.1.EL).

Comment 17 Josh Bressers 2005-05-25 16:42:39 UTC

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHSA-2005-472.html