We can cause 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. I am 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. 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. Steps to Reproduce: 1. Get example file from "http://pyrit.googlecode.com/svn/tags/opt/aircrackng_exploit.cap"; or generate it via "http://pyrit.googlecode.com/svn/tags/opt/aircrackng_exploit.py"; 2. Run it through aircrack-ng, airdecap-ng or airodump-ng ("airodump-ng -r aircrackng_exploit.cap")
