Late last week, I was in a taxi with a business acquaintance, heading to an event at which we were both speaking.
We’re both Mac users, so in the fashion of fanbuoys-in-denial the world over, we started chatting about all things Apple. That led us to Lion, which in turn led to my chum James saying, “Have you seen the recent discussions online about LDAP network authentication on Lion clients? It’s a really handy feature – if you forget your password, you can just make one up. A real helpdesk time saver!”
This issue has been brewing in online forums for more than a month, pretty much since Lion’s release, but has now hit the news in a big way. Irrepressibly eager Register hack Dan Goodin, for example, describes it as a ‘huge hole’ threatening enterprise networks.
Unfortunately, exactly how extensive the hole is – and exactly where the fault lies, where the fix should come from, and what can be done in the meantime – isn’t terribly clear from the articles I’ve seen, including the discussions on Apple’s own forum.
Clearly, a network which grants a client computer access to network resources because of a bug on the client (or, for that matter, deliberately malicious behaviour on the client) is itself equally buggy, and dangerously insecure.
Server resources should fail closed when faced with a misbehaving client.
On the other hand, if you’re using your network authentication service to tell the client whether it should allow a user to access local resources, you rely on the correct behaviour of the authentication software on the client – just as you would if the user were logging in entirely locally.
And as far as I can make out, that’s what seems to be happening here. If you have an OS X Lion client which relies on an OpenLDAP authentication server, your Lion computer may be at risk.
If you leave your computer at the login screen, for instance, you might find that anyone else could log back in to your computer with any old username and password.
(Some of the reports in the abovementioned forums describe total lock-out, when no username or password, legitimate or otherwise, will work on their Lion clients. Others describe exactly the opposite, when it seems that any username and password will do.)
So this problem might not be quite the huge enterprise network hole Dan Goodin proclaims, but even if it isn’t, it’s still very serious.
It seems that at the very best there is a security bypass bug in OS X Lion’s local authentication.
Sadly, the one organisation which could usefully and helpfully comment on all of this just isn’t going to do so, at least not yet.
Apple’s official attitude to security, documented in its overarching knowledge base article HT1222, is a corporate Cone of Silence:
For the protection of our customers, Apple does not disclose, discuss or confirm security issues until a full investigation has occurred and any necessary patches or releases are available.
Until Apple is good and ready, and has turned the problem into a thing of the past, you’re entirely on your own.
This is a unhelpful attitude to security by Apple, and it’s one which Apple users should keep criticising publicly until the company changes it. But it’s how Apple does business, so for now it’s simply part of the cost of having Macs in your corporate infrastructure.
Let’s hope for a silver lining. Perhaps this incident will be the one which persuades Apple to engage more closely with its many loyal fans on matters of security?
Follow @duckblog
–
PS. If you’ve been affected by this bug, and can provide us with objective information about exactly which aspects of login and authentication are at risk, please let us know so can we update this article. In particular, if a user has correctly-authenticated network access, e.g. to a file server, and then locks his Mac, can an imposter unlock the computer with a non-existent password and pick up where the previous user left off? Or does this authentication problem affect local resources on Lion computers only? Also, which LDAP authentication back-ends are affected? Do you know of any reliable workarounds?
