Mac OS X Lion accepts any password when authenticating via LDAP | Hacker News Reader

Mac OS X Lion accepts any password when authenticating via LDAP

forums.macrumors.com

279 pointsd0ne82 comments

News.YC community is being much kinder towards Apple than it acted towards Dropbox for identical security bugs. Dropbox even had the issue resolved in hours.

I don't see anyone threatening to switch away from Apple or demanding an immediate personal response from Steve Jobs or ranting how this lapse is unforgivable.

And you can't say it's because this bug only affects a small portion of Lion users as the Dropbox bug also only affected 100 accounts.

This is how bullying works.

If the victim is small and accessible, with their reputation on the line, you can put them in their place.

When DropBox broke, the community pounced.

Apple can't be bullied.

With DropBox I can just cancel my membership and sign-up somewhere else.

I'm not going to throw out my $1000+ Mac with $1000+ in software on it out the Window, right along with my livelihood of creating software for iOS. I'm not going to cancel my iPhone contract and pay hundreds in penalties too, and throw out all my apps and games and switch to Android. Not happening.

They've got us by the balls here, we just have to let them fix this and move on.

It's not bullying to tell people to fix security bugs.

It's not bullying to use your own resources to entice (or force) them to do so in a timely manner.

You're right that no one can threaten Apple and get action, but you're wrong in characterizing the threat as bullying.

The dropbox bug only affected 100 people? Or it affected everyone but only 100 people logged in with it? That's a big difference.

"According to our records, there were fewer than a hundred affected users and neither account settings nor files were modified in any of these accounts."

http://blog.dropbox.com/?p=821

Everyone was vulnerable for 4 hours.

The News.YC "community" is not homogenous. I find this just as odious as Dropbox's security issues, and just as indicative of a broken software development process.

Then again, it's Apple. I wouldn't normally even bother commenting here, because nobody from Apple cares. My finest rant would have epsilon impact on anyone at Apple, so why bother?

Dropbox, on the other hand, is present here. Someone might be able to convince them to change their practices for the better by getting on their case here.

That doesn't justify meanness, but a different response from this community over an issue from BigIvoryTowerCo versus OneOfOurOwn shouldn't be surprising.

It's because it's only for enterprise setups that use LDAP in the particular way described here. It's not every Mac OS X user, it's not every enterprise Mac OS X setup. If they had been using AD it would have worked. So really it's not as wide spread as DropBox's issue that was for every single user.

No. AD is fucked too, just in a different way. 5 minute logins anyone? And don't restart or you'll have to re-bind to AD.

> And you can't say it's because this bug only affects a small portion of Lion users as the Dropbox bug also only affected 100 accounts.

  - The dropbox issue was not initially reported as 100 exposed accounts, it was
    reported as "Dropbox vulnerable", that's something that alarms about 99% of 
    the HN readership.  
  - Dropbox is a YC company.
  - Dropbox is exposed to the world and the issue was seemingly 
    out of users control (until the facts were known).

By comparison, the OSX issue was initially reported as being LDAP specific which probably means it's not an issue for 99% of HN readership. The OSX issue can also be disabled, at great inconvenience I'm sure, but the point is you can protect yourself.

The OSX issue is a big screwup, but I see no mystery as to the response.

That's because lots of people here have dropbox accounts. Very few authenticate via LDAP to a Lion server.

People are a lot more emotional about problems when they're personally affected.

>News.YC community is being much kinder towards Apple than it acted towards Dropbox for identical security bugs

My old HN account got shaddowbanned after I talked shit about Dropbox when that happened. The post got a big number of points (more than anything else I had ever posted) and sparked interesting discussion, but I now know better than to question the Hacker News community's Sacred Cows.

>or ranting how this lapse is unforgivable.

I ranted against Dropbox because of the amount of people downplaying the severity, I'm not seeing that with this OS X issue (yet?). With the dropbox password thing, I saw a frequent argument, also used in their encryption scandal, one that really pissed me off. People were defending them with what boiled down to "you're stupid for expecting them to provide any level of service, as reasonable as it may be, unless their underlying tech doesn't force them to provide it".

Tells you something about Apple's testing methodology. QA team at Apple must be playing real fast and loose.

Being affected by 3 serious regressions in Lion (all filed as bugs and Apple closed them as duplicates, btw) - I get the feeling that Apple could do better at software engineering. (Alarms on iOS if you are still not convinced :) Just the fact that they release software that allows authentication without correct password means that they lack any kind of automated test case verification even for basic functionality - and this is basic functionality we are talking about, not some obscure thing that happens only when dozen different factors are combined or a thing that only happens once in billion tries.

