- 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 -p
At 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.
daemon:*:1:1::0:0:Owner of many system processes:/root:/usr/sbin/nologin
bin:*:3:7::0:0:Binaries Commands and Source:/:/usr/sbin/nologin
To convert this into a human-readable date and time, open a terminal and do this:
>>> 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 1474441704
If 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?
As far as I know, possibility of root = root = pwn, game over, time to format.
 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.
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.
Instructions from Apple: https://support.apple.com/en-us/HT204012
sudo dscl . -readpl "/Users/dan.koepke" accountPolicyData passwordLastSetTime
Software 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.
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.
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 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.
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.
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?
But you're right, I could probably switch to Linux and be fairly happy.
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?
iMessage absolutely is a lock-in for iOS, though.
- 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.
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.
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).
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.
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?"
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.
They definitely have a more modern design language going, but they're not exactly consistent about it.
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.
(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 … :(
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.
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.
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.
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?
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.
There's a specific line somewhere that's doing this, in theory.
Maybe they should have opted for "create `root` with unguessable password"
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.
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.
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.
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.
Perhaps the root issue here is forgetting that the asterisk indicates that the account is disabled and shouldn't be a candidate for promotion.
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?
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.
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.
To be flippant, I might say HN discussions seem to QA using Apple methods.
sudo passwd -u root
It's sad we have to do this, though.
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.
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.
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?
Insufficient testing at today's Apple is not limited to software. They bragged about their extensive input testing lab  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.
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.
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.
- 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.
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?
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.
They’re now retreating from that strategy: https://factordaily.com/apple-to-pull-back-development-work-...
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.
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.
 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.
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...)
At the minimum, i'd say i feel apple release less innovating os versions while producing at least the same number of bugs.
TechCrunch, if you're reading this... please discourage people from reproducing the bug.
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.
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.
They already can:
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.
As such, it's very dangerous for people to try to verify and should be strongly discouraged.
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.
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.
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.
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.
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.
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
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.
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)...
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).
"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."
That seems to match the technical explanation of the bug here:
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:
or just enter root with no password
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.
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.
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.
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.
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.
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.
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.
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.
Well, sparing software. I've had intermittent phantom screen input using the latest betas on the X, making it infuriatingly unusable at times.
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 , breaking the immersive edge-to-edge continuity, for no other reason than to accommodate the notch. Ugh.
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.
Instructions here: https://support.apple.com/en-us/HT204012
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.
If I remember correctly, one is supposed to make it public once patched or in event of no response, no?
What is "Responsible Disclosure"?
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.
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.
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
2) (Apple) Blank root password
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.
* 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.
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 nullok
I 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
(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?
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."
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.
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?
- 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`.
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)
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://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.
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.
> "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:
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.
> 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.
> Is it a bad way? No!
OK this is where I stop feeding the troll.
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.
"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".
Password change is the only protection until it is patched.
utility; by first enabling the root user with a strong password, then disabling it with the
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.
After 8 months of living hell using their overpriced MacBook Pro, I'm moving to Surface Pro (running Xubuntu, though).
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.
"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!"
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.
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.
There is a setting to immediately destroy the key when the laptop sleeps. It might be outdated but  should give you a starting point for setting it up.
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
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.
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)  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.
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."
"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.
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.
From his Twitter account, he's not just some layman stumbling across it.
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 <firstname.lastname@example.org>
To: email@example.com, firstname.lastname@example.org,
Pete "Gymble Roulette" Cottrell <email@example.com>
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 <firstname.lastname@example.org>
Gymble has been `upgraded'.
Pyramid's new login program requires that every account have a
The remote login system works by having special, password-less
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
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
se a lonNew passger password.
se a lonNew password:ger password.
Please use a longer password.
Retype new password: <cr>
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
So then there was an entry in /etc/passwd where the ::0:0::: had been:
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
So just because I was enjoying myself so much, I once again did:
% rlogin gymble -l ""
[ 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
P.S.: First one to forward this to Pyramid is a turd.
They also respond to email@example.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.
This isn't the first extremely serious and dumb High Sierra password bug this year  , 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.
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 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.
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.
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.
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.
That said, I wouldn't visit jwz's blog at work anyway.
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
In this particular case, the ease of validation additionally works against users.
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.
> 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?
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.
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.
One would think that something as simple as a login would be deterministic.
See: https://stackoverflow.com/a/33272796 for a bit more information of what I mean.
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.
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.
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.
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.
Personally I think if you report through the proper channels and nothing is changed THEN broadcast, but not as an opener.
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.
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.
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.
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.