Apple Clients Still Vulnerable After DNS Patch

Glenn Fleishman sends word that SANS Institute testing indicates that, even after installing Apple's latest patch for the DNS vulnerability, Leopard desktops (not servers) are still vulnerable — or at least perpetuate risky behavior that makes exploitation easier. This matters because "With servers rapidly being patched worldwide, it's likely that the low-hanging fruit disappears, and vectors [will be] designed to attack massive numbers of clients on ISP networks."

Comments

This exploitation, so far seems extremely unlikely

[Space cowboy]

... the title is the start of the second paragraph. Perhaps Glen didn't read TFA...

From later on in TFA...

These clients pass their requests along, and it seems unlikely that they could be attacked directly unless an attacker had a computer on the same local network segment as the exposed system. In that case, the attacker would have a panoply of other network information poison available, and could disrupt DNS in a more efficient manner

[sigh] even the article title is "DNS Clients Have Small Vector of Risk after Patch" ,,, where is the word 'small' in the /. title... ?

Simon.

My own DNS implementaion was never vulnerable

[Ex-Linux-Fanboy]

You know, the ISC should have fixed this issue in 2001. This is an old known issue with DNS and DNS implementors who cared about security were never vulnerable to this particular hole.

I think one of the reasons MaraDNS (my own DNS server) is as good as it is is because I paid attention to DJB's writings. You know, a lot of people don't like DJB and his software is very polarizing. His confrontational behavior towards BIND and Sendmail was, at best, very unprofessional. I also don't like his dishonesty about the security issues both DjbDNS and Qmail have, pretending that these programs have no security problems. That is also fanboy behavior and not behavior a responsible software developer should have. The license was an issue for years, also; when the license was finally made reasonable late 2007 it has been too long to really develop a community of developers around either DjbDNS or Qmail (or Publicfile or...).

That said, he had some good ideas. The idea of randomizing both the query ID and the source port came from DJB and I implemented it in MaraDNS because I took the time to read what he had to say about DNS before implementing MaraDNS.

It is unfortunate that the bad blood between DJB and the BIND developers made it so BIND didn't implement source port randomization back in, say, 2001. It was known and a good idea then; it's essential today.

- Sam

Re:My own DNS implementaion was never vulnerable

[xrayspx]

Except that DJB and presumably Mara are likely both still susceptible to the original bug. Honestly, how hard is this to understand?

Source port randomization does NOT fix the fundamental flaw of being able to change existing records in a caching DNS server with glue fields. Source port randomization is simply a workaround to mitigate the risk by making someone guess two 16 bit numbers instead of only one (source port AND txid). The core flaw remains unfixed because it's going to take a whole lot longer than 6 months to get anyone to agree on how to proceed.

djb is much, much harder to exploit, but if he implemented the spec, he should be vulnerable to the main bug, though in all honesty I haven't seen anyone saying he is, or you are.

Re:My own DNS implementaion was never vulnerable

[wkcole]

You know, the ISC should have fixed this issue in 2001.

ISC has nothing to do with the system stub resolver for MacOS.

Re:My own DNS implementaion was never vulnerable

[TooMuchToDo]

The only real solution is DNSSEC, and hell will freeze over before that gets widely implemented.

Re:My own DNS implementaion was never vulnerable

[xrayspx]

That was pretty much the consensus from the webcast given by Dan Kaminsky et al. last week. That's why it was so critical to get a workaround in place to give them time to agree on how to go forward, hopefully with DNSSEC.

DNSSEC vs. IPv6, let's race 'em!

Just Wait

[segedunum]

Because it's the desktop they're trying to make this patch as pretty as possible, without sacrificing the innate beauty and usability of the system.

Re:Just Wait

[74nova]

I'll "just wait" until you use some grammar I can understand. I'm not kidding, I have no idea what you're trying to say.

Re:Just Wait

[segedunum]

Hmmmm. English not a first language for you and the mods then :-).

Re:This exploitation, so far seems extremely unlik

[Space cowboy]

Really ? Troll ? For pointing out that content *within* the article counters the sensationalism of the /. submission ?

Or is that one of those 'I hate Apple' moderations, or perhaps 'I disagree with your point of view' moderations ?

Hmm. Let me think...

Simon

What's the exposure? Where's the hole?

[argent]

Unless lookupd is doing something really weird, this is a non-issue.

Lookupd only talks to the nameservers specified by the settings in netinfo, provided by DHCP, and possibly flat files. Unless your immediate upstream nameserver isn't recursive (which is really stupid) or it is compromised there's no mechanism to get lookupd to query any other nameservers.

Which means that unless the attacker is on the local LAN there's no mechanism to see the queries.

And if he is then this is the least of your worries.

