Red Hat Bugzilla – Bug 134874
CAN-2004-1070 binfmt_elf loader vulnerabilities (CAN-2004-1071 CAN-2004-1072 CAN-2004-1073)
Last modified: 2007-11-30 17:07:04 EST
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
This issue is currently embargoed with no date set.
Created attachment 104867 [details]
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.
Still needinfo as per comment #4.
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
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)
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?
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
>> 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