Bug 144361 - CAN-2004-1074 a.out binfmt DoS
Summary: CAN-2004-1074 a.out binfmt DoS
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: Dave Anderson
QA Contact: Brian Brock
URL:
Whiteboard: public=20041111,impact=important
: 144153 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2005-01-06 15:21 UTC by Josh Bressers
Modified: 2007-11-30 22:07 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2005-05-23 21:48:17 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Josh Bressers 2005-01-06 15:21:52 UTC
From the lkml mailing list.
http://www.ussg.iu.edu/hypermail/linux/kernel/0411.1/1222.html

It is possible that an improperly formed a.out binary can cause a
kernel-oops, which if executed in a loop will ead fd's and memory.
It seems that you have to turn on memory overcommit on for this to
work.

davej says we didn't enable a.out binaries on FC3 and RHEL4.  This
will be undone in the future though.

We do not turn on memory overcommit by default in RHEL2.1 or 3.
This should make the impact of this issue significantly mitigated
since it seems the issue is only exploitable when overcommit
is on (sysctl -w vm.overcommit_memory=1).  However note that
we do tell customers how to turn this on.

fixed=2.6.10 (20041116 cset@419aaba8xdR0decwoMnVpt3G8_f8kQ)
not fixed for 2.4 (as at Nov24)

Patch: http://www.ussg.iu.edu/hypermail/linux/kernel/0411.1/1290.html

Comment 3 Dave Anderson 2005-01-07 14:29:23 UTC
I cannot reproduce this problem.  

> try executing this binary:
> perl -e'print"\x07\x01".("\x00"x13)."\xc0".("\x00"x16)'>eout
> (it may be neccessary to turn memory overcommit on before)
>
> This should result in a kernel-oops.
> Doing this in a loop will eat fd's and memory.

I've loaded the binfmt_aout module, and set vm.overcommit_memory,
and created the binary using the supplied perl script:

# uname -r
2.4.21-27.ELsmp
# lsmod | grep binfmt
binfmt_aout             5440   0
# sysctl -w vm.overcommit_memory=1
vm.overcommit_memory = 1
# perl -e'print"\x07\x01".("\x00"x13)."\xc0".("\x00"x16)'>eout
# file eout
eout: 386 executable not stripped
# chmod +x eout
# while true
> do
> ./eout
> done
-bash: ./eout: cannot execute binary file
-bash: ./eout: cannot execute binary file
-bash: ./eout: cannot execute binary file
-bash: ./eout: cannot execute binary file
...
# strace ./eout
strace: exec: Exec format error
execve("./eout", ["./eout"], [/* 30 vars */]) = 0
#




Comment 4 Mark J. Cox 2005-01-10 15:12:52 UTC
See
http://linux.bkbits.net:8080/linux-2.4/cset@41c36fb6q1Z68WUzKQFjJR-40Ev3tw
for the backported fix

Removing [kernel-unsupported] since this allegedly will also affect
elf binaries on ia64 etc.

Comment 5 Dave Anderson 2005-04-26 20:31:11 UTC
How can it be reproduced with an ELF binary on an ia64?


Comment 6 Ernie Petrides 2005-05-23 21:48:17 UTC
I've determined that this was fixed in U5 (in kernel version 2.4.21-27.8.EL)
as well as in the 2nd E5 build (in kernel version 2.4.21-27.0.2.EL).  Here
is the comment associated with the release of that E5 advisory:

"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-043.html"

Obviously, we'd rather have people upgrade to U5 at this point,
which was released with advisory RHSA-2005:294.


Comment 7 Ernie Petrides 2005-05-24 00:06:49 UTC
*** Bug 144153 has been marked as a duplicate of this bug. ***


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