Worm Threat Forces Apple To Disable Software?

SkiifGeek writes "After the debacle that surrounded the announcement and non-disclosure of a worm that targets OS X, the vulnerability in mDNSResponder may have forced Apple to remove support for certain mDNSResponder capabilities with the recently released Security Update 2007-007. 'Seeming to closely follow the information disclosed by InfoSec Sellout, Apple's mDNSResponder update addresses a vulnerability that can be exploited by an attacker on the local network to gain a denial of service or arbitrary code execution condition. Apple goes on to identify that the vulnerability that they are addressing exists within the support for UPnP IGD... and that an attacker can exploit the vulnerability through simply sending a crafted network packet across the network. With the crafted network packet triggering a buffer overflow, it passes control of the vulnerable system to the attacker. Rather than patching the vulnerability and retaining the capability, Apple has completely disabled support for UPnP IGD (though there is no information about whether it is only a temporary disablement until vulnerabilities can be addressed).'"

Comments

Hmmm...

[catdevnull]

Isn't mDNSResponder and Open Source package ported for OS X?

  http://developer.apple.com/opensource/internet/bon jour.html

Is Apple the developer of mDNSResponder or are they just using it?

At least they disabled it!

[Opportunist]

I mean, it was a given that, given increasing market share, Apple becomes interesting for malware. No system is 100% secure.

But at least they decided that it's better to disable the feature and minimize the damage to the net as a whole (and yes, even if you don't have an Apple, a worm damages you by clogging your tubes with packets trying to spread itself). MS decided that it's better to keep the insecure service up and running 'til it can be addressed.

Question for 100: Still getting sober/blaster packets? I do.

Re:Standard Operating Procedure?

[Rosyna]

I'm not opposed to temporarily disabling functionality to fix something potentially disastorous. There are three options when implementing UPnP:

1. Implement it to Microsoft's spec.
2. Implement it correctly (by choosing a direction in places the spec contradicts itself or real implementations).
3. Implement it securely.

Choose only one.

I do not think it is possible to implement UPnP securely and have it based on the spec. Also, the specific code they removed existed only for legacy NAT traversals and may not even be needed any more.

"additional validation" or "disabled support"

[czmax]

If you follow the link to the apple security update page there are actually two vulnerabilities associated with UPnP IGD. For one of them apple indicates that "this update addresses the issue by performing additional validation when processing UPnP protocol packets in iChat". For mDNSResponder apple indicates "this update addresses the issue by removing UPnP IGD support.

Clearly something is unclear since iChat is obviously still using UPnP IGD, likely as a client?

But why is the mDNSResponder using UPnP IGP anyway? mDNS is for service discovery etc and is basically a competitor to UPnP (I thought). Perhaps there is a way for mDNSResponder to leverage UPnP IGP to broadcast service messages (e.g. bonjour) across a local NAT? If so I've never seen nor heard of this working -- so perhaps what they're disabling is vulnerable code that wasn't doing anything anyway?

Re:Apple did the right thing

[Ash-Fox]

Apple is doing the right thing, here, folks!

Yes, because disabling support for the standard Internet Gateway Device support which software uses to seamlessly setup port forwarding on NAT systems etc. and having the user do it manually is good.

Many, many programs use IGD, from Instant Messengers to games.

Sorry, I cannot agree that it is the right thing.

Who wants to bet...

[subl33t]

... that the iPhone will be the vector that finally gets Macs infected with a virus/worm that will replicate in the wild?

I bet there's a secret cabal at Microsoft that is working on this very thing.

Now that Apple has disabled uPnP compatibility....

[argent]

Now that Apple has disabled uPnP compatibility will the original anonymous extortionist reveal the hole that he claims he didn't want to reveal lest Apple come up with some excuse for not disabling whatever his hole was, or will we hear more FUD from him?

Re:Standard Operating Procedure?

[Rosyna]

I call bullshit. You are saying it's not possible to implement UPnP without being vulnerable to a buffer overflow that may lead to remote code execution? Because that's one of the (at least) two issues at hand. Nice try on passing the responsibility for this bug to the spec writers (mentioning Microsoft seems to help too), Uhm, UPnP is a microsoft created and controlled spec, this is why I specifically mentioned Microsoft. Some people think it's not microsoft related because Microsoft hides their name from being easily found on the site (they do the same thing with the Zune). But, do a whois on upnp.org or look at many of the UPnP documents and you will see Microsoft's name plastered all over.

Can you show me an implementation of UPnP that hasn't had bugs? According to wikipedia security is a problem with the spec itself. It's getting so bad that some major router manufacturers are disabling the routing of UPnP packets by default on their non-consumer (and a few consumer) networking appliances.

And my list was more of a dig at OOXML rather than being security related.

Re:*Pulls out a plate 'o crow*

[fermion]

This is what should happen. Fix it, or remove the feature, or at least make it optional. This is what Apple normally does. It does not ship with all ports open and sharing on.

I hope this indicates a return to sensibility at Apple. Lately they are trying so hard to be like MS, that the security has suffered. Can't turn off HTML in email is at the top of my security vulnerabilities.