I think I'll hold off on that 10.13.1 "security update" it keeps bugging me about. Seems to let anyone use my computer...
Edit: After looking a little further, it seems staying on Sierra will always be a 10.12.* version, and High Sierra is 10.13.*?
- Mavericks (10.9.x)
- Yosemite (10.10.x)
- El Capitan (10.11.x)
- Sierra (10.12.x)
- High Sierra (10.13.x)
https://www.reddit.com/r/linux/comments/7hj6v/i_use_my_login...
Maybe they need to re-think their hiring process, because clearly something is not working as it should.
2. Add a complex root passphrase and clean this up after the fix is released.
3. Reflect on how irresponsibly this serious security bug was ‘reported’, he didn’t just potentially miss out on $200,000, he put an enormous number of people at risk of local intrusions when instead if it was properly reported there’s a good chance Apple would have released a bug fix for this quicker thus reducing the potential impact and spread of misinformation.
https://en.m.wikipedia.org/wiki/Responsible_disclosure
https://support.apple.com/en-au/HT201220 (See ‘Security and privacy researchers’)
He did not put people at risk, he showed people they are already at risk, so they would know to set a root password, and thereby not be at risk.
Security by obscurity does not work!
If it’s not publicly known and is a security risk it is far more effective to directly contact the developers / companies security team so they can immediately work on actually protecting people by developing a patch. If they don’t respond quickly (subjective, I’d call it within 12 hours) or fail to issue a fix in a timely manor (subjective, I’d say 24 hours) then yes - go public, start by logging a bug report and link to that bug report or if you can’t - the bug number / reference.
https://tctechcrunch2011.files.wordpress.com/2017/11/ooooooh...
"Can someone here explain to me what is the login dialog supposed to do? ... Ok. Then why the !@#% doesn't it do that???"
In the Spotlight Search type "Terminal" and press enter.
At the terminal type "passwd" and press enter.
The terminal will prompt you to change the password for "root".
Waiting for a fix before disclosing a security flaw is security by obscurity, even if it is to be replaced soon.
It is best for users to know that their system is vulnerable, and how to fix that without waiting for a system update.
Citation needed.
> "It is best for users to know that their system is vulnerable, and how to fix that without waiting for a system update."
Stepping outside the 'tech' social bubble, most general users likely won't create a root account and password from something they see on TV or their local news site or at least not before a patch would have been released.
--
Further to previously provided examples:
https://www.cloudflare.com/disclosure/
https://access.redhat.com/security/team/contact
https://www.xenproject.org/security-policy.html
https://about.gitlab.com/disclosure/
https://help.github.com/articles/responsible-disclosure-of-s...
https://www.kernel.org/doc/html/v4.10/admin-guide/security-b...
https://www.drupal.org/drupal-security-team/general-informat...
https://www.cisco.com/c/en/us/about/security-center/security...
https://www.juniper.net/us/en/security/report-vulnerability/
Has there been an update released yet? I wouldn't know, I don't use OS X.
Is this the best way to report a security flaw? Of course not! Is it a bad way? No! The only bad way to report a security flaw is to not report it at all.
That does not make it malicious.
Sure, there are more malicious people aware of this security flaw, but there are also more users aware of this security flaw, and the simple steps they can take to mitigate it.
Since this is a flaw any user can run into, I wouldn't get so mad about someone who doesn't know best practice running into it.
I am much more concerned that such an obvious tractable flaw exists in the first place.
Until Apple forces me to with a required xCode update for the newest iOS SDK...>.>
sudo dscl . -passwd /Users/root $(uuidgen)
It's a big world out there, especially nowadays. And nothing I've seen in recent history suggests to me the average user knows or cares about infosec concerns beyond basic hindsight understandings.
Agile Software Craftsman, iyzicoder @ http://www.iyzico.com , Founder of Software Craftsmanship Turkey @scturkey, The community guy http://bit.ly/lemiorhan
I'm not convinced private disclosure is without its downsides nor a panacea.
Not impossible to believe he's unaware of the right way of handling this kind of issue, but that banner photo (Enthralling My F-ing Audience) [1] and stats there suggest he should be aware that there probably are sensible and polite procedures for this, even if he didn't immediately know what they were.
[1] http://jesuschristsiliconvalley-blog.tumblr.com/post/4653787...
From his Twitter account, he's not just some layman stumbling across it.
Agile Software Craftsman, iyzicoder @ http://www.iyzico.com , Founder of Software Craftsmanship Turkey @scturkey, The community guy http://bit.ly/lemiorhan
> Has there been an update released yet? I wouldn't know, I don't use OS X.
I think you might have misunderstood what I meant when when asking for citation, it's based on the statement you made in relation to citing sources for what something that could be opinion stated as fact.
https://libguides.mit.edu/citing
> Is it a bad way? No!
OK this is where I stop feeding the troll.
Password change is the only protection until it is patched.
``` dsenableroot ```
utility; by first enabling the root user with a strong password, then disabling it with the
``` dsenableroot -d ```
option. It's heavily recommended to not leave the root user enabled.
I'm guessing it probably would've been a fairly big chunk of change.
At least if it'd been open, maybe someone could have diffed it …
High Sierra seems to be focused in Emojis. Urghh
Disabling root re-enables the blank password to root.
How to set root password.
https://finance.yahoo.com/quote/AAPL?p=AAPL
A higher risk, higher leverage bet: buy some put options the milisecond markets open:
I'm still on 10.12 Sierra. Long ago I stopped major updating when those releases were new. I learned to wait months or many months for bugs to be dealt with and for older software to be updated to be compatible with the new release. High Sierra provides nothing critical that Sierra does not provide, and thus, I am happy in my position as late adopter.
Might be a bad day to leave the laptop at the table at the coffeeshop when ordering.
He's a manager. CSM, PSM1, PSD1, Scrum Master, Kanban Practitioner. Code retreat facilitator. Translated Agile Manifesto into Turkish. The only thing that immediately makes me think he even touches code is "git trainer and lover." Notably lacking from his résumé: references to specific open source projects he's worked on or code he's written (though personally, I'd be concerned because his résumé does list "Restful Services" and I'd expect that to have given him a taste of infosec basics, but maybe it's a bit of résumé padding... shouldn't it be spelled "RESTful services?" ;) ).
It feels weird to say for those of us deeply immersed in the internet / telecoms / web app side of software development, but depending on your focus, you can do an awful lot of software development without ever brushing up against the sharp edge of infosec.
After 8 months of living hell using their overpriced MacBook Pro, I'm moving to Surface Pro (running Xubuntu, though).
"Oh, good boy. Thanks for the responsible disclosure. You're sure you haven't told ANYONE else about this? Great! Keep it that way and we'll send you a big check real soon. Promise!"
Coordinates acquired.
Boom.
Keep in mind, Apple was caught working directly with NSA in Snowden disclosures. The US government will drone strike people outside the US without trial or charges. Apple illegally SWATed a Gizmodo reporter over a leaked iPhone prototype.
I don't blame this Turkish national, not one bit.
I updated the post to include the word 'strong', although I would expect most users to simply set their own password, which should provide identical security to what they currently (should) have.
Disabling the root account does not open up the vulnerability again.
This vulnerability doesn't reset the root password, it only enables the root account and checks the password against that. The default root password out of the box on OSX is blank which is what allows this to work as-is.
By setting a root password, the next time you attempt this (and I tried it), the attempt fails since the 'root' account now has a password set.
Disabling simply puts the root account back in a dormant state, where it should be for most users, for after this vulnerability is fixed and it can't be enabled maliciously.
The replies to this tweets are all everyones snarky comments to the @AppleSupport account or their edgy 'hot takes' on the issue. @AppleSupport responded promptly - albeit obviously out of their depth, and a bunch of people couldn't help but make fun of this fact. It's almost like tweeting to Apple's customer support account is not the best way to report a vulnerability?
Responsible disclosure has a proven history of working. When the vulnerability is appropriately patched and disclosed to the public, there is still a lot of backlash. You only need to look at the recent responsibly disclosed vulnerabilities for proof of this. Instead, we have a bunch of armchair analysts—who don't at all seem to be driven by past occurrences / existing data in any way—claiming that it didn't work.
Linux didn't have that problem, a single vendor did. You could say the same for Apple except they are the single vendor. That stupid security trick in Ubuntu only impacts subset of a subset of Linux _desktop_ users which is a pretty small subset of computer users as a whole. When Apple does something like this, it impacts a much larger share of the world population.
So how about we keep the snark to an appropriate level based on the impact to the world population? ;)
So lets keep the snark to an appropriate level, shall we?
These sorts of bugs can happen anywhere. We all need to bear that in mind.
One notable difference, though, is that macOS is proprietary software. Apple have sold their users a product and haven't respected their users' right to use, modify & distribute that product; their users have never had the ability to inspect the macOS source for this kind of problem. Thus, responsibility for this disaster rests solely on Apple's shoulders.
There is a setting to immediately destroy the key when the laptop sleeps. It might be outdated but [1] should give you a starting point for setting it up.
[1] http://mattwashchuk.com/articles/2016/01/08/maximizing-filev...
Interesting...
Also the UX is different. Typing root on the fresh installed one fails, then resets the user text box to my name, and if I type root again it doesn't let me it.
On the upgraded laptop, if I type root, it sticks and clicking unlock twice gets me in.
The only mitigation that automation would bring is if the bug was found in earlier versions, and test case was subsequently written. IOW, and very much a generalization, automation is to find regressions. But if the bug is new...
(To be clear, this bug still should have been found. But automation is unlikely to have found it.)
"We are working on a software update to address this issue. In the meantime, setting a root password prevents unauthorized access to your Mac. To enable the Root User and set a password, please follow the instructions here: https://support.apple.com/en-us/HT204012. If a Root User is already enabled, to ensure a blank password is not set, please follow the instructions from the ‘Change the root password’ section."
https://techcrunch.com/2017/11/28/astonishing-os-x-bug-lets-...
https://images-na.ssl-images-amazon.com/images/I/51I4nsyt9AL...
In this case the story hit a software penalty for a while, which we noticed and corrected as we usually do eventually. This software works well most of the time but unfortunately not always. Either way, it has nothing to do with our opinions about Apple, which is fortunate because we don't particularly have any.
- Open Directory Utility (/System/Library/CoreServices/Applications/Directory Utility.app)
- Authenticate with the lock icon
- From the Edit menu you can enable the root user and set a proper password (it would already be enabled if you had tried out the exploit)
Having that root user enabled isn't great overall, so it would be best to set a reminder to disable it using the same Directory Utility app once the security hole is patched.
It looks to me like my root user is disabled.
When I type "root" into the username field and click unlock (in System Preferences > Users & Groups) "root" is replaced with my username and the dialog shakes... I have to type root in each time, but it never unlocks. 10.13.1
Edit: trying it after logging out keeps "root" in the username field, but never logs me in... tried 20+ times
I've upgraded a through a couple versions of OS X on this machine - maybe that makes a difference?
Edit: changing the login method to "Name and password" under login options, then logout and login with "root" with empty password also works.
Fortunately, it doesn't work on cold boot with FileVault enabled, at least it doesn't appear so. `sudo su root` also doesn't work with an empty password.
Apparently someone verified that it /does/ also work with `su - root`.
We can point to avenues for remote root all day but I don't recall any that are/were as simple as "just hit [enter] to get root" that impacts the shared attack surface that impacts all Linux systems.
NOTE: I did not go and search NVD before writing this reply but I did stay at a Holiday Inn Express once.
Following the link to his home page we find:
"He has worked as software architect, software craftsman, technical leader, team leader, technical coordinator, Scrum Master and Agile coach in dozens of software projects at BYM, GittiGidiyor / eBay and Sony."
and
"Lemi Orhan Ergin is a Software craftsman, passionate developer, technical architect, Agile culture cultivator, Agile coach, Scrum / Kanban practitioner and trainer, Management 3.0 trainer, experienced mentor, engineering booster, Git trainer and lover, the TDD guy, clean coder, infected with the technical side of Agile, presentation and visualization freak, non-stop learner, full time apprentice of my masters, the community guy."
It's possible this guy was oblivious to the idea that there's a good way to share this information with Apple / The World At Large, and consequently did not attempt to find out the preferred way of doing it, but I don't buy it.
I know it's been asked before (by me, for one), but can you tell us anything about the protections HN has in place against astroturfing?
First, he is an active developer - his resume cites big shops such as ebay and Sony (many years). It's possible that most of his bug reports at those places come through tweets, but it's more likely he's had some exposure to formal disclosure processes.
Second, he follows some thousand people on twitter, has been active in IT for nearly two decades, is a founder of a couple of tech / dev groups. As I say, it's possible he's unaware that there are mechanisms to advise vendors of major security holes beyond tweeting to the world.
Third, I wonder what he was thinking when he did post that on twitter. As in, even being unaware of generic, or Apple-specific, responsible disclosure mechanisms, what does one imagine will happen when you discover a massive hole in a popular platform and decide to just tell the world. I'm disturbed that someone with this level of IT experience and credentials didn't consider consequences here.
Fourth, a corollary to that last one, if you do spend a brief moment contemplating the consequences, it should be a fairly short process to then wonder if there's a better mechanism, and that mechanism is pretty easy to discover.
If I remember correctly, one is supposed to make it public once patched or in event of no response, no?
Edit: What is "Responsible Disclosure"[0]?
To whom does he owe that obligation? Apple? The public? Both? Why?
That said, I don't immediately see evidence that this gentleman is in the security field, and perhaps isn't aware of responsible disclosure. Full disclosure isn't the worst thing in the world.
Also reminds me of https://youtu.be/BVL8_ne4WZo?t=19s
> That isn't a login screen for Windows 98, it's a login for Microsoft Networking (which the box shows). If you had any shared mapped drives, network privileges, etc they wouldn't work if you cancelled. If you had multiple profiles set up, you wouldn't get those either. Win98 wasn't intended to have password security.
They'll not only have to patch the vulnerability but they'll also have to disable all of the root accounts that were inadvertently enabled. What a mess.
I've two factor authentication on my Apple account and now every time I use a new browser (or after clearing the Cache) and try to log into one of the Apple developer sites it sends me the authentication code to the same machine that I'm using. How is that two factor ?
I've an iPhone which is connected to the same account but it's not my primary phone so it's most likely not ON when I do this. I guess Apple tries to send the code to my phone and when it fails sends to the next online device which happens to be the same machine I'm using to log in. So all I have to do is click Allow and enter the 6 digit code which is displayed in a different app.
Your password is something you know. Your computer (which is associated with your Apple ID) is something you have.
If someone tries to log in using your password from another computer, your account is safe. If someone steals your computer but doesn't know your password, your account is safe. You're only in trouble if someone steals your computer _and_ knows your password.
System Preferences > Users & Groups > Login Options > Join > Open Directory Utility > Edit > Change Root Password
EDIT: My bad - editing was locked on that screen. Got it now...
EDIT2: Root user is disabled on mine. Is that enough, given that this bug seems to create a new root user each time? Should I enable root user and set a password rather than leave it disabled?
SELECT * FROM plist WHERE path = "/private/var/db/dslocal/nodes/Default/users/root.plist" AND key = "passwd" AND length(value) > 1;
1) (Apple) 1 + 2 + 3 = 24 https://news.ycombinator.com/item?id=15538666
2) (Apple) Blank root password https://news.ycombinator.com/item?id=15800676
3) ...
There ARE areas more safety critical than desktop computing, you know.
- it is almost 2018 and copy pasting on an ipad/iphone is still a horrible, non-deterministic nightmare
I would really like to see a top 10 list of software blunders, I think everyone on HN would.
edit: I stand corrected. The 'require password' setting under Security Preferences didn't change, but other settings do. Yikes
Update: And even after attempting it, checking Directory Utility the root user is still disabled. So I wonder if something 3rd party has enabled the root user and left it passwordless.
While Apple works on its fix, it offered a workaround for users concerned about the bug.
“Setting a root password prevents unauthorized access to your Mac,” the company explained.
"To enable the Root User and set a password, please follow the instructions here: https://support.apple.com/en-us/HT204012.
---
Edit - for me those Apple instructions didn't work. This seemed to:
Search for 'Directory Utility' in Spotlight and click it.
Click the lock to make changes
Select 'Enable root user' from 'Edit' on the main menu and set a password.
If I give you a Mac logged in with an unprivileged account and you can use only the keyboard and mouse to gain root access, the security has failed.
I think you've conflated this with the attacker having (full) physical access to the machine, which conventionally means access to its ports and perhaps a screwdriver. This is not that.
I was thinking along the lines of, if I have write access to your .bashrc (or a multitude of other config files that you as an unprivileged user have write access to, and can be used to trick you later into running code of my choosing), all bets are off.
edit: Screen sharing is is vulnerable not ssh. Either way its bad.
Set a good password there and disable the root account again.
Now people making use of this vulnerability will still be able to re-enable the root account (that's why it fail the first time - root is default off, but this bug enables it), but now there will at least be a useful password set.
/etc/pam.d$ grep -RI nullok /etc/pam.d
/etc/pam.d/authorization:auth required pam_opendirectory.so use_first_pass nullok
/etc/pam.d/checkpw:auth required pam_opendirectory.so use_first_pass nullok
/etc/pam.d/screensaver:auth required pam_opendirectory.so use_first_pass nullokI initially saw this thinking it didn't affect Sierra or High Sierra.
It does not work if you are not admin. It does not work if your root user is enabled and has a password set. If you tried the vuln, you should set a password for the root user ("sudo passwd root").
To me personally 10.6.8 + Security Updates + APFS is extremely close to the ideal operating system.
Real answer, APFS (which changes the Filevault encryption model to no longer be full-disk-encryption...) and Metal2 graphics (which has brought a variety of new gfx bugs into play, even for 1st party applications) are the big technical draws
For a full list of changes, review the marketing page or the developer release docs
- https://www.apple.com/macos/high-sierra/
- https://developer.apple.com/library/content/releasenotes/Mac...
(yes Apple can't be bothered to update their dev docs with the point releases. Documentation quality has fallen off dramatically since the 10.6 days)
Given the stream of bug reports on various apple sites, I have not upgraded any of my personal machines, and my employer has stated they will not be upgrading our machines in the near term.
Do you think a hacker with ill-intent would have reported this issue at all?
Yikes!
* a computer with remote login enabled
* a computer with the main login screen set to "username and password" mode
* a computer with a guest account
This would have been a pain for me when i was using parental restrictions to lock a 12 year old out of 18 hour a day Minecraft.
How are all bets off if they don't have access to a root user? This isn't Windows we're talking about.
It could also be a security/privacy decision to leave it broken but safe until they can implement camera access through WebViews securely.
The closest to any official reason I could find is a dev letting us know that mum's the word:
>I asked about this internally and the answer is that, right now, WebRTC is only supported in Safari. No WKWebView, not even SFSafariViewController.
:/
https://en.wikipedia.org/wiki/Pyramid_Technology
Here's the email in which I reported it to the staff mailing list.
Date: Tue, 30 Sep 86 03:53:12 EDT
From: Don Hopkins <don@brillig.umd.edu>
Message-Id: <8609300753.AA22574@brillig.umd.edu>
To: chris@mimsy.umd.edu, staff@mimsy.umd.edu,
Pete "Gymble Roulette" Cottrell <pete@mimsy.umd.edu>
In-Reply-To: Chris Torek's message of Mon, 29 Sep 86 22:57:57 EDT
Subject: stranger and stranger and stranger and stranger and stranger
Date: Mon, 29 Sep 86 22:57:57 EDT
From: Chris Torek <chris@mimsy.umd.edu>
Gymble has been `upgraded'.
Pyramid's new login program requires that every account have a
password.
The remote login system works by having special, password-less
accounts.
Fun.
Pyramid's has obviously put a WHOLE lot of thought into their nifty
security measures in the new release.
Is it only half installed, or what? I can't find much in the way of
sources. /usr/src (on the ucb side of the universe at lease) is quite
sparse.
On gymble, if there is a stray newline at the end of /etc/passwd, the
next time passwd is run, a nasty little "::0:0:::" entry gets added on
that line! [Ye Olde Standard Unix "passwd" Bug That MUST Have Been Put
There On Purpose.] So I tacked a newline onto the end with vipw to see
how much fun I could have with this....
One effect is that I got a root shell by typing:
% su ""
But that's not nearly as bad as the effect of typing:
% rlogin gymble -l ""
All I typed after that was <cr>:
you don't hasword: New passhoose one new
word: <cr>
se a lonNew passger password.
word: <cr>
se a lonNew password:ger password.
<cr>
Please use a longer password.
Password: <cr>
Retype new password: <cr>
Connection closed
Yes, it was quite garbled for me, too: you're not seeing things, or on
ttyh4. I tried it several times, and it was still garbled. But I'm not
EVEN going to complain about it being garbled, though, for three
reasons: 1) It's the effect of a brand new Pyramid "feature", and
being used to their software releases, it seems only trivial cosmetic,
comparitivly. 2) I want to be able to get to sleep tonight, so I'm
just going to pretend it didn't happen. 3) There are PLEANTY of things
to complain about that are much much much worse. [My guess, though,
would be that something is writing to /dev/tty one way, and something
else isn't.] Except for this sentence, I will also completely ignore
the fact that it closed the connection after setting the password, in
a generous fit of compassion for overworked programmers with
ridiculous deadlines.
So then there was an entry in /etc/passwd where the ::0:0::: had been:
:7h37OHz9Ww/oY:0:0:::
i.e., it let me insist upon a password it thought was too short by
repeating it. (A somewhat undocumented feature of the passwd program.)
("That's not a bug, it's a feature!")
Then instead of recognizing an empty string as meaning no password,
and clearing out the field like it should, it encrypted the null
string and stuck it there. PRETTY CHEEZY, PYRAMID!!!! That means
grepping for entries in /etc/passwd that have null strings in the
password field will NOT necessarily find all accounts with no
password.
So just because I was enjoying myself so much, I once again did:
% rlogin gymble -l ""
Password: <cr>
[ message of the day et all ]
#
Wham, bam, thank you man! Instead of letting me in without prompting
for a password [like it should, according to everyone but pyramid], or
not allowing a null password and insisting I change it [like it
shouldn't, according to everyone but pyramid], it asked for a
password. I hit return, and sure enough the encrypted null string
matched what was in the passwd entry. It was quite difficult to resist
the temptation of deleting everyone's files and trashing the root
partition.
-Don
P.S.: First one to forward this to Pyramid is a turd.
product-security@apple.com
They also respond to security@apple.com but prefer the product-security address.
Further, there are any number of legit bug bounty programs out there like ZDI that would pay for a bug like this then immediately disclose to Apple for it to be fixed.
Disclosing an 0Day root authentication bypass vulnerability on Twitter isn't cool, even if it is local: think of the impact to shared iMacs on university campuses.
In this case the bug is so bad and egregious, that publicizing it with the fix might have been the best thing to do -- no telling how many people have already discovered this or how long it would take Apple to fix.
Yes, let's educate each other about what responsible disclosure WITH A DEADLINE TO FIX looks like, but don't assume this person just wanted internet points. And now that the report and a workaround are out there, at least it can be mitigated personally.
Though I imagine there will be some SERIOUS hijinks that result from this until Apple fixes it because it is so easy to do. :(
Responsible disclosure works when you are fairly certain you have found something nobody else knows about. Logging in with root must be known to many people.
This isn't just a snarky comment. They have just released the most awfull iOS upgrade for a long time, and now this. Something's messed up, and they better fix it soon.
I've think i've read somewhere they merged the iOS and macOS teams, i suppose the wrong people were promoted during the operation.
> They have just released the most awfull iOS upgrade for a
> long time, and now this. Something's messed up, and they
> better fix it soon.
That's just wrong. There's no excuse for that. We're not talking about fancy animation or new features that we think aren't a great idea. Just a basic regression on one of the most fundamental things you can do with this device (the other being displaying things).
Another thing is that they usually fix slowdowns and stability with the following release soon after. Not this time, so my guess is that it'll be a "change your device" kind of upgrade.
sudo laugh
This isn't the first extremely serious and dumb High Sierra password bug this year [1] [2], and unless Apple is severely hurt by it, so they're forced to change, it won't be the last. High Sierra is full of bugs and seemingly not just annoying bugs, but also security bugs.
Let's hope Apple gets sued for the damage they'll cause by including this bug in High Sierra so they make sure that next release of macOS won't be another bug filled mess.
[1] https://arstechnica.com/information-technology/2017/09/passw...
[2] https://www.macrumors.com/2017/10/05/macos-high-sierra-disk-...
Encouraging irresponsible disclosure because one wants to see Apple hurt is a reckless and selfish attitude because it puts millions of Apple customers at risk in the process.
I'm a die-hard Apple user myself, but I agree that the long list of severe bugs in High Sierra is absurd, and a big public backlash might be enough to kick them into gear. On the other hand, I, a university student with next to no understanding of computer security, can simply walk onto campus, sit down at a Mac, and within seconds have complete access to the computer. It's ridiculous, it's horrendous that it shipped like this, but it's not something that needed to get out, especially something so easy to utilize.
One would think that something as simple as a login would be deterministic.
How would you feel if someone discovered a 0day at a company that exposes credit card and identity info, published the 0day, then hackers steal all that info (including yours)? I'm sure 'creating a thunderstorm of negative publicity' would be the last thing you would want.
If so, why? How do you identify companies like Apple that get one set of rules to other companies?
Yes Apple shouldn't be having this issue but disclosing a 0-day issue can possibly hurt users far worse than hurting Apple. Apple may lose a tiny bit of money but users could lose far, far more especially if someone develops a good way to remotely deploy / take advantage of this defect.
Ignoring responsible disclosure also limits the ability to sue them for any damage resulting from it (or so I'm told by one of my lawyer friends who thinks this disclosure may make it almost impossible to successfully sue them over it unless it simply takes them too long to fix).
How can that happen in any case ? Isn't pretty much the first line in every license waiving of liability ? Unless you have some special contract with Apple that overrides other standard boxes that you ticked, how would anyone sue ?
It's about protecting systems RIGHT NOW from immediately causing harm to people's lives.
https://www.eff.org/deeplinks/2017/10/drms-dead-canary-how-w...
Blame the DMCA. This guy is in Turkey - does GP really think he can expect fair treatment and equal compensation as a "western world" security researcher?
The fact that we know about it means we can take steps to mitigate the damage.
There is blame on both.
If you leave your key in your front door lock and I blast out on twitter your address and tell people about it, I think I have some responsibility.
https://www.theregister.co.uk/2016/08/05/apple_joins_the_bug...
The idea of responsible disclosure is to minimize harm for you, the user. Not to minimize bad publicity.
> people are under no obligation to
> report vulns privately
This vulnerability is ridiculous, unacceptable, and braindead to execute.
They've been quick (within 45 days) to patch every major bug I've reported to them and where the bugs were cross platform, impacting Windows, Android, etc., they've consistently been amongst the quickest to issue a patch so I'm not sure how you qualify that statement.
Although for what it's worth last time I reported a security vuln to Apple using their official process they took around 2 years to fix it (admittedly low priority security vuln, passwords being sent over http).
Wait, what?
His twitter account tells that he is an agile software craftsman, turkey founder and a community guy. And he tweets about devops, open source and other stuff.
An average person disguised as a software developer?
The thing about bug bounty programs are that they are not a negotiation. They decide how much your information is worth--take it or leave it.
If you thought this bug was worth $25,000 and you feared that Apple might offer a $100 discount coupon plus a lovely "I Love My Mac" coffee mug, is there any way to start a negotiation without being accused of extortion (if you imply that you might disclose it publicly)?
This is a serious question: Is there any way to negotiate for security bugs, before or after disclosing all the details, without running a legal risk?
In general, you have to rely on this being a repeated game - you and the pentester community at large submit lots of bugs to this company, and you rely on them to make it worth your time and talent. If they don't, you go test someone else's software. Reputation is everything.
It gets the word out quickly.
Releasing proprietary software with such a hilariously insecure authentication system isn't cool. This isn't free software, produced by people & corporations out of the goodness of their hearts; rather, it's something for which people pay a good deal of money and which they have a right to expect is at least somewhat secure.
Getting the word out, fast that a) there's a huge insecurity and b) it's in Apple software provides benefits to those running macOS (so they can fix their systems) and to those considering running macOS (so they can evaluate whether an alternative is more appropriate).
Instead of trying to control behaviour of every single human being in this world and demanding of them to do things in a certain way - which is, was and will always be impossible it is much more favourable to establish the expectation that a zero day vulnerability might be dropped every week and have businesses (vendors and clients) be prepared for it so it can be handled adequately.
You may know the protocol, security researchers and people in the tech industry may know that, but why is an ordinary Joe expected to know, or research, that email address and/or the protocol regarding 0-day vulnerabilities.
It's the same logical line of thought that leads people into turning wallets into the lost and found (or an authority) instead of just pointing at it on the ground shouting "hey look, a wallet!" then walking away.
I'm just curious how much of a payday this guy missed out on by not disclosing responsibly.
In the course of developing my current application, I've discovered a couple security bugs in macOS, which I reported to Apple product security in PGP-encrypted emails. The only thing offered to me was to have my name/company listed in the release notes (which they are, for the latest 10.13 update, along with a CVE#).
I'm sure Apple will in the future.
no one is under any obligation to sweep company's security problems under the rug for them.
If companies create incentives for people to share vulnerabilities with them first, great, but no one is under any obligation to participate in those programs.
Don't ship broken software if you don't want pie in your face.
Once the root user has been enabled locally, the only sharing settings I found to permit anyone remote access with the root/null combo is Remote Management.
How dare you publicly shame him and risk his future employability like this? It's only responsible of you to contact him quietly and directly so he can correct his mistake and cover it up so nobody needs to know.
It's like there's one rule for the negligent global corporation which happens to work in the corporation's favor and shames the public for speaking to each other about their salary, I mean flaws in their software, and another rule for ordinary people giving a heads up to people who are fair game to pile on.
The PGP key is available here: https://support.apple.com/en-us/HT201214
I wonder what percentage of emails to security@... (apple.com or otherwise) are sent encrypted...
And the only way Apple gets motivated to fix either of those two things is massive Pr damage.
Human fallibility, yo.
Source: Information Security 101
There is no justification for releasing a 0day publicly.
It's trivial to find. He can't presume he is the only one who found it. Telling any individual that doesn't have malicious intent is a good thing, therefore telling everyone is a good thing.
My guess is he found this vulnerability on accident, freaked out, and tweeted about it. Probably has limited infosec experience.
So he's either not reading his replies or he's being deliberately irresponsible. My guess, based on his profile and online behavior, is that he's trying to ride the coattails of getting some exposure online.
I think the problem is due to the fact that they are fans. In this case, it's Apple, but there's no reason it couldn't be Linux or Go or whatever. Regardless, any bad news about their hero is irresponsible to disseminate. We see this same phenomenon in politics, in sports and elsewhere — I daresay it's regrettable human nature.
On the other hand, I'm glad that I have this information so I know not to install High Sierra on my work iMac (sitting on a desk in a WeWork behind a door whose lock would be very easy to force open) until this is fixed.
[Edit: I now see that there's a simple workaround (change the root password and keep root enabled), so I'm all for "irresponsible disclosure" in this case]
I think this is an unfair characterization. Sure, it's hard to hear that their "hero is irresponsible", but the real reason is that this kind of behavior puts everyone at risk while Apple tries to fix it.
If you read through the comments, you'll see people are arguing that Apple is to blame here. It doesn't require much discourse to recognize that's the case and hence why you don't see more people complaining about this being possible in the first place.
A Tesla has ~ 100.000.000 [1] lines of code. Considering this post, do you think we are sufficiently educated in software security to produce secure self-driving cars?
Elon Musk: "I think one of the biggest risks for autonomous vehicles is somebody achieving a fleet wide hack" [2].
I imagine a Twilight Zone episode... Go back in time to before cars were invented and imagine some Mephistopheles offering the bargain: "You'll fly like the wind over hills and mountains, making a journey of days in mere hours!" What the catch? "For each mile traveled a certain number of people chosen at random must be put to death or maimed."
He would go on about how the chances of someone you love being chosen for sacrifice were infinitesimal, and the benefits to all were so great and so obvious...
("Also, it will poison the air and water, and force you to become dependent on fuel sources that destroy life and engender wars.")
Firstly, car automation is machine learning, not programming. Completely incomparable.
Finally, we've known how to prove the absence of bugs for decades. It's not a matter of not knowing how, it's about incentives to do it right.
Just because the vulnerability is not disclosed does not mean it is not being actively exploited. It probably is.
Users who don't care about their security do not deserve to be "protected" at the expense of compromising the security of those who do care who benefit from immediate disclosure.
You mean, in addition to bad QA and complete disregard for their users' security? And being the richest and most profitable company ever, cutting corners and evading taxes?
Their response on Twitter was amazing: "PM us so we can discuss this privately", not "thank you, we're looking into it NOW".
Apple is a Rorschach test writ large. What people see in it reflects more on the observer than the company in many cases.
The other day I actually ran across some AWS docs which suggest you send your AWS root key id in the url of http requests:
http://docs.aws.amazon.com/AlexaWebInfoService/latest/index....
https://forums.aws.amazon.com/thread.jspa?threadID=126537
Still I'm surprised they would suggest sending the root key to your account over http. Even if it is just the id and not secret it still seems like something you want to keep secure. I don't use my root key for services. I create new accounts and IAM roles.
Obviously, something's wrong with your keyboard, but how do you know it's iOS's fault instead of your app's?
As for human readiness to safely control a tonne of speeding metal, my position as a full-time motorcyclist makes me extremely confident that the average alleged 'driver' (actually: daydreamer, snot-picker, instagrammer) isn't even approaching the edge of the competence ballpark.
Project Zero (and infosec professionals, at least all of the ones I've ever worked with) would tell you that this was the most irresponsible way to handle the issue, short of not saying anything and selling knowledge of the exploit to someone other than the vendor who could fix it. Publicizing something like this in this way is something people do because they want publicity for themselves. It is not something someone does if their biggest concern is for the users who might be affected by it. It is something someone would do if they didn't care about the users, and just wanted public credit for pointing it out.
Furthermore, that deadline is 7 days if they are aware of active exploitation.
DJB is famous for his full disclosure with no advanced warning stance.
The rest of your post is false. That is your opinion, and people disagree. I'm going to guess you have not personally spoken with folks from project zero. I have spoken with some of them. And trust me, they would not agree with your statement. A few of them even feel strongly that their timelines are far too generous. I also understand their reasoning, and it has nothing to do with ego or publicity, and everything to do with concern for users.
They do not give a shit about credit beyond believing that it is proper to cite the authors of any work. That isn't the case for everyone finding bugs, but people on that team lost the novelty of having their name on bug reports long ago.
It seems to me (somebody who has no chops in this domain) that this is such a basic bug. Like something a child would have found just messing around.
And it came from a corporation that has around $200B of cash and cash equivalents. Apple has the resources to test and find bugs like this.
That Apple didn't find it is down to leadership and priorities more than some inherent limits of producing reliable code. One spends on what one thinks important.
But who knows, I've got no domain expertise here. Maybe a fifth of a trillion dollars C&CE really isn't enough to fund production of more robust code. But really?
A lot of security vulnerabilities are of this type: "let's do crazy shit X that the system was not built for and see what breaks." I'm sure this will be in their test suite now though.
Maybe Apple should spin up a group of 7 - 14 year-olds to add to their test suite input. They might be better at coming up with crazy shit X that might break things.
I'm pretty sure any fix has to go through Build and Integration before being rolled out. Then you need to have people actually install the update…
But seriously, a fix is whatever fixes the problem.
If ISIS was able to hack a major fleet through one such bug, do you think for a single moment they wouldn't make use of it to kill many people?
Us geeks have been complaining about the horrible QA in macOS for years, yet nothing has been done. The fact that this is so simple to do will probably/hopefully get ordinary people to start talking about it too ("Hey, have you heard that you can hack Macs without a password? Very insecure"), which would force Apple to improve.
I think you have to be very careful about that line of argument. It's a single vulnerability researcher making a unilateral decision about the short term and long term security of an entire user base, based entirely on personal judgement. I personally think the researcher should make the decision that best protects users from that specific vulnerability. Making long-term changes to a company's QA should come second.
I find it odd that you're putting the responsibility of making decisions about how to protect Apple's users on an unaffiliated third party.
Apple has a multi-hundred-billion dollar war chest and, if they wanted to, could afford to make macOS the most secure operating system on the market. The fact that they don't is their own choice and a reflection of their priorities, not some act of God or a natural disaster. Putting the onus for cleaning up the mess in the most "responsible" way possible on third parties with a fraction of Apple's resources is being too kind to Apple.
Unfortunately, I don't believe those will happen.
I don't have any experience with enterprise-grade IT, but it seems like shared computers should be thin clients or at least use UEFI to securely boot an image over the network and not keep anything sensitive locally.
If you give someone physical access to a box, they will be able to own it.
its educational for the end user. You cannot trust Apple. Good reminder there are other OS available out there.
The question is large and complicated, and people can agree to disagree. There's nothing wrong with tweeting vulns: The company is at fault, we can defend ourselves now that we know about the vuln, and it's a big PR disaster for Apple.
A past conversation: https://news.ycombinator.com/item?id=14009937
No, no it's not strictly more ethical. It's not even strictly safer, which should be an even easier question to answer. The baked-in assumption in your logic is that users have no options other than waiting to patch. But, obviously, they do, and keeping vulnerabilities secret deprives them of those options.
> There's nothing wrong with tweeting vulns
Those two statements seem to be contradictory. It seems to me there is still quite a lot of debate about which disclosure policy is best,
It seems to me the right thing to do is to tell Apple privately, tell them to either push a fix or put out some kind of release letting all their customers know how to mitigate this in the next, say, 3 days, or I'll just tweet about it. What's the downside? At the worst case, you just prolonged the status quo for another 3 days.
Edit:
See: https://stackoverflow.com/a/33272796 for a bit more information of what I mean.
And at the same time provided everyone with a simple, free, and perfect way to fireproof his/her house.
You could wait for the fire department, which may take hours to get there, and hope that no malicious party down the street saw the fire, or you can do this. It turns out that both are quite reasonable reactions in this scenario, and that the latter is much more obvious to the layman.
There is no good reason to get angry at the layman for taking a course you don't prefer.
The issue here is that it isn't perfect in the long run (having a root account with a password is worse than not having one) and many people will not be adopting it since they're not in the know.
Of course, it is always possible people have been already exploiting this, but most likely it is at most a small number of people who know about it. Now every script kiddie in the world can and will go around trying to hack anyone who isn't well-informed enough to know how to protect themselves.
Dude. That was your example.
By your logic, we should not fly any modern commercial or military aircraft or spacecraft, live within a certain radius of any power or hazardous chemical plant, place any dependency on any first world country's health care network, including life support, or invest in any company or stock.
Like most things in life it comes down to a security/convenience risk/benefit compromise.
Are you claiming that this could not have happened with Tesla? If so, please explain why.
> By your logic, we should not fly any modern commercial or military aircraft or spacecraft, live within a certain radius of any power or hazardous chemical plant, place any dependency on any first world country's health care network, including life support, or invest in any company or stock.
Up until now the benefits have clearly outweighed the risks, but that does not mean it will continue to do so.
Embedded software used to be low-level code we'd bang together using C or assembler. These days, even a relatively straightforward, albeit critical, task like throttle control is likely to use a sophisticated RTOS and tens of thousands of lines of code. " [1] [2]
[1] https://www.edn.com/design/automotive/4423428/Toyota-s-kille...
[2] https://www.embedded.com/electronics-blogs/barr-code/4214602...
The same actions can be a hack or not, depending on what they're accomplishing.
Simply pretending root does not exist is a rather new idea and is not best practice. It's only for convenience.
This is an outmoded guideline for password security. String enough dictionary words together and you achieve a high level of entropy. See for example https://en.wikipedia.org/wiki/Diceware
Says who? Sure, it's convenient not to have to worry about choosing a secure password for your root account, but why is it "sort of a hack in itself"?
And many users will create insecure passwords, leaving them with a serious vulnerability after the patch. A password of "root" or "qwerty" is only marginally more secure than a blank one.
If it was previously possible to create a root account then I guess there's no way to tell the difference between those who created the password as a response to the vulnerability and those that knowingly created a root account.
Yes, you can. macOS ships with the account disabled by default, but you can re-enable it if you wish. Most of the time there is no reason to do so.
> If it was previously possible to create a root account then I guess there's no way to tell the difference between those who created the password as a response to the vulnerability and those that knowingly created a root account.
Yes, but this difference doesn't matter. By creating a root account you have made your computer less secure anyways, assuming that we didn't have the current issue at hand.
Not a choice now. If people have physical access to Macs at the moment then it seems to me there are two options right now: either 1) you have changed the root password, hopefully to a strong password or 2) they'll be able to login as root.
Right now you can expect the participants in this thread to be a little smarter than the average computer user.
On the surface, this particular exploit on macOS seems to be caused by a totally unrelated subsystem (security vs. GUI).
In any case, in a desktop system you shove everything together and then try to modularize it with good design and weak tools like UNIX processes. In a car, the safety-critical systems are literally running on separate hardware with limited communication over a specialized data bus. Of course it's still possible for them to have bugs or even exploits, but the complexity of the infotainment system is irrelevant, aside from making it a potential jumping-off point for using an exploit in the safety-critical systems.
Counting the infotainment system here makes about as much sense as counting the number of lines in Windows when talking about a Mac vulnerability because a Windows machine could be used to launch an attack.
As for your subsystem argument, explain this: https://www.youtube.com/watch?v=OobLb1McxnI&feature=youtu.be...
But it's still wrong to focus on total complexity. You want to look at the complexity of the relevant system.
That video is explained by using the infotainment systems as a bridge, exactly as I described in my previous comment.
Personally I think if you report through the proper channels and nothing is changed THEN broadcast, but not as an opener.
Other than buy an Apple product, the users did nothing intentional to undermine security.
Since this is a subjective argument, based more on historical instances of "responsible disclosure" and not law, I'm gonna lean in this case of it being Apple that failed
They built the entire "walled garden" without getting outside help. They want the control, they have billions of dollars, can hire whatever talent...
Failed to spot a password-less root login issue.
People need to know today to be even more cautious about using Apple gear in public places or around plain ol' tech jerks that like to fuck with people for a gag.
Society has no legal or moral obligation to make sure Apple stays in business.
Responsible disclosure is an interesting concept. How does this kind of disclosure make sure that the public knows about a company's track record of vulnerabilities, if everyone is under NDA and the company has no obligation to ever publicize it?
Now, if the reseacher could give a grace period, that's cool, but there MUST be a deadline by which stuff goes public. Hopefully the company fixes it and issues a postmortem first. If not - too bad!
It’s not like being good morally correlates with being good at security.
The main question that should be asked is, how did this get overlooked? How is it that your average website has better password security than the OS of one of the richest tech companies in the world?
To be fair to Apple, Microsoft had similar issues back in the 1990s. Perhaps it takes a string of security blunders for some tech companies to take security seriously.
You would hope the self-described twitter bio "Agile Software Craftsman" might have thought about this a little before tweeting.
Since we're just making up statements, I guarantee that Apple would never voluntarily disclose this issue if it was reported privately. So Full Disclosure is the only way to put Apple's feet to the fire, as it's the only way in which this issue would have had any visibility whatsoever.
https://en.wikipedia.org/wiki/Full_disclosure_(computer_secu...
I'd lay responsibility at the lockmaker's door, not the guy who told everybody they were at the mercy of anyone with a toothpick.
That's not a faithful analogy. Apple isn't your neighbour. They are the landlord. The scenario is more like that the landlord uses bogus locks in your complex, and you post it on twitter. You could complain to them privately too, but given your past experiences perhaps, you thought that twitter would be a more effective medium.
There is no realistic way to keep a lid on something like that and so in this case the blame is entirely on Apple.
asejfwe8823 24 minutes ago [dead] [-]
A better analogy would be "if the lending bank left the door to your new house open..." Other than buy an Apple product, the users did nothing intentional to undermine security. Since this is a subjective argument, based more on historical instances of "responsible disclosure" and not law, I'm gonna lean in this case of it being Apple that failed They built the entire "walled garden" without getting outside help. They want the control, they have billions of dollars, can hire whatever talent... Failed to spot a password-less root login issue. People need to know today to be even more cautious about using Apple gear in public places or around plain ol' tech jerks that like to fuck with people for a gag. Society has no legal or moral obligation to make sure Apple stays in business.
The fact locks are easy to pick doesn’t mean people don’t take more measures to defend it. More and more people install steel door as an extra layer and home security surveillance system, all of which can be compromised with the right tools.
Responsible disclosure is something I respect. While he has the right to not disclose this privately first, has he tried? How hard is it to ask someone to get in contact with the Apple security team? There are a bunch of top sec researchers on Twitter constantly tweeting) to help escalate this. I think someone on Google zero project team did this to escalate.
I don't want to see Apple hurt (I'm an Apple-guy myself, using Macs, iPhone, iPad and Apple Watch), I want to see them improve. I doubt they start will start caring about QA unless they're forced to.
One absurdly serious and stupid password bug like this can be a honest mistake, but three (that we know of, that were full disclosures) in a few months is negligence that should be criminal if it isn't.
Now if every person started disclosing vulnerabilities via twitter without giving the company turn around time to resolve the issue based on their dissatisfaction with Apple based on standards they came up with personally, I don’t think it is nice or fair.
A root password solves this issue. Its seconds to implement and helps right now.... Not "later" as closed disclosure does.
I'd rather know every error and critical bug. I can bring up with our team and decide now to either sudo service * stop or continue.
Your closed options keep the fact I'm vulnerable away, along with any pathways I might have to fix.
I mean, this bugs has been reported already - by every cheesy hacking movie ever, by every beginners book on social engineering and so-forth. Heck, it was "reported" by Richard Feynman talking about cracking safes during the Manhattan.
IMO, this behaviour is part of the problem, the reason why tech companies take security only on a superfiscial level seriously.
Don't kill the Messenger.
EDIT: putting users at _additional_ risk
edit: Typo.
> it puts millions of Apple customers at risk in the process.
Nah, it's Apple which put millions of customers at risk, not the person who disclosed the vulnerability. let's not shift away the blame from the guilty here.
Apple one of the richest company in the world is obviously just cutting corners in QA here. This is unacceptable.
it's seems some people here are more concerned about negative publicity than user security. This is a pattern that have been seen countless times in big tech corporations(such as Yahoo), not disclosing hacks that put their users and their data at risk. This is unacceptable for a company that claims to be all about their users.
Yes, it's Apple's fault for poor QA that this was released, but this guy also put users at risk by telling the entire world about it without giving Apple a chance to fix it.
You're right, it's about user security before publicity. So make sure users are safe first.
Nowadays, you're "irresponsible" if you don't follow some vendor's own made up procedures.
Disclosing 0day vulnerability via Twitter for the sake of self promotion is bad. Especially when you advertise yourself as a software developer.
It's not a bug; it's a bad design decision. How to initialize the root password on a new machine is a hard problem in a consumer environment. Some people will set it, lose it, and then want support to fix it. One would expect some clever Apple solution, such as initializing the password to random letters and providing the buyer with that info on a scratch-off card. That way, the buyer can be sure no one has seen the password before they use the scratch-off card.
Setting it to null? That means nobody thought about the problem.
Apple put millions of their customers at risk by skimping on QA. As an Apple user I'm OK with this getting out if it motivates Apple to improve their approach in the future.
Edit: as usual, downvotes but no response. I miss when this place was decent.
The very comment you are replying do lists a reason why disclosing huge vulnerabilities without providing upstream time to patch is irresponsible: "because it puts millions of Apple customers at risk in the process."
Your comment doesn't refute the reasoning the comment you are replying to provides, and it also doesn't tell us anything about why you think "There is nothing irresponsible about disclosing huge vulnerabilities in software by any means necessary." You state your position, but offer no rationale, no reason for it; why should I accept your position as the correct or ethical thing to do?
Which is my point. More code, more complexity, more bugs. If you are correct, the security boundary you are referring to got stretched out to accommodate a separate system.
As for your strategy on separating concerns and carefully crafting important code – don't you think that's what they originally had in mind when they first designed it?
loginwindow is not doing the wrong thing because it's complex. It's doing the wrong thing because that was never its job.
> don't you think that's what they originally had in mind when they first designed it?
Probably, but they didn't fail because loginwindow itself was complex. They failed either for systemic reasons that would have happened with simple or complex code, or they failed because the actual secure part was too complex. That's why I think total complexity is the wrong thing to look it; it may or may not correlate with those two real causes.
The drive encryption password hint bug looked like a symptom of something like that. The utility was rewritten in a rush, and it's probably not a whole lot of lines of code. But it didn't have even basic testing.
Yes? Agreed? It's simple, and yet it fails, because of management problems. That kind of management issue can happen to simple code or complex code.
Are you asking me to name a failure that's simple and large/complex at the same time? I'm confused.
Let me restate my position:
You originally brought up total lines of code. mikeash made a point that it's not total lines of code, it's code in relevant system, like ECU or the login service. I'm arguing in support of that point.
Complexity correlates with lines of code. But different subsystems can have different complexities. Especially when they're written by different teams.
The fact that the login service had special behavior wrt com.apple.loginwindow does not mean the complexity of com.apple.loginwindow is a notable factor. Com.apple.loginwindow was almost certainly not designed to enforce the security guarantees that the login service is responsible for. Its role could be played by either very complex code, or very simple code.
If the login service failed because of complex code, it failed because it was made of complex code. Not the total across the entire system.
Go ahead and pretend I never mentioned "systemic reasons" if it makes my argument make more sense to you. That was only about a possible scenario where the problem wasn't complex code. If complex code is the problem, then "systemic reasons" are utterly irrelevant. You don't need to argue that "systemic reasons" are complexity in disguise. Just delete that phrase entirely from my argument.
Anyhow, personally i wouldn't exclude something like this, e.g. suing, as a last resort. Anything that changes apples attitude towards security or at the very least, enhancing the value of security as a product qualifier.
This guy is, with all probability, not the first one to have found it.
I'm not sure what length grace period is appropriate, though.
I think on the (probably intentionally snarky) basis of "just making up statements":
> Since we're just making up statements, I guarantee that Apple would never voluntarily disclose this issue if it was reported privately.
That said, I wouldn't visit jwz's blog at work anyway.
Disclosing this immediately puts those people who can't setup enable the root and set its password into more harm's way.
Let's be clear - Apple put their users in harms way by letting a bug of this nature slip past testing. Disclosing "responsibly" would certainly be nicer to users, but mostly it would be nice for Apple by helping mitigate the bad publicity.
Fixed that for you.
Sorry, I'm not going to cater to the lowest common denominator of "users". If my system has a hole, I want to know so I can get in a fix or shut down that particular feature until its fixed by a vendor.
Ive only 60k machines and 40 clients that depend on that decision. And they agree with me. If something's broke, I can analyse how it breaks and if it impacts us. If it does, we can triage it. I can do a damage assessment. I certainly can't do that if it's being sold on the darknets and whispered.
That assumes you can shut down that particular feature without crippling your business operations. If my system had a hole, I'd prefer that it were disclosed to the vendor before it's disclosed to hackers, adversaries and foreign governments.
In this particular case, the ease of validation additionally works against users.
I've seen the dark side where this leads. It leads to BTC transactions and 0days bought and sold. That's the worst, further past scrappy company sitting on exploits.
I strongly believe in transparency. It empowers users and admins more than any other option out there.
Same applies for Apple. No reason to believe this guy was the first one to find this exploit, we only know he was the first one to publicize it.
True, and this is where the analogy breaks down, since they would not be able to remotely send over a fix. But Apple would, and apparently now has.
- Can be mitigated by enabling the root user with a strong password
- Can be detected with `osquery` using `SELECT * FROM plist WHERE path = "/private/var/db/dslocal/nodes/Default/users/root.plist" AND key = "passwd" AND length(value) > 1;";`
- You can see what time the root account was enabled using `SELECT * FROM plist WHERE path = "/private/var/db/dslocal/nodes/Default/users/root.plist" WHERE key = "accountPolicyData";` then base 64 decoding that into a file and then running `plutil -convert xml1` and looking at the `passwordLastSetTime` field.
Note: osquery needs to be running with `sudo` but if you have it deployed across a fleet of macs as a daemon then it will be running with `sudo` anyway.
$ sudo plutil -p /private/var/db/dslocal/nodes/Default/users/root.plist
Edit: trying a little harder to dump accountPolicyData:
$ sudo defaults read /private/var/db/dslocal/nodes/Default/users/root.plist accountPolicyData | grep -oE '[[:xdigit:]]+' | xxd -r -pAt the risk of sounding a bit pedantic you can't really assume that, it's possible that somebody used this vulnerability, installed some sort of backdoor and then disabled the account to hide their tracks.
However I still can't login as root. This leads me to believe this behavior has always been there, and maybe the login methods just didn't allow an empty password.
As far as I know, possibility of root = root = pwn, game over, time to format.
[1] https://support.apple.com/en-us/HT204899
[2] Unless/until you reboot to a diagnostic monitor on a special partition (which requires pressing command-R from a local keyboard during the POST), then run a command to disable SIP, and then reboot again. Continuity Activation Tool requires users to perform this step as part of the install process to allow installation of Bluetooth drivers not originally signed by Apple.
Instructions from Apple: https://support.apple.com/en-us/HT204012
sudo dscl . -readpl "/Users/dan.koepke" accountPolicyData passwordLastSetTimeSoftware quality in macOS was important back when they were trying to get people to switch from Windows-based PCs to Macs. Nowadays, most people who were going to switch have already switched, so Apple has no incentive to keep up the same level of software quality anymore. They just have to keep people locked into their ecosystem (with iPhone etc.) enough that the barrier to switch out again is high enough.
There is no reason for Apple to improve macOS, since doing so won’t make anyone switch to Macs who hasn’t already switched, and not improving macOS won’t make anyone upset enough to switch back. Ergo, Apple leaves macOS to stagnate, and they will keep macOS at this bad-but-not-horrible-enough-to-switch level for the foreseeable future.
That’s my theory, anyway.
https://forums.developer.apple.com/thread/79235
(spotted by https://twitter.com/fristle/status/935670476214378496)
I should have known that updating to a new MacOS versions before 6 to 9 months have passed is a mistake. High Sierra is in my experience the buggiest MacOS release so far, not only security-wise. The system is not very stable and APFS reduced drive performance … :(
In fact, 99% of the time the only advice you'll get is "restore your iPhone", "restore your MacBook Pro", "restore your Apple TV" and so on into bitter infinity.
I could see how someone would dismiss a posting like that with an "this cannot possibly be true" shrug.
But I'm breaking my brain trying to figure out how in the hell a login attempt for "root" will enable it if it's disabled. Why is this is a possibility, to just enable root, no questions asked?
Kind of ironic that you can easily get elevated privileges with it.
edit: I should say, I did test this locally first so I don't know if a fresh machine that hasn't done it will do the same thing and let a remote account enable root.. Would like to hear if anyone tested it remotely WITHOUT doing it locally first.
While it's unlikely, there are probably plenty of users who have done this for some reason or another.
Don't underestimate a user's ability to blindly do things like this by following arcane instructions in attempts to fix an unrelated problem.
https://www.youtube.com/watch?v=FpOH0lxEGBE
They seem to be remotely accessing the machine to both set and then use the root account.
Not sure if you'd get different results after logging in as root at the login screen...
I know testing is hard, but a company with Apple’s resources shouldn’t be making slip ups like this. It suggests some real issues such as lack of unit/automated tests and/or sufficient release testing, which pretty urgently need addressing.
Anyone got any inside scoop?
TechCrunch, if you're reading this... please discourage people from reproducing the bug.
"We are working on a software update to address this issue. In the meantime, setting a root password prevents unauthorized access to your Mac. To enable the Root User and set a password, please follow the instructions here: https://support.apple.com/en-us/HT204012. If a Root User is already enabled, to ensure a blank password is not set, please follow the instructions from the ‘Change the root password’ section."
https://twitter.com/unsynchronized/status/935656609140711426
That seems to match the technical explanation of the bug here:
https://objective-see.com/blog/blog_0x24.html
The tweet claims they've got Apple Remote Desktop access & screen sharing working via the _applepay user account. Why/how that's possible, I have no idea - I don't have High Sierra to confirm this, and I'm not sure I'd want to mess with the _applepay user account even if I did.
1) open Directory Utility app (via Spotlight or other) 2) Click lock to make changes, log in with admin account 2) Click Edit -> Enable Root User 3) Click Edit -> Change Root Password… 4) Set a password 5) Do NOT disable root user!
If you disable the root user, the admin prompt will create it again with an empty password.
My personal policy: If there's a workaround or mitigation, then full disclosure is more responsible. If there isn't then report to developers and CERT or similar. Never report only to developers, always have a deadline for full disclosure, and always have a third-party (CERT, Project Zero, etc) to disclose if you come under legal fire.
It seems like root has no password by default. Setting one is enough to close the hole. This is unbelievable!
Curious to see what's in /var/db/dslocal/nodes/Default/users/root.plist before trying this.
Protect yourself by changing root’s password: ⌘ (Command) + Space, Directory Utility, click the lock and enter your password, Edit -> Change Root Password…, then do NOT disable Root User.
Or open a terminal and do:
sudo passwdor just enter root with no password
dsenableroot -d
sudo passwd
I think it would be best to recommend an unambiguous
sudo passwd root"sudo passwd" unambiguously changes the password of root.
Come on Apple you have a quarter trillion dollars in the bank why don't you spend some on improving your software.
https://forums.developer.apple.com/thread/79235
Screenshot. http://oi67.tinypic.com/2h6embp.jpg
Well, sparing software. I've had intermittent phantom screen input using the latest betas on the X, making it infuriatingly unusable at times.
Instructions here: https://support.apple.com/en-us/HT204012
https://aws.amazon.com/blogs/apn/why-sponsor-aws-reinvent-20...
It seems like the best mitigation for the moment might be to enable the root user and set a password for it.
It is really ironic that a company, making billions of dollars and branding itself as the leaders of quality, stability and so on, to have this kind of vulnerability.
I have truly lost faith in Apple.
iOS 11 was the tipping point for me (can't delete photos using trash icon, wrong orientation when unlocking phone, random lag/freezes etc).
Apple just doesn't care any more.
(Sorry, couldn't resist writing :) )
> and branding itself as the leaders of quality, stability
> and so on
Should it happen ? Obviously not. But even popular open source software used by millions and developed by hundreds is not free of issues like this, like Heartbleed showed.
The core applications that I use (Firefox, Docker, VSCode, vim, ...) all work just as well on Linux, MacOS and Windows.
I have a Mac, because it's (at least previously) been pretty secure by default, doesn't require me to invest a lot of time sysadmining my own box, and lets me dip into a healthy ecosystem of commercial software useful to my hobbies (like photography.)
The software has definitely declined in quality, but not enough to massively annoy me.
If there is lock-in, it's on the hardware side. I've got an early 2013 MBP, still going strong, a bit dented but it's been around the world with me a few times, so that's understandable.
My workplace uses Dell XPS hardware, and that's good, but it still doesn't feel as solid to me. It's good, but it's not as good.
I think the hardware is the laurel Apple has really been resting on.
I could meet my main use cases on Linux quite happily, and dual-boot Windows for the rest. Right now the premium on Mac hardware, which only happily runs an increasingly decrepit operating system, isn't looking worth it. Previously, it was.
Most people don't realize but the vast majority of Video Editing was Windows based till about 2010 when Final Cut was considered best in class (I can't stand Final Cut myself but to each their own...) The vast majority of video editing is now Premier due to Apple's handling of Final Cut Pro and the lack of support for the Mac Pro (They usually sit in back rooms as expensive file servers) Also most people mentally think that somehow Apple is better for design but the software runs just as well on Windows.
The iPhone and the money spent on software is what is keeping people these days. But whenever I talk with my friends they are certainly not thrilled and zealots of Macs anymore. The vast majority of my video editing friends are getting really frustrated with what they call the ceiling. Do you really want to be editing full time on a lap top? The Mac Pro isn't a real solution for full time editors.
I believe not only that for the majority of users there is a level of software lock-in, but further there is a high level of psychological lock-in, where users get used to and comfortable with Apple's design strength, which is Apple's main offering.
As people get more comfortable and more older it is easy to say that people get more resistant to change.
Photos, apps purchased, and iMessage are overwhelmingly the reasons I don't see people switch. All their kids photos, etc, are stored away and they'd have to figure out how to nicely export them. iMessage is seemless for them across devices while an alternative like Hangouts doesn't have the market penetration—it isn't ubiquitously used even among just Android users. Apps purchased I added to the list because often people don't think about it, but if you mention "re-buying all your apps" you see the frown appear on their face.
I personally prefer Windows, but as a software developer I had to buy a Mac, I grew tired of having to always power-on a Mac OS X virtual machine. My job is so much easier now then it was on windows.
I have the macbook pro, iphone, watch, airpods, and they all work pretty great together. It's a cohesive experience that is going to be really hard for me to break out of it.
But you're right, I could probably switch to Linux and be fairly happy.
- Large iPhoto library - Easy syncing with multiple iPhones (notes, photos etc) - Xcode for iOS development
Edit: By the way, regarding the vulnerability, ANY password you use when you first attempt to login as root BECOMES root's new password. (Blank is a red herring.)
So if you're going to test this, maybe use something non-obvious. In a terminal, setting a strong password for root with "sudo passwd" is the quickest mitigation.
Ill-advised, but in a pinch, you can apparently 'secure' a machine you don't otherwise have access to by attempting to log in as root with a long random password you fail to remember. An admin on that machine can later change root's password with a "sudo passwd".
Also, it appears the "dseneableroot -d" command suggested elsewhere here fails in preventing root login.
Try it and post a top level comment now. I'm pretty sure it won't be at the top initially because you don't have enough karma for that.
That said, between this, the disk encryption bug, not being able to type "I" on an iphone you have to wonder what is going on. I recently upgrade my MacBook Pro to High Sierra and it's been plagued with problems (Weird red flash when displaying menus, hangs/crashes with external monitors etc.)
Then I look at switching away, and I lose all the OSX software I own, all the easy iOS integration, all those Pages documents etc.
Maybe I just need to build a cheap but upgradable Linux box and start trying to switch.
https://taoofmac.com/space/blog/2016/10/29/2240
I have to use Windows for work, though (I'm at a Microsoft subsidiary, and all we get are Windows machines), and I can live OK inside WSL.
A lot of macOS users would actually prefer Apple to do less with it than what they are currently doing.
I don't know much about this bug but I have seen several reports that the bug has actually existed quite some time and is not new, only the publicity surrounding it is now shining a bright light on it.
I’m not so sure about this — although it may be due more to the hardware side of their business: after the recent, disappointing iteration of their MacBook Pros I’ve heard a lot of people considering to switch (and actually switching).
Taken together with software quality issues, I wouldn’t be surprised if at least a subgroup of users are leaving Apple gradually. That subgroup being professional users, of course: Apple is still unassailed as a status symbol, and casual (+ mobile) users seem more than happy.
Remember that back when Apple made only computers, right before the iPod, they were on the verge of bankruptcy and barely profitable.
Since then their laptops have taken off, of course, and I have no idea how much money they make off them. But compared to the huge torrent of cash Apple makes off iPhones I can't imagine the beancounters see a huge amount of value in investing heavily in the parts of OS X that aren't shared with iOS.
Much like the importance of feeling safe in our own house, if the computer that houses our information suddenly makes us feel unsafe or exposed, we'll naturally seek other options unless the issue is, shall I say, swiftly fixed or easily fixable.
They can't afford to wait 2 years (or whatever) to update the phones, and Mac OS gets pulled along for the ride.
Of course all that changed when its only priority became to shift more iPhones, and everything became secondary to that.
So it’s not that there aren’t still people who could conceivably switch to Macs, it’s that Apple decided they didn’t need more converts quite as badly anymore.
Still, only my theory of course.
For some examples, look at the impression of Microsoft and Windows when it comes to quality. It is only now starting to improve, with gigantic efforts from Microsofts side. Another example is Linux and usability, which have constantly gotten better (maybe still not good enough, but that's better left for another thread) but still many see Linux as "advanced" and only for power users. These are not perfect examples, of course.
What I mean is that I think it's bad strategy on Apple's part (if they're doing this deliberately), especially considering the resources they have at their hands. I wouldn't be surprised if Apple could increase it's desktop market share further by positioning themselves as high quality. However, it's a reputation they are losing fast.
Is it? They axed their internal QA and definitely aren't catching all the bugs with the "Insiders Program."
After the Fall Creator's Update I've had to log in twice (after the first one I just get sent back to the login screen).
The workaround is disabling a setting: "Use my sign-in info to automatically finish setting up my device after an update or restart."
I'm also getting repeated alerts that a restart is required to complete installing an audio driver, but restarting doesn't finish it. I probably need to track down the responsible driver, uninstall it, and reinstall manually or hope Windows does it.
Obviously that's not as serious an issue as unauthenticated root access, but in day-to-day use of my Windows computer I don't have a very positive impression of their software quality.
I've heard of a lot of people switching away from Macs to Linux and Windows, especially with Windows building up their own official Linux subsystem now.
PC hardware is cheaper than Apple's, and hardware (even the "good stuff") becomes obsolete after 5 years anyway. Besides, most software is cross platform these days.
The only real good retention plan Apple has is that we can't release iOS apps without owning Apple hardware; there's a few Mac-specific software titles that certain professionals rely on; and a little bit of "it's overall higher quality than PCs" mindshare that some people still have either from the 80s and early 2000s, but that can't last long if Apple keeps this up.
The new MBP isn't attractive anymore. The software stagnates. The only reason I keep using Mac for usual use cases is just its wonderful collection of dictionaries (I like to constantly learn new languages). I wonder why no publisher ever bothered coming up with a decent dictionary software on Windows/Linux yet instead of making do with crappy online versions. If they did I'd happily just use a Windows + Linux dual boot machine.
I wouldn't be so sure about that. There are a lot of "about to switch" people out there, in both directions, who are just waiting for either the extra nudge or the extra reason to not switch.
At the logon screen, just pressing ESC got you to the desktop.
Incompetence seems to be a more likely fit here than that.
Now that Google Docs and Office 365 are "good enough" for most things, I would probably be happy to go back to Linux if there was a Linux machine that had comparable build quality yet was a bit cheaper than a Mac.
I'd mention aesthetics, but the current Linux distros look quite good, plus they're customisable.
There's a specific line somewhere that's doing this, in theory.
Maybe they should have opted for "create `root` with unguessable password"
It would have to be that looking up the root account enabled it, maybe users go dormant or something, and this was a way to readd them? then once it was enabled it defaulted to a blank password, but you would think that it needs sudo to enable root in the first place.
Edit: Which also means it's possible to "secure" a vulnerable (unexploited) machine simply by attempting to log in as root with a long random password.
IMHO these are two separate bugs: promoting disabled accounts and using the password the user typed in instead of the value in the password list.
But this does indeed seem to be an extra level of user-friendly stupid.
Apples user management is even more complex than most Unixes.
A guess: there's a code path in the UI that is only tested on "mac" accounts, not the root account that the system requires to exist. Something about the non-macness of the root account interacts badly with the UI that expects to be run on a mac users account.
Or because people care to inspect the codebases they otherwise use?
https://www.gnu.org/philosophy/open-source-misses-the-point....
/System/Library/CoreServices/Applications/Directory Utility.app
Edit > Change Root Password
Anyone who does this should probably set a password for now and then disable the root user account once it has been patched.
Insufficient testing at today's Apple is not limited to software. They bragged about their extensive input testing lab [0] when the new line of Magic accessories was released, but the Magic Keyboard with Numeric Keypad launched last summer had all of its inventory pulled from the channel last month because users discovered that the model was so thin that its midsection bowed over time.
[0]: https://medium.com/backchannel/what-i-saw-inside-apple-s-top...
But since I don't work there, I have no good inside info. But just from gut feel, I don't think my anecdata is too far off the mark. Based just on the bugs made public, I just don't get the impression that there are testers at Apple whose sole reason for being there is to tear into a piece of software and break it. There was a bug a few weeks ago posted to HN that I commented on. I don't have a link without digging through my comments, but it was something along the lines of "how could a tester not find this in five minutes of exploratory testing?" This bug is similar. It would take more than five minutes, but were this my area to test I'd pick at it once in a while when I had a few minutes. As I pick at it, I wouldn't expect to find anything, but I've got a minute between builds, so instead of randomly clicking Facebook I'll randomly click this dialog. What did the dev forget? What weird state was not accounted for? Some kind of state overflow if I click the button enough times? Shove some Unicode in there, that didn't find anything; meh, maybe I ought to move o...hey, wait a minute. Did that thing just log me in as root?
But my gut says that Apple doesn't employ a lot of testers like that.
For example, I do not own an iPhone, but at work, I made a bet with my colleague (jokingly) that I could break _something_ on his phone in a few minutes.
I did not have his finger print or pin-code, so I was very limited, I even joked "I don't need that, give it here!"
Finding out I only had a hand full of options, I focused on the emergency dialer. As any good tester would be curious about, I wanted to check the max field length, so I entered digits, copy/paste it a few times, copy/paste that string, ("wait, no limit? Not even at 1000? why?") and so on, until I noticed the interface became laggy, so of course, I kept going.
Boom, suddenly back at the login screen, tried to open the emergency dialer, but got a full blank white screen, in the meantime the phone started heating up substantially. Since it was a new Phone (iPhone 7 with iOS 10.x I believe) and the dev getting nervous, we decided to reboot it. That fixed the issue. (Curious if this is still an issue in iOS 11.x)
TL;DR: As a tester this simple curiosity should be in your blood, and especially covered in behavioral tests when your software has been around for 5+ years.
Actually, I've been wondering why I hear less about people working at Apple than at other big tech companies. It seems everyone and their mother work at Google or Facebook, but no so much at Apple. Do they have less software engineers, or their employees are required to be more discrete?
They’re now retreating from that strategy: https://factordaily.com/apple-to-pull-back-development-work-...
Are there any "(tech) household name" engineers doing system-level work on iOS/macOS these days? It seems like Google and Facebook have a slew of them.
Of course, until recently they had Chris Lattner as well.
[1] For some iOS releases, they converted HFS to APFS in-place, report the results back to Apple, but did not write the APFS 'superblock' to keep the filesystem HFS+. It's quite a smart idea, because they got reports from millions of devices without actually switching them to APFS.
I have a feeling that anyone who does would get fired for commenting here about it.
Open software enables people to take a look inside to what is going on. It isn't a cure for bug free development.
At the minimum, i'd say i feel apple release less innovating os versions while producing at least the same number of bugs.
That should be much higher up in the article.
Apple's going to have to nuke everyone's root account on an update. I don't see any other solution that won't leave a shitload of machines with open root accounts from trying the fun tweet and then never setting a pw.
1. Try logging in with root and a good password. It should not work (if it does, root with that password had been enabled before).
2. Now, try logging in again with root and that same password.
2a. If it works, your system was vulnerable to that bug, but you've now fixed the problem, as you've enabled root and set a good password (so nobody else can log in unless they find that password).
2b. If it doesn't work, it looks like root had been set up before with some other password (maybe empty), and it's conceivable that someone has exploited that bug on your machine before.
Is that understanding correct?
What should be done is that Apple releases fix to this problem.
Once you enable root access - by 'testing' this - others can remotely & silently access the system as root.
GP is right - don't encourage people to test this, as there's nothing to gain from it. If you're on a shared machine you need to mitigate. If you're on your own dedicated machine you need to not share it until this is fixed.
Once done, you have opened for root without password globally. That's bad.
What they should do, as responsible disclosure dictates, is report it in secret to apple, and at most publicize a workaround (activate root user, set password) without reporting the details of the vulnerability.
EDIT: It does not appear to be limited to admin users. It appears to be related to disabled root accounts of older origin, such as through upgrades. I cannot reproduce on a fresh High Sierra install, but I reproduced on an upgraded install.
https://gfycat.com/gifs/detail/sentimentalnaiveantelopegroun...
Otherwise the hole is still there for others to exploit.
Edit: I was partly wrong. The bug still works if you disable root afterwards, then it reenables and resets it.
Sounds like something's wrong with your friend's computer, because neither of those issues are reasonable to expect no matter what your opinion of Apple's software is.
> But the submit button on their developer site is broken
Given the number of people who've successfully gone through that form, I'm willing to bet it's a content blocker extension that's blocking some dependency the form needs.
> And now shipping an operating system with a root account with no password by default.
The OS actually ships with root disabled. The bug isn't that there's no password (after all, a factory-set password isn't any more secure), the bug is that the login form is somehow re-enabling the root user when it's not supposed to be able to do so.
Doubtful Firefox and Chrome work just fine.
> Given the number of people who've successfully gone through that form, I'm willing to bet it's a content blocker extension that's blocking some dependency the form needs.
Brand new install of Mac OS on a new SSD. So Safari was clean no extensions, no custom configuration.
> The OS actually ships with root disabled. The bug isn't that there's no password (after all, a factory-set password isn't any more secure), the bug is that the login form is somehow re-enabling the root user when it's not supposed to be able to do so.
Mere semantics, It doesn't matter if root is being "reenabled" or not. From an attackers point of view High Sierra effectively ships with root with no password.
Neither is your password showing up in a password hint field (or anywhere for that matter... why is it even stored unhashed?).
Neither is logging in with a blank password enabling a disabled root user.
In my personal experience Windows has been much better than MacOS for me. I've been using Windows 7 for the last year at work and I'm having significantly less problems with Windows then MacOS. But Windows and MacOS both give me more problems then a FreeBSD or Linux box ever has.
The other day I had to use vanilla Windows 10, and wanted to save a text file from Edge. Nope, there's no such functionality. The closest thing to save is print to PDF.
Apple's sales per square foot in their stores is really high. Having some place to take your computer to when you need help is extremely valuable for a lot of people. Why don't Samsung, Dell, Lenovo, and HP all have their own stores in every neighborhood that has an Apple store? Is the Apple store only successful because of the iPhone?
EDIT: apparently, the first login attempt with root enables root login with whatever password is provided. Then, when you try again, login will work.
If that's true, we have a combined diagnostic and workaround:
Try logging in with root and a good password. It should not work (if it does, root with that password had been enabled before).
Now, try logging in again with root and that same password.
If it works, your system was vulnerable to that bug, but you've now fixed the problem, as you've enabled root and set a good password (so nobody else can log in unless they find that password).
If it doesn't work, it looks like root has been set up before with some other password (maybe empty), and it's conceivable that someone has exploited that bug on your machine before.
Is that understanding correct?
I could do it on guest account, by first pressing enter after entering "root". And after a fail, clicking the unlock button.
However, user labcomputer is right, I doubt that applies to the solutions proposed by OP here. Well, I'm certain: root can switch out the shell or terminal emulator binary itself and have it lie about executing those commands and return something trustworthy. One way or another, to truly check this, you'd need an immutable audit log (probably not currently available), AND a reboot into safe mode or a mount as a HDD onto a safe system.
Yes, Apple monitors them, but apparently not closely enough :/
Checking the dev forums was my favourite thing to do in IT class at school :)
These days, I get that (especially now that they're open) the forums are too saturated with content to have engineers on the ball all the time... But the Captain Hindsight in me thinks they could have done with some keyword notifications to nip instances like this in the bud...
Sorry that the free support for your expensive device does not match the quality of the non-existing support from your device vendor.
The reason people throw fits is because the experience between a group messaging together on iMessage is exceptional - this experience breaks down when even one of your friends in the chat doesn't have an Apple product. They aren't able to send or receive the majority of the "chat add ons" iMessage provides. I'm sure making the bubbles green vs. blue only helps to stoke the "us vs. them" fire.
I consider myself to be a reasonably technical user and still prefer to message with iMessage since I know the experience will be the same for everyone I'm chatting with. Yes, we _could_ all start using WhatsApp et al, but if 8/9 of our group message is on iMessage, why would we?
If the system can't generate a secure hash, or can't generate cryptographically random numbers, you're in serious trouble. Those tools are foundational to security.
Moving the problem from "a root account is created with the first password you try" to "you have to break crypt(1) or /dev/random" is basically equivalent to solving it.
Perhaps the root issue here is forgetting that the asterisk indicates that the account is disabled and shouldn't be a candidate for promotion.
Otherwise I don't care which browser you are using to look at my pages, or which Desktop to run my qt app.
There was a massive influx of developers switchting to mac laptops before it was popular with a majority of users (around 2008).
Or is this not a permanent password set?
But, if you don't have Screen Sharing or Remote Management enabled and exposed to the WAN, you're probably safe unless someone untrusted had physical access.
It's hard to know how long this vulnerability was "known." The initial report on Nov 13th looks second hand, so it may have been circulating earlier.
They definitely have a more modern design language going, but they're not exactly consistent about it.
All in all, it took me about a minute to break it, and around 5 minutes to get it working again. I was getting a bit nervous.
- Performance
- Usability
- Brute-force capabilities
- Error handling
- And in this case, Security, a bug where trying to log in a couple of times on the Login screen with an empty, or set, password.
A test scenario closer to this would be:
---
When I am on the login screen
And I enter 'root' in the 'Username' field
And I enter 'thispasswordisfalse' in the 'Password' field
And I press the 'Login' button '10' times
Then I should see the text 'Your password is invalid'
---
Please note that this issue is not just in the Settings page, it takes place on the login screen as well, that's why I'm shocked, it's such a core functionality, touching so many system components.
Unlike doing this through the GUI, this seems to retain the root password and prevent this vuln from re-occuring.
I've tested both approaches - disabling via the GUI causes this bug to re-occur next time you try, disabling via the shell does not.
To be flippant, I might say HN discussions seem to QA using Apple methods.
And bad design choices lead to further bad design compromises. Now when you go view a website in landscape mode, the browser adds unsightly white bars on either side of the screen [1], breaking the immersive edge-to-edge continuity, for no other reason than to accommodate the notch. Ugh.
1: https://twitter.com/thomasfuchs/status/907764896829452288/ph...
ex:
daemon:*:1:1::0:0:Owner of many system processes:/root:/usr/sbin/nologin
operator:*:2:5::0:0:System &:/:/usr/sbin/nologin
bin:*:3:7::0:0:Binaries Commands and Source:/:/usr/sbin/nologin
tty:*:4:65533::0:0:Tty Sandbox:/:/usr/sbin/nologin
iMessage absolutely is a lock-in for iOS, though.
At this state in the company's life there is a disconnect between those who make the software and those who make the business decisions.
I don't think it's likely that Apple's board just decided to give up attracting new customers, and any apparent decline in quality is likely attributed to bad management; ineptitude, rather than purpose.
Occam's Razor supports this hypothesis.
The DEC Employee Handbook made a big deal out of Doing the Right Thing. Obviously that was subjective, frequently debatable, and sometimes just a pain in the ass - but it was a guiding principle for engineers of that generation, and for engineers who became managers.
And it produced some outstanding engineering and innovation.
Because it actually means "Do the best work you can, for your own self-respect, and also because you respect your users."
That's light years away from "Screw as much money out of your customers as you can, as many overtime hours out of your developers as you can, and if the product is broken - who cares if the money keeps coming in?"
Some security bugs exist in the Linux/BSDs kernels for a loooong time before someone notice and fix it (e.g., https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20pre...)
It's not stored unhashed. And the password hint field never showed the password, it always showed the password hint.
The bug was Disk Utility's UI was accidentally using the password field instead of the password hint field when passing the data to the underlying API.
> Neither is logging in with a blank password enabling a disabled root user.
Stupid and awful bug, sure, but I actually can understand it. Something that's worked fine for years breaks because of some change to some underlying system, and there weren't any existing tests to see what happens if you try and log in as root (root has been disabled by default for something like 15 years, so it doesn't surprise me that people don't test trying to log in with it).
But apple.com not rendering right in Safari? That doesn't make sense, you know damn well apple.com is basically designed to be viewed in Safari and everybody that works on it is going to be using Safari with it.
And Safari not being able to load HTTPS sites makes even less sense. That literally breaks most of the web. This has to be an issue with the local computer.
On my laptop I was able to exploit the bug from the local GUI and then disable it from happening (as far as I can tell) by changing the root password from the shell with sudo passwd root and then disabling the root user altogether with dsenableroot -d
sudo passwd -u root
It's sad we have to do this, though.
That doesn't mean anything. It just means that whatever is messed up affects Safari. It's not like the computer recognizes "oh those 3 apps are all web browsers, therefore if I'm going to screw one of them up, I have to screw them all up". Your claim would carry more weight if you were listing multiple browsers that all use the same system-provided WebKit.framework, but Firefox and Chrome are completely separate browsing engines.
Regarding the HTTPS issue, I believe Firefox and Chrome maintain their own list of root certs, so one possible way the computer could be screwed up is having the system-managed root cert list be damaged (you didn't specify what actually happens when trying to connect to HTTPS sites so I don't know if this is actually a plausible cause in this particular case).
> Brand new install of Mac OS on a new SSD. So Safari was clean no extensions, no custom configuration.
Well I don't know what to tell you, except to point out that there's, what, hundreds of thousands of registered Apple developers now? who've all had to go through that form, and there's only a handful of people on that thread, so it's far more likely to be a local issue.
That fact that everything besides Safari works certainly means something and the fact that they have different rendering engines is irrelevant. What is relevant is whether a site renders in a browser or not.
> Well I don't know what to tell you, except to point out that there's, what, hundreds of thousands of registered Apple developers now? who've all had to go through that form, and there's only a handful of people on that thread, so it's far more likely to be a local issue.
Well that's just one example of dozens of people having that problem. Also I have successfully filled out that form my self in the past, as I am a registered apple developer. But just because large amounts of people can use the form successfully does not mean that there isn't a bug affecting other user's like my friend.
I'm interested.. What kind of problems?
> But Windows and MacOS both give me more problems then a FreeBSD or Linux box ever has.
I switched from linux on the desktop to MacOs precisely because of the problems linux had - driver support, even LTS updates breaking functionality, and overall clunkiness. I run linux on all my servers.
I've run Linux mint on my desktop at home for a few years now and have had zero problems at all (Intel i5, Nvidia gfx, wired connection).
The last time I had driver issues with Linux was ~10 years ago and it was for a laptop running Ubuntu.
To convert this into a human-readable date and time, open a terminal and do this:
python
>>> import time
>>> time.strftime("%a, %d %b %Y %H:%M:%S", time.localtime(1474441704.265237))
(I'm sure you can do this in other languages than python...)
date -r 1474441704If I understood correctly, this particular bug was only exploitable from the GUI and this machine hasn't been away from home, so it's likely this isn't related, but posting here, in case it's part of a bigger picture.
Did you also have sshd running, and do you know what kind of network you were using at the time?
But I think if you keep compiling for older versions you should be able to stay on an older version for a while without newer versions of the OS refusing to run it.
It's just that sometimes new features are introduced that require you to change something in your application because there's a new or deprecated framework. Apple likes to break things to not drag a lot of legacy around.
Immersion was their goal with the thinner bezels. The notch hinders immersion in instances such as browsing with Safari in landscape mode where solid-colored padding is added on both sides for the sole purpose of compensating for the notch. The notch also draws attention to itself. They missed the mark.
Don't get me wrong the notch enables novel functionality. But they should have figured out how to do it without blocking out a chunk of the screen.
But unlike you, I have actually used the iPhone X extensively and I find the experience incredibly immersive. I have done the same with the Samsung Galaxy S8 and I find the iPhone X more immersive - yes, even with the notch.
Unfortunately I can't afford either, so I have a OnePlus, but if I could, I'd get the X.
My hope in recommending people disable this way is that with the additional scrutiny on this subsystem, accounts disabled this way will remain genuinely disabled in a future update. Either way this doesn't seem to reintroduce the bug.
... but the whole thing is a mess overall.
Playing around with disable/enable and the exploit: Root always has a /bin/sh shell "Disable root user" removes the ShadowHashData from the directory services entry for root The bug sets ShadowHashData to the hash of an empty string.
Now, ShadowHashData is a complex DS entry. I've never seen passwords represented this way in other OSX versions. I think this password storage format is new.
I strongly suspect the bug here is one related to OSX attempting to upgrade the password to the new storage format and when it does that, it inadvertently stores the password with a hash of null.
This should be very trivial for Apple to fix that (and thus "disable" the root user) by just removing any ShadowHashData that is solvable by an empty string.
I think the feature that caused this is related to upgrading pre-high-sierra user password hashes to high-sierra-style hashes.
The fact that it works for situations where the password is null is a/the bug.
I know but a few that work at Apple, and of those few they strike me as less forthcoming than the multitudes I've worked with and know at Microsoft. I've wondered if part of that is because Microsoft previews/pre-announces just about everything, whereas Apple (mostly, and not so much anymore) announces it when the shipping trucks show up at the local Apple store.
So the outcome from the Microsoftie is, "it'll do this that and the other, but that's all I can say right now." From a recent conversation with an Apple employee: "they make me go in a special room to use the hardware, and I can't work from home. That's all I can say."
Probably more so, last I looked, Apple has considerably fewer software employees than the other big companies.
I don't think this is true. Apple, Google, and Microsoft all have on the order of 100K employees.
Yes, I believe so. I've heard there are strict requirements on even internal discussion. (Who you can talk to; about what; where.)
The only people I know locally that work for Apple are remote customer support folks.
When I worked at a major printing company, they were not using Macs because people would THINK they were color accurate when they were very much not, and we had a bunch of calibrated Dell monitors around specifically for that purpose.
So definitely more of an urban legend than anything. Apple displays are reasonable, they're decent IPS panels, but they're middle of the road if anything.
People need to buy calibrators. I use the open source ColorHug it runs on Linux so I actually use a live cd and do the calibration. http://www.hughski.com/
I calibrate my monitors with DisplayCAL[0] on Linux.
There should be one calibrator in every office, the difference it makes is enormous.
Yeah Apple is making some very bad mistakes in their software quality, but there are two things that are very essential to the Mac experience that still make it the most straightforward choice.
One key advantage Macs have over Windows is that they run Unix. You can open a terminal and be involved with most of the Linux/Unix monoculture that exists and have access to much the same tools. No VMs and all the hassle they bring to take into account, mostly at least.
One key advantage Macs have over Linuxes is the availability of good quality graphical software. If you like a GUI for Git, the best are available on Mac. It has OmniGraffle, which many regard as amongst the best diagramming software out there. It runs a very decent version of Microsoft Office. Many would argue that - especially for developers - the software ecosystem for Macs is even superior to Windows. And add on top of that is that this also runs on a still mostly flawless out-of-the-box experience.
Sure, I bet most people could switch to Linux or Windows if they wanted to go through some effort. But it's more than a mental lock-in, you give too little credit to the Mac ecosystem. It might not be the obvious best place to be anymore, but it's still great value. As was pointed out before, this seems to be something that Apple is okay with.
I really hope Apple feels this security incident steps up their game - they deserve all the hate they get for this. But the Mac value proposition will barely change for most people, as sad as that may be.
Please note as disclaimer that although I do use Macs sometimes, I spend most of my time on Windows and Linux systems.
Thankfully we are getting there with "Windows Subsystem for Linux." I am using the OpenSUSE subsystem which you can install in the Windows 10 store. It isn't perfect but it sure is getting closer.
But then you have to run Windows. I still prefer MacOS by a large margin. I would move to Linux, but I want Photoshop and more of that without having to start a Windows VM.
Back in the PowerPC days, a large part of every keynote was getting Phil on to press the spacebar so we could all see how much slower Photoshop was at making the poster for Inspector Gadget. Can't help but feel like this was where a lot of people cut their teeth on this opinion. While Mac OS 9 and its users (niners) are a tiny minority now, I suspect a lot of those shops moved to Mac OS X.
But that was all a lie about the speed of Macs. It was absolutely smoke and mirrors. Intel CPU blew the doors off the Power PC. Case in point, Apple switched from Power PC to Intel and saw a huge speed increase. The "Cult of Mac" was 100% anti-Intel and people would tell me that the G5 Power PC was the fastest personal computer you could buy. All lies and dishonesty. Apple for years caused huge animosity of "Apple Fanboys" vs Intel.
As such, it's very dangerous for people to try to verify and should be strongly discouraged.
[1] https://www.computerworld.com/article/2528936/mac-os-x/snow-...
It also marks the decline of the desktop UI to introduce increasing amounts of iOS-like behaviour and appearance to the detriment of a usable desktop. Like proper scrollbars etc.
While some nostalgia might account for holdouts, it was the peak of MacOS in the minds of many, including myself. As a developer, I've been quite disappointed by its direction and declining quality. For the amount we pay for this hardware, it's not much to ask for some basic maintenance work and testing to be done.
Also I think when most people think of Snow Leopard they're thinking of 10.6.8, at least that's the version number you always see get thrown around on the internet.
Unless you’re arguing Lion wasn’t major because you didn’t like it, but that’s an argument that proves to much, methinks.
In my opinion, there's a point at which it becomes irresponsible to let them sit on issues for so long, but their newspeak for the disclosure policy tries to pre-empt that idea.
Somebody in Turkey has no expectation that they will be treated with respect. It's much more likely they will be attacked as in "shoot the messenger." (So, please don't attack the person who brought this to our attention.)
I think they made a reasonable decision, due to the critical nature of this bug, and tweeted about it.
The DMCA is a disgusting and absurd set of laws that can always make me angry. Its existence alone proves very much how big companies can rule with money, placing capitalism over democracy.
The factors that differed from my laptop, where it worked until I set a root password, as that her machine was a fresh install, and she is not admin (a managed machine).
If we assume that ShadowHashData hash was introduced in High Sierra, I thought it was safe to assume that a crypt hash would only origin from a pre-High Sierra install. Unless, of course, they are used as some form of default value (such as when disabling the user)...
They already can:
https://gfycat.com/gifs/detail/sentimentalnaiveantelopegroun...
Source: Just tried it myself.
I'm advising folks (incl. non-tech) to set a root password and then re-disable the account (specifically via shell), which prevents this from re-occuring:
Really bad stuff
That's not accurate. The user appears to be there either way, but attempting to log in to a machine remotely using 'root' and no password does not work - even after doing the preference pane thing...
root account is 'there' all the time, yes. This process enables the account proper (rather than just sudo). Evidently some remote mechanisms using root work after the account is enabled.
But yes, responsible disclosure includes a deadline (60 days?). Flexibility granted if the company truly needs it, and the nature of the vulnerability requires discretion until fixed. A major widespread flaw with no workaround short of air-gapping the machine would be wise to keep secret until fixed.
Microsoft are the other big one.
The "right" thing is far more complicated than people who have no experience working with vendors to fix bugs like to assert.
There is some game theory here. The rationale is that if vendors know that GPZ will sit on their vuln until it is fixed, they are not forced to take the deadline seriously. For that reason, GPZ must remain firm on their deadlines, and everyone knows that if you try to call their bluff, you are going to lose that bet and have an even bigger mess.