Slashdot Mirror

← Back to Stories (view on slashdot.org)

Mac OS X Lion LDAP Vulnerability Emerges

Posted by Soulskill on from the mash-keyboard-for-access dept.

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.

65 of 97 comments (clear)

  1. Thanks, now I know what LDAP is by hardtofindanick · · Score: 1

    and I dont even have to read the article!

    1. Re:Thanks, now I know what LDAP is by _xeno_ · · Score: 1

      Plus I learned that IT is using LDAP wrong where I work! They use it to authenticate user accounts on the various servers that contain "repositories of highly sensitive enterprise data" but apparently those are supposed to be stored on the Lightweight Directory Access Protocol server itself.

      What do you know - I'll have to fire off an email to IT and ask them to transfer our SVN repository (accessed via SSH) to the LDAP server.

      --
      You are in a maze of twisty little relative jumps, all alike.
    2. Re:Thanks, now I know what LDAP is by DrgnDancer · · Score: 1

      Technically you can use LDAP to store information. Being an an auth/user database is only part of what LDAP does. It's more like a lightweight non-relational database than anything (I realize that isn't quite right, but it's a reasonable comparison). One of the things that nearly any LDAP tutorial has you do is create a shared address book for instance. Indeed, if you look at the most popular LDAP system currently available (Microsoft's Active Directory) you'll see that it can store all sorts of potentially valuable information about users. From their contact info to there access levels.

      --
      I don't need a million points of light, just two points of multi-mode fiber and a 10 Gig-E router.
    3. Re:Thanks, now I know what LDAP is by interval1066 · · Score: 3, Informative

      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".'
    4. Re:Thanks, now I know what LDAP is by elsurexiste · · Score: 3, Informative

      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!
    5. Re:Thanks, now I know what LDAP is by arglebargle_xiv · · Score: 1

      It's more like a lightweight non-relational database than anything (I realize that isn't quite right, but it's a reasonable comparison).

      It's actually a heavyweight pre-relational (hierarchical) database of the type used in the 1960s before relational databases were invented. Many LDAP servers actually use an RDBMS underneath, with LDAP being an additional mapping layer on top of the standard database (others use key/value stores like Berkeley DB, but again you have to add a hugely-complex mapping layer because LDAP isn't anything like the key/value store that it's using for its storage engine). The only LDAP server I know of that uses a storage engine that's even close to what LDAP does is (supposedly) Novell's Recman (although that may just be marketing propaganda, since they ditched Recman some years ago).

    6. Re:Thanks, now I know what LDAP is by WebManWalking · · Score: 1

      I agree with what you said. ((Please moderate parent up.))

      But I can't help but wonder if they're talking about Lion Server, which is optional and costs significantly extra. I don't see "PoS Directory/Authentication Mess" in the Sharing preference pane.

    7. Re:Thanks, now I know what LDAP is by LordKronos · · Score: 2

      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

    8. Re:Thanks, now I know what LDAP is by elsurexiste · · Score: 1

      To be honest, I was aiming for "Funny", but got "Informative" instead. Since we are serious, I guess I'll answer like an adult :) . Believe me, I spent too many hours on LDAP to have any love for it. I even contributed a few scripting lines to the OpenLDAP page in Ubuntu. Just look at Amplicate and you'll see I'm not alone ;) .

      I'm not against authenticating. I would have liked authentication and LDAP to be defined/handled separately, though, not in a single protocol. Everything ends up cleaner. LDAP remains as a truly lightweight directory access protocol, it defines operations and that's that. It's not even a new idea: Kerberos is just an authentication protocol. That would have saved us from the present situation: we authenticate against LDAP not to see its contents, but to know if we can authenticate. If we use a relational database instead of a hierarchical one, we may as well use PostgreSQL or SQL Server just to know if the user is allowed to proceed instead of querying its data. Sounds too much like a hack, even if we query data about users and groups once they log on.

      I mixed up TLS and ldaps, you got that right. I guess it was the port numbers.

      For some reason, when I started filling objects, I thought they were more like prototypes, not classes. Maybe because I was too influenced by Self or Python. Or maybe because I expect information about an account to be fixed and predictable, but not for a person. After all, when I put people in my contact list, I add info about them that's not defined on the metadata, like T-Shirt size. In my particular case, I needed to add a PGP fingerprint to a bunch of people. So, I had to create a whole new class to store a single piece of additional data.

      Although you surely know it, you can use views to speed the whole stuff up in RDBs. Oracle offers an LDAP solution built on top of its relational database, after all. As to which is simpler... I agree that's is small and somewhat legible, but it's like saying DVORAK keyboards are faster. Nobody would say otherwise, yet the number of people that uses it is smaller.

      Which leads us to the syntax. Whereas I just complain about authentication and ldaps/StartTLS, the syntax really anguishes me. Especially the domain component chains. I understand that the protocol is old, but why do we keep using dn: cn=John Doe,dc=example,dc=com. I suffered because I had a domain once that was goddamn large, so I had to painfully type it again and again.

      As for command line interfaces... I guess it's vendor-independent because I hated OpenLDAP while a friend raged against ActiveDirectory. Administration with the CLI is hard as hell. I don't doubt you are experienced on it, but grant me that it isn't user-friendly.

      Finally, naturally I didn't went to IANA for an OID, but they advise you to use one if you want to share it... which is crazy nonetheless. If a schema is private, the most likely place to get the latest version is with that private party.

      I know we aren't going to completely convince the other one, but you are right, I have to give a clear message if people are to decide objectively.

      --
      I rarely respond to comments. Also, don't ask for clarifications: a brain and Google are faster, believe me!
    9. Re:Thanks, now I know what LDAP is by rakaur · · Score: 1

      I agree with what you said. ((Please moderate parent up.))

      Wow, so that's how the moderation works on Slashdot. I knew it!

  2. Actually.... by Jon.Laslow · · Score: 1

    Actually, this is only a problem if you can actually get Lion to bind to your AD Domain in the first place. Stupid legacy .local domain suffixes....

    1. Re:Actually.... by citylivin · · Score: 1

      just turn off bonjour with iservebox , but that might be a new bug because I dont even think the new macs come with bonjour.

      And I haven't had to do that since 10.5 IIRC. In short, that problem no longer exists (well at least on my .local domain).

      --
      As a potential lottery winner, I totally support tax cuts for the wealthy
    2. Re:Actually.... by dakameleon · · Score: 1

      ...because I dont even think the new macs come with bonjour.

      Say wha...? If anything, Apple's increasing its use of bonjour. It's baked into iOS and certainly still being pushed in the latest OS X.

      --
      Man who leaps off cliff jumps to conclusion.
    3. Re:Actually.... by LordLimecat · · Score: 1

      .local is there for a reason. It ensures that if you do not want any internal DNS to resolve externally and are not answering DNS requests from the outside, that your Domain Controller's DNS doesnt supercede legitimate domains.

      Take for example a company that wants to use foo.com as their internal domain. If they host all external foo.com services "in the cloud", naming their internal dns domain "foo.com" will hose the ability for anyone on the domain to properly resolve the external addresses. To fix it you would have to manually update your internal DNS A records every time you made a "cloud" change; you would no longer have a single place that lookups occurred to.

      To fix that easily, you use foo.local. Foo.com addresses will properly be resolved at the authoratative NS, and the foo.local records are guarenteed not to be resolvable on the internet (as there is no .local root nameserver).

    4. Re:Actually.... by geekboybt · · Score: 1

      Add ".local" to the front of your search domains, and you'll be back in business.

      Signed, another admin who got screwed when they decided to use .local for Bonjour.

    5. Re:Actually.... by LordLimecat · · Score: 1

      It makes very little sense to combine the two into one, when they share completely seperate address space, are on completely separate ISPs, and one half is supposed to be unresolvable by design. Putting them in the same DNS domain would be bad design; you will either have a non-authoratative DNS server claiming to be authoritative for a domain, or you will have unreachable RFC 1918 addresses in your public DNS.

      The first scenario leads to the breakage I mentioned, and is the worst kind of kludge since it makes it much harder to diagnose issues with nslookup. No longer can you simply do a nslookup on NS records to find out who hosts your DNS, since you now have two independently resolving sets of DNS nameservers with no linkage between them; and it is a pain to figure out what has been done if you ever hand off to another tech (since again it is a nonstandard kludge and wont show up in a nslookup query). In a nutshell, DNS is hierarchical, and your plan would split that hierarchy in two.

      The second scenario is utterly retarded as it means you would have every DHCP record in your domain recorded by a public DNS, and Im not even clear on how you would get that to work. You would also be publishing for the whole world to see the entire layout of your network.

      Using .local is best practice as recommended by MS, and for darn good reasons. You can also, of course, use internal.foo.com, which isnt so bad, but using foo.com is a really terrible idea and if you ever do it you will find yourself regretting it (and probably having to rename your domain) shortly thereafter.

  3. Re:Server problem by Spad · · Score: 2

    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.

  4. User Error by notKevinJohn · · Score: 1, Funny

    Don't worry, I am sure Apple will soon release a statement explaining that LDAP works on Lion as long as you hold your laptop in the correct way.

  5. Security theater a little by vlm · · Score: 3, Informative

    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
    1. Re:Security theater a little by boxxa · · Score: 1

      LDAP if interfacing with AD can get you user credentials for domain admins, server admins, server name objects, login history with IP ranges, etc. Simply a user login can get you email access to anyone in the company and I am sure no matter what company you work for, your CEO would not be happy with their emails getting leaked.

      --
      Bryan
    2. Re:Security theater a little by 0100010001010011 · · Score: 1

      They're using LDAP for authentication.

      Meaning if we have a network of linux, windows, mac, etc machines all served by a LDAP backend run on Lion, then I can login as you.

    3. Re:Security theater a little by Spad · · Score: 5, Informative

      *IF* this vulnerability allowed you to authenticate to AD Domain Controllers with administrative rights then you would be able to dump the SAM database and potentially gain access to all of the user credentials, but then if you could authenticate to a DC as an admin why would you bother when you can just setup your own credentials or modify account permissions directly?

      But it doesn't, so you're getting usernames, machine names, a bit of contact info, a lastlogontimestamp and a few other bits and pieces that in most cases anyone with regular user credentials on the domain would be able to access anyway (Most people don't seem to realise that a lot of fields on AD accounts are readable by any authenticated user).

      Except you're not even getting that because as far as I can tell this only affects logging on locally to an OSX Lion client.

      Storm, meet Teacup.

    4. Re:Security theater a little by vlm · · Score: 1

      They're using LDAP for authentication.

      Meaning if we have a network of linux, windows, mac, etc machines all served by a LDAP backend run on Lion, then I can login as you.

      Yeah that's exactly what I meant, I didn't know anyone did that. Currently and always LDAP for directory stuff (full name, uid, home dir) and kerberos for password auth everywhere I've ever been. Never seen a place with just ldap deployed, but then I've pretty much avoided hard core microsoft areas, per posts above thats just how those guys roll. I would imagine doing password auth over ldap is kinda like serving up web pages on the internet over nfs instead of http, I mean you could do it, but isn't it ... just wrong? I mean outta the box, ldap isn't even authenticated and encrypted itself, is it? Is ldap even theoretically capable of preventing a MITM attack (maybe using SSL?) Use the right tool for the job and do auth in kerberos...

      --
      "Science flies us to the moon. Religion flies us into buildings." - Victor Stenger
    5. Re:Security theater a little by ulzeraj · · Score: 2

      I've seen quite a few mid-sized companies storing passwords on pure ldap and controlling access through LDAP ACLs allowing only the admin to see the userPassword field besides its owner. You can consult everything else anonymously. Thats pretty common on smbldap-tools and some samba domains managed by SuSE YaST that I've met.

    6. Re:Security theater a little by jimicus · · Score: 1

      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 have. There is a PAM module that does an LDAP password update. The biggest problem is that there's about a hundred different ways you can configure it, every Linux distribution makes different assumptions about your environment - assumptions which can change between versions - and this almost invariably leads to interoperability problems. Fortunately they all use the same libraries so you can generally dump a known-good set of config files in the appropriate place in /etc and away you go.

    7. Re:Security theater a little by Anonymous Coward · · Score: 2, Informative

      Yeah that's exactly what I meant, I didn't know anyone did that. Currently and always LDAP for directory stuff (full name, uid, home dir) and kerberos for password auth everywhere I've ever been. Never seen a place with just ldap deployed, but then I've pretty much avoided hard core microsoft areas, per posts above thats just how those guys roll. I would imagine doing password auth over ldap is kinda like serving up web pages on the internet over nfs instead of http, I mean you could do it, but isn't it ... just wrong? I mean outta the box, ldap isn't even authenticated and encrypted itself, is it? Is ldap even theoretically capable of preventing a MITM attack (maybe using SSL?) Use the right tool for the job and do auth in kerberos...

      I've worked where LDAP is used for authentication, lots of applications support using just plain LDAP for authentication. However, these applications also support SSL-encrypted LDAP, so the data is secure in transit. LDAPS is what that's called, and it's on port 636.

      So companies do use LDAP for authentication, yes. And it can be secure in transit, yes.

    8. Re:Security theater a little by v1 · · Score: 1

      it's also worth noting that the LDAP database, though encrypted, can have its password reset if you know which bits to twiddle. the server has to be able to access it, after all.

      But that's true of any system that doesn't require a password during boot

      --
      I work for the Department of Redundancy Department.
    9. Re:Security theater a little by chemosh6969 · · Score: 1

      You're acting as though system/network admins are usually qualified and know what's going on. I usually see guys that talk a lot as if they know what they're doing but don't actually understand what they're saying and rely on people lower on the totem pole to actually get anything done. Now you just have to rely on those guys to know what they're doing which isn't always the case.

    10. Re:Security theater a little by Kalriath · · Score: 1

      Actually, the login history is stored in the event log if auditing is enabled - the LDAP user store contains only the last login date, nothing more. You also cannot get the password from Active Directory (you have to crack the SAM on the server). You certainly can't access the mailboxes using only the details in AD since you have to authenticate with the Exchange server using a valid Kerberos ticket (NTLM requires you already have the password) to get those.

      --
      For a site about things like basic rights, Slashdot users sure do like to censor "dissent".
    11. Re:Security theater a little by Kalriath · · Score: 2

      Contrary to boxxa's completely fabricated post, NT domains aren't that insecure. For a start, Windows uses LDAPS for communication with the LDAP server, and second the authentication is all done using Kerberos v5. Logon history is not accessible over LDAP or even remotely at all short of remote event log viewing, user passwords cannot be retrieved via LDAP and you cannot access anyone's email just by getting some details out of LDAP.

      --
      For a site about things like basic rights, Slashdot users sure do like to censor "dissent".
    12. Re:Security theater a little by bk2204 · · Score: 1

      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.

      Debian uses LDAP and does not use Kerberos. I presume that they store the passwords in LDAP in the standard fashion.

    13. Re:Security theater a little by LordLimecat · · Score: 1

      I dont believe that the user password hashes are stored in the local SAM of a domain controller; Im fairly certain it is stored within directory services. Certainly samdump does nothing on a DC.

    14. Re:Security theater a little by buchanmilne · · Score: 2

      Firstly, this vulnerability has nothing to do with the LDAP server, or owning the LDAP server. It is effectively as if Mac OS X, when configured for LDAP authentication, has a 'auth sufficient pam_permit.so', so the client will accept any username or password. However, this doesn't imply any access to the LDAP server ...

      Once we own an LDAP server we own everything

      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 have a few, where Kerberos is not really viable, and (since almost all access to anything is via ssh with public keys - but stored in LDAP), the passwords aren't really the issue, but the ssh public keys could be replaced ...

      I would think it would be kind of awkward, like using cfengine to do moves/adds/changes inside your passwd file.

      Why would it be any less awkward than Kerberos (besides the actual SSO part, but if you're not actually doing GSSAPI auth anywhere after login it is irrelevant)?

      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.

      Almost all Linux distros have tools to configure a box for LDAP authentication, most of them get it right to set 'passwd' up so that it works correctly ... even if you didn't have that, you could use 'ldappasswd' to change your password (but, it is probably a bit too inconvenient for most users).

      However, if you have password policies configured (e.g. with slapo-ppolicy on OpenLDAP), and users log in to a display manager, they would be prompted to change their passwords on login (without having to touch the command line), just like you could do with Kerberos.

    15. Re:Security theater a little by buchanmilne · · Score: 1

      No. This is a vulnerability in the client-side portion, as if you had configured a linux client with:
      auth sufficient pam_permit.so

      It should have no effect on any other clients.

    16. Re:Security theater a little by deniable · · Score: 1

      To be charitable, we're not all incompetent. We're just under-staffed and under-budget. We then get the Boss With Ideas telling us how to run deployments and requiring easy access for the important / loud / connected users.

    17. Re:Security theater a little by deniable · · Score: 1

      It would be an interesting training exercise to figure out how you'd make all of that true. You'd most likely have to extend the schema with an 'unencrypted password' field and a direct link to web mail.

    18. Re:Security theater a little by smash · · Score: 1

      hush, don't let the facts get in the way of a good headline.

      I believe the largest use of LDAP only auth is actually in.... free software. Anything semi-professional generally uses kerberos for auth...

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    19. Re:Security theater a little by smash · · Score: 1

      So you're saying its a debian vulnerability....

      --
      I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
    20. Re:Security theater a little by Kalriath · · Score: 1

      You might be right actually - I believe there is an attribute within ADS which is only visible to administrators which may contain the (irreversible) password hash.

      --
      For a site about things like basic rights, Slashdot users sure do like to censor "dissent".
    21. Re:Security theater a little by Kalriath · · Score: 1

      Well, if you're running Exchange 5.5 it's easy - if you authenticate as an administrator, Exchange 5.5 will let you open any mailbox.

      --
      For a site about things like basic rights, Slashdot users sure do like to censor "dissent".
    22. Re:Security theater a little by deniable · · Score: 1

      You can do it with the right group memberships on the later versions. OK, so we need the administrators password unencrypted in the LDAP.

    23. Re:Security theater a little by LordLimecat · · Score: 1

      I found this out when we had to do password recovery on a DC, without either the domain password or the AD repair mode password. Its a multistep process, where you first have to use a boot disk to reset the recovery mode password, boot into directory services restore mode, and then change the domain admin password. The bootdisk is unable to do anything to domain passwords, because theyre not stored in registry.

  6. Re:but... by Anonymous Coward · · Score: 1

    If by "secure" you mean it won't execute W32.Blaster.Worm then yeah, it's secure.

  7. Re:but... by dimeglio · · Score: 4, Insightful

    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.
  8. Is this AD or just straight LDAP? by xrayspx · · Score: 1

    I've been unable to reproduce this with AD authenticated Lion 10.7.1. The stories I've read referenced OpenLDAP and LDAP in general, but I haven't seen AD mentioned yet. Has anyone gotten this to work with AD?

    --
    I like music
    1. Re:Is this AD or just straight LDAP? by NatasRevol · · Score: 1

      It's an LDAP only issue. If you're using Kerberos/AD, then it's a non-issue.

      --
      There are two types of people in the world: Those who crave closure
    2. Re:Is this AD or just straight LDAP? by xrayspx · · Score: 1

      Thanks, the articles and threads available over the weekend were kind of skimpy on detail.

      --
      I like music
  9. Re:but... by _xeno_ · · Score: 2

    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.
  10. This sounds like an ACL issue. by Zombie+Ryushu · · Score: 2

    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.

  11. Uh.. What? by synthesizerpatel · · Score: 3, Insightful

    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.

  12. Re:but... by Mitchell314 · · Score: 1

    lol, I'm a mac user but even I'll never claim that they're the most secure OS. IIRC Apple has an even more horrible track record of addressing bugs than MS.

    Of course, the best (and hardest to achieve) security comes from smart vigilant system admin and smart users. The best operating systems can do is to make their work easier and not undercut their efforts (with serious vulnerabilities, autoplay, weak permissions, etc).

    --
    I read TFA and all I got was this lousy cookie
  13. Ergh, horrible article is horrible. by Darkinspiration · · Score: 1

    Seriously, would it kill them to do better then forum reading and printing post almost verbatim. The issue as i understand it is that if you have a mac os 10.7 open ldap server or apple open directory it will either not let user login or let them login without password. but nobody has any details, or my googlefuu failed me... Still that should have been caught in beta.

  14. Re:but... by jo_ham · · Score: 2

    I guess that's what happens when you use OpenLDAP.

    Silly Apple.

  15. Re:but... by CharlyFoxtrot · · Score: 2

    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.
  16. Re:but... by tibit · · Score: 1

    I've been running Fedora Core on an iMac for a good while. Mostly to play Doom 3 and Quake 4 -- somehow those games never get tiring for me. Yep, I'm too cheap to shell $50 or so out for an OS X version of the same :)

    --
    A successful API design takes a mixture of software design and pedagogy.
  17. This has been on a few sites by jimicus · · Score: 4, Informative

    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.

  18. Re:but... by Anonymous Coward · · Score: 1

    Well the Mac in this case is the threat and not the vulnerability. So from that perspective, the Mac itself remains secure.

    Actually, in this case the Mac is a vulnerability, and thus becomes a threat. From what users are reporting, the Mac doesn't even try to authenticate against the LDAP server. It just accepts any password blindly and let's the user login.

    Not a bug with LDAP - just a failure with how Apple has implemented LDAP authentication in OSX Lion.

  19. Re:but... by Doctor_Jest · · Score: 2

    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.
  20. Doesn't work with OpenDirectory by gozar · · Score: 1

    I just tried it with a Lion client bound to an OS X 10.6 server using OpenDirectory, and I couldn't replicate the problem.

    So is Lion doing something non-standard when connecting to OpenLDAP servers? I noticed that in the main thread it was mentioned that they weren't using the full Apple LDAP schema.

    --
    What, me worry?
  21. Re:but... by smash · · Score: 1

    Yeah, they're called girls.

    --
    I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
  22. Servers? by justforgetme · · Score: 1

    You use mac OSX on servers? and what do you do with linux then?

    --
    -- no sig today
    1. Re:Servers? by catmistake · · Score: 1

      and what do you do with linux then?

      Linux is for Windows fail. Microsoft breaks it... Linux fixes it. That is its prime reason for existing. The fact that Linux makes a fast, stable server platform is purely an unintended side-effect, call it a happy accident, of not being Windows.

      --
      The Admin and the Engineer
  23. Re:Server problem by deniable · · Score: 1

    It's just like the security problem with Samba when it let you look at parent directories and Windows servers honored the request. Apple will learn just like Microsoft did.

  24. Re:Yay for vulnerabilities! by stewbacca · · Score: 1

    Or it will be patched within weeks and will be part of the next Software Update. What precedent can you provide that would suggest otherwise?

  25. Possible Solution by Alan+Evans · · Score: 1

    My company uses OpenLDAP for user authentication in the datacenter and ran across a strange problem that seems very similar to this. It was present in at least OpenLDAP 2.4.16. We tracked it down to a weird problem in the password policy overlay. If I recall right it was the password policy overlay was returning a successful response to updating the last failed login time attribute but that was being passed up and causing binds to return true also. Our solution was to remove the password policy overlay and we have not gone back to revisit it.

    I do not know if OpenLDAP in Lion uses the password policy overlay but if it does it would be an easy test to disable it and see if the problem persists. I post here because I don't really feel like registering to a Mac related forum that I will only post once on. I hope someone finds this and finds it useful.