[7055] in bugtraq
Re: {proc,kern}fs bug in FreeBSD (other systems?)
daemon@ATHENA.MIT.EDU (Scott Bartram)
Sat Jun 27 03:39:25 1998
Date: Fri, 26 Jun 1998 16:00:26 -0400
Reply-To: Scott Bartram <scottb@IIS.COM>
From: Scott Bartram <scottb@IIS.COM>
X-To: Brian Feldman <green@FELDMAN.DYN.ML.ORG>
To: BUGTRAQ@NETSPACE.ORG
NetBSD is not vulnerable to this problem.
Brian Feldman wrote:
>
> In keeping compliant with the policies of BugTraq, I first gave the
> developers fair warning and a chance to fix the bugs. As per usual, the
> FreeBSD core team's response time was very quick, and the problem was
> fixed within the first day of reporting it to them. The purpose of this
> message is to alert anyone running FreeBSD (possibly NetBSD and OpenBSD,
> may want to check this out) that there are fixes out, and vulnerable
> systems should be fixed ASAP. The versions that are vulnerable are as
> follows (I am using procfs as the example), other systems should be
> checked out.
>
> FreeBSD 2.2.6-STABLE:
> * @(#)procfs_vnops.c 8.6 (Berkeley) 2/7/94
> *
> * $Id: procfs_vnops.c,v 1.24.2.1 1997/08/12 04:45:27 sef Exp $
>
> This seems to be using older code, and was never vulnerable.
>
> FreeBSD 3.0-CURRENT:
> * @(#)procfs_vnops.c 8.18 (Berkeley) 5/21/95
> *
> * $Id: procfs_vnops.c,v 1.60 1998/06/25 16:54:41 dt Exp $
>
> This is apparently a bug introduced in 4.4BSD-Lite2; this file's two id's
> reflect both that it is from 4.4BSD-Lite2, and that it was fixed in the
> FreeBSD-CURRENT source tree on 6/25/98, after I reported the bug, so
> anyone running 3.0-CURRENT should definitely update their {kern,proc}fs to
> prevent exploitation.
>
> Others:
> The best way to look for this is to try the following:
> grep hungry < `locate procfs_vnops.c`
> And see if there is any reference to the following panic (from a crash
> core bt)
> #1 0xf0119367 in panic (fmt=0xf5740bc8 "kernfs_readdir: not hungry")
> at ../../kern/kern_shutdown.c:423
>
> Any systems using 4.4BSD-Lite2 code should be interested in checking this
> out. Now of course, I can't leave off without revealing the actual
> exploit, now can I? The problem seems to be in the syscall usage of Linux
> programs in the 'emulation', and so far the only program I tested this
> with is RealPlayer 5.0 for Linux/i386. Attempting to browse /proc or /kern
> will cause a crash on a vulnerable system. i.e. "rvplayer /proc/curproc"
> or "rvplayer /kern/hostname".
>
> my->name = "Brian Feldman";
> my->email = "brianfeldman@hotmail.com";
> my->info = finger("green@feldman.dyn.ml.org");