Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!

Full Text Bug Listing

dnsmasq 2.43 introduced a bug where an unknown client attempts to renew a lease
causing a segfault. This has potential security implications. A new version
upstream (and another for other issues) have been released to resolve this. One
of my clients keeps triggering this bug, so I've had to isolate it for the time
being.

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