The newest Version of mDNSResponder in the portage tree is 107.6 (from Mac OS 10.4), but version 212.1 (from Mac OS 10.6) is out already. Please update the application to a more recent version. Quite a few security-related issues have been fixed in newer versions! Reproducible: Always http://www.opensource.apple.com/tarballs/mDNSResponder/mDNSResponder-212.1.tar.gz
Daniel, thanks for the report. Could you please point us to an advisory or some other resource of information regarding the security issues? I can't find any right now.
(In reply to comment #1) > Could you please point us to an advisory or some > other resource of information regarding the security issues? All the source files contain descriptions of their revisions: mDNSPosix/Responder.c: "Potential buffer overflow in mDNSResponderPosix" mDNSCore/uDNS.c: Revision 1.409 2007/07/25 03:05:02 vazquez Fixes for: <rdar://problem/5338913> LegacyNATTraversal: UPnP heap overflow <rdar://problem/5338933> LegacyNATTraversal: UPnP stack buffer overflow and a myriad of other security problems Also have a look at: http://www.net-security.org/advisory.php?id=9270 "Impact: mDNSResponder is susceptible to DNS cache poisoning and may return forged information" Why is the version in the tree a couple of years old anyway?
Because noone from kde uses it anyway, we prefer avahi[+mdnsresponder-compat]. And when we spotted bugs about mdnsresponder and asked those reporters to actualy do some ebuild nobody did any work. So i might be even in favor of removal.
It's in RDEPEND/DEPEND in ~20 packages which use zeroconf or bonjour. I think removing it is not a good option right now. Quoting http://www.securiteam.com/securitynews/5FP032KMAW.html: "Vulnerable Systems: * Mac OS X version 10.4.10, Server and Workstation, with mDNSResponder version 108.5. Exploitation of this vulnerability allows an attacker to execute arbitrary code with root privileges on a vulnerable host. No authentication is needed to exploit this vulnerability. Failed attempts will result in the service crashing. Shortly after crashing, it will be restarted." We've got 107.6-r5 and I don't see CVE packports there. Let's bump to a new version...
+ 08 Nov 2009; Patrick Lauer <patrick@gentoo.org> + +mDNSResponder-212.1.ebuild: + Bump, fixes #290822 Not well tested, but at least this version seems to not fail like the 176.* did.
Thanks, patrick! Adjusting severity according to the gentoo vulnerability treatment guide. Arches, please test and mark stable: =net-misc/mDNSResponder-212.1 Target keywords : "alpha amd64 arm hppa ia64 ppc ppc64 s390 sh sparc x86"
x86 stable
Stable for HPPA.
alpha/arm/ia64/s390/sh/sparc
mdnsresponder code is here: http://svn.macosforge.org/repository/mDNSResponder/ git://git.macosforge.org/mDNSResponder.git Regarding the issues mentioned above. All but one are already covered by CVEs: == CVE-2008-3630 == impact: cache poisoning for windows: git: 691669439eb31cc559f5901dbe4edd934da6b21d for posix: git: 2948346b71b87c5d8ae5bca2074a5f663435fc55 git: 7835c9c18a70e721bae608b57eb0560ff94f5b65 (and previous) == CVE-2008-2326 == git: b10ec9ee04a68b9805b67699549f7df75397fe72 impact: crash Upstream claims this only affects windows. Code changes are in the core though. == CVE-2008-0989 == impact: code execution should only affect osx as mDNSResponderHelper is not built for posix == CVE-2007-3744 == impact: code execution git: 2b1d199002fb38635541fe34de4a366f767985d6 osx only / LEGACY_NAT_TRAVERSAL only == CVE-2007-3828 / CVE-2007-2386 == impact: code execution I do not know which commit fixed this bug, so it is hard to determine whether we are affected. == mDNSResponderPosix Buffer Overflow == While this is a buffer overflow, the input that is read from is a system configuration file given at program start. No trust boundaries are crossed here.
amd64 stable
ppc64 done
ppc stable
@security, could you please resolv this bug as all araches are done w/ stabilization?
@security Can we close this?
GLSA request filed.
This issue was resolved and addressed in GLSA 201201-05 at http://security.gentoo.org/glsa/glsa-201201-05.xml by GLSA coordinator Sean Amoss (ackle).