Say what you will about Microsoft but in my several years of using Windows I rarely had these type of glaring issues even with the awful amount of hardware it supports. It might just be that Microsoft was forced to adopt better Engineering practices due to their situation - lot of complexity, huge impact potential, and lot of money at stake - 50% server market and the Server OS shares a whole lot with consumer version etc.

Not trying to troll - just my thoughts on something that I have always wondered - how Engineering culture varies between different successful software companies and to what effect.

I don't know about Microsoft. Their road to software quality has been long and hard. Do you remember Windows 95? How many new Windows versions did they ship before they got anywhere near the stability and reliability of *nix systems?

They're doing well these days, but it didn't happen overnight.

Also, although I'm not defending anyone, I've never worked on an operating system before but I can imagine QA isn't a walk in the park.

That's exactly my point. They started off not so great and made mistakes on their way but if you look at how they evolved their Engineering practices in response to grave realities - the XP pre-SP2 security nightmare for instance, created a lot of positive Engineering changes at Microsoft and with Windows 7 they have made a lot of tangible progress in that area.

OS QA is a pain - a huge one for Microsoft given the complexity and volumes involved. The pain is in dealing with unknowns and unpredictable combinations of thousands of different variables and what reaction it produces.

But for something like authentication there must be standard testcases that are automatically executed and verified - blank password authentication, wrong password auth should all be standard test cases that are executed automatically and no software should go out the door until those basics are looking good.

> Say what you will about Microsoft but in my several years of using Windows I rarely had these type of glaring issues even with the awful amount of hardware it supports.

I'm an ex-MS employee. One thing that really impressed me about my team at MS is the depth and quality of testing that was done. Unit tests, integration, fuzz, load, UI, regression, etc. All done in extreme depth, extremely efficiently, and across every supported SKU (and when you consider every possible OS, culture and .NET combinations out there, that's a lot)

I always thought that an interesting thing about Vista was that although it was widely seen as a horrible failure it wasn't actually highly buggy. It had horrible problems with performance and hardware compatibility, but the software itself didn't seem to contain glaring issues - at least if you calibrated your expectations to the perception of its quality by the market and end users.

On the other hand, Apple always nails the user experience - a release like Vista just wouldn't get out the door. But they let other horrendous quality problems through that would and should be caught by better process.

So it sort of illustrates two fairly orthogonal axes of quality and how different companies excel in different directions along those axes.

Tells you something about Apple's testing methodology. QA team at Apple must be playing real fast and loose.

Yep, I agree. I've been very disappointed with Lion, even taking into account the common "Don't buy an x.0 Apple product", there were some terrible bugs (I was personally bitten by the inability to look up DNS servers after waking from sleep, which I can't believe was missed in testing).

Apple's software quality has been markedly going down. iTunes is a UI mess, and I used to really like it. Safari continues to lag behind the competition (no omnibar/awesome bar? Really?), iWork has stagnated. I suspect the reason is that Apple is growing, and the Eye of Jobs is focused entirely on iOS products, so the quality is being diluted in other areas.

I strongly feel like Apple's leadership is looking f, orward to the day when they can kill off the Mac completely. The line of "we'll always need something for developers to develop on" doesn't make a lot of sense. With Apple on x86, I can see a future where Xcode lives on Ubuntu/Windows.

>I strongly feel like Apple's leadership is looking f, orward to the day when they can kill off the Mac completely.

Yeah - it sounds unrealistic for any other company but Apple is not at all shy of ignoring and finally dumping products that don't do great for their bottom line.

Either Xcode on Windows/Linux OR Web IDE - iOS App Development may be offered as a service. You develop on the web and submit code to Apple's server farm where specialized devices compile/deploy/run it and send it to your device to test it - maximum control for Apple. But I think that's a little too sophisticated - so might be a while!

Apple's software quality has been markedly going down

People have said the same thing about nearly every OS X release (with the possible exception of 10.1). At least Lion doesn't erase your firewire hard drives [1], or delete your entire home folder [2] etc etc. The comparative severity of these really bad bugs can be debated, but I think in terms of general quality OS X 10.0 − 10.2 really were quite a lot worse than the more recent releases.

I don't disagree with your general point though, the Mac is obviously not their priority anymore, and hasn't been for a while.

[1] http://www.wired.com/gadgets/mac/news/2003/10/61031

[2] http://macs.about.com/b/2009/10/13/snow-leopard-may-delete-u...

Yeah, this is true. Those ones were pretty bad.

Possible, but having gone from 8.6->Linux->10.4 myself, I think it's worth noting that 10.6, their previous release, was without question one of the most solid, stable, usable desktop OSes ever released by anyone. 10.7's instability and rough edges seem extraordinarily out of place by comparison.

Did you look at the linked articles? The second one is titled: "Snow Leopard May Delete User Accounts: Are You At Risk?"

It's nothing to do with how the Mac ranks in Apple's priorities. Apple security has been a joke, compared to Windows, for a very long time.