Re:What's the exposure? Where's the hole?

[AySz88]

Which means that unless the attacker is on the local LAN there's no mechanism to see the queries.

Out of curiosity, what about public Wi-Fi? Wouldn't people (normally) expect their https connection to their bank to be okay?

Re:What's the exposure? Where's the hole?

[CatOne]

Hmmm.

Note that Netinfo and lookupd no longer exist on Leopard, so I think your comments are either innaccurate, obsolute, or perhaps both :-)

Re:What's the exposure? Where's the hole?

[nsayer]

The issue is that if you're using your macbook at Starbucks, that local LAN you're on is suspect. Because lookupd implements caching, its cache can be poisoned, and I rather suspect that the stub resolver that lookupd uses probably isn't hardened (that is, doesn't use good source port randomization).

It'd be nice to be able to disable lookupd's caching for when you're on a less-than-fully-trusted network, but then the bigger attack vector would be the recursive resolver anyway.

Re:What's the exposure? Where's the hole?

[nsayer]

While lookupd no longer exists, its functionality is part of the directory services cache. Nothing really has changed.

Re:What's the exposure? Where's the hole?

[gatekeep]

The problem is this;
  How does lookupd really KNOW it's talking to it's upstream nameserver?

The answer is, because it's replies match the query info and the transaction ID, and come to the right port from the right IP.

Spoof the IP, brute force the transaction number, and get the client to perform lookups for names you already know, and you can convince it that YOU are the upstream server.

That's really no different than how this attack works against servers.

Re:What's the exposure? Where's the hole?

[leamanc]

One could say "nothing has really changed" in that an application makes an Internet lookup request, and the OS does its internal DNS lookup, passing it back to the application. But the internal plumbing of Leopard and previous versions of OS X are quite a bit different. It's quite unlike most other *nix'es out there, as out of the box, it's set to authenticate against an LDAP-style directory service, be it the local Directory Services node, an Apple Open Directory server, or Active Directory. (Note that this is different only because it's the default...we all know that other *nix'es can do this if so configured.)

Previous versions of OS X used NetInfo only for authentication purposes, and the standard lookupd process handled DNS requests and caching. Now it's all tied into Directory Services. To the end user, it may look and act the same, but as the article points out, Leopard clients are potentially exposed to a vulnerability that earlier OS X clients are not.

Re:What's the exposure? Where's the hole?

[argent]

The issue is that if you're using your macbook at Starbucks, that local LAN you're on is suspect.

If the local LAN is suspect you've already lost. That was proven when a bunch of fellows sniffed a bunch of security researcher's passwords on the Wifi at Usenix a while back.

Re:What's the exposure? Where's the hole?

[wkcole]

O but as the article points out, Leopard clients are potentially exposed to a vulnerability that earlier OS X clients are not.

1. The Fleishman article in TidBITS says no such thing.
2. The SANS article it references notes that Tiger behaves identically
3. The cited behavior does not in fact amount to a vulnerability that is any worse than the vulnerability of a fully-patched system of any other sort, because without access to the path between the client and its recursing nameserver, an attacker would still be left guessing both the port and transaction ID

Re:What's the exposure? Where's the hole?

[jhol13]

How about ADSL routers? A lot of ISP's advice to use automatic settings which means the router will behave as a DNS query router as well.

They are not fixed and most never will be.

So your machines in your LAN (behind NAT/firewall) should not rely on the DHCP information they get from the router, instead they should use ISP's DNS servers directly.

This is the advice CERT gives, anyway.

Re:What's the exposure? Where's the hole?

[KGIII]

If you were to whisper in your friend's ear in public in a code only you two thought you knew would you be 100% sure it was secure? Normal people might think so. Reality may be different.

Re:What's the exposure? Where's the hole?

[AySz88]

Er, that analogy doesn't really address my question - I was asking specifically about this vulnerability that GP says needs someone "on the local LAN".

Re:What's the exposure? Where's the hole?

[argent]

I'm not sure what you're getting at. I didn't say anything about HOW you should configure your DNS on your Mac, I merely pointed out that the client itself is not behaving like a recursive DNS server and thus is not exposed to this particular attack.

Changing the details of how the client DNS resolver selects ports and sequence numbers won't make any difference at all if your upstream is exposed.

But I would be surprised to see a recursive DNS server in a home firewall/router. Mine just provides via DHCP whatever it gets via DHCP from the ISP, rather than adding the substantial overhead of an additional and unnecessary application.

Re:What's the exposure? Where's the hole?

[jhol13]

I would be surprised to see a recursive DNS server in a home firewall/router.

Mine works that way (A-Link). Actually I think my old one did the same (Telewell).

