[Pdns-users] PowerDNS Security Advisory 2012-01: Denial of Service vulnerability in most versions of the PowerDNS Authoritative Server

bert hubert bert.hubert at netherlabs.nl
Tue Jan 10 17:42:12 UTC 2012


Yes, the freebsd maintainer was notified a few days ago and is working on it.

Secondly, the iptables command blocks incoming responses by matching packets with the QR bit in the fixed dnsheader set.

We tried to find a bsd equivalent command but failed to do so.

Sent from a phone, pardon my brevity!

 Charles Sprickman <spork at bway.net> wrote: 

Two quick questions for those of us not running Linux:

-Are you coordinating with the FreeBSD port maintainer to get the new version pushed out?  (http://www.freshports.org/dns/powerdns)
-For those of us unfamiliar with iptables, can you describe in a more generic fashion what that rule is accomplishing?

Thanks,

Charles

On Jan 10, 2012, at 9:01 AM, bert hubert wrote:

> Dear PowerDNS users,
> 
> It saddens us to have to release this Security Advisory, the first one since
> almost exactly two years ago.
> 
> Updated versions of the Authoritative Server are available from
> http://www.powerdns.com/content/downloads.html and you will find two
> workarounds and a patch below. 
> 
> A version of this announcement with clickable links is available from
> http://doc.powerdns.com/powerdns-advisory-2012-01.html
> 
> If you have problems upgrading and would like us to help you, please contact
> powerdns.support at netherlabs.nl for a support arrangement.
> 
> +-------------+---------------------------------------------------------------+
> |CVE          |CVE-2012-0206                        |
> +-------------+---------------------------------------------------------------+
> |Date         |10th of January 2012              |
> +-------------+---------------------------------------------------------------+
> |Credit       |Ray Morris of BetterCGI.com.                                   |
> +-------------+---------------------------------------------------------------+
> |Affects      |Most PowerDNS Authoritative Server versions < 3.0.1 (with the  |
> |             |exception of the just released 2.9.22.5)                       |
> +-------------+---------------------------------------------------------------+
> |Not affected |No versions of the PowerDNS Recursor ('pdns_recursor') are     |
> |             |affected.                                        |
> +-------------+---------------------------------------------------------------+
> |Severity     |High                                         |
> +-------------+---------------------------------------------------------------+
> |             |Using well crafted UDP packets, one or more PowerDNS servers   |
> |Impact       |could be made to enter a tight packet loop, causing temporary  |
> |             |denial of service                           |
> +-------------+---------------------------------------------------------------+
> |Exploit      |Proof of concept                     |
> +-------------+---------------------------------------------------------------+
> |Risk of      |                                                   |
> |system       |No                                            |
> |compromise   |                                           |
> +-------------+---------------------------------------------------------------+
> |Solution     |Upgrade to PowerDNS Recursor 2.9.22.5 or 3.0.1                 |
> +-------------+---------------------------------------------------------------+
> |Workaround   |Several, the easiest is setting: cache-ttl=0, which does have a|
> |             |performance impact. Please see below.                          |
> +-------------+---------------------------------------------------------------+
> 
> 
> Affected versions of the PowerDNS Authoritative Server can be made to
> respond to DNS responses, thus enabling an attacker to setup a packet loop
> between two PowerDNS servers, perpetually answering each other's answers. 
> In some scenarios, a server could also be made to talk to itself, achieving
> the same effect.
> 
> If enough bouncing traffic is generated, this will overwhelm the server or
> network and disrupt service.
> 
> As a workaround, if upgrading to a non-affected version is not possible,
> several options are available.  The issue is caused by the packet-cache,
> which can be disabled by setting 'cache-ttl=0', although this does incur a
> performance penalty.  This can be partially addressed by raising the
> query-cache-ttl to a (far) higher value.
> 
> Alternatively, on Linux systems with a working iptables setup, 'responses'
> sent to the PowerDNS Authoritative Server 'question' address can be blocked
> by issuing:
> 
> # iptables -I INPUT -p udp --dst $AUTHIP --dport 53 \! -f -m u32 --u32 "0>>22&0x3C at 8>>15&0x01=1" -j DROP
> 
> 
> If this command is used on a router or firewall, substitute FORWARD for INPUT.
> 
> To solve this issue, we recommend upgrading to the latest packages available
> for your system. Tarballs and new static builds (32/64bit, RPM/DEB) of 2.9.22.5
> and 3.0.1 have been uploaded to our download site. Kees Monshouwer has provided
> updated CentOS/RHEL packages in his repository. Debian, Fedora and SuSE should
> have packages available shortly after this announcement.
> 
> For those running custom PowerDNS versions, just applying this patch may be
> easier:
> 
> --- pdns/common_startup.cc   (revision 2326)
> +++ pdns/common_startup.cc   (working copy)
> @@ -253,7 +253,9 @@
>       numreceived4++;
>     else
>       numreceived6++;
> -
> +    if(P->d.qr)
> +      continue;
> +
>     S.ringAccount("queries", P->qdomain+"/"+P->qtype.getName());
>     S.ringAccount("remotes",P->getRemote());
>     if(logDNSQueries) {
> 
> It should apply cleanly to 3.0 and with little trouble to several older
> releases, including 2.9.22 and 2.9.21.
> 
> This bug resurfaced because over time,the check for 'not responding to
> responses' moved to the wrong place, allowing certain responses to be processed
> anyhow.
> 
> We would like to thank Ray Morris of BetterCGI.com for bringing this issue to
> our attention and Aki Tuomi for helping us reproduce the problem.
> 
> Kind regards,
> 
> Bert Hubert
> _______________________________________________
> Pdns-users mailing list
> Pdns-users at mailman.powerdns.com
> http://mailman.powerdns.com/mailman/listinfo/pdns-users


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.powerdns.com/pipermail/pdns-users/attachments/20120110/78e15a16/attachment-0001.html>


More information about the Pdns-users mailing list