From owner-freebsd-hackers@FreeBSD.ORG Thu Sep 16 23:51:16 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 313F916A4CE for ; Thu, 16 Sep 2004 23:51:16 +0000 (GMT) Received: from mail.vicor-nb.com (bigwoop.vicor-nb.com [208.206.78.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id 1800143D31 for ; Thu, 16 Sep 2004 23:51:16 +0000 (GMT) (envelope-from julian@elischer.org) Received: from elischer.org (julian.vicor-nb.com [208.206.78.97]) by mail.vicor-nb.com (Postfix) with ESMTP id 9141C7A41E; Thu, 16 Sep 2004 16:51:15 -0700 (PDT) Message-ID: <414A26F3.8030201@elischer.org> Date: Thu, 16 Sep 2004 16:51:15 -0700 From: Julian Elischer User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3.1) Gecko/20030516 X-Accept-Language: en, hu MIME-Version: 1.0 To: gerarra@tin.it References: <4146316C000077FD@ims3a.cp.tin.it> In-Reply-To: <4146316C000077FD@ims3a.cp.tin.it> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit 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: Thu, 16 Sep 2004 23:51:16 -0000 This is standard proceedure. "there is no security problem." There is not even a practical problem.. No-one is going to be able to break into your machine because of this unless they have already broken into your machine by some other method. There is an implicit understanding in the kernel that it trusts itrself to be done right.. If you wan to check this I can show you many more things we trust ourselves on in the kernel for example do you check the function pointers in vfs method arrays before calling them? If we checked everything we would never get anything done.. In the end we draw the line at "we check values that come from userspace." We trust values that come from root indirectly e.g. when root mounts a filesystem or a kld module. As you have raise dth issue we might add a KASSERT checking that it is within bounds but the check would not be turned on for normal kernels just debug kernels. gerarra@tin.it wrote: >>As you point out, >> >> > >Seen i said alredy, why repeating? I was pointing out about the problem, >not security issue. >Like FreeBSD user I want the patch for this code and I think is useful reporting >bug. It's an important part of the kernel so I didn't prepared a patch alredy, >I would like to know how core team will move. > > > >>The number of arguments for a syscall is defined within the kernel and >> >> > > > >>is not >>supplied from an untrusted source. This means that this is not a >>security problem. >> >> > >Inside the kernel? i can define a syscall accepting 30 args and it could >send in panic freebsd kernel. I think it's a problem and a patch 'must' >occur. > > > >>to load a kernel module you must be root (and not in a jail) meaning >>that if you >>wanted to, the quicker and easier exploit would be >>/bin/sh >> >> >> >nice but it doesn't solve the problem. > > what problem would that be? If you are writing a kernel module then we assume yuo are truted otherwise whoever gave you root privs is in more trouble than a crashed system. > >cheers, >rookie > > >_______________________________________________ >freebsd-hackers@freebsd.org mailing list >http://lists.freebsd.org/mailman/listinfo/freebsd-hackers >To unsubscribe, send any mail to "freebsd-hackers-unsubscribe@freebsd.org" > >