Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Buffer overflow not properly patched #728

Closed
aircrack-ng opened this issue Mar 10, 2018 · 6 comments

Comments

Projects
None yet
1 participant
@aircrack-ng
Copy link
Owner

commented Mar 10, 2018

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 aircrack-ng added this to the 1.1 milestone Mar 10, 2018

@aircrack-ng

This comment has been minimized.

Copy link
Owner Author

commented Mar 10, 2018

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

This comment has been minimized.

Copy link
Owner Author

commented Mar 10, 2018

Modified by misterx on 1 Apr 2010 21:38 UTC

@aircrack-ng

This comment has been minimized.

Copy link
Owner Author

commented Mar 10, 2018

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 aircrack-ng reopened this Mar 10, 2018

@aircrack-ng

This comment has been minimized.

Copy link
Owner Author

commented Mar 10, 2018

Comment by clopez on 1 Apr 2010 21:38 UTC

Here are the relevant links:

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 aircrack-ng modified the milestones: 1.1, 1.2 Mar 10, 2018

@aircrack-ng

This comment has been minimized.

Copy link
Owner Author

commented Mar 10, 2018

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

This comment has been minimized.

Copy link
Owner Author

commented Mar 10, 2018

Comment by misterx on 1 Apr 2010 21:38 UTC

Fixed in 3d140fe and d7e2399.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.