Remote-exploit against Aircrack-ng

I’ve just posted demonstration code for a remote-exploit against Aircrack-ng to the svn-repository. It causes aircrack-ng and airdecap-ng to crash when reading specially crafted dump-files and can also crash remote airodump-ng sessions by sending specially crafted packets over the air, kicking out those pesky folks who try to read our traffic. I am also 90% sure that this denial-of-service can be escalated to remote-code-execution by carefully introducing new stations to airodump-ng (for memory allocation) and then causing a heap corruption as demonstrated.

There an example dump-file here. It will do no harm to your computer ;-)

From the code’s comments:

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
which:
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.

About these ads

1 Comment(s)

Comments RSS TrackBack Identifier URI