Send freebsd-security mailing list submissions to
[email protected]
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
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
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 <[EMAIL PROTECTED]>
Subject: Check PRIV_VFS_MOUNT when jailed.
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
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
[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>
Subject: Re: freebsd vpn server behind nat dsl router
To: VANHULLEBUS Yvan <[EMAIL PROTECTED]>
Cc: [email protected]
Message-ID: <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
Subject: Re: freebsd vpn server behind nat dsl router
To: Robert Johannes <[EMAIL PROTECTED]>
Cc: [email protected], VANHULLEBUS Yvan
<[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>
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 <[EMAIL PROTECTED]>
Subject: Re: Check PRIV_VFS_MOUNT when jailed.
To: [email protected]
Message-ID: <[EMAIL PROTECTED]>
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
[EMAIL PROTECTED] 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 <[EMAIL PROTECTED]>
Subject: Re: OpenBSD IPv6 remote kernel buffer overflow. FreeBSD has
this too?
To: Eygene Ryabinkin <[EMAIL PROTECTED]>
Cc: [email protected]
Message-ID: <[EMAIL PROTECTED]>
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
------------------------------
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-security
To unsubscribe, send any mail to "freebsd-security-
[EMAIL PROTECTED]"
End of freebsd-security Digest, Vol 201, Issue 2
************************************************
