We often crow about the various and sundry security flaws that affect the world of Windows on a weekly, and sometimes even daily, basis. New flaws in the many different Windows versions out there are being revealed all the time, while some flaws that were long ago patched by Microsoft are the same flaws being exploited for new virus outbreaks through unpatched systems.
Often in our coverage, we have pointed out that Microsoft was notoriously slow in releasing patches for newly found exploits. Many in the security world gave up working with Microsoft when they found new flaws after the company put more effort into hushing up news of the flaws than it did in working to fix them.
Eventually, that led to security researchers simply releasing news of the flaws on their own schedules so that those interested could try and cope as they could. That, added to pressure from the then-nascent US Department of Homeland Security eventually led to the much more responsive Microsoft that we have today; and make no mistake about it, Big Redmond has indeed come a long way in being more responsive to new security flaws.
In the *nix world, in the meanwhile, new security flaws are often patched the same day they are discovered. Apple, as a *nix vendor, has so far followed such fixes from the greater *nix community fairly swiftly with its own Mac OS X patches. While there was briefly some concern earlier this year about whether or not Apple would be fixing security flaws in Jaguar, the company quickly affirmed its commitment to Jaguar in an official statement.
Today (the news actually hit late on Wednesday before Thanksgiving), however, we have news of a new security flaw in Mac OS X that could allow someone with access to a Mac network to gain control over Macs in the network. Along with the news came statements from the security researcher, one William Carrel, saying that Apple had so far "reneged" on its commitment to have a fix for the hole on November 3rd, and that he was revealing the flaw in order to protect Mac OS X users in case of independent discovery of the flaw from "less scrupulous" people. In other words, according to Mr. Carrel, he gave up waiting for Apple to fix the problem.
From Mr. Carrelis Web site:
Why did you release this when you did?
This was an exploitable remote root vulnerability. After Apple reneged on the Nov. 3rd release date I gave them 2-3 weeks. After the 2-3 weeks were up, I asked for the status and they said "December". Meanwhile, users are left exposed and independent rediscovery seemed fairly likely. And maybe by someone less scrupulous than myself. I felt I was being strung along and that the issue may never get properly addressed so I set a hard deadline at that point. They didnit meet it, and I issued my advisory.
It would not be fair of me to let Mac users hang out in the breeze for more than 2 months on an issue of this magnitude. You may disagree, but I have no regrets about my actions and feel that I was more than fair to Apple Computer and its users.
So what is the hole?
Malicious DHCP response can grant root access
- Mac OS X 10.3 (all versions through at least 26-Nov-2003)
- Mac OS X Server 10.3 (all versions through at least 26-Nov-2003)
- Mac OS X 10.2 (all versions through at least 26-Nov-2003)
- Mac OS X Server 10.2 (all versions through at least 26-Nov-2003)
- Probably earlier versions of Mac OS X and Mac OS X Server
- Possibly developer seeded copies of future versions of Mac OS X
A series of seemingly innocuous default settings can cause an affected Mac OS X machine to trust a malicious machine on a network for user, group, and volume mounting settings.
What does this mean to the average user
Anyone who can gain access to your network can gain administrator (root) access to your computer and therefore steal your data or launch attacks upon others as soon as you reboot your machine. System administrators and users of affected software should read the section "Workarounds" for immediate actions to protect their machines. It is important to note that WEP security in 802.11b/g (AirPort/AirPort Extreme) wireless networks is generally not sufficient to protect your network from access by an attacker.
Apple released a KBase Article on this issue late on Wednesday. In that article, the company says:
Please note that the exploit requires the malicious DHCP server to be located on your local subnet. For typical home network configurations with a broadband (DSL or cable service) modem and a NAT (Network Address Translation) device, such as Appleis Airport, this exploit is not possible.
If there is a chance that a malicious DHCP server has been injected into your subnet or you are operating on an untrusted network there are two solutions to the potential vulnerability depending on if you are using a directory service.
In Mr. Carrelis article, he says that AirPort networks are actually not protected -- despite what Apple says in the KBase article -- because of the poor quality of the WEP encryption included in the original AirPort platform. He added that properly secured AirPort Extreme networks should be safe because of AirPort Extremeis more robust encryption. Weill also toss in our own two bits that for most home users, access to your AirPort network requires a somewhat close physical proximity that offers its own level of protection (your housing situation will greatly affect this, of course).
Appleis offices were closed all of last week, meaning that Apple has not had an opportunity to respond to anyoneis questions on this issue. In Mr. Carrelis article, he offers a timeline of his interactions with Apple on this issue. We recommend reading the full announcement on Mr. Carrelis Web site.