New Remote Root in Mac OS X

Cysgod writes "I've released a security advisory detailing a new remote root vulnerability in Mac OS X 10.3, 10.2 and possibly earlier versions." The main thrust is that it exploits a problem in the DHCP client, to gain root access, and turning off various services can prevent attack. It is unclear why an exploit was made public before Apple resolved the problem. Apple's fix is apparently scheduled for a December release.

Exploitability Questionable

[marsipan]

"In most cases, the Mac will need to be booted into the malicious environment to be exploitable by this flaw. (The netinfod process must be restarted to cause the malicious server to be inserted into the authentication source list.)"

This definitely makes the exploit less likely...

Default?

[Phroggy]

and on any network provided service, including ssh (which is turned on by default in certain versions of the affected software).

I'm not aware that SSH was enabled by default in any version of Mac OS X.

What does this mean to the average home user?

[Anonymous Coward]

Assuming two scenarios:

1. A home user with dialup, running no external services, with the firewall turned on.

2. A home user with DSL/CABLE, running behind NAT. And for fun, let's add Airport. Also not running any services, firewall on.

For the non-technical /. reader, is this vulnerability something to be seriously concerned about?

My turn to karma-whore

[McDutchie]

It's already slow and it may get slashdotted soon, so here it is:

[blank.gif] [1]Carrel.ORG > Important Mac OS X Security Advisory

Mac OS X Security Advisory

Vulnerability:

Malicious DHCP response can grant root access

Affected Software

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

Abstract

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.

Vendor Patch

Apple Computer has been notified of this issue and may be working a
fix at this time. At the time of this writing, a fix is not available
from Apple.

Workarounds

There are a variety of avenues to avoiding this vulnerability...
1. Disable any network authorization services from obtaining settings
from DHCP:
+ in Directory Access, select LDAPv3 in the Services tab, click
"Configure...", uncheck "Use DHCP-supplied LDAP Server"
+ in Directory Access, select NetInfo in the Services tab,
click "Configure...", uncheck "Attempt to connect using
broadcast protocol" and "Attempt to connect using DHCP
protocol"
+ in Directory Access, uncheck LDAPv3 and NetInfo in the
Services tab, if you don't intend to use them
2. Turning off DHCP on all interfaces on your affected Mac OS X
machine can also keep you from being affected.

For added security, be sure to disable any unused network ports:
* turn the AirPort card off or remove it, if it is not being used.

Configuration Awareness

If a user should need any of these settings turned on due to the
network and authorization system they are currently using, they should
be aware that they could fall prey to a malicious individual using the
techniques outlined in this advisory. Steps to mitigate this concern
could be as simple as manually configuring the directory server
settings on the affected machine.

Technical Details

By default, the affected versions of Mac OS X attempt to negotiate
DHCP on all available interfaces. In the event that an Airport card is
installed but there is no network nearby, they also default to
associate with any network that might appear and then use DHCP to
obtain an address. The system will also use DHCP provided fields, if
available, to connect to an LDAP or NetInfo server on the network.
The default settings in "Directory Access" on affected systems will
cause the system to place the network LDAP or NetInfo server ahead of
the local user info for any given account, and will implicitly trust
the LDAP or NetInfo server to provide correct information.
Furthermore, nothing in the system prevents a login as a user with uid
0 (zero) with any login name. For example, an LDAP or NetInfo source
with an account username "bluemeanie", uid 0, would be perfectly valid
and usable for login at the login window and on any network provided
service, includi

Re:The Reason the exploit was made public..

[abde]

also there's this timeline of events, which is quite revealing:

History of this Advisory & Vendor Contact Log
2003-10-09 Initial version of this advisory
2003-10-09 Apple Computer notified
2003-10-09 Apple Computer confirmed receipt and forwarded to eng. team
2003-10-11 Minor edits, also added "Philosophical Issues" and "Path to Root"
2003-10-14 Apple Computer assigns specific point of contact
2003-10-14 Requested confirmation of issue with Apple Computer
2003-10-15 Apple Computer confirms issue
(2003-10-24 Original deadline given to Apple for acknowledging issue)
(2003-10-24 Mac OS X 10.3 is released with this known issue)
(2003-10-28 Mac OS X 10.3 Security Update released, does not address issue)
2003-10-28 Requested update of fix status from Apple Computer
2003-10-28 Apple Computer proposes Nov. 3 fix date
2003-10-29 Apple Computer reneges on Nov. 3 date
2003-10-29 Requested fix in "2 or 3 weeks" from Apple Computer
(2003-11-04 Mac OS X 10.3 Security Update released, does not address issue)
(2003-11-15 Mac OS X 10.3.1 is released with this known issue)
2003-11-17 Requested update of fix status from Apple Computer
2003-11-18 Requested update of fix status from Apple Computer
(2003-11-19 Mac OS X 10.3.1 Security Update released, does not address issue)
2003-11-19 Apple Computer replies "scheduled to go out in December's update"
2003-11-19 Deadline of Nov. 26 given to Apple Computer
2003-11-25 Minor edits, made "Path to Root" a little more work for the script kiddies
2003-11-26 Advisory issued (48 days after initial vendor notification)

Vulnerability Text (Already running slow)

[Anonymous Coward]

Carrel.ORG > Important Mac OS X Security Advisory
Mac OS X Security Advisory
Vulnerability:
Malicious DHCP response can grant root access

Affected Software
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

Abstract
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.

Vendor Patch
Apple Computer has been notified of this issue and may be working a fix at this time. At the time of this writing, a fix is not available from Apple.

Workarounds
There are a variety of avenues to avoiding this vulnerability...
Disable any network authorization services from obtaining settings from DHCP:
in Directory Access, select LDAPv3 in the Services tab, click "Configure...", uncheck "Use DHCP-supplied LDAP Server"
in Directory Access, select NetInfo in the Services tab, click "Configure...", uncheck "Attempt to connect using broadcast protocol" and "Attempt to connect using DHCP protocol"
in Directory Access, uncheck LDAPv3 and NetInfo in the Services tab, if you don't intend to use them
Turning off DHCP on all interfaces on your affected Mac OS X machine can also keep you from being affected.
For added security, be sure to disable any unused network ports:
turn the AirPort card off or remove it, if it is not being used.
Configuration Awareness
If a user should need any of these settings turned on due to the network and authorization system they are currently using, they should be aware that they could fall prey to a malicious individual using the techniques outlined in this advisory. Steps to mitigate this concern could be as simple as manually configuring the directory server settings on the affected machine.

Technical Details
By default, the affected versions of Mac OS X attempt to negotiate DHCP on all available interfaces. In the event that an Airport card is installed but there is no network nearby, they also default to associate with any network that might appear and then use DHCP to obtain an address. The system will also use DHCP provided fields, if available, to connect to an LDAP or NetInfo server on the network.

The default settings in "Directory Access" on affected systems will cause the system to place the network LDAP or NetInfo server ahead of the local user info for any given account, and will implicitly trust the LDAP or NetInfo server to provide correct information. Furthermore, nothing in the system prevents a login as a user with uid 0 (zero) with any login name. For example, an LDAP or NetInfo source with an account username "bluemeanie", uid 0, would be perfectly valid and usable for login at the login window and on any network provided service, including ssh (which is turned on by default in certain versions of the affected software).

In most cases, the Mac will need to be booted into the malicious environment to be exploitable by this flaw. (The netinfod process must be restarted to cause the malicious server to be inserted into the authentication source list.)

By taking advantage of these default se

What is telling

[Space cowboy]

is that this is news. Ok, it's not a vanilla BSD, but it is based on BSD, which has a fantastic record on security. What will be interesting to find out is where the bug came from - Apple or some third party ...

I'm pretty sure it was Apple that could boast of no exploits against them (this was OS9 days). Sad to see that go, if it's true. Any unix-os is a friend of mine :-)

Simon

Re:And now the question of support...

[llf4nlp]

Apple is on record saying they will provide security fixes for all versions of OS X. In some cases, the press has not caught up with this fact.

Re:And now the question of support...

[tgibbs]

Even more unclear is which releases of Mac OS X Apple plans to continute to release security fixes for...

Yes, all we have to go on is Apple's past record of continuing to provide security fixes for previous versions of OS X and OS 9.

Re:Default?

[Darth_Foo]

I don't beleive it is in the client versions of OS X but it almost certainly is in OS X Server (which is also subject to the published vulnerability).

Re:Making rounds

[Onan]

You're right. The only sense in which root is "disabled" in osx is that it has no valid password unless someone explicitly sets one. So supplying a whole new set of accounts does obviate that.

