Bug 134874

Created attachment 104867 [details]
isec.pl advisory

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.

Created attachment 104915 [details]
RHEL3 patch, adapted from attached 2.6 patch

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.

Removing embargo.

Still needinfo as per comment #4.

Final advisory:
http://isec.pl/vulnerabilities/isec-0017-binfmt_elf.txt

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
level.

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,
		GFP_KERNEL);       

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
exploitable.

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,
                GFP_KERNEL);

(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?

Commited upstream:

http://linux.bkbits.net:8080/linux-2.6/gnupatch@41925edcVccsXZXObG444GFvEJ94GQ

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.

Created attachment 106607 [details]
RHEL3 patch adapted from final 2.6 patch

Josh or Mark, is there a CVE # associated with this?

Sadly, there is not.  I'll request one.

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.)

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).

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).

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

http://rhn.redhat.com/errata/RHSA-2004-549.html