From owner-freebsd-ipfw@FreeBSD.ORG Mon May 12 11:01:39 2003 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 189D637B405 for ; Mon, 12 May 2003 11:01:39 -0700 (PDT) Received: from freefall.freebsd.org (freefall.freebsd.org [216.136.204.21]) by mx1.FreeBSD.org (Postfix) with ESMTP id 95FCC43F75 for ; Mon, 12 May 2003 11:01:38 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: from freefall.freebsd.org (peter@localhost [127.0.0.1]) by freefall.freebsd.org (8.12.9/8.12.9) with ESMTP id h4CI1cUp034872 for ; Mon, 12 May 2003 11:01:38 -0700 (PDT) (envelope-from owner-bugmaster@freebsd.org) Received: (from peter@localhost) by freefall.freebsd.org (8.12.9/8.12.9/Submit) id h4CI1cjN034866 for ipfw@freebsd.org; Mon, 12 May 2003 11:01:38 -0700 (PDT) Date: Mon, 12 May 2003 11:01:38 -0700 (PDT) Message-Id: <200305121801.h4CI1cjN034866@freefall.freebsd.org> X-Authentication-Warning: freefall.freebsd.org: peter set sender to owner-bugmaster@freebsd.org using -f From: FreeBSD bugmaster To: ipfw@FreeBSD.org Subject: Current problem reports assigned to you X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 May 2003 18:01:39 -0000 Current FreeBSD problem reports Critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2003/01/26] kern/47529 ipfw natd/ipfw lose TCP packets for firewalled o [2003/03/23] kern/50216 ipfw kernel panic on 5.0-current when use ipfw o [2003/04/28] kern/51485 ipfw "Fatal trap 12" from bridge code with ipf 3 problems total. Serious problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- o [2002/12/27] kern/46557 ipfw ipfw pipe show fails with lots of queues o [2003/04/18] kern/51132 ipfw kernel part of ipfw1 processes 'to not me o [2003/04/22] kern/51274 ipfw ipfw2 create dynamic rules with parent nu o [2003/04/24] kern/51341 ipfw ipfw rule 'deny icmp from any to any icmp 4 problems total. Non-critical problems S Submitted Tracker Resp. Description ------------------------------------------------------------------------------- a [2001/04/13] kern/26534 ipfw Add an option to ipfw to log gid/uid of w f [2002/01/11] kern/33804 ipfw ipfw bug/problem o [2002/12/07] kern/46080 ipfw [PATCH] logamount in ipfw2 does not defau o [2002/12/10] kern/46159 ipfw ipfw dynamic rules lifetime feature o [2002/12/27] kern/46564 ipfw IPFilter and IPFW processing order is not o [2003/01/05] bin/46785 ipfw [patch] add sets information to ipfw2 -h o [2003/01/15] bin/47120 ipfw [patch] Sanity check in ipfw(8) o [2003/02/06] bin/48015 ipfw make ipfw2 work with iplen ranges o [2003/02/11] kern/48172 ipfw ipfw does not log size and flags o [2003/03/10] kern/49086 ipfw [patch] Make ipfw2 log to different syslo o [2003/03/12] bin/49959 ipfw ipfw tee port rule skips parsing next rul o [2003/04/09] bin/50749 ipfw ipfw2 incorrectly parses ports and port r o [2003/04/20] kern/51182 ipfw ipfw2. -d list shows couters for dynamic o [2003/05/04] bin/51750 ipfw ipfw2.c typos 14 problems total. From owner-freebsd-ipfw@FreeBSD.ORG Tue May 13 03:58:05 2003 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4018537B401 for ; Tue, 13 May 2003 03:58:05 -0700 (PDT) Received: from radix.sorted.org (radix.sorted.org [194.70.217.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 082AD43FBF for ; Tue, 13 May 2003 03:58:04 -0700 (PDT) (envelope-from andy@sorted.org) Received: from radix.sorted.org (localhost [127.0.0.1]) by radix.sorted.org (Postfix) with SMTP id 2CEE42B905; Tue, 13 May 2003 11:58:01 +0100 (BST) Received: from 217.154.240.18 (SquirrelMail authenticated user andy) by radix.sorted.org with HTTP; Tue, 13 May 2003 11:58:01 +0100 (BST) Message-ID: <19025.217.154.240.18.1052823481.squirrel@radix.sorted.org> Date: Tue, 13 May 2003 11:58:01 +0100 (BST) From: andy@sorted.org To: freebsd-ipfw@freebsd.org User-Agent: SquirrelMail/1.4.0 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 X-Priority: 3 Importance: Normal Subject: Q: ipfw & divert sockets (2nd try) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 May 2003 10:58:05 -0000 Apologies if this is not the place for this question - I worked through the list of mailing lists and this seemed the appropriate spot (and apologies if you already have this mail from another address - reverse-DNS problems). I've been working to use FreeBSD4.8-STABLE/IPFW2 and a small user-land App linked to it via a divert socket, to encapsulate all outgoing data on a given interface into a UDP packet stream (and visa versa) - effectively an IP-over-UDP tunnel. The send-side of this seems to work fine - I can send a datagram, encapsulate it, and watch it travel over the network. Furthermore, the receive side seems to correctly deencapsulate the packet without raising an error. However, the deencapsulated packet, which is identical to its 'pre-encapsulated' form does not seem to make it out of the diverted socket, and appears to be dropped. Is what I'm doing possible within the IPFW2 framework, or am I trying to do something foolish? Are inbound packets handled differently to outbound ones? Yours in frustration, Andy -- Andrew Garrett andy@sorted.org From owner-freebsd-ipfw@FreeBSD.ORG Thu May 15 10:15:56 2003 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id C224037B401 for ; Thu, 15 May 2003 10:15:56 -0700 (PDT) Received: from cv.org (cv.org [66.111.39.80]) by mx1.FreeBSD.org (Postfix) with SMTP id 6920343F75 for ; Thu, 15 May 2003 10:15:56 -0700 (PDT) (envelope-from mrkocol@cv.org) Received: (qmail 10262 invoked by uid 48); 15 May 2003 16:18:44 -0000 Received: from 216.20.255.203 (SquirrelMail authenticated user mrkocol) by mail.cv.org with HTTP; Thu, 15 May 2003 09:18:44 -0700 (PDT) Message-ID: <51222.216.20.255.203.1053015524.squirrel@mail.cv.org> Date: Thu, 15 May 2003 09:18:44 -0700 (PDT) From: "Jason Kocol" To: X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.11) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: ipfw + dummynet: bandwidth limiting not working X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2003 17:15:57 -0000 I am running FreeBSD 4.8 STABLE and am trying to use dummynet with ipfw to limit bandwidth on my DSL connection. I have added the rules for dummynet to my existing firewall rules in rc.firewall (which are pretty open as you can see) in the last two lines below: ipfw -f flush ipfw add divert natd all from any to any via vx0 ipfw add pass all from any to any ipfw pipe 1 config bw 128K ipfw add pipe 1 tcp from x.x.x.x to any (x.x.x.x being my public IP address, and vx0 in line 2 being the interface for this address) By those last two lines I would expect the outbound/inbound traffic to be limited to 128Kbps, yet I am still able to transfer data at my normal broadband speeds (1.5Mb/768Kb). Anyone have any idea why this is not working the way I'd expect it to? Thanks, -Jason From owner-freebsd-ipfw@FreeBSD.ORG Thu May 15 10:22:56 2003 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 94F7637B401 for ; Thu, 15 May 2003 10:22:56 -0700 (PDT) Received: from exchange.wan.no (exchange.wan.no [80.86.128.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 6897C43F93 for ; Thu, 15 May 2003 10:22:55 -0700 (PDT) (envelope-from sten.daniel.sorsdal@wan.no) X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0 content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 15 May 2003 19:22:33 +0200 Message-ID: <0AF1BBDF1218F14E9B4CCE414744E70F1F3D40@exchange.wanglobal.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ipfw + dummynet: bandwidth limiting not working Thread-Index: AcMbBaBQPirHJIhiQZWTBg4uOcsQuAAAOOuA From: =?iso-8859-1?Q?Sten_Daniel_S=F8rsdal?= To: "Jason Kocol" , Subject: RE: ipfw + dummynet: bandwidth limiting not working X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2003 17:22:56 -0000 > I am running FreeBSD 4.8 STABLE and am trying to use dummynet=20 > with ipfw to > limit bandwidth on my DSL connection. I have added the rules=20 > for dummynet > to my existing firewall rules in rc.firewall (which are=20 > pretty open as you > can see) in the last two lines below: >=20 > ipfw -f flush > ipfw add divert natd all from any to any via vx0 > ipfw add pass all from any to any > ipfw pipe 1 config bw 128K > ipfw add pipe 1 tcp from x.x.x.x to any >=20 > (x.x.x.x being my public IP address, and vx0 in line 2 being=20 > the interface > for this address) >=20 > By those last two lines I would expect the outbound/inbound=20 > traffic to be > limited to 128Kbps, yet I am still able to transfer data at my normal > broadband speeds (1.5Mb/768Kb). >=20 > Anyone have any idea why this is not working the way I'd expect it to? >=20 Remove the line that says 'ipfw add pass all from any to any' and it = should work. - Sten From owner-freebsd-ipfw@FreeBSD.ORG Thu May 15 10:27:06 2003 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 49E8037B418 for ; Thu, 15 May 2003 10:27:05 -0700 (PDT) Received: from nfs.ssl-website.net (ns1.ssl-website.net [65.38.28.146]) by mx1.FreeBSD.org (Postfix) with ESMTP id 7565043F85 for ; Thu, 15 May 2003 10:27:04 -0700 (PDT) (envelope-from brian@bkw.org) Received: from brian.ssl-website.net ([65.38.28.149] helo=dell01) by nfs.ssl-website.net with asmtp (Exim 4.20) id 19GMVQ-00097f-Os; Thu, 15 May 2003 12:27:00 -0500 Message-ID: <05cc01c31b07$293d7380$951c2641@dell01> From: "Brian K. West" To: =?iso-8859-1?Q?Sten_Daniel_S=F8rsdal?= , "Jason Kocol" , References: <0AF1BBDF1218F14E9B4CCE414744E70F1F3D40@exchange.wanglobal.net> Date: Thu, 15 May 2003 12:26:46 -0500 Organization: BKW.ORG MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1158 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1165 Subject: Re: ipfw + dummynet: bandwidth limiting not working X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2003 17:27:06 -0000 Or atleast number your rules... so that it falls after the pipe config. And check out sysctl net.inet.ip.fw.one_pass bkw ----- Original Message ----- From: "Sten Daniel Sørsdal" To: "Jason Kocol" ; Sent: Thursday, May 15, 2003 12:22 PM Subject: RE: ipfw + dummynet: bandwidth limiting not working > I am running FreeBSD 4.8 STABLE and am trying to use dummynet > with ipfw to > limit bandwidth on my DSL connection. I have added the rules > for dummynet > to my existing firewall rules in rc.firewall (which are > pretty open as you > can see) in the last two lines below: > > ipfw -f flush > ipfw add divert natd all from any to any via vx0 > ipfw add pass all from any to any > ipfw pipe 1 config bw 128K > ipfw add pipe 1 tcp from x.x.x.x to any > > (x.x.x.x being my public IP address, and vx0 in line 2 being > the interface > for this address) > > By those last two lines I would expect the outbound/inbound > traffic to be > limited to 128Kbps, yet I am still able to transfer data at my normal > broadband speeds (1.5Mb/768Kb). > > Anyone have any idea why this is not working the way I'd expect it to? > Remove the line that says 'ipfw add pass all from any to any' and it should work. - Sten _______________________________________________ freebsd-ipfw@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ipfw To unsubscribe, send any mail to "freebsd-ipfw-unsubscribe@freebsd.org" From owner-freebsd-ipfw@FreeBSD.ORG Thu May 15 14:01:44 2003 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2551937B401 for ; Thu, 15 May 2003 14:01:43 -0700 (PDT) Received: from hubsch.org (as1-3-6.ars.s.bonet.se [194.236.5.112]) by mx1.FreeBSD.org (Postfix) with SMTP id C236343F3F for ; Thu, 15 May 2003 14:01:41 -0700 (PDT) (envelope-from nisse@hubsch.org) Received: (qmail 64560 invoked by uid 204); 15 May 2003 21:01:38 -0000 Received: from unknown (HELO snaps.home) (172.16.1.3) by 0 with SMTP; 15 May 2003 21:01:38 -0000 Date: Thu, 15 May 2003 23:01:38 +0200 (CEST) From: nisse@hubsch.org X-X-Sender: micke@snaps.home To: freebsd-ipfw@freebsd.org Message-ID: <20030515225945.Y63945-100000@snaps.home> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: ipfw2: How to detect packets without incoming interface? X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 May 2003 21:01:44 -0000 In ipfw1 I could use "recv any" to indicate that a packet originated on a remote host. To for example prevent tcp traffic from being forwarded trough the host but still allow traffic to/from the host on all interfaces it was possible to say ipfw add deny tcp from any to any out recv any ipfw add allow tcp from any to any How do I do this with ipfw2? I want to detect locally generated packets. netinet/ip_fw2.c does't seem to handle the "any" case and ipfw2.c contains the following lines: /* Parse the interface or address */ if (!strcmp(arg, "any")) cmd->o.len = 0; /* effectively ignore this command */ -- Mikael Hubsch From owner-freebsd-ipfw@FreeBSD.ORG Thu May 15 19:48:56 2003 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 18ED537B401 for ; Thu, 15 May 2003 19:48:56 -0700 (PDT) Received: from cv.org (cv.org [66.111.39.80]) by mx1.FreeBSD.org (Postfix) with SMTP id 9A4F743FA3 for ; Thu, 15 May 2003 19:48:55 -0700 (PDT) (envelope-from mrkocol@cv.org) Received: (qmail 10668 invoked by uid 48); 16 May 2003 01:51:46 -0000 Received: from 64.36.78.74 (SquirrelMail authenticated user mrkocol) by mail.cv.org with HTTP; Thu, 15 May 2003 18:51:46 -0700 (PDT) Message-ID: <3910.64.36.78.74.1053049906.squirrel@mail.cv.org> Date: Thu, 15 May 2003 18:51:46 -0700 (PDT) From: "Jason Kocol" To: X-Priority: 3 Importance: Normal X-Mailer: SquirrelMail (version 1.2.11) MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Subject: Re: ipfw + dummynet: bandwidth limiting not working X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2003 02:48:56 -0000 > Remove the line that says 'ipfw add pass all from any to any' and it > should work. > > - Sten No, removing that line causes all traffic to the outside to cease. Meaning I can no longer ping out, cannot connect to any machine via ftp, http, etc. Also some services on startup complain, like mountd and RCP are unable to register. So it looks like I need to leave that line in in order to have a connection to the internet. > Or atleast number your rules... so that it falls after the pipe config. > > And check out sysctl net.inet.ip.fw.one_pass > > bkw Moving the rules around in the firewall script, or numbering them, did at least solve the problem of not configuring the pipe to the desired bitstream, but even doing that and setting net.inet.ip.fw.one_pass=0 still does not limit the bandwidth. Any other suggestions? Thanks, Jason >> I am running FreeBSD 4.8 STABLE and am trying to use dummynet >> with ipfw to >> limit bandwidth on my DSL connection. I have added the rules >> for dummynet >> to my existing firewall rules in rc.firewall (which are >> pretty open as you >> can see) in the last two lines below: >> >> ipfw -f flush >> ipfw add divert natd all from any to any via vx0 >> ipfw add pass all from any to any >> ipfw pipe 1 config bw 128K >> ipfw add pipe 1 tcp from x.x.x.x to any >> >> (x.x.x.x being my public IP address, and vx0 in line 2 being >> the interface >> for this address) >> >> By those last two lines I would expect the outbound/inbound >> traffic to be >> limited to 128Kbps, yet I am still able to transfer data at my normal >> broadband speeds (1.5Mb/768Kb). >> >> Anyone have any idea why this is not working the way I'd expect it to? From owner-freebsd-ipfw@FreeBSD.ORG Fri May 16 06:53:39 2003 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CD10037B401 for ; Fri, 16 May 2003 06:53:38 -0700 (PDT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id 7D72443FB1 for ; Fri, 16 May 2003 06:53:36 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 12053 invoked from network); 16 May 2003 13:47:26 -0000 Received: from office.sbnd.net (HELO straylight.ringlet.net) (217.75.140.130) by gandalf.online.bg with SMTP; 16 May 2003 13:47:25 -0000 Received: (qmail 14351 invoked by uid 1000); 16 May 2003 13:50:53 -0000 Date: Fri, 16 May 2003 16:50:53 +0300 From: Peter Pentchev To: ipfw@FreeBSD.org Message-ID: <20030516135052.GA13482@straylight.oblivion.bg> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Yylu36WmvOXNoKYn" Content-Disposition: inline User-Agent: Mutt/1.5.4i Subject: ipfw2 buffer overruns X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2003 13:53:40 -0000 --Yylu36WmvOXNoKYn Content-Type: multipart/mixed; boundary="Dxnq1zWXvFF0Q93v" Content-Disposition: inline --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, A friend of mine, Kiril Todorov (CC'd), recently came across some quite strange ipfw2 behavior on -STABLE: when given a specific rule to add, ipfw would hang. A bit of digging into src/sbin/ipfw/ipfw2.c revealed a couple of internal buffers - actbuf[], cmdbuf[], rulebuf[] - with a set length of 255, and a couple of pointers traversing those buffers which were never actually checked for running over the end. Thus, it was trivial to construct a long enough 'ipfw add' command that would eventually overrun the buffer, with much confusion ensuing. Attached is a sample rule that causes this, and a patch which performs a couple of length checks and refuses to add the rule if a buffer overrun is detected. This is not the most elegant solution, and in a couple of the checks the damage is already done, but still... The patch is against -STABLE; it applies to -CURRENT with just a couple of offset lines, and the resulting source compiles; I do not currently have a functional -CURRENT machine to test it on, though. It works on -STABLE, correctly diagnosing the oversized rule, and some other tests I threw at it in a hurry. Still, this is the first time I'm touching the ipfw code, so there is a very high probability that this is not the right way, or not even close to the right direction; feel free to point it out :) G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@sbnd.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 You have, of course, just begun reading the sentence that you have just fin= ished reading. --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=windows-1251 Content-Disposition: attachment; filename="rule.big" Content-Transfer-Encoding: quoted-printable add 10 skipto 1000 all from { 139.92.144.0/24 or 139.92.170.0/24 or 139.92.= 51.0/24 or 152.158.113.0/24 or 157.125.223.0/24 or 192.92.129.0/24 or 193.1= 08.24.0/24 or 193.108.32.0/23 or 193.109.54.0/23 or 193.110.159.0/24 or 193= =2E110.216.0/21 or 193.110.82.0/24 or 193.111.194.0/23 or 193.111.89.0/24 o= r 193.178.152.0/23 or 193.178.166.0/24 or 193.178.222.0/24 or 193.193.162.0= /22 or 193.193.164.0/24 or 193.193.182.0/24 or 193.194.140.0/23 or 193.194.= 141.0/24 or 193.194.156.0/24 or 193.200.0.0/16 or 193.201.114.0/24 or 193.2= 01.172.0/24 or 193.201.240.0/22 or 193.254.29.0/24 or 193.41.182.0/23 or 19= 3.41.188.0/22 or 193.41.206.0/24 or 193.41.64.0/22 or 193.68.0.0/19 or 193.= 68.128.0/17 or 193.68.96.0/19 or 194.12.224.0/19 or 194.141.0.0/16 or 194.1= 45.63.0/24 or 194.153.145.0/24 or 195.138.128.0/19 or 195.212.63.0/24 or 19= 5.230.0.0/19 or 195.234.236.0/22 or 195.24.32.0/19 or 195.34.96.0/19 or 195= =2E72.112.0/24 or 195.75.71.0/24 or 195.96.224.0/19 or 209.239.78.0/23 or 2= 12.116.128.0/19 or 212.122.160.0/19 or 212.124.64.0/19 or 212.21.128.0/19 o= r 212.36.0.0/19 or 212.39.64.0/19 or 212.50.0.0/19 or 212.5.128.0/19 or 212= =2E56.0/19 or 212.7.192.0/19 or 212.72.192.0/19 or 212.91.160.0/19 or 212.9= 5.160.0/19 or 213.130.64.0/19 or 213.137.32.0/19 or 213.145.96.0/19 or 213.= 16.32.0/19 or 213.169.32.0/19 or 213.174.0.0/19 or 213.191.192.0/19 or 213.= 208.10.0/23 or 213.222.32.0/19 or 213.226.0.0/18 or 213.91.128.0/17 or 217.= 10.240.0/20 or 217.18.240.0/20 or 217.145.160.0/20 or 217.197.128.0/20 or 2= 17.79.32.0/19 or 217.79.64.0/20 or 217.9.224.0/20 or 217.75.128.0/20 or 10.= 0.0.0/8 or 172.16.0.0/12 } to any --Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=windows-1251 Content-Disposition: attachment; filename="ipfw2-rel4.patch" Content-Transfer-Encoding: quoted-printable Index: src/sbin/ipfw/ipfw2.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D RCS file: /home/ncvs/src/sbin/ipfw/ipfw2.c,v retrieving revision 1.4.2.12 diff -u -r1.4.2.12 ipfw2.c --- src/sbin/ipfw/ipfw2.c 14 Apr 2003 12:41:37 -0000 1.4.2.12 +++ src/sbin/ipfw/ipfw2.c 16 May 2003 13:40:25 -0000 @@ -2481,6 +2481,14 @@ return NULL; } =20 +static void +check_length(ipfw_insn *cmd, size_t add, void *ptr, size_t size) +{ + + if ((uintptr_t)(cmd + add) > (uintptr_t)((char *)ptr + size)) + errx(EX_DATAERR, "Rule too long!"); +} + /* * Parse arguments and assemble the microinstructions which make up a rule. * Rules are added into the 'rulebuf' and then copied in the correct order @@ -2562,6 +2570,7 @@ NEED1("missing action"); i =3D match_token(rule_actions, *av); ac--; av++; + check_length(action, 1, actbuf, sizeof(actbuf)); /* superfluous.. */ action->len =3D 1; /* default */ switch(i) { case TOK_CHECKSTATE: @@ -2602,6 +2611,7 @@ case TOK_QUEUE: case TOK_PIPE: action->len =3D F_INSN_SIZE(ipfw_insn_pipe); + check_length(action, action->len, actbuf, sizeof(actbuf)); case TOK_SKIPTO: if (i =3D=3D TOK_QUEUE) action->opcode =3D O_QUEUE; @@ -2639,6 +2649,7 @@ =20 action->opcode =3D O_FORWARD_IP; action->len =3D F_INSN_SIZE(ipfw_insn_sa); + check_length(action, action->len, actbuf, sizeof(actbuf)); =20 p->sa.sin_len =3D sizeof(struct sockaddr_in); p->sa.sin_family =3D AF_INET; @@ -2665,6 +2676,7 @@ default: errx(EX_DATAERR, "invalid action %s\n", av[-1]); } + check_length(action, F_LEN(action), actbuf, sizeof(actbuf)); action =3D next_cmd(action); =20 /* @@ -2687,6 +2699,7 @@ errx(EX_DATAERR, "logamount must be positive"); ac--; av++; } + check_length(cmd, F_LEN(cmd), cmdbuf, sizeof(cmdbuf)); cmd =3D next_cmd(cmd); } =20 @@ -2751,12 +2764,16 @@ !strncmp(*av, "mac", strlen(*av))) { ac--; av++; /* the "MAC" keyword */ add_mac(cmd, ac, av); /* exits in case of errors */ + check_length(cmd, F_LEN(cmd), cmdbuf, sizeof(cmdbuf)); cmd =3D next_cmd(cmd); ac -=3D 2; av +=3D 2; /* dst-mac and src-mac */ NOT_BLOCK; NEED1("missing mac type"); if (add_mactype(cmd, ac, av[0])) + { + check_length(cmd, F_LEN(cmd), cmdbuf, sizeof(cmdbuf)); cmd =3D next_cmd(cmd); + } ac--; av++; /* any or mac-type */ goto read_options; } @@ -2775,6 +2792,7 @@ else { proto =3D cmd->arg1; prev =3D cmd; + check_length(cmd, F_LEN(cmd), cmdbuf, sizeof(cmdbuf)); cmd =3D next_cmd(cmd); } } else if (first_cmd !=3D cmd) { @@ -2800,6 +2818,7 @@ ac--; av++; if (F_LEN(cmd) !=3D 0) { /* ! any */ prev =3D cmd; + check_length(cmd, F_LEN(cmd), cmdbuf, sizeof(cmdbuf)); cmd =3D next_cmd(cmd); } } @@ -2814,7 +2833,10 @@ add_ports(cmd, *av, proto, O_IP_SRCPORT)) { ac--; av++; if (F_LEN(cmd) !=3D 0) + { + check_length(cmd, F_LEN(cmd), cmdbuf, sizeof(cmdbuf)); cmd =3D next_cmd(cmd); + } } } =20 @@ -2835,6 +2857,7 @@ ac--; av++; if (F_LEN(cmd) !=3D 0) { /* ! any */ prev =3D cmd; + check_length(cmd, F_LEN(cmd), cmdbuf, sizeof(cmdbuf)); cmd =3D next_cmd(cmd); } } @@ -2849,7 +2872,10 @@ add_ports(cmd, *av, proto, O_IP_DSTPORT)) { ac--; av++; if (F_LEN(cmd) !=3D 0) + { + check_length(cmd, F_LEN(cmd), cmdbuf, sizeof(cmdbuf)); cmd =3D next_cmd(cmd); + } } } =20 @@ -3167,6 +3193,7 @@ } if (F_LEN(cmd) > 0) { /* prepare to advance */ prev =3D cmd; + check_length(cmd, F_LEN(cmd), cmdbuf, sizeof(cmdbuf)); cmd =3D next_cmd(cmd); } } @@ -3187,6 +3214,7 @@ if (match_prob !=3D 1) { /* 1 means always match */ dst->opcode =3D O_PROB; dst->len =3D 2; + check_length(dst, 2, rulebuf, sizeof(rulebuf)); *((int32_t *)(dst+1)) =3D (int32_t)(match_prob * 0x7fffffff); dst +=3D dst->len; } @@ -3196,6 +3224,7 @@ */ if (have_state && have_state->opcode !=3D O_CHECK_STATE) { fill_cmd(dst, O_PROBE_STATE, 0, 0); + check_length(dst, F_LEN(dst), rulebuf, sizeof(rulebuf)); dst =3D next_cmd(dst); } /* @@ -3210,6 +3239,7 @@ case O_LIMIT: break; default: + check_length(dst, i, rulebuf, sizeof(rulebuf)); bcopy(src, dst, i * sizeof(u_int32_t)); dst +=3D i; } @@ -3220,6 +3250,7 @@ */ if (have_state && have_state->opcode !=3D O_CHECK_STATE) { i =3D F_LEN(have_state); + check_length(dst, i, rulebuf, sizeof(rulebuf)); bcopy(have_state, dst, i * sizeof(u_int32_t)); dst +=3D i; } @@ -3234,6 +3265,7 @@ src =3D (ipfw_insn *)cmdbuf; if ( src->opcode =3D=3D O_LOG ) { i =3D F_LEN(src); + check_length(dst, i, rulebuf, sizeof(rulebuf)); bcopy(src, dst, i * sizeof(u_int32_t)); dst +=3D i; } @@ -3242,6 +3274,7 @@ */ for (src =3D (ipfw_insn *)actbuf; src !=3D action; src +=3D i) { i =3D F_LEN(src); + check_length(dst, i, rulebuf, sizeof(rulebuf)); bcopy(src, dst, i * sizeof(u_int32_t)); dst +=3D i; } --Dxnq1zWXvFF0Q93v-- --Yylu36WmvOXNoKYn Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE+xOy87Ri2jRYZRVMRAstYAJ4yL/eZnXwGKNz7xhSlLmifds+BJQCcCWuw kWA58CT1Q6d+oibcgx4rYcA= =Pj5n -----END PGP SIGNATURE----- --Yylu36WmvOXNoKYn-- From owner-freebsd-ipfw@FreeBSD.ORG Fri May 16 07:01:09 2003 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 1AF4A37B48D for ; Fri, 16 May 2003 07:01:08 -0700 (PDT) Received: from gandalf.online.bg (gandalf.online.bg [217.75.128.9]) by mx1.FreeBSD.org (Postfix) with SMTP id A9FEF43F3F for ; Fri, 16 May 2003 07:01:06 -0700 (PDT) (envelope-from roam@ringlet.net) Received: (qmail 13161 invoked from network); 16 May 2003 13:54:56 -0000 Received: from office.sbnd.net (HELO straylight.ringlet.net) (217.75.140.130) by gandalf.online.bg with SMTP; 16 May 2003 13:54:55 -0000 Received: (qmail 15275 invoked by uid 1000); 16 May 2003 13:58:23 -0000 Date: Fri, 16 May 2003 16:58:23 +0300 From: Peter Pentchev To: ipfw@FreeBSD.org Message-ID: <20030516135823.GB13482@straylight.oblivion.bg> References: <20030516135052.GA13482@straylight.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1251 Content-Disposition: inline In-Reply-To: <20030516135052.GA13482@straylight.oblivion.bg> User-Agent: Mutt/1.5.4i Subject: Re: ipfw2 buffer overruns X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2003 14:01:09 -0000 On Fri, May 16, 2003 at 04:50:52PM +0300, Peter Pentchev wrote: > Hi, > > A friend of mine, Kiril Todorov (CC'd), recently came across some quite > strange ipfw2 behavior on -STABLE: when given a specific rule to add, > ipfw would hang. A bit of digging into src/sbin/ipfw/ipfw2.c revealed a > couple of internal buffers - actbuf[], cmdbuf[], rulebuf[] - with a set > length of 255, and a couple of pointers traversing those buffers which > were never actually checked for running over the end. Thus, it was > trivial to construct a long enough 'ipfw add' command that would > eventually overrun the buffer, with much confusion ensuing. > > Attached is a sample rule that causes this, and a patch which performs a > couple of length checks and refuses to add the rule if a buffer overrun > is detected. This is not the most elegant solution, and in a couple of > the checks the damage is already done, but still... > > The patch is against -STABLE; it applies to -CURRENT with just a couple > of offset lines, and the resulting source compiles; I do not currently > have a functional -CURRENT machine to test it on, though. It works on > -STABLE, correctly diagnosing the oversized rule, and some other tests I > threw at it in a hurry. Still, this is the first time I'm touching the > ipfw code, so there is a very high probability that this is not the > right way, or not even close to the right direction; feel free to point > it out :) I wonder; did this actually make it to the list? (I received a warning about an attachment that would require the recipient to execute a program on their end.. what is it about three text/plain files that would cause this? or is it the PGP/MIME sig?) In case it didn't, the patch and the big rule are both at http://people.FreeBSD.org/~roam/ipfw2/ G'luck, Peter -- Peter Pentchev roam@ringlet.net roam@sbnd.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 You have, of course, just begun reading the sentence that you have just finished reading. From owner-freebsd-ipfw@FreeBSD.ORG Fri May 16 12:46:53 2003 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id D583A37B404 for ; Fri, 16 May 2003 12:46:53 -0700 (PDT) Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by mx1.FreeBSD.org (Postfix) with ESMTP id 316AB43FAF for ; Fri, 16 May 2003 12:46:53 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: from blossom.cjclark.org (12-234-159-107.client.attbi.com[12.234.159.107]) by attbi.com (rwcrmhc52) with ESMTP id <2003051619465005200jbq3de>; Fri, 16 May 2003 19:46:50 +0000 Received: from blossom.cjclark.org (localhost. [127.0.0.1]) by blossom.cjclark.org (8.12.8p1/8.12.3) with ESMTP id h4GJkoki098383; Fri, 16 May 2003 12:46:50 -0700 (PDT) (envelope-from crist.clark@attbi.com) Received: (from cjc@localhost) by blossom.cjclark.org (8.12.8p1/8.12.8/Submit) id h4GJkmIV098382; Fri, 16 May 2003 12:46:48 -0700 (PDT) X-Authentication-Warning: blossom.cjclark.org: cjc set sender to crist.clark@attbi.com using -f Date: Fri, 16 May 2003 12:46:48 -0700 From: "Crist J. Clark" To: andy@sorted.org Message-ID: <20030516194648.GD98044@blossom.cjclark.org> References: <19025.217.154.240.18.1052823481.squirrel@radix.sorted.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <19025.217.154.240.18.1052823481.squirrel@radix.sorted.org> User-Agent: Mutt/1.4.1i X-URL: http://people.freebsd.org/~cjc/ cc: freebsd-ipfw@freebsd.org Subject: Re: Q: ipfw & divert sockets (2nd try) X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list Reply-To: "Crist J. Clark" List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 May 2003 19:46:54 -0000 On Tue, May 13, 2003 at 11:58:01AM +0100, andy@sorted.org wrote: > Apologies if this is not the place for this question - I worked through > the list of mailing lists and this seemed the appropriate spot (and > apologies if you already have this mail from another address - reverse-DNS > problems). > > I've been working to use FreeBSD4.8-STABLE/IPFW2 and a small user-land App > linked to it via a divert socket, to encapsulate all outgoing data on a > given interface into a UDP packet stream (and visa versa) - effectively an > IP-over-UDP tunnel. > > The send-side of this seems to work fine - I can send a datagram, > encapsulate it, and watch it travel over the network. Furthermore, the > receive side seems to correctly deencapsulate the packet without raising > an error. However, the deencapsulated packet, which is identical to its > 'pre-encapsulated' form does not seem to make it out of the diverted > socket, and appears to be dropped. > > Is what I'm doing possible within the IPFW2 framework, or am I trying to > do something foolish? > Are inbound packets handled differently to outbound ones? I wrote some code to do this too. Are you checking the return value of the sendto(2) that writes the packet back to the divert(4) socket? It is returning the correct size? We'll probably need to at least see the firewall rules and likely some of the source code too to be able to help. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org From owner-freebsd-ipfw@FreeBSD.ORG Sat May 17 12:41:12 2003 Return-Path: Delivered-To: freebsd-ipfw@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 9279837B401 for ; Sat, 17 May 2003 12:41:12 -0700 (PDT) Received: from xorpc.icir.org (xorpc.icir.org [192.150.187.68]) by mx1.FreeBSD.org (Postfix) with ESMTP id 513A943FA3 for ; Sat, 17 May 2003 12:41:10 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: from xorpc.icir.org (localhost [127.0.0.1]) by xorpc.icir.org (8.12.8p1/8.12.3) with ESMTP id h4HJf9Qg041407; Sat, 17 May 2003 12:41:09 -0700 (PDT) (envelope-from rizzo@xorpc.icir.org) Received: (from rizzo@localhost) by xorpc.icir.org (8.12.8p1/8.12.3/Submit) id h4HJf8nh041406; Sat, 17 May 2003 12:41:08 -0700 (PDT) (envelope-from rizzo) Date: Sat, 17 May 2003 12:41:08 -0700 From: Luigi Rizzo To: Peter Pentchev Message-ID: <20030517124107.A36097@xorpc.icir.org> References: <20030516135052.GA13482@straylight.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable User-Agent: Mutt/1.2.5.1i In-Reply-To: <20030516135052.GA13482@straylight.oblivion.bg>; from roam@ringlet.net on Fri, May 16, 2003 at 04:50:53PM +0300 cc: ipfw@freebsd.org Subject: Re: ipfw2 buffer overruns X-BeenThere: freebsd-ipfw@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: IPFW Technical Discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 17 May 2003 19:41:12 -0000 Peter, i agree that it is useful to have the ipfw2 compiler check for overflows, but i believe the checks can be greatly simplified by putting them in two places only: right after the 'target:' label in OR_START(), and at the beginning of the while() loop after 'read_options:'. These are the only places where you can have a loop, in all other places you only insert single rules of bounded size so as long as you check that there is a 'large enough' buffer (in the order of 60 bytes or so) at the beginning and before each iteration of the loop, you should be safe. cheers luigi On Fri, May 16, 2003 at 04:50:53PM +0300, Peter Pentchev wrote: > Hi, >=20 > A friend of mine, Kiril Todorov (CC'd), recently came across some quite > strange ipfw2 behavior on -STABLE: when given a specific rule to add, > ipfw would hang. A bit of digging into src/sbin/ipfw/ipfw2.c revealed a > couple of internal buffers - actbuf[], cmdbuf[], rulebuf[] - with a set > length of 255, and a couple of pointers traversing those buffers which > were never actually checked for running over the end. Thus, it was > trivial to construct a long enough 'ipfw add' command that would > eventually overrun the buffer, with much confusion ensuing. >=20 > Attached is a sample rule that causes this, and a patch which performs a > couple of length checks and refuses to add the rule if a buffer overrun > is detected. This is not the most elegant solution, and in a couple of > the checks the damage is already done, but still... >=20 > The patch is against -STABLE; it applies to -CURRENT with just a couple > of offset lines, and the resulting source compiles; I do not currently > have a functional -CURRENT machine to test it on, though. It works on > -STABLE, correctly diagnosing the oversized rule, and some other tests I > threw at it in a hurry. Still, this is the first time I'm touching the > ipfw code, so there is a very high probability that this is not the > right way, or not even close to the right direction; feel free to point > it out :) >=20 > G'luck, > Peter >=20 > --=20 > Peter Pentchev roam@ringlet.net roam@sbnd.net roam@FreeBSD.org > PGP key: http://people.FreeBSD.org/~roam/roam.key.asc > Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 > You have, of course, just begun reading the sentence that you have just f= inished reading. > add 10 skipto 1000 all from { 139.92.144.0/24 or 139.92.170.0/24 or 139.9= 2.51.0/24 or 152.158.113.0/24 or 157.125.223.0/24 or 192.92.129.0/24 or 193= .108.24.0/24 or 193.108.32.0/23 or 193.109.54.0/23 or 193.110.159.0/24 or 1= 93.110.216.0/21 or 193.110.82.0/24 or 193.111.194.0/23 or 193.111.89.0/24 o= r 193.178.152.0/23 or 193.178.166.0/24 or 193.178.222.0/24 or 193.193.162.0= /22 or 193.193.164.0/24 or 193.193.182.0/24 or 193.194.140.0/23 or 193.194.= 141.0/24 or 193.194.156.0/24 or 193.200.0.0/16 or 193.201.114.0/24 or 193.2= 01.172.0/24 or 193.201.240.0/22 or 193.254.29.0/24 or 193.41.182.0/23 or 19= 3.41.188.0/22 or 193.41.206.0/24 or 193.41.64.0/22 or 193.68.0.0/19 or 193.= 68.128.0/17 or 193.68.96.0/19 or 194.12.224.0/19 or 194.141.0.0/16 or 194.1= 45.63.0/24 or 194.153.145.0/24 or 195.138.128.0/19 or 195.212.63.0/24 or 19= 5.230.0.0/19 or 195.234.236.0/22 or 195.24.32.0/19 or 195.34.96.0/19 or 195= .72.112.0/24 or 195.75.71.0/24 or 195.96.224.0/19 or 209.239.78.0/23 or 212= .116.128.0/19 or 212.122.160.0/19 or 212.124.64.0/19 or 212.21.128.0/19 or = 212.36.0.0/19 or 212.39.64.0/19 or 212.50.0.0/19 or 212.5.128.0/19 or 212.5= 6.0/19 or 212.7.192.0/19 or 212.72.192.0/19 or 212.91.160.0/19 or 212.95.16= 0.0/19 or 213.130.64.0/19 or 213.137.32.0/19 or 213.145.96.0/19 or 213.16.3= 2.0/19 or 213.169.32.0/19 or 213.174.0.0/19 or 213.191.192.0/19 or 213.208.= 10.0/23 or 213.222.32.0/19 or 213.226.0.0/18 or 213.91.128.0/17 or 217.10.2= 40.0/20 or 217.18.240.0/20 or 217.145.160.0/20 or 217.197.128.0/20 or 217.7= 9.32.0/19 or 217.79.64.0/20 or 217.9.224.0/20 or 217.75.128.0/20 or 10.0.0.= 0/8 or 172.16.0.0/12 } to any > Index: src/sbin/ipfw/ipfw2.c > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > RCS file: /home/ncvs/src/sbin/ipfw/ipfw2.c,v > retrieving revision 1.4.2.12 > diff -u -r1.4.2.12 ipfw2.c > --- src/sbin/ipfw/ipfw2.c 14 Apr 2003 12:41:37 -0000 1.4.2.12 > +++ src/sbin/ipfw/ipfw2.c 16 May 2003 13:40:25 -0000 > @@ -2481,6 +2481,14 @@ > return NULL; > } > =20 > +static void > +check_length(ipfw_insn *cmd, size_t add, void *ptr, size_t size) > +{ > + > + if ((uintptr_t)(cmd + add) > (uintptr_t)((char *)ptr + size)) > + errx(EX_DATAERR, "Rule too long!"); > +} > + > /* > * Parse arguments and assemble the microinstructions which make up a ru= le. > * Rules are added into the 'rulebuf' and then copied in the correct ord= er > @@ -2562,6 +2570,7 @@ > NEED1("missing action"); > i =3D match_token(rule_actions, *av); > ac--; av++; > + check_length(action, 1, actbuf, sizeof(actbuf)); /* superfluous.. */ > action->len =3D 1; /* default */ > switch(i) { > case TOK_CHECKSTATE: > @@ -2602,6 +2611,7 @@ > case TOK_QUEUE: > case TOK_PIPE: > action->len =3D F_INSN_SIZE(ipfw_insn_pipe); > + check_length(action, action->len, actbuf, sizeof(actbuf)); > case TOK_SKIPTO: > if (i =3D=3D TOK_QUEUE) > action->opcode =3D O_QUEUE; > @@ -2639,6 +2649,7 @@ > =20 > action->opcode =3D O_FORWARD_IP; > action->len =3D F_INSN_SIZE(ipfw_insn_sa); > + check_length(action, action->len, actbuf, sizeof(actbuf)); > =20 > p->sa.sin_len =3D sizeof(struct sockaddr_in); > p->sa.sin_family =3D AF_INET; > @@ -2665,6 +2676,7 @@ > default: > errx(EX_DATAERR, "invalid action %s\n", av[-1]); > } > + check_length(action, F_LEN(action), actbuf, sizeof(actbuf)); > action =3D next_cmd(action); > =20 > /* > @@ -2687,6 +2699,7 @@ > errx(EX_DATAERR, "logamount must be positive"); > ac--; av++; > } > + check_length(cmd, F_LEN(cmd), cmdbuf, sizeof(cmdbuf)); > cmd =3D next_cmd(cmd); > } > =20 > @@ -2751,12 +2764,16 @@ > !strncmp(*av, "mac", strlen(*av))) { > ac--; av++; /* the "MAC" keyword */ > add_mac(cmd, ac, av); /* exits in case of errors */ > + check_length(cmd, F_LEN(cmd), cmdbuf, sizeof(cmdbuf)); > cmd =3D next_cmd(cmd); > ac -=3D 2; av +=3D 2; /* dst-mac and src-mac */ > NOT_BLOCK; > NEED1("missing mac type"); > if (add_mactype(cmd, ac, av[0])) > + { > + check_length(cmd, F_LEN(cmd), cmdbuf, sizeof(cmdbuf)); > cmd =3D next_cmd(cmd); > + } > ac--; av++; /* any or mac-type */ > goto read_options; > } > @@ -2775,6 +2792,7 @@ > else { > proto =3D cmd->arg1; > prev =3D cmd; > + check_length(cmd, F_LEN(cmd), cmdbuf, sizeof(cmdbuf)); > cmd =3D next_cmd(cmd); > } > } else if (first_cmd !=3D cmd) { > @@ -2800,6 +2818,7 @@ > ac--; av++; > if (F_LEN(cmd) !=3D 0) { /* ! any */ > prev =3D cmd; > + check_length(cmd, F_LEN(cmd), cmdbuf, sizeof(cmdbuf)); > cmd =3D next_cmd(cmd); > } > } > @@ -2814,7 +2833,10 @@ > add_ports(cmd, *av, proto, O_IP_SRCPORT)) { > ac--; av++; > if (F_LEN(cmd) !=3D 0) > + { > + check_length(cmd, F_LEN(cmd), cmdbuf, sizeof(cmdbuf)); > cmd =3D next_cmd(cmd); > + } > } > } > =20 > @@ -2835,6 +2857,7 @@ > ac--; av++; > if (F_LEN(cmd) !=3D 0) { /* ! any */ > prev =3D cmd; > + check_length(cmd, F_LEN(cmd), cmdbuf, sizeof(cmdbuf)); > cmd =3D next_cmd(cmd); > } > } > @@ -2849,7 +2872,10 @@ > add_ports(cmd, *av, proto, O_IP_DSTPORT)) { > ac--; av++; > if (F_LEN(cmd) !=3D 0) > + { > + check_length(cmd, F_LEN(cmd), cmdbuf, sizeof(cmdbuf)); > cmd =3D next_cmd(cmd); > + } > } > } > =20 > @@ -3167,6 +3193,7 @@ > } > if (F_LEN(cmd) > 0) { /* prepare to advance */ > prev =3D cmd; > + check_length(cmd, F_LEN(cmd), cmdbuf, sizeof(cmdbuf)); > cmd =3D next_cmd(cmd); > } > } > @@ -3187,6 +3214,7 @@ > if (match_prob !=3D 1) { /* 1 means always match */ > dst->opcode =3D O_PROB; > dst->len =3D 2; > + check_length(dst, 2, rulebuf, sizeof(rulebuf)); > *((int32_t *)(dst+1)) =3D (int32_t)(match_prob * 0x7fffffff); > dst +=3D dst->len; > } > @@ -3196,6 +3224,7 @@ > */ > if (have_state && have_state->opcode !=3D O_CHECK_STATE) { > fill_cmd(dst, O_PROBE_STATE, 0, 0); > + check_length(dst, F_LEN(dst), rulebuf, sizeof(rulebuf)); > dst =3D next_cmd(dst); > } > /* > @@ -3210,6 +3239,7 @@ > case O_LIMIT: > break; > default: > + check_length(dst, i, rulebuf, sizeof(rulebuf)); > bcopy(src, dst, i * sizeof(u_int32_t)); > dst +=3D i; > } > @@ -3220,6 +3250,7 @@ > */ > if (have_state && have_state->opcode !=3D O_CHECK_STATE) { > i =3D F_LEN(have_state); > + check_length(dst, i, rulebuf, sizeof(rulebuf)); > bcopy(have_state, dst, i * sizeof(u_int32_t)); > dst +=3D i; > } > @@ -3234,6 +3265,7 @@ > src =3D (ipfw_insn *)cmdbuf; > if ( src->opcode =3D=3D O_LOG ) { > i =3D F_LEN(src); > + check_length(dst, i, rulebuf, sizeof(rulebuf)); > bcopy(src, dst, i * sizeof(u_int32_t)); > dst +=3D i; > } > @@ -3242,6 +3274,7 @@ > */ > for (src =3D (ipfw_insn *)actbuf; src !=3D action; src +=3D i) { > i =3D F_LEN(src); > + check_length(dst, i, rulebuf, sizeof(rulebuf)); > bcopy(src, dst, i * sizeof(u_int32_t)); > dst +=3D i; > }