Topic: Malformed ELF images can cause a system hang

Category: core
Module: kernel
Announced: 2000-08-28
Credits: Adam McDougall <[email protected]>
Affects: FreeBSD 3.x, 4.x and 5.x prior to the correction date
Corrected: 2000-07-25 (FreeBSD 5.0-CURRENT)
2000-07-23 (FreeBSD 4.0-STABLE)
FreeBSD only: Yes

I. Background

The ELF binary format is used for binary executable programs on modern
versions of FreeBSD.

II. Problem Description

The ELF image activator did not perform sufficient sanity checks on
the ELF image header, and when confronted with an invalid or truncated
header it suffered a sign overflow bug which caused the CPU to enter
into a very long loop in the kernel.

The result of this is that the system will appear to lock up for an
extended period of time before control returns. This bug can be
exploited by unprivileged local users.

This vulnerability is not present in FreeBSD 4.1-RELEASE, although
3.5-RELEASE and 3.5.1-RELEASE are vulnerable.

III. Impact

Local users can cause the system to lock up for an extended period of
time (15 minutes or more, depending on CPU speed), during which time
the system is completely unresponsive to local and remote users.

IV. Workaround

None available.

V. Solution

One of the following:

1) Upgrade your vulnerable FreeBSD system to 4.1-RELEASE, 4.1-STABLE
or 5.0-CURRENT after the respective correction dates. FreeBSD
3.5-STABLE has not yet been fixed due to logistical difficulties (and
the patch below does not apply cleanly). Consider upgrading to
4.1-RELEASE if this is a concern - this advisory will be reissued once
the patch has been applied to the 3.x branch.

2) Apply the patch below and recompile your kernel.

Either save this advisory to a file, or download the patch and
detached PGP signature from the following locations, and verify the
signature using your PGP utility.

ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:41/elf.patch
ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:41/elf.patch.asc

cd /usr/src/sys/kern

patch -p < /path/to/patch_or_advisory

[ Recompile your kernel as described in
http://www.freebsd.org/handbook/kernelconfig.html and reboot the
system ]

--- imgact_elf.c    2000/04/30 18:51:39     1.75
+++ imgact_elf.c    2000/07/23 22:19:49     1.78
@@ -190,6 +190,21 @@
    object = vp->v_object;
    error = 0;
 
+   /*
+    * It's necessary to fail if the filsz + offset taken from the
+    * header is greater than the actual file pager object's size.
+    * If we were to allow this, then the vm_map_find() below would
+    * walk right off the end of the file object and into the ether.
+    *
+    * While I'm here, might as well check for something else that
+    * is invalid: filsz cannot be greater than memsz.
+    */
+   if ((off_t)filsz + offset > object->un_pager.vnp.vnp_size ||
+       filsz > memsz) {
+           uprintf("elf_load_section: truncated ELF file\n");
+           return (ENOEXEC);
+   }
+
    map_addr = trunc_page((vm_offset_t)vmaddr);
    file_addr = trunc_page(offset);
 
@@ -341,6 +356,12 @@
    }
 
    error = exec_map_first_page(imgp);
+   /*
+    * Also make certain that the interpreter stays the same, so set
+    * its VTEXT flag, too.
+    */
+   if (error == 0)
+           nd.ni_vp->v_flag |= VTEXT;
    VOP_UNLOCK(nd.ni_vp, 0, p);
    if (error)
                 goto fail;
@@ -449,6 +470,17 @@
    /*
     * From this point on, we may have resources that need to be freed.
     */
+
+   /*
+    * Yeah, I'm paranoid.  There is every reason in the world to get
+    * VTEXT now since from here on out, there are places we can have
+    * a context switch.  Better safe than sorry; I really don't want
+    * the file to change while it's being loaded.
+    */
+   simple_lock(&imgp->vp->v_interlock);
+   imgp->vp->v_flag |= VTEXT;
+   simple_unlock(&imgp->vp->v_interlock);
+
    if ((error = exec_extract_strings(imgp)) != 0)
            goto fail;
 
@@ -610,9 +642,6 @@
    imgp->auxargs = elf_auxargs;
    imgp->interpreted = 0;
 
-   /* don't allow modifying the file while we run it */
-   imgp->vp->v_flag |= VTEXT;
-   
 fail:
    return error;
 }