mDNSResponder Tastes Like Burning

Dave G. | July 18th, 2007 | Filed Under: Apple

InfoSecSellout points us to new mDNSResponder flaw that is, as the vuln reasearch community likes to say, wormable. In fact, InfoSecSellout claims to have done just that.

Which, of course, got the folks at McAfee all riled up. They also have older version of InfoSecSellout’s post. They end their post with:

This story prove both things: the first is that Macintosh with Intel is an interesting target. Real outbreaks are more than ever possible. The second is that the lure of money motivates many people more or less scrupulous. It is another cause for concern.

The PowerPC vs. Intel debate is pretty useless. If you can write exploits on x86, ramping up on what you need to know to exploit vulns on PowerPC is trivial. At least, it was when I did it. It isn’t to say that there aren’t any differences, just that they don’t amount to much from a security perspective.

Of course, Intel vs. PPC is neither here nor there. This post is about mDNSResponder, otherwise known as the primary client -> server attack surface on Mac OS X. The firewall lets mDNS traffic through, and while it is unclear whether or not you can reach mDNS if you aren’t on the local subnet, it’s bad either way.

My favorite part of the source code is LegacyNATTraversal.c. Even the name just speaks of potential problems. Legacy… mmm. NATTraversal… mmm.

Other fun parts:

Revision 1.14.2.1 2005/12/12 17:38:40 cheshire Put buffer overflow bug 4151514 back in by order of Program CCC: “Program CCC Denied. This change does not meet the criteria for Chardonnay.”

…

Revision 1.13 2005/09/07 18:23:05 ksekar Off-by-one overflow in LegacyNATTraversal

…

Revision 1.9 2004/10/27 02:25:05 cheshire Random memory smashing bug

Lots of uPNP/SOAP message handling. Plenty of unbounded memory copies, and oh yeah, a history of overflows and memory smashing bugs. If I were guessing where mDNSResponder is going to have bugs, it’s in here. But it is nothing more than a guess.

If you want to run mDNSResponder without using the LegacyNATTraversal code, which might have nothing to do with the aforementioned mDNS worm/vuln, apply this patch, provided by Dino Dai Zovi.

Standard disclaimers about this patch apply (including: may do nothing, may protection you form current/future vulns, may cause mDNSresponder to not work, may break support contracts). Also, this patch is unsupported, which is why I didn’t give step by step instructions on how to apply it. Did I mention that this might have nothing to do with InfoSecSellout’s vuln? And that it could break things? and that we aren’t going to support it?

14 Comments so far

  • Rosyna

    July 18th, 2007 2:47 pm

    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

    July 18th, 2007 3:05 pm

    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

    July 18th, 2007 3:06 pm

    @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

    July 18th, 2007 3:23 pm

    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

    July 18th, 2007 4:11 pm

    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

    July 18th, 2007 11:53 pm

    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

    July 19th, 2007 4:14 am

    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

    July 19th, 2007 12:26 pm

    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

    July 21st, 2007 4:19 pm

    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

    July 21st, 2007 8:21 pm

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

  • notme

    July 21st, 2007 8:22 pm

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

  • HD

    July 22nd, 2007 7:53 pm

    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

    July 25th, 2007 12:30 pm

    @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

    August 1st, 2007 1:55 am

    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.

    • Leave a reply