From owner-freebsd-security Mon Jul 19 6: 8:52 1999 Delivered-To: freebsd-security@freebsd.org Received: from fed-ef1.frb.gov (fed.frb.gov [132.200.32.32]) by hub.freebsd.org (Postfix) with ESMTP id 4081E15171 for ; Mon, 19 Jul 1999 06:08:43 -0700 (PDT) (envelope-from seth@freebie.dp.ny.frb.org) Received: by fed-ef1.frb.gov; id JAA23451; Mon, 19 Jul 1999 09:07:39 -0400 (EDT) Received: from m1pmdf.frb.gov(192.168.3.38) by fed.frb.gov via smap (V4.2) id xma023383; Mon, 19 Jul 99 09:07:35 -0400 Date: Mon, 19 Jul 1999 09:07:27 -0400 (EDT) From: Seth Subject: Re: Shared memory DoS's (fwd) To: security@freebsd.org Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Anyone following this bugtraq thread? SB ---------- Forwarded message ---------- Date: Sat, 17 Jul 1999 14:47:23 -0500 From: Mike Perry To: BUGTRAQ@SECURITYFOCUS.COM Subject: Re: Shared memory DoS's If you had read the report closely you would see that FreeBSD has no limits to set. The shells can set limits, but none of them effect mmap or shmget. Try actually running the exploit (with the __FUXX0R_SYSV__ option for best results.. See previous mails), you'll be pleasantly surprised :) If you still don't believe me, check sys/vm/vm_mmap.c and see for yourself. The only two limits checked are RLIMIT_MEMLOCK (a limit on the amout of memory a user can mark as non-swappable), and RLIMIT_STACK, a limit on how much stack space mmap can use if it is configured to mmap memory into the stack region for some reason (doesn't sound like the default, and when you want to map into stack, you have to specifically request it on BSD). The same goes for the Linux shells. They have limits, but none of them set RLIMIT_AS. You have to use pam, or Sys V init, or my patch. Lshell does not set the RLIMIT_AS limit either, you have to apply my patch to it (my path to login.c was actually based on lshell, and says so if you read it). After more research, it seems that System V implements RLIMIT_VMEM to stop people from exploiting this problem, but apparently when BSD implemented the Sys V IPC, they neglected to add an appropriate RLIMIT. P.S. For people who have reported to me that using small segments to map causes the program to segfault, this is because the default attack is mmap (see previous mails), and you can do an infinite number of private mmapings. I use an array of pointers to keep track of the memory to free it when the __REALLY_FUXX0R__ option isn't set. So I overrun my own buffer. The buffer size is 2 times the limit for SysV IPC shares for processes, so the buffer will not be overrun with that attack. (I was not about to realloc the buffer dynamically for mmap.. just use a larger buffer size to eat up more than your total ram using only SHMSEG*2 segments). Thus spake Nicolas V. Chernyy (nico@ROUTED.NET): > On most bsd systems including my FreeBSD machine you can set such limits with ulimits > a-la /etc/login.conf and login classess. I think that people who pretend to run large > systems on small hardware like myself should invest time in setting up login classess. > My current configuration has proven to be effective against fork bombs and memory > related DoSes such as this one. > > -Nick Chernyy, BOFH-wannabee > > Mike Perry wrote: > > > Hello, sorry if it's considered poor form to cross post to both bugtraq and a > > development list, but I'm too lazy to fire off two emails. > > > > While fiddling with various IPC mechanisms and reading The Design and > > Implementation of 4.4BSD (What a book!), a few things struch me as potentially > > dangerous. According to the book, when you request a shared memory segment via > > mmap(), the file isn't actually physically in memory until you start to > > trigger page faults and cause the vnode-pager to page in the data from the > > file. > > > > Then, the following passage from shmctl(2) under Linux caught my eye: > > "The user must ensure that a segment is eventually destroyed; otherwise its pages > > that were faulted in will remain in memory or swap." > > > > So as it turns out that it is in fact possible to create a DoS condition by > > requesting a truckload of shared mem, then triggering pagefaults in the entire > > shared region. > > > > Now the end result is no different than a simple fork or malloc bomb, but it is > > considerably harder to prevent on most systems. > > > > This is mainly because: > > > > 1. The system does not check rlimits for mmap and shmget (FreeBSD) > > 2. The system never bothers to offer the ability to set the rlimits for > > virtual memory via shells, login process, or otherwise. (Linux) > > 3. b. The system does not actually allocate shared memory until a page > > fault is triggered (this could be argued to be a feature - Linux, *BSD) > > a. The system does not watch to make sure you don't share more memory > > than exists. (Linux, Irix, BSD?) > > 4. With System V IPC, shared memory persists even after the process is > > gone. So even though the kernel may kill the process after it exhausts > > all memory from page faults, there still is 0 memory left for the system. > > I suppose with some trickery you might be able to achieve the same results > > by shared mmap()'ing a few large files between pairs of processes. (All) > > > > I've attached a program that will exploit these conditions using either > > shmget(), mmap(), or by getting malloc to mmap() (those are in order of > > effectivness). > > > > This program should compile on any architecture. SGI Irix is not vulnerable. > > Reading The Design and Implementation of 4.4BSD, it sounds as if the BSDs > > should all be vulnerable. FreeBSD will mmap as much memory as you tell it. > > I haven't tried page faulting the memory, as the system is not mine. > > I'd be very interested to hear about OpenBSD... > > > > Also attached is a patch to util-linux-2.9o login.c (and pathnames.h) that > > provides a means under Linux (should be pretty portable to other OS's) to set > > limits for the address space limit (RLIMIT_AS: the rlimit that controls how > > much data you can actually map into your process). The patch is based on an old > > program called lshell that set limits by wrapping your shell (I've found that > > wrapping the shell in this way caused all sorts of problems with gdb, for some > > reason). > > > > sample /etc/limits file: > > > > # Limit the user guest to 5 minutes CPU time and 8 procs, 5Mb address space > > guest C5P8V5D2 > > # 60 min's CPU time, 30 procs, 15Mb data, 50 megs total address space, 5 megs > > # stack, 15 megs of RSS. > > default C60P30D15V50S5R15 > > > > At the very least, I recommend default V. > > You can use lowercase letters for the next lowest order of magnitude of units. > > The comment in the patch explains it in further detail. > > > > Note even in this case, a determined user can probably just login a dozen or > > so times and use SysV IPC to steal the system memory. Core wars, anyone? :) > > > > P.S. Util-linux people: I also suspect a small memory leak due to the > > strdup(hostname) provided by Ambrose C. Li. > > > > -- > > Mike Perry > > Proud user of both PGP 2.6.3i and GNU Privacy guard. > > Considering overthrowing any governments? Count me in! > > http://mikepery.linuxos.org/keys.html > > > > ------------------------------------------------------------------------ > > > > vmfuxx0r.cName: vmfuxx0r.c > > Type: Plain Text (text/plain) > > > > login.patchName: login.patch > > Type: Plain Text (text/plain) -- Mike Perry Proud user of both PGP 2.6.3i and GNU Privacy guard. Considering overthrowing any governments? Count me in! http://mikepery.linuxos.org/keys.html To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Mon Jul 19 6:21:14 1999 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 A22A215202 for ; Mon, 19 Jul 1999 06:21:09 -0700 (PDT) (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.8.8/8.8.8) with SMTP id JAA09584; Mon, 19 Jul 1999 09:20:44 -0400 (EDT) (envelope-from robert@cyrus.watson.org) Date: Mon, 19 Jul 1999 09:20:44 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org Reply-To: Robert Watson To: Seth Cc: security@freebsd.org Subject: Re: Shared memory DoS's (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 On Mon, 19 Jul 1999, Seth wrote: > Anyone following this bugtraq thread? Following it, but don't have much to say. :-) Matt Dillon has confirmed that the memory system doesn't impose resource limits on mmaping and other shared memory IPC (this was actually raised on -hackers a few months ago, I think), and that it probably should. I haven't tried the posted sample code, but generally speaking if memory resources become low, the guilty process is terminated when the vm system discoveres it doesn't have the pages to back the request, so I suspect the same thing happens, although the system could get quite sluggish in the process. I'd like to see a first-hand report from someone who has a spare crash machine to give it a try, however. :-) Since this is a DOS and not a root exploit, my feeling is that it should be fixed, but it isn't particularly urgent, although it should be addressed. Matt's overall VM quota per-uid seems to make sense to me, but sounds like something he should be implementing, not me, given my somewhat pathetic knowledge of the VM system :-). > Date: Sat, 17 Jul 1999 14:47:23 -0500 > From: Mike Perry > To: BUGTRAQ@SECURITYFOCUS.COM > Subject: Re: Shared memory DoS's > > If you had read the report closely you would see that FreeBSD has no limits to > set. The shells can set limits, but none of them effect mmap or shmget. Try > actually running the exploit (with the __FUXX0R_SYSV__ option for best > results.. See previous mails), you'll be pleasantly surprised :) > > If you still don't believe me, check sys/vm/vm_mmap.c and see for yourself. > The only two limits checked are RLIMIT_MEMLOCK (a limit on the amout of memory > a user can mark as non-swappable), and RLIMIT_STACK, a limit on how much stack > space mmap can use if it is configured to mmap memory into the stack region > for some reason (doesn't sound like the default, and when you want to map into > stack, you have to specifically request it on BSD). > > The same goes for the Linux shells. They have limits, but none of them set > RLIMIT_AS. You have to use pam, or Sys V init, or my patch. Lshell does not > set the RLIMIT_AS limit either, you have to apply my patch to it (my path to > login.c was actually based on lshell, and says so if you read it). > > After more research, it seems that System V implements RLIMIT_VMEM to > stop people from exploiting this problem, but apparently when BSD implemented > the Sys V IPC, they neglected to add an appropriate RLIMIT. > > P.S. For people who have reported to me that using small segments to map > causes the program to segfault, this is because the default attack is mmap > (see previous mails), and you can do an infinite number of private mmapings. > > I use an array of pointers to keep track of the memory to free it when the > __REALLY_FUXX0R__ option isn't set. So I overrun my own buffer. The buffer > size is 2 times the limit for SysV IPC shares for processes, so the buffer > will not be overrun with that attack. (I was not about to realloc the buffer > dynamically for mmap.. just use a larger buffer size to eat up more than your > total ram using only SHMSEG*2 segments). > > > > Thus spake Nicolas V. Chernyy (nico@ROUTED.NET): > > > On most bsd systems including my FreeBSD machine you can set such limits with ulimits > > a-la /etc/login.conf and login classess. I think that people who pretend to run large > > systems on small hardware like myself should invest time in setting up login classess. > > My current configuration has proven to be effective against fork bombs and memory > > related DoSes such as this one. > > > > -Nick Chernyy, BOFH-wannabee > > > > Mike Perry wrote: > > > > > Hello, sorry if it's considered poor form to cross post to both bugtraq and a > > > development list, but I'm too lazy to fire off two emails. > > > > > > While fiddling with various IPC mechanisms and reading The Design and > > > Implementation of 4.4BSD (What a book!), a few things struch me as potentially > > > dangerous. According to the book, when you request a shared memory segment via > > > mmap(), the file isn't actually physically in memory until you start to > > > trigger page faults and cause the vnode-pager to page in the data from the > > > file. > > > > > > Then, the following passage from shmctl(2) under Linux caught my eye: > > > "The user must ensure that a segment is eventually destroyed; otherwise its pages > > > that were faulted in will remain in memory or swap." > > > > > > So as it turns out that it is in fact possible to create a DoS condition by > > > requesting a truckload of shared mem, then triggering pagefaults in the entire > > > shared region. > > > > > > Now the end result is no different than a simple fork or malloc bomb, but it is > > > considerably harder to prevent on most systems. > > > > > > This is mainly because: > > > > > > 1. The system does not check rlimits for mmap and shmget (FreeBSD) > > > 2. The system never bothers to offer the ability to set the rlimits for > > > virtual memory via shells, login process, or otherwise. (Linux) > > > 3. b. The system does not actually allocate shared memory until a page > > > fault is triggered (this could be argued to be a feature - Linux, *BSD) > > > a. The system does not watch to make sure you don't share more memory > > > than exists. (Linux, Irix, BSD?) > > > 4. With System V IPC, shared memory persists even after the process is > > > gone. So even though the kernel may kill the process after it exhausts > > > all memory from page faults, there still is 0 memory left for the system. > > > I suppose with some trickery you might be able to achieve the same results > > > by shared mmap()'ing a few large files between pairs of processes. (All) > > > > > > I've attached a program that will exploit these conditions using either > > > shmget(), mmap(), or by getting malloc to mmap() (those are in order of > > > effectivness). > > > > > > This program should compile on any architecture. SGI Irix is not vulnerable. > > > Reading The Design and Implementation of 4.4BSD, it sounds as if the BSDs > > > should all be vulnerable. FreeBSD will mmap as much memory as you tell it. > > > I haven't tried page faulting the memory, as the system is not mine. > > > I'd be very interested to hear about OpenBSD... > > > > > > Also attached is a patch to util-linux-2.9o login.c (and pathnames.h) that > > > provides a means under Linux (should be pretty portable to other OS's) to set > > > limits for the address space limit (RLIMIT_AS: the rlimit that controls how > > > much data you can actually map into your process). The patch is based on an old > > > program called lshell that set limits by wrapping your shell (I've found that > > > wrapping the shell in this way caused all sorts of problems with gdb, for some > > > reason). > > > > > > sample /etc/limits file: > > > > > > # Limit the user guest to 5 minutes CPU time and 8 procs, 5Mb address space > > > guest C5P8V5D2 > > > # 60 min's CPU time, 30 procs, 15Mb data, 50 megs total address space, 5 megs > > > # stack, 15 megs of RSS. > > > default C60P30D15V50S5R15 > > > > > > At the very least, I recommend default V. > > > You can use lowercase letters for the next lowest order of magnitude of units. > > > The comment in the patch explains it in further detail. > > > > > > Note even in this case, a determined user can probably just login a dozen or > > > so times and use SysV IPC to steal the system memory. Core wars, anyone? :) > > > > > > P.S. Util-linux people: I also suspect a small memory leak due to the > > > strdup(hostname) provided by Ambrose C. Li. > > > > > > -- > > > Mike Perry > > > Proud user of both PGP 2.6.3i and GNU Privacy guard. > > > Considering overthrowing any governments? Count me in! > > > http://mikepery.linuxos.org/keys.html > > > > > > ------------------------------------------------------------------------ > > > > > > vmfuxx0r.cName: vmfuxx0r.c > > > Type: Plain Text (text/plain) > > > > > > login.patchName: login.patch > > > Type: Plain Text (text/plain) > > -- > Mike Perry > Proud user of both PGP 2.6.3i and GNU Privacy guard. > Considering overthrowing any governments? Count me in! > http://mikepery.linuxos.org/keys.html > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-security" in the body of the message > 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, Computing Laboratory at Cambridge University 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 Mon Jul 19 11: 8:55 1999 Delivered-To: freebsd-security@freebsd.org Received: from lily.ezo.net (lily.ezo.net [206.102.130.13]) by hub.freebsd.org (Postfix) with ESMTP id D5008157B0 for ; Mon, 19 Jul 1999 11:08:29 -0700 (PDT) (envelope-from jflowers@ezo.net) Received: from ivy.ezo.net (ivy.ezo.net [206.150.211.171]) by lily.ezo.net (8.8.7/8.8.7) with SMTP id OAA02637 for ; Mon, 19 Jul 1999 14:07:21 -0400 (EDT) Message-ID: <004501bed211$d72ed440$abd396ce@ezo.net> From: "Jim Flowers" To: Subject: SKIP Mailing List Date: Mon, 19 Jul 1999 14:09:22 -0400 X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-Priority: 3 X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org For anyone interested the SKIP mailing list has resurfaced: skip-info@skip-vpn.org. You can get instructions for joining the mailing list at www.skip.org or just add subscribe to the subject of skip-info-request@skip-vpn.org or skip-info-d-request@skip-vpn.org if you prefer a daily digest. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Tue Jul 20 13:35:57 1999 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 4D1FF153A2 for ; Tue, 20 Jul 1999 13:35:48 -0700 (PDT) (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.02 #1) id 116gaM-0003Tt-00; Tue, 20 Jul 1999 22:33:58 +0200 From: Sheldon Hearn To: blokey@indigo.ie (Smelly Pooh) Cc: Paulo Fragoso , Matthew Dillon , freebsd-security@FreeBSD.ORG Subject: Re: FreeBSD exploit? In-reply-to: Your message of "Tue, 20 Jul 1999 21:32:15 +0100." <19990720213215.A10104@poo.smooch> Date: Tue, 20 Jul 1999 22:33:58 +0200 Message-ID: <13384.932502838@axl.noc.iafrica.com> Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Tue, 20 Jul 1999 21:32:15 +0100, Smelly Pooh wrote: > Remote or not has there been a patch released for it yet? For FreeBSD, no. Ciao, Sheldon. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 22 4: 8:39 1999 Delivered-To: freebsd-security@freebsd.org Received: from lily.ezo.net (lily.ezo.net [206.102.130.13]) by hub.freebsd.org (Postfix) with ESMTP id 3CD6414D72 for ; Thu, 22 Jul 1999 04:08:35 -0700 (PDT) (envelope-from jflowers@ezo.net) Received: from orchid (c3-1e218.neo.rr.com [24.93.234.218]) by lily.ezo.net (8.8.7/8.8.7) with SMTP id HAA15874; Thu, 22 Jul 1999 07:06:47 -0400 (EDT) Message-ID: <000c01bed432$5f289120$feb197ce@ezo.net> From: "Jim Flowers" To: Cc: , Subject: wi driver with SKIP Date: Thu, 22 Jul 1999 07:07:21 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0009_01BED410.D76F1860" 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_0009_01BED410.D76F1860 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm really enjoying your wi driver with the Lucent IEEE ISA wireless = card running under FreeBSD-STABLE. While I have been able to use it = with most configurations, it will not work with SKIP bound to the same = interface. It works fine in the inbound direction where SKIP receives packets from = wi0 and the SKIP module is able to decrypt successfully. In the = outbound direction, where SKIP hands off packets to wi0, the packets are = malformed and the companion skiphost (Windows 98 with domestic SKIP) = complains of a corrupted V2 header upon giving up. SKIP packets will pass through an interface with the wi0 driver = successfully in both directions as long as they are created on a = different interface. Just thought it might be something simple. Regards, Jim =20 ------=_NextPart_000_0009_01BED410.D76F1860 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I'm really enjoying your wi driver with = the Lucent=20 IEEE ISA wireless card running under FreeBSD-STABLE.  While I have = been=20 able to use it with most configurations, it will not work with SKIP = bound to the=20 same interface.
 
It works fine in the inbound = direction where=20 SKIP receives packets from wi0 and the SKIP module is able to = decrypt=20 successfully.  In the outbound direction, where SKIP hands off = packets to=20 wi0, the packets are malformed and the companion skiphost (Windows 98 = with=20 domestic SKIP) complains of a corrupted V2 header upon giving = up.
 
SKIP packets will pass through an = interface with=20 the wi0 driver successfully in both directions as long as they are = created on a=20 different interface.
 
Just thought it might be something=20 simple.
 
Regards,
 
Jim
 
------=_NextPart_000_0009_01BED410.D76F1860-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 22 5:40: 4 1999 Delivered-To: freebsd-security@freebsd.org Received: from lily.ezo.net (lily.ezo.net [206.102.130.13]) by hub.freebsd.org (Postfix) with ESMTP id 3A87414D8F for ; Thu, 22 Jul 1999 05:39:55 -0700 (PDT) (envelope-from jflowers@ezo.net) Received: from lily.ezo.net (jflowers@localhost.ezo.net [127.0.0.1]) by lily.ezo.net (8.8.7/8.8.7) with SMTP id IAA18406; Thu, 22 Jul 1999 08:39:06 -0400 (EDT) Date: Thu, 22 Jul 1999 08:39:05 -0400 (EDT) From: Jim Flowers To: skip-info@skip-vpn.org, freebsd-security@freebsd.org Subject: SKIP and NAT nomadic server - howto (long) Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Skip and NAT are two very popular strategies for building secure networks with FreeBSD. They are sometimes believed to be incompatable when applied to the same interface. They will work together, however, when correctly configured. This document addresses the reference implementation of SKIP (1.0) and natd as implemented through ipfw. The key to understanding the operation of SKIP and NAT in parallel is to realize that inbound packets traverse the ipfw ruleset twice - once as an encapsulated packet and once as an de-encapsulated packet with the original destination address restored. Outbound packets, on the other hand, make a single pass in the unencapsulated state. This understanding can be used to advantage in building a nomadic SKIP server. A nomadic SKIP server allows any host equipped with a SKIP client to connect to the Internet (eg. via a dialup connection to an ISP) and then establish a secure connection to the nomadic SKIP server allowing full access to a Local Area Network. Because the remote host may have a different IP address each time it connects it is known as a nomad and its KeyID is used for identification rather than the IP address identification normally used to establish authenticity. The primary difficulty in setting up a nomadic server in conjunction with NAT is not in reaching in to the LAN but in returning a response to the remote host. The remote host IP address cannot, by definition, be known in advance. Further - authentication of the remote host and identification of its IP address by the SKIP module does not proceed to update the routing tables in the kernel. A LAN host receiving a connection request has insufficient information to reply to the remote host either via a static route or by dynamic routing. This leads to the requirement that the nomadic server must be in-line between the Internet and the LAN so that all packets not destined for the LAN are routed to the nomadic server by the gateway address in the LAN host. The second requirement is to prevent NAT from interfering. NAT does not bother the SKIP pass as the packet header is directed to the nat/skiphost. You can count the inbound SKIP packets as they can be identified by the SKIP protocol (57). Use an ipfw rule before the NAT rule such as: 00010 allow skip from any to any in recv fxp0 00100 divert 8668 ip from any to any via fxp0 assuming that skip is identified as 57 in /etc/protocols. A rule is required for the de-encrypted packets to allow them to be forwarded to the LAN by the routing mechanism without interference from NAT during the second pass: 00010 allow skip from any to any in recv fxp0 00020 allow ip from any to 192.168.0.0/24 in recv fxp0 00100 divert 8668 ip from any to any via fxp0 Now you can have nomadic hosts connect securely as part of the LAN and hosts on the LAN can continue to access the Internet through NAT. Of course, you have to configure the skiphost ACL correctly and setup the SKIP client on the nomad to match but that's covered in the documentation. Jim Flowers #4 ISP on C|NET, #1 in Ohio To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 22 7:12:32 1999 Delivered-To: freebsd-security@freebsd.org Received: from sirius.ctr.columbia.edu (sirius.ctr.columbia.edu [128.59.64.60]) by hub.freebsd.org (Postfix) with ESMTP id CF14514D62 for ; Thu, 22 Jul 1999 07:12:27 -0700 (PDT) (envelope-from wpaul@ctr.columbia.edu) Received: from startide.ctr.columbia.edu (wpaul@startide.ctr.columbia.edu [128.59.64.52]) by sirius.ctr.columbia.edu (8.9.1/8.6.4.287) with ESMTP id KAA11275; Thu, 22 Jul 1999 10:12:20 -0400 (EDT) From: wpaul@ctr.columbia.edu (Bill Paul) Received: (wpaul@localhost) by startide.ctr.columbia.edu (8.9.1/8.6.4.788743) id KAA26519; Thu, 22 Jul 1999 10:12:21 -0400 (EDT) Message-Id: <199907221412.KAA26519@startide.ctr.columbia.edu> Subject: Re: wi driver with SKIP To: jflowers@ezo.net (Jim Flowers) Date: Thu, 22 Jul 1999 10:12:21 -0400 (EDT) Cc: , In-Reply-To: <000c01bed432$5f289120$feb197ce@ezo.net> from "Jim Flowers" at Jul 22, 99 07:07:21 am X-Mailer: ELM [version 2.4 PL25] 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 Of all the gin joints in all the towns in all the world, Jim Flowers had to walk into mine and say: > I'm really enjoying your wi driver with the Lucent IEEE ISA wireless = > card running under FreeBSD-STABLE. While I have been able to use it = > with most configurations, it will not work with SKIP bound to the same = > interface. > > It works fine in the inbound direction where SKIP receives packets from = > wi0 and the SKIP module is able to decrypt successfully. In the = > outbound direction, where SKIP hands off packets to wi0, the packets are = > malformed and the companion skiphost (Windows 98 with domestic SKIP) = > complains of a corrupted V2 header upon giving up. Hm. My understanding is that in an Ethernet II frame, the type field represents the payload type in the frame, which can be IP, ARP, reverse ARP, to name a few. If SKIP packets have a different kind of header than IP, then the frame type will be different from IP (which is 0x800). The WaveLAN/IEEE has to send Ethernet II within 802.11 frames using RFC 1042 encapsulation, which means that a SNAP header is included before the packet data. This encapsulation is done in software. Currently, the driver checks the frame type in wi_start() and if it is ETHERTYPE_IP, ETHERTYPE_ARP or ETHERTYPE_REVARP, it will use RFC 1042 encapsulation. If it's anything else (i.e. an 802.3 frame), it will transmit the data directly without any encapsulation. In wi_start(), you will see the following code: /* * Use RFC1042 encoding for IP and ARP datagrams, * 802.3 for anything else. */ if (ntohs(eh->ether_type) == ETHERTYPE_IP || ntohs(eh->ether_type) == ETHERTYPE_ARP || ntohs(eh->ether_type) == ETHERTYPE_REVARP) { If there is an ETHERTYPE_SKIP, then you should change this code so that it looks like this: /* * Use RFC1042 encoding for IP and ARP datagrams, * 802.3 for anything else. */ if (ntohs(eh->ether_type) == ETHERTYPE_IP || ntohs(eh->ether_type) == ETHERTYPE_SKIP || ntohs(eh->ether_type) == ETHERTYPE_ARP || ntohs(eh->ether_type) == ETHERTYPE_REVARP) { Alternatively, you might try this: if (ntohs(eh->ether_type) > 1536) { As to why it works when the packets originate on another interface, I'm not sure. I can only assume that in that case, the packets are tunneled through IP, in which case the ethertype is correct and wi_start() passes them correctly. Please try one of the above changes and let me know if it helps. Oh yeah: and turn off 'send HTML and plain text mail' in your browser/mail client/whatever. :) -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Department of Electrical Engineering Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "Mulder, toads just fell from the sky!" "I guess their parachutes didn't open." ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 22 13:23:33 1999 Delivered-To: freebsd-security@freebsd.org Received: from lily.ezo.net (lily.ezo.net [206.102.130.13]) by hub.freebsd.org (Postfix) with ESMTP id BDE2214C08 for ; Thu, 22 Jul 1999 13:23:29 -0700 (PDT) (envelope-from jflowers@ezo.net) Received: from lily.ezo.net (jflowers@localhost.ezo.net [127.0.0.1]) by lily.ezo.net (8.8.7/8.8.7) with SMTP id QAA03851; Thu, 22 Jul 1999 16:22:13 -0400 (EDT) Date: Thu, 22 Jul 1999 16:22:13 -0400 (EDT) From: Jim Flowers To: Bill Paul Cc: skip-info@skip-vpn.org, freebsd-security@freebsd.org Subject: Re: wi driver with SKIP In-Reply-To: <199907221412.KAA26519@startide.ctr.columbia.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 Thanks for the response. Sorry for the hypertext. A new portable not fully configured yet. See comments below. Jim Flowers #4 ISP on C|NET, #1 in Ohio On Thu, 22 Jul 1999, Bill Paul wrote: > > Hm. My understanding is that in an Ethernet II frame, the type field > represents the payload type in the frame, which can be IP, ARP, reverse > ARP, to name a few. If SKIP packets have a different kind of header > than IP, then the frame type will be different from IP (which is 0x800). SKIP encapsulates the original packet and prepends a new IP header and recalculates the header checksum. The 8-bit protocol field is 57. Should look like a normal IP packet to the link layer. Just not TCP or UDP. Note the problem is in the outbound direction so I don't quite see how the Ethernet II type field would be wrong. Isn't this determined by the wi driver and hardware? > > As to why it works when the packets originate on another interface, > I'm not sure. I can only assume that in that case, the packets are > tunneled through IP, in which case the ethertype is correct and > wi_start() passes them correctly. Well, I think I misrepresented this. What works is to install SKIP on a FreeBSD Ethernet interface (lnc1) and then connect this to a WaveLAN/EC converter that then communicates with the Windows 98 skiphost. No wi driver involved but it is what leads me to think that the W98 implementation is OK. Before I try hacking the driver, I think I should try two FreeBSD machines over wi drivers and use a bpf packet sniffer to see whats going to / coming from the link layer. > > Oh yeah: and turn off 'send HTML and plain text mail' in your > browser/mail client/whatever. :) Sorry. I'll let you know. Jim To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 22 13:37:53 1999 Delivered-To: freebsd-security@freebsd.org Received: from sirius.ctr.columbia.edu (sirius.ctr.columbia.edu [128.59.64.60]) by hub.freebsd.org (Postfix) with ESMTP id 56A8F14E8A for ; Thu, 22 Jul 1999 13:37:35 -0700 (PDT) (envelope-from wpaul@ctr.columbia.edu) Received: from startide.ctr.columbia.edu (wpaul@startide.ctr.columbia.edu [128.59.64.52]) by sirius.ctr.columbia.edu (8.9.1/8.6.4.287) with ESMTP id QAA21364; Thu, 22 Jul 1999 16:36:41 -0400 (EDT) From: wpaul@ctr.columbia.edu (Bill Paul) Received: (wpaul@localhost) by startide.ctr.columbia.edu (8.9.1/8.6.4.788743) id QAA27461; Thu, 22 Jul 1999 16:36:43 -0400 (EDT) Message-Id: <199907222036.QAA27461@startide.ctr.columbia.edu> Subject: Re: wi driver with SKIP To: jflowers@ezo.net (Jim Flowers) Date: Thu, 22 Jul 1999 16:36:42 -0400 (EDT) Cc: skip-info@skip-vpn.org, freebsd-security@freebsd.org In-Reply-To: from "Jim Flowers" at Jul 22, 99 04:22:13 pm X-Mailer: ELM [version 2.4 PL25] 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 Of all the gin joints in all the towns in all the world, Jim Flowers had to walk into mine and say: > Thanks for the response. Sorry for the hypertext. A new portable not > fully configured yet. See comments below. Gotta watch those defaults. > > Hm. My understanding is that in an Ethernet II frame, the type field > > represents the payload type in the frame, which can be IP, ARP, reverse > > ARP, to name a few. If SKIP packets have a different kind of header > > than IP, then the frame type will be different from IP (which is 0x800). > > SKIP encapsulates the original packet and prepends a new IP header and > recalculates the header checksum. The 8-bit protocol field is 57. > Should look like a normal IP packet to the link layer. Just not TCP or > UDP. > > Note the problem is in the outbound direction so I don't quite see how > the Ethernet II type field would be wrong. Isn't this determined by the > wi driver and hardware? The host creates the ethernet frame header, including the destination address, source address and ethernet frame type. There are different frame types for different kinds of packets: #define ETHERTYPE_PUP 0x0200 /* PUP protocol */ #define ETHERTYPE_IP 0x0800 /* IP protocol */ #define ETHERTYPE_ARP 0x0806 /* Addr. resolution protocol */ #define ETHERTYPE_REVARP 0x8035 /* reverse Addr. resolution protocol */ #define ETHERTYPE_VLAN 0x8100 /* IEEE 802.1Q VLAN tagging */ #define ETHERTYPE_LOOPBACK 0x9000 /* used to test interfaces */ /* XXX - add more useful types here */ Like I said: the RFC1042 encapsulation is only done for IP, ARP and Reverse ARP frame types: if for some reason the SKIP software is using a different ethertype then the encapsulation won't be done and the packets will appear bogus on the other end. The receive decapsulation works because the WaveLAN tells the host ahead of time of the received frame has a SNAP header or not. If you look at the SKIP source you might actually be able to determine if this is the case. I don't have the SKIP source but you do (you must have or you wouldn't have been able to make it work with FreeBSD) so it's up to you to look. > > As to why it works when the packets originate on another interface, > > I'm not sure. I can only assume that in that case, the packets are > > tunneled through IP, in which case the ethertype is correct and > > wi_start() passes them correctly. > > Well, I think I misrepresented this. What works is to install SKIP on a > FreeBSD Ethernet interface (lnc1) and then connect this to a WaveLAN/EC > converter that then communicates with the Windows 98 skiphost. No wi driver > involved but it is what leads me to think that the W98 implementation is > OK. *sigh* You never mentioned a WaveLAN/EC before. > Before I try hacking the driver, No. You should try hacking the driver first, because it would take you a very short amount of time and it would satisfy my burning curiosity. You could even attempt to prove or disprove my theory by adding a single printf() in wi_start() which prints the ethertype field out so that you can see what it thinks it is. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Department of Electrical Engineering Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "Mulder, toads just fell from the sky!" "I guess their parachutes didn't open." ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 22 13:42:19 1999 Delivered-To: freebsd-security@freebsd.org Received: from lily.ezo.net (lily.ezo.net [206.102.130.13]) by hub.freebsd.org (Postfix) with ESMTP id 3A4B714E8A for ; Thu, 22 Jul 1999 13:42:15 -0700 (PDT) (envelope-from jflowers@ezo.net) Received: from lily.ezo.net (jflowers@localhost.ezo.net [127.0.0.1]) by lily.ezo.net (8.8.7/8.8.7) with SMTP id QAA04513; Thu, 22 Jul 1999 16:41:54 -0400 (EDT) Date: Thu, 22 Jul 1999 16:41:54 -0400 (EDT) From: Jim Flowers To: Thomas Uhrfelt Cc: skip-info@skip-vpn.org;, freebsd-security@FreeBSD.ORG Subject: Re: SV: SKIP and NAT nomadic server - howto (long) In-Reply-To: <01BED471.C8203720.thomas.uhrfelt@plymovent.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Content-Transfer-Encoding: QUOTED-PRINTABLE Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Absolutely not stupid. This is the essential VPN concept (at least in my= =20 mind). There isn't any reason why the configuration that I outlined=20 shouldn't work for both ends as long as the public skiphost address on=20 one end is fixed. Even better if both skiphost addresses are known in adva= nce as=20 that relieves the requirement that the skiphosts be located in-line=20 through the use of static routes. With this kind of setup you can even access the Internet from the other=20 end, set up Exchange server replications and anything else you can think=20 of that can run over IP. Great for desktop to desktop transfer if you=20 have enough bandwidth. For secure systems, I prefer a screened subnet system. The skiphost=20 functions can be combined with bastion host functions running on a=20 perimeter network. I have one system with VPN nodes in USA East Coast, USA West Coast, Belgium, Goa, India and Taiwan. Soon to add USA Southeast and Delhi, India. Works great. Jim Flowers #4 ISP on C|NET, #1 in Ohio On Thu, 22 Jul 1999, Thomas Uhrfelt wrote: > Excuse me if I am a bit stupid here but my question boils down to this.. >=20 > Is it possible to connect two private (192.168.1.0/24 and 192.168.10.0/24= )=20 > networks on the net via 2 skip/natd gateways and still have the original = natd=20 > functionality (http etc for the clients)? >=20 > Thomas Uhrfelt thomas.uhrfelt@plymovent.se > Computer Technician >=20 > PlymoVent AB > F=F6reningsgatan 37 > 211 52 Malmoe > Sweden >=20 > http://www.plymovent.com >=20 >=20 >=20 >=20 >=20 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Thu Jul 22 20: 7: 7 1999 Delivered-To: freebsd-security@freebsd.org Received: from lily.ezo.net (lily.ezo.net [206.102.130.13]) by hub.freebsd.org (Postfix) with ESMTP id A762614FC8 for ; Thu, 22 Jul 1999 20:07:01 -0700 (PDT) (envelope-from jflowers@ezo.net) Received: from lily.ezo.net (jflowers@localhost.ezo.net [127.0.0.1]) by lily.ezo.net (8.8.7/8.8.7) with SMTP id XAA15345; Thu, 22 Jul 1999 23:05:39 -0400 (EDT) Date: Thu, 22 Jul 1999 23:05:39 -0400 (EDT) From: Jim Flowers To: Bill Paul Cc: skip-info@skip-vpn.org, freebsd-security@freebsd.org Subject: Re: wi driver with SKIP In-Reply-To: <199907222036.QAA27461@startide.ctr.columbia.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 OK, you win. Would take me that long to find my sniffer, anyway. The driver installs by pccardd at startup and at that time returns 806 for the value of Ether type. That's before the skip driver is loaded. It also returns 800 for each IP packet and 806 for each arp packet with the skip module turned off and 800 for each IP packet with the skip module turned on. Tcpdump verifies that the SKIP packets are IP protocol 57. Jim Flowers #4 ISP on C|NET, #1 in Ohio On Thu, 22 Jul 1999, Bill Paul wrote: > > No. You should try hacking the driver first, because it would take you > a very short amount of time and it would satisfy my burning curiosity. > You could even attempt to prove or disprove my theory by adding a single > printf() in wi_start() which prints the ethertype field out so that you > can see what it thinks it is. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 23 7:50:28 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns1.sprawlnet.com (ns1.sprawlnet.com [208.224.169.130]) by hub.freebsd.org (Postfix) with ESMTP id D7D1315341 for ; Fri, 23 Jul 1999 07:50:16 -0700 (PDT) (envelope-from mike@sprawlnet.com) Received: from websprawl (jedi.sprawlnet.com [208.224.169.134]) by ns1.sprawlnet.com (8.9.2/8.9.2) with SMTP id WAA00845 for ; Fri, 23 Jul 1999 22:50:25 GMT (envelope-from mike@sprawlnet.com) Message-ID: <001201bed51a$a2a682c0$86a9e0d0@sprawlnet.com> From: "Michael Steinfeld" To: Subject: subscribing Date: Fri, 23 Jul 1999 10:49:58 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01BED4F9.1B54A570" 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_000F_01BED4F9.1B54A570 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable subscribe freebsd-stable ------=_NextPart_000_000F_01BED4F9.1B54A570 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
subscribe = freebsd-stable
------=_NextPart_000_000F_01BED4F9.1B54A570-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 23 8:55:19 1999 Delivered-To: freebsd-security@freebsd.org Received: from ns1.sprawlnet.com (ns1.sprawlnet.com [208.224.169.130]) by hub.freebsd.org (Postfix) with ESMTP id 36C7814D48 for ; Fri, 23 Jul 1999 08:55:07 -0700 (PDT) (envelope-from mike@sprawlnet.com) Received: from websprawl (jedi.sprawlnet.com [208.224.169.134]) by ns1.sprawlnet.com (8.9.2/8.9.2) with SMTP id XAA00982 for ; Fri, 23 Jul 1999 23:55:02 GMT (envelope-from mike@sprawlnet.com) Message-ID: <004301bed523$a9c6c3e0$86a9e0d0@sprawlnet.com> From: "Michael Steinfeld" To: Subject: ipfw or ipfilter Date: Fri, 23 Jul 1999 11:54:35 -0400 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0040_01BED502.226D4570" 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_0040_01BED502.226D4570 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I need to set up a firewall/client mode on a 3.2-STABLE box and a = 4.0-current box. In the past I have been using ipfw but im hearing that = a lot of people are moving towards IPfilter. In any case feedback would be appreciated. Michael Steinfeld Unix Administrator Sprawlnet.com INC ------=_NextPart_000_0040_01BED502.226D4570 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
I need to set up a firewall/client mode on a = 3.2-STABLE box=20 and a 4.0-current box. In the past I have been using ipfw but im hearing = that a=20 lot of people are moving towards IPfilter.
In any case feedback would be = appreciated.
 
 
Michael Steinfeld
Unix = Administrator
Sprawlnet.com=20 INC
------=_NextPart_000_0040_01BED502.226D4570-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 23 14:17:42 1999 Delivered-To: freebsd-security@freebsd.org Received: from lily.ezo.net (lily.ezo.net [206.102.130.13]) by hub.freebsd.org (Postfix) with ESMTP id CACB11575A for ; Fri, 23 Jul 1999 14:17:37 -0700 (PDT) (envelope-from jflowers@ezo.net) Received: from lily.ezo.net (jflowers@localhost.ezo.net [127.0.0.1]) by lily.ezo.net (8.8.7/8.8.7) with SMTP id RAA13637; Fri, 23 Jul 1999 17:16:37 -0400 (EDT) Date: Fri, 23 Jul 1999 17:16:37 -0400 (EDT) From: Jim Flowers To: Bill Paul Cc: skip-info@skip-vpn.org, freebsd-security@FreeBSD.ORG Subject: Re: wi driver with SKIP In-Reply-To: <199907222036.QAA27461@startide.ctr.columbia.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 Ran test between two fbsd boxes, one with SKIP on box A and the other with SKIP on wi interface (box C) with an intermediate WavePOINT II as in: =======Ethernet========= [C] | | | [SKIP] [B] [SKIP] | | | [A] [W1]--))))[WP-1][WP-2](((([W2] W1 and W2 are IEEE/ISA Turbo cards with the wi driver Ping requests originating from A are succesfully encapsulated and arrive at C where they are successfully de-encapsulated causing a ping response from C that begins the trek back to A. Tcpdump, gets a copy of the frame through the bpf interface to the wi driver which it correctly identifies the source and destination addresses and that the IP type is SKIP (57) but complains that the packet has been truncated and is short by 120 bytes. With SKIP turned off, transmission is successful in both directions. From this, it appears that SKIP encapsulated packets will transit out the wi interface just fine (as in W1) as long as the SKIP module is not shimmed in before the wi interface (as in W2). Looks like the routine where SKIP hands the encrypted/encapsulated packets back may be suspect. As SKIP works with other traditional ethernet interfaces (I use mainly ed, lnc, and fxp), it must be something that is expected by the wi driver that is not being furnished by the SKIP shim. Would have done more but the building that Hillary Clinton is speaking in front of is next to ours and we got kicked out by the secret service. I would look at the SKIP code (I've debugged it before) but I haven't a clue what I'm looking for at the moment. Jim Flowers #4 ISP on C|NET, #1 in Ohio To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Fri Jul 23 14:30: 8 1999 Delivered-To: freebsd-security@freebsd.org Received: from sirius.ctr.columbia.edu (sirius.ctr.columbia.edu [128.59.64.60]) by hub.freebsd.org (Postfix) with ESMTP id 08FD715693 for ; Fri, 23 Jul 1999 14:30:05 -0700 (PDT) (envelope-from wpaul@comet.columbia.edu) Received: from comet.columbia.edu (xylophone.comet.columbia.edu [128.59.68.38]) by sirius.ctr.columbia.edu (8.9.1/8.6.4.287) with ESMTP id RAA00718; Fri, 23 Jul 1999 17:30:04 -0400 (EDT) From: wpaul@comet.columbia.edu (Bill Paul) Received: (from wpaul@localhost) by comet.columbia.edu (8.9.3/8.8.7/COMET) id RAA02570; Fri, 23 Jul 1999 17:30:04 -0400 (EDT) Message-Id: <199907232130.RAA02570@comet.columbia.edu> Subject: Re: wi driver with SKIP In-Reply-To: from Jim Flowers at "Jul 23, 1999 05:16:37 pm" To: jflowers@ezo.net (Jim Flowers) Date: Fri, 23 Jul 1999 17:30:04 -0400 (EDT) Cc: skip-info@skip-vpn.org, freebsd-security@FreeBSD.ORG X-Mailer: ELM [version 2.4ME+ PL54 (25)] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: owner-freebsd-security@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Of all the gin joints in all the towns in all the world, Jim Flowers had to walk into mine and say: > Ran test between two fbsd boxes, one with SKIP on box A and the other > with SKIP on wi interface (box C) with an intermediate WavePOINT II as in: > > =======Ethernet========= [C] > | | | > [SKIP] [B] [SKIP] > | | | > [A] [W1]--))))[WP-1][WP-2](((([W2] > > W1 and W2 are IEEE/ISA Turbo cards with the wi driver > > Ping requests originating from A are succesfully encapsulated and arrive > at C where they are successfully de-encapsulated causing a ping response > from C that begins the trek back to A. Tcpdump, gets a copy of > the frame through the bpf interface to the wi driver which it correctly > identifies the source and destination addresses and that the IP type is > SKIP (57) but complains that the packet has been truncated and is short > by 120 bytes. With SKIP turned off, transmission is successful in both > directions. Ideally what you ought to do is run tcpdump -n -e -p -x -s1514 -i wi0 on both sides. This will avoid putting the interface into promiscuous mode (changes the operation of the NIC slightly) and will dump out the packet contents. At this point, you show me the packet contents so I can see for myself the difference between how the frame should look and how it ultimately does look. Furthermore, what happens when you ping W2 from W1? > Would have done more but the building that Hillary Clinton is speaking > in front of is next to ours and we got kicked out by the secret service. You know, I've heard plenty of excuses in my time, but this one takes the cake. Not that I'm assusing you of lying, but this is definitely one for the books. -Bill -- ============================================================================= -Bill Paul (212) 854-6020 | System Manager, Master of Unix-Fu Work: wpaul@ctr.columbia.edu | Department of Electrical Engineering Home: wpaul@skynet.ctr.columbia.edu | Columbia University, New York City ============================================================================= "Mulder, toads just fell from the sky!" "I guess their parachutes didn't open." ============================================================================= To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jul 24 10:47: 3 1999 Delivered-To: freebsd-security@freebsd.org Received: from rebel.net.au (rebel.rebel.net.au [203.20.69.66]) by hub.freebsd.org (Postfix) with ESMTP id 54BB114C9F for ; Sat, 24 Jul 1999 10:46:38 -0700 (PDT) (envelope-from kkenn@rebel.net.au) Received: from 203.20.69.78 (dialup-8.rebel.net.au [203.20.69.78]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id DAA27195 for ; Sun, 25 Jul 1999 03:15:20 +0930 Received: (qmail 95938 invoked from network); 24 Jul 1999 17:44:53 -0000 Received: from localhost (kkenn@127.0.0.1) by localhost with SMTP; 24 Jul 1999 17:44:53 -0000 Date: Sun, 25 Jul 1999 03:14:52 +0930 (CST) From: Kris Kennaway Reply-To: kkenn@rebel.net.au To: security@freebsd.org Subject: New libcrypt snapshot 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 some delay, I've got another snapshot of my libcrypt code ready for comment and testing: http://www.freebsd.org/~kris/crypt-990725.tar.gz This is a complete rewrite of my previous code, based on suggestions from several people. Here is a summary of what the new crypt library does: * Plug-in crypt() modules - new hash algorithms can be compiled and installed on-the-fly without recompiling libcrypt or your applications (currently only works for shared library). * Available modules are listed in /etc/crypt.conf and hashed into /etc/crypt.db using crypt_mkdb(8). The reason for the separate database is that information internal to the module needs to be picked up (namely the algorithm's magic number) and I don't think it appropriate that the system administrator should have to know this. Besides, using a database is more efficient than parsing the config file. * Two login capabilities, localcipher and localcipherrounds are available in /etc/login.conf to specify the password hash (from /etc/crypt.conf) to use for users in that class. localcipherrounds is an algorithm-specific parameter used for specifying the number of encryption rounds to perform in generating the hash. * crypt() understands the traditional DES and MD5 password formats internally (i.e. without using external modules). This should make it fully backwards- compatible with existing password files. * The default format ("modular crypt format", MCF) for password hashes is: $Magic$Rounds$Salt$Hash "Magic" is a 24-bit base-64 encoded random number which is unique to each hash algorithm. This provides statistical collision protection against third-party vendors providing their own hash modules or developing their own algorithms. Using a magic number obfuscates the password hash somewhat, but it's much more robust than using an ordinal or string identifier (e.g. "md5"). "Rounds" specifies the number of encryption rounds to use. The meaning of the number is algorithm-dependent; e.g., blowfish passwords have rounds = log_2 #encryption rounds. For fixed-cost algorithms like the current MD5 hash, this is null. "Salt" is a random base-64 encoded salt. "Hash" is the hashed password. * A new function, char *generate_salt(char *salt, const char *cipher, long rounds); has been added to libcrypt for the purposes of generating a valid salt which can be passed to crypt(). There are at least two places in the base OS which need to generate new salts; passwd(1) and the pam_unix PAM module, and possibly others. * Currently modules for the MCF versions of MD5, and SHA-1 are provided, as well as openbsd-style Blowfish passwords. Windows NT-style hashes and Secure Remote Password (SRP) hashes are also planned. The SHA-1 hash is only provided as a proof of concept - there is probably little reason to migrate to it at this point, as the current MD5 algorithm is convoluted enough that it's likely to be secure even against (as yet unknown) serious MD5 weaknesses. This is alpha-level code and is still in need of some cleanups and added functionality (in particular, static binaries need to be able to use plug-in modules, probably by fork()ing in the library and calling an external helper binary module). Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message From owner-freebsd-security Sat Jul 24 11:15:33 1999 Delivered-To: freebsd-security@freebsd.org Received: from rebel.net.au (rebel.rebel.net.au [203.20.69.66]) by hub.freebsd.org (Postfix) with ESMTP id 21E2D14BC9 for ; Sat, 24 Jul 1999 11:15:25 -0700 (PDT) (envelope-from kkenn@rebel.net.au) Received: from 203.20.69.76 (dialup-6.rebel.net.au [203.20.69.76]) by rebel.net.au (8.8.5/8.8.4) with ESMTP id DAA28137 for ; Sun, 25 Jul 1999 03:45:21 +0930 Received: (qmail 97663 invoked from network); 24 Jul 1999 18:14:57 -0000 Received: from localhost (kkenn@127.0.0.1) by localhost with SMTP; 24 Jul 1999 18:14:57 -0000 Date: Sun, 25 Jul 1999 03:44:57 +0930 (CST) From: Kris Kennaway Reply-To: kkenn@rebel.net.au To: security@FreeBSD.ORG Subject: Re: New libcrypt snapshot 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, 25 Jul 1999, Kris Kennaway wrote: > After some delay, I've got another snapshot of my libcrypt code ready for > comment and testing: > > http://www.freebsd.org/~kris/crypt-990725.tar.gz Actually I belatedly realised I shouldn't have put it here since it contains export-restricted code. It's at http://www.physics.adelaide.edu.au/~kkennawa/crypt-990725.tar.gz instead. Sorry :-( Kris To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-security" in the body of the message