I doubt it is really a full server, I think it is just a forwarder (does not cache any information locally, or at most very little).

Re:What's the exposure? Where's the hole?

[argent]

If it's just forwarding the requests to the ISP's server than it's not vulnerable to this issue.

Re:What's the exposure? Where's the hole?

[jhol13]

Why not?

If the attacker sends his reply before ISP then the (wrong) response will/can be accepted.

Just like with a caching server.

Re:What's the exposure? Where's the hole?

[argent]

If the resolver only contact's the ISP's nameserver, then the attacker can't make the resolver contact a nameserver he controls, so never sees a query, how is he supposed to predict any request so he can send the wrong response?

If the attacker *can* see a query, that means he's already in the path between the resolver and the nameserver, and he doesn't need to predict any queries, so the behavior of the resolver in selecting ports and sequence numbers is irrelevant.

Re:What's the exposure? Where's the hole?

[jhol13]

The same way as it does in the original attack. Nobody contacts any other resolver except those in /etc/resolv.conf as they are (almost always) recursive.

Re:What's the exposure? Where's the hole?

[argent]

The same way as it does in the original attack.

The original attack is not against a client resolver, it's against a recursive DNS server. If the upstream recursive DNS server is vulnerable, then you are vulnerable. If the upstream is not vulnerable, then you are not vulnerable. Whether the packets passing between your resolver and the upstream recursive server are using sequential or random ports and sequence numbers is irrelevant.

Re:What's the exposure? Where's the hole?

[jhol13]

Please read: http://www.us-cert.gov/cas/techalerts/TA08-190B.html

Re:What's the exposure? Where's the hole?

[argent]

Please read: http://www.us-cert.gov/cas/techalerts/TA08-190B.html

You're not answering the question, because unless the upstream resolver is not doing recursion the stub resolver will not issue queries that the attacker can see and so will not receive packets from the attacker:

Stub resolvers that will issue queries in response to attacker behavior, and may receive packets from an attacker, should be patched.

The message here is clear..

[Channard]

.. with the low hanging fruit disappearing, we should be wary of giraffe hackers. So if you see someone with an exceptionally long neckbeard, you should inform your local police.

Re:This exploitation, so far seems extremely unlik

[s.bots]

The title is completely true, the clients are still vulnerable; regardless of the reduced risk, there is the possibility of an attack. I don't really find the submission to be very sensationalist, simply stating that there is still a risk. Thanks for informing the /.ers that don't RTFA.

I don't understand

[Hatta]

I don't understand how I can be vulnerable to this if I'm not running a DNS server. No open ports means no one can get in, unless I connect to them. If the DNS server I connect to is secured, how can anyone compromise my machine this way?

Re:I don't understand

[stevied]

DNS generally runs over UDP, which works slightly differently to TCP. If you send a UDP packet out, and want a reply, you have to listen for that reply, which means you have an "open port", though in the case of DNS, hopefully only to your local network. TCP is connection based and will discard packets which do not appear to part of the connection; UDP isn't and therefore can't.

If someone can inject packets into your local network, they can try to spoof a reply to any queries you make to a recursive DNS server or forwarder (e.g. on your xDSL gateway device.) But if they can do this, you have more substantial security issues anyway. There might be something clever that could be done to attack people who've left their WiFi unsecured, but you'd still need to force them to generate multiple queries for unknown subdomains - perhaps a targetted HTML email with embedded IMG tags? Still sounds like too much work compared to emailing trojans to naive Windows users, unless you happen to work for the security services ..

Re:I don't understand

[springbox]

TCP isn't magic. You can run TCP over UDP if you really wanted to. If someone is trying to spoof UDP DNS responses to your system, they probably also have the resources to inject fake responses into a TCP stream.

Re:I don't understand

[stevied]

Well, yes, but for TCP you always have to guess 32 bits of sequence number, whereas for UDP spoofing control has to be implemented at the application layer level. In this case, DNS with sequential serial numbers, we're back to only 16 bits of TXID.

Re:I don't understand

[wkcole]

Well, yes, but for TCP you always have to guess 32 bits of sequence number, whereas for UDP spoofing control has to be implemented at the application layer level. In this case, DNS with sequential serial numbers, we're back to only 16 bits of TXID.

Plus 14 bits of port number (i.e. where in the 48k-64k range it is) and 32 bits of IP address. Really.

Think about it: if you have to guess at the transaction ID, that means that you are in a position where you can't see the stub resolver's queries, so you are also not seeing what IP those queries are being sent to or what source ports have been used. If an attacker can capture two stub resolver query packets (needed in order to know that they use sequential ports and know where in the 16k range they are currently) then that attacker should have no trouble capturing the query packet he actually wants to spoof a response to. In that circumstance there's need to guess at anything, there's only a need to reply faster than the real nameserver.

