Hacker News new | comments | show | ask | jobs | submit login
macOS High Sierra: Anyone can login as “root” with empty password (twitter.com)
3001 points by vladikoff 83 days ago | hide | past | web | favorite | 1055 comments



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.


osquery is not a built-in tool. You can get the same info with plutil(1):

  $ sudo plutil -p /private/var/db/dslocal/nodes/Default/users/root.plist
If I understand OP correctly, if passwd is a lone asterisk, then you haven't been exploited.

Edit: trying a little harder to dump accountPolicyData:

  $ sudo defaults read /private/var/db/dslocal/nodes/Default/users/root.plist accountPolicyData | grep -oE '[[:xdigit:]]+' | xxd -r -p


>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.


That's correct.


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.


I'm confused, why do you have to escape an asterisk?


He's stuck inside


Markdown in HN comments.


Famous last words of a Roman centurion.


Nah, I've never seen them do worse than knock people out. Probably the next thing the centurion said was "Ow, what hit me!".


wildcard.


Only High Sierra is affected.


`sudo dscl . -read Users/root accountPolicyData`


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:

  python

  >>> import time

  >>> time.strftime("%a, %d %b %Y %H:%M:%S", time.localtime(1474441704.265237))
You'll get something like 'Wed, 21 Sep 2016 07:08:24'

(I'm sure you can do this in other languages than python...)


If you're already in the terminal you could instead enter

  date -r 1474441704


This is a much better answer!


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.


This works remotely as well (although not through SSH, obviously).


possibly the same timestamp here: 1510300538.767916 'Fri, 10 Nov 2017 04:55:38'


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?


My root pw passwordLastSetTime says this morning.. the fuck??


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!)

[1] https://support.apple.com/en-us/HT204899

[2] Unless/until you reboot to a diagnostic monitor on a special partition (which requires pressing command-R from a local keyboard during the POST), then run a command to disable SIP, and then reboot again. Continuity Activation Tool requires users to perform this step as part of the install process to allow installation of Bluetooth drivers not originally signed by Apple.


A motivated and knowledgeable adversary could most likely load a custom kext to bypass the integrity measures. Am I right?


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.


> Can be mitigated by enabling the root user with a strong password

Instructions from Apple: https://support.apple.com/en-us/HT204012


And if you're thinking that manually disabling root might also fix this, it won't. You have to leave root enabled.


Security update now available: https://support.apple.com/en-us/HT208315


You can also get the password last set time with:

    sudo dscl . -readpl "/Users/dan.koepke" accountPolicyData passwordLastSetTime


ok dan...


apple have a security update out now: https://support.apple.com/en-au/HT208315


Excellent! Thanks for sharing


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.

That’s my theory, anyway.


These days, where is the lock-in?

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.


It's a mental lock in now a days.

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.

[0] https://displaycal.net/


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.


Windows 10 and Windows 8 have really moved the OS forward in my opinion.


> 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.


> PowerPC days

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.


>These days, where is the lock-in?

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.


This might me valid for the US. Anecdotally, where I live (Switzerland/central Europe) almost nobody uses iMessage, and WhatsApp is the big dominator.


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 honestly don't think most iPhone owners in Europe even understand that iMessage is not SMS.


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?


There are a few "quality of life" tools on OSX that I use, like Alfred that I haven't seen a Linux equivalent.

But you're right, I could probably switch to Linux and be fairly happy.


