Products Openwall GNU/*/Linux   server OS Linux Kernel Runtime Guard John the Ripper   password cracker Free & Open Source for any platform in the cloud Pro for Linux Pro for macOS Wordlists   for password cracking passwdqc   policy enforcement Free & Open Source for Unix Pro for Windows (Active Directory) yescrypt   KDF & password hashing yespower   Proof-of-Work (PoW) crypt_blowfish   password hashing phpass   ditto in PHP tcb   better password shadowing Pluggable Authentication Modules scanlogd   port scan detector popa3d   tiny POP3 daemon blists   web interface to mailing lists msulogin   single user mode login php_mt_seed   mt_rand() cracker Services Publications Articles Presentations Resources Mailing lists Community wiki Source code repositories (GitHub) Source code repositories (CVSweb) File archive & mirrors How to verify digital signatures OVE IDs What's new

Date: Fri, 12 Sep 2014 17:14:55 +0400
From: Solar Designer <solar@...nwall.com>
To: oss-security@...ts.openwall.com
Cc: bert hubert <bert.hubert@...herlabs.nl>
Subject: PowerDNS Recursor 3.6.0 can be crashed remotely (CVE-2014-3614)

Hi,

A security advisory and a security update for PowerDNS Recursor were
posted on September 10:

http://blog.powerdns.com/2014/09/10/security-update-powerdns-recursor-3-6-1/
http://doc.powerdns.com/html/powerdns-advisory-2014-01.html

"Issue: A specific sequence of packets can crash PowerDNS Recursor 3.6.0 remotely
CVE: CVE-2014-3614
Affected: All deployments of PowerDNS Recursor 3.6.0
Not Affected: PowerDNS Authoritative Server, PowerDNS Recursor versions other than 3.6.0"

"There appears to be no way to use this crash for system compromise or
stack overflow."

Please refer to the URL above for much more detail, and a patch.
Looking at the patch, I see that one of the conditions it handles is
"labellen > 63", and it throws an exception when this happens.  It is
not clear to me whether or not arbitrary code execution is possible via
this vulnerability (via any of several issues that are now patched).
The pieces seen within the (very limited) context of the patch look like
the risk is there, and it'd take thorough analysis or a PoC to arrive at
either conclusion with confidence.

This issue was brought to the distros list at about the same time that
it was made public.  Per distros list policy, the issue must also be
brought to oss-security:

http://oss-security.openwall.org/wiki/mailing-lists/distros#how-to-use-the-lists

"When the security issue is finally to be made public, it is your (the
original reporter's) responsibility to post about it to oss-security"

Since the issue was already public on the same day, I think it should
have been posted to oss-security right away, without use of the distros
list.  (Any distro on the distros list is supposed to also be on
oss-security.)  The wiki page states this, too:

"Please only use these lists to report and discuss security issues that
are not yet public (but that are to be made public very soon - please
see below).  For security issues that are already public or that are to
be made public right away, please post to oss-security instead."

Even though formally it was not my responsibility to bring the issue to
oss-security, I apologize to the oss-security community for the two day
delay in doing so.

Alexander

Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.