That is why Kaminsky, Vixie, and others have called this a flaw in the design of DNS. All anyone has ever needed to spoof a DNS reply is to see the query and answer fast. If an attacker knows what the query is, what nameserver IP it is directed at, and what IP+port the reply needs to go to, then there's only 16 bits of guesswork to do and that's not so hard. With a recursive resolver using a single port, an attacker can discover and deduce everything but the transaction ID without doing anything but getting the target to resolve some names, while that is simply not the case with a stub resolver.

Re:I don't understand

[stevied]

Plus 14 bits of port number (i.e. where in the 48k-64k range it is)

Oops, yes. My bad. Sequentially incrementing port numbers != predictable starting port. To be fair it was early and I was hung over ;-)

and 32 bits of IP address. Really.

Think about it: if you have to guess at the transaction ID, that means that you are in a position where you can't see the stub resolver's queries, so you are also not seeing what IP those queries are being sent to or what source ports have been used.

The IP address might be guessable. If you're going to the effort of targeting stub resolvers in the first place, it might not be too much extra effort to whois the IP address and guess the names of the ISP's caching resolvers. (The only situation I can really see this sort of effort being worthwhile is where, say, a particular ISP habitually supplies a particular gateway device, which turns out to have NAT/firewall flaws allowing packet injection into the local network.)

With a recursive resolver using a single port, an attacker can discover and deduce everything but the transaction ID without doing anything but getting the target to resolve some names, while that is simply not the case with a stub resolver.

I'm still not convinced it's impossible, but I'm pretty sure it wouldn't be worth making the effort. There are almost certainly bigger issues.

