From owner-freebsd-security Sun Nov 9 15:35:53 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id PAA14545 for security-outgoing; Sun, 9 Nov 1997 15:35:53 -0800 (PST) (envelope-from owner-freebsd-security) Received: from cwsys.cwsent.com (66@cschuber.net.gov.bc.ca [142.31.240.113]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id PAA14537; Sun, 9 Nov 1997 15:35:36 -0800 (PST) (envelope-from cy@cwsys.cwsent.com) Received: (from uucp@localhost) by cwsys.cwsent.com (8.8.8/8.6.10) id PAA18013; Sun, 9 Nov 1997 15:35:28 -0800 (PST) Message-Id: <199711092335.PAA18013@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpd018003; Sun Nov 9 23:34:28 1997 X-Mailer: exmh version 2.0gamma 1/27/96 Reply-to: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: cy To: freebsd-security@freebsd.org cc: security-officer@freebsd.org Subject: [linux-security] Perl script to locate F0 0F C7 C8 bombs Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 09 Nov 1997 15:34:27 -0800 Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Here's a little Perl script that may make postmortums a little easier. There's one error in it. The line containing if($data =~ /\xf0\x0f\xc7\xc8/) { should be replaced with if($data =~ /\xf0\x0f\xc7[\xc8\xc9\xca\xcb\xcc\xcd\xce\xcf]/) { as any LOCK CMPXCHG8B opcode with a direct register reference (invalid as cou cannot compare and swap a 64 bit value with a 32 bit value) will cause the P5 chip hangs, e.g. LOCK CMPXCHG8B %EAX or LOCK CMPXCHG8B %EDX. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca Cy.Schubert@gems8.gov.bc.ca "Quit spooling around, JES do it." ------- Forwarded Message Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.8/8.6.10) id OAA22578 for ; Sun, 9 Nov 1997 14:59:21 -0800 (PST) X-UIDL: 879117126.003 Resent-Message-Id: <199711092259.OAA22578@passer.osg.gov.bc.ca> Received: from localhost(127.0.0.1), claiming to be "passer.osg.gov.bc.ca" via SMTP by localhost, id smtpdaawBqa; Sun Nov 9 14:59:11 1997 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.8/8.6.10) id OAA23054 for ; Sun, 9 Nov 1997 14:58:51 -0800 (PST) Received: from orca.gov.bc.ca(142.32.102.25) via SMTP by passer.osg.gov.bc.ca, id smtpdaawBga; Sun Nov 9 14:58:32 1997 Received: from mail2.redhat.com by orca.gov.bc.ca (5.4R3.10/200.1.1.4) id AA16352; Sun, 9 Nov 1997 14:58:31 -0800 Received: (qmail 10538 invoked by uid 501); 9 Nov 1997 22:58:29 -0000 Prev-Resent-Date: 9 Nov 1997 22:58:29 -0000 Prev-Resent-Cc: recipient.list.not.shown.;@uumail.gov.bc.ca Mbox-Line: From linux-security-request@redhat.com Sun Nov 9 17:58:28 1997 X-Pop3-Rcpt: t757607@helium Date: Fri, 7 Nov 1997 13:03:23 -0800 (PST) From: Sam Trenholme To: linux-security@redhat.com Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Prev-Resent-Message-Id: <"uM3Km3.0.Ka2.K0aPq"@mail2.redhat.com> Prev-Resent-From: linux-security@redhat.com Reply-To: linux-security@redhat.com X-Mailing-List: archive/latest/341 X-Loop: linux-security@redhat.com Precedence: list Prev-Resent-Sender: linux-security-request@redhat.com Subject: [linux-security] Perl script to locate F0 0F C7 C8 bombs Resent-To: cy@passer.osg.gov.bc.ca Resent-Date: Sun, 09 Nov 1997 14:59:10 -0800 Resent-From: Cy Schubert - ITSD Open Systems Group There is no known fix to the F0 0F C7 C8 bug at this time. What can be done, however, is run a program, such as the script after my signature, to locate any and all such programs. This script can be used in single user mode after a mysterious lockup on a multiuser Pentium system. I hope it is possible to come up with a software fix for this problem. - - Sam "You can...turn sadness into laughter" -- Sunscreem, _Love_U_More_ #!/usr/bin/perl # There is no known software fix to the F0 0F C7 C8 bug at this time # usage: finddeath dir # where dir is the directory you recursively look at all programs in # for instances of the F0 0F C7 C8 sequence # This script will search for programs with this sequence, which will # help sysadmins take appropriate action against those running such # programs # This script is written (but has not been tested) in Perl4, to # insure maximum compatibility sub findit { local($dir,$file,@files,$data) = @_; undef $/; if(!opendir(DIR,$dir)) { print STDERR "Can not open $dir: $!\n"; return 0; } @files=readdir(DIR); foreach $file (@files) { if($file ne '.' && $file ne '..') { if( -f "$dir/$file" && open(FILE,"< $dir/$file")) { $data=; if($data =~ /\xf0\x0f\xc7\xc8/) { print "$dir/$file contains F0 0F C7 C8\n"; } } elsif( -d "$dir/$file") { &findit("$dir/$file"); } } } } $dir = shift || '/home'; &findit($dir); - -- - ---------------------------------------------------------------------- Please refere to the information about this list as well as general information about Linux security at http://www.aoy.com/Linux/Security. - ---------------------------------------------------------------------- To unsubscribe: mail -s unsubscribe test-list-request@redhat.com < /dev/null ------- End of Forwarded Message From owner-freebsd-security Sun Nov 9 23:34:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id XAA10297 for security-outgoing; Sun, 9 Nov 1997 23:34:21 -0800 (PST) (envelope-from owner-freebsd-security) Received: from kemicol.rezidew.net (qmailr@kemicol.rezidew.net [208.216.242.241]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id XAA10279 for ; Sun, 9 Nov 1997 23:34:14 -0800 (PST) (envelope-from rezidew@rezidew.net) Received: (qmail 3223 invoked from network); 10 Nov 1997 08:29:25 -0000 Received: from soap.rezidew.net (rezidew@208.216.242.243) by kemicol.rezidew.net with SMTP; 10 Nov 1997 08:29:25 -0000 Message-ID: X-Mailer: XFMail 1.1 [p0] on Linux Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 Resent-Date: Sat, 8 Nov 1997 19:28:28 +0100 (MET) Resent-Message-Id: Resent-From: (Jacob Navia) Resent-To: linux-security@redhat.com Date: Mon, 10 Nov 1997 02:10:09 -0600 (CST) From: Graphic Rezidew To: roger@nwu.edu, freebsd-security@freebsd.org, Kadokev@ripco.com Subject: FW: [linux-security] pentium bug makes security under linux impo Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk note: I have tested this for myself with netbsd (???) freebsd (2.2.2) BSDi (BSD/OS 3.0) dos (6.22) linux (as if a version means anything here) solaris x86 (2.6 and 2.5.1) (with gcc not /usr/ucb/bin/cc) The results are the same. (SEEE!!!!!!! linux *IS* good for SOMETHING.) -----FW: ----- Date: Sat, 8 Nov 1997 19:28:28 +0100 (MET) From: (Jacob Navia) To: linux-security@redhat.com Subject: [linux-security] pentium bug makes security under linux impossible This morning I received this message from the list gnu-win32@cygnus.com: The sender was anonymous > > There is a SERIOUS bug in all pentium CPUs. The following > code will crash any machine running on a pentium CPU, MMX or no > MMX, any speed, regardless of OS (crash as in instant seize, hard > reboot the only cure): > > char x [5] = { 0xf0, 0x0f, 0xc7, 0xc8 }; > > main () > { > void (*f)() = x; > f(); > } > > This require no special permissions to run, it works fine with > average-joe-userspace permissions. I have verified this, it works. > Demand a new CPU from Intel. > Curious, I compiled that under Linux OS. Linux freezed. Dead. Without *any* warning. My machine is a Genuine Intel 166 MHZ Pentium MMX. Then I rebooted Windows NT. Compiled it with my compiler system (lcc-win32). Windows NT freezed. DEAD. Without *any* warning. Then, I ported the code to my old faithful 486-DX33 with linux. Compiled it. When it run it traps with 'illegal instruction' This means that anybody can crash anytime any OS that runs under a Pentium CPU. As the poster said, no special permissions are needed, the pentium runs under ring 3 permissions!!!! This means that no secure system can ever be built that uses the pentium CPU. No protected system. The OS receives NO TRAP!!! This is absolutely incredible. Bugs are impossible to avoid. Not even with huge corporations like Intel. I will *not* start screaming at Intel now. Myself, I have done more bugs than Intel ever will. As somene said before: Those that are free of sin, throw the first stone... For any user of pentium cpus in a multiuser system this means that anybody that can execute a program can freeze the system dead. I repeat: NO ROOT PERMISSIONS ARE NEEDED. -- Jacob Navia Logiciels/Informatique 41 rue Maurice Ravel Tel (1) 48.23.51.44 93430 Villetaneuse Fax (1) 48.23.95.39 France -- ---------------------------------------------------------------------- Please refere to the information about this list as well as general information about Linux security at http://www.aoy.com/Linux/Security. ---------------------------------------------------------------------- To unsubscribe: mail -s unsubscribe test-list-request@redhat.com < /dev/null --------------End of forwarded message------------------------- ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ The word "spine" is, of course, an anagram of "penis". This is true in almost fifty percent of the languages of the Galaxy, and many people have attempted to explain why. Usually these explanations get bogged down in silly puns about "standing erect" -- Douglas Adams, "The Hitchhiker's Guide to the Galaxy" ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Graphic Rezidew rezidew@rezidew.net http://Graphic.Rezidew.net From owner-freebsd-security Mon Nov 10 05:39:57 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id FAA01148 for security-outgoing; Mon, 10 Nov 1997 05:39:57 -0800 (PST) (envelope-from owner-freebsd-security) Received: from mail.virginia.edu (mail.Virginia.EDU [128.143.2.9]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id FAA01140 for ; Mon, 10 Nov 1997 05:39:49 -0800 (PST) (envelope-from atf3r@cs.virginia.edu) Received: from mail.cs.virginia.edu by mail.virginia.edu id aa06422; 10 Nov 97 8:39 EST Received: from stretch.cs.virginia.edu (atf3r@stretch-fo.cs.Virginia.EDU [128.143.136.14]) by ares.cs.Virginia.EDU (8.8.5/8.8.5) with ESMTP id IAA02280; Mon, 10 Nov 1997 08:39:30 -0500 (EST) Received: (from atf3r@localhost) by stretch.cs.virginia.edu (8.8.5/8.8.5) id IAA08403; Mon, 10 Nov 1997 08:39:29 -0500 (EST) Date: Mon, 10 Nov 1997 08:39:28 -0500 (EST) From: "Adrian T. Filipi-Martin" Reply-To: adrian@virginia.edu To: Graphic Rezidew cc: roger@nwu.edu, freebsd-security@freebsd.org, Kadokev@ripco.com Subject: Re: FW: [linux-security] pentium bug makes security under linux impo In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Mon, 10 Nov 1997, Graphic Rezidew wrote: > note: I have tested this for myself with > netbsd (???) > freebsd (2.2.2) > BSDi (BSD/OS 3.0) > dos (6.22) > linux (as if a version means anything here) > solaris x86 (2.6 and 2.5.1) (with gcc not /usr/ucb/bin/cc) Argh! I built the test program on a 486/66 running 2.2.2-STABLE which correctly trapped the illegal instruction. The same binary does indeed kill a P120 running 2.2.1 cold. Does anyone know of other illegal instruction patterns that can cause this? Is this a unique one that a compiler could be patched to avoid? I know it would not prevent the deliberate creation of such binaries, but it would slow down the novice-crackers who want to play with it. Adrian -- adrian@virginia.edu ---->>>>| If I were stranded on a desert island, and System Administrator --->>>| I could only have one OS for my computer, Neurosurgical Visualzation Lab -->>| it would be FreeBSD. Think about it..... http://www.nvl.virginia.edu/ ->| http://www.freebsd.org/ From owner-freebsd-security Mon Nov 10 11:11:54 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id LAA21219 for security-outgoing; Mon, 10 Nov 1997 11:11:54 -0800 (PST) (envelope-from owner-freebsd-security) Received: from sui.gda.itesm.mx (sui.gda.itesm.mx [132.254.53.124]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id LAA21212 for ; Mon, 10 Nov 1997 11:11:44 -0800 (PST) (envelope-from alexv@sui.gda.itesm.mx) Received: from sui.gda.itesm.mx ([132.254.148.4]) by sui.gda.itesm.mx (8.8.5/8.8.5) with ESMTP id NAA00832; Mon, 10 Nov 1997 13:14:33 -0600 (CST) Message-ID: <34675C10.B7CFA5F2@sui.gda.itesm.mx> Date: Mon, 10 Nov 1997 13:10:08 -0600 From: "Alejandro Vázquez C." Organization: SUI - ITESM Campus Guadalajara X-Mailer: Mozilla 4.03 [en] (Win95; I) MIME-Version: 1.0 To: Graphic Rezidew CC: roger@nwu.edu, freebsd-security@FreeBSD.ORG, Kadokev@ripco.com Subject: Re: FW: [linux-security] pentium bug makes security under linux impo References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Graphic Rezidew wrote: > > There is a SERIOUS bug in all pentium CPUs. The following > > code will crash any machine running on a pentium CPU, MMX or no > > MMX, any speed, regardless of OS (crash as in instant seize, hard > > reboot the only cure): > > > > char x [5] = { 0xf0, 0x0f, 0xc7, 0xc8 }; > > > > main () > > { > > void (*f)() = x; > > f(); > > } > > > > This require no special permissions to run, it works fine with > > average-joe-userspace permissions. I have verified this, it works. > > Demand a new CPU from Intel. If I had someone, I would. But I have an AMD K5 and detects perfectly the illegal instruction. It seems that it only happens with Intel's Pentium (I have NOT tested with AMD K6, neigther Cyrix's Pentium class CPUs). From owner-freebsd-security Mon Nov 10 12:37:56 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA26608 for security-outgoing; Mon, 10 Nov 1997 12:37:56 -0800 (PST) (envelope-from owner-freebsd-security) Received: from Rigel.orionsys.com (root@rigel.orionsys.com [205.148.224.9]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA26599 for ; Mon, 10 Nov 1997 12:37:51 -0800 (PST) (envelope-from root@Rigel.orionsys.com) Received: from localhost (root@localhost) by Rigel.orionsys.com (8.8.7/8.8.7) with ESMTP id MAA12245; Mon, 10 Nov 1997 12:37:02 -0800 (PST) Date: Mon, 10 Nov 1997 12:37:01 -0800 (PST) From: Dave Babler To: "Alejandro Vázquez C." cc: freebsd-security@FreeBSD.ORG Subject: Re: FW: [linux-security] pentium bug makes security under linux impo In-Reply-To: <34675C10.B7CFA5F2@sui.gda.itesm.mx> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8BIT Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Mon, 10 Nov 1997, Alejandro Vázquez C. wrote: > > > Graphic Rezidew wrote: > > > > There is a SERIOUS bug in all pentium CPUs. The following > > > code will crash any machine running on a pentium CPU, MMX or no > > > MMX, any speed, regardless of OS (crash as in instant seize, hard > > > reboot the only cure): > > > > > > char x [5] = { 0xf0, 0x0f, 0xc7, 0xc8 }; > > > > > > main () > > > { > > > void (*f)() = x; > > > f(); > > > } > > > > > > This require no special permissions to run, it works fine with > > > average-joe-userspace permissions. I have verified this, it works. > > > Demand a new CPU from Intel. > > If I had someone, I would. But I have an AMD K5 and detects perfectly the illegal > instruction. It seems that it only happens with Intel's Pentium (I have NOT tested > with AMD K6, neigther Cyrix's Pentium class CPUs). > If it *did* crash non-Intel parts, Intel would probably have cause to sue since it is a mask error, apparently. Take a peek at http://www.x86.org for more on the "F00F bug". From owner-freebsd-security Tue Nov 11 21:58:28 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA12413 for security-outgoing; Tue, 11 Nov 1997 21:58:28 -0800 (PST) (envelope-from owner-freebsd-security) Received: from room101.sysc.com (qmailr@richmojm2.student.rose-hulman.edu [137.112.206.126]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id VAA12402 for ; Tue, 11 Nov 1997 21:58:23 -0800 (PST) (envelope-from jayrich@room101.sysc.com) Received: (qmail 865 invoked by uid 1000); 12 Nov 1997 05:58:00 -0000 Date: Wed, 12 Nov 1997 00:58:00 -0500 (EST) From: "Jay M. Richmond" To: freebsd-security@freebsd.org Subject: Intel Pentium Bug: BSDI Releases a patch (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk What are the freebsd team's thought on this? --jay -- As many of you probably know, a bug was recently discovered in the Pentium CPU that causes the CPU to hang when a certain instruction is executed. This bug has been widely reported in mailing lists and news groups. The bug enables an unprivileged user to hang the system, requiring the system to be reset or power-cycled. With information provided by Intel, BSDI has developed a workaround for this problem. A beta version of the mod for BSD/OS version 3.1 is now available for testing from ftp://ftp.bsdi.com/bsdi/patches/patches-3.1/M310-hangfix This mod may also be applied to 3.0 based systems. The workaround is enabled only on P5 processors, and should not be necessary on Pentium Pro, Pentium II or non-Intel CPUs. The mod is currently available only in binary form. We anticipate general release of the mod within a day or so. We are interested in hearing of any problems experienced with this change. We are also interested in hearing about testing on any non-Intel Pentium-compatible systems. Please send any reports to bsdi-hang-beta@BSDI.COM We are not at liberty to discuss the mechanism of the workaround at this time. If you are installing the mod in a source kernel tree, you will need to copy the files sys/i386/OBJ/{machdep.o,locore.o} to your kernel compile directory before rebuilding your kernel. Jeff - -- /\ Jeff Polk Berkeley Software Design, Inc. (BSDI) /\/ \ polk@BSDI.COM 5575 Tech Center Dr. #110, Colo Spgs, CO 80919 - -- To unsubscribe from this list, send 'unsubscribe' in the body of an e-mail message to 'bsdi-users-request@mailinglists.org' ------- End of Forwarded Message From owner-freebsd-security Wed Nov 12 07:52:21 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id HAA12612 for security-outgoing; Wed, 12 Nov 1997 07:52:21 -0800 (PST) (envelope-from owner-freebsd-security) Received: from cwsys.cwsent.com (66@cschuber.net.gov.bc.ca [142.31.240.113]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id HAA12479; Wed, 12 Nov 1997 07:51:17 -0800 (PST) (envelope-from cy@cwsys.cwsent.com) Received: (from uucp@localhost) by cwsys.cwsent.com (8.8.8/8.6.10) id HAA06579; Wed, 12 Nov 1997 07:50:00 -0800 (PST) Message-Id: <199711121550.HAA06579@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpd006574; Wed Nov 12 15:49:52 1997 X-Mailer: exmh version 2.0gamma 1/27/96 Reply-to: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-Sender: cy To: security-officer@freebsd.org cc: freebsd-security@freebsd.org Subject: Updating microcode on the fly Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Nov 1997 07:49:50 -0800 Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk It appears from a couple of postings on BUGTRAQ, this being the second one, and a BSDI fix being the first, that Intel has released a workaround or possibly even a microcode patch. What are the chances of the FreeBSD Core Team getting their hands on this patch from Intel? Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca Cy.Schubert@gems8.gov.bc.ca "Quit spooling around, JES do it." ------- Forwarded Message Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.8/8.6.10) id HAA01211 for ; Wed, 12 Nov 1997 07:16:06 -0800 (PST) X-UIDL: 879348978.008 Resent-Message-Id: <199711121516.HAA01211@passer.osg.gov.bc.ca> Received: from localhost(127.0.0.1), claiming to be "passer.osg.gov.bc.ca" via SMTP by localhost, id smtpdaabdca; Wed Nov 12 07:15:59 1997 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.8/8.6.10) id HAA27214 for ; Wed, 12 Nov 1997 07:15:56 -0800 (PST) Received: from orca.gov.bc.ca(142.32.102.25) via SMTP by passer.osg.gov.bc.ca, id smtpdaabdva; Wed Nov 12 07:15:44 1997 Received: from brimstone.netspace.org by orca.gov.bc.ca (5.4R3.10/200.1.1.4) id AA20483; Wed, 12 Nov 1997 07:15:43 -0800 Received: from unknown@netspace.org (port 58972 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <96982-12505>; Wed, 12 Nov 1997 09:50:03 -0500 Received: from NETSPACE.ORG by NETSPACE.ORG (LISTSERV-TCP/IP release 1.8c) with spool id 5580459 for BUGTRAQ@NETSPACE.ORG; Wed, 12 Nov 1997 09:47:17 -0500 Received: from brimstone.netspace.org (brimstone.netspace.org [128.148.157.143]) by netspace.org (8.8.7/8.8.2) with ESMTP id JAA22118 for ; Wed, 12 Nov 1997 09:36:53 -0500 Received: from unknown@netspace.org (port 58972 [128.148.157.6]) by brimstone.netspace.org with ESMTP id <96517-12502>; Wed, 12 Nov 1997 09:36:45 -0500 Approved-By: aleph1@UNDERGROUND.ORG Received: from wildcat.tomcat.ru (wildcat.tomcat.ru [194.58.216.216]) by netspace.org (8.8.7/8.8.2) with ESMTP id JAA19197 for ; Wed, 12 Nov 1997 09:03:36 -0500 Received: (root@localhost) by wildcat.tomcat.ru (8.7.6/SCA-6.6) id OAA00745 for BUGTRAQ@NETSPACE.ORG; Wed, 12 Nov 1997 14:02:46 GMT X-Mailer: SCO OpenServer Mail Release 5.0 Message-Id: <199711121402.OAA00745@wildcat.tomcat.ru> Date: Wed, 12 Nov 1997 17:02:46 MSK Reply-To: Superuser Sender: Bugtraq List From: Superuser Subject: Updating microcode on the fly To: BUGTRAQ@netspace.org Resent-To: cy@passer.osg.gov.bc.ca Resent-Date: Wed, 12 Nov 1997 07:15:58 -0800 Resent-From: Cy Schubert - ITSD Open Systems Group Hi ! See the following letter for info about updating microcode for Pentium. If SCO does that during booting UnixWare then it is possible for any programs to do the update. Pavel Yakovlev. ========== ftp://ftp.sco.com/SLS/ptf3343.ltr ================= Dear SCO Customer, The enclosed Support Level Supplement (SLS) PTF3343, the Intel Pentium Pro and Pentium II Microcode Driver, provides Intel P6 microcode fixes. Some models and steppings of the Intel Pentium Pro processor and the Intel Pentium II processor may, in some circumstances, depart from their specifications. Some of these issues can be resolved by updating the microcode of the processor at system startup. SLS PTF3343 installs updates from the Intel Corporation to do that. Contents - -------- /etc/conf/bin/idtune /etc/conf/pack.d/pstart/Driver_atup.o /etc/conf/pack.d/pstart/Driver_mp.o /etc/conf/pack.d/pstart/space.c /usr/sbin/pat Software Notes and Recommendations - ---------------------------------- PTF3343 may be installed on any of these releases: SCO UnixWare Application Server Release 2.01 or 2.02 or 2.03 SCO UnixWare Personal Edition Release 2.01 or 2.02 or 2.03 SCO UnixWare Application Server Release 2.1 or 2.1.1 or 2.1.2 SCO UnixWare Personal Edition Release 2.1 or 2.1.1 or 2.1.2 PTF3028B, the Virtual Memory Subsystem Improvements and Intel Processor SLS, (on UnixWare Release 2.1.x) and PTF3131B, the Intel Processor Supplement, (on Release 2.1.1 or 2.1.2) work around some other Intel P6 issues. You may wish to install one of those additionally. If PTF3028B is installed after PTF3343, then PTF3343 should be installed again after that. PTF3131B and PTF3343 may be installed in either order. If osmp is installed after PTF3343, then PTF3343 should be installed again after that. PTF3343 is incompatible with PTF3191, the 4GB User Space Supplement. New tunable INTEL_CPUREV is autotuned by idtune when the kernel is rebuilt to minimize the size of the Pentium Pro & Pentium II microcode updates table in pstart/space.c. Until the new driver is running, the full information to minimize it is not available, so the table may be reduced when the kernel is next rebuilt. If a different P6 processor is brought online in the future, then it may be omitted from the updates table until the kernel is next rebuilt. To avoid that possibility, manually tune INTEL_CPUREV to 0x6000000 for the whole 12k table always to be built. Conversely, tune INTEL_CPUREV to 0 to suppress all microcode updates. /usr/sbin/pat is a patching utility taken from future releases of UnixWare. Here it is used by /etc/conf/bin/idtune to extract the appropriate value for INTEL_CPUREV from the running kernel. Hardware Notes and Recommendations - ---------------------------------- PTF3343 is designed for genuine Intel Pentium Pro processors or genuine Intel Pentium II processors only. Installation Instructions - ------------------------- 1. Download the ptf3343.Z file to the /tmp directory on your machine. 2. As root, uncompress the file and add the package to your system using these commands: $ su Password: # uncompress /tmp/ptf3343.Z # pkgadd -d /tmp/ptf3343 # rm /tmp/ptf3343 3. Reboot the system after installing this package. Release notes can be found in: /var/sadm/pkg/ptf3343/install/ptf3343.txt Removal Instructions - -------------------- 1. As root, remove the package using these commands: $ su Password: # pkgrm ptf3343 2. Reboot the system after removing this package. If you have questions regarding this SLS, or the product on which it is installed, please contact your software supplier. We appreciate your business. SCO Support Services ------- End of Forwarded Message From owner-freebsd-security Wed Nov 12 09:40:09 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA20708 for security-outgoing; Wed, 12 Nov 1997 09:40:09 -0800 (PST) (envelope-from owner-freebsd-security) Received: from time.cdrom.com (root@time.cdrom.com [204.216.27.226]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA20641; Wed, 12 Nov 1997 09:39:45 -0800 (PST) (envelope-from jkh@time.cdrom.com) Received: from time.cdrom.com (jkh@localhost.cdrom.com [127.0.0.1]) by time.cdrom.com (8.8.7/8.6.9) with ESMTP id JAA03813; Wed, 12 Nov 1997 09:39:31 -0800 (PST) To: Cy Schubert - ITSD Open Systems Group cc: security-officer@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Updating microcode on the fly In-reply-to: Your message of "Wed, 12 Nov 1997 07:49:50 PST." <199711121550.HAA06579@cwsys.cwsent.com> Date: Wed, 12 Nov 1997 09:39:31 -0800 Message-ID: <3809.879356371@time.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > possibly even a microcode patch. What are the chances of the FreeBSD Core > Team getting their hands on this patch from Intel? No idea, you tell us. ;-) Jordan From owner-freebsd-security Wed Nov 12 09:58:24 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id JAA22020 for security-outgoing; Wed, 12 Nov 1997 09:58:24 -0800 (PST) (envelope-from owner-freebsd-security) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id JAA21998; Wed, 12 Nov 1997 09:58:12 -0800 (PST) (envelope-from cschuber@passer.osg.gov.bc.ca) Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.8.8/8.6.10) id JAA00890; Wed, 12 Nov 1997 09:58:06 -0800 (PST) Message-Id: <199711121758.JAA00890@passer.osg.gov.bc.ca> Received: from localhost(127.0.0.1), claiming to be "passer.osg.gov.bc.ca" via SMTP by localhost, id smtpdaabDva; Wed Nov 12 09:58:04 1997 X-Mailer: exmh version 2.0gamma 1/27/96 Reply-to: Cy Schubert - ITSD Open Systems Group X-Sender: cschuber To: "Jordan K. Hubbard" cc: Cy Schubert - ITSD Open Systems Group , security-officer@freebsd.org, freebsd-security@freebsd.org Subject: Re: Updating microcode on the fly In-reply-to: Your message of "Wed, 12 Nov 1997 09:39:31 PST." <3809.879356371@time.cdrom.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 12 Nov 1997 09:58:04 -0800 From: Cy Schubert - ITSD Open Systems Group Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk > > possibly even a microcode patch. What are the chances of the FreeBSD Core > > Team getting their hands on this patch from Intel? > > No idea, you tell us. ;-) > > Jordan I just spoke to a fellow at Intel. He told me that they are testing the solution and that something should be available in the next few days. They will be releasing the information to all vendors including the free O/S maintainers. He didn't know whether it would be a workaround or a microcode patch that could be loaded at O/S boot. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca Cy.Schubert@gems8.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Wed Nov 12 10:06:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id KAA22955 for security-outgoing; Wed, 12 Nov 1997 10:06:31 -0800 (PST) (envelope-from owner-freebsd-security) Received: from sokol.npi.msu.su (sokol.npi.msu.su [158.250.9.3]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id KAA22926 for ; Wed, 12 Nov 1997 10:06:17 -0800 (PST) (envelope-from denis@satty.npi.msu.su) Received: from localhost (localhost [127.0.0.1]) by sokol.npi.msu.su (8.8.8/8.8.6) with SMTP id VAA02941 for ; Wed, 12 Nov 1997 21:07:23 +0300 (MSK) Date: Wed, 12 Nov 1997 21:07:23 +0300 (MSK) From: DENIS Kalinin X-Sender: denis@sokol.npi.msu.su To: security@freebsd.org Subject: Intel Pentium Bug: BSDI Releases a patch (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Is there any way to reverse engineer it and use for FreeBSD? Denis Kalinin. ------- Forwarded Message To: bsdi-users@bsdi.com Subject: Beta test of Pentium hang work-around for BSD/OS 3.1 (and 3.0) Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 11 Nov 1997 16:38:48 -0700 From: Jeff Polk Sender: owner-bsdi-users@mailinglists.org Precedence: bulk X-Sender: Jeff Polk X-UIDL: fb8659ed152bd2ba9912c603b6a1b837 As many of you probably know, a bug was recently discovered in the Pentium CPU that causes the CPU to hang when a certain instruction is executed. This bug has been widely reported in mailing lists and news groups. The bug enables an unprivileged user to hang the system, requiring the system to be reset or power-cycled. With information provided by Intel, BSDI has developed a workaround for this problem. A beta version of the mod for BSD/OS version 3.1 is now available for testing from ftp://ftp.bsdi.com/bsdi/patches/patches-3.1/M310-hangfix This mod may also be applied to 3.0 based systems. The workaround is enabled only on P5 processors, and should not be necessary on Pentium Pro, Pentium II or non-Intel CPUs. The mod is currently available only in binary form. We anticipate general release of the mod within a day or so. We are interested in hearing of any problems experienced with this change. We are also interested in hearing about testing on any non-Intel Pentium-compatible systems. Please send any reports to bsdi-hang-beta@BSDI.COM We are not at liberty to discuss the mechanism of the workaround at this time. If you are installing the mod in a source kernel tree, you will need to copy the files sys/i386/OBJ/{machdep.o,locore.o} to your kernel compile directory before rebuilding your kernel. Jeff - -- /\ Jeff Polk Berkeley Software Design, Inc. (BSDI) /\/ \ polk@BSDI.COM 5575 Tech Center Dr. #110, Colo Spgs, CO 80919 - -- To unsubscribe from this list, send 'unsubscribe' in the body of an e-mail message to 'bsdi-users-request@mailinglists.org' ------- End of Forwarded Message From owner-freebsd-security Wed Nov 12 12:28:12 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA06529 for security-outgoing; Wed, 12 Nov 1997 12:28:12 -0800 (PST) (envelope-from owner-freebsd-security) Received: from passer.osg.gov.bc.ca (passer.osg.gov.bc.ca [142.32.110.29]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id MAA06242; Wed, 12 Nov 1997 12:27:04 -0800 (PST) (envelope-from cschuber@uumail.gov.bc.ca) Received: (from cschuber@localhost) by passer.osg.gov.bc.ca (8.8.8/8.6.10) id MAA02624; Wed, 12 Nov 1997 12:26:48 -0800 (PST) Date: Wed, 12 Nov 1997 12:26:48 -0800 (PST) Message-Id: <199711122026.MAA02624@passer.osg.gov.bc.ca> Mime-Version: 1.0 X-Newsreader: knews 0.9.8 From: cschuber@osg.gov.bc.ca (Cy Schubert - ITSD Open Systems Group) Subject: Illegal Instruction Erratum (Intel's position) (fwd) To: security-officer@freebsd.org, freebsd-security@freebsd.org Content-Type: message/rfc822 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk The following was posted by support@mailbox.intel.com (Joe Goldmeer) on comp.sys.intel. It may be of interest to you. ------------------ Start of forwarded message ---------------------- Hi, On Friday afternoon (11/7/97) we discovered a number of postings in newsgroups talking about a potential processor "bug." Working all weekend, we have confirmed a new erratum on Pentium(R) processor and the Pentium(R) processor with MMX(TM) technology and have been aggressively pursing this issue in a very accelerated manner. If a user with access rights to the operating environment and execution rights on the processor itself intentionally issues a specific illegal instruction in native machine language to the processor, the invalid instruction is not flagged and the system stops immediately. It is important to note that this erratum will only occur when someone has intentionally created this invalid instruction because they want to crash the system. The expected behavior is that the processor should return an "exception flag" to the operating system telling it that an illegal instruction was issued. This does not occur and the user system hangs; all the user needs to do is reboot to return to normal operation. There are a number of ways of dealing with errata. These include advising software authors of applicable programming techniques, implementing operating systems patches, and hardware modifications. We have been aggressive in investigating and characterizing this issue since Friday 11/7. We are following our normal(albeit accelerated) process and have begun the process of working with key industry software and hardware providers to determine the best workaround for this issue. We expect to have an update on the status of the workarounds within the next week. Intel has created a web page dedicated to this issue available to the public. It can be found at: http://support.intel.com/support/processors/pentium/ppiie/index.htm Joe Goldmeer Intel Internet Support ----------------- End of forwarded message ------------------------- Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 UNIX Support OV/VM: BCSC02(CSCHUBER) ITSD BITNET: CSCHUBER@BCSC02.BITNET Government of BC Internet: cschuber@uumail.gov.bc.ca Cy.Schubert@gems8.gov.bc.ca "Quit spooling around, JES do it." From owner-freebsd-security Thu Nov 13 02:15:41 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id CAA02555 for security-outgoing; Thu, 13 Nov 1997 02:15:41 -0800 (PST) (envelope-from owner-freebsd-security) Received: from itesec.hsc.fr (root@itesec.hsc.fr [192.70.106.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id CAA02549; Thu, 13 Nov 1997 02:15:29 -0800 (PST) (envelope-from pb@hsc.fr) Received: from mars.hsc.fr (pb@mars.hsc.fr [192.70.106.44]) by itesec.hsc.fr (8.8.8/8.8.5/itesec-1.10-nospam) with ESMTP id LAA11568; Thu, 13 Nov 1997 11:15:08 +0100 (MET) Received: (from pb@localhost) by mars.hsc.fr (8.8.5/8.8.5/pb-19970301) id LAA27368; Thu, 13 Nov 1997 11:13:54 +0100 (MET) Message-ID: <19971113111353.YC28927@mars.hsc.fr> Date: Thu, 13 Nov 1997 11:13:53 +0100 From: Pierre.Beyssac@hsc.fr (Pierre Beyssac) To: cschuber@uumail.gov.bc.ca (Cy Schubert - ITSD Open Systems Group) Cc: security-officer@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Updating microcode on the fly References: <199711121550.HAA06579@cwsys.cwsent.com> X-Mailer: Mutt 0.59.1e Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit In-Reply-To: <199711121550.HAA06579@cwsys.cwsent.com>; from Cy Schubert - ITSD Open Systems Group on Nov 12, 1997 07:49:50 -0800 Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk According to Cy Schubert - ITSD Open Systems Group: > ========== ftp://ftp.sco.com/SLS/ptf3343.ltr ================= > > Dear SCO Customer, > > The enclosed Support Level Supplement (SLS) PTF3343, the Intel Pentium Pro > and Pentium II Microcode Driver, provides Intel P6 microcode fixes. Apparently, this is an unrelated microcode fix for the P6. It probably won't fix the illegal instruction bug which, according to Intel, occurs only on the P5 : http://support.intel.com/support/processors/pentium/ppiie/index.htm This erratum does not affect the Pentium® Pro processor or the Pentium® II Processor. [ Note their cute statement that "all the user has to do is reboot the system". They're apparently not aware about multiuser systems or remote administration. ] And the famed BSDI patch is apparently not available yet: $ lynx ftp://ftp.bsdi.com/bsdi/patches/patches-3.1/M310-hangfix $ more M310-hangfix The M310-hangfix beta patch is unavailable at the moment. We'll keep everyone posted. In conclusion it seems that for the moment nobody has a fix: not SCO, not BSDI, and probably not even Intel. -- Pierre.Beyssac@hsc.fr From owner-freebsd-security Thu Nov 13 03:28:27 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id DAA05541 for security-outgoing; Thu, 13 Nov 1997 03:28:27 -0800 (PST) (envelope-from owner-freebsd-security) Received: from edina.xenologics.com (edina.xenologics.com [194.77.5.1]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id DAA05535; Thu, 13 Nov 1997 03:28:12 -0800 (PST) (envelope-from stepken@edina.xnc.com) Received: from www (xpl114.xnc.de [194.77.5.78]) by edina.xenologics.com (8.6.8.1/8.6.6) with SMTP id MAA08794; Thu, 13 Nov 1997 12:26:09 +0100 Message-ID: <346AE3D8.29BAE4D1@edina.xnc.com> Date: Thu, 13 Nov 1997 12:26:16 +0100 From: Stepken Organization: F.S.S. X-Mailer: Mozilla 3.01Gold (X11; I; Linux 2.0.30 i586) MIME-Version: 1.0 To: Pierre Beyssac CC: Cy Schubert - ITSD Open Systems Group , security-officer@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Updating microcode on the fly References: <199711121550.HAA06579@cwsys.cwsent.com> <19971113111353.YC28927@mars.hsc.fr> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by hub.freebsd.org id DAA05537 Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Pierre Beyssac wrote: > > According to Cy Schubert - ITSD Open Systems Group: > > ========== ftp://ftp.sco.com/SLS/ptf3343.ltr ================= > > > > Dear SCO Customer, > > > > The enclosed Support Level Supplement (SLS) PTF3343, the Intel Pentium Pro > > and Pentium II Microcode Driver, provides Intel P6 microcode fixes. > > Apparently, this is an unrelated microcode fix for the P6. It probably > won't fix the illegal instruction bug which, according to Intel, occurs > only on the P5 : > > http://support.intel.com/support/processors/pentium/ppiie/index.htm > > This erratum does not affect the Pentium® Pro processor or > the Pentium® II Processor. > > [ Note their cute statement that "all the user has to do is reboot > the system". They're apparently not aware about multiuser systems > or remote administration. ] > > And the famed BSDI patch is apparently not available yet: > > $ lynx ftp://ftp.bsdi.com/bsdi/patches/patches-3.1/M310-hangfix > $ more M310-hangfix > The M310-hangfix beta patch is unavailable at the moment. We'll > keep everyone posted. > > In conclusion it seems that for the moment nobody has a fix: not > SCO, not BSDI, and probably not even Intel. > -- > Pierre.Beyssac@hsc.fr Oh, sure LINUX has. it came out 8 Hours later. cu, Guido Stepken From owner-freebsd-security Fri Nov 14 04:09:50 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id EAA23470 for security-outgoing; Fri, 14 Nov 1997 04:09:50 -0800 (PST) (envelope-from owner-freebsd-security) Received: from antioche.lip6.fr (antioche.lip6.fr [132.227.61.33]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id EAA23465; Fri, 14 Nov 1997 04:09:35 -0800 (PST) (envelope-from bouyer@antioche.lip6.fr) Received: from antifer.ipv6.lip6.fr (antifer.ipv6.lip6.fr [132.227.61.34]) by antioche.lip6.fr (8.8.7/8.8.5) with ESMTP id NAA19778; Fri, 14 Nov 1997 13:08:59 +0100 (MET) Received: (bouyer@localhost) by antifer.ipv6.lip6.fr (8.8.5/8.6.4) id NAA25513; Fri, 14 Nov 1997 13:08:57 +0100 (MET) Message-ID: <19971114130857.37773@antioche.lip6.fr> Date: Fri, 14 Nov 1997 13:08:57 +0100 From: Manuel BOUYER To: security-officer@FreeBSD.ORG, freebsd-security@FreeBSD.ORG Subject: Re: Updating microcode on the fly References: <199711121550.HAA06579@cwsys.cwsent.com> <19971113111353.YC28927@mars.hsc.fr> <346AE3D8.29BAE4D1@edina.xnc.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.76e In-Reply-To: <346AE3D8.29BAE4D1@edina.xnc.com>; from Stepken on Thu, Nov 13, 1997 at 12:26:16PM +0100 Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk On Nov 13, Stepken wrote > Oh, sure LINUX has. it came out 8 Hours later. > NetBSD has one too, which seems to work on my p100 -- Manuel Bouyer, LIP6, Universite Paris VI. Manuel.Bouyer@lip6.fr -- From owner-freebsd-security Fri Nov 14 08:01:03 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id IAA08855 for security-outgoing; Fri, 14 Nov 1997 08:01:03 -0800 (PST) (envelope-from owner-freebsd-security) Received: from shadows.aeon.net (bsdsec@shadows.aeon.net [194.100.41.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id IAA08782; Fri, 14 Nov 1997 08:00:02 -0800 (PST) (envelope-from bsdsec@shadows.aeon.net) Received: (from bsdsec@localhost) by shadows.aeon.net (8.8.7/8.8.3) id RAA15357; Fri, 14 Nov 1997 17:48:43 +0200 (EET) From: mika ruohotie Message-Id: <199711141548.RAA15357@shadows.aeon.net> Subject: Re: Updating microcode on the fly In-Reply-To: <19971114130857.37773@antioche.lip6.fr> from Manuel BOUYER at "Nov 14, 97 01:08:57 pm" To: bouyer@antioche.lip6.fr (Manuel BOUYER) Date: Fri, 14 Nov 1997 17:48:43 +0200 (EET) Cc: security-officer@FreeBSD.ORG, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL31 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk > On Nov 13, Stepken wrote > > Oh, sure LINUX has. it came out 8 Hours later. > NetBSD has one too, which seems to work on my p100 neither is a fix, just a (cruel) hack somewhat around the problem... mickey From owner-freebsd-security Fri Nov 14 12:41:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA01983 for security-outgoing; Fri, 14 Nov 1997 12:41:39 -0800 (PST) (envelope-from owner-freebsd-security) Received: from room101.sysc.com (qmailr@richmojm2.student.rose-hulman.edu [137.112.206.126]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA01969 for ; Fri, 14 Nov 1997 12:41:30 -0800 (PST) (envelope-from jayrich@room101.sysc.com) Received: (qmail 20229 invoked by uid 1000); 14 Nov 1997 20:40:59 -0000 Date: Fri, 14 Nov 1997 15:40:59 -0500 (EST) From: "Jay M. Richmond" To: freebsd-security@freebsd.org Subject: Pentium bug workaround in NetBSD (was Re: Intel Pentium Bug: BSDI Releases a patch) (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk ---------- Forwarded message ---------- Date: Fri, 14 Nov 1997 08:30:21 -0500 From: "Charles M. Hannum" To: BUGTRAQ@NETSPACE.ORG Subject: Pentium bug workaround in NetBSD (was Re: Intel Pentium Bug: BSDI Releases a patch) FYI, I put a patch similar in nature to the BSDI one in the NetBSD kernel. It seems to work, and crashme has been unable to crash my machine so far. However, I note three caveats to this approach: * With this workaround, it's impossible for the kernel to distinguish whether exceptions 0-2 and 6 occured due to an INT ${0-2,6} instruction or due to their normal causes. Without the workaround, an INT ${0-2,6} instruction would normally cause a protection fault, in turn causing the process to get a SIGBUS, because the descriptors for these exceptions are marked as not being callable by user code. Instead the process will get a SIGFPE, SIGTRAP, SIGBUS, or SIGILL, depending on which of INT ${0-2,6} was executed. * There's also no way to distinguish whether we got exceptions 3-4 due to an INT3 or INTO instruction, or due to an INT ${3-4} instruction, without actually inspecting the user code. Ideally, we want to know this so we can advance the PC the right amount; the page fault is a restartable exception, and the saved PC points to the {INT3,INTO,INT $N} instruction, whereas these instructions normally cause the exception to be taken after the PC has been advanced. Currently I just patch the PC as if the exception always occured due to INT3 or INTO, since no real code uses INT ${3-4}, or uses a prefix on them, and I'd rather not slow down this path much more to check. * The previous also applies to the exception 5 and the BOUND instruction, which I haven't fully dealt with as of this writing. (It actually uses the operand size prefix, so it needs to be decoded. YUCK.) Note that since VM86 mode always traps INT instructions via a GP fault, code running in VM86 mode is unaffected by this. In the all too likely event that some whacked out DOS program actually uses INT ${0-6}, its behaviour inside doscmd or dosemu should not change. From owner-freebsd-security Fri Nov 14 12:41:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA01984 for security-outgoing; Fri, 14 Nov 1997 12:41:39 -0800 (PST) (envelope-from owner-freebsd-security) Received: from room101.sysc.com (qmailr@richmojm2.student.rose-hulman.edu [137.112.206.126]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA01973 for ; Fri, 14 Nov 1997 12:41:30 -0800 (PST) (envelope-from jayrich@room101.sysc.com) Received: (qmail 20395 invoked by uid 1000); 14 Nov 1997 20:41:11 -0000 Date: Fri, 14 Nov 1997 15:41:11 -0500 (EST) From: "Jay M. Richmond" To: freebsd-security@freebsd.org Subject: Re: Pentium bug workaround in NetBSD (was Re: Intel Pentium Bug: BSDI Releases a patch) (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzQe9IMAAAEEAKVCBVhfVHCyNOsNvCwXbamYDslPoBoUgllJxGWrjYr8+XOS mAIo6VNyR6E0Q57SICfxAlw8CfrW3jSFZxCalyAr7f4SU/ioF7qOx9AEeRePKbQD XQYT/eUirjo4h1TzQPWMrlGtnehTJfX4LKLeu8WRsMog/6LMzxBohdeuTAY9AAUR tCJKYXkgTS4gUmljaG1vbmQgPGpheXJpY2hAc3lzYy5jb20+ =PTZq -----END PGP PUBLIC KEY BLOCK----- ---------- Forwarded message ---------- Date: Fri, 14 Nov 1997 10:50:53 -0500 From: "Charles M. Hannum" To: BUGTRAQ@NETSPACE.ORG Subject: Re: Pentium bug workaround in NetBSD (was Re: Intel Pentium Bug: BSDI Releases a patch) > It occurs to me that there may be another way to solve this -- [...] An addendum to the previous: Not quite all entries into the page fault handler will be due to user instructions. In particular, our partially mapped IDT may cause a page fault during a normal trace trap. This should not be reexcuted; if we do so, we'll skip an instruction, which would screw the debugger. We should be able to differentiate this condition by checking for the RF flag; if it's not set, then the trap wasn't due to a particular instruction, and we should emulate it per the BSDI code. Using the RF flag, though, we could also fix the BSDI hack to not have the original caveats. If RF is set, we know that a particular instruction caused the fault, and we can always decode it to decide what to do: * If the page fault was for vectors 3-5, advance the PC past the instruction, turn off the RF flag, and enter the fault handler for the real exception. * If the page fault was for vectors 0-2 or 6, and the instruction was not INT, don't advance the PC, and enter the fault handler for the real exception. * If the page fault was for vectors 0-2 or 6, and the instruction was INT, don't advance the PC, and enter the privileged instruction handler. (Change the above rules as appropriate if you care about what happens with the undocumented INT01 instruction.) [And now I'm really going to go sleep. B-)] From owner-freebsd-security Fri Nov 14 12:41:51 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id MAA02023 for security-outgoing; Fri, 14 Nov 1997 12:41:51 -0800 (PST) (envelope-from owner-freebsd-security) Received: from room101.sysc.com (qmailr@richmojm2.student.rose-hulman.edu [137.112.206.126]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id MAA02015 for ; Fri, 14 Nov 1997 12:41:47 -0800 (PST) (envelope-from jayrich@room101.sysc.com) Received: (qmail 20400 invoked by uid 1000); 14 Nov 1997 20:41:26 -0000 Date: Fri, 14 Nov 1997 15:41:26 -0500 (EST) From: "Jay M. Richmond" To: freebsd-security@freebsd.org Subject: Re: Pentium bug workaround in NetBSD (was Re: Intel Pentium Bug: BSDI Releases a patch) (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzQe9IMAAAEEAKVCBVhfVHCyNOsNvCwXbamYDslPoBoUgllJxGWrjYr8+XOS mAIo6VNyR6E0Q57SICfxAlw8CfrW3jSFZxCalyAr7f4SU/ioF7qOx9AEeRePKbQD XQYT/eUirjo4h1TzQPWMrlGtnehTJfX4LKLeu8WRsMog/6LMzxBohdeuTAY9AAUR tCJKYXkgTS4gUmljaG1vbmQgPGpheXJpY2hAc3lzYy5jb20+ =PTZq -----END PGP PUBLIC KEY BLOCK----- ---------- Forwarded message ---------- Date: Fri, 14 Nov 1997 09:49:27 -0500 From: "Charles M. Hannum" To: BUGTRAQ@NETSPACE.ORG Subject: Re: Pentium bug workaround in NetBSD (was Re: Intel Pentium Bug: BSDI Releases a patch) It occurs to me that there may be another way to solve this -- with a slightly higher performance penalty. To put it simply: return to user mode and let the instruction be executed again. To make this work, I suggest: * Create the partially mapped IDT as per the BSDI patch. Use it. * Create a second copy of the IDT that it fully mapped. For each vector in this second copy, install a routine which first reloads the IDT pointer to point to the partially mapped IDT and then uses the normal routine. * When we get a page fault, check to see if the fault was in the second IDT, and if so turn off interrupts (with a CLI), load the pointer to the first IDT, gratuitously fetch the IDT descriptor for exception 6 to make sure it's in the cache, and return to user mode (doing an implicit CLI during the IRET). The theory is that we reexecute the faulting instruction with a normal-looking IDT, making sure that the descriptor is in the L1 cache, so we don't get the hang. The only way it would get rotated out of the cache before the instruction is reexecuted would be if an interrupt or exception occurs (i.e. some other code is caused to execute) between when we reload the IDT pointer to the fully mapped IDT and when the instruction is reexecuted. To prevent this, we arrange for any such interrupt or exception to cause the partially mapped IDT to be loaded again, and thus when the interrupt or exception completes, the instruction would cause another page fault. This has a bit more performance impact on debuggers (because trace and breakpoint traps are handled through this mechanism, with an additional ~100 cycles on a 486), but it shouldn't have any of the caveats I previously mentioned. [I'd implement this right now and try it, but I *really* have to go sleep now. Recovering from a cold. *sigh*] From owner-freebsd-security Fri Nov 14 17:02:43 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA17910 for security-outgoing; Fri, 14 Nov 1997 17:02:43 -0800 (PST) (envelope-from owner-freebsd-security) Received: from room101.sysc.com (qmailr@richmojm2.student.rose-hulman.edu [137.112.206.126]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA17897 for ; Fri, 14 Nov 1997 17:02:34 -0800 (PST) (envelope-from jayrich@room101.sysc.com) Received: (qmail 2388 invoked by uid 1000); 15 Nov 1997 01:02:04 -0000 Date: Fri, 14 Nov 1997 20:02:04 -0500 (EST) From: "Jay M. Richmond" To: security-officer@freebsd.org cc: freebsd-security@freebsd.org Subject: Pentium processor invalid instruction erratum (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id RAA17904 Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzQe9IMAAAEEAKVCBVhfVHCyNOsNvCwXbamYDslPoBoUgllJxGWrjYr8+XOS mAIo6VNyR6E0Q57SICfxAlw8CfrW3jSFZxCalyAr7f4SU/ioF7qOx9AEeRePKbQD XQYT/eUirjo4h1TzQPWMrlGtnehTJfX4LKLeu8WRsMog/6LMzxBohdeuTAY9AAUR tCJKYXkgTS4gUmljaG1vbmQgPGpheXJpY2hAc3lzYy5jb20+ =PTZq -----END PGP PUBLIC KEY BLOCK----- ---------- Forwarded message ---------- Date: Fri, 14 Nov 1997 15:59:06 -0600 From: Aleph One To: BUGTRAQ@NETSPACE.ORG Subject: Pentium processor invalid instruction erratum http://support.intel.com/support/processors/pentium/ppiie/descrip.htm Pentium processor invalid instruction erratum Erratum Technical Description Problem: The CMPXCHG8B instruction compares an 8 byte value in EDX and EAX with an 8 byte value in memory (the destination operand). The only valid destination operands for this instruction are memory operands. If the destination operand is a register the processor should generate an invalid opcode exception, execution of the CMPXCHG8B instruction should be halted and the processor should execute the invalid opcode exception handler. This erratum occurs if the LOCK prefix is used with the CMPXCHG8B instruction with an (invalid) register destination operand. In this case, the processor may not start execution of the invalid opcode exception handler because the bus is locked. This results in a system hang. Implication: If an (invalid) register destination operand is used with the CMPXCHG8B instruction and the LOCK prefix, the system may hang. No memory data is corrupted and the user can perform a system reset to return to normal operation. Note that the specific invalid code sequence necessary for this erratum to occur is not normally generated in the course of programming nor is such a sequence generated by commercially available software. This erratum only applies to Pentium® processors, Pentium processors with MMX™ technology, Pentium OverDrive® processors and Pentium OverDrive processors with MMX technology. Pentium Pro processors, Pentium II processors and i486™ and earlier processors are not affected. Workaround: The recommended workaround for protected mode operating systems is to always create a page not present fault when an invalid opcode exception occurs. This page not present fault will be serviced before the invalid opcode exception and thus prevent the lock condition from occurring. The implementation details will differ depending on the operating system. The workaround has two parts. First, the Interrupt Descriptor Table (IDT) is aligned such that any invalid opcode exception will cause a page not present fault. Second, the page fault handler is modified to recognize and correctly dispatch the invalid opcode exception and certain other exceptions that are now routed through the page fault handler. Part I, IDT Alignment: 1. Align the Interrupt Descriptor Table (IDT) such that it spans a 4KB page boundary by placing the first entry starting 56 bytes from the end of the first 4KB page. This places the first seven entries (0-6) on the first 4KB page, and the remaining entries on the second page. 2. The page containing the first seven entries of the IDT must not have a mapping in the OS page tables. This will cause any of exceptions 0-6 to generate a page not present fault. A page not present fault prevents the bus lock condition and gives the OS complete control to process these exceptions as appropriate. Note that exception 6 is the invalid opcode exception, so with this scheme an OS has complete control of any program executing an invalid CMPXCHG8B instruction. Part II, Page Fault Handler Modifications: 1. Recognize accesses to the first page of the IDT by testing the fault address in CR2. Page not present faults on other addresses can be processed normally. 2. For page not present faults on the first page of the IDT, the OS must recognize and dispatch the exception which caused the page not present fault. Before proceeding, test the fault address in CR2 to determine if it is in the address range corresponding to exceptions 0-6. 3. Calculate which exception caused the page not present fault from the fault address in CR2. 4. Depending on the operating system, certain privilege level checks may be required, along with adjustments to the interrupt stack. 5. Jump to the normal handler for the appropriate exception. This workaround should only be implemented on Intel processors that return Family=5 via the CPUID instruction. 75/90/100/120/133/150/166/200 MHz Pentium Processors and 120/133/150/166/200/233 MHz Pentium Processors with MMX Technology 60 MHz and 66 MHz Pentium Processors 63/83/120/125/133/150/166 MHz Pentium OverDrive Processors and 125/150/166/180/200 MHz Pentium OverDrive Processors with MMX Technology From owner-freebsd-security Fri Nov 14 17:03:31 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA17985 for security-outgoing; Fri, 14 Nov 1997 17:03:31 -0800 (PST) (envelope-from owner-freebsd-security) Received: from room101.sysc.com (richmojm2.student.rose-hulman.edu [137.112.206.126]) by hub.freebsd.org (8.8.7/8.8.7) with SMTP id RAA17974 for ; Fri, 14 Nov 1997 17:03:23 -0800 (PST) (envelope-from jayrich@room101.sysc.com) Received: (qmail 2395 invoked by uid 1000); 15 Nov 1997 01:02:37 -0000 Date: Fri, 14 Nov 1997 20:02:37 -0500 (EST) From: "Jay M. Richmond" To: security-officer@freebsd.org cc: freebsd-security@freebsd.org Subject: Software backgrounder (fwd) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by hub.freebsd.org id RAA17978 Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk -----BEGIN PGP PUBLIC KEY BLOCK----- Version: 2.6.2 mQCNAzQe9IMAAAEEAKVCBVhfVHCyNOsNvCwXbamYDslPoBoUgllJxGWrjYr8+XOS mAIo6VNyR6E0Q57SICfxAlw8CfrW3jSFZxCalyAr7f4SU/ioF7qOx9AEeRePKbQD XQYT/eUirjo4h1TzQPWMrlGtnehTJfX4LKLeu8WRsMog/6LMzxBohdeuTAY9AAUR tCJKYXkgTS4gUmljaG1vbmQgPGpheXJpY2hAc3lzYy5jb20+ =PTZq -----END PGP PUBLIC KEY BLOCK----- ---------- Forwarded message ---------- Date: Fri, 14 Nov 1997 16:08:26 -0600 From: Aleph One To: BUGTRAQ@NETSPACE.ORG Subject: Software backgrounder http://support.intel.com/support/processors/pentium/ppiie/softback.htm Pentium processor invalid instruction erratum Software backgrounder workaround for "Invalid Operand with Locked CMPXCHG8B Instruction" erratum. The LOCK Prefix Some types of programs perform computations that require data accesses to have a specific ordering. These types of programs most commonly include operating systems, database engines, and applications for multiple processors. To ensure the ordering of data accesses, these programs use synchronization. Synchronization may be done by either software or hardware methods, but most programs use hardware synchronization for efficiency. Hardware synchronization usually involves reading and updating a memory location, with the hardware ensuring that the sequence is done in one operation. Such a combined operation is called a locked access. Intel processors support locked accesses by an instruction feature called the lock prefix. This feature tells the processor that an instruction that updates memory is to be processed as a locked access to memory. The CMPXCHG8B Instruction Beginning with the Pentium® processor, Intel processors have provided special hardware support for synchronization using the CMPXCHG8B (compare and exchange 8 bytes) instruction. This instruction compares a specified memory location with processor registers, and conditionally updates the 8-byte memory location. When used with the lock prefix, this instruction provides very flexible hardware support for synchronization. The Erratum In Pentium processors, Pentium processors with MMX™ technology, Pentium OverDrive® processors, and Pentium OverDrive processors with MMX technology there is an erratum that affects the lock prefix on a CMPXCHG8B instruction with a register destination. This erratum does not affect the Pentium Pro processor, Pentium II processor, or the i486™ and earlier processors. The documented use of the CMPXCHG8B instruction requires an 8-byte memory destination; attempting to use a CMPXCHG8B to update a 4-byte processor register is a program error. A computer’s operating system typically processes program errors through error handling routines. The erratum may cause an unexpected system freeze, preventing the program error from being processed by the error handling routine. The affected form of the instruction is not contained in any operating system or other application known to Intel, nor is there any reasonable purpose for a software tool to generate it. Hence user software should not be affected. However, it is possible for a malicious program to use this instruction to cause a system freeze. The system freeze will not affect data that a user has already saved to disk. When the system is restarted all saved data will still be available. The Workaround Intel has developed a workaround for this erratum that can be incorporated by operating systems vendors. The workaround takes advantage of the memory management support provided by Intel processors. Specifically, it relies upon a page not present fault being processed before the program error handling routine. The page not present fault also prevents the memory bus lock caused by the lock prefix. When an affected instruction is processed and the processor attempts to invoke the error handling routine, it is made to encounter a page not present fault. While processing the page not present fault the program error is dispatched to the error handling routine as expected. The operating system then continues normally. If you are an operating system vendor and would like further information about the erratum or the workaround, see [20]Contact Info. Please identify yourself as an operating system vendor. From owner-freebsd-security Fri Nov 14 21:30:29 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id VAA01189 for security-outgoing; Fri, 14 Nov 1997 21:30:29 -0800 (PST) (envelope-from owner-freebsd-security) Received: from granite.sentex.net (granite.sentex.ca [199.212.134.1]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id VAA01183; Fri, 14 Nov 1997 21:30:25 -0800 (PST) (envelope-from mike@sentex.net) Received: from gravel (gravel-remote.sentex.ca [209.112.4.181]) by granite.sentex.net (8.8.6/8.6.9) with SMTP id AAA25898; Sat, 15 Nov 1997 00:31:51 -0500 (EST) Message-Id: <3.0.2.32.19971114232337.02496330@sentex.net> X-Sender: mdtancsa@sentex.net X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.2 (32) Date: Fri, 14 Nov 1997 23:23:37 -0500 To: questions@freebsd.org From: Mike Tancsa Subject: IPFW and ipfragment overlap attack... Cc: security@freebsd.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk Does anyone know of a way to prevent via ipfw the use of the ip fragment attack that was posted on bugtraq the other day ? Since this can take out NT/95 machines at will, it would be nice if I could protect my dialup users from outside attack. Also, it seems that FreeBSD is safe against this program is it not ? I am not a network programmer, but looking through /usr/src/sys/netinet/ip_input.c there are some safegaurds against this. Are there any modifications to the program that could effect FreeBSD ? ---Mike >Approved-By: aleph1@UNDERGROUND.ORG >X-Mailer: ELM [version 2.4 PL25] >Date: Thu, 13 Nov 1997 22:06:15 -0800 >Reply-To: route@RESENTMENT.INFONEXUS.COM >Sender: Bugtraq List >From: G P R >Subject: Linux IP fragment overlap bug >To: BUGTRAQ@NETSPACE.ORG > > > As it happens, Linux has a serious bug in it's IP fragmentation module. >More specifically, in the fragmentation reassembly code. More specifically, >the bug manifests itself in the `ip_glue()` function.... > > When Linux reassembles IP fragments to form the original IP datagram, it >runs in a loop, copying the payload from all the queued fragments into a newly >allocated buffer (which would then normally be passed to the IP layer proper). >From ip_fragment.c@376: > > fp = qp->fragments; > while(fp != NULL) > { > if(count+fp->len > skb->len) > { > error_to_big; > } > memcpy((ptr + fp->offset), fp->ptr, fp->len); > count += fp->len; > fp = fp->next; > } > > While it does check to see if the fragment length is too large, which would >have the kernel copy too much data, it doesn't check to see if the fragment >length is too small, which would have the kernel copy WAY too data (such is the >case if fp->len is < 0). ********************************************************************** Mike Tancsa (mike@sentex.net) * To do is to be -- Nietzsche Sentex Communications Corp, * To be is to do -- Sartre Cambridge, Ontario * Do be do be do -- Sinatra (http://www.sentex.net/~mdtancsa) * From owner-freebsd-security Sat Nov 15 01:28:40 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id BAA09701 for security-outgoing; Sat, 15 Nov 1997 01:28:40 -0800 (PST) (envelope-from owner-freebsd-security) Received: from lab321.ru (anonymous1.omsk.net.ru [194.226.32.34]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id BAA09686; Sat, 15 Nov 1997 01:28:10 -0800 (PST) (envelope-from Eugeny.Kuzakov@lab321.ru) Received: from lab321.ru (kev.l321.omsk.net.ru [194.226.33.68]) by lab321.ru (8.8.5-MVC-230497/8.8.5) with ESMTP id PAA25162; Sat, 15 Nov 1997 15:21:55 +0600 (OSK) Message-ID: <346DBE80.F45FD68D@lab321.ru> Date: Sat, 15 Nov 1997 15:23:44 +0000 From: Eugeny Kuzakov Organization: Powered by FreeBSD. X-Mailer: Mozilla 4.04 [en] (X11; I; FreeBSD 3.0-971022-SNAP i386) MIME-Version: 1.0 To: Mike Tancsa CC: questions@FreeBSD.ORG, security@FreeBSD.ORG Subject: Re: IPFW and ipfragment overlap attack... References: <3.0.2.32.19971114232337.02496330@sentex.net> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk Mike Tancsa wrote: > > Does anyone know of a way to prevent via ipfw the use of the ip fragment > attack that was posted on bugtraq the other day ? Since this can take out > NT/95 machines at will, it would be nice if I could protect my dialup users > from outside attack. Also, it seems that FreeBSD is safe against this > program is it not ? I am not a network programmer, but looking through > /usr/src/sys/netinet/ip_input.c there are some safegaurds against this. > Are there any modifications to the program that could effect FreeBSD ? ipfw add XXX deny log all from any to any frag It will be work. If MTU on interfaces on gateway not below 1500. -- Best wishes, Eugeny Kuzakov Laboratory 321 ( Omsk, Russia ) kev@lab321.ru From owner-freebsd-security Sat Nov 15 17:06:00 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id RAA08157 for security-outgoing; Sat, 15 Nov 1997 17:06:00 -0800 (PST) (envelope-from owner-freebsd-security) Received: from milf18.bus.net (milf18.bus.net [207.41.25.18]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id RAA08149 for ; Sat, 15 Nov 1997 17:05:52 -0800 (PST) (envelope-from cao@bus.net) Received: from localhost (cao@localhost) by milf18.bus.net (8.8.5/8.8.5) with SMTP id UAA07459 for ; Sat, 15 Nov 1997 20:05:44 -0500 (EST) X-Authentication-Warning: milf18.bus.net: cao owned process doing -bs Date: Sat, 15 Nov 1997 20:05:44 -0500 (EST) From: "Chuck O'Donnell" Reply-To: "Chuck O'Donnell" To: freebsd-security@freebsd.org Subject: permissions and /dev/speaker Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@freebsd.org X-Loop: FreeBSD.org Precedence: bulk If this is not an appropriate place for this question, please let me know. I would like to write to /dev/speaker from a CGI script to sound the speaker on a web server. I use the Apache http server compiled from sources and run under the user "nobody". The web server has multiple logins. By default, permissions on /dev/speaker are: crw------- 1 root wheel 26, 0 Nov 15 18:00 /dev/speaker I was thinking of creating a "speaker" user/group and placing the httpd user in that group, setting permissions as follows: crw-rw---- 1 root speaker 26, 0 Nov 15 18:00 /dev/speaker or bypassing the creation of the new user/group and using: crw-rw-rw- 1 root wheel 26, 0 Nov 15 18:00 /dev/speaker Is anyone aware of any potential problems or holes that may arise from this? Thoughts and suggestions are welcome. Thank you. Regards, Chuck O'Donnell