Just in case it is relevant for anyone here this is what our security team have established thus far:
- 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.
>if passwd is a lone asterisk, then you haven't been exploited.
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.
Bad news: I tried the exploit in my macOS Sierra installation and it didn't seem to work. However, the passwd entry on the output of your first command IS A LONE ASTERISK.
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.
This is very normal in 'nix' systems. '' indicates a locked account. (I've given up figuring out how to escape an asterisk)
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
If the OS is letting you in with a '*'in the encrypted password field, something is very very wrong.
When you do this you'll get the creationTime and passwordLastSetTime as seconds since the 'epoch' – January 1, 1970, 00:00:00 (UTC). These are numbers like 1474441704.265237 which aren't very easy for a human to read :-)
To convert this into a human-readable date and time, open a terminal and do this:
One of my Macs is showing a root password change date of Nov 10th 2017. I can't explain that, so I'm reinstalling now. It did have sshd enabled and remotely accessible, though I thought root login was prohibited.
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.
OK, I guess when doing OP's root trick, the root user gets activated/created, and that's that's when the PW gets set to empty. I guess that's where my passwordLastSetTime comes from.
Oh wow. Is there any other explanation for this other than this having been exploited in the wild for almost three weeks? Or maybe someone just tried to log in over SSH to exploit some other weakness (something like predictable SSH passwords on jailbroken iOS devices), and happened to create the root user on your machine?
Did you also have sshd running, and do you know what kind of network you were using at the time?
Wait, isn't the point of having root you can erase your traces? Are these logs immutable, even to root? That sounds pretty next level.. and how do I trust the tools?
As far as I know, possibility of root = root = pwn, game over, time to format.
System Integrity Protection (SIP)[1] does prevent even the root user from modifying some system files[2]. It seems possible, at least in principle, to protect system logs from modification by user root. In practice, I think most system logs are stored in /var, and that part of the directory tree does not appear to be protected by SIP (but I hope I'm wrong!)
[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.
You can't load unsigned kexts anymore, due to that same SIP. It's a pain in the gonads when hacking your own kexts. I had forgotten about this, but it does indeed allow for a system that leaves an audit trail which cannot be hidden, even by root.
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.
I see a lot of comments here wondering why Apple seems to not care about software quality anymore. I don’t know if that’s true, but there’s a perfectly obvious answer: They don’t have to.
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.
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.
It's also display quality. If you're doing design work you can use a MacBook pro and be pretty sure that the color is accurate with no calibration. If you switch platforms you have to sort out the enterprise and gaming displays, which have totally different selling points (price and responsiveness, respectively). Getting a good display and accurate color on a Windows machine requires a lot more knowledge and effort. This is definitely less true since Apple abandoned their display line (one more bit of evidence that Apple doesn't care about the professionals that established their brand anymore).
Those Apple mirrors (err, thunderbolt displays) were definitely not close to color accurate. The macbooks are okay I guess?
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.
I own my own calibrator. I calibrate every monitor I use for Video. I have never seen a accurate monitor in the wild yet. The funny thing is I can get a horrible cheap monitor to be calibrated in a dark room and it is better than anything not calibrated.
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/
My partner does photography and has a Datacolor Spyder 4, which I of course borrow to calibrate all my monitors. At work I have a 30" IPS and next to it vertically an old 24" tn-film. After calibration, they are very close color-wise and they both are very enjoyable for reading code. The tn panel has worse viewing angles and about ~80% of sRGB, but after calibration it is absolutely much nicer even for development.
I calibrate my monitors with DisplayCAL[0] on Linux.
There should be one calibrator in every office, the difference it makes is enormous.
I'm not sure I agree with this. Or at least it goes too far to say that it's a mental lock in.
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.
> 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.
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.
> Thankfully we are getting there with "Windows Subsystem for Linux."
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.
> Also most people mentally think that somehow Apple is better for design but the software runs just as well on Windows.
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.
While you don't believe you are locked in, I don't believe that you as a programmer "power user" are the majority that Apple cares about.
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.
Without directly disagreeing with your post, I think there is a slight OS lock-in, in the fact that the MS alternative is a horrible piece of burning wreckage. Anybody that had to put up with the autoupdate experience in Windows 10 (oh, you were doing something important? Never mind, I'll just hog your network in random intervals for like an hour without you having a way to stop me and then I'll take 2 hours to apply the patches before the reboot), can understand that Apple was playing without serious competition for some years now.
There are many lock-ins, first there is iMessage, second there are some apps that still work only on Mac OS X I don't remember the name of the software but I once was sent a design file and was only able to open it on a Mac OS X software (there was a windows alternative but it didn't allow me to edit the file as needed). Another example is XCode, you need a Mac to properly create iPhone apps. For programming, there are also issues with symbolic links on Windows.
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.
iMessages is the lock-in. It is the primary reason why I switched to the iPhone.
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.
iMessage is a huge lock-in for non-technical users. They are just obsessed with it on iOS. You can find tons of forum posts with people throwing fits that XYZ Android phone doesn't have iMessage.
I used WhatsApp, Telegram, Messenger and Skype on my phone in the past two hours. Obviously no iMessage because I'm on Android. Maybe my friends with an iPhone use only iMessage between them (I doubt it) but the network effect is all for WhatsApp and Messenger where I live (Italy). Probably nobody switches to Apple because of iMessage here, but it could be a lock in if you really use it.
I'm not sure the correlation is technical proficiency by itself, I think it's based upon a critical mass of your social circles using iMessage or not using iMessage. If you choose to, you can probably make a correlation between "technical savviness" and a user's choice between Android and Apple, but I don't think that is a deciding factor in who uses iMessage.
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?
Mac is also easier to use for non technical users. I bought my mom a Mac and she can plays with the "system preferences." Good luck showing her Control Panel on windows.
The Apple Store is a huge deal for non-technical users as well.
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?
The biggest thing I lost in a similar switch was ANY old conversation with somebody who was an iMessage user. Where they reply to a conversation and think they are just texting you, but actually they are sending iMessages that you just aren’t receiving. Especially on, for example, family group texts, people just find the old conversation and continue it from the previous year or whatever. Lots of times when I was on windows phone or had iMessage switched off, I’d only get the parts of the conversation coming from non-iMessage users. A good example is random family members who use android texting me reactions to an original text or picture I didn’t get. It’s really dumb. Maybe there’s something I could have done about it in my own settings, but instead I ended up switching back to iPhone recently. Not just for that reason but it sure was nice to get messages properly again. But also more sensitive stuff like somebody sharing pictures of items related to planning a funeral.
Thanks, that is really interesting. I hadn’t read that page, but I had disabled iMessage from the phone settings, which is how I first noticed the issue. Maybe I was not thorough enough, (it says to disable FaceTime too, which I didn’t/don’t want to disable) because it never corrected itself.
I have also heard that if you complain and drill down enough in the support funnel on this issue that eventually the best answer will be "change your phone number". Now that's what you call lock in.
I second this. The only feature that I can immediately think of that locks me in the mac eco-system is the convenience of airdropping files with my wife. Apart from this, with most of my stuff on the cloud, there won't even be a migration process if I decide to switch to Windows.
I have a lot of software I bought on the App Stores for Mac and iOS, hundreds, maybe even over a thousand dollars' worth. If I switch platforms, I can't use that software any more.
While your theory is interesting, if deeply cynical, the thing I find most interesting is that it's the top comment on an 800+ comment discussion when it was less than a minute old. Do new comments start at the top? I've never noticed that before.
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.
The higher the poster's karma, the higher her comment will be upon posting. This user has almost 6k karma, so it can rise high. Once the comment is at the top for a minute or so, it can stay there if enough people keep upvoting it.
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.
I have also seen new comments spring to the top of the conversation, but always assumed they were selected randomly, as some of them were from posters who were fairly new or had a low karma count.
I think new comments do get a slight boost initially. But I also think people are venting their frustrations at the very noticeable decline in software quality from Apple over the last 3 years.
I really hope that's not true and this is just some extended blip.
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.
Maybe. But this particular bug happened precisely because Apple has changed _something_ in macOS. Also this something was probably quite profound since it has impacted a part of software that, at least from the outside, haven't changed much since a long time.
A lot of macOS users would actually prefer Apple to do less with it than what they are currently doing.
> this particular bug happened precisely because Apple has changed _something_ in macOS
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 think you are right, but it's still been in the wild for several months, despite that Apple just realized a comment claiming they discovered the problem yesterday.
I kind of love how you frame it as "everyone who has switched has switched" as if the job is done. As if there would be no market to capture. Which isn't true. And doesn't even consider the reality that there are young computer buyers who they need to capture because existing users don't buy new machines or won't last in the long run (people die).
There is always more market to capture, but the cost of capturing those few additional users might not be worth it (to Apple, currently). And new users don’t look to the quality of the OS to pick their platforms, they look to existing user bases. And Apple now has a sizable existing user base, especially if you also count iPhones.
I was going to comment the same thing. Most people are always open to switching if the evidence is there to support a better workflow or experience. The realm of endless marketing to all the demographics will never stop.
> not improving macOS won’t make anyone upset enough to switch back
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.
Nobody cares about what developers like in their computers, developers will go wherever the users are. And Apple now has a sizable chunk of computer users and an even larger chunk of smartphone users.
There's a big difference between a developer grudgingly keeping a cheap headless mini-computer under a stack of papers somewhere that gets used only as needed, and a developer using your system as their "home base" and buying into your entire ecosystem.
This only holds true if you consider lock-in IMO, e.g. you need a mac to develop iOS or mac apps, or you need a windows machine to develop windows apps.
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).
I think it's more that desktop machines make them a fraction of the money that their iOS devices do. Development goes towards the profit centre.
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.
Whether or not most potential apple users have already switched, security is surely vital to keeping their customers with them.
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.
Not to excuse the bug, but I think it has more to do with the annual upgrade cycle for the iPhone. Everything else Apple does has to tie into this, which is a pretty tight cycle for an OS with new "regular" OS features, plus the integrations with iOS.
They can't afford to wait 2 years (or whatever) to update the phones, and Mac OS gets pulled along for the ride.
Their QA department has been in a downward spiral since 2014. I would love to name some people who were doing a fantastic job running the place until then, but I'll spare the embarrassment. This really isn't about some mega company not caring as much as one of their cornerstone departments being unable to function effectively.
I really don't think that to be the case. Quality on OS X was a priority in its own right and fundamental to everything at Apple, not just a by-product of a strategy to get people to move from Windows.
Of course all that changed when its only priority became to shift more iPhones, and everything became secondary to that.
Some years ago, I was hearing about people switching from PCs to Macs all the time. Later, not so much, but macOS was still getting praise. Maybe Apple looked at the conversion numbers at that time and decided that the cost of keeping up the quality of macOS wasn’t worth the few PC converts they were still getting, and they figured that not enough people would switch back to PCs since the iOS system lock-in effects, etc. would present enough of a barrier.
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.
This goes against basically every corporate strategy ever, which is to always increase growth.
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.
Old school corps - DEC, HP, even IBM to an extent - weren't about increasing growth irrespective of consequences.
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?"
Increase growth, yes, but not at any cost. My point is that Apple may have decided that at this time they don’t need the growth as much as they need internal developers to work on other things than macOS.
While I think there's a chance you might be right, I don't think it's logical in the long run. I think changes in perception like this are accumulated over time and will in the end hurt the product.
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.
>It is only now starting to improve, with gigantic efforts from Microsofts side.
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.
Maybe not quality wise in all areas (I agree with you there) but at least in giving a professional and modern impression compared to let's say Windows XP/7. Maybe operating systems are declining in quality in general, even though organizations sometimes try to improve them. I guess legacy plays a big role here.
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.
Nah. At this rate people will simply abandon the ship sooner or later. There's definitely some deterioration going on instead of only a cynical strategy shift.
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.
Surely they should care about the security of their _own_ developers, who surely program in macOS. I believe we are being too harsh on Apple unnecessarily.
> 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.
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.
Saying that you only care about existing users via lockin and don't expect switchers is a sure path to doom in the long run. Surely that cannot really be it.
Incompetence seems to be a more likely fit here than that.
There are probably a lot of people like me on HN who _need_ a unix box to do their work, and the various Macs are still far and away the best general purpose unix boxes available (best chassis, best peripheral compatibility, best (o|O)ffice software compatibility).
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.
Dell XPS 15 on Linux is pretty glorious you guys. My 2011 version is still kicking amazingly well with a 1TB SSD, and the newer models are way sleek. I also have a 2013 Sony vaio with dual boot linix/windows. Haven't booted to windows for anything but updating it for years.
… as a _workaround_ for an administrator account-related bug.
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 … :(
From one bad upgrade that cost me a bunch of productivity - believe it was Lion - as well as observing the struggles of colleagues, these days always wait 6 months at least before upgrading OSX
I basically only update when (a beta of) Xcode tells me it won't run on my current version. Usually that's the point when either all bugs have been fixed or they will not be fixed before the new version.
Yea, Xcode is so annoying with this. What magical features does it use under the hood to not allow basic functionality and iOS support that seems completely unrelated to the macOS version? I have zero incentive to update macOS except Xcode telling me it needs a new version that only runs on the new one.
Xcode still needs to compile for macOS of course. It's not just for iOS development. If you want to compile for the next version of macOS you need to be on the next version.
But why? You don't need to be running the latest version of the Linux kernel to compile binaries for it. You don't need to run Windows 10 to compile programs for it. Why does Apple's compiler need to run on the same system its build target is for?
Probably also to run the actual application. But a Linux kernel is a different beast than macOS versions. macOS versions are pretty stale in terms of features to change abruptly with a new release.
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.
Apple's support forums aren't a place where Apple provides their users with support, they're where Apple users seek support from other Apple users, mostly unhelpful and often inaccurate support.
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.
Yeah, I miss the days back at the start of the decade when I would brim with delight over an email notification that a senior engineer / moderator had chimed-in on my thread on the Apple dev forums.
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...
I ran into a bug with High Sierra, posted in the user forums and was contacted by a friendly Apple Engineer a day later. So they do read them, but apparently not close enough.
I could see how someone would dismiss a posting like that with an "this cannot possibly be true" shrug.
I've been a developer for a long time. I understand bugs happen, even bugs with terrible consequences. A lot of bugs seem understandable, like I can see the chain of ifs/thens required to end up at some hilarious broken state.
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?
Seems to be something related to a backwards-compatibility code path for upgraded systems. According to multiple posts on this thread it only affects systems upgraded to High Sierra, not fresh installs. See https://news.ycombinator.com/item?id=15802622 for example.
Adding extra layers for compatibility complicates testing and debugging. With this many eyes on it hopefully someone will be able to deduce exactly what's going on.
Note that I had to try twice for this to "work" - maybe try again. Incredible.
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.
You have some pretty high standards. Being imperfect doesn't automatically make it better than the alternative of not doing it.
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.
Apparently it is not just enabling root, but setting the password the first time you do it (in other words, the blank value has nothing to do with it). Then the subsequent times it'll use the pw you set the first time.
I'm having a hard time understanding how this could happen too.
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.
Blank password is not necessary. Any password provided on initial attempt WILL BECOME the root password. Blank is being circulated simply because that's what was discovered first.
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.
So by my logic - if you tried this exploit and it failed the first time, then worked the second time: No one else has tried it before you. Otherwise it would either have worked the first time (if you guessed the same pass) or not worked at all (if the first time it was tried a different pass was used).
Well, I suppose if someone had exploited your system with this, they could probably install some remote access tool, and then disable the root account and unset the password, and remove all evidence they were there.
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.
Not only enabled it but actually set an empty-string password. Usually the stored hash for a disabled account is not in the hash space, so it was either overwritten, or root account password was actually empty string out of the factory. That and the enabling of the account both point to debug code accidentally left in (or intentional backdoor by the disgruntled).
To some up, when you try to log in with a disabled account, MacOS "promotes" the account but uses the _password provided by the user trying to log in_ instead of the password on file (in this case, an asterisk indicating the account is disabled). Once that is done, you can log in with that account.
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.
I see your point, but it still seems kind of wacky to me. They should validate that the password is correct, then promote the account. Taking the password provided in the authentication dialog just seems like a bad idea.
Perhaps the root issue here is forgetting that the asterisk indicates that the account is disabled and shouldn't be a candidate for promotion.
Like an illusionist hiding the truth, this bug too will have a logical explanation that will leave us in wonder for as long as we aren't told how it happened.
OSX user management is weird. At least on prev versions, they don't show a root account in the Users & Groups ui.
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.
I hope a judge will order Apple to make all source code of macOS to be readable by everyone. This does not necessarily mean open source: you will not be allowed to modify and re-release it.
It's worse than that. You're enabling the root user EVERY time you use this vulnerability. Even if you disable the root user in Directory Utility, logging in with root and no password will re-enable the root user.
And you might want to disable the root account again with `dsenableroot -d` as well, so that the root account stays disabled after the vulnerability is patched.
Unlike doing this through the GUI, this seems to retain the root password and prevent this vuln from re-occuring.
Bizarrely though, you can still use the root user (with the password that you set) to login to the Directory Utility even while it is supposed to be disabled... This behaviour seems super weird.
Yeah I've noticed this myself - I'm on the fence as to whether this is actually disabling the account or simply creating that impression (it does show as disabled in Directory Utility after you perform this command).
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.
As far as I can tell, "dsenableroot -d" seems to have no useful effect. After having "* Successfully disabled root user." with it, I can still log in to the root account with the password I set, both at the command line with "login" and from a remote machine via screen sharing.
To be flippant, I might say HN discussions seem to QA using Apple methods.
I haven't upgraded to High Sierra yet and this doesn't happen on my install atm. Does adding a password to the root user stop this vulnerability? If it does then that seems way better than disabling the account until this is fixed.
Having tested this by both approaches (disabling through GUI & shell), the above (through shell) seems to prevent this from re-occurring when you attempt to perform this bogus login again. Disabling the account via the GUI causes the failure to re-occur.
It is disabled by default[1] (meaning you can't login as it), this vulnerability appears to enable the root user without setting a password. If the root user has already been enabled it doesn't work.
Anyone who does this should probably set a password for now and then disable the root user account once it has been patched.
Can this be used remotely? Edit: Yes, after turning on Remote Management on my second mac I was able to log into it using Remote Desktop, account root and no pw.
It only works after getting physical access once.
Yes, I just had a coworker test it after I enabled remote management and they used screensharing.app. I didn't even get notified a user remoted in.. never used screen share, that seems awful. Had to look over and ask if he was in.
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.
It only works after getting physical access once to enable the root user by gibing any password UI the root user with no password (which will enable the local root account, which is also why it fails the first time around)
I tested this by logging in as root at a preference pane then attempting to connect via ssh and screen sharing (both enabled) using root with no password. It did not work.
Not sure if you'd get different results after logging in as root at the login screen...
"Perhaps nobody noticed two weeks ago when the root login vulnerability in macOS High Sierra was shared as a helpful tip on Apple’s own Developer forums. https://forums.developer.apple.com/thread/79235"
I wonder what is going on with software quality and testing at Apple. It feels like recently there have been quite a few issues like this (the FileVault password bug, numerous issues with iOS 11, the issue that totally broke iOS Safari a couple of years ago) which should have been fairly easily caught, especially given the limited range of devices their software runs on.
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.
macOS and iOS updates at Apple are now inextricably tied to new iPhone releases. There is a strict yearly deadline that the teams sprint toward, a timeline imposed by marketing rather than readiness. This affects prioritization of which features are pursued, where they lie in the stack, and how polished they get.
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.
it is also that they pursue features just for the sake of it. things get moved arund in the iPad from release to release for no good reason, often going backwards in usability. every release i have to relearn simple things like how to manage the screen brightness. i really wonder what they are thinking internally other than “we need to shake things up to make it appear we’re doing something with stale products”.
It seems phones and tablets have reached the stage where laptops were maybe 15 years ago. All the major features are done and innovation is pretty much over. So they have to make a lot of cosmetic changes that look like activity.
Haven't deadlines at Apple always been driven by marketing? I'm looking for a source but I remember a story where the product director for iPod was told by steve jobs "make it simple, fast, beautiful, and have it done by Christmas."
That's sure to send shivers down the spine of anyone reading it here but, to be fair to jobs, he managed to get exactly what he wanted on that occasion.
Asking for stuff requires no talent, vision, discipline or effort whatsoever. Pretty much anyone can do it. If you don't actually deliver, you don't actually matter.
Take this for the anecdata that it is. I interviewed at Apple, referred by old Microsoft friends that worked there. As I was trying to get a feel for things before the interview, I asked about the software testing. I was told, "don't expect what you're used to at Microsoft". The reference there is from when Microsoft often had more testers on a team than devs (ah, the good ol' days). The summary of what I was told by friends, and the questions I asked during the interview, is that testers at Apple aren't the testers that Microsoft used to have. Microsoft had testers working in MS Research, researching ways to better test software. Apple, from the impressions I got, is doing good to have testers than can write "hello, world". This was from the app side of things, not OS; I don't know if it's any different on the OS side.
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.
As a Tester myself, I cannot understand why this is not covered by either unit tests or behavioral tests.
Clicking dialog buttons in rapid succession is what we (should) do once in a while. Especially in core functionalities such as the login screen.
It's one of the first screens you see as a tester. And you have default usernames, be it enabled or not.
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.
I got my friends Apple Watch stuck last week just by looking at it's features. IIRC it got stuck while using the "flashlight". It suddenly froze, and it took me a while to reboot it (it got stuck once more while rebooting).
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.
This bug isn't caused by rapid succession or whatever, it's more of a generic end to end test. In this case someone would have had to write an exact scenario that opens a settings page, unlocks it, types in 'root', no password, presses login and it should not work.
Rapid succession button clicking usually combines many different tests:
- 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.
> But since I don't work there, I have no good inside info
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?
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 believe there was an article about how Apple was finding it extremely difficult to hire ML experts because of the secrecy they require. In order to mitigate that they mad an exception for their ML/AI engineers allowing them to publish papers to external journals and present at conferences.
Presumably this is why their software is increasingly shoddy. But I wonder whether it's a direct effect of poor internal communications, or an indirect effect where the ludicrous secrecy has driven away any half-decent programmers.
Unrelated to Mac OS but I used to wonder all the time why iTunes connect was so shoddy. I got my answer when I learned Apple had outsourced a ton of backend work including iTunes Connect, App Store backend to Infosys in India.
It's the last release they made any significant updates to the BSD userland. I'd mark this as the release they ceased serious investment into the operating system itself. After this point it's almost nothing of note. If you look at the dates of the various tools etc., this release is when they were last updated. Many are now getting on for being a decade out of date. The only major change has been the switch to llvm, and they made that horribly painful.
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.
There's been releases ever since that improve battery life, or, keep it the same while doing more; background apps get throttled, graphics rendering has been optimized using Metal, and in future Mac devices, I'm sure they'll put their mobile processors in it to handle background tasks - it might even be strong enough to power the next generation of Macbook Air.
Mavericks was a big one for extending battery life. It came quite a bit after Snow LeopRd and introduced timer coalescing which significantly improved battery life across the board for all MacBooks:
I should have specified I meant 10.6.8 I ran it on my main computer until 10.9.2 because of the problems I had experienced with Lion and Mountain Lion on other computers.
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.
Your right but I think the biggest Issue is Apple does much more frequent releases now than when they were doing Snow Leopard. So more iteration hence more stable OS.
I have been in the apple ecosystem for about 10 years. For a company that has been priding itself on end user security, the bugs that have been creeping their way into the OS are just... disappointing. What is the point of paying a premium for a well polished hardware/software bundle if the OS is malfunctioning in a non trivial manner. Design? Right now when I use my calculator app on my iPhone and do 2+2+2 I get 24. That's a pretty awful design. Actually, it's a lie.
The loss of people like Avie Tevanian and Bertrand Serlet took its toll.
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.
Dominic Giampaolo of BeOS/BeFS fame. He now works on APFS at Apple. Their work is really - impressive APFS was announced in June 2016 and rolled out on iOS devices in March 2017. Given that the APFS roll-out was relatively uneventful and how they tested it [1], it seems that they can still do low-level engineering and proper testing.
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.
Whilst APFS is an improvement and I fondly remember using BeOS back in the day, I am not sure APFS is that impressive feature-wise compared to NTFS. It's still miles behind NTFS, which is now ancient.
In the case of Facebook, all the “household named” developers do nothing to improve the quality of their output, be it their user-facing software or developer-facing open source.
Subjectively it feels like Apple bugs have become larger and more prevalent, over the last few years. That and IMO clean OSX/iOS installs don't quite feel as polished as they used to. (I stopped using Apple products, except for a MBP, for a few years and recently started using them again, and the MBP still runs 10.10 for precisely this reason) The last solid OSX release was Snow Leopard
They've added features over the years without removing or polishing them; there's Launchpad which was added in a period where OSX seemed to lean towards becoming touch-friendly, but it didn't replace any existing feature (iirc) and just feels off. Might just be me though. Notification center? Don't use it.
And seeing this I am wondering why people still trust closed-source software. My long term dream is using 100% free software on a HW with minimum binary blobs.
There’s no need to do this yourself to verify it. Doing so creates a “root” account that others may be able to take advantage of if you don’t disable it.
I really wish it had been. I had no idea it was something that A) left droppings, and B) actually enables direct login from boot with root/no pw once you've done it.
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.
Wouldn't it make sense to propose this combined diagnostic and workaround:
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.
This bug exists regardless of user reproducing it or not. If there is anything good, reproducing it actually brings awareness to the user (make them change the password maybe). Hacker will "enable" the root user anyway.
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.
Even if you're on a dedicated machine, this vulnerability enables a local user to bypass the authentication prompt on things like System Preferences or other auth checks.
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:
No, root is root and has always been there. It's the super user account and cannot be removed, I think, from any modern unix like os (well, you can rename it to whatever you want in linux but UID 0 will always be there). The difference might be that if you do log in for the first time you will have lots of stuff on /private/var/root (talking from memory but it was something like that in OSX) and lots of preferences will be set, maybe even a /Users/root folder
I hope that the SSH server, which is disabled by default, will also handle root login in a sensible way, but given the size of the f* up, I'm not so sure.
Root can absolutely be disabled. OS X normally runs rootless. This vulnerability actually both gives access AND enables that disabled root account in one action. From that point on, root is active with no password regardless of how you authenticate whereas the initial issue is only on password GUI screens.
No, by default, root has an undefined password and cannot log in from a terminal or ssh, but that doesn't mean it doesnt exist. If you make a SSH key for the root user and place it on his folder you wont need to set up a password and will be able to login just fine as UID 0. If you do 'sudo -s' as an administrator and then run 'passwd' to set the root passwd, you're not magically creating a root account, you're only changing the settings for that user, but it was already there
> Once you enable root access - by 'testing' this - others can remotely & silently access the system as root.
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...
I don't have access to a vulnerable machine -- just going by comments in the other HN thread.
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.
Yeah that was my thought initially too but there may be invisible ways to leverage an existing root user that we're not aware of. After all, this bug exists...
The issue is that the bug leaves a password-less root account available through other means as well. Once you try to reproduce the bug, an attacker could potentially do a remote root login without password.
As such, it's very dangerous for people to try to verify and should be strongly discouraged.
Apparently, High Sierra has a 'feature' that updates hashes to a new format on login, and consequently publishes a hash where there was none before. Which pretty much disables the 'no hash, no login' policies. Ooops. Donno if that's unique to the GUI, or if a simple 'sudo su -' would also trigger, as I don't own a mac.
If you have remote login enabled does root/no password not work already because of the bug? It apparently does from the login screen if you have username/password mode on, so I wouldn't be surprised if it worked over remote login by default.
This vulnerability lets users activate the root user without using their password.
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.
Care to explain the comment about Apple? I can think of a few companies (DJI, for example) that try to screw over security researchers, but big IT companies usually don't go on the list.
Most of the big companies will take their sweet time to fix something if it suits them. Not always, but sometimes they just won't feel like getting around to it, and they know that as a "responsible" researcher, you will keep your mouth shut about it. I'm talking like a year. I've seen this with the "researcher friendly" companies.
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.
I have heard of many incidents like this from various companies, but not Apple that I know of.
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.
90 days, and Apple in fact are a noteworthy example. They have repeatedly missed the deadline and had full disclosure by GPZ, with widespread flaws, complete with exploit code.
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.
Updated. I was unable to reproduce on another machine as a standard user, but it appears to be related to it being a fresh install of High Sierra, not an upgraded install with old disabled root user entries.
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.
But throwing it on twitter doesn't stop you from using the DMCA, and having the DMCA used against you doesn't stop you from posting it on Twitter as counter-measure (which might make the company retract the use of DMCA to avoid publicity about suing "messengers"). If you're afraid of DMCA, keep your mouth shut and stay away from the US.
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.
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.
Your comment suggests that it is related to users with older, pre-High Sierra directory entries. That is, upgraded rather than freshly installed machines that leave older, pre-ShadowHashData intact. Is this correct?
Ah, yes, but that is what I meant in suggesting that it was related to a High Sierra upgrade.
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)...
Odd. No reasonable amount of attempts would reproduce it on my wife's few-weeks-old work machine, where the root user was visibly disabled.
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).
Apple released the following statement regarding this 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."
That might not be enough. There's a tweet claiming it isn't limited to the root account, and applies to other similar Apple-default accounts on the system, such as the _applepay user account:
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.
With user switching enabled as a username + password combo, I was able to login to the root account from the login screen with no password on 10.13.1. It's not just a UI bug, it's a full on authentication bypass.
Anyone else think it was a bad idea to disclose this so publicly over Twitter? I thought that the usual practice was to let the development team know first.
Letting the development team know first is nice to the development team, but not so nice to the users (especially not-nice if there's a workaround, which there is in this case.)
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.
Time and time again we have been shown that the way to a company's heart is through it's PR department. This is a dev complaining to Apple like a lunchgoer would complain to Mc D's about a bad burger. Expect more of it.
Seems to go for almost all issues regarding Apple. I've been reporting that calculator bug since iOS 9, with updates for several betas that it's still there. Two years later someone with a significant following on Twitter writes about it, gets enough retweets and Apple finally fixes something so miniscule.
its such a braindead problem that its plausible that the person who disclosed it over twitter didn't know what responsible disclosure is.
Usually exploits are hard to exploit meaning that those who find them likely know of responsible disclosure. In this case though anyone who has ever installed Linux is capable of stumbling upon this.
If the vulnerability required scripting or special tools to be written, yes, it should be disclosed in private. But anyone can happen upon this, and I imagine the reaction for most is "Huh! That's funny! My friends and followers would get a kick out of this!" He was just being social about a problem he found with his new computer, which is something most people would do upon finding a something you can laugh about.
Ah, there's no ShadowHashData or KerberosKeys nodes. Presumably the code creating that plist is not aware that later on it's going to be accessed thru layers of other software and end up as a usable login. To quote Shrek:
"Software is like an onion".
Looks like changing root’s password blocks the exploit but if you disable the root user, it re-enables the exploit.
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.
Fortunately, I'm OK. The latest OS upgrade failed to install and bricked my computer so that no one could log in, let alone root. I was able to restore it using Time Machine but I don't think I'll go through that exercise again for a while yet.
Apple along with a decline in product utility, reliability and quality, their software has been getting buggier every year post-Jobs. The QA people should be fired and replaced with a team whom insists on perfection. Otherwise, these embarrassing incidents will repeat, errode their brand and encourage customers to seek other platforms.
Apple has a serious software quality problem. Last night I was helping a friend with their computer. Safari couldn't even render apples website correctly. Nor could Safari connect to any site with HTTPS. Installed FireFox and HTTPS sites worked and apples's site renders. But the submit button on their developer site is broken[1]. Mail on my Mom's fully updated laptop crashes every time it's opened. Once I reported a bug in ptrace like 4 years ago and no response yet. Also the archive utility fails often to extract tar files that the tar command has no problem extracting at all. Quicktime can't play most videos, etc, etc. And now shipping an operating system with a root account with no password by default.
Come on Apple you have a quarter trillion dollars in the bank why don't you spend some on improving your software.
> Safari couldn't even render apples website correctly. Nor could Safari connect to any site with HTTPS.
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.
> 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.
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 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.
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?).
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.
Paid $3,000 for an iMac. Can't even watch any video or have the kids FaceTime their grandparents because video freezes constantly. Rebooting fixes it...for 2 minutes.
Its not just Apple though. Microsoft had the similar problems in the past. Edge did not support silverlight causing people to move to other browser. It was strange to see Microsoft's own software not supported by Microsoft.
> Its not just Apple though. Microsoft had the similar problems in the past. Edge did not support silverlight causing people to move to other browser. It was strange to see Microsoft's own software not supported by Microsoft.
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 having significantly less problems with Windows then MacOS.
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.
Windows 7 has been on the market since 2009 while High Sierra has been out since June of this year. I feel like we're not comparing apples to apples here.. I'm sure both companies are releasing security fixes consistently and Win7 has clearly had more of them in 8 years.
EdgeHTML sure has advanced a lot from Trident, and I appreciate their openness with Platform status, but Edge as a browser is still a joke IMO.
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.
My computer automatically downloaded high sierra without me wanting it to. Whether I was tricked into clicking something I don’t know. And then I heard about the disk utility password bug and decided I should wait a while before installing this OS— it seems as though Apple wants me to do their QA for them. And now I hear about this. And I see that dumb ugly notch on the iPhone X (seriously who approved that design decision?). And the 2015 MacBook Pro is more pro than the 2016 model? Apple is officially a tribute band, riding on the fame of its previous self. And I say this as someone who owns a MacBook Pro, MacBook Air, iPad Pro, iPhone, and Apple Watch. This comes from a place of love. You’re trendy now, but don’t you forget that trendy people will leave you for the next shiny thing in an instant. Please fire everyone who is just there to milk the profits, actually put some focus back into QA, and remember who your base was.
Have you used an iPhone X? The notch actually makes a lot of sense once you've used the gestures associated with it, same with how it integrates into apps. I'll agree that they've made a lot of mistakes in their product lines recently but the iPhone X was not one of them.
Well, sparing software. I've had intermittent phantom screen input using the latest betas on the X, making it infuriatingly unusable at times.
I get that you can swipe down from the left or the right. But obscuring a chunk of the screen is not something to aspire to. The notch is clearly a compromise to make room for hardware. They should have found a way to fit the hardware such that it doesn’t cutaway the screen.
cutting away a portion of the screen is not an upgrade. it's a sacrifice.
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.
The iPhone X has a much better screen-to-size ration than the iPhone 7/8. Therefore, it is an "upgrade". The notch would only be a "downgrade" if there was already a phone (and more specifically an iPhone) on the market that had an edgeless display without a notch. But there isn't one, so I'm not sure I see your point.
A notch breaking the continuity on the screen is a downgrade when, prior to, the screens had nothing protruding into them and blocking out a chunk of them.
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.
Sure, it's less immersive than if there wasn't a notch.
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.
Doesn't help to disable it, you have to change the password.
UPDATE: if you disable the account after setting a password, a login without a password is possible again ..
AWS ReInvent 2017 is going right now in Las Vegas, the number of attendees is about 40000, and I'm wondering how many laptops can be attacked using this technique. The `root` user stays in the system, so one just need to create it and open SSH quickly, and later they can do whatever they please.
This reminds me of the jailbreaking scene a few years back. I was at an event centered around jailbreaking, and you were able to ssh into 80% of users iOS devices by using the default root password, alpine.
For those who can't make it happen, it requires that the root account is disabled, which is the default. If you already enabled the root account for some other reason (which apparently I had on one of my Macs, although I don't know why) then that prevents it from working.
It seems like the best mitigation for the moment might be to enable the root user and set a password for it.
This is comical at this point. I have no idea how such vulnerable software makes it to production.
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.
> and branding itself as the leaders of quality, stability
> and so on
The days of Mac vs. PC guy are long over. Apple usualy compares their products only to their other products now (best iPhone ever, not best smartphone ever, etc.)
Alas if you look around such vulnerable software makes it to production now and again, there is nothing new. Hindsight is 20/20.
i am not saying something like this will always happen, but it can happen. No matter what kind of testing and QA you employ (and i bet it's gigantic in Apples case), not having critical bugs in something as complex as an OS every few years is kind of impossible.
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.
FWIW, as a mostly Android user, the latest Oreo update was pretty terrible as well. Its all about adding new "features" just for new features sake isnt it.
In my opinion they don't "owe" anyone that obligation, unless it's a contractual obligation associated with using a Mac. But just because it's not owed to anyone, doesn't mean there isn't a nicer way to handle it just to be nice.
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.
Twitter's also the goto for banning trans people from military service, attacking freedom of the press, threatening to declare nuclear war, and all kinds of other things too.
There have been some really horrible bugs at Apple lately. I'm still waiting on them to patch the camera bug in iOS 11 where if you try to use the camera in a web app pinned to the home screen, it shows the camera UI on a black screen. This dates back to June. How can it be that hard to patch such a glaring and embarrassing problem?
How many people are using the camera in pinned web apps? What's the app you use? I'd imagine most camera-related functions are already best served by native apps.
Does that make it OK? I mean, something as important to the web as getUserMedia is broken on websites only if you pin it to the home screen. Forcing people into Apple's walled garden doesn't seem like an acceptable excuse.
Wow. This is fun. I remember my Windows98 had the same feature. You just use Administrator with empty password and you're in. Apple is finally catching up.
AFAIK, its not really a security bug. Windows 98 didn't really have any concept of user security. With the default install you could always cancel out of the login dialog and use the guest account. Every account was an 'administrator'. The user name / pwd was mainly to store the OS customization settings like UI colors and such.
> 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.
Exactly early versions of Windows XP had this: They removed the Administrator user from their graphical login splash but when booted in rescue mode ("Safe mode") you could just type in "Administrator" with no password and were in. On Win98, you could just cancel the login.
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.
What's going on with Apple's QA team ? Here's another serious bug that I came across:
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.
> 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?
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.
Standalone iMac here - the 'Join' button is disabled. So is this vulnerability only for Macs on a network?
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?
I'm sure many of us can often see how some kinds of bugs managed to slip through testing/QA, but this is crazy to me given it works on the login screen if it's happening for everyone on whatever version: is "user cannot log in as root when root account is disabled" not a test case? That seems.. insane?
What does this say about the state of iOS security? I don’t know how to hope that my phone isn’t 0wned already. I’m not saying this from my high horse - more as a disappointed user who invested a lot of money in my Apple phone.
Confirmed that root with no password unlocks the preferences pane. But, changing the require password after screen saver setting doesn't take effect. So, it seems to be a bug in the UI not an actual vulnerability.
edit: I stand corrected. The 'require password' setting under Security Preferences didn't change, but other settings do. Yikes
Went to the next Apple store. Tried it out. It works. Can't believe it. Thousands of Macs are vulnerable. I'm wondering how fast all of these devices will be patched. Even if there is an update next week: How many devices won't get updated for quite some time. Unbelievable.
I can't reproduce this on a clean 10.13.1 (17B48) system, either at the login window or an authentication dialog.
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.
It requires the attacker to be able to type a few characters into a logged in session. If the session is not an administrative one, it's not fair to say all bets were off.
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.
I have not been able to trigger this with ssh, but certainly have been able to with Screen Sharing, even after explicitly re-disabling the root account.
The 'attacker' could be someone like your 12 year old son or an employee, who already has access to the computer but not necessarily everything on it at all times.
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.
If they have access to the account that is being used normally, they can modify the (user-accessible) settings to trick the user into running malicious code and giving them access (or causing trouble even without access to the root account).
I know the theory, but practically there's a huge difference between that type of physical access and "the victim left the room to go to the bathroom for 2 minutes" type of physical access
A quick mitigation workaround: If you follow the steps here https://support.apple.com/en-us/HT204012 to disable the root account until the point where you open and authenticate the Directory Utility, in the Edit menu there's a "Change Root Password" option.
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.
All too easily. There's so much to keep track of in modern systems engineering. We should all have a healthy dose of awareness that we could be/create that weakest link even on our best days.
It seems to activate the root user with an empty password if you try, as an admin user, to use "root"/"" as credentials in a System Preferences authentication prompt.
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").
Besides for APFS what user visible killer features has Apple made to Mac OS since 10.6.8? I'm sure they have made internal non user visible improvements to their kernel and userland. But it seems most of the "changes" to Mac OS is just churning code, or at least it seems that way from the outside.
To me personally 10.6.8 + Security Updates + APFS is extremely close to the ideal operating system.
There's the new poop emoji!! (unicode 10 emojis via 10.13.1 update)
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.
Kudos for reporting this publicly! We need this kind of stuff exposed publicly so that companies fix the issue and force an update. At the same time, consumers should be made aware of what security holes look like and what the risks are. Apple has been getting away with this stuff for a while now.
Do you think a hacker with ill-intent would have reported this issue at all?
No one else has mentioned it seems, digging through the twitter comments I found a tweet which states this was already known by Apple, and posted on the forums in the form of a solution...
So far the best mitigation I could find out is to enable the root account and set a strong password for it. Hopefully we'll get a security update quickly so that I disable root access again. While checking on this I also realized I was running 10.13 instead of 10.13.1 which fixes another major security flaw (key chain saves in plain text)
Doesn't work for me on a freshly installed MacOS High Sierra, but does work on an upgraded laptop to High Sierra.
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.
In order to create the test case that you would automate, you first must create the repro scenario. IOW, automation has nothing to do with this until the bug is found in the first place. Arguably, one could create a test model that might have found this but raise your hand if you even know what I'm talking about when I say "test model".
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.)
Respectfully disagree. "User cannot log in as root if root user is disabled" is absolutely a test case that should be written regardless of previously seeing the bug.
Meh, you're probably right. If nothing else, I'd want to verify the result of trying to use a disabled account (text in the dialog is localized, et. al.) Run through the scenario before I formally write the case and...WTF? Yeah, I could see that.
Apple suggests the workaround also discussed in this thread until the issue is fixed:
"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."
I just have no words, it seems intentional. They may want to review their build pipeline to check someone didn't manipulate the source code before it was signed. I haven't seen an easy root priv-esc like this in a long while.
[meta] I think this thread is currently being downvoted, or dragged down by the mods somehow. It should be in the #1 right now. I suspect people are flagging/downvoting because there is no responsible disclosure in this case.
Be careful about noticing a few data points and then connecting the dots. You can get an image that way but it's usually just a reflection of your own bias, and people with opposite views will see opposite patterns in the same data. That's because we're more likely to notice what we dislike, and to weight it more heavily.
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.
Apple software quality has got very sloppy (again). I recall it was particularly bad around 2014, but then seemed to have improved. Seems the sloppiness is back again. It would seem Apple is no unique in the regard that its success has made it fat and lazy. My particular favourite one at the moment is that in iOS 11.1.2 navigation transition animations eventually break if the device is running long enough (a few days). Restarting the device fixes this. The fun part is trying to work out why on earth this would be? Transition animations are cached?
To workaround this before Apple have had a chance to patch it(thanks @lemiorhan), it seems you can:
- 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.
I mean, I only tried 15 times, I don't know if that counts as "several" but this doesn't work for me.
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
So — if you log out and log in as root without a password (EEK!), you can set your own password as root. Once you do, Mac os will no longer bypass the password.
wat. confirmed on 10.13.1 (17B48). I was even able to add another super user.
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.
Good point. Force of habit. Unfortunately I can no longer try since I set the root password under the Directory Utility, which probably changed the state of the system.
Apparently someone verified that it /does/ also work with `su - root`.
Yeah, everyone seems to be forgetting that until very recent versions of MacOS you could just boot into SUM and make your own admin account to get access to a mac.
Reminds me of an exploit back in 10.7 where you could create a new admin privileged user from a non-admin account using some bash commands. Used that to add Xcode to my work computer at college so I could fool around with learning how to code when I was at work.
Oh god, seriously what happened to apple? They are the richest company in the world and the quality of their software has kept declining every year.
Right now there is no computer system that I can wholeheartedly recommend to non technical people... :(
1. Ensure you always have FileVault enabled (you should regardless) and shutdown after work until the bug is fixed.
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.
It’s not an example of security by obscurity, it’s a straight out security flaw and bug.
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.
The fact is that the devs certainly do know about it by now, yet users do not have a fix yet. Users do, however, have a workaround, and knowledge that the security flaw exists in the first place.
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.
> "The fact is that the devs certainly do know about it by now, yet users do not have a fix yet."
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.
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.
This is the most idiotic thing I've heard in a long time. Yes, they were already at risk, but with the way he disclosed the information, the risk increased exponentially. This guy's actions were either stupid or malicious.
Obviously this isn't the best way to disclose a security flaw.
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.
It really feels like the only thing that made Apple to be less prone to hacking and malware (and therefore more secure) than other OS is the lack of scrutiny by hackers and malware authors. This is a front door open kind of problem.
I haven't seen anyone mention this critical part of the flaw - if you disable the root account, then log out and log back in, the root account is active again.
Password change is the only protection until it is patched.
It seems as though buying a new apple product or upgrading one to new software implicitly signs you up to be a beta tester. It's pretty surprising from the world's most valuable company, no?
I'm using 10.13.1 and it did work for me. You have to first fail a login in one of these dialogs (did it with my current user and no password) before doing root with no password.
Confirmed on 10.13.1. As a workaround, once you login as "root", you can change the password to something else, and the empty password will stop working.
Reminds me of the time Mac OS X would trust any NIS server in the local net to authenticate local root. Can't find the story though. Did that even happen?
The bug does not exist on El Capitan. Your description tells me you already had the root user enabled with no password (which is something you can do with Directory Utility.app)
This is indeed a bad black mark on Apple. With all the money they have, it's terrible that they let this one slip by.
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.
By default no as most people expect things to keep running when they lock their laptop.
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.
if someone has discovered a way to wipe anyones paypal account, should he disclose it privately or let it trend on social media? and lets say the fix will take about a day at the earliest.
Excuse my language, but this was a dick move to post this publicly, especially on Twitter. Go through private bug channels properly for something as serious as this. Of course doing it that way doesn't give you your 15 minutes of interweb fame.
When I put it into my personal malice / ignorance balance, it weighs out to the likelihood that the discloser isn't plugged in enough to the infosec scene to be aware that there are already best practices for this kind of disclosure.
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.
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.
Maybe he didn't know about the proper procedures to handle a security vulnerability. You wouldn't have to be a security researcher to discover this bug, and I don't see any indication that he is one.
Also, it's reasonable for someone to think that making a public stink about it is in the best interest of all the people then that can immediately patch it themselves instead of having to wait for Apple to push a patch and then for everyone to download that patch.
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.
He is giving a technical talk to a large audience. Slides refer to development, and bio implies this means software development. Bio uses the phrase 'founder of software craftsmanship Turkey'.
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 guess I am, but it's more than a belief that 'active programmer ==> familiarity with responsible disclosure'.
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.
I would say it's pretty basic common sense, not to publicly announce ANYTHING that could immediately affect millions of people. Unless he's just a sociopath.
From his Twitter account, he's not just some layman stumbling across it.
If that were true, then the security community wouldn't have spent years fighting about whether responsible disclosure was the right approach. That's for people who actually understand this stuff. It's unreasonable to expect an outsider to derive it all on their own from first principles.
So someone stumbles upon a lost cache of chemical weapons. Rather than reporting to the authorities, they post its location on Twitter. That's called just using your brain.
You're coming at this from a position of knowledge and assuming everyone else knows as much as you do, or should be able to figure it out in short order. That's not how it works. It's really hard to see how other people might think in situations like this.
The guy is a self professed "Agile Software Craftsman". I could give some leeway to my average friend finding this, but he's pretty involved with this community.
Security though obscurity is no security at all. Don't you think the people living around the chemical weapons should be informed too so they can take precautions to protect themselves?
Probably could still get 15 minutes of fame if you disclosed privately then blogged about the back and forth and a picture of the $10,000 cheque from Apple.
That this would be the prevailing understanding is exactly why a bug like this would live in the wild at all. There are plenty of other orgs out there who would have paid big money for this.
Source? I've heard of iPhone vulnerabilities getting high six figures from Apple (for root access via sms). Why wouldn't Apple pay for something like this?
Yeh, except for the millions of MacOS users out there, like my parents who don't read Twitter, or HN or any of the other sites people think that everyone stays up on. They are the targets.
Not technically. Exploitation still requires physical access to the machine or remote access to have been enabled, right? Did your parents who don't read Twitter or HN enable a feature that generally only power users want or need?
As I had said above, this, in the long run, is actually less secure than not having a root account at all. If you do this, make sure to revert it once the issue is patched.
I may not be an apple fanboy, but I admit, I really miss Jobs, and his commitment to quality. Apple has just been minting money and forgot all about its core values.
Pyramid's OSx version of Unix (a dual-universe Unix supporting both 4.xBSD and System V) [1] had a bug in the "passwd" program, such that if somebody edited /etc/passwd with a text editor and introduced a blank line (say at the end of the file, or anywhere), the next person who changed their password with the setuid root passwd program would cause the blank line to be replaced by "::0:0:::" (empty user name, empty password, uid 0, gid 0), which then let you get a root shell with 'su ""', and log in as root by pressing the return key to the Login: prompt. (Well it wasn't quite that simple. The email explains.)
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 see
- 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.