Date: Fri, 16 Mar 2007 10:26:27 +0800 From: rhinux <linuxinfoplus@gmail.com> To: freebsd-security@freebsd.org Subject: Re: freebsd-security Digest, Vol 201, Issue 2 Message-ID: <3DF5B330-90FD-4268-A3D7-874A7566E855@gmail.com> In-Reply-To: <20070315120026.D7B2916A411@hub.freebsd.org> References: <20070315120026.D7B2916A411@hub.freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
=D4=DA 2007-3-15=A3=AC=CF=C2=CE=E78:00=A3=ACfreebsd-security-request@freeb= sd.org =D0=B4=B5=C0=A3=BA > Send freebsd-security mailing list submissions to > freebsd-security@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.freebsd.org/mailman/listinfo/freebsd-security > or, via email, send a message with subject or body 'help' to > freebsd-security-request@freebsd.org > > You can reach the person managing the list at > freebsd-security-owner@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-security digest..." > > > Today's Topics: > > 1. Check PRIV_VFS_MOUNT when jailed. (Pawel Jakub Dawidek) > 2. Re: freebsd vpn server behind nat dsl router (Robert Johannes) > 3. Re: freebsd vpn server behind nat dsl router (Tom Judge) > 4. Re: Check PRIV_VFS_MOUNT when jailed. (Pawel Jakub Dawidek) > 5. Re: OpenBSD IPv6 remote kernel buffer overflow. FreeBSD has > this too? (Robert Watson) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 14 Mar 2007 13:59:18 +0100 > From: Pawel Jakub Dawidek <pjd@FreeBSD.org> > Subject: Check PRIV_VFS_MOUNT when jailed. > To: freebsd-security@FreeBSD.org > Message-ID: <20070314125918.GF7847@garage.freebsd.pl> > Content-Type: text/plain; charset=3D"iso-8859-2" > > Hi. > > I'd like to commit this patch: > > http://people.freebsd.org/~pjd/patches/vfs_mount.c.9.patch > > It currently should change nothing, but will be needed once we =20 > allow to > grant privileges for jails. I'd like to commit it now, so I can > experiment easier with my ZFS improvements. > > --=20 > Pawel Jakub Dawidek http://www.wheel.pl > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 187 bytes > Desc: not available > Url : http://lists.freebsd.org/pipermail/freebsd-security/=20 > attachments/20070314/28c8fdd2/attachment-0001.pgp > > ------------------------------ > > Message: 2 > Date: Wed, 14 Mar 2007 14:06:45 -0500 (CDT) > From: Robert Johannes <rjohanne@piper.hamline.edu> > Subject: Re: freebsd vpn server behind nat dsl router > To: VANHULLEBUS Yvan <vanhu_bsd@zeninc.net> > Cc: freebsd-security@freebsd.org > Message-ID: <Pine.LNX.4.64.0703141353250.3246@wnk.hamline.edu> > Content-Type: TEXT/PLAIN; charset=3DUS-ASCII; format=3Dflowed > > > On Wed, 7 Mar 2007, VANHULLEBUS Yvan wrote: > >> On Wed, Mar 07, 2007 at 12:04:17PM -0600, Robert Johannes wrote: >>> Thanks for your response. My freebsd vpn servers are behind the dsl >>> routers at each site which. The modems have firewall and NAT =20 >>> turned on. >>> The vpn servers are part of the local LANs, and I have port-=20 >>> forwarding >>> setup between the dsl modems and the vpn servers. E.g, when =20 >>> traffic comes >>> from the internet destined for port 500, I forward that traffic =20 >>> to the vpn >>> servers (192.168.x.254 on the diagram). >> >> If your redirection only works for port 500, it won't be enough, =20 >> as it >> will only allow IKE negociations, not encrypted traffic. >> >> You'll have to add forwarding for ESP protocol, or use NAT-T patch =20= >> and >> also forward UDP 4500 port. >> >> >>> The freebsd servers are not running a firewall or NAT at this =20 >>> point. I >>> don't think they need to run NAT, but I haven't decided on the =20 >>> firewall >>> yet. >>> >>> So, given that situation, I don't know if the NAT changes to the =20 >>> kernel >>> you are suggesting below would help, since NAT is happening on =20 >>> the dsl >>> routers. I am guessing my problem is between the vpn server and =20 >>> the dsl >>> router's NAT capability. I have done a tcpdump on the gif =20 >>> interface, and >>> I can see the ping requests being made across it, but there's no =20 >>> response. >>> I don't even know if the traffic is making it beyond the vpn box, =20= >>> let >>> alone beyond the dsl modem. >> >> The NAT-T patch I was talking about adds the kernel part of an =20 >> *IPSec* >> feature: support for NAT-Traversal extension (RFCs 3947 and 3948), >> which allows IPSec tunnels to be established if there is some NAT >> between IPSec gates. >> >> This is exactly your setup. > > Ok, I have done quite a bit of work since my last email, but I =20 > still don't > see visible progress. I did rebuild world and the kernel with the =20 > NAT-T > patches/support that you recommended. I have been playing around with > ipsec e.t.c. > > I have created an esp tunnel between my two sites, and I am sending =20= > some > ping traffic to the remote end, but the packets don't seem to get =20 > through. > Here's a snippet of what I see on tcpdump: > > 14:06:53.594241 IP 190.41.95.135 > =20 > client-201.240.165.191.speedy.net.pe: \ > IP 192.168.1.254 > 192.168.0.254: ICMP echo request, id 5784, seq =20 > 1519, \ > length 64 (ipip-proto-4) > 14:06:54.595071 IP 190.41.95.135 > =20 > client-201.240.165.191.speedy.net.pe: \ > IP 192.168.1.254 > 192.168.0.254: ICMP echo request, id 5784, seq =20 > 1520, \ > length 64 (ipip-proto-4) > >> =46rom what I can tell, the kernel knows that it is to send the ping =20= >> request > from 192.168.1.254 to 192.168.0.254 through the tunnel mouths > 190.41.95.135 and 201.240.165.191. But, there's no request from =20 > the other > end. Doing a tcpdump on the other side (192.168.0.254), nothing is =20= > coming > in. I have also done a ping from the latter machine to the former, =20= > but > with exactly the same problem. Nothing seems to get to the other end. > > The tunnel is not using racoon yet. I figure that I should be able =20= > to see > some traffic going back and forth before I use racoon to manage =20 > keys. The > tunnel was created by the following lines on one host, and reversed on > the other: > > spdadd 192.168.1.0/24 192.168.0.0/24 any -P in ipsec > esp/tunnel/190.41.95.135-201.240.151.15/require; > spdadd 192.168.0.0/24 192.168.1.0/24 any -P out ipsec > esp/tunnel/201.240.151.15-190.41.95.135/require; > > If any one can shed some more light on this, I would appreciate it. > > thanks > robert > > > ------------------------------ > > Message: 3 > Date: Thu, 15 Mar 2007 02:31:54 +0000 > From: Tom Judge <tom@tomjudge.com> > Subject: Re: freebsd vpn server behind nat dsl router > To: Robert Johannes <rjohanne@piper.hamline.edu> > Cc: freebsd-security@freebsd.org, VANHULLEBUS Yvan > <vanhu_bsd@zeninc.net> > Message-ID: <45F8B01A.50106@tomjudge.com> > Content-Type: text/plain; charset=3DISO-8859-1; format=3Dflowed > > Robert Johannes wrote: >> >> On Wed, 7 Mar 2007, VANHULLEBUS Yvan wrote: >> >> >> Ok, I have done quite a bit of work since my last email, but I still >> don't see visible progress. I did rebuild world and the kernel =20 >> with the >> NAT-T patches/support that you recommended. I have been playing =20 >> around >> with ipsec e.t.c. >> >> I have created an esp tunnel between my two sites, and I am =20 >> sending some >> ping traffic to the remote end, but the packets don't seem to get >> through. Here's a snippet of what I see on tcpdump: >> >> 14:06:53.594241 IP 190.41.95.135 > =20 >> client-201.240.165.191.speedy.net.pe: \ >> IP 192.168.1.254 > 192.168.0.254: ICMP echo request, id 5784, seq =20 >> 1519, \ >> length 64 (ipip-proto-4) >> 14:06:54.595071 IP 190.41.95.135 > =20 >> client-201.240.165.191.speedy.net.pe: \ >> IP 192.168.1.254 > 192.168.0.254: ICMP echo request, id 5784, seq =20 >> 1520, \ >> length 64 (ipip-proto-4) > > Firstly have you set your DSL routers up to nat the ipencap protocol > back to your FreeBSD box? (IPencap is a IP payload protocol, not a TCP > or UDP payload, so you will probably need a prity advanced router =20 > to do > this). The packets you see here are not protected by IPSEC they are > just plain old IPENCAP packets. If they where IPSEC packets I would > expect to see ESP as the protocol and not see the encapsulated packet > header (Again when you get IPSEC working you are going to need to NAT > these packets to your freebsd boxes.) > >> >>> =46rom what I can tell, the kernel knows that it is to send the ping >>> request >> from 192.168.1.254 to 192.168.0.254 through the tunnel mouths >> 190.41.95.135 and 201.240.165.191. But, there's no request from the >> other end. Doing a tcpdump on the other side (192.168.0.254), =20 >> nothing >> is coming in. I have also done a ping from the latter machine to the >> former, but with exactly the same problem. Nothing seems to get =20 >> to the >> other end. >> >> The tunnel is not using racoon yet. I figure that I should be =20 >> able to >> see some traffic going back and forth before I use racoon to manage >> keys. The tunnel was created by the following lines on one host, and >> reversed on the other: >> >> spdadd 192.168.1.0/24 192.168.0.0/24 any -P in ipsec >> esp/tunnel/190.41.95.135-201.240.151.15/require; >> spdadd 192.168.0.0/24 192.168.1.0/24 any -P out ipsec >> esp/tunnel/201.240.151.15-190.41.95.135/require; >> >> If any one can shed some more light on this, I would appreciate it. >> > > =46rom what I can see your /etc/ipsec.conf should look like this: > > spdadd 190.41.95.135/32 201.240.151.15/32 ipencap -P in ipsec > esp/tunnel/190.41.95.135-201.240.151.15/require; > spdadd 201.240.151.15/32 190.41.95.135/32 ipencap -P out ipsec > esp/tunnel/201.240.151.15-190.41.95.135/require; > > These rules may be wrong but your tunnel seems to be an IP protocol 4 > payload which is ipencap (see /etc/protocols). > > Hope this helps. > > Tom > > > > > ------------------------------ > > Message: 4 > Date: Thu, 15 Mar 2007 05:11:50 +0100 > From: Pawel Jakub Dawidek <pjd@FreeBSD.org> > Subject: Re: Check PRIV_VFS_MOUNT when jailed. > To: freebsd-security@FreeBSD.org > Message-ID: <20070315041149.GM7847@garage.freebsd.pl> > Content-Type: text/plain; charset=3D"iso-8859-2" > > On Wed, Mar 14, 2007 at 01:59:18PM +0100, Pawel Jakub Dawidek wrote: >> Hi. >> >> I'd like to commit this patch: >> >> http://people.freebsd.org/~pjd/patches/vfs_mount.c.9.patch >> >> It currently should change nothing, but will be needed once we =20 >> allow to >> grant privileges for jails. I'd like to commit it now, so I can >> experiment easier with my ZFS improvements. > > Reviewed by rwatson@ and committed. > > --=20 > Pawel Jakub Dawidek http://www.wheel.pl > pjd@FreeBSD.org http://www.FreeBSD.org > FreeBSD committer Am I Evil? Yes, I Am! > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: not available > Type: application/pgp-signature > Size: 187 bytes > Desc: not available > Url : http://lists.freebsd.org/pipermail/freebsd-security/=20 > attachments/20070315/a6be0eb3/attachment-0001.pgp > > ------------------------------ > > Message: 5 > Date: Thu, 15 Mar 2007 12:02:24 +0100 (BST) > From: Robert Watson <rwatson@FreeBSD.org> > Subject: Re: OpenBSD IPv6 remote kernel buffer overflow. FreeBSD has > this too? > To: Eygene Ryabinkin <rea-fbsd@codelabs.ru> > Cc: freebsd-security@freebsd.org > Message-ID: <20070315120009.A60010@fledge.watson.org> > Content-Type: TEXT/PLAIN; charset=3DUS-ASCII; format=3Dflowed > > > On Wed, 14 Mar 2007, Eygene Ryabinkin wrote: > >> Just spotted the new advisory from CORE: >> http://www.securityfocus.com/archive/1/462728/30/0/threaded Not = an >> expert, but FreeBSD's src/sys/kern/uipc_mbuf2.c has the very =20 >> simular code. >> >> Robert, anyone, could you please check? > > Eygene, > > Sorry for the delayed response on this -- I've only just returned =20 > from Tokyo > in the last day and am significantly behind in e-mail from the trip. > > According to a source analysis by Jinmei, we are not vulnerable, =20 > but I will > continue tracking the thread. Apparently this vulnerability =20 > involved an issue > in the handling of M_EXT, and our implementation of clusters differs > significantly from OpenBSD, so it seems likely we are not =20 > affected. If we > discover any information to the contrary, you can be sure that we =20 > will get it > fixed and release an advisory! > > Robert N M Watson > Computer Laboratory > University of Cambridge > > > ------------------------------ > > _______________________________________________ > freebsd-security@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-=20 > unsubscribe@freebsd.org" > > End of freebsd-security Digest, Vol 201, Issue 2 > ************************************************
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3DF5B330-90FD-4268-A3D7-874A7566E855>