Regarding DNS design: short of net-wide DNSSEC rollout (ha! We'll see IPv6 transition first..), a medium-term approach might be to start with the assumption that we can't be 100% sure that any individual answer is genuine, but that we can be pretty sure that a sequence of successful spoofing attempts is extremely unlikely. How do we re-engineer caching resolver behaviour (caches are the key target, because of the cascade effect of a successful poisoning on end users) to minimize the amount of trust we place in a single reply packet?

Paul Vixie made some suggestions back in '95 (see 7.2: "What We Would Like To Fix .. Hierarchical Cache.") It might make sense to return additional RRs to the calling stub without caching them, but then setting up another request to grab those names, in order to prime the cache and so minimize network traffic, but at the same time not delaying the first requester's query by too long and only risking returning false information to one client.

I'll admit my grasp on this is a little fuzzy around the edges, I haven't had much experience with DNS guts in the past (I'm hoping Dan Kaminsky's explanation will include some analysis which might clear the waters for me.) The issue as far as I can see it is that the additional RRs, which were originally only needed to solve one specific problem (glue for zone delegation), have been used as a general mechanism to prime caches (e.g. when doing MX record lookups), and so nobody wants to tighten up the processing behaviour of the caching resolvers.

I don't know whether this sort of effort is worth it, a jump to DNSSEC might actually be simpler, and the source port randomization is a good fix for the moment. Network speeds will continue to get faster, however, and I'm sure some people will continue to put nameservers behind NATs that eliminate source port randomness. Also, flaws will presumably continue to be found in random number generators. A bit of further thought might be wise before the next issue crops up..

Already submitted

[rkanodia]

I already submitted this; unfortunately, since I was using a Mac, I submitted it to Paypal instead of slashdot.

Re:Already submitted

[Trull]

All your base are belong to us

So basically, you are saying...

[tlambert]

So basically, you are saying that using a protocol which tells you the port you are supposed to respond to requests on, it's possible to "guess" the port on which responses are expected?

Uh, if you are close enough to see the request, why do you not just use the response port in the request instead of guessing it from the last request?

I'm not understanding how this is any more vulnerable, unless you can predict requests.

Also, what do Windows and Linux boxes do?

-- Terry

Re:So basically, you are saying...

[stevied]

I suppose it might be of some use if combined with an exploit against a NAT device -- if you could coerce it into forwarding spoofed responses?

Even so, I don't know how long most stub resolvers cache answers (in memory). If at all, I thought it was a matter of seconds ..

Re:So basically, you are saying...

[Nom du Keyboard]

I'm not understanding how this is any more vulnerable, unless you can predict requests.

It is possible to snoop requests - no prediction necessary.

Re:So basically, you are saying...

[Todd Knarr]

Because you're racing against the real DNS server, trying to beat it to providing a response. It's a lot easier to do that if you can start sending your faked responses as soon as you know the target's going to be listening. If you have to wait to see the target's request, you're starting the race already behind by the amount of network latency between you and your target. But if you can guess from the first request what port's going to be used for the second, you can start sending faked responses as soon as you know the target's sent it's request (you don't need to see the actual request to predict that timing in a lot of cases).

It's like winning a drag race. If you can time the sequence of the lights on the starting pole you can get on the gas and start to release the brakes before the light goes green, timing it so you'll start moving when the light will have turned green. That gives you a big jump on the guy who waits for the light to go green before starting to shove the gas pedal down.

Can't they read?

[Anonymous Coward]

Apple clearly stated that they only patched the BIND name server, not the client libraries.

No Shit

[That's Unpossible!]

Since Apple themselves stated the patch was for BIND, and that only people running Mac OS X Server would likely benefit from it, I am not surprised that it didn't change the workings of the client.

Re:No Shit

[Anonymous Coward]

very true, so all that we can really take from this is that apple don't give a shit about all the client Mac's out there that are vulnerable. The usual apple sticking its head in the sand for security yet again.

Re:This exploitation, so far seems extremely unlik

[eggboard]

Um...I wrote the article, Space Cowboy? This article was revised after initially being posted as I received more information. Dan Kaminsky is the only one who currently knows the full scope of client weakness, but it's out there, so we revised our article to be clearer about the known knowns and the known unknowns!

The patch that isn't a patch, eh?

[Anonymous Coward]

So this is a patch. Sort of. It fixes some things, on some versions of the OS... but nothing significant.

I'm not sure I 'get' it!

Re:The patch that isn't a patch, eh?

[wkcole]

The Apple updates include a patched version of BIND for all 4 versions (standard and Server for both 10.4 and 10.5) but it is rather uncommon for non-server machines to be running BIND. Instead of having a local caching-only daemon running, they use the system's resolver library and the lookupd daemon that aggregates multiple name services and provides a unified cache (kinda like Solaris' nscd but not broken.) The system resolver uses ephemeral port numbers picked by the system for its DNS queries, and like all classic BSD systems, MacOS assigns ephemeral port numbers sequentially. This means that while Apple could have put port randomization into their libresolv, that would be a 2nd-rate solution. The right solution is to change the socket subsystem so that ports handed out when bind() is called with the port set to 0 are selected pseudo-randomly instead of sequentially. That change is easier said than done, and FreeBSD proved it a couple years ago. It looks like Apple decided not to push out that level of change fast or to hack up a temporary fix just for the resolver.

That's a perfectlyrational choice. The attack Kaminsky has described requires that the attacker trigger the target resolver to send DNS query packets to somewhere that the attacker can see them and hence find out the port number being used for queries. The canonical example of this is to have IMG tags on a web page pointing to a hostname resolved by a DNS server under the control of the attacker. That sort of approach is useless against the MacOS resolver, because it is a non-recursing stub. It only makes DNS queries to the recursive nameservers that it is configured to use, so it cannot be drawn into sending packets off to random bad guys for inspection. An attacker without a tap into the packet flow between the target and his nameservers has it just as hard as he would in attacking a patched nameserver. In addition, it may be that the lookupd cache that the stub resolver feeds may not be subtle enough to be vulnerable to the Kaminsky attack.

I take exception to the assertion

[bogaboga]

I take exception to the assertion that Apple's patch was installed.

What was installed was not a patch. If it were a patch, the problem it was supposed to fix would not be there.

I assert the following:

What was installed was [redundant] code to allegedly act as a patch to the vulnerability. Of course it worked as expected after all it was and still is redundant code. Let's get our English right.

Re:I take exception to the assertion

[Moridineas]

I don't think the definition of a software patch means a problem necessarily HAS to be solved. Afterall, even if ineffective, you're still patching new code/functionality/whatever into an existing program's binary or source code (think patching as in patching a quilt or clothes, etc, rather than as a bandage)

Late then broke then YAY!?

[Coolhand2120]

First Apple is late with the patch. Then the patch does not address the problem. And they do it again and again and again. Which is always met with great fanfare by Mac fans. Exhibit A is the first 50 posts here on slashdot. As long as Mac fans accept these BS patch fixes with a cheer, Apple will keep releasing patches that don't patch the probelm.

[sigh] even the article title is "DNS Clients Have Small Vector of Risk after Patch" ,,, where is the word 'small' in the /. title... ?

Unless lookupd is doing something really weird, this is a non-issue.

I don't understand how I can be vulnerable to this if I'm not running a DNS server. No open ports means no one can get in, unless I connect to them. If the DNS server I connect to is secured, how can anyone compromise my machine this way?

What it comes down to was Apple reported this patched fixed a problem that it did not fix. This means either they did not test the patch, incompetence, or they knew it didn't address the problem but told everyone it did, lies. All this defence of the indefensible makes people look like blithering idiots. If any company releases a patch that claims to patch something, then does not, that company deserves scorn, not this weak defence (oh it's not that bad!).

Re:Late then broke then YAY!?

[Anonymous Coward]

Apple fixed BIND. BIND ships with OS X (client, not server) but is not enabled by default. The patch rolled out to the client updated the - usually dormant - BIND in case someone manually enabled it.

Apple never claimed the patch rolled out addressed client issues. You can disagree with the fact that it didn't, but the problem that Apple did patch is indeed fixed, if late.

Re:Late then broke then YAY!?

[eclectic4]

Whoa, dude. You are wrong, and angry.

Are you a Republican?

So appearantly articles writers don't read TFA...

[Krelnor]

The advisory was issued against BIND.

Putting bad cache entries in a DNS server is bad for lots of people.

Apple fixed BIND (if a bit tardy).

End of story.

If you are in the position to spoof DNS responses, you don't have to wait for the SECOND request to feeding bad results, so whether or not the client ports are predictable isn't important. But there's no way you can make the client start asking your server for DNS results, and that's the known part of the vulnerability: Injecting foreign servers into the DNS system and giving them responsibility for things they shouldn't have.

Apple's Disgrace

[Nom du Keyboard]

This is an absolute disgrace for Apple. Admittedly the details of the hack were leaked out in the most stupid manner possible and the person who did it deserves to have their mousing hand cut off to prevent future such offenses, but there's simply no way for Apple to come out of this looking good and I'm very surprised at their laggardly ways regarding this issue.

Re:Apple's Disgrace

[Ash-Fox]

This is an absolute disgrace for Apple.

Not really, it's better than loads of other crap they've done.

Re:Apple's Disgrace

[Anonymous Coward]

Frankly I'm not surprised that this fell thru the cracks, considering how Apple raced to get the patch out the door. Seriously, Apple! Slow down. Check your work before releasing. /snark

Rarer than hen's teeth...

[Anonymous Coward]

Also, by default, BIND is disabled in OS X clients.

From Apple's security advisory:

"The Berkeley Internet Name Domain (BIND) server is distributed with Mac OS X, and is not enabled by default. When enabled, the BIND server provides translation between host names and IP addresses. A weakness in the DNS protocol may allow remote attackers to perform DNS cache poisoning attacks. As a result, systems that rely on the BIND server for DNS may receive forged information. This update addresses the issue by implementing source port randomization to improve resilience against cache poisoning attacks. For Mac OS X v10.4.11 systems, BIND is updated to version 9.3.5-P1. For Mac OS X v10.5.4 systems, BIND is updated to version 9.4.2-P1. Credit to Dan Kaminsky of IOActive for reporting this issue."

The original \. article (http://it.slashdot.org/article.pl?sid=08/08/01/1215209&tid=172) neglected to include the first few sentences of the above.

yawn

[Cyberfed]

I already had to go to my data center at 4 a.m. to patch all my servers thanks to this exploit. Slow news day..good to know I'm not part of the 'low hanging fruit' too bad my MacBook Pro is still "at risk", such...deep....fear... yawn..

Don't worry

[Ryan1984]

It's from Apple, it's secure from day four hundred eighty-One.

Re:Don't worry

[Overly Critical Guy]

It was secure from day one since BIND isn't enabled. Fancy that. It's almost like they purposely disabled it by default to be secure.

Re: Don't worry

[Anonymous Coward]

It's almost like they purposely disabled it by default to be secure.
No, it is nothing like that.

It is exactly like they didn't enable a service that almost no one was going to need or use to avoid support calls. Apple doesn't care much about security.

IMHO.

Re:This exploitation, so far seems extremely unlik

[Anonymous Coward]

Holy hell, is this a funny thread or what :)

Not to defend Apple, but they're not the only ones

[Anonymous Coward]

I'm no Apple fanboy (never had a Mac and likely never will), but I feel that I have to stand up for them here.

The author seems to have a personal vendetta against Apple here, since I'd guess most Linux clients are at least as vulnerable.

Let's see what's going on here: If your DNS server recurses and caches, then it will accept glue records and you really need to patch your server.
m
However, stub resolvers which ost clients use simply ask your local DNS server directly, which does all the recursing. As a result they will only accept responses from the local DNS server (which is probably harder to spoof in practice) and further more they probably won't (at least the Linux libc resolver doesn't) accept any additional records. In particular this means that the attack as currently described can't work - you only get one chance to spoof a response to a DNS query rather than as many as you like (and in practice you can't trigger a DNS query from a client whenever you like - they'd have to visit your website or similar). Essentially this new attack gives you nothing new when it comes to attacking clients (and as has been pointed out if you're on the same local network segment as your victim, then there are many other attacks to try). That said of course, we may not know the full extent of the attack found by Dan Kaminsky and he may also have found an awesome attack on stub resolvers. But he wants his glory at the BlackHat conference, so the rest of us have to sit in the dark hoping there isn't more to come!! Of course it's still recommended that stub resolvers are patched, although they don't need to be so urgently, so yes indeed Apple should release a complete patch as we don't know what other attacks may be possible, and we're better safe than sorry. But certainly it's not something to panic about. Panic about the large number of unpatched servers still out there!