Fortunately, the other point is still somewhat valid: sshd (and afpd, and all other services) are turned off by default. Anyone who enables any of them could get bitten by this, so it's still a problem, but the vast majority of users will leave them off and be invulnerable.

Re:Call me an Apple Apologist, but..

[Evil Adrian]

Root exploits are newsworthy. Every time Microsoft has a root exploit, it makes headlines, so Quit Thy Bitching.

Local insecurity

[Anonymous Coward]

You can "physically sit down to any Mac OS X machine and log in as root locally" by doing this:

1. Shut down machine, or power it off if you can't shut down.

2. Hold down Command-S while starting up the machine.

You're in as root, no login required, and it even tells you how to mount local filesystems writable.

You can also reset the password by booting from a Jaguar or Panther installation CD with the "C" key down, and resetting the password from the Installer menu.

I love my Mac, but Mac OS X is not a secure OS.

I've reported this bug before, and Apple sees it as a feature.

Here's a mirror

[EvilStein]

http://www.pbp.net/~jnichols/dhcp-vuln.html

Link for the extra-lazy: here

Whoops

[EvilStein]

here is the clicky-link [pbp.net]

Re:Local insecurity

[Jesrad]

IIRC there IS now a login prompt before accessing single-user mode. And there is a free utility that lets you password-protect the OpenFirmware, which prevents you from booting from a CD or in single-user mode.

But in any case, having physical access to any machine WILL give you admin access anyway. If you really want the data, just crack the case open and pick the hard drive up.

The real issue is REMOTE security, and MacOS X has a wonderful track record on that. The flaw mentionned in the article is hardly exploitable even when all the (numerous) conditions are met.

Re:Call me an Apple Apologist, but..

[Maserati]

Funny, I just installed the latest Omega drivers for my Ti4600. During the install process, ZoneAlarm said that ScriptingHost 6.0 (maybe VisBasic 6, not 100% sure) wanted to access the Internet. I'm glad I didn't let it.

