? 2007-3-15???8:00?freebsd-security-request@freebsd.org ???
> 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="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
> 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/
> 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=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 <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=ISO-8859-1; format=flowed
>
> 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
>> 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)
>
> 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
>> 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.
>>
>
> 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 <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="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.
>
> --
> 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/
> 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=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
>
>
> ------------------------------
>
> _______________________________________________
> freebsd-security@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-
> unsubscribe@freebsd.org"
>
> End of freebsd-security Digest, Vol 201, Issue 2
> ************************************************
