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 > [email protected] 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@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 > [email protected] > http://mailman.powerdns.com/mailman/listinfo/pdns-users _______________________________________________ Pdns-users mailing list [email protected] http://mailman.powerdns.com/mailman/listinfo/pdns-users