I'm also glad that the only machine at the office that ever has remote login turned on is on a static IP address and isn't running dhcpd at all (and it doesn't have it turned on now anyway). And we aren't using directory services on the desktop for any authentication at all, so even the DHCP machines shouldn't be at all vulnerable. Having an email out to the group as soon as I'm back from vaaction will be a nice feather in my cap.

Incidentally, a fresh install of 10.3 does have some of these services turned on by default, and they aren't really necessary unless you have a specific reason for them - corporate IT environments for example. This is usually a Microsoft boobo, Apple usually leaves things off - remote login for one - by default. And hasn't ever done anything like share your C$ automatically.

Re:What does this mean to the average home user?

[Anonymous Coward]

Routers connect subnets. Routers do not forward broadcasts. If you use VLANs and have multiple logical subnets on one physical network, you still won't see broadcasts from one VLAN passed to the others.

So if you're on the same physical/logical subnet with no routing required between machines, the exploit is possible.

Re:source

[llf4nlp]

Source: CNET: http://news.com.com/2100-1002-5109969.html Apple has come under fire from some in the security community who feared that it was not planning to patch the Jaguar flaws and that it would instead force people to upgrade. However, the Cupertino, Calif.-based company said it would patch the holes in earlier Mac OS X versions, as it had done in the past.

Re:Call me an Apple Apologist, but..

[maniac1860]

Let's be serious. A bug in active script that "may allow access to a users files" is no where near the same magnitude of a remote root exploit.

Re:Call me an Apple Apologist, but..

[DeltaSigma]

Seriously, Liu Die Yu has once again torn IE a new one. He's a very talented vulnerability researcher. I wish I had the money to help him get a computer, but I don't.

People can donate via paypal here [clik.to], if they want.

He's very good, very responsible. Doesn't bash on Microsoft in his reports. It all appears to be acedemic with him. Help him out if you can.

Re:Default?

[Cysgod]

Hi there.

It is important to note that having all your services turned off is *not* protection against this bug.

The malicious LDAP server also gets to dictate your mountpoints to you. This means malicious executables can be mounted anywhere in your filesystem. Including places where they can be expected to be executed.

A trivial exploit of this would be to replace the directory with crontabs and set up a crontab and an executable to run as root. Suddenly sshd *is* enabled.

I'll try to answer other questions as I can. This got posted when I was horseback riding, I submitted it at 9am....

Just use an Open Firmware password.

[netsrek]

Set an Open Firmware password on your machine.

You will then need to enter this password to enter single user mode or boot from a CD.

Note that this still doesn't fully secure your machine unless it's physically secured, as someone can simply reset the OF password by changing the amount of RAM in the machine, then zapping the PRAM.

Makes securing a powerbook pretty much impossible, but otherwise...

Re:i thought i would never say this

[RustyTaco]

Uh, lookup how "Automatic Proxy Configuration" works before you get too relaxed. It's a "hey you untrustworty slime out on the network, do you want me to run something" sort of thing, just like this. Both are on by default, which is bad. Apple is accepting account information and passwords without cross-checking, MS is running a random script an injected packet told it to run.

Bad Fruit on Apple though. Since they probably don't want to remove the automagical "Just Works" functionality I have a feeling they're change it so that it "Just Works" only for unpriliaged users and requires some statement of trust to allow prilieged users.

- RustyTaco

Re:Default?

[nehril]

your OSX server is vulnerable only if it uses DHCP on an untrusted lan. if you're using dhcp for *servers* on an unsecured network.... well then you have more problems than this.

the exploit as I understand is this: evil dhcp server gives you an IP addr and also an evil LDAP server, which if your mac is configured to do so, will allow the LDAP server to authenticate root level users too (besides other fun admin stuff like mount points).

this behavior is actually useful for 'lab full of macs)' scenarios and, as I understand, has been an admin 'feature' since the NeXTStep days.

Re:Local insecurity

[dirkx]

This seems to only affect machines which did not come through an upgrade path from 10.1 or before; but had Panther instaleld on them cleanly.

The solution is documented in /etc/ttys, simply change the secure of the console to a insecure:

If the console is marked insecure, single-user requires the root password. Since DirectoryServices is not running by the time we enter single-user mode, init will ask for the non-shadow crypt password stored for root in /etc/master.passwd. If no such password exists, it will not be possible to enter single-user mode from a console marked insecure.

I.e. The lines you want to edit is/are (with sudo vi /etc/ttys):

console "/usr/libexec/getty std.9600" vt100 on insecure

console "/System/Library/CoreServices/loginwindow.app/Cont ents/MacOS/loginwindow" vt100 on insecure onoption="/usr/libexec/getty std.9600"

Given that you propably still want to be able to log in if you have to - you propably also want to do:

netinfo or other default passwd: sudo passwd root

default passwd file used during early boot stages sudo passwd -i file root

Note that in most cases you want to change both.

Dw

Re:Local insecurity

[stefanb]

Hold down Command-S while starting up the machine.

Open Firmware Password [apple.com] is a little utility that will set up the password for Open Firmware, which you could also do from the Open Firmware prompt (Cmd-Opt-O-F).

Once set, you cannot boot from anything but the default startup disk. Also you need to enter the root password to enter single-user. (If root is enabled.)

CNET article

[green pizza]

http://news.com.com/2100-1002-5109969.html

Re:Good News?

[debrain]

Apple has chosen to make the users do all administrative tasks via sudo instead, which makes sense in the case of your clueless friends.

You mean like:
$ sudo bash

What is the difference, if any, between having an enabled root account and a user account with sudo access to every command (ie. bash)?

Cheers

Re:Making rounds

[arkanes]

Except that (as (he?) posted in this thread), the LDAP server can also specify mountpoints for you, (apparently) including things like replacing your crontab with a remote one that WILL start all those services.

Re:Call me an Apple Apologist, but..

[freeweed]

Sorry, I linked to the wrong page.

Yu said the redirection feature could also be exploited to download and execute a malicious file on a user's system. [atnewyork.com]

You're right, it needs the browser to work. Still pretty damn close to a remote root exploit, in a Windows environment anyway. Visit a malicious webpage, and bang! you're rooted.

AUTHOR: FAQs answered

[Cysgod]

Thought I'd field some of the more mentioned questions and misconceptions here...

Is my machine safe if I have the root account "turned off"?
No. The account attacking can be uid 0 and have any other name in the universe that is a valid account name.

Is my machine safe if I have all remote access services "turned off"?
*NO*, and please quit saying it is. This exploit allows malicious people full control of where things are mounting on your system. They can mount malware anywhere. Including places that can virtually guarantee executiong of their target code. For example, an attacker could cause their evil data to be mounted in place of crontabs and have their fake root's crontab point to an evil executable mounted there or somewhere else.

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 didn't 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.

(As I mentioned in a previous post, I was out horseback riding by the time /. got around to finally posting the article. Sorry it has taken me so long to respond.)

Re:What is the fix?

[Glock27]

They're not fixes, but there are some fairly easy workarounds:

Workarounds
There are a variety of avenues to avoiding this vulnerability...

1. Disable any network authorization services from obtaining settings from DHCP:

* in Directory Access, select LDAPv3 in the Services tab, click "Configure...", uncheck "Use DHCP-supplied LDAP Server"

* in Directory Access, select NetInfo in the Services tab, click "Configure...", uncheck "Attempt to connect using broadcast protocol" and "Attempt to connect using DHCP protocol"

* in Directory Access, uncheck LDAPv3 and NetInfo in the Services tab, if you don't intend to use them

2. Turning off DHCP on all interfaces on your affected Mac OS X machine can also keep you from being affected.

For added security, be sure to disable any unused network ports:

* turn the AirPort card off or remove it, if it is not being used.

subnet exploit ?!

[didiken]

Remote exploit ? Can you say subnet exploit ?! Victim gotta have DHCP and SSH turned on. So not a default client installation exploit.

You MAY say MacOS X Server got SSH turned on so will be vulnerable, but you must enter a static IP address at the system setup, that means you've no DHCP options unless you manually change it to DHCP later at "System Preference". By the way, if you do use DHCP to hand out server IP address you deserve to get rooted.

Anyway I get enough laugh out of some amateur security people today. Movie at 11.

Re:Exploitability Questionable

[moof1138]

Static automounts from directory services (which are what you need to exploit this) only get mounted at boot, if if certain directory services related processes get restarted that never get restarted in a normal setup, so you really need to boot a machine in a hostile environment for this to affect you. Dynamic automounts will get mouted at each login, but will not be mounted in a dangerous way.

You can just go into Directory Access and uncheck LDAP and NetInfo to be immune to the issue even if you use DHCP. I always do this. While this guy thinks he is early in reporting this bug, rogue NetInfo servers are not a new thing (though rogue LDAP servers would be more recent). There used to be an article in NextAnswers from the late 80s about how to track them down. I always customized these settings when I first get a OS X system to avoid this very thing.

Re:Damn

[Steve Cowan]

"Hundreds of Macs"? Um, troll much?

Anyway, somebody has to be plugged into your LAN before they can take advantage of this security hole, i.e. they must be on your subnet. If you are behind a NAT device you are safe, unless somebody can get in via wireless or by plugging in.

I'm not worried.

Re:Ummm

[smcv]

An attacker could override arbitrary directories, if they could control the mount table. As another poster pointed out, if they mounted a network share containing a malicious script over the top of, say, /etc/cron.daily, you'd never know, and it'd execute at midnight.

Alternatively, if they knew your OS version, they could replace /lib with a nearly-identical version, except that the standard C library (libc) contained some sort of malicious code which executed once (the first time fork() was called, say), and it'd get loaded the first time you ran any dynamically-linked program. Again, unless you habitually mess with the contents of /lib (not advisable), you'd never know - the only symptom would be a slight slowdown when starting new programs, and it could even be coded to be self-removing so it only triggered once, while quietly opening up remote access in the background.

No panic, just reconfigure

[ApocryphX]

Just in case anybody missed it: the solution is easy!
Just open the Directory Access tool and deselect:

LDAPv3, NetInfo, SLP

done!

I.M.H.O., Apple made the same mistake as MS in this case: Enable everything in case someone might need it. And don't worry about the bad guys ......

Re:Show-boating, grand-standing

[Quixotic Raindrop]

First, the average user 1) doesn't have a directory server to authenticate to and 2) doesn't mount anything that's not connected by either USB or Firewire. The average Macintosh user doesn't have Remote Login enabled, and lots of average Macintosh users don't have Personal File Sharing enabled (neither is enabled in the installation, by default).

