Bug 157451 - CVE-2005-1263 Linux kernel ELF core dump crash vulnerability
CVE-2005-1263 Linux kernel ELF core dump crash vulnerability
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
3.0
All Linux
medium Severity high
: ---
: ---
Assigned To: Ernie Petrides
Brian Brock
public=20050511,reported=isec,reporte...
: Security
Depends On:
Blocks: 156321
  Show dependency treegraph
 
Reported: 2005-05-11 14:32 EDT by Mark J. Cox (Product Security)
Modified: 2007-11-30 17:07 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-25 12:42:39 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Mark J. Cox (Product Security) 2005-05-11 14:32:00 EDT
"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 18:14:06 EDT
Associated RHEL4 bug is 157450.
Comment 2 Ernie Petrides 2005-05-11 19:03:11 EDT
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-11 20:26:15 EDT
Patch posted for review on 11-May-2005.
Comment 4 Mark J. Cox (Product Security) 2005-05-12 05:54:48 EDT
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 15:36:53 EDT
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 01:24:22 EDT
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 18:16:06 EDT
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 12:42:39 EDT
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.