| Summary: | net-dns/dnsmasq <2.45 DHCP lease renewal crash (CVE-2008-3350) | ||
|---|---|---|---|
| Product: | Gentoo Security | Reporter: | Justin Bellmor <justin> |
| Component: | Vulnerabilities | Assignee: | Gentoo Security <security> |
| Status: | RESOLVED FIXED | ||
| Severity: | minor | CC: | chutzpah, zoltarx |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| URL: | http://article.gmane.org/gmane.network.dns.dnsmasq.general/2189 | ||
| Whiteboard: | B3 [glsa] | ||
| Package list: | Runtime testing required: | --- | |
|
Description
Justin Bellmor
2008-07-20 23:22:01 UTC
Justin, do you have a reproducer for this issue? Either a client configuration, packet dump, or similar? Patrick, can you please bump the package? Snipped (and MAC address masked slightly) from my syslog: Jul 20 22:53:34 ansible dnsmasq[24246]: DHCPREQUEST(eth1) 10.0.2.4 00:21:e9:44:af:XX Jul 20 22:53:34 ansible dnsmasq[24246]: DHCPNAK(eth1) 10.0.2.4 00:21:e9:44:af:XX wrong address Jul 20 22:53:37 ansible dnsmasq[24246]: segfault at 10 ip 0805d69d sp bf8cc7e8 error 4 in dnsmasq[8048000+22000] Jul 20 22:53:37 ansible dnsmasq[24246]: DHCPDISCOVER(eth1) 00:21:e9:44:af:XX Jul 20 22:53:37 ansible dnsmasq[24246]: DHCPOFFER(eth1) 10.0.0.86 00:21:e9:44:af:XX Jul 20 22:53:37 ansible dnsmasq[24246]: DHCPREQUEST(eth1) 10.0.2.4 00:21:e9:44:af:XX Jul 20 22:53:37 ansible dnsmasq[24246]: DHCPNAK(eth1) 10.0.2.4 00:21:e9:44:af:XX wrong network I setup a NAT on my MacBook Pro (OS X) for the wireless and connected my iPhone to it, it was given a lease of 10.0.2.4. Then I connected to an AP on my dnsmasq-powered network and it attempts to acquire that lease (from a network range that dnsmasq doesn't deal with). dnsmasq isn't a fan and segfaults. My iPhone seems to be the client that triggers this most often, since it hops around so many networks throughout the day. If you'd really like my config file, let me know and I'll attach an unmangled copy, but I have some public IPs in there so I'm in no rush to publicize them. If you don't mind an altered configuration, I can just mask the public IPs. net-dns/dnsmasq-2.45 is now in the portage tree Arches, please test and mark stable: =net-dns/dnsmasq-2.45 Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86" Stable AMD64 keyword for 2.45; tested on hardened Opteron 2218 and Core 2 Duo systems. ppc64 stable Stable for HPPA. sparc stable alpha/ia64/x86 stable ppc stable This issue looks similar to CVE-2008-3214, which was assigned to dnsmasq 2.25. A reproducer created by Jamie Strandboge [1] for that older version will also crash 2.43. Earlier versions are unaffected, and so is 2.44. [1] http://thread.gmane.org/gmane.comp.security.oss.general/596/focus=635 GLSA vote: YES I have the same problem on gentoo hardened, and following lines in /var/log/grsec.log Jul 23 16:18:16 agryf grsec: signal 11 sent to /usr/sbin/dnsmasq[dnsmasq:25473] uid/euid:65534/65534 gid/egid:65534/65534, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0 Jul 24 05:12:15 agryf grsec: From 10.103.30.100: signal 11 sent to /usr/sbin/dnsmasq[dnsmasq:28201] uid/euid:65534/65534 gid/egid:65534/65534, parent /sbin/init[init:1] uid/euid:0/0 gid/egid:0/0 After moving to recent 2.45 version by simply renaming ebuild file :) problem seems to go away. http://freshmeat.net/projects/dnsmasq/?branch_id=1991&release_id=281597 Maybe 2.43 should be masked before 2.45 approval? Filip, it does not need to be masked since a later stable version is available. You should "emerge --sync" and update to that. Marking of a vulnerable version will be done via a GLSA and your local tools. CVE-2008-3350 (http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-3350): dnsmasq 2.43 allows remote attackers to cause a denial of service (daemon crash) by (1) sending a DHCPINFORM while lacking a DHCP lease, or (2) attempting to renew a nonexistent DHCP lease for an invalid subnet as an "unknown client," a different vulnerability than CVE-2008-3214. I'll take the lack of an answer as a YES and filed a request together with bug 231282. GLSA 200809-02 |