As for Alfred replacement... How about [Albert](https://github.com/albertlauncher/albert)?


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 lock-in is Messages, at least for a lot of people.


I'd wager the number of people using Messages on macOS is really not that high. Most people are content to message using their phone.

iMessage absolutely is a lock-in for iOS, though.


Why's iMessage a lock-in? I have an iPhone but I wasn't aware I'd lose anything (significant) by switching to Android (or whatever).


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.


It's not well publicised but, if you know anyone who's moved away from iOS they can remove their phone number from iMessage here;

https://selfsolve.apple.com/deregister-imessage/


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.


For photography on Linux you gotta check out Darktable. It's actually very very good as a Lightroom replacement for RAW workflow.


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.


The lock in is definitely less, but for me:

- Large iPhoto library - Easy syncing with multiple iPhones (notes, photos etc) - Xcode for iOS development


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 guess this happens if the other posters are of low karma, or if the other comments are quite old.


Ah thanks, now it makes sense. I always wondered why sometimes my comments went straight to the top. I've lost too much productivity here, clearly! ;)


Yeah I only know because I‘ve watched my posts gain better positions when I hit 1k karma (iirc).


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.


Yes new comments get a bit of time near the top. The amount of time varies based on the amount and quality of other comments.


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.


I've been actively investigating that for over a year:

https://taoofmac.com/space/blog/2016/10/29/2240

I have to use Windows for work, though (I'm at a Microsoft subsidiary, and all we get are Windows machines), and I can live OK inside WSL.


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 thought it was confirmed that it is new to High Sierra, it was indeed lingering on forums as a "administrator hint" though.


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.


That’s not a big difference for Apple. They’ve got their user base now, they don’t need developers to spread the word anymore.


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.


Surely they havent used up the pool of people that might/want switch to macOS. How can anyone make even such statement?


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.

Still, only my theory of course.


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.

Occam's Razor supports this hypothesis.


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?"


You're right. I was being a bit hyperbolic.


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.


I do see people switching to Linux for this reason, Apple the new MS, Ubuntu the new Apple?


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.


Saw this on the Windows 10 subreddit and got a sad chuckle out of it: https://i.redd.it/dvzzftkyzyiz.png

They definitely have a more modern design language going, but they're not exactly consistent about it.


But customer retention is still important.

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.


It reminds me of the Windows 95/98 login.

At the logon screen, just pressing ESC got you to the desktop.

Video: https://www.youtube.com/watch?v=CAH2j9mRgUM


It's kind of similar, but that was intentional. There was even a "Cancel" button in the GUI that did the same thing.


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.


Can't agree more. The main thing that keeps me using OSX is Adobe Creative Cloud.

I'd mention aesthetics, but the current Linux distros look quite good, plus they're customisable.


Amazingly, this was disclosed offhand on the Apple developer forums, two weeks ago (see final comment by chethan177):

https://forums.developer.apple.com/thread/79235

(spotted by https://twitter.com/fristle/status/935670476214378496)


… 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.


"If you're able to log in (hurray, you're the admin now)" Personally not very hurray


So not so much a 0day vulnerability anymore (+ 13 days ) ?


That’s absolutely terrible. Does Apple not monitor those forums at all?


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.


Those are the support forums, GP is asking about developer forums.

Yes, Apple monitors them, but apparently not closely enough :/


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...


You forgot about "repair permissions" and "do a SMC+NVRAM reset"


> mostly unhelpful and often inaccurate support

Sorry that the free support for your expensive device does not match the quality of the non-existing support from your device vendor.


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.


My High Sierra is a fresh install, and it's affected.


Yup. Can confirm. I installed it fresh on a VM from the downloaded installer and it is affected.


My upgraded high sierra doesn't have this problem. The theory could be backwards. Anyways, this is stunning.


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.

Is that understanding correct?


Try guest account.

I could do it on guest account, by first pressing enter after entering "root". And after a fail, clicking the unlock button.


Mine is an upgrade and does.


But at one point a root account is created with an empty password right?

There's a specific line somewhere that's doing this, in theory.

Maybe they should have opted for "create `root` with unguessable password"


No, that's a hack. And it opens new attacks, like on the hashing algorithm and poor randomness or predictability in the generation logic.


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.


Maybe something like this was added to make debugging/testing of the OS easier? maybe they just forgot to remove it before shipping the new macOS


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.


That seems the only probable cause I've come across so far. It doesn't seem to be a backdoor because it would be more of a back-spillway-gate.


That could be the case - I can't find any other possible logical explanation, because it doesn't make any sense.


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).

Or is this not a permanent password set?


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.


If that's true (and certainly sounds plausible from what is known so far), that's a very valuable heuristic.


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).


Login screen is probably already running as root in the first place, so it already had permission to enable shell/GUI access



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 assume that it can't use the password in the password list as that should be hashed already.


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.


I'm reminded of: "Solaris Telnet 0-day vulnerability", 2007: https://m.slashdot.org/story/80056

But this does indeed seem to be an extra level of user-friendly stupid.


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.


Identity management is complex and boring.

Apples user management is even more complex than most Unixes.


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.


Another user suggested it may have to do with Apple’s new file system: https://news.ycombinator.com/item?id=15801643


You misunderstood. He's talking about a password hash storage system, not a filesystem.


Exactly, how can this happens and no one asks.


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.


And that will help because Open Source security is so great?

Or because people care to inspect the codebases they otherwise use?


I don't think you understand the difference between open source and free software. Allowing everyone to read it makes it open source.

https://www.gnu.org/philosophy/open-source-misses-the-point....


Apple uses the slogan for High Sierra: "Your Mac. Elevated."

Kind of ironic that you can easily get elevated privileges with it.


Be careful testing this! It appears that you're creating a "root" superuser with no password. Be sure to clean up that user afterwords.

https://twitter.com/a_hailes/status/935601901839806464


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.


You can simply set a root password with "sudo passwd" to close the hole.


Then you better remember the password you set, or be sure that you will always have sudo access.


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.


Don't disable root. The bug re-enables it with a new blank password.


It doesn't if you disable it from the shell like this, as I note in my comment.

I've tested both approaches - disabling via the GUI causes this bug to re-occur next time you try, disabling via the shell does not.


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.

... but the whole thing is a mess overall.


I confirm, disabling from shell does seem to prevent further logins


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.


...unless you set a password, right?


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.


You're not creating it, but rather enabling it. When the bug is triggered, the root user is enabled (per Directory Utility).


But you are creating the password for it.


This support article explains how to disable the root user: https://support.apple.com/en-us/HT204012


Do note that this doesn't fix the problem. The system (at least High Sierra) will happily re-enable the user for every attempt at logging in.


Just change the root password once the account is enabled; this fixes the hole.

sudo passwd -u root

It's sad we have to do this, though.


If you disable the root user using `dsenableroot -d` from the Terminal, this seems to disable the account in a way that leaves its password intact.


The bug isn't in the disabling, it's in the auto-enabling on attempt.


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.


Until this is fixed it's probably better to use Directory Utility to enable root with a strong password.

/System/Library/CoreServices/Applications/Directory Utility.app

Edit > Change Root Password


The "root" superuser is always there, I'm not sure if it's possible to actually delete it.


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.

[1] https://support.apple.com/en-us/HT204012


This is the best workaround for now. Enable the root user with a strong password till the bug is fixed by Apple.


oh my god


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.


You can get undetectble remote access on most machines given "physical access once", so I don't think this qualifies as "remotely exploitable".


If root was ever enabled without setting a password, the machine is then in a state that it can be remotely exploitable.

While it's unlikely, there are probably plenty of users who have done this for some reason or another.

Don't underestimate a user's ability to blindly do things like this by following arcane instructions in attempts to fix an unrelated problem.


Not according to this video:

https://www.youtube.com/watch?v=FpOH0lxEGBE

They seem to be remotely accessing the machine to both set and then use the root account.


The system needs to have some sort of remote access, like screen sharing, turned on first, then you can remotely use the root account.


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...


Been wondering that myself since it seems that this also happens with 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 "

https://twitter.com/fristle/status/935670476214378496


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.

Anyone got any inside scoop?


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.

[0]: https://medium.com/backchannel/what-i-saw-inside-apple-s-top...


Everything ends in tears when managers mix up targets/estimates with commitments


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.


Where did you hear that the keyboard was pulled from the channel? It just seems to be out of stock for me.


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.


In this case, any password works. The blank one is just the initial example. The password is set to whatever you typed, even if nothing.


> 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.


> Probably more so, last I looked, Apple has considerably fewer software employees than the other big companies.

I don't think this is true. Apple, Google, and Microsoft all have on the order of 100K employees.


Keep in mind that Apple directly employs retail staff.


Point taken. A closer look shows that about half of them are part of Apple corporate.


> or their employees are required to be more discrete?

Yes, I believe so. I've heard there are strict requirements on even internal discussion. (Who you can talk to; about what; where.)


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.


Could it be the level of secrecy around Apple? I see responses for Google and Facebook devs on HN a lot but never Apple.

The only people I know locally that work for Apple are remote customer support folks.


Apple probably doesn't take too kindly to their employees talking about their work. I'd imagine it's a fire-able offense.


it is everywhere else too, but people do quit...


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.

They’re now retreating from that strategy: https://factordaily.com/apple-to-pull-back-development-work-...


Everyone retreats from that strategy.


well that explains allot, iTunes store/ App Store have always been painfully slow, compared to doing anything in Safari.


It seems apple's software has been trending down in quality since Snow Leopard.


I'll agree that Snow Leopard is the high water-mark.


It's common among a small group of Mac users to hold Snow Leopard up as the peak of software quality, but only because of rose-colored glasses [1].

[1] https://www.computerworld.com/article/2528936/mac-os-x/snow-...


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.


I remember my Macbook's battery life being significantly extended by an OS upgrade; either Leopard or Snow Leopard.


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:

https://m.imore.com/mavericks-preview-timer-coalescing


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.


The last High Sierra update will have less bugs than the next major release too, so I don't think that's really relevant.


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.


It can't be a coincidence that this was the last major release before Steve Jobs died.


It can’t be a coincidence because it’s not true. Lion was released well before SJ’s death.

Unless you’re arguing Lion wasn’t major because you didn’t like it, but that’s an argument that proves to much, methinks.


3rded. I wish time stopped at 10.6.8.


Apple has always had QA issues, the difference now is that they’re increasingly tested by the users, hackers, etc.


Difference? MacOS userbase hasn’t changed much since 2011, I thought?


I've no information on how good this site's data is, but https://www.statista.com/statistics/218089/global-market-sha... seems to show that from 2013-2017 global macOS market share has increased from 7.95% to 11.3%.


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.


Repressive collusion to fix salaries and restrict industry movement, doesn't really inspire your employees to try their best


> Anyone got any inside scoop?

I have a feeling that anyone who does would get fired for commenting here about it.


You have to think that whoever was responsible for testing this is going to get fired. This is egregiously bad...


This is a management issue. It shouldn't be possible for such a mistake to slip into production code. It has happened more than once in recent times.


iTunes had QA problems for more than 10 years, only the early versions were really solid. I am not sure that it is a recent problem.


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.


A [?] don't know what you are talking about.


I've experienced lots of issues wiht IOS and High Sierra as well. Apple definitely reduced their software quality since IOS 11.


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.


This also can happen in open software. So I don't think your comment is valid.

Open software enables people to take a look inside to what is going on. It isn't a cure for bug free development.


It reminds me the KMail bug: https://www.ctrl.blog/entry/kmail-cve-2017-9604-openpgp

Some security bugs exist in the Linux/BSDs kernels for a loooong time before someone notice and fix it (e.g., https://media.defcon.org/DEF%20CON%2025/DEF%20CON%2025%20pre...)


Anecdotal but I started noticing a decline in quality after Steve Jobs died.


i'm still wondering if that impression ( which i share) is real or not.

At the minimum, i'd say i feel apple release less innovating os versions while producing at least the same number of bugs.


Encouraging users to "try it" is dangerous here. Recreating the bug enables root user across the system, and most users won't know how to disable it.

TechCrunch, if you're reading this... please discourage people from reproducing the bug.


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.

That should be much higher up in the article.


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.

Is that understanding correct?


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.


Not the case.

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.


> others can remotely & silently access the system as root.

They already can:

https://gfycat.com/gifs/detail/sentimentalnaiveantelopegroun...


This does not work if the root user has not been enabled locally.

Source: Just tried it myself.


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:

https://www.facebook.com/amar.sood/posts/10209545863036116


Uh I tested redisabling the root account and it reenabled the flaw. You have to keep the root account enabled.



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.

Really bad stuff


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.


Wonder if people tried screen share/vnc with that theory. I'd suspect anything gui-driven.


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.


On most systems, root without password isn't available remotely. Is this not true on OSX?


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.


Does not work via ssh or screen sharing based on my testing here. Seems to require physical access to the machine.



No, it doesn't work for remote login.


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.


"responsible disclosure" isn't some morally unassailable high ground, but companies like apple sure want you to believe it is.


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.


That's when you put a clear timeline for how long you will wait before disclosing when you report these bugs.


I run as a standard user and was able to reproduce the bug.


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.


I agree that we need more responsible disclosure. But as https://www.eff.org/deeplinks/2017/10/drms-dead-canary-how-w... explains, blame the DMCA.

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.



I was wondering about that. I'm going to change this.


Thanks :)


Yes, but the most secure thing to do at this point _is_ to recreate the bug and then set a password for the root user.

Otherwise the hole is still there for others to exploit.


If you set a root password, this bug still works, it seems to reset the root password.

Edit: I was partly wrong. The bug still works if you disable root afterwards, then it reenables and resets it.


Yeah, you’re safe if you keep the foot account alive and you set a password for root. At least as far as I can tell...


Can you talk about how to correctly disable the root account if someone did try it?


If you're wondering how to disable it, the menu option can be found here: https://support.apple.com/en-gb/HT204012


According to another comment thread here https://news.ycombinator.com/item?id=15802113 disabling from the GUI re-enabled the bug.

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


Enables root access in what way?


Mac OS X doesn't have a real root account, it uses sudo exclusively. This enables a true root user shell.


The root account always exists.

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?


No, sorry, I did not mean that or mean to imply it.

I think the feature that caused this is related to upgrading pre-high-sierra user password hashes to high-sierra-style hashes.

The fact that it works for situations where the password is null is a/the bug.


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)...


No, I reproduced on freshly-installed High Sierra on two machines.


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).


Works with El Capitan too.


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."


Thank you! I was looking for a workaround to avoid leaving my system vulnerable until the patch lands in App Store.


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:

https://twitter.com/unsynchronized/status/935656609140711426

That seems to match the technical explanation of the bug here:

https://objective-see.com/blog/blog_0x24.html

The tweet claims they've got Apple Remote Desktop access & screen sharing working via the _applepay user account. Why/how that's possible, I have no idea - I don't have High Sierra to confirm this, and I'm not sure I'd want to mess with the _applepay user account even if I did.


Current workaround / fix:

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.


Once the fix for this issue is out, you should disable the root user.


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.


I'm able to do this as well, login as root with no password from the login screen.


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.


Nah, Apple really needs to realize that they need to step up their game. This might hurt some users, but it sets a much needed fire under Apple's ass.