This looks both real and a pretty serious issue (I wonder how it went by almost a month without getting picked up by the security community). There's an discussion about it on Apple's own forums, linked below, but the gist of it is that users can authenticate over LDAP using any password using the login screen, and can't authenticate at all using su:

https://discussions.apple.com/message/15887083

Not many people in the security community use Mac servers in such a way that they need LDAP, and of those people, very few are running Lion on their servers.

Wouldn't Mac clients need LDAP for authentification too?

Are you saying that the fact that this issue doesn't effect many people means that it's not a serious security problem?

He's saying that since the issue doesn't affect many people it didn't get found right away. It is a serious security problem for businesses that use Mac OS X with LDAP. However, it's not a serious security problem for me.

It's been known for just under a month, since five days after OS X Lion was released, so that interpretation of his statement seems incorrect.

> This looks both real and a pretty serious issue (I wonder how it went by almost a month without getting picked up by the security community).

Followed by:

> Not many people in the security community use Mac servers in such a way that they need LDAP, and of those people, very few are running Lion on their servers.

Therefore, we see that Mr. Ptacek thinks "it went by almost a month without getting picked up by the security community" because "Not many people in the security community use Mac servers".

In the interest of expedience, let me be blunt: very few security researchers give a shit about how OS X Server uses LDAP.

We're all pretty busy lately, too.

(-2. You guys are funny. In case it matters: I'm not being snarky. They really don't).

It wasn't your bug to find, it was Apple's, and they should have found it far sooner.

Who are you talking to? Me? Did you read the comment thread? I'm not sure who you're arguing with, or why you picked me for this reply.

Yeah, you're right, I misposted. Sorry.

I wasn't entirely clear from the link — Are Lion servers not being picky about passwords, or are Lion clients not being picky about LDAP authentication failing (hence not being able to mount the user's home folder)?

If the latter, the impact is bad, but not as bad (you'll be able to get access to the machine you're sitting at, but not to any server-side resources).

Agreed that few are relying on Lion servers. But the security flaw is at the side of the Mac client, not the server. If you have Lion clients authenticating against OpenLDAD hosted on, say, a Linux server, then only the username is checked and any password is accepted. IMHO this is a serious security flaw that should be fixed as soon as possible by Apple.

Can someone give a quick lowdown on what's really happening here? I am assuming the Lion client is connecting to an LDAP server using the provided password, and regardless of the response from LDAP, Lion proceeds with the login?

No-if you try to submit a blank password it is (rightly) rejected. If you submit a non-blank password, the login succeeds. This (to me) points to the LDAP server responding with a login success message and the OS allowing the user in. This bug appears to only effect Lion clients talking to OpenLDAP (not the LDAP server shipped with Lion Server) or Active Directory.

I played with a Lion client bound to OpenLDAP running on a Linux server. I could login with my username and any password (empty or not). I used a packet sniffer and it appeared to me, that the Lion client is not even sending the password to the server, but simply logging the user in. At least in my case, the server didn't send any login success message, and the Lion still let the user in. It clearly seems to be an issue on the side of the Mac OS X client, not the server.

This is only an issue when binding to an OpenLDAP server. There may be additional issues with LDAP on Lion server, but this problem as reported is an issue with Lion clients bound to servers running OpenLDAP without Kerberos or SSL.

Your use of the word "only" here is misplaced. This is a very serious security issue that affects clients connecting to OpenLDAP.

