> 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.
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.
>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".
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.
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.
> 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.
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 , or delete your entire home folder  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.
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.
>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!
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.
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:
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.
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.
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.
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.
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!).
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.
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.
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.
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'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.
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. :)
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.
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.
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).