Confirming this works, both from preferences, as well as from the main login screen

It seems like root has no password by default. Setting one is enough to close the hole. This is unbelievable!

Curious to see what's in /var/db/dslocal/nodes/Default/users/root.plist before trying this.


These are the contents of the file, after converting them from binary plist to plain xml: https://gist.github.com/shoghicp/2b529b54b9d70daf192b68e3564...


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.

Or open a terminal and do:

    sudo passwd


> click the lock and enter your password

or just enter root with no password


Ha, ya. That way you know it's still needed!


Disabling the root user again with

  dsenableroot -d
does not re-enable the exploit


    sudo passwd
Does that change the password for the current user without authentication, or does it change the password for root without authentication?

I think it would be best to recommend an unambiguous

    sudo passwd root


"sudo foo" with no other arguments runs "foo" as root. "passwd" with no other arguments changes the password of the user it is running as.

"sudo passwd" unambiguously changes the password of root.


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.


That probably takes some major doublethink: convincing yourself that a bricked machine is less broken than a vulnerable one.


you might be able to fix that. I had that too, had to manually update the preboot. Details are somewhere in here https://forums.developer.apple.com/thread/80174


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.

[1]: https://forums.developer.apple.com/thread/60763


> 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.


> Doubtful Firefox and Chrome work just fine.

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 of those issues are reasonable to expect no matter what your opinion of Apple's software is.

Neither is your password showing up in a password hint field (or anywhere for that matter... why is it even stored unhashed?).

Neither is logging in with a blank password enabling a disabled root user.


> 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.


Really? What driver support on a desktop were you experiencing?

I've run Linux mint on my desktop at home for a few years now and have had zero problems at all (Intel i5, Nvidia gfx, wired connection).

The last time I had driver issues with Linux was ~10 years ago and it was for a laptop running Ubuntu.


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.


Silverlight was EOL'd five years ago.


Tell that to Dish Network.


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.


It was partly a marketing thing, but Edge is not IE, and Edge has never supported any plugins (which Silverlight is).


Correction: Edge is Not-IE(-Not-At-All-Nooosir)


Seems as though this tweet is not the first time it came up in public. Nov 13, 2017 12:48 PM

https://forums.developer.apple.com/thread/79235

Screenshot. http://oi67.tinypic.com/2h6embp.jpg


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.


Nothing wrong with incremental upgrades.


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.

1: https://twitter.com/thomasfuchs/status/907764896829452288/ph...


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.


Fix this by setting a password for root (or disable).

Instructions here: https://support.apple.com/en-us/HT204012


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 ..


Yeah, confirmed it myself too. Enable root with a strong password works though.


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.


Unlikely any AWS imaged employee MacBooks at least. AWS IT back in the beginning of October forbade employees to not upgrade to High Sierra.


There're a lot of attendees from a lot of companies, they can be vulnerable.


Forbade to not upgrade? So, forcefully install?


I really hope there's an extra zero in your 40000.


Maybe closer to 35000, but yeah, that's the scale of ReInvent, last year AWS reported 24000 attendees. I was there last year, that's a lot of people

https://aws.amazon.com/blogs/apn/why-sponsor-aws-reinvent-20...


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.


Once you disable the root account you can log in without a password again :/


Yep. If you keep it enabled and set a good password then you should be OK. I think.


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.

I have truly lost faith in Apple.


Agreed.

iOS 11 was the tipping point for me (can't delete photos using trash icon, wrong orientation when unlocking phone, random lag/freezes etc).

Apple just doesn't care any more.


Unless you buy Apple Care, of course.

(Sorry, couldn't resist writing :) )


I chuckled.


   > 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.


Is social media the goto for reporting security vulnerabilities in 2017?

If I remember correctly, one is supposed to make it public once patched or in event of no response, no?

Edit: What is "Responsible Disclosure"[0]?

[0] https://en.wikipedia.org/wiki/Responsible_disclosure


Someone notices that they can log in as root with no password. In 2017, reflexively tweeting about it seems pretty unsurprising.


Seems like the guy just discovered this by accident. It's not like you'd have to be a security engineer to stumble upon this.


I think the difference is if the problem is discovered by Joe Schmoe or a security researcher.


Where is Joe Random's obligation to responsibly disclose?

To whom does he owe that obligation? Apple? The public? Both? Why?


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.


This is one of those cases where responsible disclosure just means you're doing the job one of apples automated tests should be doing.


Full disclosure is also a form of responsible disclosure.


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.


It's certainly not acceptable, I just think it hasn't been a priority for Apple since it's a relatively niche usecase.

It could also be a security/privacy decision to leave it broken but safe until they can implement camera access through WebViews securely.

The closest to any official reason I could find is a dev letting us know that mum's the word:

>I asked about this internally and the answer is that, right now, WebRTC is only supported in Safari. No WKWebView, not even SFSafariViewController.

https://forums.developer.apple.com/thread/88052#266901


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.


I believe hitting "cancel" was enough. https://www.youtube.com/watch?v=DE5PRW-AR7Q

Also reminds me of https://youtu.be/BVL8_ne4WZo?t=19s


from the only top-level comment on that video:

> 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.


Good point. Been a while. Windows 7 also has/had an interesting one https://www.youtube.com/watch?v=zwO4YqSc4XE but it's much more involved.


Did Windows98 even have administrator role? I mean FAT file systems don't even have file ownership right?


It did. But didn't have security tied to the fs.


Exactly my thoughts. I remember this, I think even early versions of WinXP had this feature.


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.


it was a feature not a bug. something related to not DoSing yourself by forgetting your password /s


This will be a fun fix.

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.


In the meantime, if you'd like to protect your mac, you can set a password for root by going to:

System Preferences > Users & Groups > Login Options > Join > Open Directory Utility > Edit > Change Root 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?


The bug enables the root user, so leaving it disabled won't save you. Set a password for root, then you should be good to go.


Mine is currently enabled and since i've set a password, the bug seems to be gone. I can't authenticate by just typing root anymore.


Alternatively, there's `sudo passwd`.


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?


There are thousands of ways you could test this. Like most tests, having them isn't the same as having good ones.


If you have `osquery` deployed to your fleet you can detect compromise with this query:

SELECT * FROM plist WHERE path = "/private/var/db/dslocal/nodes/Default/users/root.plist" AND key = "passwd" AND length(value) > 1;


That only detects enabled root users, which is a start but may include innocent people who have set a root password to protect their machines.


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.


Top 10 software blunders of all time:

1) (Apple) 1 + 2 + 3 = 24 https://news.ycombinator.com/item?id=15538666

2) (Apple) Blank root password https://news.ycombinator.com/item?id=15800676

3) ...


0) Therac 25: https://hackaday.com/2015/10/26/killed-by-a-machine-the-ther...

There ARE areas more safety critical than desktop computing, you know.


Sort of related:

- it is almost 2018 and copy pasting on an ipad/iphone is still a horrible, non-deterministic nightmare


Well I remember when the Ubuntu installer left your root password in a clear text file that was world readable on your FS.[1]

I would really like to see a top 10 list of software blunders, I think everyone on HN would.

1. https://launchpad.net/ubuntu/+source/shadow/+bug/34606


In that case the bug was fixed in less than a day. Let's see how Apple fares.


0)(Apple) If macOS High Sierra shows your password instead of the password hint https://news.ycombinator.com/item?id=15410953



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


I have "Guest User" disabled normally. This allowed me to switch Guest User on, log out, login as `root` into OS X. lol


Oh this is a real vulnerability. It's possible to switch your user to System Administrator using "root" and no password.


10.13.1 can't make it happen


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.


Temporary workaround (pasted from http://www.bbc.com/news/technology-42161823)

While Apple works on its fix, it offered a workaround for users concerned about the bug.

“Setting a root password prevents unauthorized access to your Mac,” the company explained.

"To enable the Root User and set a password, please follow the instructions here: https://support.apple.com/en-us/HT204012.

---

Edit - for me those Apple instructions didn't work. This seemed to:

Search for 'Directory Utility' in Spotlight and click it.

Click the lock to make changes

Select 'Enable root user' from 'Edit' on the main menu and set a password.


Am I missing something or does this require the attacker to have access to an unlocked computer? In which case all bets are off anyways.


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.


Fair point, if that works with a guest account.

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.


It works remotely if remote login is enable.

edit: Screen sharing is is vulnerable not ssh. Either way its bad.


No it does not. I tested this rather carefully, and both ssh and screen sharing do not allow the user root with no password.


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.


nope. you can log in at the login screen, it creates a new root admin user


Missed that part in the text, thanks.

Yikes!


an unlocked computer, or:

* a computer with remote login enabled

* a computer with the main login screen set to "username and password" mode

* a computer with a guest account


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.


>In which case all bets are off anyways

How are all bets off if they don't have access to a root user? This isn't Windows we're talking about.


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).


If you lose physical control over the machine, all bets are off because an attacker can modify the hardware to do nefarious things.


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


ok, sure, but in practice that is pretty unlikely.


What if it's a stolen laptop with an encrypted hard drive?


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.


if you disable the root account you can log in again without a password, even when you set one.


This is deeply troubling. How does this even happen?


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.


Errr... umm... unit tests? Tests?


You can have 100% coverage and never check a single edge case. Much less remember every edge case.


