Nginx DNS resolver vulnerabilities allow cache poisoning attack

By injecting responses for server1.yourco.com, server2.yourco.com, you could MITM someone&#x27;s backend servers without leaving any traces, which is an even more serious concern if they&#x27;re terminating TLS at the NGINX server, which is a <i>very</i> common use case.<p>DJB has been warning against non-randomized port numbers for DNS resolvers for more than 15 years.[1] This is not a new issue.<p>NGINX&#x27;s response here is quite disheartening.<p>1. <a href="https:&#x2F;&#x2F;cr.yp.to&#x2F;djbdns&#x2F;forgery.html" rel="nofollow">https:&#x2F;&#x2F;cr.yp.to&#x2F;djbdns&#x2F;forgery.html</a>

This post is from last year, so I checked the nginx source to see if they had fixed things since then.<p>Nope! Still using ngx_random to generate packet IDs:<p><a href="http:&#x2F;&#x2F;hg.nginx.org&#x2F;nginx&#x2F;file&#x2F;tip&#x2F;src&#x2F;core&#x2F;ngx_resolver.c#l3740" rel="nofollow">http:&#x2F;&#x2F;hg.nginx.org&#x2F;nginx&#x2F;file&#x2F;tip&#x2F;src&#x2F;core&#x2F;ngx_resolver.c#l...</a><p>And ngx_random is still #defined to random:<p><a href="http:&#x2F;&#x2F;hg.nginx.org&#x2F;nginx&#x2F;file&#x2F;tip&#x2F;src&#x2F;core&#x2F;ngx_config.h#l57" rel="nofollow">http:&#x2F;&#x2F;hg.nginx.org&#x2F;nginx&#x2F;file&#x2F;tip&#x2F;src&#x2F;core&#x2F;ngx_config.h#l57</a>

This is something djbdns excelled at in it&#x27;s initial implementation. DJB, always impressive. These vulnerabilities don&#x27;t seem all that hard to fix. This also points out why DNSSec is so important IMO. I know many don&#x27;t see as much value in it, but it can be very useful for defending against inauthentic records. It&#x27;s a big reason why I&#x27;ve been working on TRust-DNS.<p>On a separate note; I&#x27;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:<p>randomized port (UDP only): <a href="https:&#x2F;&#x2F;github.com&#x2F;bluejekyll&#x2F;trust-dns&#x2F;blob&#x2F;master&#x2F;client&#x2F;src&#x2F;udp&#x2F;udp_stream.rs#L175" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;bluejekyll&#x2F;trust-dns&#x2F;blob&#x2F;master&#x2F;client&#x2F;s...</a><p>randomized msg id (TCP &amp; UDP): <a href="https:&#x2F;&#x2F;github.com&#x2F;bluejekyll&#x2F;trust-dns&#x2F;blob&#x2F;master&#x2F;client&#x2F;src&#x2F;client&#x2F;client_future.rs#L200" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;bluejekyll&#x2F;trust-dns&#x2F;blob&#x2F;master&#x2F;client&#x2F;s...</a>

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 &quot;these are configurations you <i>should not use</i>&quot; 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:<p>1. Switch off untrusted DNS (e.g. Google&#x27;s) regardless of any POC. Nginx views using these as insecure (fair enough), so they may decline to issue security advisories for <i>any</i> exploit that doing so allows (less fair).<p>2. In certain circumstances (1) is insufficient; the post details at least some of these. But you <i>need</i> to do (1) regardless.