Not So Spooky: Linux “Ghost” Vulnerability(blog.trendmicro.com)
blog.trendmicro.com
Not So Spooky: Linux “Ghost” Vulnerability
http://blog.trendmicro.com/trendlabs-security-intelligence/not-so-spooky-linux-ghost-vulnerability/
3 comments
It is not misleading in any way, actually. It accurately and factually reports the difficulties one has to grapple with in order to use this exploit successfully. It paints a picture of this exploit as being limited in scope, limited in execution, and limited in use, all of which are true.
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.
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.
Having your own DNS server is not substantially harder than having your own HTTP server. Get a domain, set up bind or similar (or a crocked variant thereof), make your domain authoritative for its subdomains, set up forward/reverse DNS on your bind server for a subdomain for an IP address, hit servers from that IP, anybody that resolves it gets pwned.
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.
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.
I think you missed where I said a resolver would not accept these exploit records. You can not set up your own DNS server and have a resolver pass your records on. You have to be the target's resolver or mitm it. Or do it locally.
I guess I'm confused about something, then.
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?
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?
> it has to make another query to the server mentioned
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.
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.
Basically, that's correct. of course a caching mechanism is always involved and that's the reason for 24 hour DNS propagation.
It really comes down to a few things, and everything else is just spin on them:
- 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
- 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
> Let's wait until someone figures this out or the POC exploit is made public.
The release included a POC against Exim (section 5 "exploitation" of the openwall post)
The release included a POC against Exim (section 5 "exploitation" of the openwall post)
The fact that the patch has been out since May 2013 doesn't help if few systems have it installed.
Qualys has developed a PoC that runs arbitrary code against a sample target.
Qualys has developed a PoC that runs arbitrary code against a sample target.
These days you get a scary name and a logo, and then you find a bug to go with it...
"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.