3571e53040
patches for easier mirroring, to eliminate a special copy, to make www.freebsd.org/security a full copy of security.freebsd.org and be eventually be the same. For now files are just sitting there. The symlinks are missing. Discussed on: www (repository location) Discussed with: simon (so)
148 lines
4.8 KiB
Text
148 lines
4.8 KiB
Text
-----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 <bsdx@looksharp.net>
|
|
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;
|
|
}
|
|
|
|
-----BEGIN PGP SIGNATURE-----
|
|
Version: 2.6.2
|
|
|
|
iQCVAwUBOaq1hlUuHi5z0oilAQGpvgQAoaeqjoU1QppgQ+yXF7KOL6EfTQ9mrdEe
|
|
zKQ6vU//hc1ejKx9C4zmQybflQIpkHS2TMNAfXuvFG74hvETwa8cpVqolJU29CCf
|
|
FKlGTCAGCSzosWrndBuvakKqjeVvvQR4JydVhkO04neVEfbUXkich/2PT+3h3dKW
|
|
GuW3coG8nYE=
|
|
=2w2A
|
|
-----END PGP SIGNATURE-----
|