From owner-freebsd-security Wed Sep 27 11:25:38 2000 Delivered-To: freebsd-security@freebsd.org Received: from smx.pair.com (smx.pair.com [209.68.1.56]) by hub.freebsd.org (Postfix) with SMTP id DB4FF37B440 for ; Wed, 27 Sep 2000 11:24:44 -0700 (PDT) Received: (qmail 7667 invoked by uid 1000); 27 Sep 2000 18:24:43 -0000 Message-ID: <20000927182443.7666.qmail@smx.pair.com> From: sigma@pair.com Subject: Status of FreeBSD-SA-00:41.elf? To: freebsd-security@freebsd.org Date: Wed, 27 Sep 2000 14:24:43 -0400 (EDT) X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org 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 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