{"vuid":"VU#209659","idnumber":"209659","name":"Unbound multiple denial-of-service vulnerabilities","keywords":["Unbound","CNAME"],"overview":"A specially crafted DNS query containing signed duplicate resource records or a malformed NSEC3 signed resource record may cause Unbound to crash.","clean_desc":"NLnetLabs advisory states: == Description 1: crash on signed duplicate Resource Records There are authoritative servers that erroneously send duplicated redirection Resource Records. Unbound has had a workaround that deals with this problem since version 1.0.1 whereby it ignores the duplicate answers. At the time, likely, no DNSSEC signed versions of such zones existed and only recently such misbehaving authority servers also started serving signed duplicate RRs causing improper memory allocation in a portion of the workaround code. Referencing this improper allocated data causes a crash which can look like 'uninitialised lock', segmentation faults or free() errors as it tries to free memory that was never allocated. == Description 2: crash on missing NSEC3 Resource Records. If an authority server sends a reply for an NSEC3-signed zone, and Unbound is configured to validate that zone, then a malformed response can trigger an assertion failure: when an authority server sends a response that contains RR types that trigger special processing and where part of the non-existence proof is missing then an assertion failure is triggered in unbound. This response case was observed in the wild on authority servers that host zones at different points in the hierarchy at the same time. The code crashes at assertion failure validator/val_nsec3.c:1214: nsec3_do_prove_nodata: assertion ce.nc_rrset failed Or, if assertions are not compiled it, it crashes soon after as it attempts to access an expected NSEC3 RR. Additional details can be found in the full NLnetLabs Unbound advisory.","impact":"A remote, unauthenticated attacker could cause the Unbound daemon to crash creating a denial-of-service condition.","resolution":"Apply an Update\nThis vulnerability has been addressed in Unbound 1.4.14 and 1.4.13p2. The following patch may also be applied to resolve the issue: For unbound version 1.4.0 - 1.4.13 the patch is: http://www.unbound.net/downloads/patch_CVE-2011-4528_unbound_140-1413.diff For unbound version 1.0.1 - 1.3.4 the patch is: http://www.unbound.net/downloads/patch_CVE-2011-4528_unbound_101-134.diff","workarounds":"","sysaffected":"","thanks":"This vulnerability was found by Christopher Olah and reported by NLnetLabs.","author":"This document was written by Michael Orlando.","public":["http://www.unbound.net/downloads/CVE-2011-4528.txt","http://www.unbound.net/download.html"],"cveids":["CVE-2011-4528"],"certadvisory":"","uscerttechnicalalert":null,"datecreated":"2011-12-14T14:12:26Z","publicdate":"2011-12-19T00:00:00Z","datefirstpublished":"2011-12-19T18:39:18Z","dateupdated":"2011-12-19T18:44:46Z","revision":16,"vrda_d1_directreport":"1","vrda_d1_population":"4","vrda_d1_impact":"3","cam_widelyknown":"8","cam_exploitation":"6","cam_internetinfrastructure":"10","cam_population":"10","cam_impact":"5","cam_easeofexploitation":"11","cam_attackeraccessrequired":"4","cam_scorecurrent":"0.99","cam_scorecurrentwidelyknown":"1.485","cam_scorecurrentwidelyknownexploited":"2.0625","ipprotocol":"","cvss_accessvector":"","cvss_accesscomplexity":"","cvss_authentication":null,"cvss_confidentialityimpact":"","cvss_integrityimpact":"","cvss_availabilityimpact":"","cvss_exploitablity":null,"cvss_remediationlevel":"","cvss_reportconfidence":"","cvss_collateraldamagepotential":"","cvss_targetdistribution":"","cvss_securityrequirementscr":"","cvss_securityrequirementsir":"","cvss_securityrequirementsar":"","cvss_basescore":"","cvss_basevector":"","cvss_temporalscore":"","cvss_environmentalscore":"","cvss_environmentalvector":"","metric":0.99,"vulnote":null}