DISQUS

Rosyna · 2 years ago

Oh wow, bugs in an UPnP implementation, such news... And people wonder why new routers/devices are starting to disable UPnP packet forwarding by default.

But also, where is all this news coming from? That blog has two posts and the only one contains any information. And that post only links to a security focus article that just links back the original bug. It seems like someone pranked Security Focus to see if they'd repost something with no actual information.

Finally, mDNSReponsder does not handle routable packets without significant setup on both sides. It also sets their TTL to 255 and if it's any less than that, it rejects the packet.

And as someone else mentioned, who has 1500 ICBMs on the same subnet? I didn't even know there were 1500 Mac users.

Drew Thaler · 2 years ago

Heh ... I know Mr. Cheshire a little bit, and it's clear that he was not happy about being told to revert a buffer-overflow bugfix. Apple's CCC (change control committee, or central change control, iirc) tends to err on the side of inertia, which can be enormously irritating.

You're absolutely right, that file is screaming out "sploit me! sploit me!", isn't it? :-)

Dino · 2 years ago

@Rosyna

Behavior as advertised and as implemented are often different things. I.e. the TTL check in mDNSResponder was removed in 2004 (going by the comments in the source code). It now checks that the packet came from the same subnet. But that's only for mDNS packets, not UPnP packets. That means that those nasties can come from anywhere.

Drew Thaler · 2 years ago

btw, like Rosyna, I found the claim of testing on a network of ~1500 Macs to be really odd. It sounds like a nice detail that you'd use to embellish a story and give it some real credibility, doesn't it?

But it represents a hardware investment of $1.5 million dollars at the bare, rock-bottom minimum. That's not even counting cabling, networking, and power. (Imagine a classroom lab with 30 machines. Now imagine 50 of those labs.) Sure, there are lots of places where there are probably more than 1500 machines on-site ... college campuses, large corporations, etc. But all on the same subnet???

Let's just say for the sake of argument that it's highly unlikely that you're going to find 1500 Macs on the same subnet anywhere. I think that's a fair statement. (I'd welcome counterexamples.)

From this there are two possible conclusions to be drawn:

(1) The claimed "worm" already hops subnets, even though the anonymous blogger who made the claim said that it didn't do that yet.
(2) The anonymous blogger who made the claim is full of shit and lying about the 1500 Macs.

I'd be more than ready to believe a credible worm against OSX -- after all, there's no particular reason that it's less vulnerable than anything else -- but this just smells fishy so far.

Thomas Ptacek · 2 years ago

It's a weird claim to make out of the blue. Who cares about exploit code written for an older vulnerability that isn't released in the wild, unless it really exists and demonstrates something?

ivan · 2 years ago

here we go again...since when claims on a blog post directly translate to proof of existence of a new bug? I do not believe, by any stretch of imagination, that mDNS is bug-free in fact, I've always suspected the opposite after briefly looking at the source code BUT...where are the details about this alleged bug? where is the source code for the exploit? where is the so-called worm? are we all going to make infosec decisions based on blog posts from random individuals with untestable claims? is this what the so called security 2.0 is all about?

notme · 2 years ago

i imagine why the blog is mildly credible is because a lot of people know just how many damn bugs there are in mdnsresponder.

Alfred Huger · 2 years ago

SecurityFocus has the 'issue' listed a single source report and the language is being adjusted right now to reflect some of the concerns around credibility. The reality it though that BID's are assigned to many, many issues which are just single source. It just so happens that this one is from a contentious source.

-al

HD · 2 years ago

There are no bugs here. Nothing to see, please move along. Whatever you do, don't look at the HTTP header parsing code, and absolutely ignore the fact that the structure used to store header entries is hard-coded to an array size of 30. Do not, under any circumstances, send more than 30 headers in a HTTP response.

@Rosyna: The entire LegacyNAT code uses a different port other than the standard mDNS listener. Thats how the "known" bug works too. To exploit these, either hit all ~40k possible UDP ports with your exploit or sniff the network to locate the correct one (hint: its source port of the M-SEARCH requests sent after a network change event).

What bugs me about mDNS is how much attention it has received and how little of the bugs have been found...

notme · 2 years ago

HD, why arent you dropping any of your 50 some odd bugs in mdns then?

notme · 2 years ago

Imy fifty number was taken from a comment of yours made when one of the sets of mdns patches came out)

HD · 2 years ago

The recent set of patches fixed a pile of them. The reason for "dropping" this one is to laugh at the folks performing the audits ;-)

Dino · 2 years ago

@HD: The LegacyNAT code listening UDP port always starts near 49000, so you really don't have to scan that many. OSX, like the other BSDs, follows some new convention that reserves range for ephemeral ports. You can also send a UPNP packet with a URL in it, so that when you hit the right port, mDNSResponder will do an HTTP GET on it, so you'll know when you've found the port.

Rosyna · 2 years ago

Looks like apple removed UPnP support from mDNSResponder in the latest security update. It's about freakin time. I really don't think it's *possible* to implement UPnP securely after seeing issues from every vendor that implements it.