freebsd-security Digest, Vol 201, Issue 2 - rhinux - org.freebsd.freebsd-security

1 message in org.freebsd.freebsd-securityfreebsd-security Digest, Vol 201, Iss...

From	Sent On	Attachments
rhinux	Mar 16, 2007 2:50 am

Subject:	freebsd-security Digest, Vol 201, Issue 2
From:	rhinux (linu...@gmail.com)
Date:	Mar 16, 2007 2:50:58 am
List:	org.freebsd.freebsd-security

? 2007-3-15???8:00?free...@freebsd.org ???

Send freebsd-security mailing list submissions to free...@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 free...@freebsd.org

You can reach the person managing the list at free...@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 <pj...@FreeBSD.org> Subject: Check PRIV_VFS_MOUNT when jailed. To: free...@FreeBSD.org Message-ID: <2007...@garage.freebsd.pl> Content-Type: text/plain; charset="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 allow to grant privileges for jails. I'd like to commit it now, so I can experiment easier with my ZFS improvements.

-- Pawel Jakub Dawidek http://www.wheel.pl pj...@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/ attachments/20070314/28c8fdd2/attachment-0001.pgp

------------------------------

Message: 2 Date: Wed, 14 Mar 2007 14:06:45 -0500 (CDT) From: Robert Johannes <rjoh...@piper.hamline.edu> Subject: Re: freebsd vpn server behind nat dsl router To: VANHULLEBUS Yvan <vanh...@zeninc.net> Cc: free...@freebsd.org Message-ID: <Pine...@wnk.hamline.edu> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

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 turned on. The vpn servers are part of the local LANs, and I have port- forwarding setup between the dsl modems and the vpn servers. E.g, when traffic comes from the internet destined for port 500, I forward that traffic to the vpn servers (192.168.x.254 on the diagram).

If your redirection only works for port 500, it won't be enough, as it will only allow IKE negociations, not encrypted traffic.

You'll have to add forwarding for ESP protocol, or use NAT-T patch and also forward UDP 4500 port.

The freebsd servers are not running a firewall or NAT at this point. I don't think they need to run NAT, but I haven't decided on the firewall yet.

So, given that situation, I don't know if the NAT changes to the kernel you are suggesting below would help, since NAT is happening on the dsl routers. I am guessing my problem is between the vpn server and the dsl router's NAT capability. I have done a tcpdump on the gif interface, and I can see the ping requests being made across it, but there's no response. I don't even know if the traffic is making it beyond the vpn box, let alone beyond the dsl modem.

The NAT-T patch I was talking about adds the kernel part of an *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 still don't see visible progress. I did rebuild world and the kernel with the 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 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 > client-201.240.165.191.speedy.net.pe: \ IP 192.168.1.254 > 192.168.0.254: ICMP echo request, id 5784, seq 1519, \ length 64 (ipip-proto-4) 14:06:54.595071 IP 190.41.95.135 > client-201.240.165.191.speedy.net.pe: \ IP 192.168.1.254 > 192.168.0.254: ICMP echo request, id 5784, seq 1520, \ length 64 (ipip-proto-4)

From 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), 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 to the other end.

The tunnel is not using racoon yet. I figure that I should be 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.

thanks robert

------------------------------

Message: 3 Date: Thu, 15 Mar 2007 02:31:54 +0000 From: Tom Judge <to...@tomjudge.com> Subject: Re: freebsd vpn server behind nat dsl router To: Robert Johannes <rjoh...@piper.hamline.edu> Cc: free...@freebsd.org, VANHULLEBUS Yvan <vanh...@zeninc.net> Message-ID: <45F8...@tomjudge.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Robert Johannes wrote:

On Wed, 7 Mar 2007, VANHULLEBUS Yvan wrote:

I have created an esp tunnel between my two sites, and I am 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:

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 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.)

From what I can tell, the kernel knows that it is to send the ping request

If any one can shed some more light on this, I would appreciate it.

From 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 <pj...@FreeBSD.org> Subject: Re: Check PRIV_VFS_MOUNT when jailed. To: free...@FreeBSD.org Message-ID: <2007...@garage.freebsd.pl> Content-Type: text/plain; charset="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 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.

------------------------------

Message: 5 Date: Thu, 15 Mar 2007 12:02:24 +0100 (BST) From: Robert Watson <rwat...@FreeBSD.org> Subject: Re: OpenBSD IPv6 remote kernel buffer overflow. FreeBSD has this too? To: Eygene Ryabinkin <rea-...@codelabs.ru> Cc: free...@freebsd.org Message-ID: <2007...@fledge.watson.org> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed

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 simular code.

Robert, anyone, could you please check?

Eygene,

Sorry for the delayed response on this -- I've only just returned 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, but I will continue tracking the thread. Apparently this vulnerability 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 affected. If we discover any information to the contrary, you can be sure that we will get it fixed and release an advisory!

Robert N M Watson Computer Laboratory University of Cambridge

End of freebsd-security Digest, Vol 201, Issue 2 ************************************************

	Start a set with this search
	Include this search in one of my sets
	Exclude this search from one of my sets