But what really annoys my about this article is that it also applies to Linux. Take Debian Stable - a quick test shows that it actually uses a fixed port for its queries! They fully admit they haven't yet patched the glibc stub resolver yet (look up DSA 1605-1). In newer kernels (>=2.6.24) the glibc resolver uses an unspecified port, so it's essentially chosen by the kernel, so it is fixed. But any Linux system prior to this is probably still vulnerable.

I can't actually quite believe I'm posting this as a Debian fan, and Apple hater, but this sort of shoddy journalism really annoys me.

Yes Apple have been slow to patch this. Yes they should have done a complete job. But much as we might despise them, lets at least be fair about this!

Dirty fix

[Anonymous Coward]

Since Apple did patch the BIND server that comes with OS X client by default, but is disabled, you could work around this issue by enabling BIND and using localhost as the only DNS server.

To enable BIND, simply edit /System/Library/LaunchDaemons/org.isc.named.plist and change the 'Disabled' key from true to false (file is owned by root:wheel)

Generate the rndc key the default configuration is looking for and cannot start up without via 'rndc-confgen -a' with root privileges.

Follow the hint at http://www.macosxhints.com/article.php?story=20080725172011439 to configure the system to ignore all DNS settings handed out to it via DHCP, and statically configure 127.0.0.1 as a DNS source.

