From owner-doc-jp@jp.freebsd.org  Sun Sep  3 09:24:29 2000
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id JAA86677;
	Sun, 3 Sep 2000 09:24:29 +0900 (JST)
	(envelope-from owner-doc-jp@jp.FreeBSD.org)
Received: from sv01.geocities.co.jp (sv01.geocities.co.jp [210.153.89.155])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id JAA86672
	for <doc-jp@jp.freebsd.org>; Sun, 3 Sep 2000 09:24:28 +0900 (JST)
	(envelope-from hrs@geocities.co.jp)
Received: from mail.geocities.co.jp (mail.geocities.co.jp [210.153.89.137]) by sv01.geocities.co.jp (8.9.3+3.2W/3.7W) with ESMTP id JAA06349 for <doc-jp@jp.freebsd.org>; Sun, 3 Sep 2000 09:24:28 +0900 (JST)
Received: from mail.hrs.jp (sutnmax1-ppp17.ed.noda.sut.ac.jp [133.31.173.27]) by mail.geocities.co.jp (1.3G-GeocitiesJ-3.3) with ESMTP id JAA27944 for <doc-jp@jp.freebsd.org>; Sun, 3 Sep 2000 09:24:25 +0900 (JST)
Message-Id: <200009030024.JAA27944@mail.geocities.co.jp>
Received: from localhost (alph.hrs.jp [192.168.0.10])
	by mail.hrs.jp (8.9.3/3.7W/DomainMaster) with ESMTP id JAA09980
	for <doc-jp@jp.freebsd.org>; Sun, 3 Sep 2000 09:11:23 +0900 (JST)
	(envelope-from hrs@hrs.jp)
To: doc-jp@jp.freebsd.org
In-Reply-To: <20000828194347.2D1A537B662@hub.freebsd.org>
References: <20000828194347.2D1A537B662@hub.freebsd.org>
X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit
Date: Sun, 03 Sep 2000 09:11:22 +0900
From: Hiroki Sato <hrs@geocities.co.jp>
X-Dispatcher: imput version 990905(IM130)
Lines: 210
Reply-To: doc-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: doc-jp 7657
Subject: [doc-jp 7657] Re: ANNOUNCE: FreeBSD Security Advisory: FreeBSD-SA-00:41.elf
Errors-To: owner-doc-jp@jp.freebsd.org
Sender: owner-doc-jp@jp.freebsd.org
X-Originator: hrs@geocities.co.jp

$B:4F#!wEl5~M}2JBg3X$G$9!#(B

 FreeBSD-SA-00:41.elf $B$NK]Lu$G$9!#(B