I'm on Sierra and haven't been able to reproduce. But does anyone know if it respects pam.d "nullok" and I could just delete that option?

    /etc/pam.d$ grep -RI nullok /etc/pam.d
    /etc/pam.d/authorization:auth       required       pam_opendirectory.so use_first_pass nullok
    /etc/pam.d/checkpw:auth       required       pam_opendirectory.so use_first_pass nullok
    /etc/pam.d/screensaver:auth       required       pam_opendirectory.so use_first_pass nullok


Tested it in the terminal with "su - root". Doesn't help. Or does one need to reboot after it? UPDATE: No effect after rebooting.


Title should be changed to 'macOS'

I initially saw this thinking it didn't affect Sierra or High Sierra.


Now you have me confused, is it just High Sierra or Sierra as well?


It does not work for me using Sierra.


Awesome, thanks.


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").


Who needs security when we have animoji!


To fix this with a workaround open Terminal.app and run the command "sudo passwd" to set a password. Can't believe this is happening.


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

- https://www.apple.com/macos/high-sierra/

- https://developer.apple.com/library/content/releasenotes/Mac...

(yes Apple can't be bothered to update their dev docs with the point releases. Documentation quality has fallen off dramatically since the 10.6 days)

Given the stream of bug reports on various apple sites, I have not upgraded any of my personal machines, and my employer has stated they will not be upgrading our machines in the near term.


APFS is not an example of something I would consider "user visible"–for the average user there's no difference between HFS+ and APFS.


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...

https://forums.developer.apple.com/thread/79235#277225


Mentioned many times actually. And the forum is users self help. It is not monitored by Apple.


Ahh the links weren’t on the first page of the HN comments when I posted. They are now. I didn’t click more. :)


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.


I don't know much about OS development but isn't this just the sort of thing you'd automate testing for?


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.


If they are even a little smart, they'll now have a test for this ;)


I guess not. I recall reading somewhere that the Linux kernel doesn't even have automated tests. (edit: found the link: https://stackoverflow.com/a/3177643/96855)


Have you seen iOS11? Apple doesn't seem to value testing too much


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."

https://techcrunch.com/2017/11/28/astonishing-os-x-bug-lets-...


I wouldn't have thought that NSA backdoors are so simple



I wonder if you can also defeat Face ID by wearing a white face mask?

https://images-na.ssl-images-amazon.com/images/I/51I4nsyt9AL...


Can't reproduce on multiple High Sierra machines.


Can't repro on a 2012 retina MBP running 10.13.1, attempting the original repro and others suggested here. Until the wife walks away from hers, it's the only machine I have available. I'm curious as to the difference, given the high number of repros.


Apparently you have to have the password field focused before you submit. Anything in the password field (including nothing) will be saved as the root password.


Does it work if you set the root password and try again?


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.


Not the first time I've noticed this with threads that are bad PR for Apple.


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.

In this case the story hit a software penalty for a while, which we noticed and corrected as we usually do eventually. This software works well most of the time but unfortunately not always. Either way, it has nothing to do with our opinions about Apple, which is fortunate because we don't particularly have any.


I didn't mean to imply that it was manipulation on the part of HN. I am wary that Apple, like any large company, might try to bury stories like this.

I know it's been asked before (by me, for one), but can you tell us anything about the protections HN has in place against astroturfing?


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?


Wow. As if I needed another reason to never "upgrade" to High Sierra...


Apparently El Capitan is vulnerable too.


Can't reproduce on El Cap.


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


I was just able to reproduce it in 10.13.1. I had to click submit twice.


This is very, very bad.


This is the first time I've felt happy I rarely upgrade.


I can't seem to reproduce it locally. 10.13.1… Anyone else having issues?

I've upgraded a through a couple versions of OS X on this machine - maybe that makes a difference?


It took 3 tries for me and then it worked.


Perhaps you have a root password set?


Worked fine for me on 10.13.1.


How come nobody has picked a name for this vulnerability?


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.



This is hilarious. I wonder why it took so long for this bug to be discovered, I mean, wasn't High Sierra released back in September?


Who types root in as a login name on a Mac?


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.


