Description of problem: If a NULL UDP packet is sent to the avahi port 5353 it triggers and infinite loop with all the expected goodies, 100% CPU usage and DOS of avahi. This is due to the fix for bug 607297 ( https://bugzilla.redhat.com/show_bug.cgi?id=607297 ). You can re-open that bug and fix it with something that clears the null message from the socket before going to fail or you can keep this as a separate bug. Version-Release number of selected component (if applicable): all versions of avahi >0.6.24 Steps to Reproduce: Send a null UDP packet to avahi on port 5353. I personally use Scapy but anything will work. Actual results: Infinite loop. Expected results: Packet discarded. Additional info: In avahi_recv_dns_packet_ipv4 the bug fix: if (!ms) goto fail; Doesn't clear out a Null message from the socket before returning. This is reason for the infinite loop.
I have added this bug as a ticket to the avahi tracking system, #325. http://avahi.org/ticket/325
This has been fixed upstream now.
MITRE is calling CVE-2011-0634 a dupe of CVE-2011-1002.
CVE-2011-0634 was a candidate for this issue first but never added as an alias for this bug. Someone applied for CVE-2011-1002 recently and added it as an alias for the bug so I added the original CVE-2011-0634. I was going to release a test tool with a full-disc for this bug using CVE-2011-0634 but I wanted it patched first. I apologize for the confusion, in the future I will add the CVE right away.
Moving this bug to Security Response product, to properly track the issue.
Common Vulnerabilities and Exposures assigned an identifier CVE-2011-1002 to the following vulnerability: avahi-core/socket.c in avahi-daemon in Avahi before 0.6.29 allows remote attackers to cause a denial of service (infinite loop) via an empty (1) IPv4 or (2) IPv6 UDP packet to port 5353. NOTE: this vulnerability exists because of an incorrect fix for CVE-2010-2244. References: [1] http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-1002 [2] http://openwall.com/lists/oss-security/2011/02/18/1 [3] http://openwall.com/lists/oss-security/2011/02/18/4 [4] http://avahi.org/ticket/325 [5] http://git.0pointer.de/?p=avahi.git;a=commit;h=46109dfec75534fe270c0ab902576f685d5ab3a6 [6] http://www.securityfocus.com/bid/46446 [7] http://secunia.com/advisories/43361
As noted above, the CVE-2011-0634 identifier has been rejected with the following explanation: Name: CVE-2011-0634 Status: Candidate URL: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-0634 [Open URL] Final-Decision: Interim-Decision: Modified: Proposed: Assigned: 20110120 Category: ** REJECT ** DO NOT USE THIS CANDIDATE NUMBER. ConsultIDs: CVE-2011-1002. Reason: This candidate is a reservation duplicate of CVE-2011-1002. Notes: All CVE users should reference CVE-2011-1002 instead of this candidate. All references and descriptions in this candidate have been removed to prevent accidental usage.
This issue affects the versions of the avahi package, as shipped with Red Hat Enterprise Linux 5 and 6. -- This issue affects the versions of the avahi package, as shipped with Fedora release of 13 and 14. Please schedule an update.
Created avahi tracking bugs for this issue Affects: fedora-all [bug 679861]
Because avahi is used for local network broadcast messages (local network service discovery), it should be AV:A, not AV:N. It also is low impact, not moderate impact, as a result.
I'm going to keep this at impact=moderate to have a consistent rating with what was used for CVE-2010-2244, even though it's borderline issue. The fix is to be included in the already planned avahi updated in 6.1.
Upstream git commit, noted for future reference: http://git.0pointer.de/?p=avahi.git;a=commitdiff;h=46109dfec75534fe270c0ab902576f685d5ab3a6
This issue has been addressed in following products: Red Hat Enterprise Linux 5 Via RHSA-2011:0436 https://rhn.redhat.com/errata/RHSA-2011-0436.html
This issue has been addressed in following products: Red Hat Enterprise Linux 6 Via RHSA-2011:0779 https://rhn.redhat.com/errata/RHSA-2011-0779.html