I'm pertty sure the same is true for Linux...

[bledri]

The resolver logic in glibc has the same problem. Full Disclosure: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver

The only way around it is to configure a local caching DNS server.

Re:I'm pertty sure the same is true for Linux...

[bledri]

Responding to self with more info...

My Ubuntu system uses a caching name server out of the box, so that's good. (Ubuntu is so magic I wasn't sure how it was configured...) I'm not sure about other distributions, but people should check their /etc/resovl.conf just in case.

Here's the difference

[argent]

Spoof the IP, brute force the transaction number, and get the client to perform lookups for names you already know, and you can convince it that YOU are the upstream server.

If you're in a position to read any transaction number from the client so you can brute-force the next one, you have to be able to sniff it anyway, and you don't NEED to brute-force it, you just need to be able to respond faster than the actual name server.

And since you're on the same LAN or at least closer to the nameserver than the client is, you're in a good position to do that.

The reason that this class of attack works against nameservers is that with a recursive nameserver you can get the nameserver to send you a packet that you can use to guess the sequence from. You can't do that with a client-only nameserver.

Re:Here's the difference

[gatekeep]

My point is that you don't need to sniff the transaction ID.. there's only 65536 possibilities, so by sending them all you can be sure you'll get it right.

And you could do it for a client-only nameserver as well, you just need to convince a client to make requests for you.

That would be a bug in Leopard.

[argent]

So you're saying that on Leopard the resolver ignores the DNS server settings you give it (regardless of how you give them to it, or what database it stores them in) and goes groveling around doing name resolution starting at a.root-servers.net and working down?

Because unless the client resolver does something daft like that (and, yes, that would be daft, and a bug in Leopard) the result is the same as if it was still using lookupd: the requests would have to be sniffed for a potential attacker to get a transaction or port number to use in the attack, and if the attacker is in a position to do that they don't need to predict the numbers, they just have to respond quicker than the real nameserver.

Oh, well, then you have bigger problems!

[argent]

If there's an attacker on the public wifi with you who can use this attack on you, then they have already used something like an ICMP redirect spoofing attack to get you using them as the upstream router, and they can see and modify every packet you send and receive... so they don't need to *guess* the magic numbers you're using: you're giving them to them anyway.

Re:Braiiiiiins

[Hes Nikke]

comment to remove accidental upmod

Re:This exploitation, so far seems extremely unlik

[konohitowa]

Agreed. I was afraid I might make it past more than 4 or 5 posts without the word Kaminsky in them. But I think a better title would have been "Kaminsky DNS Flaws Still Plague Apple".

Still broken

[deAtog]

Even though most of the affected servers have been patched, DNS is still broken. The patches thus far only make it slightly harder to exploit. Before the patches, you had a 1/(2^16) chance of guessing the sequence number. With the patches the likelihood of guessing the correct combination of port and sequence number has decreased to approximately 1/(2^32). Given there were reports that were reports of successful attacks in as little as 10 seconds, the patches only increase the time needed to approximately 10 minutes. With a fast enough internet connection, a successful attack could still take only minutes to succeed. DNSSEC or some other alternative may be the only way to avoid this issue completely.

Re:Still broken

[Anonymous Coward]

in as little as 10 seconds, the patches only increase the time needed to approximately 10 minutes

My math shows that if it takes 10 seconds now at a power of 16, that it will take over an hour with a power of 32.

Re:Still broken

[Anonymous Coward]

Even though most of the affected servers have been patched, DNS is still broken. The patches thus far only make it slightly harder to exploit. Before the patches, you had a 1/(2^16) chance of guessing the sequence number. With the patches the likelihood of guessing the correct combination of port and sequence number has decreased to approximately 1/(2^32). Given there were reports that were reports of successful attacks in as little as 10 seconds, the patches only increase the time needed to approximately 10 minutes. With a fast enough internet connection, a successful attack could still take only minutes to succeed. DNSSEC or some other alternative may be the only way to avoid this issue completely.

It's worse than that. In theory, adding a randomized source port adds 16 bits, but the attacking system can forge a reply to more than one port in parallel.

Send two packets to two random ports? Only 15 bits. Four packets? 14 bits. It's very broken.

Re:Still broken

[Anonymous Coward]

Wouldn't a 2^16 difference in probability translate to a difference of ~182 hours, not 10 minutes?

Only if you're referring to Kaminsky's blunder...

[sethstorm]

Admittedly the details of the hack were leaked out in the most stupid manner possible

That's what you get for waiting for a $1000+ convention to do so. A leak and some code for Metasploit.

Karmic justice for his secrecy.

Re:Not to defend Apple, but they're not the only o

[Trull]

...and its not like DNS should be run from a client PC anyway. This is a ISP/corporate WAN/LAN issue - nothing to do with end user machines. Would you use a mac as your gateway/dns? Apple has done the right thing, mostly.

Re:Not to defend Apple, but they're not the only o

[kayditty]

Both you and the grandparent are misinformed. All clients which are capable of resolving hostnames have a stub .. gasp .. resolver, which is what this is about. It has nothing to do with caching nameservers. The grandparent is wrong because the original attack requires user interaction in the first place.

The core of the vulnerability has been known for years and years, and was always possible. The new bit is just an interesting spin on it: reduce attack time by averaging over a number of sub-domain queries that you control (e.g. through a web page).

usage of tcpdump

[Anonymous Coward]

tcpdump | grep domain ???
pardon me?

Re:This exploitation, so far seems extremely unlik

[CountBrass]

Wake me up when *any* Mac actually gets taken over in the wild, or gets a virus or any other kind of malware that is specific to it (social engineering attacks for example don't count)

Until then these stories are just one big yawn.

Re:Not to defend Apple, but they're not the only o

[ruiner13]

m
However, stub resolvers which ost clients use simply ask your local DNS server directly...

I think you just had a hijacked DNS server relocate your "m".

Relax on Apple

[not_hylas( )]

Relax on Apple

"Apple fixed their server. There are scenarios in which the clients are vulnerable, but it's servers we need to worry about right now, and Apple did right by fixing their server."

DAN KAMINSKY

http://www.doxpara.com/?p=1198

Check your DNS there too.

Your name server, at 001.02.03.04, appears to be safe, but make sure the ports listed below aren't following an obvious pattern (:1001, :1002, :1003, or :30000, :30020, :30100...).

Click on the last period in his post (eggish) :-)

FALSE ALARM, RED HERRING, NOT AN ISSUE!

[argent]

As I noted in http://it.slashdot.org/comments.pl?sid=633511&cid=24441397 this is a non-issue. Also see
wkcole's article http://it.slashdot.org/comments.pl?sid=633511&cid=24445481 .

Unless the code is doing a full DNS lookup, rather than requesting a lookup from a recursive nameserver, there is no mechanism for a hostile nameserver to receive any packets from the local resolver to guess at the port and sequence number. It does not seem that the local resolver in Tiger or Leopard behaves that way... nor does the local resolver in Linux, nor does the local resolver in Windows, to address some other comments I have seen here and elsewhere.

Re:This exploitation, so far seems extremely unlik

[bluesk1d]

How about the brand new, fully patched up-to-date Macbook Air at this year's pwn-to-own contest a couple months ago? Oh noes! It was the first to be compromised. http://dvlabs.tippingpoint.com/blog/2008/03/27/day-two-of-cansecwest-pwn-to-own---we-have-our-first-official-winner-with-picture