well, `sudo su root` would be using the user password for the logged in user, not for root. Does `su root` work, with no password at the prompt?


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`.


Works with "su - root" too in a Terminal.


I guess Apple aren't the kind of company that would do it, but I'd love to read a frank post mortem about how this happened.


I just tested this on a Sierra (10.12.6) machine, and verified this bug isn't present in that earlier OSX version.


Same, I'm on 10.12.6, could not reproduce anywhere.

I think I'll hold off on that 10.13.1 "security update" it keeps bugging me about. Seems to let anyone use my computer...

Edit: After looking a little further, it seems staying on Sierra will always be a 10.12.* version, and High Sierra is 10.13.*?


Yes, that's correct. Recent macOS (nee OS X) versions:

- Mavericks (10.9.x)

- Yosemite (10.10.x)

- El Capitan (10.11.x)

- Sierra (10.12.x)

- High Sierra (10.13.x)


They could have at least used "rms" instead of a blank password.

https://www.reddit.com/r/linux/comments/7hj6v/i_use_my_login...


Does this work from single user mode?


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.


Security update just came out. Installed it and can no longer reproduce. Can anyone confirm?


LOL. Can we call this...front door?


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.


I guess we finally figured out what the "insanely" great products was all about.


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... :(


Maybe NSA asked for an easy access. Apple is generally good at making things simple for users.


Time to install Afterdark on all the computers in the Apple store. Confirmed here, 10.13.1.


And I just googled afterdark at work... haha thanks!


This is near Windows-95 levels of bad - at the very least you need to already be logged in



How can one of the most wealthy companies on the planet, that every single software engineer would kill to work for, manage to have a bug like this?

Maybe they need to re-think their hiring process, because clearly something is not working as it should.


Apple proves they still care about UX: finally, I found a way to login without typing.


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.

https://en.m.wikipedia.org/wiki/Responsible_disclosure

https://support.apple.com/en-au/HT201220 (See ‘Security and privacy researchers’)


It's not irresponsible to make a bug public.

He did not put people at risk, he showed people they are already at risk, so they would know to set a root password, and thereby not be at risk.

Security by obscurity does not work!


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.

--

Further to previously provided examples:

https://www.cloudflare.com/disclosure/

https://access.redhat.com/security/team/contact

https://www.xenproject.org/security-policy.html

https://about.gitlab.com/disclosure/

https://help.github.com/articles/responsible-disclosure-of-s...

https://www.kernel.org/doc/html/v4.10/admin-guide/security-b...

https://www.drupal.org/drupal-security-team/general-informat...

https://www.cisco.com/c/en/us/about/security-center/security...

https://www.juniper.net/us/en/security/report-vulnerability/


> Citation needed.

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.


>> Citation needed.

> Has there been an update released yet? I wouldn't know, I don't use OS X.

I think you might have misunderstood what I meant when when asking for citation, it's based on the statement you made in relation to citing sources for what something that could be opinion stated as fact.

https://libguides.mit.edu/citing

> Is it a bad way? No!

OK this is where I stop feeding the troll.


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.


Yep, just saying that if he's not malicious (intending to maximize harm to users), then he's an idiot for disclosing it this way.


Or just didn't know what the best practice was.

Since this is a flaw any user can run into, I wouldn't get so mad about someone who doesn't know best practice running into it.

I am much more concerned that such an obvious tractable flaw exists in the first place.


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.


Imagine what Steve Jobs would've said in a meeting today at Apple HQ to discuss this incident.

"Can someone here explain to me what is the login dialog supposed to do? ... Ok. Then why the !@#% doesn't it do that???"


Press "command" and the "space" keys at the same time.

In the Spotlight Search type "Terminal" and press enter.

At the terminal type "passwd" and press enter.

The terminal will prompt you to change the password for "root".


You can just type root in the login window to get System administrator access.


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 was able to successfully fix this by using the

``` dsenableroot ```

utility; by first enabling the root user with a strong password, then disabling it with the

``` dsenableroot -d ```

option. It's heavily recommended to not leave the root user enabled.


I tried it anyway and it does not work! I'm running version 10.13.1


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.


Try one more time.


I asked this in the other thread, but... does anyone know how big of a bounty the guy missed by not disclosing this responsibly?

I'm guessing it probably would've been a fairly big chunk of change.


Apparently there is no macOS bug bounty: https://twitter.com/i0n1c/status/935608248027303936


The solution for now is to set a passwd for root... this is ridiculous


Has no one been running password crackers against OSX this whole time?


<sarcasm>"OSX the more secure OS because nobody tries to hack it, CONFIRMED."</sarcasm> ;)


The new Apple is the old Microsoft, and the new Microsoft is the old Apple.

After 8 months of living hell using their overpriced MacBook Pro, I'm moving to Surface Pro (running Xubuntu, though).


I didn't think the BSD's allowed a blank root password.


Well, if they don't then this is a clear indication of the improvements possible with closed-source software.

At least if it'd been open, maybe someone could have diffed it …



If I could just use Mavericks and develop apps for last iOS release, that will be great. But I should update to High Sierra. I hate this.

High Sierra seems to be focused in Emojis. Urghh


The only current solution is to leave root enabled and change the password to something strong until this is patched by Apple.

Disabling root re-enables the blank password to root.


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.


https://support.apple.com/en-us/HT204012

How to set root password.


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?


These bugs are getting ridiculous. With Apple's budget, finding such bugs in a security architecture review or just in QA should be as easy as 1+2+3.



Should I leave my Mac unattended until this is resolved?


Enable the root account and set a (obviously, strong) password for it. Keep calm and carry on.


You can keep using it.


I wonder when/what Apple's response will be


Even on El Capitan, I was able to unlock with "root" on my first try. From there, I could add a new admin user. This seems... not good.


I wasn't able to do it on 10.12.6 (Sierra) though, so perhaps there's something else odd here?


Doesn't work for me either on 10.12.6.


I cannot reproduce this on Sierra or El Cap


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)


Especially not good is Apple likely won't fix it in El Cap. They'll tell all of us to upgrade. I don't want that buggy HS mess.


When I tried to make a new user after unlocking as "root" it ended up making a group instead. (High Sierra 10.13.1)


The person who found this is at greatest risk. Public disclosure keeps him safe.

"Oh, good boy. Thanks for the responsible disclosure. You're sure you haven't told ANYONE else about this? Great! Keep it that way and we'll send you a big check real soon. Promise!"

Coordinates acquired.

Boom.

Keep in mind, Apple was caught working directly with NSA in Snowden disclosures. The US government will drone strike people outside the US without trial or charges. Apple illegally SWATed a Gizmodo reporter over a leaked iPhone prototype.

I don't blame this Turkish national, not one bit.


High Sierra has been one of the worst OSX upgrade.


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.


Anyone in a position to short AAPL? It's apparently 6bps up in after hours trading but that's very low liquidity.

https://finance.yahoo.com/quote/AAPL?p=AAPL

A higher risk, higher leverage bet: buy some put options the milisecond markets open:

http://www.nasdaq.com/symbol/aapl/option-chain


I would say I'm surprised such a serious bug made it out, but after the A � thing who knows what's going on at Apple


While this true, please keep in mind that rebooting your Mac into single user mode also allows anybody to login as root


Not if I use FileVault, surely?


You can set a firmware password to prevent this.


Does this bypass filesystem encryption?


It might, if you added "root" as a user able to unlock the disk. But you'd probably have needed to set a password for the root account to do that.


You have a valid user as far as the OS is concerned, so you'd be able to access encrypted files and copy them off of the machine.


Only if the laptop is locked (as the encryption key is already in memory).


Any chance that self clears after an interval?

Might be a bad day to leave the laptop at the table at the coffeeshop when ordering.


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.

[1] http://mattwashchuk.com/articles/2016/01/08/maximizing-filev...


If it does then it means Apple's encryption implementation is fucked.


On my system, the trick doesn't work. But then, I did explicitly set a non-empty root password.


While reading this, my mac just prompted me to Upgrade to High Sierra. I think I'll hold off...


Confirmed on 10.13. I was even able to add a user as an administrator after unlocking with root.


I'm unsurprised, loginwindow is a piece of shit nobody wants to work on. Poor dude.


People going on about responsible disclosure when this is such a gross violation of CUSSE: https://web.archive.org/web/20170712120031/http://www.cusse....


#whyidontupgrade

Until Apple forces me to with a required xCode update for the newest iOS SDK...>.>


To block this, set a random password for root:

sudo dscl . -passwd /Users/root $(uuidgen)


Good thing I haven't updated yet. I wonder how many machines are vulnerable?


patch has been released in record time, I have update my mac

https://support.apple.com/en-in/HT208315


Does this effect people who already have a root user with a password set up?


No


No.


This clearly is a feature!


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.


workaround: ENABLE ROOT USER AS FAST AS POSSIBLE

https://support.apple.com/en-us/HT204012


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.


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.


Isn't the best practice full disclosure? It seems like it was followed well.


Sure, now look at his Twitter account. He looks pretty plugged into the software community.

Agile Software Craftsman, iyzicoder @ http://www.iyzico.com , Founder of Software Craftsmanship Turkey @scturkey, The community guy http://bit.ly/lemiorhan


Yes. And from his personal site [http://www.lemiorhanergin.com/]:

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.


Maybe. Look at his twitter page though: https://twitter.com/lemiorhan

Not impossible to believe he's unaware of the right way of handling this kind of issue, but that banner photo (Enthralling My F-ing Audience) [1] and stats there suggest he should be aware that there probably are sensible and polite procedures for this, even if he didn't immediately know what they were.

[1] http://jesuschristsiliconvalley-blog.tumblr.com/post/4653787...


How do the banner or stats suggest he should have known about this?


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.


Are you proposing that being an active programmer implies familiarity with responsible disclosure? That doesn't follow in my mind.


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.

Agile Software Craftsman, iyzicoder @ http://www.iyzico.com , Founder of Software Craftsmanship Turkey @scturkey, The community guy http://bit.ly/lemiorhan


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.


It seems like every programmer on HN is also deeply interested in security, but I don't think that's generally true elsewhere.


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.


Apple doesn't pay bounties for this sort of report, even if direct to their team. They have a private bounty program, for a select few.


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?


this is too serious to hide. better to tell users how to fix it than wait until apple releases something


That's not how responsible disclosure works.


But it's how full disclosure works which is more responsible then coordinated disclosure.


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?


I think it is only a local exploit. The bigger risk are the Macs in schools and libraries.


Doesn't matter, Apple gets an automatic pass.


Wow, setting a root password seems to fix this...


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.


Wow. Can't believe it. It's true.


Worked for me on the second try (10.13.1)


root is disabled by default. The first try, somehow, enables it with no password. The second try will let you in.


There is also now a patch available.


Serious 0-day on Twitter. How exciting!


There's no way this wasn't being used prior to being publicized on twitter. I'm sure the FBI/etc was on this day one.


In what version did the issue appear?


we've seen it only in 10.13.1 (17B48) so far


It also works on 10.13 (17A365)


I can confirm that, too. Took 2 attempts.


This is why I use disk encryption.


When you're too busy as a company making sure the corners of your products are sufficiently rounded, you get things like this.


Apple is the new Internet Explorer


Is this also in 10.13.2 beta?


Does it affect MacOS Server?


Confirmed here on 10.13


*macOS High Sierra


verified on latest build of 10.13.1 (17B48).


But there are new emojis, and emoji karaoke works!


Not cool to disclose this kind of bug on Twitter.


I miss Snow Leopard.

:/


1


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.)

https://en.wikipedia.org/wiki/Pyramid_Technology

Here's the email in which I reported it to the staff mailing list.

    Date: Tue, 30 Sep 86 03:53:12 EDT
    From: Don Hopkins <don@brillig.umd.edu>
    Message-Id: <8609300753.AA22574@brillig.umd.edu>
    To: chris@mimsy.umd.edu, staff@mimsy.umd.edu,
            Pete "Gymble Roulette" Cottrell <pete@mimsy.umd.edu>
    In-Reply-To: Chris Torek's message of Mon, 29 Sep 86 22:57:57 EDT
    Subject: stranger and stranger and stranger and stranger and stranger

       Date: Mon, 29 Sep 86 22:57:57 EDT
       From: Chris Torek <chris@mimsy.umd.edu>

       Gymble has been `upgraded'.

       Pyramid's new login program requires that every account have a
       password.

       The remote login system works by having special, password-less
       accounts.

       Fun.

    Pyramid's has obviously put a WHOLE lot of thought into their nifty
    security measures in the new release. 

    Is it only half installed, or what? I can't find much in the way of
    sources. /usr/src (on the ucb side of the universe at lease) is quite
    sparse. 

    On gymble, if there is a stray newline at the end of /etc/passwd, the
    next time passwd is run, a nasty little "::0:0:::" entry gets added on
    that line! [Ye Olde Standard Unix "passwd" Bug That MUST Have Been Put
    There On Purpose.] So I tacked a newline onto the end with vipw to see
    how much fun I could have with this....

    One effect is that I got a root shell by typing:

    % su ""

    But that's not nearly as bad as the effect of typing:

    % rlogin gymble -l ""

    All I typed after that was <cr>:

    you don't hasword: New passhoose one new
    word: <cr>
    se a lonNew passger password.
    word: <cr>
    se a lonNew password:ger password.
    <cr>
    Please use a longer password.
    Password: <cr>
    Retype new password: <cr>
    Connection closed

    Yes, it was quite garbled for me, too: you're not seeing things, or on
    ttyh4. I tried it several times, and it was still garbled. But I'm not
    EVEN going to complain about it being garbled, though, for three
    reasons: 1) It's the effect of a brand new Pyramid "feature", and
    being used to their software releases, it seems only trivial cosmetic,
    comparitivly.  2) I want to be able to get to sleep tonight, so I'm
    just going to pretend it didn't happen. 3) There are PLEANTY of things
    to complain about that are much much much worse. [My guess, though,
    would be that something is writing to /dev/tty one way, and something
    else isn't.]  Except for this sentence, I will also completely ignore
    the fact that it closed the connection after setting the password, in
    a generous fit of compassion for overworked programmers with
    ridiculous deadlines.

    So then there was an entry in /etc/passwd where the ::0:0::: had been:

    :7h37OHz9Ww/oY:0:0:::

    i.e., it let me insist upon a password it thought was too short by
    repeating it. (A somewhat undocumented feature of the passwd program.)
    ("That's not a bug, it's a feature!")

    Then instead of recognizing an empty string as meaning no password,
    and clearing out the field like it should, it encrypted the null
    string and stuck it there. PRETTY CHEEZY, PYRAMID!!!! That means
    grepping for entries in /etc/passwd that have null strings in the
    password field will NOT necessarily find all accounts with no
    password. 

    So just because I was enjoying myself so much, I once again did:

    % rlogin gymble -l ""

    Password: <cr>
    [ message of the day et all ]
    #

    Wham, bam, thank you man! Instead of letting me in without prompting
    for a password [like it should, according to everyone but pyramid], or
    not allowing a null password and insisting I change it [like it
    shouldn't, according to everyone but pyramid], it asked for a
    password. I hit return, and sure enough the encrypted null string
    matched what was in the passwd entry. It was quite difficult to resist
    the temptation of deleting everyone's files and trashing the root
    partition.

        -Don

    P.S.: First one to forward this to Pyramid is a turd.
P.P.S.: The origin story of Pete's "Gymble Roulette" nick-name is here: http://art.net/~hopkins/Don/text/gymble-roulette.html The postscript comment was an oblique reference to the fact that I'd previously gotten in trouble for forwarding Pete's hilarious "Gymble Roulette" email to a mailing list and somehow it found its was back to Pyramid. In my defense, he did say "Tell your friends and loved ones.")


But someone at Apple got their bonus for shipping the animated poop icon in time for this release.


If you think the team that makes animojis is the same team in charge of security or QA, I have news for you.


If you think Apple's management aren't 100% responsible for what people and budget is allocated to each team, I have news for you too...


At this point, I'm not so sure.


kk


Apple makes it pretty easy to report vulnerabilities to:

product-security@apple.com

They also respond to security@apple.com but prefer the product-security address.

Further, there are any number of legit bug bounty programs out there like ZDI that would pay for a bug like this then immediately disclose to Apple for it to be fixed.

Disclosing an 0Day root authentication bypass vulnerability on Twitter isn't cool, even if it is local: think of the impact to shared iMacs on university campuses.


I really disagree - this needs to be reported as much as possible publicly to create a huge thunderstorm of negative publicity for Apple.

This isn't the first extremely serious and dumb High Sierra password bug this year [1] [2], and unless Apple is severely hurt by it, so they're forced to change, it won't be the last. High Sierra is full of bugs and seemingly not just annoying bugs, but also security bugs.

Let's hope Apple gets sued for the damage they'll cause by including this bug in High Sierra so they make sure that next release of macOS won't be another bug filled mess.

[1] https://arstechnica.com/information-technology/2017/09/passw...

[2] https://www.macrumors.com/2017/10/05/macos-high-sierra-disk-...


Responsible disclosure does not prevent negative publicity. It provides the vendor with a grace period during which they can fix the vulnerability. There can be plenty of negative publicity once the vulnerability is patched and publicly disclosed.

Encouraging irresponsible disclosure because one wants to see Apple hurt is a reckless and selfish attitude because it puts millions of Apple customers at risk in the process.


Closed disclosure does, to a large degree, prevent negative publicity. I don't think it is in dispute that this bug would receive vastly less media coverage if it were only revealed as a bug in outdated/patched versions of the OS.

I don't want to see Apple hurt (I'm an Apple-guy myself, using Macs, iPhone, iPad and Apple Watch), I want to see them improve. I doubt they start will start caring about QA unless they're forced to.

One absurdly serious and stupid password bug like this can be a honest mistake, but three (that we know of, that were full disclosures) in a few months is negligence that should be criminal if it isn't.


Closed disclosure is responsible disclosure. Moving past the terminology, I am an Apple user as well, I am pretty satisfied with how quickly Apple resolves issues.

Now if every person started disclosing vulnerabilities via twitter without giving the company turn around time to resolve the issue based on their dissatisfaction with Apple based on standards they came up with personally, I don’t think it is nice or fair.


So, obscurity is responsible disclosure? Cause being "closed disclosure" is being obscure.

A root password solves this issue. Its seconds to implement and helps right now.... Not "later" as closed disclosure does.

I'd rather know every error and critical bug. I can bring up with our team and decide now to either sudo service * stop or continue.

Your closed options keep the fact I'm vulnerable away, along with any pathways I might have to fix.


This is a rather limited view point. You forget the majority of macOS users are NOT technically savy. This is why responsible disclosure is so important as it gives tech companies time to create and push a fix to protect their users.

Disclosing this immediately puts those people who can't setup enable the root and set its password into more harm's way.


> Disclosing this immediately puts those people who can't setup enable the root and set its password into more harm's way.

Let's be clear - Apple put their users in harms way by letting a bug of this nature slip past testing. Disclosing "responsibly" would certainly be nicer to users, but mostly it would be nice for Apple by helping mitigate the bad publicity.


Apple isn't the first company to have security bugs. Is this how all 0days are to be reported?


> You forget the majority of users are NOT technically savy.

Fixed that for you.

Sorry, I'm not going to cater to the lowest common denominator of "users". If my system has a hole, I want to know so I can get in a fix or shut down that particular feature until its fixed by a vendor.

Ive only 60k machines and 40 clients that depend on that decision. And they agree with me. If something's broke, I can analyse how it breaks and if it impacts us. If it does, we can triage it. I can do a damage assessment. I certainly can't do that if it's being sold on the darknets and whispered.


> I want to know so I can get in a fix or shut down that particular feature until its fixed by a vendor.

That assumes you can shut down that particular feature without crippling your business operations. If my system had a hole, I'd prefer that it were disclosed to the vendor before it's disclosed to hackers, adversaries and foreign governments.


So, if if find a security bug with your product, you prefer that I publish it directly to twitter as a 0-day?


Yes. Ideally you would also ping me in your public release, so I know whom to pay. Because that would also for be the users benefit to know to either fix, firewall, or not use until software is deployed.

I've seen the dark side where this leads. It leads to BTC transactions and 0days bought and sold. That's the worst, further past scrappy company sitting on exploits.

I strongly believe in transparency. It empowers users and admins more than any other option out there.


I think the responsible way to handle it is, you inform Apple in a closed way. Once they come up with a fix, if you think they didn’t come up with a fix soon enough, make that information public then on how long it took Apple to turn this around. Disclosing every vulnerability to the internet and setting their ass on fire is not a good way to solve this IMO.


Obscurity is not long-term security, but it can buy you a bit of time to get a fix released and pushed out to users.


I actually do think it is in dispute. This is a tweet after all. This guy could totally tweet about it in much the same way after Apple released a patch. The negative publicity would still exist because the bug would be equally stupid and disastrous, just fewer people would be harmed along the way.


It wouldn't be as clear that the bug is widely reproducible after the patch is put out. And it certainly wouldn't gather as much attention.


Exactly. Everyone I know on Mac immediately tried reproducing this bug the moment they heard about it. On those systems where it didn't reproduce, they immediately dismissed it as a false report.


That is assuming people patch their Mac ASAP. It will still be on high alert for most media if they have disclose it few days after the bug was fixed.


Giving Apple negative publicity is not an end that justifies harming its users.


A bug like 'can log in with password "root"/""' just isn't going to get you a grace period no matter what security researchers might want.

I mean, this bugs has been reported already - by every cheesy hacking movie ever, by every beginners book on social engineering and so-forth. Heck, it was "reported" by Richard Feynman talking about cracking safes during the Manhattan.


Grub's "backspace 28 times to a rescue shell" was also a stupid one, but it first got fixed, and then made it to the news.


This reminds me of jwz's XScreenSaver rant.

https://www.jwz.org/xscreensaver/toolkits.html


FYI...that's currently forwarding to a very NSFW image.


Huh. It's only doing that if you go there from HackerNews. He must have a rule that checks the http-referrer O_o


Whoa. Not my intention. But I can't edit my original comment.


It only forwards if the referrer is HN.


A kiwi is nsfw?


Yes it is. But being a brilliant brogrammer, I figured out how to view the link.


It's not hard to make it work, but for those of us at work it's nice to have a warning that we shouldn't just blindly click it.

That said, I wouldn't visit jwz's blog at work anyway.


Pretty sure every cheesy hacker film doesn't have the root password being empty. They usually put in "password" or the favourite music band of the target.


Not the attitude of the people reporting the issue have put "millions of apple customers" at risk, but the company which allowed to let issues like this one slip through their Q&A process.

IMO, this behaviour is part of the problem, the reason why tech companies take security only on a superfiscial level seriously.

Don't kill the Messenger.


I think this incorrectly interprets my comment. I am not defending apple or blaming the individual that disclosed the vulnerability on Twitter. I am simply pointing out that putting users at additional risk because you want to see Apple hurt may be misguided. We have responsible disclosures in place for a reason.

EDIT: putting users at _additional_ risk


They were already at risk.


Making an exploit widely known increases the risk dramatically.


No... I immediately set a root password, if this had not been posted I would be far more at risk.


Maybe you personally are at less risk, but the population as a whole is at greater risk.


I'm now seeing cases of non technical people trying this because they heard about it and it's easy. To them, it just unlocks some system preferences thing. Guess what those people are not doing after they try it? 'passwd root' to change the password because in many cases they don't even know what the terminal is.

In this particular case, the ease of validation additionally works against users.


I do get the impression that you do blame the individual, as you have attributed unsavory motivations to his behavior. Why do you care to make such a loose statement about this person having a petty motive of malice?


One of the grandparent posts specifically said they supported the tweet because it would hurt Apple, and I think bradrydzewski is responding to those comments.


I dont understand the implied correlation between, what you call, irresponsible disclosure and "wanting to hurt apple". Where did you get this impression from?

edit: Typo.


> Let's hope Apple gets sued ...


Thanks, you are right. If he refers this post (which i believe he does), he is indeed right.

Anyhow, personally i wouldn't exclude something like this, e.g. suing, as a last resort. Anything that changes apples attitude towards security or at the very least, enhancing the value of security as a product qualifier.


And Full disclosure is about protecting users of a software, not letting the vendor off the hook. Here, the hack and the fix are so trivial the responsible thing to do is to publicly call out Apple for its lack of QA and warn users directly. It affects everybody who runs High Sierra.

> it puts millions of Apple customers at risk in the process.

Nah, it's Apple which put millions of customers at risk, not the person who disclosed the vulnerability. let's not shift away the blame from the guilty here.

Apple one of the richest company in the world is obviously just cutting corners in QA here. This is unacceptable.

it's seems some people here are more concerned about negative publicity than user security. This is a pattern that have been seen countless times in big tech corporations(such as Yahoo), not disclosing hacks that put their users and their data at risk. This is unacceptable for a company that claims to be all about their users.


I would argue that releasing this vulnerability as irresponsibly as he did is showing he cares more about negative publicity than user security.

Yes, it's Apple's fault for poor QA that this was released, but this guy also put users at risk by telling the entire world about it without giving Apple a chance to fix it.

You're right, it's about user security before publicity. So make sure users are safe first.


"as irresponsibly as he did" is how all vulnerabilities were announced, at one time. I miss those days, personally.

Nowadays, you're "irresponsible" if you don't follow some vendor's own made up procedures.


You can follow your own procedures - decide for yourself how long you think it is reasonable for the company to mitigate in private. But give the company some time.


Why? You're not an employee, you're a concerned citizen. You havr no obligations to vendors whatsoever. Now, I think it's nice to do responsible disclosure, and I certainly don't envy the people whose week has been ruined, but the discoverer of this bug did nothing wrong.


It is about the increased risk fellow users will have due to this style of disclosure. Who cares about the vendor, but they are best situated to resolve the issue quickly for everyone.


> Nah, it's Apple which put millions of customers at risk, not the person who disclosed the vulnerability. let's not shift away the blame from the guilty here.

Disclosing 0day vulnerability via Twitter for the sake of self promotion is bad. Especially when you advertise yourself as a software developer.


The defense will stem primarily from users invested in the Apple ecosystem. If anything that is very concerning on its own.


This is such a lame vulnerability that it's probably already known to competent attackers.

It's not a bug; it's a bad design decision. How to initialize the root password on a new machine is a hard problem in a consumer environment. Some people will set it, lose it, and then want support to fix it. One would expect some clever Apple solution, such as initializing the password to random letters and providing the buyer with that info on a scratch-off card. That way, the buyer can be sure no one has seen the password before they use the scratch-off card.

Setting it to null? That means nobody thought about the problem.


> Encouraging irresponsible disclosure because one wants to see Apple hurt is a reckless and selfish attitude because it puts millions of Apple customers at risk in the process.

Apple put millions of their customers at risk by skimping on QA. As an Apple user I'm OK with this getting out if it motivates Apple to improve their approach in the future.


There is nothing irresponsible about disclosing huge vulnerabilities in software by any means necessary.

Edit: as usual, downvotes but no response. I miss when this place was decent.


> as usual, downvotes but no response

The very comment you are replying do lists a reason why disclosing huge vulnerabilities without providing upstream time to patch is irresponsible: "because it puts millions of Apple customers at risk in the process."

Your comment doesn't refute the reasoning the comment you are replying to provides, and it also doesn't tell us anything about why you think "There is nothing irresponsible about disclosing huge vulnerabilities in software by any means necessary." You state your position, but offer no rationale, no reason for it; why should I accept your position as the correct or ethical thing to do?


Why not? The end goal is protecting users. If disclosing a vulnerability before a company has a chance to fix it puts more users at risk than waiting how is that not irresponsible?


Considering the vulnerability was supposedly brought to Apple's attention a month earlier via the "proper" channels, and considering Apple's history of repeatedly ignoring and dismissing said disclosures, I'd say this was the only correct action to take.


I think there's a middle ground to this. Submit your report to Apple security, allow them time to develop a patch, and then in a week go ahead and tweet at the big media outlets about it.

I'm a die-hard Apple user myself, but I agree that the long list of severe bugs in High Sierra is absurd, and a big public backlash might be enough to kick them into gear. On the other hand, I, a university student with next to no understanding of computer security, can simply walk onto campus, sit down at a Mac, and within seconds have complete access to the computer. It's ridiculous, it's horrendous that it shipped like this, but it's not something that needed to get out, especially something so easy to utilize.


The fact that you as the ordinary student can become root and create a lot of damage so easily is the only reason the public will care.

Us geeks have been complaining about the horrible QA in macOS for years, yet nothing has been done. The fact that this is so simple to do will probably/hopefully get ordinary people to start talking about it too ("Hey, have you heard that you can hack Macs without a password? Very insecure"), which would force Apple to improve.


It sounds to me like you're arguing that full disclosure in this situation could lead to a worse outcome for users in the short term, but the negative publicity will force Apple to improve their security posture, leading to a better outcome for users in the long term. (Please let me know if I'm miss-characterizing your argument)