As far as your understanding of the timeline goes, you should RTFA. He notified Apple, and they did respond. He is just unjustifiably impatient.

Re:AUTHOR: FAQs answered

[Wanker]

Kudos to you for handling this very responsibly. Despite the attention-grabbing comment by pudge [pudge.net], you followed the policy he linked to [wiretrip.net] quite nicely.

It doesn't seem to me at all unclear "why an exploit was made public before Apple resolved the problem". In fact this seems very clear in what you wrote:

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.

The wiretrip policy linked above is quite clear on how long to give a vendor ("maintainer") to come up with a fix:

B. The MAINTAINER has 5 work days respond. Note that all times of work days are relative to the ORIGINATOR, not the MAINTAINER. Suggestion to the MAINTAINER: sooner is better than later--just because you have 5 days does not mean you need to take them all. The ORIGINATOR is technically free to do whatever they want to do after 5 work days--however, they should be fair and wait if the MAINTAINER shows adequate initiative to fix the ISSUE.

This is clarified a bit on what it means to "respond" in the FAQ section:

Q. I'm a software maintainer, and I can't possibly fix the problem in 5 days....
A. You don't have to. If you (re)read the above, you have 5 days to establish communication. Provided you cooperate with the researcher and keep them 'in the loop', they should provide you with whatever time necessary to resolve the ISSUE (within fair reason).

