{"vuid":"VU#183657","idnumber":"183657","name":"libspf2 DNS TXT record parsing buffer overflow","keywords":["libspf2","spam","dns","txt","spf","sender policy framework"],"overview":"libspf2 contains a buffer overflow vulnerability in code that parses DNS TXT records.","clean_desc":"libspf2 is a widely-deployed implementation of the Sender Policy Framework. According to RFC 4408: An SPF record is a DNS Resource Record (RR) that declares which hosts are, and are not, authorized to use a domain name for the \"HELO\" and \"MAIL FROM\" identities. Loosely, the record partitions all hosts into permitted and not-permitted sets (though some hosts might fall into neither category). libspf2 contins a buffer overflow in DNS TXT record parsing. According to Doxpara Research: DNS TXT records have long been a little tricky to parse, due to them containing two length fields. First, there is the length field of the record as a whole. Then, there is a sublength field, from 0 to 255, that describes the length of a particular character string inside the larger record. There is nothing that links the two values, and DNS servers to not themselves enforce sanity checks here. As such, there is always a risk that when receiving a DNS TXT record, the outer record length will be the amount allocated, but the inner length will be copied. This issue is similar to VU#814627 \"Sendmail vulnerable to buffer overflow when DNS map is specified using TXT records.\"","impact":"This vulnerability could allow an unauthenticated, remote attacker to execute arbitrary code on a system running libspf2.","resolution":"Upgrade\nVendors and those who directly use libspf2 should upgrade to version 1.2.8. Users that run a mail server or anti-spam products should consult their vendor for an appropriate patch.","workarounds":"","sysaffected":"","thanks":"This issue was reported by Dan Kaminsky of  \nDoxpara Research","author":"This document was written by Chris Taschner.","public":["http://www.ietf.org/rfc/rfc4408.txt","http://www.doxpara.com/?page_id=1256","http://www.libspf2.org/docs/html/"],"cveids":["CVE-2008-2469"],"certadvisory":"","uscerttechnicalalert":null,"datecreated":"2008-09-11T13:49:20Z","publicdate":"2008-10-21T00:00:00Z","datefirstpublished":"2008-10-30T12:43:00Z","dateupdated":"2011-07-22T12:49:09Z","revision":24,"vrda_d1_directreport":"1","vrda_d1_population":"2","vrda_d1_impact":"4","cam_widelyknown":"15","cam_exploitation":"0","cam_internetinfrastructure":"5","cam_population":"4","cam_impact":"20","cam_easeofexploitation":"15","cam_attackeraccessrequired":"20","cam_scorecurrent":"9","cam_scorecurrentwidelyknown":"11.25","cam_scorecurrentwidelyknownexploited":"20.25","ipprotocol":"tcp","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":9.0,"vulnote":null}