Bug 49287 (CVE-2004-0138)

<!-- SBZ_reproduce  -->
From: Chris Wright <chrisw@osdl.org> 
To: Mike O'Connor <mjo@dojo.mi.org> 
Cc: vendor-sec List <vendor-sec@lst.de>, markgw@sgi.com 
Date: Tue, 3 Feb 2004 16:22:48 -0800 
Subject: Re: [vendor-sec] Problem with the 2.4 execve() fixes 
 
* Mike O'Connor (mjo@dojo.mi.org) wrote: 
> With those fixes applied (2.4.22+), if a normal user runs an elf 
> program compiled with a dynamic linker whose architecture doesn't 
> match the native arch, the system will oops.  At least this appears 
> to be true for ia64 systems, but it seems likely others are impacted 
> as well.  Here's a recipe to illustrate/demonstrate this problem for 
> one's self: 
> 
> % echo 'main(){;}' > crashme.c 
> % cc -o crashme crashme.c -Wl,--dynamic-linker,/lib/ld-linux.so.2 
> % ./crashme 
 
I've duplicated this here.  As originally pointed out, the elf loader 
gets far enough to recognize the interpreter is bad and returns -ENOEXEC. 
This allows search_binary_handler to continue its search.  This eventually 
gets to the i386 elf code (which is largely stolen from the core elf 
code).  This code erroneously sets up the arg pages with a start and 
end that look like: 
 
vm_start 0x60001000bff78000, vm_end 0xc0000000 
 
This ultimately causes a BUG() when unmapping that vma.  The following 
patch (from 2.6) works well for me.  I've tried this against the 
2.4.25-pre8-ia64 tree, as well as 2.4.25-pre8 on x86.  In both cases, the 
error is caught earlier and turned into a -ELIBBAD return which stops the 
search_binary_handler instead of BUG() on ia64 or userland SEGV on x86. 
 
This patch is already in 2.6, and I'm not clear if issue is exploitable 
since there is a pending SEGV waiting for returning from syscall. 
 
thanks, 
-chris 
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net 
 
===== fs/binfmt_elf.c 1.27 vs edited ===== 
--- 1.27/fs/binfmt_elf.c       Mon Aug 25 22:12:50 2003 
+++ edited/fs/binfmt_elf.c     Thu Jan 29 23:08:42 2004 
@@ -577,6 +577,10 @@ 
       // printk(KERN_WARNING "ELF: Ambiguous type, using ELF\n"); 
       interpreter_type = INTERPRETER_ELF; 
       } 
+      /* Verify the interpreter has a valid arch */ 
+      if ((interpreter_type == INTERPRETER_ELF) && 
+          !elf_check_arch(&interp_elf_ex)) 
+      goto out_free_dentry; 
       } else { 
       /* Executables without an interpreter also need a personality  */ 
       SET_PERSONALITY(elf_ex, ibcs2_interpreter);

Do the gurus agree with the fix?

Since nobody complained, I know committed this fix into the CVS.

<!-- SBZ_reopen -->Reopened by thomas@suse.de at Mon Feb 16 11:42:52 2004

reopen, reassigned for tracking. 

thanks Hubert, the patch looks fine.

Created attachment 16077 [details]
elf-loader-check (9.0-i386)

packages released. 

CVE-2004-0138

The ELF loader in Linux kernel 2.4 before 2.4.25 allows local users to cause a denial of service (crash) via a crafted ELF file with an interpreter with an invalid arch (architecture), which triggers a BUG() when an invalid VMA is unmapped.

CVE-2004-0138: CVSS v2 Base Score: 4.9 (AV:L/AC:L/Au:N/C:N/I:N/A:C)