Date: Sun, 26 Oct 2003 20:10:09 -0800 (PST) From: "Crist J. Clark" <cristjc@comcast.net> To: freebsd-bugs@FreeBSD.org Subject: Re: kern/57760: Psec policy on inbound trafic is not enforced (allows spoofing) Message-ID: <200310270410.h9R4A9vu009494@freefall.freebsd.org>
next in thread | raw e-mail | index | archive | help
The following reply was made to PR kern/57760; it has been noted by GNATS.
From: "Crist J. Clark" <cristjc@comcast.net>
To: Joachim Schueth <dl2kcd@darc.de>
Cc: FreeBSD-gnats-submit@FreeBSD.org
Subject: Re: kern/57760: Psec policy on inbound trafic is not enforced (allows spoofing)
Date: Sun, 26 Oct 2003 20:07:15 -0800
On Wed, Oct 08, 2003 at 01:57:36PM -0400, Joachim Schueth wrote:
> >How-To-Repeat:
> The following example uses ESP with authentication, but the effect is
> the same with AH.
>
> Configure two hosts running FreeBSD 4.8-RELEASE-p13 with IP addresses
> of 192.168.0.26 and 192.168.0.42, respectively (called host26 and host42
> below). On host42 (the target host), use the following setkey script:
>
> flush;
> spdflush;
> add 192.168.0.26 192.168.0.42 esp 0x026042
> -E 3des-cbc "xxxxxxxxxxxxxxxxxxxxxxxx"
> -A hmac-sha1 "hhhhhhhhhhhhhhhhhhhh";
> add 192.168.0.42 192.168.0.26 esp 0x042026
> -E 3des-cbc "AAAAAAAAAAAAAAAAAAAAAAAA"
> -A hmac-sha1 "rrrrrrrrrrrrrrrrrrrr";
> spdadd 192.168.0.0/24 192.168.0.0/24 any -P in ipsec esp/transport//require;
> spdadd 192.168.0.0/24 192.168.0.0/24 any -P out ipsec esp/transport//require;
>
> On host26 (the attacking host), use the same setkey script but omit the
> spadd lines. This means that host26 has the correct security associations
> to accept the ESP packets of host42, but host26 itself will not use ipsec
> on outgoing packets.
>
> Then establish a TCP connection between host26 and host42, e.g. by
> connecting host42 from host26 via ftp. The connection succeeds, and
> a network dump shows ESP from host42 to host26, but plain TCP packets
> in the other direction. These packets are accepted by host42 despite the
> -P in .../require policy which is essentially ignored. Thus, an attacker
> could inject spoofed packets into an ESP connection simply by omitting
> the IPsec elements. The same behaviour is observed when AH is used.
I've been trying to reproduce this. I thought I got it to "work" one
of the first tries, but I have not been able to do it since.
I have the same SAs set on both hosts. One host has the SPDs set, one
does not. I have tried TCP and UDP traffic. I cannot get the machine
with the SPD set up to accept the traffic. The appropriate SA misses
are recorded in the counters. I have tried:
- Loading up the SPD after a TCP connection was established and
then,
+ Sending more data from the SPD-less to SPD-ed host. The SPD-less
host does not accept any traffic.
+ Sending more data from the SPD-ed host to the SPD-less host. The
SPD-less host successfully processes the ESP-encapsulated TCP
packet and tries to ACK (in the clear), but the SPD-ed host does
not accept the cleartext ACK.
- Load of the SPD before trying TCP connections and then,
+ Attempt to connect from the SPD-less to the SPD-ed, but the
cleartext SYNs are dropped.
+ Attempt to connect from the SPD-ed host to the SPD-less. The
ESP-wrapped SYNs are SYN-ACKed (in the clear) by the SPD-less
host, but the SYN-ACKs are dropped.
I repeated this for AH. Here's an example setkey(8) input file,
# Flush databases.
flush;
spdflush;
# Security Policy Database
spdadd 192.168.64.70/32 192.168.64.50/32 any -P out
ipsec ah/transport//require;
spdadd 192.168.64.50/32 192.168.64.70/32 any -P in
ipsec ah/transport//require;
# Security Associations Database
add 192.168.64.70 192.168.64.50 ah 0x4321
-A hmac-sha1 "testkey1testkey2keys";
add 192.168.64.50 192.168.64.70 ah 0x1234
-A hmac-sha1 "testkey2testkey1keys";
And here's a portion of a packet capture where we're trying to
initiate a TCP connection (ssh(1)) over AH from an SPD-ed host to
SPD-less,
19:27:02.692097 192.168.64.50 > 192.168.64.70: AH(spi=0x00001234,sumlen=16,seq=0x6): 3784 > 22: S 3709471770:3709471770(0) win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 770286532[|tcp]> (DF) (ttl 64, id 54876, len 84)
19:27:02.692516 192.168.64.70.22 > 192.168.64.50.3784: S [tcp sum ok] 2467069692:2467069692(0) ack 3709471771 win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 33688331 770286532> (DF) (ttl 64, id 24074, len 60)
19:27:05.684765 192.168.64.70.22 > 192.168.64.50.3784: S [tcp sum ok] 2467069692:2467069692(0) ack 3709471771 win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 33688631 770286532> (DF) (ttl 64, id 24075, len 60)
19:27:05.686206 192.168.64.50 > 192.168.64.70: AH(spi=0x00001234,sumlen=16,seq=0x7): 3784 > 22: S 3709471770:3709471770(0) win 57344 <mss 1460,nop,wscale 0,nop,nop,timestamp 770286832[|tcp]> (DF) (ttl 64, id 54885, len 84)
Which shows the initial AH-wrapped SYN, the clear SYN-ACK response,
and retransmits from both since the SYN-ACKs get dropped by the
receiver.
Are you using the KAME IPsec (IPSEC and IPSEC_ESP) or the Fast IPsec
(FAST_IPSEC) implementation? These results were for the KAME IPsec.
--
Crist J. Clark | cjclark@alum.mit.edu
| cjclark@jhu.edu
http://people.freebsd.org/~cjc/ | cjc@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200310270410.h9R4A9vu009494>