The question I have is, in WPA2 session between the AP and client are DNS requests sent plain text?
Trying to wrap my head around the latest glibc exploit.
Information Security Stack Exchange is a question and answer site for information security professionals. It only takes a minute to sign up.Sign up to join this community
No, DNS requests are not sent in plaintext over the air between the access point and client device. All traffic between the two is encrypted according to the WPA2 spec using the supplied key, including DNS requests.
Once the encrypted traffic containing the DNS request is received by the AP, it is decrypted and can be examined, and it is at that point that the DNS request exists in plaintext again. It will then presumably be forwarded on to its destination via a wired connection, but not necessarily.
As far as how this relates to the recent glibc vulnerability, only a device that is connected to the network can possibly intercept or read DNS requests. A device must either be connected via a wired connection, or it must be able to authenticate with a wireless AP. WPA2, while not as easy to crack as WEP, is still crackable if the malicious device is listening when a valid handshake occurs. A handshake can be forced by sending out what's known as a "deauth frame". This forces devices in range to re-authenticate with the AP, which allows the attacker to capture the handshake. Once captured, the attacker can use this data from the handshake to crack the password. Depending on how much processing power they have and how secure your password is, this could take anywhere from a few minutes to a whole week. A week is a lot of time and energy to invest in cracking some random person's wifi (an attacker will likely move on to the person who has "pony123" as their password), so you can inoculate yourself against this kind of attack by choosing a secure wifi password (avoid dictionary words, use upper- and lowercase letters, use numbers, and maximize the length).
Once a malicious device has access to your network, it can potentially interfere with DNS requests and exploit the vulnerability in the glibc library.
What can you do about this? First, make sure all of your affected operating system instances are patched. Then make sure you aren't using any apps that are also affected. Any application that is statically linked to glibc will also need to be updated with the patched version. Dynamically-linked applications will be effectively "patched" when the OS is patched. You can also set your DNS server IP addresses manually (for example, use Google's 126.96.36.199 or Level3's 4.2.2.X range) which will cause your device to ignore DNS responses from spoofers (assuming they aren't also IP spoofing). And, obviously, choose a secure wifi password.