Re: freebsd-security Digest, Vol 201, Issue 2
- From: rhinux <linuxinfoplus@xxxxxxxxx>
- Date: Fri, 16 Mar 2007 10:26:27 +0800
在 2007-3-15，下午8:00，freebsd-security-request@xxxxxxxxxxx 写道：
Send freebsd-security mailing list submissions to
freebsd-security@xxxxxxxxxxx
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@xxxxxxxxxxx
You can reach the person managing the list at
freebsd-security-owner@xxxxxxxxxxx
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@xxxxxxxxxxx>
Subject: Check PRIV_VFS_MOUNT when jailed.
To: freebsd-security@xxxxxxxxxxx
Message-ID: <20070314125918.GF7847@xxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxx 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@xxxxxxxxxxxxxxxxx>
Subject: Re: freebsd vpn server behind nat dsl router
To: VANHULLEBUS Yvan <vanhu_bsd@xxxxxxxxxx>
Cc: freebsd-security@xxxxxxxxxxx
Message-ID: <Pine.LNX.4.64.0703141353250.3246@xxxxxxxxxxxxxxx>
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 requestfrom 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@xxxxxxxxxxxx>
Subject: Re: freebsd vpn server behind nat dsl router
To: Robert Johannes <rjohanne@xxxxxxxxxxxxxxxxx>
Cc: freebsd-security@xxxxxxxxxxx, VANHULLEBUS Yvan
<vanhu_bsd@xxxxxxxxxx>
Message-ID: <45F8B01A.50106@xxxxxxxxxxxx>
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 pingfrom 192.168.1.254 to 192.168.0.254 through the tunnel mouths
request
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@xxxxxxxxxxx>
Subject: Re: Check PRIV_VFS_MOUNT when jailed.
To: freebsd-security@xxxxxxxxxxx
Message-ID: <20070315041149.GM7847@xxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxx 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@xxxxxxxxxxx>
Subject: Re: OpenBSD IPv6 remote kernel buffer overflow. FreeBSD has
this too?
To: Eygene Ryabinkin <rea-fbsd@xxxxxxxxxxx>
Cc: freebsd-security@xxxxxxxxxxx
Message-ID: <20070315120009.A60010@xxxxxxxxxxxxxxxxx>
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@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security- unsubscribe@xxxxxxxxxxx"
End of freebsd-security Digest, Vol 201, Issue 2
************************************************
_______________________________________________
freebsd-security@xxxxxxxxxxx mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-unsubscribe@xxxxxxxxxxx"
- Prev by Date: Re: OpenBSD IPv6 remote kernel buffer overflow. FreeBSD has this too?
- Next by Date: Re: OpenBSD IPv6 remote kernel buffer overflow. FreeBSD has this too?
- Previous by thread: Check PRIV_VFS_MOUNT when jailed.
- Next by thread: Reality check: IPFW sees SSH traffic that sshd does not?
- Index(es):
Relevant Pages
|
|
