Not So Spooky: Linux “Ghost” Vulnerability
blog.trendmicro.com
blog.trendmicro.com
"First of all, this vulnerability has long been patched" - not true, it wasn't patched on RedHat and Debian until yesterday.
"many apps are not at risk" - so, what, nothing to worry about?
"the functions that are the subject of this vulnerability are obsolete" - obsolete they may be, but a ton of software still uses them.
"Taken together, the risk of actual exploits targeting GHOST is relatively small compared to other vulnerabilities like Shellshock or Heartbleed." - just because it is not widely known how to exploit this does not imply the risk is small. Let's wait until someone figures this out or the POC exploit is made public.
- Exposure: How many systems are affected and reachable
- Ease of exploit: What conditions need to be met after exposure to allow exploit
- Ease of patch: How hard it is to patch exposed and exploitable systems so they are no longer exploitable
The sentence after the first one you quote explicitly explains this sentence, so it is not misleading.
The author never alludes to the idea that "many apps are not at risk" equals "nothing to worry about". He links to an e-mail that describes a list of apps that are apparently not affected by the bug. In fact, the point at the beginning of the paragraph, "not all applications are at equal risk", very fairly summarizes his point.
The third point about obsolete functions is a minor one, but again, accurate and useful in lowering the scope of potential attack targets.
Finally, we know how to exploit this. Qualys is even going to release a metasploit module. And the risk is small not because we don't understand it, but because the risk is small, as has been pointed out many times in the article. It's been figured out. It's very simple, and it's not very useful. This article explains that.
--
What the article doesn't explicitly mention is the real silver bullet in the whole thing: you have to inject a DNS record into gethostbyname's buffer that is an invalid record. It's bigger than DNS records are allowed to be and uses invalid characters. So every DNS resolver and server in the world is going to ignore it. So the only way you can really exploit this reliably is by 1. hacking a DNS resolver used by a server, or 2. man-in-the-middle attacks. It is nearly impossible to use this attack on random targets on the internet.
Not counting DNS propagation delays, this is not even an hour of work. Heck, you wouldn't even need a noncompliant version of bind - sockets and your favorite scripting language could be set to return whatever DNS-looking replies you want.
My understanding of DNS is that you want to look up somesite.corp.com, your computer first goes to its configured resolver. Resolver returns what it knows about the domain you wanted.
If that information includes an NS record, it has to make another query to the server mentioned in that record to actually retrieve the information (since, say, 8.8.8.8 doesn't have their own records for the stuff somedomain.corp is authoritative for)
Is this incorrect?
Almost. It's the resolver making the query, not your client, and the resolver won't accept the bad records.
---
Your client application uses your host's DNS resolver library to query a DNS resolver for DNS records. It will only ask the configured resolver for records, and only receive them from the same configured resolver. So all records must go through your resolver. ('DNS resolver' = '8.8.8.8')
The resolver will do all the heavy lifting with external servers to find your records. Think of it as the 'gateway': if you are inside a network with no internet access, but you still want to resolve records (say, on a captive portal wifi network), some server needs to straddle your network and the internet to talk to internet-side DNS servers. The resolver does that work so your client doesn't have to, and can be on multiple networks, etc. (On a wifi network your resolver will probably be '192.168.1.1' or some other internal router/server)
So basically, your client [and its resolver library] will never ever talk to someone else's DNS server directly. So it won't talk to an 'evil' DNS server either. It will only talk to your 'good' resolver ("8.8.8.8"). And your 'good' resolver is checking to make sure the responses are valid, and truncating or dropping bad responses so you don't get them.
So no, you cannot just set up an evil DNS server and own random hosts. You need to be the resolver. But your IP probably isn't 8.8.8.8, so you will probably not be able to own random targets.
The release included a POC against Exim (section 5 "exploitation" of the openwall post)
Qualys has developed a PoC that runs arbitrary code against a sample target.