I think you have to be very careful about that line of argument. It's a single vulnerability researcher making a unilateral decision about the short term and long term security of an entire user base, based entirely on personal judgement. I personally think the researcher should make the decision that best protects users from that specific vulnerability. Making long-term changes to a company's QA should come second.


> I personally think the researcher should make the decision that best protects users from that specific vulnerability.

I find it odd that you're putting the responsibility of making decisions about how to protect Apple's users on an unaffiliated third party.

Apple has a multi-hundred-billion dollar war chest and, if they wanted to, could afford to make macOS the most secure operating system on the market. The fact that they don't is their own choice and a reflection of their priorities, not some act of God or a natural disaster. Putting the onus for cleaning up the mess in the most "responsible" way possible on third parties with a fraction of Apple's resources is being too kind to Apple.


My point was exactly the opposite of putting the onus on the researcher. I support responsible disclosure. In responsible disclosure, the researcher informs the vendor (Apple) and leaves it to them to coordinate informing people of mitigations and pushing out a patch. If the vendor fails to respond or make progress in a certain period of time, the researcher can inform the public. It specifically puts the responsibility for dealing with the vulnerability in the hands of the vendor.


I think only economic consequences would cause Apple to up its QA game. Like decreased sales or lawsuits with good prospects of winning serious money.

