2 
http://thehackernews.com/2017/06/linux-buffer-overflow-code.html
https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-9445

"that could allow remote attackers to potentially trigger a buffer overflow"

Can someone define "remote attacker"? Are we talking about a local network man-in-the-middle attack? Malicious ISP? Global (nation state) advisory? All of the above?

And how might this CVE effect VPN connections?

Improve this question

3 Answers 3

Reset to default
1

As this particular CVE requires a malicious DNS server, all of the attack vectors you detailed (MITM, Malicious ISP, etc) are possible attack vectors. Any party that is able to redirect your DNS traffic to a malicious server (or compromise the server you're currently using) can craft the responses detailed in these articles.

This affects VPN's in the case where your connections are resolving to a specific (compromised / malicious) DNS server they are, in theory, vulnerable to this type of attack. The VPN configuration would largely dictate their vulnerability as some VPN connections may choose to override the DNS server and not "inherit" it from the DHCP when they log into the VPN. With that said, the effect on VPN Connections will depend on the configuration.

Improve this answer
0

It depends when systemd-resolved is involved but let's imagine the following case:

I send you an email with a picture inside: http://myevilandswagsite.com/picture.png. Your local mail reader (Outlook, Thunderbird, etc.) will probably load the remote picture. To get the picture, it has to get the IP address of myevilandswagsite.com, so it will send DNS request to my evil DNS. My evil DNS will respond with a specially crafted response which exploit the buffer overflow.

So, the attacker can be "remote" without any restriction. Everytime I can drive you to resolve my DNS hostname, I can pown you. We can imagine that Google could take the full control of many machines by sending malicious answer to DNS queries everytime someone try to reach www.google.com

EDIT: I think to another old widespread attack. Because DNS requests are in UDP, you can try to emit many many DNS answers with the IP source of your choice (whatever, this is UDP). If your answer come before the real good one and is accepted by the host who make the request, it will use it.

So why not trying to send DNS response for www.google.com int he name of the real Google DNS and pray for they are accepted. In order to make them accepted, you need to guess the good UDP ID sequence and the good DNS query ID. If I correctly remember this is 65535*65535 possibilities but "hey, still better than lotery"

Improve this answer
1
  • On the final paragraph, things are now more complicated (more difficult for an attacker) due to the use of the 0x20 trick: as hostnames are case insensitive, the querier send the name with mixed case and expect the answerer to give back the same. See dyn.com/blog/use-of-bit-0x20-in-dns-labels Of course the true only solution to this attack is the use of DNSSEC.
    – Patrick Mevzek
    Jun 30, 2017 at 10:11
0

Maybe this helps you to judge the risk.

"Considering how well-confined the service runs (drops down to a normal user, has no actual devices in /dev, read-only filesystem, empty /home, syscall filtering and all the other goodies): I doubt that this is much of a threat in the wild."

https://www.reddit.com/r/netsec/comments/6k8c0l/cve20179445_outofbounds_write_in_systemdresolved/

Improve this answer

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .