Oh this is a real vulnerability. It&#x27;s possible to switch your user to System Administrator using &quot;root&quot; and no password.

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

Confirmed that root with no password unlocks the preferences pane. But, changing the require password after screen saver setting doesn&#x27;t take effect. So, it seems to be a bug in the UI not an actual vulnerability.edit: I stand corrected. The &#x27;require password&#x27; setting under Security Preferences didn&#x27;t change, but other settings do. Yikes

Doesn&#x27;t work for me either on 10.12.6.

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

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

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

I cannot reproduce this on Sierra or El Cap

The bug does not exist on El Capitan. Your description tells me you already had the root user enabled with no password (which is something you can do with Directory Utility.app)

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

Yes, that&#x27;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)

Same, I&#x27;m on 10.12.6, could not reproduce anywhere.I think I&#x27;ll hold off on that 10.13.1 &quot;security update&quot; 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.*?

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

Those teams are extremely unlikely to be the same ones.

I guess they were more focused in introducing bugs and less performant filesystem than security in High Sierra.

I&#x27;m able to do this as well, login as root with no password from the login screen.

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&#x27;s not just a UI bug, it&#x27;s a full on authentication bypass.

It took 3 tries for me and then it worked.

I can&#x27;t seem to reproduce it locally. 10.13.1… Anyone else having issues?I&#x27;ve upgraded a through a couple versions of OS X on this machine - maybe that makes a difference?

Been wondering that myself since it seems that this also happens with the login screen.

Yes, I just had a coworker test it after I enabled remote management and they used screensharing.app. I didn&#x27;t even get notified a user remoted in.. never used screen share, that seems awful. Had to look over and ask if he was in.edit: I should say, I did test this locally first so I don&#x27;t know if a fresh machine that hasn&#x27;t done it will do the same thing and let a remote account enable root.. Would like to hear if anyone tested it remotely WITHOUT doing it locally first.

It only works after getting physical access once to enable the root user by gibing any password UI the root user with no password (which will enable the local root account, which is also why it fails the first time around)

I tested this by logging in as root at a preference pane then attempting to connect via ssh and screen sharing (both enabled) using root with no password. It did not work.Not sure if you&#x27;d get different results after logging in as root at the login screen...

If root was ever enabled without setting a password, the machine is then in a state that it can be remotely exploitable.While it&#x27;s unlikely, there are probably plenty of users who have done this for some reason or another.Don&#x27;t underestimate a user&#x27;s ability to blindly do things like this by following arcane instructions in attempts to fix an unrelated problem.

Not according to this video:<a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=FpOH0lxEGBE" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=FpOH0lxEGBE</a>They seem to be remotely accessing the machine to both set and then use the root account.

You can get undetectble remote access on most machines given &quot;physical access once&quot;, so I don&#x27;t think this qualifies as &quot;remotely exploitable&quot;.

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.

Wow. As if I needed another reason to never &quot;upgrade&quot; to High Sierra...

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?

Linux != UbuntuLinux didn&#x27;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? ;)

Number of mentions of &quot;Linux&quot; outside of your thread comment chain: 0

Hypocrisy is a reason to keep snark at a minimum?

I&#x27;m a Linux desktop (and laptop!) user, and I agree (I haven&#x27;t even used macOS in almost twenty years). Anyone remember the Debian OSPRNG issue?These sorts of bugs can happen anywhere. We all need to bear that in mind.One notable difference, though, is that macOS is proprietary software. Apple have sold their users a product and haven&#x27;t respected their users&#x27; right to use, modify &amp; distribute that product; their users have never had the ability to inspect the macOS source for this kind of problem. Thus, responsibility for this disaster rests solely on Apple&#x27;s shoulders.

Fellow Linux users, please keep the snark in this thread to a minimum. Here&#x27;s just one recent example why, there are more: <a href="http:&#x2F;&#x2F;www.omgubuntu.co.uk&#x2F;2017&#x2F;05&#x2F;ubuntu-guest-sessions-login-disabled" rel="nofollow">http:&#x2F;&#x2F;www.omgubuntu.co.uk&#x2F;2017&#x2F;05&#x2F;ubuntu-guest-sessions-log...</a>

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

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

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

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

In my opinion they don&#x27;t &quot;owe&quot; anyone that obligation, unless it&#x27;s a contractual obligation associated with using a Mac. But just because it&#x27;s not owed to anyone, doesn&#x27;t mean there isn&#x27;t a nicer way to handle it just to be nice.That said, I don&#x27;t immediately see evidence that this gentleman is in the security field, and perhaps isn&#x27;t aware of responsible disclosure. Full disclosure isn&#x27;t the worst thing in the world.

Where is Joe Random&#x27;s obligation to responsibly disclose?To whom does he owe that obligation? Apple? The public? Both? Why?

Full disclosure is also a form of responsible disclosure.

Twitter&#x27;s also the goto for banning trans people from military service, attacking freedom of the press, threatening to declare nuclear war, and all kinds of other things too.

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 &quot;Responsible Disclosure&quot;[0]?[0] <a href="https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Responsible_disclosure" rel="nofollow">https:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Responsible_disclosure</a>

&lt;sarcasm&gt;&quot;OSX the more secure OS because nobody tries to hack it, CONFIRMED.&quot;&lt;&#x2F;sarcasm&gt; ;)

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

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

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

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

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: &quot;I think one of the biggest risks for autonomous vehicles is somebody achieving a fleet wide hack&quot; [2].[1] <a href="https:&#x2F;&#x2F;bit.ly&#x2F;KIB_linescode" rel="nofollow">https:&#x2F;&#x2F;bit.ly&#x2F;KIB_linescode</a>[2] <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=4G1Boh-URIM" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=4G1Boh-URIM</a>

I will take malicious improper analogy for 100

As someone who tries to do risk analysis, the prospect of sticking with human drivers because of fear of software bugs (which inevitably will kill, just in much smaller numbers) terrifies me.

Could a programmer be held liable for any bad outcomes?

As a programmer, the thought terrifies me.

technically, after they are hacked they are no longer self-driving.

Thank youI imagine a Twilight Zone episode... Go back in time to before cars were invented and imagine some Mephistopheles offering the bargain: &quot;You&#x27;ll fly like the wind over hills and mountains, making a journey of days in mere hours!&quot; What the catch? &quot;For each mile traveled a certain number of people chosen at random must be put to death or maimed.&quot;He would go on about how the chances of someone you love being chosen for sacrifice were infinitesimal, and the benefits to all were so great and so obvious...(&quot;Also, it will poison the air and water, and force you to become dependent on fuel sources that destroy life and engender wars.&quot;)

Possibly not, but the death &amp; maiming stats everywhere show we&#x27;re absolutely not ready for human-driven ones.

No. I am also skeptical of more modern cars with complex computers. The thought of being in one scares me.

I think the question you&#x27;re fundamentally asking is &quot;are we ready for imperfect systems with potential vulnerabilities?&quot;, and the answer to that question has been the same since the advent of software.

They don&#x27;t need to be perfect. Just better than humans.

Is the authentication subsystem in a Tesla machine learning as well?

&gt; Are we really ready for self-driving cars?Firstly, car automation is machine learning, not programming. Completely incomparable.Finally, we&#x27;ve known how to prove the absence of bugs for decades. It&#x27;s not a matter of not knowing how, it&#x27;s about incentives to do it right.

Are we really ready for self-driving cars? <a href="https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=4G1Boh-URIM" rel="nofollow">https:&#x2F;&#x2F;www.youtube.com&#x2F;watch?v=4G1Boh-URIM</a>

verified on latest build of 10.13.1 (17B48).

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 &#x2F;does&#x2F; also work with `su - root`.

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?

wat. confirmed on 10.13.1 (17B48). I was even able to add another super user.Edit: changing the login method to &quot;Name and password&quot; under login options, then logout and login with &quot;root&quot; with empty password also works.Fortunately, it doesn&#x27;t work on cold boot with FileVault enabled, at least it doesn&#x27;t appear so. `sudo su root` also doesn&#x27;t work with an empty password.

All too easily. There&#x27;s so much to keep track of in modern systems engineering. We should all have a healthy dose of awareness that we could be&#x2F;create that weakest link even on our best days.

This is deeply troubling. How does this even happen?

The blame lies squarely on Apple, not on the messenger.There is blame on both.If you leave your key in your front door lock and I blast out on twitter your address and tell people about it, I think I have some responsibility.

I get it, I really do, but it&#x27;s not like he was complaining about a bad Uber driver.  Disclosure in this way has real-world impacts up to and including harming people and we shouldn&#x27;t ever consider it as something which is remotely acceptable.  Is it acceptable to publicly disclose that an airport has a self-destruct switch which can be accessed near the NW mens bathroom?  No.  You contact someone who can fix the problem, then publicly disclose.

... And means that others can utilize this to cause damage.The idea of responsible disclosure is to minimize harm for you, the user. Not to minimize bad publicity.

Mostly, they&#x27;re just missing out on an up to $200,000 bug bounty.<a href="https:&#x2F;&#x2F;www.theregister.co.uk&#x2F;2016&#x2F;08&#x2F;05&#x2F;apple_joins_the_bug_bounty_party_with_200000_top_prize&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.theregister.co.uk&#x2F;2016&#x2F;08&#x2F;05&#x2F;apple_joins_the_bug...</a>

<pre><code> &gt; people are under no obligation to
 &gt; report vulns privately
</code></pre>
Legal obligation, no, you&#x27;re right. Moral obligation? Why not?

It&#x27;s the neighborly thing to do, but people are under no obligation to report vulns privately. The blame lies squarely on Apple, not on the messenger.The fact that we know about it means we can take steps to mitigate the damage.

Indeed, discovering this bug wouldn&#x27;t take any security skill (I imagine it could be harmful since you might skip really dumb stuff like this) and could easily happen by accident. Responsible disclosure is standard for security researchers but I don&#x27;t think this person was one, and it&#x27;s not very fair to blame him for not doing it right.

That is not the case among infosec professionals either. Many respected professionals believe that the right thing to do in many cases is full public disclosure. Google Project Zero are a notable example.

Is it likely it&#x27;s just an error due to the discoverer not being immersed in the Infosec space? &quot;Don&#x27;t disclose a 0-day publicly&quot; is good &#x27;common&#x27; sense, but only among the &#x27;common&#x27; of people who are steeped in security issues and the ramifications of publicizing them.

There must be some kind of scale 1-10 of how serious the issue is. This one goes up to 11 as hilarious, not sure if proper reporting ethics apply here anymore.

&quot;It only works after getting physical access once&quot; - quote form somewhere else in the thread

The &#x27;sign in as root with no password&#x27; method cannot be used to trigger the vulnerability initially via remote desktop. I tested it via SSH, File Sharing, Screen Sharing and Remote Management. None of these will enable the root user if it has not already been done locally.Once the root user has been enabled locally, the only sharing settings I found to permit anyone remote access with the root&#x2F;null combo is Remote Management.

It&#x27;s not local if you have Remote Desktop enabled. Works over that too. From there you can enable ssh and all bets are off.

I agree.<a href="https:&#x2F;&#x2F;www.eff.org&#x2F;deeplinks&#x2F;2017&#x2F;10&#x2F;drms-dead-canary-how-we-just-lost-web-what-we-learned-it-and-what-we-need-do-next" rel="nofollow">https:&#x2F;&#x2F;www.eff.org&#x2F;deeplinks&#x2F;2017&#x2F;10&#x2F;drms-dead-canary-how-w...</a>Blame the DMCA. This guy is in Turkey - does GP really think he can expect fair treatment and equal compensation as a &quot;western world&quot; security researcher?

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

Don&#x27;t forget the Disk Utility password disclosure! <a href="https:&#x2F;&#x2F;www.macrumors.com&#x2F;2017&#x2F;10&#x2F;05&#x2F;macos-high-sierra-disk-utility-vulnerability&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.macrumors.com&#x2F;2017&#x2F;10&#x2F;05&#x2F;macos-high-sierra-disk-...</a>

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.

I&#x27;m more concerned that the &quot;exploit&quot; works &quot;after a few tries&quot; and not the first-time-every-time, or not at all.One would think that something as simple as a login would be deterministic.

Why does it need to create a lot of negative publicity for Apple? Is there something you don&#x27;t like about them? Responsible disclosure needs to be valued given the number of macs out there in the wild that could potentially be susceptible to issues like this, and the impact it could have on people (including you) not just directly but indirectly.How would you feel if someone discovered a 0day at a company that exposes credit card and identity info, published the 0day, then hackers steal all that info (including yours)? I&#x27;m sure &#x27;creating a thunderstorm of negative publicity&#x27; would be the last thing you would want.

I think there&#x27;s a middle ground to this. Submit your report to Apple security, allow them time to develop a patch, and then in a week go ahead and tweet at the big media outlets about it.I&#x27;m a die-hard Apple user myself, but I agree that the long list of severe bugs in High Sierra is absurd, and a big public backlash might be enough to kick them into gear. On the other hand, I, a university student with next to no understanding of computer security, can simply walk onto campus, sit down at a Mac, and within seconds have complete access to the computer. It&#x27;s ridiculous, it&#x27;s horrendous that it shipped like this, but it&#x27;s not something that needed to get out, especially something so easy to utilize.

Zero-day disclosures aren&#x27;t about negative publicity in order to prevent problems further down the road some time in the distant future.It&#x27;s about protecting systems RIGHT NOW from immediately causing harm to people&#x27;s lives.

Do &quot;responsbile disclosure&quot; rules apply differently to Apple?If so, why? How do you identify companies like Apple that get one set of rules to other companies?

This is extremely naive.Yes Apple shouldn&#x27;t be having this issue but disclosing a 0-day issue can possibly hurt users far worse than hurting Apple. Apple may lose a tiny bit of money but users could lose far, far more especially if someone develops a good way to remotely deploy &#x2F; take advantage of this defect.Ignoring responsible disclosure also limits the ability to sue them for any damage resulting from it (or so I&#x27;m told by one of my lawyer friends who thinks this disclosure may make it almost impossible to successfully sue them over it unless it simply takes them too long to fix).

&gt;Let&#x27;s hope Apple gets sued for the damageHow can that happen in any case ? Isn&#x27;t pretty much the first line in every license waiving of liability ? Unless you have some special contract with Apple that overrides other standard boxes that you ticked, how would anyone sue ?

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&#x27;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&#x27;re forced to change, it won&#x27;t be the last. High Sierra is full of bugs and seemingly not just annoying bugs, but also security bugs.Let&#x27;s hope Apple gets sued for the damage they&#x27;ll cause by including this bug in High Sierra so they make sure that next release of macOS won&#x27;t be another bug filled mess.[1] <a href="https:&#x2F;&#x2F;arstechnica.com&#x2F;information-technology&#x2F;2017&#x2F;09&#x2F;password-theft-0day-imperils-users-of-high-sierra-and-earlier-macos-versions&#x2F;" rel="nofollow">https:&#x2F;&#x2F;arstechnica.com&#x2F;information-technology&#x2F;2017&#x2F;09&#x2F;passw...</a>[2] <a href="https:&#x2F;&#x2F;www.macrumors.com&#x2F;2017&#x2F;10&#x2F;05&#x2F;macos-high-sierra-disk-utility-vulnerability&#x2F;" rel="nofollow">https:&#x2F;&#x2F;www.macrumors.com&#x2F;2017&#x2F;10&#x2F;05&#x2F;macos-high-sierra-disk-...</a>

That was my first thought. Based on some bounty reports I&#x27;ve seen recently I would assume at least high five figures.

AFAICT, Apple&#x27;s security bounty program is officially only for their preselected group of security researchers.In the course of developing my current application, I&#x27;ve discovered a couple security bugs in macOS, which I reported to Apple product security in PGP-encrypted emails. The only thing offered to me was to have my name&#x2F;company listed in the release notes (which they are, for the latest 10.13 update, along with a CVE#).

Does anybody have any info on how much Apple would&#x27;ve been likely to pay for a responsible disclosure in this case, given the scope and severity of the issue?I&#x27;m just curious how much of a payday this guy missed out on by not disclosing responsibly.

We need to come up with a witty name to get it fixed faster.

You can go about it both ways: file a bug report, put a reasonable date that you want them to fix it by. Then you can disclose it.

&gt; Apple only responds reliably to PR stormsThey&#x27;ve been quick (within 45 days) to patch every major bug I&#x27;ve reported to them and where the bugs were cross platform, impacting Windows, Android, etc., they&#x27;ve consistently been amongst the quickest to issue a patch so I&#x27;m not sure how you qualify that statement.

If you urgently want Apple to fix something, you do not file quiet bug reports. Apple only responds reliably to PR storms.This vulnerability is ridiculous, unacceptable, and braindead to execute.

You can&#x27;t expect everybody who uses a computer to be aware of that.

think of the impact to shared iMacs on university campuses.I&#x27;m sure Apple will in the future.

A very small percentage of particularly tech-savvy users. The benefits to this subset do not justify the harm to everyone else.

People are already fixing their machines because he tweeted. this is too much of a huge blunder to wait for the official channels.

&gt; Disclosing an 0Day root authentication bypass vulnerability on Twitter isn&#x27;t cool, even if it is local: think of the impact to shared iMacs on university campuses.It gets the word out quickly.Releasing proprietary software with such a hilariously insecure authentication system isn&#x27;t cool. This isn&#x27;t free software, produced by people &amp; corporations out of the goodness of their hearts; rather, it&#x27;s something for which people pay a good deal of money and which they have a right to expect is at least somewhat secure.Getting the word out, fast that a) there&#x27;s a huge insecurity and b) it&#x27;s in Apple software provides benefits to those running macOS (so they can fix their systems) and to those considering running macOS (so they can evaluate whether an alternative is more appropriate).

<a href="https:&#x2F;&#x2F;www.google.com&#x2F;search?q=apple+report+security+bug" rel="nofollow">https:&#x2F;&#x2F;www.google.com&#x2F;search?q=apple+report+security+bug</a> does bring <a href="https:&#x2F;&#x2F;support.apple.com&#x2F;en-us&#x2F;HT201220" rel="nofollow">https:&#x2F;&#x2F;support.apple.com&#x2F;en-us&#x2F;HT201220</a> right up, but that page documents &quot;how security researchers, developers, law enforcement personnel, and journalists can contact Apple to report or ask about a security issue&quot; -- notably absent from that set is &quot;your average Joe who stumbled upon something entirely by accident&quot; for some reason.

Is this address easily discoverable without needing too much insight into tech company workings? Like, do they have a help menu that tells people where to report stuff? I&#x27;m not an apple user.

If Apple released a patch in less than 24 hours I’d be seriously concerned about the QA that had gone into the patch.

Let&#x27;s wait until Apple release their patch so we know just how long they left everyone&#x27;s machines vulnerable for. That will be a factor in determining whether this disclosure was irresponsible or not. It&#x27;s been two and a half hours so far.

Attackers being unaware of the flaw does.

I disagree.  Being unaware of the flaw doesn&#x27;t make you more secure.

A better analogy is that there&#x27;s a fire somewhere in your village, but it&#x27;s mostly contained (it&#x27;s not spreading, because other people don&#x27;t know about it yet). By hollering about it, you&#x27;ve made it possible for anyone to go to the fire, light a torch with it, and burn down the village. Instead, you could call up the fire department and they could put it out–and then you could tell everyone about it.

This situation is much more akin to a fire rapidly spreading through a village at night. I would go outside and start hollering in the hopes of saving anyone.

&gt; admittedly low priority security vuln, passwords being sent over httpWait, what?

&gt; complaining on Twitter is probably what an average person would do.His twitter account tells 
that he is an agile software craftsman, turkey founder and a community guy. And he tweets about devops, open source and other stuff.An average person disguised as a software developer?

Responsible disclosure is pretty much a security industry concept, it&#x27;s not something that most developers know about, complaining on Twitter is probably what an average person would do.Although for what it&#x27;s worth last time I reported a security vuln to Apple using their official process they took around 2 years to fix it (admittedly low priority security vuln, passwords being sent over http).

I&#x27;d argue that even to the ordinary Joe it should be quite logical that disclosing something publicly before the company has had a chance to fix it means that nefarious people could learn about the exploit and use it against victims.It&#x27;s the same logical line of thought that leads people into turning wallets into the lost and found (or an authority) instead of just pointing at it on the ground shouting &quot;hey look, a wallet!&quot; then walking away.

I agree in general, but calling it uncool and laying any blame on the person reporting is not fair.You may know the protocol, security researchers and people in the tech industry may know that, but why is an ordinary Joe expected to know, or research, that email address and&#x2F;or the protocol regarding 0-day vulnerabilities.

How long have you been working in software? Bugs like this get past competent developers in reasonable organizations all the time.Human fallibility, yo.

This is one of the sillier things I&#x27;ve read today. The only way something like this slips through is a culture of complacency, or incompetence.And the only way Apple gets motivated to fix either of those two things is massive Pr damage.

There is a simple workaround. Publicity means security here.It&#x27;s trivial to find. He can&#x27;t presume he is the only one who found it. Telling any individual that doesn&#x27;t have malicious intent is a good thing, therefore telling everyone is a good thing.

Yeah, the guy is an attention whore, he just wants to buzz.There is no justification for releasing a 0day publicly.

Not really; the issue is that you don&#x27;t have a way to disclose how much the bug is worth without giving away the bug itself. You can kind of ask how much an exploit that gets a local user root access is worth, but that can give away enough to let them focus their own search.In general, you have to rely on this being a repeated game - you and the pentester community at large submit lots of bugs to this company, and you rely on them to make it worth your time and talent. If they don&#x27;t, you go test someone else&#x27;s software. Reputation is everything.