Unfortunately, I don't believe those will happen.


Maybe it's crazy that we give people physical access to machines and expect them not to be able to obtain root.

I don't have any experience with enterprise-grade IT, but it seems like shared computers should be thin clients or at least use UEFI to securely boot an image over the network and not keep anything sensitive locally.

If you give someone physical access to a box, they will be able to own it.


This is actually how the public workstations in MIT computer clusters have always worked. The root password is public to anyone with a legit account, but access to it gets you almost nothing because all services including the network filesystem are kerberized, and machines are really good at wiping all local changes upon logout. Some more details here: https://www.quora.com/Are-computer-networks-in-MIT-harder-to...


yes. physical access should never be considered secure.


> On the other hand, I, a university student with next to no understanding of computer security, can simply walk onto campus, sit down at a Mac, and within seconds have complete access to the computer.

its educational for the end user. You cannot trust Apple. Good reminder there are other OS available out there.


I'm more concerned that the "exploit" works "after a few tries" and not the first-time-every-time, or not at all.

One would think that something as simple as a login would be deterministic.


My understanding is that the first attempt is creating/enabling the root account with a blank password and that the subsequent login is actually utilizing it (which is kind of bizarre and probably why this was missed in testing).


The first time I tried it, it just worked. I'm certain I've used root before. On the GUI portion it works with no password, but on the terminal it does not let me login as root without a password. Some weird OS magic must be going on there?


AFAIK usually sudo doesn't let you enter an empty string as a password, even when the actual password is empty. So that is what you might be experiencing.


it worked for me on 6th try or so. First few times, the prompt was returning to my user name, but then another failed attempt left it at 'root', and the next attempt succeeded


Does this user have admin privileges? root != admin on macOS if I recall correctly.


root IS an admin in macOS. You just cannot use root the same way you expect root to work in other Unix OS' without changing stuff in the BIOS (or whatever it's called for Apple) but you can still do most admin things with root. However root does get admin privileges, but when it comes to some system directories he is banned till you "fix" root privileges.

Edit:

See: https://stackoverflow.com/a/33272796 for a bit more information of what I mean.


Thank you, I was wrong.


It's fine, by my own definition, that isn't a true root user... It ruins everything I've come to expect from using root.


Don't forget the Disk Utility password disclosure! https://www.macrumors.com/2017/10/05/macos-high-sierra-disk-...


Thanks, added!


Why does it need to create a lot of negative publicity for Apple? Is there something you don't like about them? Responsible disclosure needs to be valued given the number of macs out there in the wild that could potentially be susceptible to issues like this, and the impact it could have on people (including you) not just directly but indirectly.

How would you feel if someone discovered a 0day at a company that exposes credit card and identity info, published the 0day, then hackers steal all that info (including yours)? I'm sure 'creating a thunderstorm of negative publicity' would be the last thing you would want.


