
Nginx DNS resolver vulnerabilities allow cache poisoning attack - rodrigocoelho
http://blog.zorinaq.com/nginx-resolver-vulns/
======
jamiesonbecker
By injecting responses for server1.yourco.com, server2.yourco.com, you could
MITM someone's backend servers without leaving any traces, which is an even
more serious concern if they're terminating TLS at the NGINX server, which is
a _very_ common use case.

DJB has been warning against non-randomized port numbers for DNS resolvers for
more than 15 years.[1] This is not a new issue.

NGINX's response here is quite disheartening.

1\.
[https://cr.yp.to/djbdns/forgery.html](https://cr.yp.to/djbdns/forgery.html)

------
agwa
This post is from last year, so I checked the nginx source to see if they had
fixed things since then.

Nope! Still using ngx_random to generate packet IDs:

[http://hg.nginx.org/nginx/file/tip/src/core/ngx_resolver.c#l...](http://hg.nginx.org/nginx/file/tip/src/core/ngx_resolver.c#l3740)

And ngx_random is still #defined to random:

[http://hg.nginx.org/nginx/file/tip/src/core/ngx_config.h#l57](http://hg.nginx.org/nginx/file/tip/src/core/ngx_config.h#l57)

~~~
mrb
You are correct. They never fixed issues #2, #3, and #6 (as stated under
"Vendor response".) _Any_ half decent resolver properly randomizes both ports
and txid not using the predictable libc random(), but nginx developers have
staunchly refused to do so...

~~~
agwa
Thanks for posting this publicly!

I suggest updating your post to say that the issues are still unfixed as of
today's date.

~~~
mrb
Done.

------
bluejekyll
This is something djbdns excelled at in it's initial implementation. DJB,
always impressive. These vulnerabilities don't seem all that hard to fix. This
also points out why DNSSec is so important IMO. I know many don't see as much
value in it, but it can be very useful for defending against inauthentic
records. It's a big reason why I've been working on TRust-DNS.

On a separate note; I'd love feedback on these areas of my code if anyone
would care to... In TRust-DNS, at least to my best ability, I implemented them
in these two locations:

randomized port (UDP only): [https://github.com/bluejekyll/trust-
dns/blob/master/client/s...](https://github.com/bluejekyll/trust-
dns/blob/master/client/src/udp/udp_stream.rs#L175)

randomized msg id (TCP & UDP): [https://github.com/bluejekyll/trust-
dns/blob/master/client/s...](https://github.com/bluejekyll/trust-
dns/blob/master/client/src/client/client_future.rs#L200)

------
mnarayan01
The POC seems to require some semi-esoteric stuff. In the absence of a more
general exploit technique, it might be better to more explicitly say "these
are configurations you _should not use_ " than being as sweeping as this is
(as for some configurations it does look super-frightening). From reading
this, my impression is that there are two things people need to do:

1\. Switch off untrusted DNS (e.g. Google's) regardless of any POC. Nginx
views using these as insecure (fair enough), so they may decline to issue
security advisories for _any_ exploit that doing so allows (less fair).

2\. In certain circumstances (1) is insufficient; the post details at least
some of these. But you _need_ to do (1) regardless.

~~~
detaro
The first paragraph of the article says which configurations the author says
you should not use (and which the nginx team agrees with from the e-mails)?
I'm not sure a less sweeping recommendation would be good, especially since
the details can be seen as "esoteric" (and thus you should make sure to
understand them to judge a scenario more precisely)

~~~
mnarayan01
I think the post is great, just that its not really clear what users _need_ to
do going forward (unsurprisingly; that should really be on nginx). In
particular:

> Even pointing to a resolver on your internal local network may be a bad
> idea. Running a resolver on localhost is the only safe option.

In many cases, going to a localhost-only DNS is going to be _way_ more
complicated than getting off e.g. Google's open DNS, and thus conflating them
likely means way more people giving up and sitting on untrusted DNS.

