Bug 157451 - CVE-2005-1263 Linux kernel ELF core dump crash vulnerability
Summary: CVE-2005-1263 Linux kernel ELF core dump crash vulnerability
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel
Version: 3.0
Hardware: All
OS: Linux
medium
high
Target Milestone: ---
Assignee: Ernie Petrides
QA Contact: Brian Brock
URL:
Whiteboard: public=20050511,reported=isec,reporte...
Depends On:
Blocks: 156321
TreeView+ depends on / blocked
 
Reported: 2005-05-11 18:32 UTC by Mark J. Cox
Modified: 2007-11-30 22:07 UTC (History)
8 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-05-25 16:42:39 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2005:472 0 normal SHIPPED_LIVE Important: kernel security update 2005-05-25 04:00:00 UTC

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



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