[ advisories | exploits | discussions | news | conventions | security tools | texts & papers ]
 main menu
- feedback
- advertising
- privacy
- FightAIDS
- newsletter
- news
 
 discussions
- read forum
- new topic
- search
 

 meetings
- meetings list
- recent additions
- add your info
 
 top 100 sites
- visit top sites
- sign up now
- members
 
 webmasters

- add your url
- add domain
- search box
- link to us

 
 projects
- our projects
- free email
 
 m4d network
- security software
- secureroot
- m4d.com
Home : Advisories : Malformed ELF images can cause a system hang

Title: Malformed ELF images can cause a system hang
Released by: FreeBSD
Date: 28th August 2000
Printable version: Click here
-----BEGIN PGP SIGNED MESSAGE-----



=============================================================================

FreeBSD-SA-00:41                                           Security Advisory

                                                                FreeBSD, Inc.



Topic:          Malformed ELF images can cause a system hang



Category:       core

Module:         kernel

Announced:      2000-08-28

Credits:        Adam McDougall 

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.



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

http://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;

     }



-----BEGIN PGP SIGNATURE-----

Version: 2.6.2



iQCVAwUBOaq1hlUuHi5z0oilAQGpvgQAoaeqjoU1QppgQ+yXF7KOL6EfTQ9mrdEe

zKQ6vU//hc1ejKx9C4zmQybflQIpkHS2TMNAfXuvFG74hvETwa8cpVqolJU29CCf

FKlGTCAGCSzosWrndBuvakKqjeVvvQR4JydVhkO04neVEfbUXkich/2PT+3h3dKW

GuW3coG8nYE=

=2w2A

-----END PGP SIGNATURE-----








(C) 1999-2000 All rights reserved.