From owner-freebsd-hackers@FreeBSD.ORG Sat Sep 18 19:18:27 2004 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9DCF316A4CE for ; Sat, 18 Sep 2004 19:18:27 +0000 (GMT) Received: from mail.freebsd.org.cn (dns3.freebsd.org.cn [61.129.66.75]) by mx1.FreeBSD.org (Postfix) with SMTP id CD52E43D31 for ; Sat, 18 Sep 2004 19:18:23 +0000 (GMT) (envelope-from delphij@frontfree.net) Received: (qmail 17443 invoked by uid 0); 18 Sep 2004 19:14:36 -0000 Received: from unknown (HELO beastie.frontfree.net) (219.239.98.7) by mail.freebsd.org.cn with SMTP; 18 Sep 2004 19:14:36 -0000 Received: from localhost (localhost.frontfree.net [127.0.0.1]) by beastie.frontfree.net (Postfix) with ESMTP id AD8A01322A6; Sun, 19 Sep 2004 03:18:20 +0800 (CST) Received: from beastie.frontfree.net ([127.0.0.1]) by localhost (beastie.frontfree.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 02213-03; Sun, 19 Sep 2004 03:18:15 +0800 (CST) Received: by beastie.frontfree.net (Postfix, from userid 1001) id B8EFF130E15; Sun, 19 Sep 2004 03:18:14 +0800 (CST) Date: Sun, 19 Sep 2004 03:18:14 +0800 From: Xin LI To: gerarra@tin.it Message-ID: <20040918191814.GA3716@frontfree.net> References: <006201c49d42$0c751aa0$1200a8c0@gsicomp.on.ca> <4146316C0000A1A7@ims3a.cp.tin.it> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="qMm9M+Fa2AknHoGS" Content-Disposition: inline In-Reply-To: <4146316C0000A1A7@ims3a.cp.tin.it> User-Agent: Mutt/1.4.2.1i X-GPG-key-ID/Fingerprint: 0xCAEEB8C0 / 43B8 B703 B8DD 0231 B333 DC28 39FB 93A0 CAEE B8C0 X-GPG-Public-Key: http://www.delphij.net/delphij.asc X-Operating-System: FreeBSD beastie.frontfree.net 5.3-delphij FreeBSD 5.3-delphij #4: Mon Sep 13 12:44:05 CST 2004 delphij@beastie.frontfree.net:/usr/obj/usr/src/sys/BEASTIE i386 X-URL: http://www.delphij.net X-By: delphij@beastie.frontfree.net X-Location: Beijing, China X-Virus-Scanned: by amavisd-new at frontfree.net cc: freebsd-hackers@freebsd.org Subject: Re: FreeBSD Kernel buffer overflow X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Sep 2004 19:18:27 -0000 --qMm9M+Fa2AknHoGS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Sep 18, 2004 at 12:10:14PM +0200, gerarra@tin.it wrote: >=20 > In my post I told that this is *NOT* exploitable but if somebody finds a > method? what you can say? In underground comunities it's not so rare, pat= ching > is better than having a new exploits for freebsd. I was very deluded by > this approach to potential security problem... > (I repeat: *POTENTIAL*). You have some different idea from ours. However, I think it might be useful to clarify our idea. 1. A kernel must trust itself in order for it to be efficient. It is not bad to have sanity checks, but checking it repeatly will pose a performance pain. With this in mind, the correct approach might be to have sanity check in the entry point, rather than having it everywhere. This is say, a input procedure must have everything in a sanity state in its early stage and, in addition, same check should not be done in elsewhere because it just repeatly check what is guaranteed to be true, in a production kernel this is not quite useful and even in a debug kernel it is not perferred approach because we don't have to explicitly have if(1=3D=3D1) or something like this. 2. As many people in this discussion has pointed out, it is necessary to have root access in order to alter a system call. That is say, that in order to successfully exploit this "vulnerablity" you have to be root first, and we have infinite "exploits" in this situation, because the attacker already got the ultimate power. We don't need to fear someone who already killed us, right? 3. Security is determined by the weakest tach. With this in concern, let's think about the following scenario: Every system calls have correct sanity check in their entry point while foo() have not. Someone has injected foo() with another way to have some code in kernel. The kernel code exploited the issue you mentioned. But is it actually wrong with the issue? Isn't it the weakest tach within the foo() system call? Shouldn't it be fixed? Hope this is helpful for the debate, and hope I have expressed my idea correctly. With these consideration, I think it is not very necessary to have the sanity check of parameter numbers for a system call entry because it need root access already and if the gain of root is considered harmful, then it's not the sanity of parameter numbers check but the actual problem should be fixed.=20 Cheers, --=20 Xin LI http://www.delphij.net/ See complete headers for GPG key and other information. --qMm9M+Fa2AknHoGS Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (FreeBSD) iD8DBQFBTIn2/cVsHxFZiIoRAo5OAJ9B/m04M0U0yNniCySmfFX623HpygCdE0Gl z4l9EdaFv56bvGSN3mGIoHo= =fP2n -----END PGP SIGNATURE----- --qMm9M+Fa2AknHoGS--