From owner-freebsd-hackers Fri Feb 21 14:22:10 2003 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 350C937B406 for ; Fri, 21 Feb 2003 14:22:07 -0800 (PST) Received: from mail1.infospace.com (mail1.infospace.com [206.29.197.87]) by mx1.FreeBSD.org (Postfix) with SMTP id 4557143FDD for ; Fri, 21 Feb 2003 14:21:58 -0800 (PST) (envelope-from eugenea@infospace.com) Received: (qmail 4988 invoked from network); 21 Feb 2003 22:21:57 -0000 Received: from unknown (HELO ketel.inspinc.ad) (10.100.11.49) by jose.inspinc.ad with SMTP; 21 Feb 2003 22:21:56 -0000 Received: (qmail 1001 invoked from network); 21 Feb 2003 22:21:55 -0000 Received: from unknown (HELO infospace.com) ([10.100.29.130]) (envelope-sender ) by ketel.inspinc.ad (qmail-ldap-1.03) with SMTP for ; 21 Feb 2003 22:21:55 -0000 Message-ID: <3E56A683.5070504@infospace.com> Date: Fri, 21 Feb 2003 14:21:55 -0800 From: Yevgeniy Aleynikov User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20021226 Debian/1.2.1-9 X-Accept-Language: en, ru MIME-Version: 1.0 To: Kirk McKusick Cc: Matt Dillon , Ian Dowse , peter@FreeBSD.ORG, ache@FreeBSD.ORG, Ken Pizzini , hackers@FreeBSD.ORG, security-officer@FreeBSD.ORG, nectar@FreeBSD.ORG, jedgar@FreeBSD.ORG, rwatson@FreeBSD.ORG, imp@FreeBSD.ORG, security-team@FreeBSD.ORG, wes@FreeBSD.ORG, guido@FreeBSD.ORG Subject: Re: bleh. Re: ufs_rename panic References: <200302200101.h1K11ZFL056229@beastie.mckusick.com> In-Reply-To: <200302200101.h1K11ZFL056229@beastie.mckusick.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG As pointed by Ken - we do have alot of file renames (qmail). But 2-nd solution, directory-only rename serialization, probably won't affect performance as much. But i believe it's not only us who's gonna have problem when exploit code will be known by everybody sooner or later.... Thanks! Kirk McKusick wrote: > The potentially slow, but utterly effective way to fix this race > is to only allow one rename at a time per filesystem. It is > implemented by adding a flag in the mount structure and using > it to serialize calls to rename. When only one rename can happen > at a time, the race cannot occur. > > If this proves to be too much of a slow down, it would be possible > to only serialize directory renames. As these are (presumably) much > rarer the slow down would be less noticable. > > Kirk McKusick > > =-=-=-=-=-= > > Date: Wed, 19 Feb 2003 15:10:09 -0800 > From: Yevgeniy Aleynikov > To: Matt Dillon > CC: Kirk McKusick , Ian Dowse , > peter@FreeBSD.ORG, ache@FreeBSD.ORG, Ken Pizzini , > hackers@FreeBSD.ORG, security-officer@FreeBSD.ORG, nectar@FreeBSD.ORG, > jedgar@FreeBSD.ORG, rwatson@FreeBSD.ORG, imp@FreeBSD.ORG, > security-team@FreeBSD.ORG, wes@FreeBSD.ORG, guido@FreeBSD.ORG > Subject: Re: bleh. Re: ufs_rename panic > X-ASK-Info: Confirmed by User > > Just reminder that this problem is local kernel panic DoS (which can do > filesystem corruption) with very simple trigger code and it still exists. > > And it's been almost 2 years since i wrote about it. > > > Workaround (commenting out panic call) doesnt fix the problem. > Server still crashes (not so often though) from virtual memory failures > like this: > > panic: vm_fault: fault on nofault entry, addr: d0912000 > mp_lock = 01000002; cpuid = 1; lapic.id = 00000000 > boot() called on cpu#1 > > > (kgdb) bt > #0 0xc0175662 in dumpsys () > #1 0xc017542c in boot () > #2 0xc0175894 in poweroff_wait () > #3 0xc01e7c18 in vm_fault () > #4 0xc0219d32 in trap_pfault () > #5 0xc021990b in trap () > #6 0xc01e008a in ufs_dirrewrite () > #7 0xc01e31a4 in ufs_rename () > #8 0xc01e4645 in ufs_vnoperate () > #9 0xc01a9121 in rename () > #10 0xc021a44d in syscall2 () > #11 0xc02077cb in Xint0x80_syscall () > > > How can i help to resolve this problem ASAP? > > Thanks! > > Matt Dillon wrote: > >> Well, I've gone through hell trying to fix the rename()/rmdir()/remove() >> races and failed utterly. There are far more race conditions then even >> my last posting indicated, and there are *severe* problems fixing NFS >> to deal with even Ian's suggestion... it turns out that NFS's nfs_namei() >> permanently adjusts the mbuf while processing the path name, making >> restarts impossible. >> >> The only solution is to implement namei cache path locking and formalize >> the 'nameidata' structure, which means ripping up a lot of code because >> nearly the entire code base currently plays with the contents of >> 'nameidata' willy-nilly. Nothing else will work. It's not something >> that I can consider doing now. >> >> In the mean time I am going to remove the panic()'s in question. This >> means that in ufs_rename() the machine will silently ignore the race >> (not do the rename) instead of panic. It's all that can be done for >> the moment. It solve the security/attack issue. We'll have to attack >> the races as a separate issue. The patch to remove the panics is utterly >> trivial and I will commit it after I test it. >> >> -Matt >> >> >> > > -- Yevgeniy Aleynikov | Sr. Systems Engineer - USE InfoSpace INC 601 108th Ave NE | Suite 1200 | Bellevue, WA 98004 Tel 425.709.8214 | Fax 425.201.6160 | Mobile 425.418.8924 eugene.aleynikov@infospace.com | http://www.infospaceinc.com Discover what you can do.TM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message