Slashdot Mirror
Mac OS X Lion LDAP Vulnerability Emerges
hypnosec tips a bit of Apple news from late last week that got overshadowed by the headlines about Steve Jobs. According to El Reg, "People logging in to Macs running OS X 10.7, aka Lion, can access restricted resources using any password they want when the machines use a popular technology known as LDAP for authentication. Short for Lightweight Directory Access Protocol, LDAP servers frequently contain repositories of highly sensitive enterprise data, making them a goldmine to attackers trying to burrow their way into sensitive networks." Initial reports about this bug cropped up less than a week after Lion was released.
It's actually a client problem. Lion may allow you to logon using any username/password combo, or refuse to allow you to logon regardless of your username/password combo if you're using an LDAP backend. AFAIK this won't allow you to access similarly secured network resources using the bogus credentials.
Once we own an LDAP server we own everything
Uhhh, say what?
I guess you could learn my cellphone number, but seeing as its somewhere in between 000-000-0000 and 999-999-9999 its not top secret. I suppose you could change my home directory to /tmp, just to piss me off, at least for a little while. You could delete my ldap account, now that would thoroughly annoy me until I restored the ldap server data from its backup...
Part of the problem is I've never seen a LDAP deployment without its buddy kerberos doing the password stuff. I guess its possible to use LDAP to do passwords, but I've never done it. I would think it would be kind of awkward, like using cfengine to do moves/adds/changes inside your passwd file. Maybe there exists a linux PAM module to change passwords etc inside LDAP, creating ldif files and running ldapmodify to change my password would get old real quick. I would guess the testers probably didn't even set up to do something that weird, assuming everyone would use kerberos with ldap.
I suppose if you consider nuclear missile launch codes to be "directory information" and thus keep them in your ldap, or more realistically keypad door combinations, then you could be in big trouble. Medical records at a hospital in a LDAP?
"Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
Well the Mac in this case is the threat and not the vulnerability. So from that perspective, the Mac itself remains secure.
Views expressed do not necessarily reflect those of the author.
No, you remember wrong. The Mac commercials say that, unlike a PC, everything just works and you won't get viruses.
Now if I try and access "Important Trade Secrets.pdf" and get told "Access Denied," that's not "just working," is it? So instead, with the new Mac OS X Lion, instead of giving you an "access denied" message when you try and access that file, it just loads it up! It just works!
OK, so I'm really confused as to what the vulnerability actually is. And given that the article starts off with "LDAP servers frequently contain repositories of highly sensitive enterprise data," I'm not exactly convinced the author knows what they're talking about either.
But from what I can gather the bug has to do with using Mac OS X Lion as a file server. Once a user has authenticated with the server once, the server starts blindly accepting any credentials it receives, I guess?
So, yeah, "it just works" if all you want to do is access files. Which is all the ads ever talk about.
If, on the other hand, you don't intend to allow everyone access to (the data on?) your entire computer, then maybe you should consider not using Mac OS X as a server.
I think. Who knows. The article is awful.
You are in a maze of twisty little relative jumps, all alike.
A few pointers. Don't use LDAP for authentication. use Heimdal Kerberos for authentication (PAM) and use LDAP for authorization. (NSS). Don't let machines bind as cn=Manager. That is very bad should a machine become compromised. Generally, SASL LDAP binds are recommended over simple. Kerberos should bind
And most relevent. Only let users in the People OU bind to their own uid in the suffix.
If you are binding to the tree with cn=Manager, on a regular basis, you deserve what you get, set your ACLs right.
I'm not quite sure what the 'bug' here is.. First off, Apple's LDAP is 'OpenLDAP'. So. Is this a flaw in OpenLDAP or Apple's configuration for OpenLDAP?
Also.. LDAP is kinda like DNS, except most places don't secure it. To see this in action, download Apache LDAP Studio, connect to your friendly local LDAP server and start browsing around (without authentication).. Most times you can get an almost full LDAP dump from a remote server without authenticating at all. Generally the only 'protected' elements are the passwords. You can enumerate users, groups, etc.
I guess that's what happens when you use OpenLDAP.
Silly Apple.
I think. Who knows. The article is awful.
El Reg is a rag, a fun rag but a rag nonetheless. There's been a spate of articles lately attacking Apple's enterprise readiness because of bugs (in a month old OS.) I wonder if that's because they are being used more in enterprise and it's becoming more of a problem or someone's just worried that they might get some traction in business ?
If all else fails, immortality can always be assured by spectacular error.
IMV, it's not as bad as it's made out.
The way LDAP authentication is supposed to work is:
1. Client connects to server to find exactly where in the tree the user's information resides (the user's DN). This is not particularly sensitive - it's usually done either anonymously or with an account with very little privileges.
2. Client drops the connection then tries to re-connect using the DN it found out in (1) and the password supplied by the user.
3. If the server responds that the login has succeeded, let the user use the service. If not, refuse.
A number of people have followed the logs on their LDAP servers and established that OS X Lion isn't carrying out step 2 at all. So provided the user ID supplied is valid, the user can log into the computer.
It's important to note that this process is repeated for every process you want to use. Kerberos makes life a little easier (the server supplies a token to say "This user has logged in OK" and that token can be used to authenticate against services that support Kerberos). In any case, the person is logged into the computer but cannot access network resources. Nevertheless, it's an absurd fault that should have been picked up in testing, I have no idea how it could possibly slip the net.
LDAP is a (what I always thought was) a pretty cool hierarchical directory type data server; its really good at storing data that is in a tree structure. But it will do relational duty as well. A company I worked for that did an enterprise web portal back in the 90's stored its stuff in a relational, but than we got a request for all its data to work on an LDAP server, so it got done. Worked pretty well as I recall. But I wonder if the NoSQL cloud dbs are better for that now. Seems like couchdb would do it just well too.
Python: 'And then suddenly you have a language which says "we're all stuck with whatever the whiniest coder wants".'
They may not be a "shill"... but their bias is very clearly marked on their collar. :) I have seen them put out false stories and, upon finding they were fake, taking their own sweet time to post a retraction... dunno if that has gotten better over time or not. To be fair, it's not a normal practice, but it sure did seem a while before they retracted...
It's rather like the decided BeOS bias of osnews.com. :) It's obvious, unhidden, and taken with a grain of salt. Their level of scrutiny for anything not BeOS (or Haiku, I suppose) was legendary. It was pretty heavy biased toward windows with the new editor... I stopped reading when the community became Microsoft Apologists... there's only so much drivel one can take. :) heheh.
Bias is fine, if a publication stops trying to hide it. :)
It's the Stay-Puft Marshmallow Man.
Thanks, now I know what LDAP is, and I dont even have to read the article!
I don't know if you really know it, but just to be sure: it's a piece of shit.
LDAP means Lightweight Directory Access Piece-of-Shit-Protocol. It was created as a lightweight replacement for another protocol. Either the oldest one was designed by Cthulhu itself, or the designers were trolling the hell out of ourselves.
So, what's the deal with this PoS? The idea is to access data in a hierarchical storage. This was a system administrator's wet dream: every piece of information and configuration for a user, person, service, computer, and organizational unit, and everything neatly organized and in a single place. Even more, everything is Standard(TM)! Cool, you imagine. Yeah, I thought the same... but here ends the coolness. What follows is what happened at the IETF headquarters, just after the original idea was presented:
Someone said, "Surely not everyone should access the database! We must add authentication!". So, we bloated the protocol a bit, and now it's a directory access protocol that also handles authentication. Ok, maybe it's an acceptable tradeoff, everyone thought. But then someone else said "Since we added authentication to this protocol, we should use it as the central authority for all authentication purposes in our organizations!". WTF, this was designed for directory access, not for authentication. So, after this kludge, someone reasoned, "Since we now have to handle authentication, we need to use TLS on the same port where we handle the directory access! We wouldn't want authentication without an encrypted channel!". And then, another engineer, who was clearly stoned, said "Yeah, let's have that AND let's have an LDAPS protocol that is just like that but on another port". At this point, we can assume that he shared his drugs with the rest of the people involved and everyone said "YES!". And then, someone else, clearly influenced by object-oriented design and abstract data types, said, "We should have defined types, so people won't forget to add data that's important and everything stays consistent, even across organizations". And another one, clearly influenced by Stalin, demanded, "Ok, but people can add only what's explicitly defined, nobody is allowed to enter new data unless we allow it, no deviations whatsoever". Another engineer, clearly influenced by Evil(TM), added "Not only do they have to enter just the data that we will allow them to enter on our defined type, should they want new types for their organizations... they must ask an ID from IANA. Nobody is allowed to share their custom types on demand, they must first come to us". Finally, Cthulhu itself showed up, saw what they did, and said, "Puny insects, you can't design a protocol even if you tried. Protocols are tame unless they are difficult to manage and fail often". And everyone lost their minds and yelled "Let's make it painfully difficult to administrate! Let's add the worst databases the world has seen! Let's make it the most unaccessible service on Earth! Let's make DNS look like a failsafe service!".
This photograph was taken at the end of this meeting. It was 4th of July, and the engineers went outside while Washington DC was having a parade. A peaceful photo is superimposed to reduce trauma on the unlucky ones that choose to see it.
I rarely respond to comments. Also, don't ask for clarifications: a brain and Google are faster, believe me!
Wow. That's one very pessimistic view of LDAP, from someone who probably hasn't spent enough time using LDAP in the way it should be used in order to appreciate it's featues. So lets just address a few of your complaints (sorry if I miss anything, but it's sort of hard to quote and address things when you basically turned your post into work of literary fiction).
1) Supporting authentication is a bad thing? Really? So you have a DB-like source with loads of info about everything and everybody in your organization, and you don't think it's a good thing that people should have to authenticate before seeing it? Or that certain bits of info should only be available to certain users (which is impossible to do without authentication)? Or that while some people should only be able to view it, certain people can edit it, and different people may need to have rights to edit different bits of information (again, impossible without authentication)? I think you are totally off base here
2) Once authentication is there, you think it's a bad thing that we reuse this authentication to authenticate other services? You would rather create 2 separate sets of authentication credentials...one for the LDAP server, and one for the other servers? When you consider some of the purposes of LDAP, like being able to manage groups of users, and that on other servers you will want to reference those groups (like say, only users from department X can access this folder, and department X is defined as a group on the LDAP server), it doesn't make sense to want to do the authentication against LDAP since we'll also be doing the group member verification against LDAP?
3) I'm pretty sure you've got your security ordering mixed up. LDAPS came before TLS. TLS sort of unifies the two methods.
4) About the structure of the objects, LDAP is nicely extendable. It provides you a way to add features and services to accounts, so you can say "this entry is for a person", and then you get available to you only the attributes that apply to a person. Then you can take a subset of those accounts and say "these particular accounts have unix shell accounts" and then you get available to you additional attributes that apply specifically to the unix shell account. You can require that some of these new attributes be required, some optional, and you also assure that no entries will have these extra attributes set unless they've been designated as having that objectclass.
This extensible structure is sort of an alternative to how a relational DB would do it. In the DB, you would have to have a bunch of separate tables for all of the different services, and then link the tables together (so a generic object table, and then link that to a table for people, and then link that to another table for unix shell accounts, etc). Doing a query and joining all of those tables together can actually be quite a pain. With LDAP, you can simplay say "give me all objects that are for people with unix shell accounts". The query would be something like (&(objectclass=person)(objectclass=unixaccount)). That's it, and it will get you all the info about the object. By contrast, the query you'd do in SQL would be SELECT * FROM object INNER JOIN person ON object.id=person.object_id INNER JOIN unixaccount ON object.id=unixaccount.object_id. Which one is simpler? Now try to go further...try to get a list of everything that matches any of multiple criteria (example, has a unix account OR an email account). In SQL you'l have to start doing outer joins. Then filter it further...only get accounts where they've logged in to either system during the past 30 days. The LDAP filter would be something like
(&
(objectclass=person)
(|
(&(objectclass=unixaccount)(unixlogindate>=20110801))
(&(objectclass=emailaccount)(emaillogindate>=20110801))
)
)
You could actua