Buffer overflow not properly patched

[aircrack-ng]

Reported by opensource on 1 Apr 2010 21:38 UTC

changeset:1676 seems not to address the recently discovered buffer overflow.

From the Fedora bug report: (Bug 577654 in Red Hat's Bugzilla)

• The code checks if the self-proclaimed size of the packet is larger than the real packet size. If the packet is larger than 256 bytes AND correctly tells about that, the heap will still be overwritten...
• The self-proclaimed size of the packet is compared to uninitialized data, resulting in random results
• They forgot to patch airbase-ng.c

[aircrack-ng]

Comment by misterx on 1 Apr 2010 21:38 UTC

Fixed now in cafc49c for aircrack-ng, airdecap-ng and airodump-ng and 9f16b51 for airbase-ng

[aircrack-ng]

Modified by misterx on 1 Apr 2010 21:38 UTC

[aircrack-ng]

Comment by opensource on 1 Apr 2010 21:38 UTC

Here is a comment from the original bug reporter claiming that the fix is not yet ok:
"""
I've only checked airodump-ng and as far as I can see the fix is incorrect as
the field "pkh.len" is uninitialized. It just happens to contain a value that
prevents the bug from getting triggered - this is left to a random value on the
stack however. It should read "caplen" instead of "pkh.len".

Why don't you just compare the promoted size of the EAPOL-frame to
"sizeof(wpa.eapol_frame)" ?
"""

[aircrack-ng]

Comment by clopez on 1 Apr 2010 21:38 UTC

Here are the relevant links:

• Bug report: https://bugzilla.redhat.com/show_bug.cgi?id=577654
• Blog post about the issue: https://pyrit.wordpress.com/2010/03/28/remote-exploit-against-aircrack-ng/

I have tested it with trunk (2002630):

svn co http://trac.aircrack-ng.org/svn/trunk/ aircrack-ng
cd aircrack-ng
make
wget http://pyrit.googlecode.com/svn/tags/opt/aircrackng_exploit.cap

$ aircrack-ng aircrackng_exploit.cap 
Opening aircrackng_exploit.cap
Read 1 packets.

   #  BSSID              ESSID                     Encryption

   1  00:DE:AD:C0:DE:00                            WPA (0 handshake)

Choosing first network as target.

Opening aircrackng_exploit.cap
Reading packets, please wait...

It keeps there forever and you have to hit CTR+C twice to make it stop :\

[aircrack-ng]

Comment by vanhoefm on 1 Apr 2010 21:38 UTC

Several tools are still vulnerable because it is not checked whether the .eapol_size is small enough. My patch fixes the vulnerability in several tools. Aircrack-ng ran forever because it did not release the mutex before reading the next packet. The WPA_hdsk structure was copied all over the codebase, and is now placed in eapol.h which is included by all tools.

I have a working exploit allowing arbitrary code execution when aircrack-ng loads a specially crafted .pcap file... Remote exploitation of other tools should also be possible. So please accept this patch!

[aircrack-ng]

Comment by misterx on 1 Apr 2010 21:38 UTC

Fixed in 3d140fe and d7e2399.