Wi-Fi Software Security Bug, Could Leave Android, Windows, Linux Open to Attack

In an Email Today to the Open Source Software Security (Oss-Security) Mailing List, the Maintainer of Wireless Network Client Code Used by Android, the Linux and BSD Unix Operating Systems and Windows Wi-Fi Device Drivers Sent an Urgent Fix to a Flaw that Could Allow Attackers to Crash Devices or Even Potentially Inject Malicious Software into their Memory. The Flaw could Allow these Sorts of Attacks via a Malicious Wireless Peer-to-Peer Network Name. The Vulnerability was Discovered by the Security Team at Alibaba and Reported to wpa_supplicant Maintainer, Jouni Malinen, by the Google Security Team.


The Problem, Malinen Wrote, is in how wpa_supplicant "uses SSID information parsed from management frames that create or update P2P peer entries" in the List of Available Networks. The Vulnerability is Similar in Some Ways to the Heartbleed Vulnerability in that it Doesn't Properly Check the Length of Transmitted Data. But, unlike Heartbleed, which Let an Attacker Read Contents Out of Memory from Beyond What OpenSSL was Supposed to Allow, the wpa_supplicant Vulnerability Works Both Ways: it Could Expose Contents of Memory to an Attacker, or Allow the Attacker to Write New Data to Memory.


That's because the Code Fails to Check the Length of incoming SSID Information and Writes Information Beyond the Valid 32 Octets of Data to Memory Beyond the Range it was Allocated. SSID Information "is transmitted in an element that has a 8-bit length field and potential maximum payload length of 255 octets", Malinen Wrote. And the Code Wasn't Sufficiently Verifying the Payload Length on One of the Code Paths Using the SSID Received from a Peer Device. This Can Result in Copying Arbitrary Data from an Attacker to a Fixed Length Buffer of 32 Bytes (i.e., a Possible Overflow of Up to 223 Bytes). The Overflow Can Override a Couple of Variables in the Struct, including a Pointer that Gets Freed.


In Addition, about 150 Bytes (the Exact Length Depending on Architecture) Can be Written Beyond the End of the Heap Allocation. The End Result is that, an Attacker could Corrupt Information in Memory, Causing wpa_supplicant and Wi-Fi Service to Crash; a Crafted SSID could Essentially be Used as a Denial-of-Service Attack on Affected Devices Simply by Sending Out Responses to Wi-Fi Probe Requests or P2P Network Public Action Messages.


But, it Could also Expose Memory Contents during the 3-Way Handshake of a Peer-to-Peer Network Negotiation (the GO Negotiation) or Potentially Allow for the Attacker to Execute Code on the Target. For the Most Part, these Vulnerabilities are Difficult to Exploit if, the Target Isn't Actively Using P2P Wi-Fi Connections. While it's Possible that an "Evil SSID" could Cause Denial of Service without a P2P Network, the Greatest Security Risks involve Peer-to-Peer Activity. A Patch for the Bug has been Posted and Based on Google's Involvement, it will Likely be Part of an Android Security Update Shortly. However, the Distribution of that Fix, will Depend on Android Handset Manufacturers and Carriers to Reach End Users.




Info Source:

http://w1.fi/security/2015-1/wpa_supplicant-p2p-ssid-overflow.txt