Indeed-for users that are bound to OpenLDAP its a massive issue. Without knowing those users exact setup its hard to know exactly what the issue is-the fact that its ONLY OpenLDAP servers is odd. The client must be receiving some sort of authentication succeeded message (you will note that it won't accept a blank password-so in that case OpenLDAP is responding with a failure). It may be a bug in Lion that triggers a bug in OpenLDAP.

It may also be possible for an attacker to impersonate an OpenLDAP server in order to induce (and exploit) the behavior.

which is possibly quite a few university macs in libraries and computer labs.

Really? Can you name even one university that uses LDAP but not Kerberos for their computer labs?

Well, I could name one that almost certainly doesn't, but I'll refrain.

In the Universities I've worked with, or visited, the computers in the labs (Macs anyway) have all been using Kerberos in one fashion or another-AD uses Kerberos, so does OpenDirectory (OS X directory offering).

First, this is a terrible bug. Shame on Apple for not rushing a fix, but...

Enterprises should not be doing immediate upgrades to any operating system, no matter how sparkly. I'm still waiting to upgrade my MacBook, and it's just me. No OS release goes off without a hitch (though there are some pretty impressive Linux releases!).

In all fairness, someone has to be an early adopter, otherwise issues like this would go unnoticed.

I've no idea how complex a problem it is to fix, but it is worrying that it seems to be taking a while for Apple to fix it.

I think you are missing the point that the gp is making; any enterprise that this would affect should not be provisioning it to the servers/clients until they test it on a smaller scale. This issue would be found during the normal testing channels of enterprise adoption.

I had to upgrade to continue using the latest Xcode, although I'm not running that on Server.

Nothing worse that righteous preaching...who knows what the op reasons are for upgrading...there could be very compelling reasons to move very quickly especially with Apple. Some models of newer Mac won't run anything older than the current OS release

There have long been issues with LDAP in Mac OS X. They don't use a standard version. It doesn't work with PHP's LDAP module. And there have long been security issues, too: PHP was often out of date with security vulnerabilities. So much so that our campus ended up blocking all Mac web servers.

Here are several other issues I wrote up a couple of years ago, the last time I was forced to use Mac OS X server: http://edtechdev.wordpress.com/2009/01/31/dont-use-mac-os-x-...

If you're hosting PHP on a Mac, I'd hope you're using a package manager so that you're not depedent on Apple to update third party software. Perhaps they should be providing timely updates to third party items that they include, but depending on those updates is foolhardy.

Can anyone confirm or deny that this is only an issue when authenticating to an OpenLDAP server (i.e. does it also affect authentication against Active Directory?) I will check it when I get to the office and update here. This could potentially be very serious.

Active directory works as you'd expect.

We just got some Lion iMacs and have not been able to keep them connected to the AD. It doesn't work as expect unfortunately.

Are you talking about the "Network accounts unavailable" red light? If you wait ~20secs, it generally resolves itself. Definitely a bug, but just an annoying one.

Yep, that's the one. We've tried waiting and even increased the timeout from 2 seconds to something higher and it's still not working.

Says this is a solution: https://discussions.apple.com/message/15700245

What alarms me is that on both of my computers with Lion, about half of the time just clicking on a name on the login screen works without entering the password. Happens on my friend's Lion install as well.

I have authentication on after every screensaver and I've never been able to bypass the password. Weird.

Likewise. We're an all-Mac shop, we do semiregular audits of everyone's machines, and I've never seen this happen.

I have never had that happen to me on all 3 of my Lion machines. Could you elaborate some more about your circumstances with this glitch?

I'm going to guess that this is very simple; he probably just has the option for requiring a password at login turned off, or is using Fast User Switching enabled (i.e., the user is question was not really logged out, so logging in and entering a password is not required), or something like this.

There is an option "Require password <time period> after sleep or screen saver begins" in the Security preferences, general tab. I'll bet yours is set to something other than "immediately".

This happens after I explicitly log out of my user account, though.

Is the mentioned option set to something else than "immediately"? If it allows you to log back in that certain period of time after explicitly logging out, which it shouldn't (it should only work that way after sleep or screen saver begins, from its description) it might be a bug in OS X itself. You should try testing it a bit more and submit a bug report on http://bugreport.apple.com/ if it indeed looks like a bug. :)

Apologies, I totally missed the phrase "login screen" in your post.

I've seen this story in 4 or 5 places today and I still can't seem to find the details of the issue. Anyone have any links or info?

Snow Leopard is the Windows 2000 of the NeXTSTEP operating systems, the best example of the series before the inevitable decline.

Oh yikes. This deserves an update... yesterday. How can it be discovered and discussed only a month later?

Shows just how often its actually used in the wild.

Only happens if OpenLDAP is not secured by Kerberos or SSL... I don't see this as very common in the first place (ie, cleartext over the wire for auth?!).

OpenLDAP is... kind of a piece of junk. I'm not surprised there are issues here. But again, who binds in cleartext?

Why are they not using Kerberos and SSL though? Does this affect those users who actually do take security seriously or just the bare bones implementations that aren't safe anyways?

This got downvoted but is a perfectly valid question, since LDAP->OSX authentication is used virtually exclusively on internal networks where the assumption needs to be that attackers can see network traffic anyways.

I don't know about Macs specifically (Apple makes servers?) or why they aren't using Kerb, but LDAP is commonly used over SSL/TLS. "LDAPS" some call it.

LDAP wasn't originally designed to be an authentication protocol. If Mac clients are using it to make authentication decisions, they had better be requiring SSL/TLS on that connection (and validating the server cert perfectly, too).

Apparently, the forum poster says he's not using SSL/TLS with LDAP for the login authentication.

Sounds to me like impersonating an LDAP server would grant login to Macs configured thusly.

Not entirely relevant, but Lion's Kerberos is pretty funky as well. Apple switched to Heimdal from MIT, supposedly marked the Heimdal API 'private' and provided a worse than broken shim between the MIT API and Heimdal.

<snark>Well, it is intended to be a lightweight protocol after all.</snark>

Not sure why you are in gray. That's a really good joke.

Reply on news.ycombinator.com