&gt; there are any number of legit bug bounty programsThe thing about bug bounty programs are that they are not a negotiation. They decide how much your information is worth--take it or leave it.If you thought this bug was worth $25,000 and you feared that Apple might offer a $100 discount coupon plus a lovely &quot;I Love My Mac&quot; coffee mug, is there any way to start a negotiation without being accused of extortion (if you imply that you might disclose it publicly)?This is a serious question: Is there any way to negotiate for security bugs, before or after disclosing all the details, without running a legal risk?

Forget the company. This harms users, who are not responsible for causing these issues; for all except the most technical 1% of Apple users, keeping the problem secret while Apple works on a quick patch is much more secure than telling the whole world immediately.

This isn’t about what’s best for Apple it’s about what is best for users. The way this was disclosed was bad for users.

&gt; Disclosing an 0Day root authentication bypass vulnerability on Twitter isn&#x27;t coolno one is under any obligation to sweep company&#x27;s security problems under the rug for them.If companies create incentives for people to share vulnerabilities with them first, great, but no one is under any obligation to participate in those programs.Don&#x27;t ship broken software if you don&#x27;t want pie in your face.

Because clearly, the random Apple user that stumbled upon it should both be aware of and follow the protocols of security researchers.

There is no &quot;responsible disclosure&quot;. You will never get 7 billion humans to do things exactly the way you want it, so if there is a possibility of at least 1 person disclosing a zero day publicly, then you have to be prepared for it just as much as if it was everyone.Instead of trying to control behaviour of every single human being in this world and demanding of them to do things in a certain way - which is, was and will always be impossible it is much more favourable to establish the expectation that a zero day vulnerability might be dropped every week and have businesses (vendors and clients) be prepared for it so it can be handled adequately.

Security experts and hobbiests know this, but not your average user. This doesn&#x27;t look like an in-depth bug hunt. Maybe more average users should be educated about responsible disclosures when finding security problems. This tweeter might not realize they gave up some money.

In this particular case, I am grateful for the early disclosure that I can fix it right now instead of waiting. For a huge bomb like this, I think you really can&#x27;t blame the messenger.

Since it isn&#x27;t exactly easy to send emails securely, I think this piece of advice may need some more work.The PGP key is available here: <a href="https:&#x2F;&#x2F;support.apple.com&#x2F;en-us&#x2F;HT201214" rel="nofollow">https:&#x2F;&#x2F;support.apple.com&#x2F;en-us&#x2F;HT201214</a>I wonder what percentage of emails to security@... (apple.com or otherwise) are sent encrypted...

Disclosing an 0Day root authentication bypass vulnerability on Twitter isn&#x27;t cool, even if it is local: think of the impact to shared iMacs on university campuses.How dare you publicly shame him and risk his future employability like this? It&#x27;s only responsible of you to contact him quietly and directly so he can correct his mistake and cover it up so nobody needs to know.It&#x27;s like there&#x27;s one rule for the negligent global corporation which happens to work in the corporation&#x27;s favor and shames the public for speaking to each other about their salary, I mean flaws in their software, and another rule for ordinary people giving a heads up to people who are fair game to pile on.

Security by Obscurity never works.Source: Information Security 101

Apple makes it pretty easy to report vulnerabilities to:product-security@apple.comThey also respond to security@apple.com but prefer the product-security address.Further, there are any number of legit bug bounty programs out there like ZDI that would pay for a bug like this then immediately disclose to Apple for it to be fixed.Disclosing an 0Day root authentication bypass vulnerability on Twitter isn&#x27;t cool, even if it is local: think of the impact to shared iMacs on university campuses.

Yeh, except for the millions of MacOS users out there, like my parents who don&#x27;t read Twitter, or HN or any of the other sites people think that everyone stays up on. They are the targets.

That&#x27;s not how responsible disclosure works.

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

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

Probably could still get 15 minutes of fame if you disclosed privately then blogged about the back and forth and a picture of the $10,000 cheque from Apple.

Maybe. Look at his twitter page though: <a href="https:&#x2F;&#x2F;twitter.com&#x2F;lemiorhan" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;lemiorhan</a>Not impossible to believe he&#x27;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&#x27;t immediately know what they were.[1] <a href="http:&#x2F;&#x2F;jesuschristsiliconvalley-blog.tumblr.com&#x2F;post&#x2F;46537875392&#x2F;what-your-profile-picture-says-about-you-hint" rel="nofollow">http:&#x2F;&#x2F;jesuschristsiliconvalley-blog.tumblr.com&#x2F;post&#x2F;4653787...</a>

