
Not So Spooky: Linux “Ghost” Vulnerability - matsuu
http://blog.trendmicro.com/trendlabs-security-intelligence/not-so-spooky-linux-ghost-vulnerability/
======
gtrubetskoy
This article is misleading.

"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.

~~~
peterwwillis
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.

~~~
Karunamon
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.

~~~
peterwwillis
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.

~~~
Karunamon
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?

~~~
peterwwillis
_> 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.

------
hellbantest
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.

------
gaius
These days you get a scary name and a logo, and _then_ you find a bug to go
with it...