> Is there something you don't like about them?

You mean, in addition to bad QA and complete disregard for their users' security? And being the richest and most profitable company ever, cutting corners and evading taxes?

Their response on Twitter was amazing: "PM us so we can discuss this privately", not "thank you, we're looking into it NOW".


I suspect the response on Twitter was a typical reply from a tier 0 support person. No reason to extrapolate from that to the company's internal response.

Apple is a Rorschach test writ large. What people see in it reflects more on the observer than the company in many cases.


I don’t see it as either/or. You can disclose responsibly, and go for publicity once the fix is in circulation. Responsible disclosure is nothing to do with protecting Apple, it’s about protecting the users.


The problem is that this is not a zero day in new technology. They made a jr sysadmin mistake. As a company who wants a reputation for good security, that is not acceptable.


Do "responsbile disclosure" rules apply differently to Apple?

If so, why? How do you identify companies like Apple that get one set of rules to other companies?


This is extremely naive.

Yes Apple shouldn't be having this issue but disclosing a 0-day issue can possibly hurt users far worse than hurting Apple. Apple may lose a tiny bit of money but users could lose far, far more especially if someone develops a good way to remotely deploy / take advantage of this defect.

Ignoring responsible disclosure also limits the ability to sue them for any damage resulting from it (or so I'm told by one of my lawyer friends who thinks this disclosure may make it almost impossible to successfully sue them over it unless it simply takes them too long to fix).


You could let them know about the vulnerability and wait until it's been patched before commenting, with some timeout where if they don't patch in a reasonable amount of time you announce it anyway.


>Let's hope Apple gets sued for the damage

How can that happen in any case ? Isn't pretty much the first line in every license waiving of liability ? Unless you have some special contract with Apple that overrides other standard boxes that you ticked, how would anyone sue ?


Zero-day disclosures aren't about negative publicity in order to prevent problems further down the road some time in the distant future.

It's about protecting systems RIGHT NOW from immediately causing harm to people's lives.


I agree.

https://www.eff.org/deeplinks/2017/10/drms-dead-canary-how-w...

Blame the DMCA. This guy is in Turkey - does GP really think he can expect fair treatment and equal compensation as a "western world" security researcher?


There's no reason why the person who discovered the bug would be safer publishing the vulnerability on Twitter than disclosing it to Apple directly. If nothing else, they could always post it on Twitter later. The link to the DMCA is a digression.


How does him being from Turkey matter in this case?


It's the neighborly thing to do, but people are under no obligation to report vulns privately. The blame lies squarely on Apple, not on the messenger.

The fact that we know about it means we can take steps to mitigate the damage.


The blame lies squarely on Apple, not on the messenger.

There is blame on both.

If you leave your key in your front door lock and I blast out on twitter your address and tell people about it, I think I have some responsibility.


If you leave keys in other people's doors all over the neighbourhood, I damn well have a rigtht, and possibly an obligation, to make it publicly known that such a thing is taking place. So that everyone may take their own precautions.


Let's say keys were hidden around the neighborhood. Would you rather everyone in the whole town know about it or quietly and quickly go pick up all the keys before someone notices and breaks into one of the houses?

Personally I think if you report through the proper channels and nothing is changed THEN broadcast, but not as an opener.


These keys aren't exactly hidden. This is like trying the doorknob a second time.


In determining whether keys-in-locks or keys-under-doormats is the closer analogy, I have to go with the doormats. Various people go door-to-door... delivery people, campaign volunteers, Jehovah's Witnesses, etc. and a key in the lock would be hard to miss. A key under a doormat is easy to miss, being obscure. Sure -- the doormat is one of the first places you look if you're actually trying to break in, but people whose nefarious side doesn't manifest until the opportunity is obvious are indeed thwarted by that obscurity.


I am going to ask, do you want to try this scenario on your own in real life? Because often we make general statements while we don’t actually practice what we say to others when the issue is going to hurt ourselves.


We all live with this scenario everyday, most consumer locks are ridiculously easy to open. https://en.wikipedia.org/wiki/Lock_bumping


But do YOU want to have your good neighbor report to tou that your key has been left on the poach before someone takes it away and then get into the house when you are away from home on Thanksgiving night celebrating a nice holiday vacation? I bet you not. The fault is on you for dropping the key, isn’t it? Or you are so bluntly careless to have a backup key left under the mat on your poach which slided away and the key is now revealed.

The fact locks are easy to pick doesn’t mean people don’t take more measures to defend it. More and more people install steel door as an extra layer and home security surveillance system, all of which can be compromised with the right tools.

Responsible disclosure is something I respect. While he has the right to not disclose this privately first, has he tried? How hard is it to ask someone to get in contact with the Apple security team? There are a bunch of top sec researchers on Twitter constantly tweeting) to help escalate this. I think someone on Google zero project team did this to escalate.


A better analogy would be "if the lending bank left the door to your new house open..."

Other than buy an Apple product, the users did nothing intentional to undermine security.

Since this is a subjective argument, based more on historical instances of "responsible disclosure" and not law, I'm gonna lean in this case of it being Apple that failed

They built the entire "walled garden" without getting outside help. They want the control, they have billions of dollars, can hire whatever talent...

Failed to spot a password-less root login issue.

People need to know today to be even more cautious about using Apple gear in public places or around plain ol' tech jerks that like to fuck with people for a gag.

Society has no legal or moral obligation to make sure Apple stays in business.


Exactly.

Responsible disclosure is an interesting concept. How does this kind of disclosure make sure that the public knows about a company's track record of vulnerabilities, if everyone is under NDA and the company has no obligation to ever publicize it?

Now, if the reseacher could give a grace period, that's cool, but there MUST be a deadline by which stuff goes public. Hopefully the company fixes it and issues a postmortem first. If not - too bad!


The problem with that analogy is that the probability that the "bad guys" already know about this vulnerability is vastly higher than the probability that thieves know about how well some random house in the neighborhood is secured.


But do they? And what portion of them do? And are they using it? There's a lot of speculation here. But surely the average person doesn't know and with this being public knowledge, AND easy to execute there is a bigger chance for crime of opportunity.


It’s always reasonable to assume that black-hats (and… what do you call government hackers — black-suits, helicopter-hats, ???) know everything that white-hats know, and that they either have or are already in the process of selling that exploit to less skilled criminals.

It’s not like being good morally correlates with being good at security.


But that's not what I'm saying. I'm saying that since this is so easy, a person that is computer illiterate can now gain root access. You definitely don't post those kinds of things on Twitter.


Computer illiterate people might now have a new way to shoot themselves in the foot, they won’t be able to exploit it because they won’t know what root is or why it does stuff.


How many more people now know about this vulnerability cause of this knuckle-head tweeting it? At least 100k impressions? Now think of how many more "bad guys" have access to this hack that are going to abuse it.


And how many people and companies are now empowered to fix this issue for themselves, immediately.


Not immediately.


You may say so, but really the level of incompetence of not setting a password for a root account is pretty high. The fact that someone reported it in a way you don't agree with shouldn't distract you from the fact that this highlights a serious oversight.

The main question that should be asked is, how did this get overlooked? How is it that your average website has better password security than the OS of one of the richest tech companies in the world?

To be fair to Apple, Microsoft had similar issues back in the 1990s. Perhaps it takes a string of security blunders for some tech companies to take security seriously.


If you sell locks and those locks can be opened by pulling on them twice, the reasonnable course of action is to make that fact known to every buyer ASAP, not tell you privately and wait for you to maybe issue a recall.


Locks don't nag you to decommission them quite as aggressively as OS X asks you to patch it. And an OS update was going to happen anyway, so including this patch doesn't really burden the user with an extra task they wouldn't already be subject to. Therefore, coordinated disclosure has a lot of value in the OS update ecosystem and very little in the physical lock ecosystem.


Wrong. This is Apple -- not the homeowners -- leaving everyone's key in everyone's door without them knowing.


Responsible Disclosure is widely regarded as a good practice in these situations. Blame isn't the key issue - fixing the problem quickly and safely is. Widespread disclosure before Apple have even a chance to respond in a timely fashion is inherently unsafe.

You would hope the self-described twitter bio "Agile Software Craftsman" might have thought about this a little before tweeting.

> https://en.wikipedia.org/wiki/Responsible_disclosure


The poster practiced Full Disclosure, which is also a valid disclosure policy.

Since we're just making up statements, I guarantee that Apple would never voluntarily disclose this issue if it was reported privately. So Full Disclosure is the only way to put Apple's feet to the fire, as it's the only way in which this issue would have had any visibility whatsoever.

https://en.wikipedia.org/wiki/Full_disclosure_(computer_secu...


Private Disclosure does not prevent you from publicly disclosing it after a grace period.


What grace period is appropriate for a 0 day root login vulnerability?

This guy is, with all probability, not the first one to have found it.


If there was a vulnerability that allowed anyone to open your car and drive off with it, you wouldn't care if he was the first to find it or not. You'd only care about it getting fixed before anyone else knows about it.

I'm not sure what length grace period is appropriate, though.


If there was a vulnerability that allowed anyone to open my car, I'd want to known ASAP, because I wouldn't trust the manufacturer to provide a remedy quickly enough that eliminates my risk.

Same applies for Apple. No reason to believe this guy was the first one to find this exploit, we only know he was the first one to publicize it.