macOS High Sierra: Anyone can login as "root" with empty password - <AUTHOR> https://twitter.com/lemiorhan/status/935578694541770752 <comment><USER3> 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.

<comment><USER4> 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

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

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

<comment><USER7> I'm confused, why do you have to escape an asterisk?

<comment><USER8> Famous last words of a Roman centurion.

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

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> 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.

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

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

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

<comment><USER12> 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/](http://www.hughski.com/)

<comment><USER14> 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/](https://displaycal.net/)

</comment></comment></comment></comment></comment></comment><comment><USER15> 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](https://forums.developer.apple.com/thread/79235)

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

<comment><USER16> That's absolutely terrible. Does Apple not monitor those forums at all?

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

<comment><USER18> Those are the support forums, GP is asking about developer forums.

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

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

</comment></comment></comment></comment></comment><comment><USER20> 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?

<comment><USER21> 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](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.

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

<comment><USER23> 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?

</comment></comment></comment></comment><comment><USER24> 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](https://twitter.com/a_hailes/status/935601901839806464)

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

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

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

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

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

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

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

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER29> Apple uses the slogan for High Sierra: "Your Mac. Elevated."

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

</comment><comment><USER30> 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.

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

<comment><USER32> Not according to this video:

[https://www.youtube.com/watch?v=FpOH0lxEGBE](https://www.youtube.com/watch?v=FpOH0lxEGBE)

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

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

</comment></comment></comment></comment><comment><USER34> " _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://forums.developer.apple.com/thread/79235) _"

[https://twitter.com/fristle/status/935670476214378496](https://twitter.com/fristle/status/935670476214378496)

</comment><comment><USER35> 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?

<comment><USER36> 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...](https://medium.com/backchannel/what-i-saw-inside-apple-s-top-secret- input-lab-6637e2e5492e)

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

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

</comment></comment></comment></comment><comment><USER39> 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.

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

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

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

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

</comment></comment></comment></comment></comment><comment><USER43> 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](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."

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

<comment><USER45> 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](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](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.

</comment></comment></comment><comment><USER46> 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.

<comment><USER47> Once the fix for this issue is out, you _should_ disable the root user.

</comment></comment><comment><USER48> 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.

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

</comment></comment><comment><USER50> 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.

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

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

</comment></comment></comment><comment><USER53> 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.

<comment><USER54> These are the contents of the file, after converting them from binary plist to plain xml: [https://gist.github.com/shoghicp/2b529b54b9d70daf192b68e3564...](https://gist.github.com/shoghicp/2b529b54b9d70daf192b68e3564b3f4f)

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

</comment></comment></comment><comment><USER55> 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

<comment><USER56> > click the lock and enter your password

or just enter root with no password

<comment><USER55> Ha, ya. That way you know it's still needed!

</comment></comment></comment><comment><USER57> 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.

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

</comment></comment><comment><USER59> 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.

</comment><comment><USER60> 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](https://forums.developer.apple.com/thread/60763)

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

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

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

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

</comment></comment></comment></comment></comment><comment><USER64> 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](https://forums.developer.apple.com/thread/79235)

Screenshot. [http://oi67.tinypic.com/2h6embp.jpg](http://oi67.tinypic.com/2h6embp.jpg)

</comment><comment><USER65> 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.

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

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

<comment><USER67> Nothing wrong with incremental upgrades.

<comment><USER65> 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...](https://twitter.com/thomasfuchs/status/907764896829452288/photo/1)

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

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

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

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER68> Fix this by setting a password for root (or disable).

Instructions here: [https://support.apple.com/en- us/HT204012](https://support.apple.com/en-us/HT204012)

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

<comment><USER70> Yeah, confirmed it myself too. Enable root with a strong password works though.

</comment></comment></comment><comment><USER71> 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.

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

<comment><USER71> There're a lot of attendees from a lot of companies, they can be vulnerable.

</comment></comment></comment><comment><USER73> 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.

<comment><USER69> Once you disable the root account you can log in without a password again :/

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

</comment></comment></comment><comment><USER74> 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.

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

<comment><USER76> Unless you buy Apple Care, of course.

(Sorry, couldn't resist writing :) )

<comment><USER75> I chuckled.

</comment></comment></comment></comment><comment><USER77> 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](https://en.wikipedia.org/wiki/Responsible_disclosure)

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

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

</comment></comment></comment><comment><USER80> 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?

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

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

<comment><USER66> 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](https://forums.developer.apple.com/thread/88052#266901)

</comment></comment></comment></comment><comment><USER81> 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.

<comment><USER82> I believe hitting "cancel" was enough. [https://www.youtube.com/watch?v=DE5PRW- AR7Q](https://www.youtube.com/watch?v=DE5PRW-AR7Q)

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

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

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

</comment></comment></comment></comment><comment><USER84> 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.

</comment><comment><USER85> 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.

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

</comment></comment><comment><USER87> 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

<comment><USER88> 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?

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

</comment></comment></comment><comment><USER89> 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?

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

</comment></comment><comment><USER3> 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;

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

</comment></comment><comment><USER92> 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.

</comment><comment><USER93> Top 10 software blunders of all time:

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

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

3) ...

<comment><USER94> 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](https://launchpad.net/ubuntu/+source/shadow/+bug/34606)

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

</comment></comment></comment><comment><USER96> 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

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

</comment></comment><comment><USER97> 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.

</comment><comment><USER98> 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.

</comment><comment><USER99> Temporary workaround (pasted from [http://www.bbc.com/news/technology-42161823](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](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.

</comment><comment><USER100> 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.

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

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

<comment><USER103> 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

</comment></comment></comment></comment><comment><USER104> A quick mitigation workaround: If you follow the steps here [https://support.apple.com/en-us/HT204012](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.

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

</comment></comment><comment><USER105> This is _deeply_ troubling. How does this even happen?

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

<comment><USER107> Errr... umm... unit tests? Tests?

<comment><USER106> You can have 100% coverage and never check a single edge case. Much less remember _every_ edge case.

</comment></comment></comment></comment><comment><USER108> 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

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

</comment></comment><comment><USER109> Title should be changed to 'macOS'

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

<comment><USER110> Now you have me confused, is it just High Sierra or Sierra as well?

<comment><USER111> It does not work for me using Sierra.

<comment><USER110> Awesome, thanks.

</comment></comment></comment></comment><comment><USER112> 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").

</comment><comment><USER113> Who needs security when we have animoji!

</comment><comment><USER114> 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.

</comment><comment><USER60> 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.

<comment><USER115> 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://www.apple.com/macos/high-sierra/)

\- [https://developer.apple.com/library/content/releasenotes/Mac...](https://developer.apple.com/library/content/releasenotes/MacOSX/WhatsNewInOSX/Articles/macOS_10_13_0.html)

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

</comment></comment><comment><USER116> 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?

</comment><comment><USER117> 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](https://forums.developer.apple.com/thread/79235#277225)

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

<comment><USER117> Ahh the links weren't on the first page of the HN comments when I posted. They are now. I didn't click more. :)

</comment></comment></comment><comment><USER119> 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)

</comment><comment><USER120> 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.

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

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

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

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

</comment></comment></comment></comment><comment><USER34> 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](https://support.apple.com/en- us/HT204012). If a Root User is already enabled, to ensure a blank password is not set, please follow the instructions from the 'Change the root password' section."_

[https://techcrunch.com/2017/11/28/astonishing-os-x-bug- lets-...](https://techcrunch.com/2017/11/28/astonishing-os-x-bug-lets-anyone- log-into-a-high-sierra-machine/)

</comment><comment><USER124> I wouldn't have thought that NSA backdoors are so simple

</comment><comment><USER125> 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...](https://images-na.ssl-images- amazon.com/images/I/51I4nsyt9AL._UL1000_.jpg)

</comment><comment><USER126> Fix has been released: [https://www.macrumors.com/2017/11/29/apple-fixes-root- passwo...](https://www.macrumors.com/2017/11/29/apple-fixes-root-password-bug- security-update/)

</comment><comment><USER127> 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.

</comment><comment><USER128> [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.

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

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

<comment><USER129> 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?

</comment></comment></comment></comment><comment><USER131> Wow. As if I needed another reason to never "upgrade" to High Sierra...

<comment><USER132> Apparently El Capitan is vulnerable too.

<comment><USER26> Can't reproduce on El Cap.

</comment></comment></comment><comment><USER133> 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?

</comment><comment><USER134> 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.

</comment><comment><USER135> 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

<comment><USER136> I was just able to reproduce it in 10.13.1. I had to click submit twice.

</comment></comment><comment><USER137> Myself and others blogged about solutions: [https://www.rderewianko.com/10-13-root-password-oh- my/](https://www.rderewianko.com/10-13-root-password-oh-my/) [https://derflounder.wordpress.com/2017/11/28/blocking- logins...](https://derflounder.wordpress.com/2017/11/28/blocking-logins-to- the-root-account-on-macos-high-sierra/)

</comment><comment><USER79> This is very, very bad.

</comment><comment><USER138> 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?

<comment> drunken-serval It took 3 tries for me and then it worked.

</comment></comment><comment><USER139> 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.

</comment><comment><USER140> How come nobody has picked a name for this vulnerability?

</comment><comment><USER141> [https://support.apple.com/en-us/HT208315](https://support.apple.com/en- us/HT208315)

Fixed.

</comment><comment><USER82> 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.

<comment><USER142> 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?

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

</comment></comment></comment><comment><USER143> 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?

<comment><USER144> Who types root in as a login name on a Mac?

</comment></comment><comment><USER69> Works with "su - root" too in a Terminal.

</comment><comment><USER89> 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.

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

<comment><USER146> 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.*?

<comment><USER147> 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)

</comment></comment></comment><comment><USER125> They could have at least used "rms" instead of a blank password.

[https://www.reddit.com/r/linux/comments/7hj6v/i_use_my_login...](https://www.reddit.com/r/linux/comments/7hj6v/i_use_my_login_name_as_my_password_richard_m/)

</comment><comment><USER148> Does this work from single user mode?

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

</comment></comment><comment><USER149> 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.

</comment><comment> oh-kumudo LOL. Can we call this...front door?

</comment><comment><USER150> Maybe NSA asked for an easy access. Apple is generally good at making things simple for users.

</comment><comment> j-pb 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... :(

</comment><comment><USER151> Security update just came out. Installed it and can no longer reproduce. Can anyone confirm?

</comment><comment><USER152> Time to install Afterdark on all the computers in the Apple store. Confirmed here, 10.13.1.

<comment><USER153> And I just googled afterdark at work... haha thanks!

</comment></comment><comment><USER154> I guess we finally figured out what the "insanely" great products was all about.

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

</comment><comment><USER156> 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.

</comment><comment><USER157> 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://en.m.wikipedia.org/wiki/Responsible_disclosure)

[https://support.apple.com/en-au/HT201220](https://support.apple.com/en- au/HT201220) (See 'Security and privacy researchers')

<comment><USER158> 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_!

<comment><USER157> 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 - <USER2> public, start by logging a bug report and link to that bug report or if you can't - the bug number / reference.

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

<comment><USER157> > "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://www.cloudflare.com/disclosure/)

[https://access.redhat.com/security/team/contact](https://access.redhat.com/security/team/contact)

[https://www.xenproject.org/security- policy.html](https://www.xenproject.org/security-policy.html)

[https://about.gitlab.com/disclosure/](https://about.gitlab.com/disclosure/)

[https://help.github.com/articles/responsible-disclosure- of-s...](https://help.github.com/articles/responsible-disclosure-of-security- vulnerabilities/)

[https://www.kernel.org/doc/html/v4.10/admin- guide/security-b...](https://www.kernel.org/doc/html/v4.10/admin- guide/security-bugs.html#contact)

[https://www.drupal.org/drupal-security-team/general- informat...](https://www.drupal.org/drupal-security-team/general-information)

[https://www.cisco.com/c/en/us/about/security- center/security...](https://www.cisco.com/c/en/us/about/security- center/security-vulnerability-policy.html)

[https://www.juniper.net/us/en/security/report- vulnerability/](https://www.juniper.net/us/en/security/report-vulnerability/)

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

<comment><USER157> >> 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](https://libguides.mit.edu/citing)

> Is it a bad way? No!

OK this is where I stop feeding the troll.

</comment></comment></comment></comment></comment></comment></comment><comment><USER159> 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.

</comment><comment><USER160> Apple proves they still care about UX: finally, I found a way to login without typing.

</comment><comment><USER161> The TC GIF is hilarious.

[https://tctechcrunch2011.files.wordpress.com/2017/11/ooooooh...](https://tctechcrunch2011.files.wordpress.com/2017/11/ooooooh- dear.gif)

</comment><comment><USER162> 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???"

</comment><comment><USER163> 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".

</comment><comment><USER30> You can just type root in the login window to get System administrator access.

</comment><comment><USER164> 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.

</comment><comment><USER165> 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?

</comment><comment><USER166> I tried it anyway and it does not work! I'm running version 10.13.1

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

</comment></comment><comment><USER168> 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.

</comment><comment><USER169> 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.

<comment><USER170> Apparently there is no macOS bug bounty: [https://twitter.com/i0n1c/status/935608248027303936](https://twitter.com/i0n1c/status/935608248027303936)

</comment></comment><comment><USER171> The solution for now is to set a passwd for root... this is ridiculous

</comment><comment><USER172> Has no one been running password crackers against OSX this whole time?

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

</comment></comment><comment><USER174> 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).

</comment><comment><USER175> I didn't think the BSD's allowed a blank root password.

<comment><USER176> 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 …

</comment></comment><comment><USER177> 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

</comment><comment><USER178> 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.

</comment><comment><USER179> 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.

</comment><comment><USER180> 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?

</comment><comment><USER181> [https://support.apple.com/en-us/HT204012](https://support.apple.com/en- us/HT204012)

How to set root password.

</comment><comment><USER182> 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.

<comment><USER156> > 1 + 2 + 3

[https://www.macrumors.com/2017/10/24/ios-11-calculator- anima...](https://www.macrumors.com/2017/10/24/ios-11-calculator-animation- bug/)

</comment></comment><comment><USER183> Patched: [https://support.apple.com/kb/HT208315](https://support.apple.com/kb/HT208315)

</comment><comment><USER184> Should I leave my Mac unattended until this is resolved?

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

</comment></comment><comment><USER186> 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.

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

<comment><USER188> Doesn't work for me either on 10.12.6.

</comment></comment></comment><comment><USER189> I wonder when/what Apple's response will be

</comment><comment><USER190> High Sierra has been one of the worst OSX upgrade.

</comment><comment><USER191> 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](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](http://www.nasdaq.com/symbol/aapl/option-chain)

</comment><comment><USER192> 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

</comment><comment><USER193> 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.

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

<comment><USER73> Not if I use FileVault, surely?

</comment></comment><comment><USER195> Does this bypass filesystem encryption?

<comment><USER196> Only if the laptop is locked (as the encryption key is already in memory).

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

<comment><USER196> 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...](http://mattwashchuk.com/articles/2016/01/08/maximizing-filevault- security)

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

</comment><comment> Stephen-E While reading this, my mac just prompted me to Upgrade to High Sierra. I think I'll hold off...

</comment><comment><USER198> Confirmed on 10.13. I was even able to add a user as an administrator after unlocking with root.

</comment><comment><USER199> I'm unsurprised, loginwindow is a piece of shit nobody wants to work on. Poor dude.

</comment><comment><USER200> #whyidontupgrade

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

</comment><comment><USER201> To block this, set a random password for root:

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

</comment><comment><USER202> Good thing I haven't updated yet. I wonder how many machines are vulnerable?

</comment><comment><USER142> Does this effect people who already have a root user with a password set up?

<comment><USER203> No

</comment></comment><comment><USER204> patch has been released in record time, I have update my mac

[https://support.apple.com/en-in/HT208315](https://support.apple.com/en- in/HT208315)

</comment><comment><USER205> This clearly is a feature!

</comment><comment><USER206> 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.

</comment><comment><USER207> 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.

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

<comment><USER41> Maybe. Look at his twitter page though: [https://twitter.com/lemiorhan](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...](http://jesuschristsiliconvalley- blog.tumblr.com/post/46537875392/what-your-profile-picture-says-about-you- hint)

<comment><USER73> How do the banner or stats suggest he should have known about this?

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

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

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

</comment></comment></comment></comment></comment></comment></comment><comment><USER208> workaround: ENABLE ROOT USER AS FAST AS POSSIBLE

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

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

</comment></comment><comment><USER209> Doesn't matter, Apple gets an automatic pass.

</comment><comment><USER56> Wow, setting a root password seems to fix this...

</comment><comment><USER210> 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.

</comment><comment><USER211> Wow. Can't believe it. It's true.

</comment><comment><USER212> Worked for me on the second try (10.13.1)

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

</comment></comment><comment><USER213> Serious 0-day on Twitter. How exciting!

</comment><comment><USER214> 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.

</comment><comment><USER215> In what version did the issue appear?

<comment><USER216> we've seen it only in 10.13.1 (17B48) so far

<comment><USER217> It also works on 10.13 (17A365)

<comment><USER218> I can confirm that, too. Took 2 attempts.

</comment></comment></comment></comment><comment><USER219> There is also now a patch available.

</comment><comment><USER220> This is why I use disk encryption.

</comment><comment><USER221> Apple is the new Internet Explorer

</comment><comment><USER222> Is this also in 10.13.2 beta?

</comment><comment><USER159> Does it affect MacOS Server?

</comment><comment><USER223> Confirmed here on 10.13

</comment><comment><USER224> *macOS High Sierra

</comment><comment><USER225> verified on latest build of 10.13.1 (17B48).

</comment><comment><USER144> But there are new emojis, and emoji karaoke works!

</comment><comment><USER43> Not cool to disclose this kind of bug on Twitter.

</comment><comment><USER67> I miss Snow Leopard.

:/

</comment><comment><USER226> 1

</comment><comment><USER125> 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](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 <email@example.com>
        Message-Id: <email@example.com>
        To: email@example.com, firstname.lastname@example.com,
                Pete "Gymble Roulette" Cottrell <firstname.lastname@example.com>
        In-Reply-To: Chris Torek's message of Mon, 29 Sep 86 22:57:57 EDT
        Subject: stranger and stranger and stranger and stranger and stranger

           Date: Mon, 29 Sep 86 22:57:57 EDT
           From: Chris Torek <email@example.com>

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

</comment><comment><USER227> Apple makes it pretty easy to report vulnerabilities to:

email@example.com

They also respond to firstname.lastname@example.com but prefer the product-security address.

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

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

<comment><USER228> 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...](https://arstechnica.com/information- technology/2017/09/password-theft-0day-imperils-users-of-high-sierra-and- earlier-macos-versions/)

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

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

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

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

<comment> mark-r 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.

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

</comment></comment></comment></comment></comment></comment></comment><comment><USER231> kk

</comment><comment><USER232> the MOST STUPID OS bug FOREVER?

</comment><comment><USER233> That twitter thread and lots of the comments are missing the point. MANY people don't know about what the ethics of reporting vulnerabilities are, they just want to say something and get it fixed. yes, it probably would have been better if this person had gone through proper channels, but there's no evidence they did it for the lulz/fame.

In this case the bug is so bad and egregious, that publicizing it with the fix might have been the best thing to do -- no telling how many people have already discovered this or how long it would take Apple to fix.

Yes, let's educate each other about what responsible disclosure WITH A DEADLINE TO FIX looks like, but don't assume this person just wanted internet points. And now that the report and a workaround are out there, at least it can be mitigated personally.

Though I imagine there will be some SERIOUS hijinks that result from this until Apple fixes it because it is so easy to do. :(

<comment><USER234> I'm not a security researcher and I don't work for Apple. If I casually came across this I would totally tweet it out. Anyone asserting I should follow some sort of procedure has a misplaced sense of reality.

<comment><USER235> You would do that.. but you don't consider what you should do.. surely responsible disclosure is the smarter strategy?

<comment><USER234> Responsible vs irresponsible... how would I know? You're assuming way too much.

<comment><USER235> The average person who has never heard these things may act as described, but the person should be criticized for it, and if they dont correct their mistake they should be criticized for that too. Thats the point of criticism.

</comment></comment></comment></comment></comment><comment><USER236> I still can't believe more people complain about this being publicly disclosed than this being possible in the first place. No one is obligated to know the procedures on InfoSec 0-days and follow those steps.

<comment><USER237> I wouldn't bash the guy. Someone already let him know about his technical faux pas in a professional manner on his twitter.

My guess is he found this vulnerability on accident, freaked out, and tweeted about it. Probably has limited infosec experience.

<comment><USER51> Or he cares more about doing the right thing than about following best practices designed to protect the guilty under the guise of helping users.

<comment><USER235> Idk why u say "designed to protect the guilty under the guise of protecting the innocent".. it clearly does both. It _does_ protect the innocent. That is a fact! It also does protect the guilty! Both are true. It makes it harder to have a strong view when you must acknowledge both facts I suppose

</comment></comment></comment></comment><comment><USER238> Are we really ready for self-driving cars? [https://www.youtube.com/watch?v=4G1Boh- URIM](https://www.youtube.com/watch?v=4G1Boh-URIM)

<comment><USER239> I will take malicious improper analogy for 100

<comment><USER238> Please point out the discrepancy.

A Tesla has ~ 100.000.000 [1] lines of code. Considering this post, do you think we are sufficiently educated in software security to produce secure self-driving cars?

Elon Musk: "I think one of the biggest risks for autonomous vehicles is somebody achieving a fleet wide hack" [2].

[1] [https://bit.ly/KIB_linescode](https://bit.ly/KIB_linescode)

[2] [https://www.youtube.com/watch?v=4G1Boh- URIM](https://www.youtube.com/watch?v=4G1Boh-URIM)

<comment><USER240> These companies have completely different operating systems, network ACLs, software update policies and subsystems that affect certain mechanical features.

By your logic, we should not fly any modern commercial or military aircraft or spacecraft, live within a certain radius of any power or hazardous chemical plant, place any dependency on any first world country's health care network, including life support, or invest in any company or stock.

Like most things in life it comes down to a security/convenience risk/benefit compromise.

<comment><USER238> > These companies have completely different operating systems, network ACLs, > software update policies and subsystems that affect certain mechanical > features.

Are you claiming that this could not have happened with Tesla? If so, please explain why.

> By your logic, we should not fly any modern commercial or military aircraft > or spacecraft, live within a certain radius of any power or hazardous > chemical plant, place any dependency on any first world country's health > care network, including life support, or invest in any company or stock.

Up until now the benefits have clearly outweighed the risks, but that does not mean it will continue to do so.

</comment></comment></comment></comment></comment><comment><USER241> Why is this so far down the front page? Are people flagging it for some reason?

<comment><USER102> The title is wrong: it affects High Sierra, not Sierra. Edit: they've fixed the title

</comment></comment><comment><USER102> The HN title is wrong. This reportedly affects High Sierra, not Sierra.

<comment><USER242> That explains why I couldn't get it to work on my machines that are still on Sierra. I'm glad I've put off the update.

</comment></comment><comment><USER243> I wonder who they're going to ask to write a public letter of apology this time.

This isn't just a snarky comment. They have just released the most awfull iOS upgrade for a long time, and now this. Something's messed up, and they better fix it soon.

I've think i've read somewhere they merged the iOS and macOS teams, i suppose the wrong people were promoted during the operation.

<comment><USER110> Cue "incorrect elevation of privileges" joke.

      sudo laugh

edit: spelling

<comment><USER244> Cue

<comment><USER110> doh, thanks. Can you tell what abstract data type I've been working with lately?

</comment></comment></comment></comment><comment><USER245> Can't reproduce on multiple High Sierra machines.

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

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

<comment><USER245> Does it work if you set the root password and try again?

</comment></comment></comment></comment><comment><USER246> This is the first time I've felt happy I rarely upgrade.

</comment><comment><USER247> 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.

</comment><comment><USER248> People going on about responsible disclosure when this is such a gross violation of CUSSE: [https://web.archive.org/web/20170712120031/http://www.cusse....](https://web.archive.org/web/20170712120031/http://www.cusse.org/)

</comment><comment><USER249> Dope

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

</comment><comment><USER251> But someone at Apple got their bonus for shipping the animated poop icon in time for this release.

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

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

</comment></comment></comment><comment><USER81> Classical click and bait title. First promises that you'll become a hacker, and then when you actually click the tweet is deleted.

<comment><USER252> Isn't deleted for me.

</comment></comment><comment><USER253> Is [http://hckrnews.com/](http://hckrnews.com/) buckling from the tremendous traffic this issue generates?

</comment><comment><USER254> I guess they were more focused in introducing bugs and less performant filesystem than security in High Sierra.

<comment><USER255> Those teams are extremely unlikely to be the same ones.

</comment></comment><comment><USER256> Oh my goodness. I have a High Sierra MBP. I am scared right now BADLY

<comment><USER26> It can't be exploited remotely. Only by someone sitting at your computer.

<comment><USER256> I know. But I don't want my roomies to access it while I'm in the toilet, for example.

</comment></comment></comment><comment><USER27> Now that this is public, it's likely worth passing this message on to non- technical folks too (e.g. share this or write a similar post - this is my only public post):

[https://www.facebook.com/amar.sood/posts/10209545863036116](https://www.facebook.com/amar.sood/posts/10209545863036116)

<comment><USER242> Important error in your instructions. They should set a very strong password and keep the root account enabled. Disabling the root account opens up the vulnerability again.

<comment><USER27> Edit: Okay so it seems that my shell based suggestion of `dsenableroot -d` prevents the bug from re-occurring, but not the GUI version. :facepalm:

I updated the post to include the word 'strong', although I would expect most users to simply set their own password, which should provide identical security to what they currently (should) have.

Disabling the root account does not open up the vulnerability again.

This vulnerability doesn't reset the root password, it only enables the root account and checks the password against that. The default root password out of the box on OSX is blank which is what allows this to work as-is.

By setting a root password, the next time you attempt this (and I tried it), the attempt fails since the 'root' account now has a password set.

Disabling simply puts the root account back in a dormant state, where it should be for most users, for after this vulnerability is fixed and it can't be enabled maliciously.

</comment></comment></comment><comment><USER257> This post reminded me of why Twitter is a pretty awful place.

The replies to this tweets are all everyones snarky comments to the @AppleSupport account or their edgy 'hot takes' on the issue. @AppleSupport responded promptly - albeit obviously out of their depth, and a bunch of people couldn't help but make fun of this fact. It's almost like tweeting to Apple's customer support account is not the best way to report a vulnerability?

Responsible disclosure has a proven history of working. When the vulnerability is appropriately patched and disclosed to the public, there is still a lot of backlash. You only need to look at the recent responsibly disclosed vulnerabilities for proof of this. Instead, we have a bunch of armchair analysts—who don't at all seem to be driven by past occurrences / existing data in any way—claiming that it didn't work.

</comment><comment><USER258> Fellow Linux users, please keep the snark in this thread to a minimum. Here's just one recent example why, there are more: [http://www.omgubuntu.co.uk/2017/05/ubuntu-guest-sessions- log...](http://www.omgubuntu.co.uk/2017/05/ubuntu-guest-sessions-login- disabled)

<comment><USER259> Linux != Ubuntu

Linux didn't have that problem, a single vendor did. You could say the same for Apple except they are the single vendor. That stupid security trick in Ubuntu only impacts subset of a subset of Linux _desktop_ users which is a pretty small subset of computer users as a whole. When Apple does something like this, it impacts a much larger share of the world population.

So how about we keep the snark to an appropriate level based on the impact to the world population? ;)

<comment><USER112> As Linux user who does kernel-mode development for a living, root escalation bugs come a dime a dozen. And, well, Linux runs everything _but_ the average persons laptop, so the impact, while different, is much greater.

So lets keep the snark to an appropriate level, shall we?

<comment><USER259> Are you arguing that privilege escalation is the equivalent to passwordless root login? I mean, I guess you squint just right you could say that a logged out user having zero privileges being able to login as a user with all privileges is an "escalation" but that's one hell of a stretch. We haven't even gotten to snark yet though.

We can point to avenues for remote root all day but I don't recall any that are/were as simple as "just hit [enter] to get root" that impacts the shared attack surface that impacts all Linux systems.

NOTE: I did not go and search NVD before writing this reply but I did stay at a Holiday Inn Express once.</comment></comment></comment></comment>