I would say it&#x27;s pretty basic common sense, not to publicly announce ANYTHING that could immediately affect millions of people. Unless he&#x27;s just a sociopath.From his Twitter account, he&#x27;s not just some layman stumbling across it.Agile Software Craftsman, iyzicoder @ <a href="http:&#x2F;&#x2F;www.iyzico.com" rel="nofollow">http:&#x2F;&#x2F;www.iyzico.com</a> , Founder of Software Craftsmanship Turkey @scturkey, The community guy <a href="http:&#x2F;&#x2F;bit.ly&#x2F;lemiorhan" rel="nofollow">http:&#x2F;&#x2F;bit.ly&#x2F;lemiorhan</a>

Also, it&#x27;s reasonable for someone to think that making a public stink about it is in the best interest of all the people then that can immediately patch it themselves instead of having to wait for Apple to push a patch and then for everyone to download that patch.I&#x27;m not convinced private disclosure is without its downsides nor a panacea.

Maybe he didn&#x27;t know about the proper procedures to handle a security vulnerability. You wouldn&#x27;t have to be a security researcher to discover this bug, and I don&#x27;t see any indication that he is one.

Sure, now look at his Twitter account. He looks pretty plugged into the software community.Agile Software Craftsman, iyzicoder @ <a href="http:&#x2F;&#x2F;www.iyzico.com" rel="nofollow">http:&#x2F;&#x2F;www.iyzico.com</a> , Founder of Software Craftsmanship Turkey @scturkey, The community guy <a href="http:&#x2F;&#x2F;bit.ly&#x2F;lemiorhan" rel="nofollow">http:&#x2F;&#x2F;bit.ly&#x2F;lemiorhan</a>

Isn&#x27;t the best practice full disclosure? It seems like it was followed well.

When I put it into my personal malice &#x2F; ignorance balance, it weighs out to the likelihood that the discloser isn&#x27;t plugged in enough to the infosec scene to be aware that there are already best practices for this kind of disclosure.It&#x27;s a big world out there, especially nowadays. And nothing I&#x27;ve seen in recent history suggests to me the average user knows or cares about infosec concerns beyond basic hindsight understandings.

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&#x27;t give you your 15 minutes of interweb fame.

