Date: Wed, 27 Sep 2000 14:24:43 -0400 (EDT) From: sigma@pair.com To: freebsd-security@freebsd.org Subject: Status of FreeBSD-SA-00:41.elf? Message-ID: <20000927182443.7666.qmail@smx.pair.com>
next in thread | raw e-mail | index | archive | help
The following advisory went out on August 28, 2000. It indicates that 4.x
and 5.x are fixed, and implies that a fix for 3.x would be forthcoming.
We actually delayed the rollout of 3.5-STABLE for our users based on this
advisory. A month has passed, and I can't find any discussion of this
issue, nor any hint as to what the "logistical difficulties" are that the
advisory mentions.
The patch does in fact seem to work under 3.5-STABLE - at least, the new
kernel runs "fine". But without a malformed ELF executable to try out, I
can't tell if the problem is really fixed.
Does anyone either 1) know how to correctly patch 3.5-STABLE for this
problem, or 2) have a malformed ELF executable handy with which to verify
the problem? I'd like to know the matter is resolved.
Kevin Martin
sigma@pair.com
----- Forwarded message from FreeBSD Security Advisories -----
=============================================================================
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;
}
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-security" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000927182443.7666.qmail>