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=92 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=92s
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")