NOTES:
------

 1) a sign overflow bug

   $B$$$^$$$A$I$&$$$&F0:n$J$N$+$o$+$j$^$;$s!#(B
   
    # sign $B$OId9f$H$7$F$^$9$,!"(B
    # $B$J$s$+0c$&$h$&$J5$$,$7$^$9!#(B

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

 $B$3$N%a!<%k$O(B, announce-jp $B$KN.$l$?(B

  Subject: ANNOUNCE: FreeBSD Security Advisory: FreeBSD-SA-00:41.elf
  From: FreeBSD Security Advisories <security-advisories@freebsd.org>
  Date: Mon, 28 Aug 2000 12:43:47 -0700 (PDT)
  Message-Id: <20000828194347.2D1A537B662@hub.freebsd.org>
  X-Sequence: announce-jp 513

 $B$rF|K\8lLu$7$?$b$N$G$9(B. 

 $B86J8$O(B PGP $B=pL>$5$l$F$$$^$9$,(B, $B$3$NF|K\8lLu$O(B PGP $B=pL>$5$l$F$$$^$;$s(B. 
 $B%Q%C%AEy$NFbMF$,2~cb$5$l$F$$$J$$$3$H$r3NG'$9$k$?$a$K(B PGP $B$N%A%'%C%/$r(B
 $B9T$J$&$K$O(B, $B86J8$r;2>H$7$F$/$@$5$$(B. 

 $BF|K\8lLu$O(B FreeBSD $BF|K\8l%I%-%e%a%s%F!<%7%g%s%W%m%8%'%/%H(B(doc-jp)$B$,;29M$N(B
 $B$?$a$KDs6!$9$k$b$N$G(B, doc-jp $B$O(B $B$=$NFbMF$K$D$$$F$$$+$J$kJ]>Z$b$$$?$7$^$;$s(B.
 $BF|K\8lLu$K$D$$$F$N$*Ld$$9g$o$;$O(B doc-jp@jp.FreeBSD.org $B$^$G$*4j$$$7$^$9(B.

--($B$3$3$+$i(B)
=============================================================================
FreeBSD-SA-00:41                                           Security Advisory
                                                                FreeBSD, Inc.

$B%H%T%C%/(B:       Malformed ELF images can cause a system hang

$BJ,N`(B:           core
$B%b%8%e!<%k(B:     kernel
$B9pCNF|(B:         2000-08-28
$B%/%l%8%C%H(B:     Adam McDougall <bsdx@looksharp.net>
$B1F6AHO0O(B:       FreeBSD 3.x, 4.x and 5.x prior to the correction date
                $B=$@5F|0JA0$N(B FreeBSD 3.x, 4.x $B$*$h$S(B 5.x
$B=$@5F|(B:         2000-07-25 (FreeBSD 5.0-CURRENT)
                2000-07-23 (FreeBSD 4.0-STABLE)
FreeBSD $B$K8GM-$+(B:   Yes

I.   $BGX7J(B - Background

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

ELF $B%P%$%J%j%U%)!<%^%C%H$O(B, $B:G6a$N%P!<%8%g%s$N(B FreeBSD $B$K$*$$$F(B
$B<B9T2DG=$J%P%$%J%j%W%m%0%i%`$K;H$o$l$F$$$k$b$N$G$9(B.

II.  $BLdBj$N>\:Y(B - 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.

ELF $B%$%a!<%8<B9T%k!<%A%s$O(B ELF $B%$%a!<%8%X%C%@$KBP$7$F(B
$B@5Ev@-$N%A%'%C%/$r==J,$K9T$J$C$F$$$^$;$s$G$7$?(B.
$B$=$N$?$a(B, $BM-8z$G$J$$%X%C%@$d@Z$j5M$a$i$l$?%X%C%@$,M?$($i$l$k$H(B,
$BId9f%*!<%P%U%m!<%P%0$N1F6A$r<u$1(B, CPU $B$,%+!<%M%kFb$GHs>o$KD9$$(B
$B%k!<%W$K4Y$C$F$7$^$$$^$9(B.

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.

$B$=$N7k2L(B, $B%7%9%F%`$O@)8f$,La$k$^$G$KHs>o$KD9$$;~4V%m%C%/$7$?$h$&$K(B
$B8+$($^$9(B.  $B$3$N%P%0$O(B, $B9b$$8"8B$r;}$?$J$$%m!<%+%k%f!<%6$K$h$C$F(B
$B0-MQ$5$l$k4m81@-$,$"$j$^$9(B.

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

$B$3$N%;%-%e%j%F%#>e$N<eE@$O(B 3.5-RELEASE $B$H(B 3.5.1-RELEASE $B$KB8:_$7(B,
FreeBSD 4.1-RELEASE $B$K$OB8:_$7$^$;$s(B.

III. $B1F6AHO0O(B - 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.

$B%m!<%+%k%f!<%6$OHs>o$KD9$$;~4V(B (CPU $BB.EY$K0MB8$7$^$9$,(B, 15 $BJ,4V$+$=$l0J>e(B)
$B%7%9%F%`$r%m%C%/$9$k$3$H$,$G$-$^$9(B.  $B%m%C%/$7$F$$$k4V(B, $B%7%9%F%`$O(B
$B%m!<%+%k%f!<%6(B, $B%j%b!<%H%f!<%6$NN>J}$KBP$7$F40A4$K1~Ez$G$-$J$/$J$j$^$9(B.

IV.  $B=$@5=hCV(B - Workaround

None available.
$B$"$j$^$;$s(B.

V.   $BBP1~:v(B - Solution

One of the following:
$B<!$N$$$:$l$+$K=>$C$F$/$@$5$$(B.

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.

1) $B%;%-%e%j%F%#>e$N<eE@$r4^$`(B FreeBSD $B%7%9%F%`$r(B, $B=$@5F|0J9_$N(B
   4.1-RELEASE, 4.1-STABLE, 5.0-CURRENT $B$N$$$:$l$+$K(B
   $B%"%C%W%0%l!<%I$7$F$/$@$5$$(B.  FreeBSD 3.5-STABLE $B$O=$@5$NE,MQ$,(B
   $B:$Fq(B ($B0J2<$N=$@5%Q%C%A$O$-$A$s$HE,MQ$G$-$^$;$s(B) $B$G(B,
   $B$^$@=$@5HG$O:n@.$5$l$F$$$^$;$s(B.  $B$3$l$,=EMW$JLdBj$H$J$k$h$&$J$i(B,
   4.1-RELEASE $B$X$N%"%C%W%0%l!<%I$r9MN8$7$F$/$@$5$$(B.
   $B$3$N4+9p$O(B, 3.x $B%V%i%s%A$X=$@5%Q%C%A$,E,MQ$5$l$?8e$K:FH/9T$5$l$kM=Dj$G$9(B.

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.

2) $B0J2<$N=$@5%Q%C%A$rE,MQ$7$F%+!<%M%k$r:F9=C[$7$F$/$@$5$$(B.

$B$3$N4+9p$r%U%!%$%k$KJ]B8$9$k$+(B, $B0J2<$N>l=j$+$i=$@5%Q%C%A$r(B
$B%@%&%s%m!<%I$7$F(B PGP $B=pL>$r<h$j=P$7(B, PGP $B%f!<%F%#%j%F%#$G=pL>$r3NG'$7$^$9(B.

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 ]

[ http://www.freebsd.org/handbook/kernelconfig.html
  $B$K=q$+$l$F$$$k$h$&$K$7$F%+!<%M%k$r:F9=C[$7(B, $B%7%9%F%`$r:F5/F0$7$^$9(B. ]

    --- 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;
     }
