Bug 134874 - CAN-2004-1070 binfmt_elf loader vulnerabilities (CAN-2004-1071 CAN-2004-1072 CAN-2004-1073)
CAN-2004-1070 binfmt_elf loader vulnerabilities (CAN-2004-1071 CAN-2004-1072 ...
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: kernel (Show other bugs)
All Linux
medium Severity high
: ---
: ---
Assigned To: Dave Anderson
Brian Brock
: Security
Depends On:
  Show dependency treegraph
Reported: 2004-10-06 17:12 EDT by Josh Bressers
Modified: 2007-11-30 17:07 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-02 06:42:07 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
isec.pl advisory (11.39 KB, text/plain)
2004-10-06 17:14 EDT, Josh Bressers
no flags Details
Current patch being kicked around vendor-sec. (1.56 KB, patch)
2004-10-06 17:19 EDT, Josh Bressers
no flags Details | Diff
RHEL3 patch, adapted from attached 2.6 patch (1.74 KB, patch)
2004-10-07 16:19 EDT, Dave Anderson
no flags Details | Diff
RHEL3 patch adapted from final 2.6 patch (2.06 KB, patch)
2004-11-12 16:28 EST, Dave Anderson
no flags Details | Diff

  None (edit)
Description Josh Bressers 2004-10-06 17:12:20 EDT
Paul Starzetz has repoted to vendor-sec an issue in the Linux ELF
binary loader while handling setuid binaries.  This could lead to
local privilege escalation.

This issue is fairly complicated, I'll attach the advisory which goes
into detail.

This issue is currently embargoed with no date set.
Comment 1 Josh Bressers 2004-10-06 17:14:36 EDT
Created attachment 104867 [details]
isec.pl advisory
Comment 2 Josh Bressers 2004-10-06 17:19:11 EDT
Created attachment 104868 [details]
Current patch being kicked around vendor-sec.

I have no doubt this patch needs some work.  It's against 2.6.
Comment 3 Dave Anderson 2004-10-07 16:19:40 EDT
Created attachment 104915 [details]
RHEL3 patch, adapted from attached 2.6 patch
Comment 4 Dave Anderson 2004-10-07 16:26:38 EDT
The patch was easily adapted to RHEL's 2.4.21-based kernel.

I've run the attached test program, which appears to want the
name of a setuid program as an argument.  However, I get the
same behaviour with and without the patch; i.e., I cannot determine
from the advisory's description how exactly the success/failure
of the patch can be ascertained.
Comment 7 Josh Bressers 2004-11-10 09:24:35 EST
Removing embargo.
Comment 8 Dave Anderson 2004-11-10 09:29:47 EST
Still needinfo as per comment #4.
Comment 9 Mark J. Cox (Product Security) 2004-11-10 10:23:10 EST
Final advisory:
Comment 10 Mark J. Cox (Product Security) 2004-11-10 10:59:57 EST
I believe this issue should be impact=important not moderate, although
it has not been proved that this can allow an easy local privilege
escalation we don't want our rating to be based on the unknown threat
Comment 11 Dave Anderson 2004-11-10 11:20:30 EST
The final advisory has an additional issue #4 that isn't addressed
in the patch supplied in comment #2.  I'm presuming that the idea
is that the kmalloc() should request elf->ppnt->p_filesz + 1 bytes
and then ensure that the last byte is a NULL?

 4) the loaded interpreter section can contain an interpreter name
    string without the terminating NULL:

518:     elf_interpreter = (char *) kmalloc(elf_ppnt->p_filesz,

But then it goes on to say:

4) This bug leads to internal kernel file system functions beeing
called with an argument string  exceeding  the  maximum  path  size 
in length (PATH_MAX). It is not clear if this condition is

That doesn't apply to our RHEL3 kernel, because it does
make an explicit check for > PATH_MAX before the kmalloc:

        if (elf_ppnt->p_filesz > PATH_MAX)
                goto out_free_file;
        elf_interpreter = (char *) kmalloc(elf_ppnt->p_filesz,

(However, I see that AS2.1 does not make that PATH_MAX check)
And my question regarding the testing is that when I run the
test program in the advisory, I get the same outward results
both with and without the patch applied.  

In any case, is there an updated patch that you are aware of?
Comment 14 Mark J. Cox (Product Security) 2004-11-11 08:34:45 EST
Commited upstream:

Comment 15 Dave Anderson 2004-11-11 08:46:26 EST
Outstanding!  Looks like the first one with the additional
NULL-byte stuffing for the additional problem.

Thanks Mark -- I really appreciate the upstream digging!
I'll rework it again for RHEL3.
Comment 17 Dave Anderson 2004-11-12 16:28:30 EST
Created attachment 106607 [details]
RHEL3 patch adapted from final 2.6 patch
Comment 19 Ernie Petrides 2004-11-12 19:14:54 EST
Josh or Mark, is there a CVE # associated with this?
Comment 20 Josh Bressers 2004-11-12 20:18:11 EST
Sadly, there is not.  I'll request one.
Comment 21 Ernie Petrides 2004-11-12 20:23:58 EST
Josh, don't bother.  I just asked so that I would know how to
update the U4 kernel erratum.  (There's no need to create extra
work for ourselves.)
Comment 22 Ernie Petrides 2004-11-12 21:13:55 EST
A fix for this problem has just been committed to the RHEL3 U4
patch pool this evening (in kernel version 2.4.21-25.EL).
Comment 23 Ernie Petrides 2004-11-24 20:31:44 EST
The fix for this problem has also been committed to the RHEL3 E4
patch pool this evening (in kernel version 2.4.21-20.0.1.EL).
Comment 24 Josh Bressers 2004-11-29 14:14:27 EST
Here is the CVE information for this issue.

>>20040920 binfmt_elf loader vulnerabilities
>>      2.4.27 and earlier, 2.6.9 and earlier are vulnerable
>>      http://www.isec.pl/vulnerabilities/isec-0017-binfmt_elf.txt
>>      1&3 Missing return value check may allow memory layout
>>      modification of setuid binaries
  CAN-2004-1070 - missing return value check

>>      2. Incorrect error handling can lead to incorrect mapped image
>>      in memory
  CAN-2004-1071 - incorrect error handling

>>      4. Possible to exceed to the maximum path size of an
>>      interpreter name string which may lead to a denial of service
  CAN-2004-1072 - exceed maximum path size for interpreter name string

>>      5. open_exec() allows reading of non-readable ELF binaries
  CAN-2004-1073 - open_exec reading non-readable ELF binaries
Comment 25 Mark J. Cox (Product Security) 2004-12-02 06:42:07 EST

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