How serious for OS X clients?
What percentage of OS X clients run with BIND enabled, I wonder...
Apple was widely skewered for being among the last to fix a gaping security hole in the net's address lookup system that could allow the wholesale hijacking of users' internet connections. And now that the company has finally got around to issuing a patch, there's just one problem: it doesn't work on client versions of Mac OS X …
Seems to me that BIND is the most up to date version. What gives?
"DNS server included in Mac OS X. BIND is updated to version 9.4.2-P1, the same version that was recommended by TidBITS's Glenn Fleishman"
"This again is pointless bashing of Apple when theres no need for it."
This again is pointless fanboi'ism of Apple when there's no need for it.
This is a serious security hole. OSX client ships with BIND. The BIND patch has been out since day one, and is dead simple to apply. Therefore, Apple is ridiculous after taking SOOO LONG to release a patch, not even releasing it for all instanced of BIND they are shipping.
This has nothing to do with running a DNS server on a Mac, the DNS client (which is in use in ALL Macs to resolve hostnames) is vulnerable to the issue. All DNS clients cache information, just like caching nameservers do, so the attack can be performed against DNS clients just like caching nameservers.
A lot of people missed the fact that both clients and caching nameservers were vulnerable. The fact Apple didn't bother to patch the client means that your individual DNS resolver (client) cache can be poisoned, an attack that is much more likely to be successful than a busy nameserver.
Whether one would or would not run BIND on a system running Mac OS X depends on how you use your system. I use mine as a workstation and a server for my network.
There's little need to install Mac OS X Server on the system unless you are using Open Directory or are uncomfortable with a BSD Unix environment. After using BIND for 30 years, I'm reasonable comfortable configuring and using BIND.
BIND 9.4.2-P1 distributed in Security Update 2008-005 is the standard version distributed by the Internet Systems Consortium. The randomness of ports used in DNS queries is similar to that of any other system upgraded to BIND 9.4.2-P1.
I don't recall anyone other than Microsoft issuing a patch for their DNS resolver routines but I suspect that Microsoft couldn't change its DNS Service without change their DNS resolver routines. Sun certainly didn't. They didn't even change the BIND version in the source or binaries.
I'm not sure what these researchers were testing. Besides, if your service provider hasn't upgraded his name server, it doesn't make any difference whether or not your DNS resolver routines have been patched. Your resolver cache will be poisoned regardless of how random the ports used for your DNS queries are.
"Given the ultra-insular culture at Apple, it's hard to know why engineers chose to patch some Mac versions and not others. It's possible they reckoned clients handle so few DNS queries that it didn't make sense. Or they may have overlooked it."
When the nameserver runs in "forwarder" mode, i.e. it forwards all requests to a single "real" server, it is not vulnerable to the cache poisoning attack. Desktop systems are pretty much always set up this way, so they are not actually vulnerable => no need to hurry with the update.
The researcher either has overlooked that, or was misunderstood.
"It's not likely we'll find out why clients remain vulnerable to one of the most critical security bugs to come around in years. Apple representatives haven't answered a single one of our security-related queries in more than 18 months."
Well, hey.... it's probably smart not to answer questions from people not equipped to understand the answers. Avoids getting into a fight with a tar-baby.
Simply put, Mac clients don't run BIND by default. No reason they should. Yes, it's there (along with lots and lots of standard UNIX stuff) and it can be switched in. But only by command-line jockeys who, presumably, know what they're doing. You need to understand launchd and how to edit its associated plist. If you know all that, it's a fair guess you're up to speed with the BIND vulnerabilities, and know where to get a recent patched version, if you haven't already received the latest update from Apple.
I would downgrade this threat level from HYSTERICAL!!! to huh?.
Hope this helps.
Wow, the fanbois are out in force on these comments. I have never seen a company so defended by paying customers, especially when the defences would be arguments that even MS wouldn't have used defending some glaring fuck-up in Windows 98!
The defences are full of assumptions, like the user will know about blah blah if he was doing blah blah, assumptions that a computer capable of doing a server role wouldn't be used as a server. And worst of all an assumption that an individual machine wouldn't be attacked. Now that is naive! What is the fewest machines that would ever get attacked, oh mighty craxx0r?
People on this thread have been smelling their own shit too much. Yes, some of the Mac's security comes from its smaller market presence, but a good chunk comes from superior design. If the owners of macs don't keep the pressure up on Apple to keep the software secure, eventually business pressures will mean costly-to-the-user mistakes will happen. Apple's business is still selling proprietary computing platforms.
And if the article isn't clear, maybe reading the linked articles will help?
Merton Campbell Crocket says "After using BIND for 30 years, I'm reasonable comfortable configuring and using BIND." This is bollocks. BIND didn't exist 30 years ago. The core DNS protocol spec wasn't published until November 1987. So the first versions of BIND wouldn't have been available until around then. The only way someone could have 30 years of BIND experience will be if they can do time travel.
"Anyone stupid enough to pay good money for a crappy proprietary GNU/Linux clone deserves everything they get. Apple only exist because tasteless fools think 70's futuristic is a neato look."
Sounds like you spend your life looking for Apple stories on here just to troll. Get a life - nobody cares what you think, even less so when you don't even back up your stupid comments.
Whether the client responds to external requests is irrelevant, by definition it must listen for answers to the queries it sends, if it does that and has a cache and doesn't randomize its ports then its vulnerable. This is why MS released patches for both the server and the client, that said I'm not 100% sure there is a local cache on osx clients is there?
"Who in their right mind would run a DNS server off the client version of OS X??"
Ever heard of Rendezvous?
From the paedia:
"Bonjour, formerly Rendezvous, is Apple Inc.'s trade name for its implementation of Zeroconf, a service discovery protocol. Bonjour locates devices such as printers, as well as other computers, and the services that those devices offer on a local network using multicast Domain Name System service records. The software is built into Apple's Mac OS X operating system from version 10.2 onwards, and can be installed onto computers using Microsoft Windows operating systems (it is installed with iTunes, for example)."
"Currently it is used by Mac OS X and on other operating systems to find printers and file sharing servers. It is also used by iTunes to find shared music, iPhoto to find shared photos, iChat, Adobe Creative Suite 3, Proteus, Adium, Fire, Pidgin, Skype, and the Gizmo Project to find other users on the local network, TiVo Desktop to find digital video recorders and shared media libraries, SubEthaEdit and e to find document collaborators, and Contactizer to find and share contacts, tasks and events information. Additionally it is used by Safari to find local web servers and configuration pages for local devices, and by Asterisk to advertise telephone services along with configuration parameters to VoIP phones and dialers. Software such as Bonjour Browser or iStumbler can be used to view all services declared by these applications and more."
The heart of Apple's networking philosophy is to run a souped-up DNS server on every machine.
I don't think Rendezvous would be an issue w.r.t. this DNS bug, but to say that Mac OS X does not or need not run a DNS server is incorrect.
Linux is just the kernel and OS X uses a Mach kernel. GNU/Linux is a type of "Unix-like" distribution ... in which case OS X is a GNU/BSD[Darwin]/Mach type of "Unix-like" distribution.
Apple is the repository for OS X updates unless you manually install GNU/OSS applications yourself. As with all non-free OS's updates usually lag behind the OSS equivalent .. just like Sun, HP, IBM, Microsoft etc. If you are using/providing Internet-facing services the best approach is usually to install the OSS de-facto standard version and upgrade that as soon as possible (having tested the patches first obviously 8-).
"The DNS cache on your computer doesn't respond to external requests. Please enlighten me as to how this can be attacked, or why someone would bother targeting a single machine."
You would target a single client if you just wanted to attack a single person. The attack scenario is a little different, but it will still work.
@ Eddie Edwards
First of all, your information is at least 2 years out of date because Apple settled a dispute over the name "Rendezvous" with TIPCO as a result of which Apple changed the name to "Bonjour". Any material that quotes "Rendezvous" is at least two years old. Way to go.
Furthermore, that "souped up" name server you are talking about, the one which provides the Bonjour features, well it is NOT BASED ON BIND. Instead it is called DNSResponder, a server developed by Apple.
BIND does not run on OSX clients.
Frankly why is it necessary in the days of broadband/ethernet for client workstations to cache lookups at all as in some cases I've found it causes pages/servers not to be found because the record in the cache is stale and so does not resolve.
Only nameservers should need to cache anything.
Nice to see the disciples of Jobs are out in force as usual though, muppets.
Mine's the leather one with the rotten Apple on the back.
Just how stupid can you get? I read a lot of stuff like "it ain't a DNS server so no need to patch" and "noone will attack a single machine". Yeah, right. Though the first assumption is correct from my point of view (I don't own a mac, so I don't care if Apple fixes its client, it won't disrupt *my* intartubes), the second is just plain idiotic. A botnet is precisely a collection of million+ compromised individual machines.
So you mac users should really put some pressure on Mr Jobs and Co. to get a patch for your client.
I got a Mac not too long ago, but thanks to this flawed and late response to what could be the exploit of the decade the honeymoon is over. OS X has an excellent design, many of the security checkboxes are checked, but even though it's Unix(r) it needs to get security updates or it *will* have security flaws. Security through obscurity is no excuse for this one, it is an attack that, in automated form, does not distinguish between operating systems.
Anonymous Coward, my apologies I should have said 25 years or, perhaps, a quarter of a century.
BIND was included in the 1983 Berkeley Software Distribution of Unix for the DARPA community. It wasn't quite ready for prime time. The ARPANET was scheduled to switch from host tables to the Domain Name System in 1984.
RFC 881, 882, and 883 defined the Domain Name System and its deployment schedule. They were published in 1983 and based on operational code as was the IETF practice at the time.
Ahh, the good old days before the riff-raff were allowed to connect. Wasn't a lot of spam when your high speed links were 19.2 Kb/s.
Yeah seriously guys... Whether you love Apple or not, stuff like this needs fixing FAST and you should pressure Apple in to fixing security holes as quickly as possible. A lot of the reason Macs don't get "hacked" as much as Windows based platforms is that it isn't as popular - A hacker writing hacks specifically for Windows has a very many more potential targets. Occasionally that type of "defence" won't work, as in this case where BIND is used on many platforms.
Actually, BIND was written under a DARPA grant in the early 1980's, so it really is nearly 30 years from then. Maybe a slight exaggeration on the part of the original commenter but not as inaccurate as yours. Early suggests PRE-1985, which gives us an absolute minimum of 23 years prior, and a maximum of 28.
"Actually, BIND was written under a DARPA grant in the early 1980's, so it really is nearly 30 years from then. Maybe a slight exaggeration on the part of the original commenter but not as inaccurate as yours. Early suggests PRE-1985, which gives us an absolute minimum of 23 years prior, and a maximum of 28."
i think the original poster was right. rfc1035 came out in november 1987. even though rfc883 was published 4 years earlier. bind was not included with the 4.2bsd release which came out in 1983. it's possible ucb had a darpa contract to write a dns server in 1983/1984. bind was part of the 4.3bsd release which came out in 1986 and mainly went to universities. so unless the guy claiming 30 years of bind experience actually wrote the earliest bind code at ucb the most he could have is just over 20 years. assuming he worked somewhere that had 4.3bsd and was on the arpanet in 1986 or theresabouts. development versions of bind won't have left ucb until a beta test of 4.3bsd in 1996. pre-release versions of bsd were only made available to a select few.
"what could be the exploit of the decade"
Well, CERT doesn't agree with you on this one. They classified it as "moderate risk". An "exploit of the decade" would hardly be "moderate risk". The ones who blew this thing out of proportion are some security folks who saw this as an opportunity to get their 15 mins of fame and of course the media who saw this as a welcome opportunity to increase their advertising revenue.
Next time the media goes into a frenzy over some security issue, do yourself a favour and check the risk status assigned at the CERT website. If it says "moderate" then you know there is no reason to believe the media hype, you know you are being spoofed into clicking on those advertisements, that's all there is to it.
Taken from http://support.apple.com/kb/HT2647
Available for: Mac OS X v10.4.11, Mac OS X Server v10.4.11, Mac OS X v10.5.4, Mac OS X Server v10.5.4
Impact: BIND is susceptible to DNS cache poisoning and may return forged information
Description: 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.
So to paraphrase, turned off, yet has been updated for both server and client. Which is the opposite of what you said.
Paris because thats the current level of the register research and reporting. Can I suggest they patch with britney.
This is a total non story. You should be ashamed of yourself.
Do you have any evidence at all that there are a significant number of Mac clients being compromised by this? I'd like to bet that you can't find one single example of a Mac in the real world that has been compromised by this attack, and led to a malicious page.
It's not the vulnerability that's the problem with ANY security issue, is the abuse of the vulnerability.
This is a total scare mongering story.
We will learn more next week when Dan Kaminsky presents his paper at Black Hat; however, we do know that the cache poisoning vulnerability is based on being able to predict the source port that will be used for a recursive query and what will be asked in the query.
For an end-user system, the risk of cache poisoning is mitigated by the fact that it's resolver does not perform recursion. If it can't answer a query from the resolver's cache, it sends a request with the recursion desired flag set to a name server that performs recursive queries on its behalf.
Basically, "Joe Hacker" has to guess what your next query is going to be and the port that will be used for that query.
If the resolver routines on the end-user system uses a pre-allocated port for its queries, "Joe Hacker" only needs to guess when you will send the query that he wants to poison.
On Mac OS X, lookupd functions as the resolver. It does not pre-allocate ports. It requests a dynamically assign ephemeral port from the operating system for each DNS query. Mac OS X uses the classic BSD round-robin approach to port allocation.
While the BSD algorithm for port assignment is predictable, "Joe Hacker" now needs to guess when the next DNS request is going to occur, the TTL returned on the previous query, and how busy the system is to determine the port that will be used.
To gather this information, "Joe Hacker" needs to compromise a system between the name server and the end-user system. If he is able to do that, then it doesn't matter what changes, if any, were made to the name resolution routines.
The nCircle research reported by Don Goodin is pure shite.
OSX may not be a linux distro in fact it's based on unix (Free BSD) from which we all know linux evolved long long ago so those who claimed mac osx was linux can be excused I think in getting the branching wrong in essence they were right. truth is that when the open source community fix linux it can't be easily compiled for osx, apple need to create the fix for themselves from scratch. being based on an ancient operating system written by someone else, applying a security fix of this complexity is bound to be hard, that fact apple have failed this time says a lot though as they will have thrown everything they have at getting a decent fix in place in a timely manner.
Please stop defending the in defenceless when a company screws up like this it needs to be bashed as there are knock on security issues for everyone and next time they certainly need to do better.
I think i'd better get my coat!
"OSX may not be a linux distro in fact it's based on unix (Free BSD) from which we all know linux evolved long long ago so those who claimed mac osx was linux can be excused I think in getting the branching wrong in essence they were right"
Pal, you are talking out of your buttocks.
Linux did not evolve from FreeBSD nor any other BSD and it wasn't derived from any BSD either. If there is anything that Linux "evolved" from, then it would be Minix (a small Unix like kernel created and used for educational purposes).
Also, OSX is more accurately described as being based on Mach, not FreeBSD. This is because it doesn't use the FreeBSD kernel, it only uses userland programs and utilities from FreeBSD.
GNU Hurd is another operating system which is based on Mach. It uses the GNU userland programs and utilities, but nobody would say it is based on Linux just because it uses the userland which the Linux kernel usually ships with.
The only Linux operating systems that can be described as based on FreeBSD are not strictly Linux operating systems because they don't use the Linux kernel. For example Debian and Gentoo have versions which ship with the FreeBSD kernel instead of the Linux kernel. It would be incorrect to say that those Debian and Gentoo versions "evolved from FreeBSD" though.
"truth is that when the open source community fix linux it can't be easily compiled for osx, apple need to create the fix for themselves from scratch."
The cache poisoning vulnerability is in a software called BIND, which is not part of Linux and not maintained by the Linux developers. There is absolutely nothing Linux specific about BIND.
Quite to the contrary, originally, BIND is a BSD piece of software, not a GNU/Linux piece of software. Hint: The B in BIND stands for Berkeley, just as the B in BSD does. Thus, by your twisted logic BIND would have to be easier to fix on BSD systems than on any other systems because BIND was originally developed as part of BSD. Yet it doesn't work this way either. Today, BIND is further developed and maintained by ISC and then bundled by Unix and Unix like operating system distributors.
No matter which Unix or Unix like operating system, no matter which project team, no matter which vendor, all they have to do is recompile ISC's latest code, test it and ship it. There is no "create the fix from scratch", not for Apple, not for anybody else who uses BIND.
Why Apple didn't ship the latest ISC code any earlier, I can't tell you, but whatever the reason, it has nothing to do with having to create the fix from scratch as you claim.
"being based on an ancient operating system written by someone else"
Well, the BIND code that ships with Linux distributions is also based on the same "ancient operating system" and it was written by "somebody else".
The ancestor of today's BSD systems may be considered "ancient" but that doesn't mean that FreeBSD or any other modern BSD system is ancient. In fact, FreeBSD is quite unique in that there are developers on the FreeBSD dev team which used to work on the original BSD at Berkeley University, bringing at least twice the experience to the FreeBSD project than that the longest serving Linux developers have. This is considered a positive thing, not a disadvantage.
No, Linux is not based on BSD. Linux was originaly based on MINIX, which was a Unix-like OS, developed for educational purposes, that was released under the BSD license (note: license, not BSD code).
Linux was designed to be a free, Unix like system. BSD Unix was derived from the original AT&T Unix code base and, following the resolution of a legal case, was unencumbered by Unix's licensing requirements.
So Linux = Unix like OS
BSD = Unix derived OS
FreeBSD and GNU/Linux operating systems have five things in common:
- development started at about the same time in the early 1990s
- they follow common Unix APIs which is why they are "Unix like"
- they use the ELF binary format for executables
- they use the GCC toolchain for development
- the source code is public (open source)
and they differ in some fundamental ways:
FreeBSD was derived from BSD. Linux was derived from Minix.
- project scope
FreeBSD is a complete operating system. Linux is a kernel only, it is usually bundled with the userland from the GNU project, whose aim it is to eventually replace the Linux kernel with their own GNU kernel.
FreeBSD uses the revised BSD license, Linux uses the GPL license.
- packaging and distribution
The FreeBSD project is a single project, which develops and ships a single coherent operating system. Linux and GNU are different projects with different goals, developing different components for third parties to package into complete operating systems and ship them.
The reason why BSD and its modern derivatives are sometimes considered to be "real Unixes" and not just "Unix like" is that AT&T Unix incorporated a large amount of BSD code, not the other way round. Unix would not be Unix without BSD. In many areas BSD was the driving force and AT&T was the follower.
It is the irony of the lawsuit AT&T brought against the University of Berkeley that it revealed there was far more BSD code in AT&T Unix (thousands of files) than there was AT&T code in BSD (3 files). After the lawsuit was settled, Berkeley replaced the remaining AT&T code but AT&T continued to incorporate the BSD code.
Yes, BSD contains AT&T Unix code, but after the cleanup, only that code which AT&T took from BSD in the first place.
Seems like you are a case of Murphy's law of tools ...
If all you know is a hammer, then every other tool will look like a hammer, too, or at the very least belong to the family of hammers. Of course, your own hammer will always be a better hammer than all the other hammers. After all, how on earth are you supposed to drive a nail with that hammer they call a pencil.
Biting the hand that feeds IT © 1998–2019