It is disabled by default[1] (meaning you can&#x27;t login as it), this vulnerability appears to enable the root user without setting a password. If the root user has already been enabled it doesn&#x27;t work.Anyone who does this should probably set a password for now and then disable the root user account once it has been patched.[1] <a href="https:&#x2F;&#x2F;support.apple.com&#x2F;en-us&#x2F;HT204012" rel="nofollow">https:&#x2F;&#x2F;support.apple.com&#x2F;en-us&#x2F;HT204012</a>

The &quot;root&quot; superuser is always there, I&#x27;m not sure if it&#x27;s possible to actually delete it.

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

This support article explains how to disable the root user: <a href="https:&#x2F;&#x2F;support.apple.com&#x2F;en-us&#x2F;HT204012" rel="nofollow">https:&#x2F;&#x2F;support.apple.com&#x2F;en-us&#x2F;HT204012</a>

But you are creating the password for it.

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

I haven&#x27;t upgraded to High Sierra yet and this doesn&#x27;t happen on my install atm. Does adding a password to the root user stop this vulnerability? If it does then that seems way better than disabling the account until this is fixed.

You can simply set a root password with &quot;sudo passwd&quot; to close the hole.

It&#x27;s worse than that. You&#x27;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.

Until this is fixed it&#x27;s probably better to use Directory Utility to enable root with a strong password.&#x2F;System&#x2F;Library&#x2F;CoreServices&#x2F;Applications&#x2F;Directory Utility.appEdit &gt; Change Root Password

Be careful testing this! It appears that you&#x27;re creating a &quot;root&quot; superuser with no password. Be sure to clean up that user afterwords.<a href="https:&#x2F;&#x2F;twitter.com&#x2F;a_hailes&#x2F;status&#x2F;935601901839806464" rel="nofollow">https:&#x2F;&#x2F;twitter.com&#x2F;a_hailes&#x2F;status&#x2F;935601901839806464</a>

This is the first time I&#x27;ve felt happy I rarely upgrade.

Letting the development team know first is nice to the development team, but not so nice to the users (especially not-nice if there&#x27;s a workaround, which there is in this case.)My personal policy: If there&#x27;s a workaround or mitigation, then full disclosure is more responsible. If there isn&#x27;t then report to developers and CERT or similar. Never report only to developers, always have a deadline for full disclosure, and always have a third-party (CERT, Project Zero, etc) to disclose if you come under legal fire.

Seems to go for almost all issues regarding Apple. I&#x27;ve been reporting that calculator bug since iOS 9, with updates for several betas that it&#x27;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.

Time and time again we have been shown that the way to a company&#x27;s heart is through it&#x27;s PR department. This is a dev complaining to Apple like a lunchgoer would complain to Mc D&#x27;s about a bad burger. Expect more of it.

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

its such a braindead problem that its plausible that the person who disclosed it over twitter didn&#x27;t know what responsible disclosure is.  
Usually exploits are hard to exploit meaning that those who find them likely know of responsible disclosure. In this case though anyone who has ever installed Linux is capable of stumbling upon this.

If the vulnerability required scripting or special tools to be written, yes, it should be disclosed in private. But anyone can happen upon this, and I imagine the reaction for most is &quot;Huh! That&#x27;s funny! My friends and followers would get a kick out of this!&quot; He was just being social about a problem he found with his new computer, which is something most people would do upon finding a something you can laugh about.

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.

I can&#x27;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.

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

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.

Can&#x27;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&#x27;s the only machine I have available. I&#x27;m curious as to the difference, given the high number of repros.

Can&#x27;t reproduce on multiple High Sierra machines.

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

Doesn&#x27;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 ..

Fix this by setting a password for root (or disable).Instructions here: <a href="https:&#x2F;&#x2F;support.apple.com&#x2F;en-us&#x2F;HT204012" rel="nofollow">https:&#x2F;&#x2F;support.apple.com&#x2F;en-us&#x2F;HT204012</a>

If it does then it means Apple&#x27;s encryption implementation is fucked.

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.

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

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

It might, if you added &quot;root&quot; as a user able to unlock the disk. But you&#x27;d probably have needed to set a password for the root account to do that.

Confirmed on 10.13.1. As a workaround, once you login as &quot;root&quot;, you can change the password to something else, and the empty password will stop working.

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.

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

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

Standalone iMac here - the &#x27;Join&#x27; 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?

Alternatively, there&#x27;s `sudo passwd`.

In the meantime, if you&#x27;d like to protect your mac, you can set a password for root by going to:System Preferences &gt; Users &amp; Groups &gt; Login Options &gt; Join &gt; Open Directory Utility &gt; Edit &gt; Change Root Password

Ah, there&#x27;s no ShadowHashData or KerberosKeys nodes.  Presumably the code creating that plist is not aware that later on it&#x27;s going to be accessed thru layers of other software and end up as a usable login.  To quote Shrek: 
&quot;Software is like an onion&quot;.

These are the contents of the file, after converting them from binary plist to plain xml: <a href="https:&#x2F;&#x2F;gist.github.com&#x2F;shoghicp&#x2F;2b529b54b9d70daf192b68e3564b3f4f" rel="nofollow">https:&#x2F;&#x2F;gist.github.com&#x2F;shoghicp&#x2F;2b529b54b9d70daf192b68e3564...</a>

Confirming this works, both from preferences, as well as from the main login screenIt seems like root has no password by default. Setting one is enough to close the hole. This is unbelievable!Curious to see what&#x27;s in &#x2F;var&#x2F;db&#x2F;dslocal&#x2F;nodes&#x2F;Default&#x2F;users&#x2F;root.plist before trying this.

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

Works with &quot;su - root&quot; too in a Terminal.

Classical click and bait title.
First promises that you&#x27;ll become a hacker, and then when you actually click the tweet is deleted.

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

A quick mitigation workaround: If you follow the steps here <a href="https:&#x2F;&#x2F;support.apple.com&#x2F;en-us&#x2F;HT204012" rel="nofollow">https:&#x2F;&#x2F;support.apple.com&#x2F;en-us&#x2F;HT204012</a> to disable the root account until the point where you open and authenticate the Directory Utility, in the Edit menu there&#x27;s a &quot;Change Root Password&quot; 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&#x27;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.

I wouldn&#x27;t have thought that NSA backdoors are so simple

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

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

Once you disable the root account you can log in without a password again :&#x2F;

For those who can&#x27;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&#x27;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.

Exactly early versions of Windows XP had this: They removed the Administrator user from their graphical login splash but when booted in rescue mode (&quot;Safe mode&quot;) you could just type in &quot;Administrator&quot; with no password and were in. On Win98, you could just cancel the login.

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

Wow. This is fun. I remember my Windows98 had the same feature. You just use Administrator with empty password and you&#x27;re in. Apple is finally catching up.

macOS High Sierra: Anyone can login as “root” with empty password