From owner-freebsd-security@FreeBSD.ORG Sat Sep 18 04:09:28 2004 Return-Path: Delivered-To: freebsd-security@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 05C0516A4CE for ; Sat, 18 Sep 2004 04:09:28 +0000 (GMT) Received: from avscan2.sentex.ca (avscan2.sentex.ca [199.212.134.19]) by mx1.FreeBSD.org (Postfix) with ESMTP id A07DE43D49 for ; Sat, 18 Sep 2004 04:09:27 +0000 (GMT) (envelope-from mike@sentex.net) Received: from localhost (localhost.sentex.ca [127.0.0.1]) by avscan2.sentex.ca (8.12.11/8.12.11) with ESMTP id i8I49SYh034693 for ; Sat, 18 Sep 2004 00:09:28 -0400 (EDT) (envelope-from mike@sentex.net) Received: from avscan2.sentex.ca ([127.0.0.1]) by localhost (avscan2.sentex.ca [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 34623-01 for ; Sat, 18 Sep 2004 00:09:28 -0400 (EDT) Received: from lava.sentex.ca (pyroxene.sentex.ca [199.212.134.18]) by avscan2.sentex.ca (8.12.11/8.12.11) with ESMTP id i8I49SPJ034667 for ; Sat, 18 Sep 2004 00:09:28 -0400 (EDT) (envelope-from mike@sentex.net) Received: from simian.sentex.net (simeon.sentex.ca [192.168.43.27]) by lava.sentex.ca (8.12.11/8.12.11) with ESMTP id i8I49IDf033358 for ; Sat, 18 Sep 2004 00:09:19 -0400 (EDT) (envelope-from mike@sentex.net) Message-Id: <6.1.2.0.0.20040918001332.02bfda70@64.7.153.2> X-Sender: mdtpop@64.7.153.2 (Unverified) X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 Date: Sat, 18 Sep 2004 00:15:28 -0400 To: freebsd-security@freebsd.org From: Mike Tancsa Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Virus-Scanned: by amavisd-new X-Virus-Scanned: by amavisd-new at avscan2b Subject: Fwd: FreeBSD kernel buffer overflow X-BeenThere: freebsd-security@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Security issues [members-only posting] List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2004 04:09:28 -0000 Can anyone provide more details about the posting below ? >Mailing-List: contact bugtraq-help@securityfocus.com; run by ezmlm >List-Id: >List-Post: >List-Help: >List-Unsubscribe: >List-Subscribe: >Delivered-To: mailing list bugtraq@securityfocus.com >Delivered-To: moderator for bugtraq@securityfocus.com >Date: Thu, 16 Sep 2004 23:48:21 +0200 >From: gerarra@tin.it >Subject: FreeBSD kernel buffer overflow >To: bugtraq@securityfocus.com >X-Virus-Scanned: by amavisd-new at avscan1b > >Topic: Buffer Overflow in FreeBSD >Versions: All the versions of FreeBSD are broken (4.x, 5.x, 6.0) >Arch: x86 >Date: 16/09/2004 > >All discussion refers to CURRENT-6.0, for other versions some things could >change (btw bugged). >Discussion involves a lot of arch x32 dependant mechanisms, so, in some >points, could sound a little bit dark. > > >A buffer overflow has been found in i386/i386/trap.c syscall() function >of FreeBSD official >source tree. >In order to rule syscalls mechanism, the 'particular' interrupt 128 (0x80) >is provided in the >IDT vector. To serve this interrupt, i386/i386/exception.s int0x80_syscall() >function is >done and, in the end, it calls syscall(). >syscall() is responsible for loading arguments from a syscall and copying >them in a kspace >pointer in order to accessing them. The code to do that is the following: > >void >syscall(frame) > struct trapframe frame; >{ > caddr_t params; > struct sysent *callp; > struct thread *td = curthread; > struct proc *p = td->td_proc; > register_t orig_tf_eflags; > u_int sticks; > int error; > int narg; > int args[8]; > u_int code; > > > ... > > > narg = callp->sy_narg & SYF_ARGMASK; (<- you can see it's the > only one >check) > > if (params != NULL && narg != 0) > error = copyin(params, (caddr_t)args, > (u_int)(narg * sizeof(int))); > else > error = 0; > > > ... > > >and: > > > grep SYF_ARGMASK /usr/src/sys/sys/sysent.h >#define SYF_ARGMASK 0x0000FFFF > >It's obvious that the amount of selectable memory is beyond the (8 * >sizeof(int)) >limit of >args array, so it would overwrite the saved eip by syscall() (it's invoked >through a call) or >making an interesting pointer corruption overwriting struct proc *p . > >It's exploitable, but the only one way I discovered is to link a new syscall >to the sysent >array and to do this you need to be root; I've no time to work on this >vulnerability, >but i think another way could be found. However it could give serious problems >(e.g. kernel >crashes). > >A good patch could be a dinamyc memory allocation for args, but it's not >a good solution >in order to mantain a well performanced system; another one could be a >strongest >check, but >it's not a good solution in order to set a good flexibility. > >You would get an attach containing proof of concept code (4.x, 5.x/6.0 >versions). > > >greetings > >rookie > > >P.S: in order to try the code, compile and link module to the kernel, later >do 'make test' and start ./poc -------------------------------------------------------------------- Mike Tancsa, tel +1 519 651 3400 Sentex Communications, mike@sentex.net Providing Internet since 1994 www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike