Apple Clients Still Vulnerable After DNS Patch 94
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."
Re: (Score:1, Offtopic)
comment to remove accidental upmod
This exploitation, so far seems extremely unlikely (Score:5, Informative)
... the title is the start of the second paragraph. Perhaps Glen didn't read TFA...
From later on in TFA...
[sigh] even the article title is "DNS Clients Have Small Vector of Risk after Patch" ,,, where is the word 'small' in the /. title... ?
Simon.
Re:This exploitation, so far seems extremely unlik (Score:1, Insightful)
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
Re: (Score:3, Informative)
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.
Re:This exploitation, so far seems extremely unlik (Score:5, Insightful)
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!
Re: (Score:2, Insightful)
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".
Re: (Score:3, Insightful)
Until then these stories are just one big yawn.
Re: (Score:1)
The patch that isn't a patch, eh? (Score:1, Interesting)
I'm not sure I 'get' it!
Re:The patch that isn't a patch, eh? (Score:5, Insightful)
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.
My own DNS implementaion was never vulnerable (Score:5, Interesting)
I think one of the reasons MaraDNS [maradns.org] (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: (Score:3, Insightful)
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 longe
Re: (Score:2)
Re: (Score:2)
DNSSEC vs. IPv6, let's race 'em!
Re: (Score:2)
You know, the ISC should have fixed this issue in 2001.
ISC has nothing to do with the system stub resolver for MacOS.
Just Wait (Score:1, Funny)
Re: (Score:2, Funny)
Re: (Score:2)
What's the exposure? Where's the hole? (Score:5, Insightful)
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: (Score:3, Interesting)
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?
Oh, well, then you have bigger problems! (Score:4, Informative)
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: (Score:3, Insightful)
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: (Score:2)
Re: (Score:2)
Hmmm.
Note that Netinfo and lookupd no longer exist on Leopard, so I think your comments are either innaccurate, obsolute, or perhaps both :-)
Re: (Score:2)
While lookupd no longer exists, its functionality is part of the directory services cache. Nothing really has changed.
Re: (Score:2)
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
That would be a bug in Leopard. (Score:4, Insightful)
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.
Re: (Score:2)
O but as the article points out, Leopard clients are potentially exposed to a vulnerability that earlier OS X clients are not.
Re: (Score:2)
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: (Score:2)
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? (Score:5, Informative)
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.
Here's the difference (Score:2)
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 cli
Re: (Score:2)
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.
Re: (Score:2)
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: (Score:2)
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 what
Re: (Score:2)
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: (Score:2)
If it's just forwarding the requests to the ISP's server than it's not vulnerable to this issue.
Re: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
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: (Score:2)
Please read: http://www.us-cert.gov/cas/techalerts/TA08-190B.html [us-cert.gov]
Re: (Score:2)
Please read: http://www.us-cert.gov/cas/techalerts/TA08-190B.html [us-cert.gov]
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:
The message here is clear.. (Score:5, Funny)
I don't understand (Score:2)
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 (Score:5, Informative)
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: (Score:2)
Re: (Score:2)
Re: (Score:2)
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 ar
Re: (Score:2)
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
Already submitted (Score:5, Funny)
I already submitted this; unfortunately, since I was using a Mac, I submitted it to Paypal instead of slashdot.
Re: (Score:1)
All your base are belong to us
So basically, you are saying... (Score:3, Informative)
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: (Score:2)
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: (Score:2)
It is possible to snoop requests - no prediction necessary.
Re:So basically, you are saying... (Score:5, Informative)
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.
No Shit (Score:5, Insightful)
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.
I take exception to the assertion (Score:2)
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: (Score:2)
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)
Re: (Score:1, Informative)
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: (Score:2)
Are you a Republican?
So appearantly articles writers don't read TFA... (Score:3, Interesting)
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 (Score:1, Insightful)
Re: (Score:3, Interesting)
Only if you're referring to Kaminsky's blunder... (Score:3, Insightful)
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.
Rarer than hen's teeth... (Score:5, Informative)
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 (Score:1)
Don't worry (Score:1)
Re:Don't worry (Score:5, Insightful)
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.
Not to defend Apple, but they're not the only ones (Score:4, Interesting)
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!
Re:Not to defend Apple, but they're not the only o (Score:1)
...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: (Score:1, Interesting)
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
Re: (Score:2)
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".
Dirty fix (Score:1, Informative)
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.maco [macosxhints.com]
I'm pertty sure the same is true for Linux... (Score:2, Informative)
The resolver logic in glibc has the same problem. Full Disclosure: [SECURITY] [DSA 1605-1] DNS vulnerability impact on the libc stub resolver [seclists.org]
The only way around it is to configure a local caching DNS server.
Re: (Score:1)
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.
Still broken (Score:3, Informative)
Relax on Apple (Score:2)
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 [doxpara.com]
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! (Score:2)
As I noted in http://it.slashdot.org/comments.pl?sid=633511&cid=24441397 [slashdot.org] this is a non-issue. Also see .
wkcole's article http://it.slashdot.org/comments.pl?sid=633511&cid=24445481 [slashdot.org]
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