Q. I'm a software maintainer, and I want more than 5 days!
A. Well, considering that, in general, you don't have *anything* technically, this document hopes to provide you with at least 5. Be on your best behavior, cooperate with the ORIGINATOR, and you should get more. :)

According to policy, you would have been OK (if somewhat rude) releasing this after 5 work days from initial contact. Extending it through 48 calendar days and several patch cycles seems extraordinarily generous.

I wouldn't feel at all bad about the timeline followed. If anything it shows remarkable restraint.

Re:Show-boating, grand-standing

[Quixotic Raindrop]

Here's the problem that shows that you don't understand. It's not enabled by default, there is nothing auto-mounted via LDAP. In order for a remote user to modify your crontab or your fstab, they'd have to already have access. The method detailed in the advisory requires that the client using DHCP have already enabled LDAP; this is not enabled by default in the non-Server versions of Mac OS X 10.2 or earlier. It might be by default on OS 10.3, but I don't have 10.3 yet. Approximately 99% of all non-Server versions of Mac OS X 10.2 and earlier are not vulnerable out of the box.

Re:i thought i would never say this

[jjhlk]

I don't understand what you meant, but Administrator does not have kernel level access, like your parent said. This is obvious when you try to kill certain processes as Administrator, but are not allowed. Of course, Administrator access is enough to still do anything you want on the computer, so the distinction is almost moot.

Re:Exploitability Questionable

[Anonymous Coward]

Ha, you people are all ignorant.

If you were a Mac person, you would know that Mac people never shut their laptops down, only put them to sleep. Why go though a slow boot on your iBook when it wakes up as soon as the lid is up?

As many moderated up quotes from the article tell us, this problem is only a problem when the services are started, which is on boot. Which is not on wake-from-sleep.

I do not mean to trivialize this hole. To me, it seems obvious why it is there. Apple wants LDAP-enabled, OSX Server managed networks to work out of the box. This includes the ability to mount shares anywhere on the client system, which is insanely powerful and useful in a trusted setup.

Trusted is, of course, the operative term there. Apple needs to fix this or disable the services by default. People who need it can enable it themselves.

Re:I remember this guy.

[Cysgod]

I've been pretty low-key about this until today, so I'm not sure what you're talking about. I'd be very interested to see links to the comments you refer to.

I may have reason to believe that the seeded copies of 10.3.2 are, in fact, still vulnerable to this bug by default. But I can't say for sure because if I did know for sure, that would mean that someone violated their NDA and that would be bad news for someone. Live in fear of Apple Legal.

It's not a real happy conundrum. I found out one week ago that Apple was planning to release in December after having previously agreed in principle to a date sometime in November. I felt that I was being strung along like a ball of yarn, but I didn't want to be unreasonable so I gave them 1 more week. They never replied and cut off all contact with me. And here we are.

And FWIW, since it's been mentioned, I'm not an Apple hater, I love my PowerBook. :-) Thanks for writing.

Apple's response

[stefanb]

Looks like Apple finally put up an article at http://docs.info.apple.com/article.html?artnum=324 78 [apple.com]

Salient quote:

Learn how to configure the Directory Access feature to protect your Mac from a malicious DHCP server.

DISCUSSION

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 Apple's Airport, this exploit is not possible.

[...]

If your Mac is configured to use a directory service consult with your IT administrator before changing any settings.