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
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)
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.
Can this be used remotely? Edit: Yes, after turning on Remote Management on my second mac I was able to log into it using Remote Desktop, account root and no pw.
It only works after getting physical access once.
Yes, I just had a coworker test it after I enabled remote management and they used screensharing.app. I didn't even get notified a user remoted in.. never used screen share, that seems awful. Had to look over and ask if he was in.
edit: I should say, I did test this locally first so I don't know if a fresh machine that hasn't done it will do the same thing and let a remote account enable root.. Would like to hear if anyone tested it remotely WITHOUT doing it locally first.
It only works after getting physical access once to enable the root user by gibing any password UI the root user with no password (which will enable the local root account, which is also why it fails the first time around)
I tested this by logging in as root at a preference pane then attempting to connect via ssh and screen sharing (both enabled) using root with no password. It did not work.
Not sure if you'd get different results after logging in as root at the login screen...
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? ;)
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?
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.
I'm a Linux desktop (and laptop!) user, and I agree (I haven'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't respected their users' right to use, modify & 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's shoulders.
In my opinion they don't "owe" anyone that obligation, unless it's a contractual obligation associated with using a Mac. But just because it's not owed to anyone, doesn't mean there isn't a nicer way to handle it just to be nice.
That said, I don't immediately see evidence that this gentleman is in the security field, and perhaps isn't aware of responsible disclosure. Full disclosure isn't the worst thing in the world.
Twitter's also the goto for banning trans people from military service, attacking freedom of the press, threatening to declare nuclear war, and all kinds of other things too.
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].
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.
> 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.
How much of that code is safety critical? I occasionally see misbehavior from my Tesla's center screen, like the network connection failing, or audio glitches, or even the occasional spontaneous reboot. This can be mildly annoying but it doesn't worry me because I know that the center screen is separate from the stuff where bugs can actually get me killed.
"On Thursday October 24, 2013, an Oklahoma court ruled against Toyota in a case of unintended acceleration that lead to the death of one the occupants. Central to the trial was the Engine Control Module's (ECM) firmware.
Embedded software used to be low-level code we'd bang together using C or assembler. These days, even a relatively straightforward, albeit critical, task like throttle control is likely to use a sophisticated RTOS and tens of thousands of lines of code.
" [1] [2]
Sure. My point is just that you can't bring up the total number of lines of code here, because most of those lines aren't in any way related to any safety-critical system. If you want to talk about how much code there is which puts you at risk, you need to look at that particular subset of code.
I don't see any evidence that this exploit is related to the GUI at all. The GUI just happens to be the easiest way to do it. Other commenters have mentioned that you can use the exploit with `su`.
In any case, in a desktop system you shove everything together and then try to modularize it with good design and weak tools like UNIX processes. In a car, the safety-critical systems are literally running on separate hardware with limited communication over a specialized data bus. Of course it's still possible for them to have bugs or even exploits, but the complexity of the infotainment system is irrelevant, aside from making it a potential jumping-off point for using an exploit in the safety-critical systems.
Counting the infotainment system here makes about as much sense as counting the number of lines in Windows when talking about a Mac vulnerability because a Windows machine could be used to launch an attack.
"Apple root bug appears to be triggered only by logins coming from com.apple.loginwindow.
Running "su" with a blank password won't get you a root shell." [1]
Not so sure:
"Apple root bug appears to be triggered only by logins coming from com.apple.loginwindow. Running "su" with a blank password won't get you a root shell."
https://twitter.com/0xAmit/status/935609423485169664
You can't blame com.apple.loginwindow for that. The security boundary is at the login processing. If it processes requests differently from certain systems then it's misbehaving. If we wanted to make this secure we would only need to carefully craft it, and even if com.apple.loginwindow was the most complex heap of bugs in the world it wouldn't matter.
> The security boundary is at the login processing. If it processes requests differently from certain systems then it's misbehaving.
Which is my point. More code, more complexity, more bugs. If you are correct, the security boundary you are referring to got stretched out to accommodate a separate system.
As for your strategy on separating concerns and carefully crafting important code – don't you think that's what they originally had in mind when they first designed it?
I don't think the security boundary was actually expanded, I think it had a hole punched in it. I doubt the bulk of com.apple.loginwindow was coded to enforce that particular security at all.
loginwindow is not doing the wrong thing because it's complex. It's doing the wrong thing because that was never its job.
> don't you think that's what they originally had in mind when they first designed it?
Probably, but they didn't fail because loginwindow itself was complex. They failed either for systemic reasons that would have happened with simple or complex code, or they failed because the actual secure part was too complex. That's why I think total complexity is the wrong thing to look it; it may or may not correlate with those two real causes.
Every time a prototype has been pushed into production. Simple code, but not tested or polished or designed for performance. This happens constantly.
The drive encryption password hint bug looked like a symptom of something like that. The utility was rewritten in a rush, and it's probably not a whole lot of lines of code. But it didn't have even basic testing.
A prototype is of considerable less size than 100.000.000 loc. I claimed that complexity is correlated with lines of code. I pose the same question: Show me a simple system that failed due to systemic reasons.
> A prototype is of considerable less size than 100.000.000 loc.
Yes? Agreed? It's simple, and yet it fails, because of management problems. That kind of management issue can happen to simple code or complex code.
Are you asking me to name a failure that's simple and large/complex at the same time? I'm confused.
Let me restate my position:
You originally brought up total lines of code. mikeash made a point that it's not total lines of code, it's code in relevant system, like ECU or the login service. I'm arguing in support of that point.
Complexity correlates with lines of code. But different subsystems can have different complexities. Especially when they're written by different teams.
The fact that the login service had special behavior wrt com.apple.loginwindow does not mean the complexity of com.apple.loginwindow is a notable factor. Com.apple.loginwindow was almost certainly not designed to enforce the security guarantees that the login service is responsible for. Its role could be played by either very complex code, or very simple code.
If the login service failed because of complex code, it failed because it was made of complex code. Not the total across the entire system.
Go ahead and pretend I never mentioned "systemic reasons" if it makes my argument make more sense to you. That was only about a possible scenario where the problem wasn't complex code. If complex code is the problem, then "systemic reasons" are utterly irrelevant. You don't need to argue that "systemic reasons" are complexity in disguise. Just delete that phrase entirely from my argument.
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.
Which is a legitimate fear, and substantial effort should go into preventing such bugs, but any sufficiently determined person doesn't need to exploit a software bug to be able to kill others. ISIS appears to be quite effective at simply convincing its members to directly and voluntarily engage themselves in such acts.
Yeah, but we're dealing with an order of magnitude difference if we give them control over > 1Million mobile bombs (ie 1 large self-driving car network).
I imagine a Twilight Zone episode... Go back in time to before cars were invented and imagine some Mephistopheles offering the bargain: "You'll fly like the wind over hills and mountains, making a journey of days in mere hours!" What the catch? "For each mile traveled a certain number of people chosen at random must be put to death or maimed."
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...
("Also, it will poison the air and water, and force you to become dependent on fuel sources that destroy life and engender wars.")
Well to be fair there are more positives to cars than just cutting journey times. But I agree the negatives are massing hugely as the world's driving population pullulates.
As for human readiness to safely control a tonne of speeding metal, my position as a full-time motorcyclist makes me extremely confident that the average alleged 'driver' (actually: daydreamer, snot-picker, instagrammer) isn't even approaching the edge of the competence ballpark.
I think the question you're fundamentally asking is "are we ready for imperfect systems with potential vulnerabilities?", and the answer to that question has been the same since the advent of software.
wat. confirmed on 10.13.1 (17B48). I was even able to add another super user.
Edit: changing the login method to "Name and password" under login options, then logout and login with "root" with empty password also works.
Fortunately, it doesn't work on cold boot with FileVault enabled, at least it doesn't appear so. `sudo su root` also doesn't work with an empty password.
Good point. Force of habit. Unfortunately I can no longer try since I set the root password under the Directory Utility, which probably changed the state of the system.
Apparently someone verified that it /does/ also work with `su - root`.
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.
Apple makes it pretty easy to report vulnerabilities to:
product-security@apple.com
They also respond to security@apple.com but prefer the product-security address.
Further, there are any number of legit bug bounty programs out there like ZDI that would pay for a bug like this then immediately disclose to Apple for it to be fixed.
Disclosing an 0Day root authentication bypass vulnerability on Twitter isn't cool, even if it is local: think of the impact to shared iMacs on university campuses.
If you leave keys in other people's doors all over the neighbourhood, I damn well have a rigtht, and possibly an obligation, to make it publicly known that such a thing is taking place. So that everyone may take their own precautions.
Let's say keys were hidden around the neighborhood. Would you rather everyone in the whole town know about it or quietly and quickly go pick up all the keys before someone notices and breaks into one of the houses?
Personally I think if you report through the proper channels and nothing is changed THEN broadcast, but not as an opener.
In determining whether keys-in-locks or keys-under-doormats is the closer analogy, I have to go with the doormats. Various people go door-to-door... delivery people, campaign volunteers, Jehovah's Witnesses, etc. and a key in the lock would be hard to miss. A key under a doormat is easy to miss, being obscure. Sure -- the doormat is one of the first places you look if you're actually trying to break in, but people whose nefarious side doesn't manifest until the opportunity is obvious are indeed thwarted by that obscurity.
I am going to ask, do you want to try this scenario on your own in real life? Because often we make general statements while we don’t actually practice what we say to others when the issue is going to hurt ourselves.
But do YOU want to have your good neighbor report to tou that your key has been left on the poach before someone takes it away and then get into the house when you are away from home on Thanksgiving night celebrating a nice holiday vacation? I bet you not. The fault is on you for dropping the key, isn’t it? Or you are so bluntly careless to have a backup key left under the mat on your poach which slided away and the key is now revealed.
The fact locks are easy to pick doesn’t mean people don’t take more measures to defend it. More and more people install steel door as an extra layer and home security surveillance system, all of which can be compromised with the right tools.
Responsible disclosure is something I respect. While he has the right to not disclose this privately first, has he tried? How hard is it to ask someone to get in contact with the Apple security team? There are a bunch of top sec researchers on Twitter constantly tweeting) to help escalate this. I think someone on Google zero project team did this to escalate.
Responsible Disclosure is widely regarded as a good practice in these situations. Blame isn't the key issue - fixing the problem quickly and safely is. Widespread disclosure before Apple have even a chance to respond in a timely fashion is inherently unsafe.
You would hope the self-described twitter bio "Agile Software Craftsman" might have thought about this a little before tweeting.
The poster practiced Full Disclosure, which is also a valid disclosure policy.
Since we're just making up statements, I guarantee that Apple would never voluntarily disclose this issue if it was reported privately. So Full Disclosure is the only way to put Apple's feet to the fire, as it's the only way in which this issue would have had any visibility whatsoever.
If there was a vulnerability that allowed anyone to open your car and drive off with it, you wouldn't care if he was the first to find it or not. You'd only care about it getting fixed before anyone else knows about it.
I'm not sure what length grace period is appropriate, though.
If there was a vulnerability that allowed anyone to open my car, I'd want to known ASAP, because I wouldn't trust the manufacturer to provide a remedy quickly enough that eliminates my risk.
Same applies for Apple. No reason to believe this guy was the first one to find this exploit, we only know he was the first one to publicize it.
"Responsible Disclosure" is a term rejected by the industry as a loaded phrase that favors vendors, instead preferring the term Coordinated Disclosure. Even so, reasonable professionals still disagree that this is the best option, in a debate that has existed for decades, so it's by no means settled as the "proper" way.
The problem with that analogy is that the probability that the "bad guys" already know about this vulnerability is vastly higher than the probability that thieves know about how well some random house in the neighborhood is secured.
But do they? And what portion of them do? And are they using it? There's a lot of speculation here. But surely the average person doesn't know and with this being public knowledge, AND easy to execute there is a bigger chance for crime of opportunity.
It’s always reasonable to assume that black-hats (and… what do you call government hackers — black-suits, helicopter-hats, ???) know everything that white-hats know, and that they either have or are already in the process of selling that exploit to less skilled criminals.
It’s not like being good morally correlates with being good at security.
But that's not what I'm saying. I'm saying that since this is so easy, a person that is computer illiterate can now gain root access. You definitely don't post those kinds of things on Twitter.
Computer illiterate people might now have a new way to shoot themselves in the foot, they won’t be able to exploit it because they won’t know what root is or why it does stuff.
How many more people now know about this vulnerability cause of this knuckle-head tweeting it? At least 100k impressions? Now think of how many more "bad guys" have access to this hack that are going to abuse it.
You may say so, but really the level of incompetence of not setting a password for a root account is pretty high. The fact that someone reported it in a way you don't agree with shouldn't distract you from the fact that this highlights a serious oversight.
The main question that should be asked is, how did this get overlooked? How is it that your average website has better password security than the OS of one of the richest tech companies in the world?
To be fair to Apple, Microsoft had similar issues back in the 1990s. Perhaps it takes a string of security blunders for some tech companies to take security seriously.
A better analogy would be "if the lending bank left the door to your new house open..."
Other than buy an Apple product, the users did nothing intentional to undermine security.
Since this is a subjective argument, based more on historical instances of "responsible disclosure" and not law, I'm gonna lean in this case of it being Apple that failed
They built the entire "walled garden" without getting outside help. They want the control, they have billions of dollars, can hire whatever talent...
Failed to spot a password-less root login issue.
People need to know today to be even more cautious about using Apple gear in public places or around plain ol' tech jerks that like to fuck with people for a gag.
Society has no legal or moral obligation to make sure Apple stays in business.
Responsible disclosure is an interesting concept. How does this kind of disclosure make sure that the public knows about a company's track record of vulnerabilities, if everyone is under NDA and the company has no obligation to ever publicize it?
Now, if the reseacher could give a grace period, that's cool, but there MUST be a deadline by which stuff goes public. Hopefully the company fixes it and issues a postmortem first. If not - too bad!
This very excellent comment lies "dead", so I'll repost it:
asejfwe8823 24 minutes ago [dead] [-]
A better analogy would be "if the lending bank left the door to your new house open..."
Other than buy an Apple product, the users did nothing intentional to undermine security.
Since this is a subjective argument, based more on historical instances of "responsible disclosure" and not law, I'm gonna lean in this case of it being Apple that failed
They built the entire "walled garden" without getting outside help. They want the control, they have billions of dollars, can hire whatever talent...
Failed to spot a password-less root login issue.
People need to know today to be even more cautious about using Apple gear in public places or around plain ol' tech jerks that like to fuck with people for a gag.
Society has no legal or moral obligation to make sure Apple stays in business.
If you sell locks and those locks can be opened by pulling on them twice, the reasonnable course of action is to make that fact known to every buyer ASAP, not tell you privately and wait for you to maybe issue a recall.
Locks don't nag you to decommission them quite as aggressively as OS X asks you to patch it. And an OS update was going to happen anyway, so including this patch doesn't really burden the user with an extra task they wouldn't already be subject to. Therefore, coordinated disclosure has a lot of value in the OS update ecosystem and very little in the physical lock ecosystem.
This is different though: the bug is so bad that random, inexpert users can discover it by accident. People that are not going to even be familiar with the term "responsible disclosure" at all. This may have been the case for the guy who tweeted this.
There is no realistic way to keep a lid on something like that and so in this case the blame is entirely on Apple.
>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.
That's not a faithful analogy. Apple isn't your neighbour. They are the landlord. The scenario is more like that the landlord uses bogus locks in your complex, and you post it on twitter. You could complain to them privately too, but given your past experiences perhaps, you thought that twitter would be a more effective medium.
I get it, I really do, but it'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'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.
It's as remotely acceptable as "root" with no password, apparently.
The question is large and complicated, and people can agree to disagree. There's nothing wrong with tweeting vulns: The company is at fault, we can defend ourselves now that we know about the vuln, and it's a big PR disaster for Apple.
No, no it's not strictly more ethical. It's not even strictly safer, which should be an even easier question to answer. The baked-in assumption in your logic is that users have no options other than waiting to patch. But, obviously, they do, and keeping vulnerabilities secret deprives them of those options.
But everyone can fix this problem by setting a root password. So telling everyone is the right call. Otherwise people would be sitting vulnerable while Apple comes up with a patch.
But a tweet isn't really the most effective way to tell everyone. Technical people, including those who would use this vulnerability for malice, will find out far far sooner than my grandmother.
It seems to me the right thing to do is to tell Apple privately, tell them to either push a fix or put out some kind of release letting all their customers know how to mitigate this in the next, say, 3 days, or I'll just tweet about it. What's the downside? At the worst case, you just prolonged the status quo for another 3 days.
I agree this person isn't malicious, certainly. But I do think his decision was bad. Not "bad" in the moral sense, but "bad" in the sense of being sub-optimal.
In a case like this, I think it would be best to maximize the bad publicity. Bad publicity is the minimum Apple deserves for a bug like this. In my idea world they'd get a lot of bad publicity, and a significant financial penalty.
Is it likely it's just an error due to the discoverer not being immersed in the Infosec space? "Don't disclose a 0-day publicly" is good 'common' sense, but only among the 'common' of people who are steeped in security issues and the ramifications of publicizing them.
Indeed, discovering this bug wouldn'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't think this person was one, and it'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.
Project Zero does full disclosure 90 days after informing the relevant organization. Full disclosure comes after there has been a chance to fix the problem. Otherwise everyone is put at risk until a fix is available.
Google Project Zero does not support full public disclosure immediately- quite the opposite. They support full public disclosure after giving the vendor an opportunity to ship a fix to their customers in a reasonable period of time. Nobody's debating whether or not security flaws should be publicly disclosed- of course they should. The only debate is, what is the most responsible way to handle such a security issue such that it harms the fewest users.
Project Zero (and infosec professionals, at least all of the ones I've ever worked with) would tell you that this was the most irresponsible way to handle the issue, short of not saying anything and selling knowledge of the exploit to someone other than the vendor who could fix it. Publicizing something like this in this way is something people do because they want publicity for themselves. It is not something someone does if their biggest concern is for the users who might be affected by it. It is something someone would do if they didn't care about the users, and just wanted public credit for pointing it out.
You added the word "immediately", making that a straw man. I did not say they disclose immediately. Their policy is still full disclosure, including working proof-of-concept exploit code, even when the vulnerability is unpatchable and millions are affected. Ask Microsoft and Apple about the times they went beyond 90 days.
Furthermore, that deadline is 7 days if they are aware of active exploitation.
DJB is famous for his full disclosure with no advanced warning stance.
The rest of your post is false. That is your opinion, and people disagree. I'm going to guess you have not personally spoken with folks from project zero. I have spoken with some of them. And trust me, they would not agree with your statement. A few of them even feel strongly that their timelines are far too generous. I also understand their reasoning, and it has nothing to do with ego or publicity, and everything to do with concern for users.
They do not give a shit about credit beyond believing that it is proper to cite the authors of any work. That isn't the case for everyone finding bugs, but people on that team lost the novelty of having their name on bug reports long ago.
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.
The 'sign in as root with no password' 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/null combo is Remote Management.
I don't think they meant using this vulnerability to enable a root remote connection, but using an existing non-root remote connection (think TeamViewer, VNC, whatever) and escalating.
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.
Blame the DMCA. This guy is in Turkey - does GP really think he can expect fair treatment and equal compensation as a "western world" security researcher?
There's no reason why the person who discovered the bug would be safer publishing the vulnerability on Twitter than disclosing it to Apple directly. If nothing else, they could always post it on Twitter later. The link to the DMCA is a digression.
You could let them know about the vulnerability and wait until it's been patched before commenting, with some timeout where if they don't patch in a reasonable amount of time you announce it anyway.
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.
And Full disclosure is about protecting users of a software, not letting the vendor off the hook. Here, the hack and the fix are so trivial the responsible thing to do is to publicly call out Apple for its lack of QA and warn users directly. It affects everybody who runs High Sierra.
> it puts millions of Apple customers at risk in the process.
Nah, it's Apple which put millions of customers at risk, not the person who disclosed the vulnerability. let's not shift away the blame from the guilty here.
Apple one of the richest company in the world is obviously just cutting corners in QA here. This is unacceptable.
it's seems some people here are more concerned about negative publicity than user security. This is a pattern that have been seen countless times in big tech corporations(such as Yahoo), not disclosing hacks that put their users and their data at risk. This is unacceptable for a company that claims to be all about their users.
I would argue that releasing this vulnerability as irresponsibly as he did is showing he cares more about negative publicity than user security.
Yes, it's Apple's fault for poor QA that this was released, but this guy also put users at risk by telling the entire world about it without giving Apple a chance to fix it.
You're right, it's about user security before publicity. So make sure users are safe first.
You can follow your own procedures - decide for yourself how long you think it is reasonable for the company to mitigate in private. But give the company some time.
Why? You're not an employee, you're a concerned citizen. You havr no obligations to vendors whatsoever. Now, I think it's nice to do responsible disclosure, and I certainly don't envy the people whose week has been ruined, but the discoverer of this bug did nothing wrong.
It is about the increased risk fellow users will have due to this style of disclosure. Who cares about the vendor, but they are best situated to resolve the issue quickly for everyone.
> Nah, it's Apple which put millions of customers at risk, not the person who disclosed the vulnerability. let's not shift away the blame from the guilty here.
Disclosing 0day vulnerability via Twitter for the sake of self promotion is bad. Especially when you advertise yourself as a software developer.
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.
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.
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.
Closed disclosure is responsible disclosure. Moving past the terminology, I am an Apple user as well, I am pretty satisfied with how quickly Apple resolves issues.
Now if every person started disclosing vulnerabilities via twitter without giving the company turn around time to resolve the issue based on their dissatisfaction with Apple based on standards they came up with personally, I don’t think it is nice or fair.
This is a rather limited view point. You forget the majority of macOS users are NOT technically savy. This is why responsible disclosure is so important as it gives tech companies time to create and push a fix to protect their users.
Disclosing this immediately puts those people who can't setup enable the root and set its password into more harm's way.
> You forget the majority of users are NOT technically savy.
Fixed that for you.
Sorry, I'm not going to cater to the lowest common denominator of "users". If my system has a hole, I want to know so I can get in a fix or shut down that particular feature until its fixed by a vendor.
Ive only 60k machines and 40 clients that depend on that decision. And they agree with me. If something's broke, I can analyse how it breaks and if it impacts us. If it does, we can triage it. I can do a damage assessment. I certainly can't do that if it's being sold on the darknets and whispered.
Yes. Ideally you would also ping me in your public release, so I know whom to pay. Because that would also for be the users benefit to know to either fix, firewall, or not use until software is deployed.
I've seen the dark side where this leads. It leads to BTC transactions and 0days bought and sold. That's the worst, further past scrappy company sitting on exploits.
I strongly believe in transparency. It empowers users and admins more than any other option out there.
> I want to know so I can get in a fix or shut down that particular feature until its fixed by a vendor.
That assumes you can shut down that particular feature without crippling your business operations. If my system had a hole, I'd prefer that it were disclosed to the vendor before it's disclosed to hackers, adversaries and foreign governments.
> Disclosing this immediately puts those people who can't setup enable the root and set its password into more harm's way.
Let's be clear - Apple put their users in harms way by letting a bug of this nature slip past testing. Disclosing "responsibly" would certainly be nicer to users, but mostly it would be nice for Apple by helping mitigate the bad publicity.
I think the responsible way to handle it is, you inform Apple in a closed way. Once they come up with a fix, if you think they didn’t come up with a fix soon enough, make that information public then on how long it took Apple to turn this around. Disclosing every vulnerability to the internet and setting their ass on fire is not a good way to solve this IMO.
Not the attitude of the people reporting the issue have put "millions of apple customers" at risk, but the company which allowed to let issues like this one slip through their Q&A process.
IMO, this behaviour is part of the problem, the reason why tech companies take security only on a superfiscial level seriously.
I think this incorrectly interprets my comment. I am not defending apple or blaming the individual that disclosed the vulnerability on Twitter. I am simply pointing out that putting users at additional risk because you want to see Apple hurt may be misguided. We have responsible disclosures in place for a reason.
I'm now seeing cases of non technical people trying this because they heard about it and it's easy. To them, it just unlocks some system preferences thing. Guess what those people are not doing after they try it? 'passwd root' to change the password because in many cases they don't even know what the terminal is.
In this particular case, the ease of validation additionally works against users.
I dont understand the implied correlation between, what you call, irresponsible disclosure and "wanting to hurt apple". Where did you get this impression from?
Thanks, you are right. If he refers this post (which i believe he does), he is indeed right.
Anyhow, personally i wouldn't exclude something like this, e.g. suing, as a last resort. Anything that changes apples attitude towards security or at the very least, enhancing the value of security as a product qualifier.
I do get the impression that you do blame the individual, as you have attributed unsavory motivations to his behavior. Why do you care to make such a loose statement about this person having a petty motive of malice?
One of the grandparent posts specifically said they supported the tweet because it would hurt Apple, and I think bradrydzewski is responding to those comments.
A bug like 'can log in with password "root"/""' just isn't going to get you a grace period no matter what security researchers might want.
I mean, this bugs has been reported already - by every cheesy hacking movie ever, by every beginners book on social engineering and so-forth. Heck, it was "reported" by Richard Feynman talking about cracking safes during the Manhattan.
Pretty sure every cheesy hacker film doesn't have the root password being empty. They usually put in "password" or the favourite music band of the target.
Why not? The end goal is protecting users. If disclosing a vulnerability before a company has a chance to fix it puts more users at risk than waiting how is that not irresponsible?
Considering the vulnerability was supposedly brought to Apple's attention a month earlier via the "proper" channels, and considering Apple's history of repeatedly ignoring and dismissing said disclosures, I'd say this was the only correct action to take.
The very comment you are replying do lists a reason why disclosing huge vulnerabilities without providing upstream time to patch is irresponsible: "because it puts millions of Apple customers at risk in the process."
Your comment doesn't refute the reasoning the comment you are replying to provides, and it also doesn't tell us anything about why you think "There is nothing irresponsible about disclosing huge vulnerabilities in software by any means necessary." You state your position, but offer no rationale, no reason for it; why should I accept your position as the correct or ethical thing to do?
> Encouraging irresponsible disclosure because one wants to see Apple hurt is a reckless and selfish attitude because it puts millions of Apple customers at risk in the process.
Apple put millions of their customers at risk by skimping on QA. As an Apple user I'm OK with this getting out if it motivates Apple to improve their approach in the future.
This is such a lame vulnerability that it's probably already known to competent attackers.
It's not a bug; it's a bad design decision. How to initialize the root password on a new machine is a hard problem in a consumer environment. Some people will set it, lose it, and then want support to fix it. One would expect some clever Apple solution, such as initializing the password to random letters and providing the buyer with that info on a scratch-off card. That way, the buyer can be sure no one has seen the password before they use the scratch-off card.
Setting it to null? That means nobody thought about the problem.
My understanding is that the first attempt is creating/enabling the root account with a blank password and that the subsequent login is actually utilizing it (which is kind of bizarre and probably why this was missed in testing).
root IS an admin in macOS. You just cannot use root the same way you expect root to work in other Unix OS' without changing stuff in the BIOS (or whatever it's called for Apple) but you can still do most admin things with root. However root does get admin privileges, but when it comes to some system directories he is banned till you "fix" root privileges.
The first time I tried it, it just worked. I'm certain I've used root before. On the GUI portion it works with no password, but on the terminal it does not let me login as root without a password. Some weird OS magic must be going on there?
AFAIK usually sudo doesn't let you enter an empty string as a password, even when the actual password is empty. So that is what you might be experiencing.
it worked for me on 6th try or so. First few times, the prompt was returning to my user name, but then another failed attempt left it at 'root', and the next attempt succeeded
Why does it need to create a lot of negative publicity for Apple? Is there something you don't like about them? Responsible disclosure needs to be valued given the number of macs out there in the wild that could potentially be susceptible to issues like this, and the impact it could have on people (including you) not just directly but indirectly.
How would you feel if someone discovered a 0day at a company that exposes credit card and identity info, published the 0day, then hackers steal all that info (including yours)? I'm sure 'creating a thunderstorm of negative publicity' would be the last thing you would want.
I don’t see it as either/or. You can disclose responsibly, and go for publicity once the fix is in circulation. Responsible disclosure is nothing to do with protecting Apple, it’s about protecting the users.
Far too many people think of Apple as infallible. I often think even Apple thinks of themselves as infallible. The more people that are aware of the inherent risk involved with using computers - any computer - the better.
The problem is that this is not a zero day in new technology. They made a jr sysadmin mistake. As a company who wants a reputation for good security, that is not acceptable.
You mean, in addition to bad QA and complete disregard for their users' security? And being the richest and most profitable company ever, cutting corners and evading taxes?
Their response on Twitter was amazing: "PM us so we can discuss this privately", not "thank you, we're looking into it NOW".
I suspect the response on Twitter was a typical reply from a tier 0 support person. No reason to extrapolate from that to the company's internal response.
Apple is a Rorschach test writ large. What people see in it reflects more on the observer than the company in many cases.
I think there's a middle ground to this. Submit your report to Apple security, allow them time to develop a patch, and then in a week go ahead and tweet at the big media outlets about it.
I'm a die-hard Apple user myself, but I agree that the long list of severe bugs in High Sierra is absurd, and a big public backlash might be enough to kick them into gear. On the other hand, I, a university student with next to no understanding of computer security, can simply walk onto campus, sit down at a Mac, and within seconds have complete access to the computer. It's ridiculous, it's horrendous that it shipped like this, but it's not something that needed to get out, especially something so easy to utilize.
The fact that you as the ordinary student can become root and create a lot of damage so easily is the only reason the public will care.
Us geeks have been complaining about the horrible QA in macOS for years, yet nothing has been done. The fact that this is so simple to do will probably/hopefully get ordinary people to start talking about it too ("Hey, have you heard that you can hack Macs without a password? Very insecure"), which would force Apple to improve.
It sounds to me like you're arguing that full disclosure in this situation could lead to a worse outcome for users in the short term, but the negative publicity will force Apple to improve their security posture, leading to a better outcome for users in the long term. (Please let me know if I'm miss-characterizing your argument)
I think you have to be very careful about that line of argument. It's a single vulnerability researcher making a unilateral decision about the short term and long term security of an entire user base, based entirely on personal judgement. I personally think the researcher should make the decision that best protects users from that specific vulnerability. Making long-term changes to a company's QA should come second.
> I personally think the researcher should make the decision that best protects users from that specific vulnerability.
I find it odd that you're putting the responsibility of making decisions about how to protect Apple's users on an unaffiliated third party.
Apple has a multi-hundred-billion dollar war chest and, if they wanted to, could afford to make macOS the most secure operating system on the market. The fact that they don't is their own choice and a reflection of their priorities, not some act of God or a natural disaster. Putting the onus for cleaning up the mess in the most "responsible" way possible on third parties with a fraction of Apple's resources is being too kind to Apple.
My point was exactly the opposite of putting the onus on the researcher. I support responsible disclosure. In responsible disclosure, the researcher informs the vendor (Apple) and leaves it to them to coordinate informing people of mitigations and pushing out a patch. If the vendor fails to respond or make progress in a certain period of time, the researcher can inform the public. It specifically puts the responsibility for dealing with the vulnerability in the hands of the vendor.
Maybe it's crazy that we give people physical access to machines and expect them not to be able to obtain root.
I don't have any experience with enterprise-grade IT, but it seems like shared computers should be thin clients or at least use UEFI to securely boot an image over the network and not keep anything sensitive locally.
If you give someone physical access to a box, they will be able to own it.
This is actually how the public workstations in MIT computer clusters have always worked. The root password is public to anyone with a legit account, but access to it gets you almost nothing because all services including the network filesystem are kerberized, and machines are really good at wiping all local changes upon logout. Some more details here: https://www.quora.com/Are-computer-networks-in-MIT-harder-to...
> On the other hand, I, a university student with next to no understanding of computer security, can simply walk onto campus, sit down at a Mac, and within seconds have complete access to the computer.
its educational for the end user. You cannot trust Apple. Good reminder there are other OS available out there.
Yes Apple shouldn't be having this issue but disclosing a 0-day issue can possibly hurt users far worse than hurting Apple. Apple may lose a tiny bit of money but users could lose far, far more especially if someone develops a good way to remotely deploy / take advantage of this defect.
Ignoring responsible disclosure also limits the ability to sue them for any damage resulting from it (or so I'm told by one of my lawyer friends who thinks this disclosure may make it almost impossible to successfully sue them over it unless it simply takes them too long to fix).
How can that happen in any case ? Isn't pretty much the first line in every license waiving of liability ? Unless you have some special contract with Apple that overrides other standard boxes that you ticked, how would anyone sue ?
Does anybody have any info on how much Apple would've been likely to pay for a responsible disclosure in this case, given the scope and severity of the issue?
I'm just curious how much of a payday this guy missed out on by not disclosing responsibly.
AFAICT, Apple's security bounty program is officially only for their preselected group of security researchers.
In the course of developing my current application, I'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/company listed in the release notes (which they are, for the latest 10.13 update, along with a CVE#).
This happens quite often. Report a bug to Apple through CERT as an example and they run with a well known 45 day disclosure timeline. For researchers who don't want to get into vendor conflicts this is a good path because CERT ultimately holds the decision.
They've been quick (within 45 days) to patch every major bug I've reported to them and where the bugs were cross platform, impacting Windows, Android, etc., they've consistently been amongst the quickest to issue a patch so I'm not sure how you qualify that statement.
I qualified it with "reliably". Major bugs reported by you, a security researcher, may be bucketed differently than those deemed less serious or filed by others. As a recent example, a minor bug like the iOS 11 calculator ignoring keypresses had reports filed since Beta 1, but only after it made headlines and caused Apple public embarrassment will it be addressed in the upcoming 11.2, six months later.
Actually, no. For all computers, running macOS High Sierra, a computer with a root password is a whole heck of a lot more secure than one without a root account at all :)
But seriously, a fix is whatever fixes the problem.
It is now. There's going to be a whole lot of people who are going to set a root password because they read an article online recommending it, then install the update that fixes this issue. Now they're stuck with a root password when they could have not had one at all.
Making it difficult to access something is always worse than not having anything to access. Plus, the average person will set their root password to something like 123456 or qwerty, which is clearly insecure.
> Making it difficult to access something is always worse than not having anything to access.
Not a choice now. If people have physical access to Macs at the moment then it seems to me there are two options right now: either 1) you have changed the root password, hopefully to a strong password or 2) they'll be able to login as root.
Right now you can expect the participants in this thread to be a little smarter than the average computer user.
> Now they're stuck with a root password when they could have not had one at all.
And many users will create insecure passwords, leaving them with a serious vulnerability after the patch. A password of "root" or "qwerty" is only marginally more secure than a blank one.
Could the patch also handle this case? Can you create a root account in OS X?
If it was previously possible to create a root account then I guess there's no way to tell the difference between those who created the password as a response to the vulnerability and those that knowingly created a root account.
Yes, you can. macOS ships with the account disabled by default, but you can re-enable it if you wish. Most of the time there is no reason to do so.
> If it was previously possible to create a root account then I guess there's no way to tell the difference between those who created the password as a response to the vulnerability and those that knowingly created a root account.
Yes, but this difference doesn't matter. By creating a root account you have made your computer less secure anyways, assuming that we didn't have the current issue at hand.
I assume he means that you should always set a password for "root". Though most users don't even knows it exists.. hence it should have been taken care of by apple.
Uhg, ok I forgot some people don't know the code. The old adage is "On your first day as the new sysadmin, change all the root passwords". The idea is that a SECURE root is good, possibly better than no root (which is sort of a hack in itself). There are best practices for root passwords. Things like length, composition (no dict words), disabled for remote access, and care in who is allowed to have it.
Simply pretending root does not exist is a rather new idea and is not best practice. It's only for convenience.
This is an outmoded guideline for password security. String enough dictionary words together and you achieve a high level of entropy. See for example https://en.wikipedia.org/wiki/Diceware
Seems like you are splitting hairs here. Clearly, the point the commenter was making is that people that have now set the root password as a result of the tweet are more secure than they were before the tweet.
That's a whole week where they can get owned by any kid with physical access to the machine. In some settings (schools, libraries) this might be a huge issue.
> 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.
It gets the word out quickly.
Releasing proprietary software with such a hilariously insecure authentication system isn't cool. This isn't free software, produced by people & corporations out of the goodness of their hearts; rather, it'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's a huge insecurity and b) it'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).
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'm not an apple user.
https://www.google.com/search?q=apple+report+security+bug does bring https://support.apple.com/en-us/HT201220 right up, but that page documents "how security researchers, developers, law enforcement personnel, and journalists can contact Apple to report or ask about a security issue" -- notably absent from that set is "your average Joe who stumbled upon something entirely by accident" for some reason.
Let's wait until Apple release their patch so we know just how long they left everyone's machines vulnerable for. That will be a factor in determining whether this disclosure was irresponsible or not. It's been two and a half hours so far.
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.
A better analogy is that there's a fire somewhere in your village, but it's mostly contained (it's not spreading, because other people don't know about it yet). By hollering about it, you'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.
Uhh, no. How are you getting that impression? I'm simply saying that arsonists exist, and it's probably a good idea to make it harder for them to burn things down than to publicly advertise a way for them to do it.
Do you live in some horrible place where your neighbors will throw gas on your burning house unless you can quickly and quietly get the fire department there first, to put out the fire that the FIRE DEPARTMENT started?
It's an analogy (and it's not mine, mind you; I simply tried to make it more accurate)–don't take it too literally. Hacking is a thing that exists. By reporting this publicly it's become a lot easier to hack people.
> you've made it possible for anyone to go to the fire, light a torch with it
And at the same time provided everyone with a simple, free, and perfect way to fireproof his/her house.
You could wait for the fire department, which may take hours to get there, and hope that no malicious party down the street saw the fire, or you can do this. It turns out that both are quite reasonable reactions in this scenario, and that the latter is much more obvious to the layman.
There is no good reason to get angry at the layman for taking a course you don't prefer.
> And at the same time provided everyone with a simple, free, and perfect way to fireproof his/her house.
The issue here is that it isn't perfect in the long run (having a root account with a password is worse than not having one) and many people will not be adopting it since they're not in the know.
Of course, it is always possible people have been already exploiting this, but most likely it is at most a small number of people who know about it. Now every script kiddie in the world can and will go around trying to hack anyone who isn't well-informed enough to know how to protect themselves.
Responsible disclosure is pretty much a security industry concept, it's not something that most developers know about, complaining on Twitter is probably what an average person would do.
Although for what it'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).
Wow I didn't believe this at first, so I dug more. AWIS requires the root key of an AWS account. I found a forum that does suggest creating a new account solely for AWIS.
Still I'm surprised they would suggest sending the root key to your account over http. Even if it is just the id and not secret it still seems like something you want to keep secure. I don't use my root key for services. I create new accounts and IAM roles.
> 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?
But it is not nearly as uncool as releasing software to millions of paying customers containing a 0Day. Who knows how many people already knew about this and other 0Days and have said nothing?
The carelessness in releasing software with 0Days is especially unforgivable when the company has more cash on hand to pay employees than any company in history. What is their excuse?
Apple can afford the very best. Their customers pay the most. But the software they release, no matter what their user may want to imagine, is most certainly not the very best.
It is not even as good as open source BSD from which OSX is derived, maintained by unpaid volunteers, which does not allow remote logins as root without a password.
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/or the protocol regarding 0-day vulnerabilities.
I'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'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 "hey look, a wallet!" then walking away.
It seems to me (somebody who has no chops in this domain) that this is such a basic bug. Like something a child would have found just messing around.
And it came from a corporation that has around $200B of cash and cash equivalents. Apple has the resources to test and find bugs like this.
That Apple didn't find it is down to leadership and priorities more than some inherent limits of producing reliable code. One spends on what one thinks important.
But who knows, I've got no domain expertise here. Maybe a fifth of a trillion dollars C&CE really isn't enough to fund production of more robust code. But really?
This is kind of a weird corner case; OSX tries really hard to hide the UNIXiness of its system, including the special nature of the username "root". So I can easily someone not thinking to test it out super thoroughly
A lot of security vulnerabilities are of this type: "let's do crazy shit X that the system was not built for and see what breaks." I'm sure this will be in their test suite now though.
Maybe Apple should spin up a group of 7 - 14 year-olds to add to their test suite input. They might be better at coming up with crazy shit X that might break things.
After the developers there is a line of QA as well, but part of the problem is having the organisational structures for developers to discover issues like this. Regular audits, security as a priority and non-recrimination policies would be a good start. In many companies if you bring up problems like this then your "not a team player", in others you could point out issues like this all day long but they will never be acted upon because the budget isn't there for various reasons.
There is a simple workaround. Publicity means security here.
It's trivial to find. He can't presume he is the only one who found it. Telling any individual that doesn't have malicious intent is a good thing, therefore telling everyone is a good thing.
> there are any number of legit bug bounty programs
The 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 "I Love My Mac" 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?
Not really; the issue is that you don'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't, you go test someone else's software. Reputation is everything.
> Disclosing an 0Day root authentication bypass vulnerability on Twitter isn't cool
no one is under any obligation to sweep company'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't ship broken software if you don't want pie in your face.
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.
If it harms the company then they will take it more seriously and it will protect users more in future. If it doesn't harm the company then they have no incentive to change.
In almost all cases immediate disclosure is better for end users who actually care about their security because they can take appropriate mitigation measures.
Just because the vulnerability is not disclosed does not mean it is not being actively exploited. It probably is.
Users who don't care about their security do not deserve to be "protected" at the expense of compromising the security of those who do care who benefit from immediate disclosure.
There is no "responsible disclosure". 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'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't blame the messenger.
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.
How dare you publicly shame him and risk his future employability like this? It'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's like there's one rule for the negligent global corporation which happens to work in the corporation'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.
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.
Yeh, except for the millions of MacOS users out there, like my parents who don't read Twitter, or HN or any of the other sites people think that everyone stays up on. They are the targets.
Not technically. Exploitation still requires physical access to the machine or remote access to have been enabled, right? Did your parents who don't read Twitter or HN enable a feature that generally only power users want or need?
Probably could still get 15 minutes of fame if you disclosed privately then blogged about the back and forth and a picture of the $10,000 cheque from Apple.
That this would be the prevailing understanding is exactly why a bug like this would live in the wild at all. There are plenty of other orgs out there who would have paid big money for this.
Source? I've heard of iPhone vulnerabilities getting high six figures from Apple (for root access via sms). Why wouldn't Apple pay for something like this?
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.
Not impossible to believe he's unaware of the right way of handling this kind of issue, but that banner photo (Enthralling My F-ing Audience) [1] and stats there suggest he should be aware that there probably are sensible and polite procedures for this, even if he didn't immediately know what they were.
He is giving a technical talk to a large audience. Slides refer to development, and bio implies this means software development. Bio uses the phrase 'founder of software craftsmanship Turkey'.
Following the link to his home page we find:
"He has worked as software architect, software craftsman, technical leader, team leader, technical coordinator, Scrum Master and Agile coach in dozens of software projects at BYM, GittiGidiyor / eBay and Sony."
and
"Lemi Orhan Ergin is a Software craftsman, passionate developer, technical architect, Agile culture cultivator, Agile coach, Scrum / Kanban practitioner and trainer, Management 3.0 trainer, experienced mentor, engineering booster, Git trainer and lover, the TDD guy, clean coder, infected with the technical side of Agile, presentation and visualization freak, non-stop learner, full time apprentice of my masters, the community guy."
It's possible this guy was oblivious to the idea that there's a good way to share this information with Apple / The World At Large, and consequently did not attempt to find out the preferred way of doing it, but I don't buy it.
I guess I am, but it's more than a belief that 'active programmer ==> familiarity with responsible disclosure'.
First, he is an active developer - his resume cites big shops such as ebay and Sony (many years). It's possible that most of his bug reports at those places come through tweets, but it's more likely he's had some exposure to formal disclosure processes.
Second, he follows some thousand people on twitter, has been active in IT for nearly two decades, is a founder of a couple of tech / dev groups. As I say, it's possible he's unaware that there are mechanisms to advise vendors of major security holes beyond tweeting to the world.
Third, I wonder what he was thinking when he did post that on twitter. As in, even being unaware of generic, or Apple-specific, responsible disclosure mechanisms, what does one imagine will happen when you discover a massive hole in a popular platform and decide to just tell the world. I'm disturbed that someone with this level of IT experience and credentials didn't consider consequences here.
Fourth, a corollary to that last one, if you do spend a brief moment contemplating the consequences, it should be a fairly short process to then wonder if there's a better mechanism, and that mechanism is pretty easy to discover.
I would say it's pretty basic common sense, not to publicly announce ANYTHING that could immediately affect millions of people. Unless he's just a sociopath.
From his Twitter account, he's not just some layman stumbling across it.
If that were true, then the security community wouldn't have spent years fighting about whether responsible disclosure was the right approach. That's for people who actually understand this stuff. It's unreasonable to expect an outsider to derive it all on their own from first principles.
So someone stumbles upon a lost cache of chemical weapons. Rather than reporting to the authorities, they post its location on Twitter. That's called just using your brain.
You're coming at this from a position of knowledge and assuming everyone else knows as much as you do, or should be able to figure it out in short order. That's not how it works. It's really hard to see how other people might think in situations like this.
The guy is a self professed "Agile Software Craftsman". I could give some leeway to my average friend finding this, but he's pretty involved with this community.
Security though obscurity is no security at all. Don't you think the people living around the chemical weapons should be informed too so they can take precautions to protect themselves?
Also, it's reasonable for someone to think that making a public stink about it is in the best interest of all the people then that can immediately patch it themselves instead of having to wait for Apple to push a patch and then for everyone to download that patch.
I'm not convinced private disclosure is without its downsides nor a panacea.
When I put it into my personal malice / ignorance balance, it weighs out to the likelihood that the discloser isn't plugged in enough to the infosec scene to be aware that there are already best practices for this kind of disclosure.
It's a big world out there, especially nowadays. And nothing I've seen in recent history suggests to me the average user knows or cares about infosec concerns beyond basic hindsight understandings.
He's a manager. CSM, PSM1, PSD1, Scrum Master, Kanban Practitioner. Code retreat facilitator. Translated Agile Manifesto into Turkish. The only thing that immediately makes me think he even touches code is "git trainer and lover." Notably lacking from his résumé: references to specific open source projects he's worked on or code he's written (though personally, I'd be concerned because his résumé does list "Restful Services" and I'd expect that to have given him a taste of infosec basics, but maybe it's a bit of résumé padding... shouldn't it be spelled "RESTful services?" ;) ).
It feels weird to say for those of us deeply immersed in the internet / telecoms / web app side of software development, but depending on your focus, you can do an awful lot of software development without ever brushing up against the sharp edge of infosec.
It is disabled by default[1] (meaning you can't login as it), this vulnerability appears to enable the root user without setting a password. If the root user has already been enabled it doesn't work.
Anyone who does this should probably set a password for now and then disable the root user account once it has been patched.
Having tested this by both approaches (disabling through GUI & shell), the above (through shell) seems to prevent this from re-occurring when you attempt to perform this bogus login again. Disabling the account via the GUI causes the failure to re-occur.
It'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.
I haven't upgraded to High Sierra yet and this doesn't happen on my install atm. Does adding a password to the root user stop this vulnerability? If it does then that seems way better than disabling the account until this is fixed.
And you might want to disable the root account again with `dsenableroot -d` as well, so that the root account stays disabled after the vulnerability is patched.
Unlike doing this through the GUI, this seems to retain the root password and prevent this vuln from re-occuring.
Bizarrely though, you can still use the root user (with the password that you set) to login to the Directory Utility even while it is supposed to be disabled... This behaviour seems super weird.
Yeah I've noticed this myself - I'm on the fence as to whether this is actually disabling the account or simply creating that impression (it does show as disabled in Directory Utility after you perform this command).
My hope in recommending people disable this way is that with the additional scrutiny on this subsystem, accounts disabled this way will remain genuinely disabled in a future update. Either way this doesn't seem to reintroduce the bug.
As far as I can tell, "dsenableroot -d" seems to have no useful effect. After having "* Successfully disabled root user." with it, I can still log in to the root account with the password I set, both at the command line with "login" and from a remote machine via screen sharing.
To be flippant, I might say HN discussions seem to QA using Apple methods.
1,119 comments
[ 2.1 ms ] story [ 545 ms ] threadedit: I stand corrected. The 'require password' setting under Security Preferences didn't change, but other settings do. Yikes
I think I'll hold off on that 10.13.1 "security update" it keeps bugging me about. Seems to let anyone use my computer...
Edit: After looking a little further, it seems staying on Sierra will always be a 10.12.* version, and High Sierra is 10.13.*?
- Mavericks (10.9.x)
- Yosemite (10.10.x)
- El Capitan (10.11.x)
- Sierra (10.12.x)
- High Sierra (10.13.x)
I've upgraded a through a couple versions of OS X on this machine - maybe that makes a difference?
edit: I should say, I did test this locally first so I don't know if a fresh machine that hasn't done it will do the same thing and let a remote account enable root.. Would like to hear if anyone tested it remotely WITHOUT doing it locally first.
Not sure if you'd get different results after logging in as root at the login screen...
While it's unlikely, there are probably plenty of users who have done this for some reason or another.
Don't underestimate a user's ability to blindly do things like this by following arcane instructions in attempts to fix an unrelated problem.
https://www.youtube.com/watch?v=FpOH0lxEGBE
They seem to be remotely accessing the machine to both set and then use the root account.
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? ;)
So lets keep the snark to an appropriate level, shall we?
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.
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't respected their users' right to use, modify & 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's shoulders.
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
To whom does he owe that obligation? Apple? The public? Both? Why?
That said, I don't immediately see evidence that this gentleman is in the security field, and perhaps isn't aware of responsible disclosure. Full disclosure isn't the worst thing in the world.
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
[2] https://www.youtube.com/watch?v=4G1Boh-URIM
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.
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.
Embedded software used to be low-level code we'd bang together using C or assembler. These days, even a relatively straightforward, albeit critical, task like throttle control is likely to use a sophisticated RTOS and tens of thousands of lines of code. " [1] [2]
[1] https://www.edn.com/design/automotive/4423428/Toyota-s-kille...
[2] https://www.embedded.com/electronics-blogs/barr-code/4214602...
On the surface, this particular exploit on macOS seems to be caused by a totally unrelated subsystem (security vs. GUI).
In any case, in a desktop system you shove everything together and then try to modularize it with good design and weak tools like UNIX processes. In a car, the safety-critical systems are literally running on separate hardware with limited communication over a specialized data bus. Of course it's still possible for them to have bugs or even exploits, but the complexity of the infotainment system is irrelevant, aside from making it a potential jumping-off point for using an exploit in the safety-critical systems.
Counting the infotainment system here makes about as much sense as counting the number of lines in Windows when talking about a Mac vulnerability because a Windows machine could be used to launch an attack.
As for your subsystem argument, explain this: https://www.youtube.com/watch?v=OobLb1McxnI&feature=youtu.be...
[1] https://twitter.com/0xAmit/status/935609423485169664
That video is explained by using the infotainment systems as a bridge, exactly as I described in my previous comment.
But it's still wrong to focus on total complexity. You want to look at the complexity of the relevant system.
Which is my point. More code, more complexity, more bugs. If you are correct, the security boundary you are referring to got stretched out to accommodate a separate system.
As for your strategy on separating concerns and carefully crafting important code – don't you think that's what they originally had in mind when they first designed it?
loginwindow is not doing the wrong thing because it's complex. It's doing the wrong thing because that was never its job.
> don't you think that's what they originally had in mind when they first designed it?
Probably, but they didn't fail because loginwindow itself was complex. They failed either for systemic reasons that would have happened with simple or complex code, or they failed because the actual secure part was too complex. That's why I think total complexity is the wrong thing to look it; it may or may not correlate with those two real causes.
The drive encryption password hint bug looked like a symptom of something like that. The utility was rewritten in a rush, and it's probably not a whole lot of lines of code. But it didn't have even basic testing.
Yes? Agreed? It's simple, and yet it fails, because of management problems. That kind of management issue can happen to simple code or complex code.
Are you asking me to name a failure that's simple and large/complex at the same time? I'm confused.
Let me restate my position:
You originally brought up total lines of code. mikeash made a point that it's not total lines of code, it's code in relevant system, like ECU or the login service. I'm arguing in support of that point.
Complexity correlates with lines of code. But different subsystems can have different complexities. Especially when they're written by different teams.
The fact that the login service had special behavior wrt com.apple.loginwindow does not mean the complexity of com.apple.loginwindow is a notable factor. Com.apple.loginwindow was almost certainly not designed to enforce the security guarantees that the login service is responsible for. Its role could be played by either very complex code, or very simple code.
If the login service failed because of complex code, it failed because it was made of complex code. Not the total across the entire system.
Go ahead and pretend I never mentioned "systemic reasons" if it makes my argument make more sense to you. That was only about a possible scenario where the problem wasn't complex code. If complex code is the problem, then "systemic reasons" are utterly irrelevant. You don't need to argue that "systemic reasons" are complexity in disguise. Just delete that phrase entirely from my argument.
If ISIS was able to hack a major fleet through one such bug, do you think for a single moment they wouldn't make use of it to kill many people?
I imagine a Twilight Zone episode... Go back in time to before cars were invented and imagine some Mephistopheles offering the bargain: "You'll fly like the wind over hills and mountains, making a journey of days in mere hours!" What the catch? "For each mile traveled a certain number of people chosen at random must be put to death or maimed."
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...
("Also, it will poison the air and water, and force you to become dependent on fuel sources that destroy life and engender wars.")
As for human readiness to safely control a tonne of speeding metal, my position as a full-time motorcyclist makes me extremely confident that the average alleged 'driver' (actually: daydreamer, snot-picker, instagrammer) isn't even approaching the edge of the competence ballpark.
Firstly, car automation is machine learning, not programming. Completely incomparable.
Finally, we've known how to prove the absence of bugs for decades. It's not a matter of not knowing how, it's about incentives to do it right.
Edit: changing the login method to "Name and password" under login options, then logout and login with "root" with empty password also works.
Fortunately, it doesn't work on cold boot with FileVault enabled, at least it doesn't appear so. `sudo su root` also doesn't work with an empty password.
Apparently someone verified that it /does/ also work with `su - root`.
product-security@apple.com
They also respond to security@apple.com but prefer the product-security address.
Further, there are any number of legit bug bounty programs out there like ZDI that would pay for a bug like this then immediately disclose to Apple for it to be fixed.
Disclosing an 0Day root authentication bypass vulnerability on Twitter isn't cool, even if it is local: think of the impact to shared iMacs on university campuses.
The fact that we know about it means we can take steps to mitigate the damage.
There is blame on both.
If you leave your key in your front door lock and I blast out on twitter your address and tell people about it, I think I have some responsibility.
Personally I think if you report through the proper channels and nothing is changed THEN broadcast, but not as an opener.
The fact locks are easy to pick doesn’t mean people don’t take more measures to defend it. More and more people install steel door as an extra layer and home security surveillance system, all of which can be compromised with the right tools.
Responsible disclosure is something I respect. While he has the right to not disclose this privately first, has he tried? How hard is it to ask someone to get in contact with the Apple security team? There are a bunch of top sec researchers on Twitter constantly tweeting) to help escalate this. I think someone on Google zero project team did this to escalate.
You would hope the self-described twitter bio "Agile Software Craftsman" might have thought about this a little before tweeting.
> https://en.wikipedia.org/wiki/Responsible_disclosure
Since we're just making up statements, I guarantee that Apple would never voluntarily disclose this issue if it was reported privately. So Full Disclosure is the only way to put Apple's feet to the fire, as it's the only way in which this issue would have had any visibility whatsoever.
https://en.wikipedia.org/wiki/Full_disclosure_(computer_secu...
I think on the (probably intentionally snarky) basis of "just making up statements":
> Since we're just making up statements, I guarantee that Apple would never voluntarily disclose this issue if it was reported privately.
This guy is, with all probability, not the first one to have found it.
I'm not sure what length grace period is appropriate, though.
Same applies for Apple. No reason to believe this guy was the first one to find this exploit, we only know he was the first one to publicize it.
True, and this is where the analogy breaks down, since they would not be able to remotely send over a fix. But Apple would, and apparently now has.
It’s not like being good morally correlates with being good at security.
The main question that should be asked is, how did this get overlooked? How is it that your average website has better password security than the OS of one of the richest tech companies in the world?
To be fair to Apple, Microsoft had similar issues back in the 1990s. Perhaps it takes a string of security blunders for some tech companies to take security seriously.
Other than buy an Apple product, the users did nothing intentional to undermine security.
Since this is a subjective argument, based more on historical instances of "responsible disclosure" and not law, I'm gonna lean in this case of it being Apple that failed
They built the entire "walled garden" without getting outside help. They want the control, they have billions of dollars, can hire whatever talent...
Failed to spot a password-less root login issue.
People need to know today to be even more cautious about using Apple gear in public places or around plain ol' tech jerks that like to fuck with people for a gag.
Society has no legal or moral obligation to make sure Apple stays in business.
Responsible disclosure is an interesting concept. How does this kind of disclosure make sure that the public knows about a company's track record of vulnerabilities, if everyone is under NDA and the company has no obligation to ever publicize it?
Now, if the reseacher could give a grace period, that's cool, but there MUST be a deadline by which stuff goes public. Hopefully the company fixes it and issues a postmortem first. If not - too bad!
asejfwe8823 24 minutes ago [dead] [-]
A better analogy would be "if the lending bank left the door to your new house open..." Other than buy an Apple product, the users did nothing intentional to undermine security. Since this is a subjective argument, based more on historical instances of "responsible disclosure" and not law, I'm gonna lean in this case of it being Apple that failed They built the entire "walled garden" without getting outside help. They want the control, they have billions of dollars, can hire whatever talent... Failed to spot a password-less root login issue. People need to know today to be even more cautious about using Apple gear in public places or around plain ol' tech jerks that like to fuck with people for a gag. Society has no legal or moral obligation to make sure Apple stays in business.
I'd lay responsibility at the lockmaker's door, not the guy who told everybody they were at the mercy of anyone with a toothpick.
There is no realistic way to keep a lid on something like that and so in this case the blame is entirely on Apple.
That's not a faithful analogy. Apple isn't your neighbour. They are the landlord. The scenario is more like that the landlord uses bogus locks in your complex, and you post it on twitter. You could complain to them privately too, but given your past experiences perhaps, you thought that twitter would be a more effective medium.
The question is large and complicated, and people can agree to disagree. There's nothing wrong with tweeting vulns: The company is at fault, we can defend ourselves now that we know about the vuln, and it's a big PR disaster for Apple.
A past conversation: https://news.ycombinator.com/item?id=14009937
No, no it's not strictly more ethical. It's not even strictly safer, which should be an even easier question to answer. The baked-in assumption in your logic is that users have no options other than waiting to patch. But, obviously, they do, and keeping vulnerabilities secret deprives them of those options.
> There's nothing wrong with tweeting vulns
Those two statements seem to be contradictory. It seems to me there is still quite a lot of debate about which disclosure policy is best,
It seems to me the right thing to do is to tell Apple privately, tell them to either push a fix or put out some kind of release letting all their customers know how to mitigate this in the next, say, 3 days, or I'll just tweet about it. What's the downside? At the worst case, you just prolonged the status quo for another 3 days.
The idea of responsible disclosure is to minimize harm for you, the user. Not to minimize bad publicity.
https://www.theregister.co.uk/2016/08/05/apple_joins_the_bug...
LMAO. It's called a "job"
Project Zero (and infosec professionals, at least all of the ones I've ever worked with) would tell you that this was the most irresponsible way to handle the issue, short of not saying anything and selling knowledge of the exploit to someone other than the vendor who could fix it. Publicizing something like this in this way is something people do because they want publicity for themselves. It is not something someone does if their biggest concern is for the users who might be affected by it. It is something someone would do if they didn't care about the users, and just wanted public credit for pointing it out.
Furthermore, that deadline is 7 days if they are aware of active exploitation.
DJB is famous for his full disclosure with no advanced warning stance.
The rest of your post is false. That is your opinion, and people disagree. I'm going to guess you have not personally spoken with folks from project zero. I have spoken with some of them. And trust me, they would not agree with your statement. A few of them even feel strongly that their timelines are far too generous. I also understand their reasoning, and it has nothing to do with ego or publicity, and everything to do with concern for users.
They do not give a shit about credit beyond believing that it is proper to cite the authors of any work. That isn't the case for everyone finding bugs, but people on that team lost the novelty of having their name on bug reports long ago.
Once the root user has been enabled locally, the only sharing settings I found to permit anyone remote access with the root/null combo is Remote Management.
This isn't the first extremely serious and dumb High Sierra password bug this year [1] [2], and unless Apple is severely hurt by it, so they're forced to change, it won't be the last. High Sierra is full of bugs and seemingly not just annoying bugs, but also security bugs.
Let's hope Apple gets sued for the damage they'll cause by including this bug in High Sierra so they make sure that next release of macOS won't be another bug filled mess.
[1] https://arstechnica.com/information-technology/2017/09/passw...
[2] https://www.macrumors.com/2017/10/05/macos-high-sierra-disk-...
https://www.eff.org/deeplinks/2017/10/drms-dead-canary-how-w...
Blame the DMCA. This guy is in Turkey - does GP really think he can expect fair treatment and equal compensation as a "western world" security researcher?
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.
> it puts millions of Apple customers at risk in the process.
Nah, it's Apple which put millions of customers at risk, not the person who disclosed the vulnerability. let's not shift away the blame from the guilty here.
Apple one of the richest company in the world is obviously just cutting corners in QA here. This is unacceptable.
it's seems some people here are more concerned about negative publicity than user security. This is a pattern that have been seen countless times in big tech corporations(such as Yahoo), not disclosing hacks that put their users and their data at risk. This is unacceptable for a company that claims to be all about their users.
Yes, it's Apple's fault for poor QA that this was released, but this guy also put users at risk by telling the entire world about it without giving Apple a chance to fix it.
You're right, it's about user security before publicity. So make sure users are safe first.
Nowadays, you're "irresponsible" if you don't follow some vendor's own made up procedures.
Disclosing 0day vulnerability via Twitter for the sake of self promotion is bad. Especially when you advertise yourself as a software developer.
I don't want to see Apple hurt (I'm an Apple-guy myself, using Macs, iPhone, iPad and Apple Watch), I want to see them improve. I doubt they start will start caring about QA unless they're forced to.
One absurdly serious and stupid password bug like this can be a honest mistake, but three (that we know of, that were full disclosures) in a few months is negligence that should be criminal if it isn't.
Now if every person started disclosing vulnerabilities via twitter without giving the company turn around time to resolve the issue based on their dissatisfaction with Apple based on standards they came up with personally, I don’t think it is nice or fair.
A root password solves this issue. Its seconds to implement and helps right now.... Not "later" as closed disclosure does.
I'd rather know every error and critical bug. I can bring up with our team and decide now to either sudo service * stop or continue.
Your closed options keep the fact I'm vulnerable away, along with any pathways I might have to fix.
Disclosing this immediately puts those people who can't setup enable the root and set its password into more harm's way.
Fixed that for you.
Sorry, I'm not going to cater to the lowest common denominator of "users". If my system has a hole, I want to know so I can get in a fix or shut down that particular feature until its fixed by a vendor.
Ive only 60k machines and 40 clients that depend on that decision. And they agree with me. If something's broke, I can analyse how it breaks and if it impacts us. If it does, we can triage it. I can do a damage assessment. I certainly can't do that if it's being sold on the darknets and whispered.
I've seen the dark side where this leads. It leads to BTC transactions and 0days bought and sold. That's the worst, further past scrappy company sitting on exploits.
I strongly believe in transparency. It empowers users and admins more than any other option out there.
That assumes you can shut down that particular feature without crippling your business operations. If my system had a hole, I'd prefer that it were disclosed to the vendor before it's disclosed to hackers, adversaries and foreign governments.
Let's be clear - Apple put their users in harms way by letting a bug of this nature slip past testing. Disclosing "responsibly" would certainly be nicer to users, but mostly it would be nice for Apple by helping mitigate the bad publicity.
IMO, this behaviour is part of the problem, the reason why tech companies take security only on a superfiscial level seriously.
Don't kill the Messenger.
EDIT: putting users at _additional_ risk
In this particular case, the ease of validation additionally works against users.
edit: Typo.
Anyhow, personally i wouldn't exclude something like this, e.g. suing, as a last resort. Anything that changes apples attitude towards security or at the very least, enhancing the value of security as a product qualifier.
I mean, this bugs has been reported already - by every cheesy hacking movie ever, by every beginners book on social engineering and so-forth. Heck, it was "reported" by Richard Feynman talking about cracking safes during the Manhattan.
https://www.jwz.org/xscreensaver/toolkits.html
That said, I wouldn't visit jwz's blog at work anyway.
Edit: as usual, downvotes but no response. I miss when this place was decent.
The very comment you are replying do lists a reason why disclosing huge vulnerabilities without providing upstream time to patch is irresponsible: "because it puts millions of Apple customers at risk in the process."
Your comment doesn't refute the reasoning the comment you are replying to provides, and it also doesn't tell us anything about why you think "There is nothing irresponsible about disclosing huge vulnerabilities in software by any means necessary." You state your position, but offer no rationale, no reason for it; why should I accept your position as the correct or ethical thing to do?
Apple put millions of their customers at risk by skimping on QA. As an Apple user I'm OK with this getting out if it motivates Apple to improve their approach in the future.
It's not a bug; it's a bad design decision. How to initialize the root password on a new machine is a hard problem in a consumer environment. Some people will set it, lose it, and then want support to fix it. One would expect some clever Apple solution, such as initializing the password to random letters and providing the buyer with that info on a scratch-off card. That way, the buyer can be sure no one has seen the password before they use the scratch-off card.
Setting it to null? That means nobody thought about the problem.
One would think that something as simple as a login would be deterministic.
Edit:
See: https://stackoverflow.com/a/33272796 for a bit more information of what I mean.
How would you feel if someone discovered a 0day at a company that exposes credit card and identity info, published the 0day, then hackers steal all that info (including yours)? I'm sure 'creating a thunderstorm of negative publicity' would be the last thing you would want.
You mean, in addition to bad QA and complete disregard for their users' security? And being the richest and most profitable company ever, cutting corners and evading taxes?
Their response on Twitter was amazing: "PM us so we can discuss this privately", not "thank you, we're looking into it NOW".
Apple is a Rorschach test writ large. What people see in it reflects more on the observer than the company in many cases.
I'm a die-hard Apple user myself, but I agree that the long list of severe bugs in High Sierra is absurd, and a big public backlash might be enough to kick them into gear. On the other hand, I, a university student with next to no understanding of computer security, can simply walk onto campus, sit down at a Mac, and within seconds have complete access to the computer. It's ridiculous, it's horrendous that it shipped like this, but it's not something that needed to get out, especially something so easy to utilize.
Us geeks have been complaining about the horrible QA in macOS for years, yet nothing has been done. The fact that this is so simple to do will probably/hopefully get ordinary people to start talking about it too ("Hey, have you heard that you can hack Macs without a password? Very insecure"), which would force Apple to improve.
I think you have to be very careful about that line of argument. It's a single vulnerability researcher making a unilateral decision about the short term and long term security of an entire user base, based entirely on personal judgement. I personally think the researcher should make the decision that best protects users from that specific vulnerability. Making long-term changes to a company's QA should come second.
I find it odd that you're putting the responsibility of making decisions about how to protect Apple's users on an unaffiliated third party.
Apple has a multi-hundred-billion dollar war chest and, if they wanted to, could afford to make macOS the most secure operating system on the market. The fact that they don't is their own choice and a reflection of their priorities, not some act of God or a natural disaster. Putting the onus for cleaning up the mess in the most "responsible" way possible on third parties with a fraction of Apple's resources is being too kind to Apple.
Unfortunately, I don't believe those will happen.
I don't have any experience with enterprise-grade IT, but it seems like shared computers should be thin clients or at least use UEFI to securely boot an image over the network and not keep anything sensitive locally.
If you give someone physical access to a box, they will be able to own it.
its educational for the end user. You cannot trust Apple. Good reminder there are other OS available out there.
It's about protecting systems RIGHT NOW from immediately causing harm to people's lives.
If so, why? How do you identify companies like Apple that get one set of rules to other companies?
Yes Apple shouldn't be having this issue but disclosing a 0-day issue can possibly hurt users far worse than hurting Apple. Apple may lose a tiny bit of money but users could lose far, far more especially if someone develops a good way to remotely deploy / take advantage of this defect.
Ignoring responsible disclosure also limits the ability to sue them for any damage resulting from it (or so I'm told by one of my lawyer friends who thinks this disclosure may make it almost impossible to successfully sue them over it unless it simply takes them too long to fix).
How can that happen in any case ? Isn't pretty much the first line in every license waiving of liability ? Unless you have some special contract with Apple that overrides other standard boxes that you ticked, how would anyone sue ?
I'm just curious how much of a payday this guy missed out on by not disclosing responsibly.
In the course of developing my current application, I'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/company listed in the release notes (which they are, for the latest 10.13 update, along with a CVE#).
This vulnerability is ridiculous, unacceptable, and braindead to execute.
They've been quick (within 45 days) to patch every major bug I've reported to them and where the bugs were cross platform, impacting Windows, Android, etc., they've consistently been amongst the quickest to issue a patch so I'm not sure how you qualify that statement.
I'm sure Apple will in the future.
But seriously, a fix is whatever fixes the problem.
Not a choice now. If people have physical access to Macs at the moment then it seems to me there are two options right now: either 1) you have changed the root password, hopefully to a strong password or 2) they'll be able to login as root.
Right now you can expect the participants in this thread to be a little smarter than the average computer user.
And many users will create insecure passwords, leaving them with a serious vulnerability after the patch. A password of "root" or "qwerty" is only marginally more secure than a blank one.
If it was previously possible to create a root account then I guess there's no way to tell the difference between those who created the password as a response to the vulnerability and those that knowingly created a root account.
Yes, you can. macOS ships with the account disabled by default, but you can re-enable it if you wish. Most of the time there is no reason to do so.
> If it was previously possible to create a root account then I guess there's no way to tell the difference between those who created the password as a response to the vulnerability and those that knowingly created a root account.
Yes, but this difference doesn't matter. By creating a root account you have made your computer less secure anyways, assuming that we didn't have the current issue at hand.
Simply pretending root does not exist is a rather new idea and is not best practice. It's only for convenience.
Says who? Sure, it's convenient not to have to worry about choosing a secure password for your root account, but why is it "sort of a hack in itself"?
This is an outmoded guideline for password security. String enough dictionary words together and you achieve a high level of entropy. See for example https://en.wikipedia.org/wiki/Diceware
The same actions can be a hack or not, depending on what they're accomplishing.
It gets the word out quickly.
Releasing proprietary software with such a hilariously insecure authentication system isn't cool. This isn't free software, produced by people & corporations out of the goodness of their hearts; rather, it'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's a huge insecurity and b) it'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).
Dude. That was your example.
And at the same time provided everyone with a simple, free, and perfect way to fireproof his/her house.
You could wait for the fire department, which may take hours to get there, and hope that no malicious party down the street saw the fire, or you can do this. It turns out that both are quite reasonable reactions in this scenario, and that the latter is much more obvious to the layman.
There is no good reason to get angry at the layman for taking a course you don't prefer.
The issue here is that it isn't perfect in the long run (having a root account with a password is worse than not having one) and many people will not be adopting it since they're not in the know.
Of course, it is always possible people have been already exploiting this, but most likely it is at most a small number of people who know about it. Now every script kiddie in the world can and will go around trying to hack anyone who isn't well-informed enough to know how to protect themselves.
Although for what it'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).
Wait, what?
The other day I actually ran across some AWS docs which suggest you send your AWS root key id in the url of http requests:
http://docs.aws.amazon.com/AlexaWebInfoService/latest/index....
https://forums.aws.amazon.com/thread.jspa?threadID=126537
Still I'm surprised they would suggest sending the root key to your account over http. Even if it is just the id and not secret it still seems like something you want to keep secure. I don't use my root key for services. I create new accounts and IAM roles.
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?
But it is not nearly as uncool as releasing software to millions of paying customers containing a 0Day. Who knows how many people already knew about this and other 0Days and have said nothing?
The carelessness in releasing software with 0Days is especially unforgivable when the company has more cash on hand to pay employees than any company in history. What is their excuse?
Apple can afford the very best. Their customers pay the most. But the software they release, no matter what their user may want to imagine, is most certainly not the very best.
It is not even as good as open source BSD from which OSX is derived, maintained by unpaid volunteers, which does not allow remote logins as root without a password.
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/or the protocol regarding 0-day vulnerabilities.
It'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 "hey look, a wallet!" then walking away.
And the only way Apple gets motivated to fix either of those two things is massive Pr damage.
Human fallibility, yo.
It seems to me (somebody who has no chops in this domain) that this is such a basic bug. Like something a child would have found just messing around.
And it came from a corporation that has around $200B of cash and cash equivalents. Apple has the resources to test and find bugs like this.
That Apple didn't find it is down to leadership and priorities more than some inherent limits of producing reliable code. One spends on what one thinks important.
But who knows, I've got no domain expertise here. Maybe a fifth of a trillion dollars C&CE really isn't enough to fund production of more robust code. But really?
A lot of security vulnerabilities are of this type: "let's do crazy shit X that the system was not built for and see what breaks." I'm sure this will be in their test suite now though.
Maybe Apple should spin up a group of 7 - 14 year-olds to add to their test suite input. They might be better at coming up with crazy shit X that might break things.
There is no justification for releasing a 0day publicly.
It's trivial to find. He can't presume he is the only one who found it. Telling any individual that doesn't have malicious intent is a good thing, therefore telling everyone is a good thing.
The 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 "I Love My Mac" 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?
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't, you go test someone else's software. Reputation is everything.
no one is under any obligation to sweep company'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't ship broken software if you don't want pie in your face.
Just because the vulnerability is not disclosed does not mean it is not being actively exploited. It probably is.
Users who don't care about their security do not deserve to be "protected" at the expense of compromising the security of those who do care who benefit from immediate disclosure.
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.
The PGP key is available here: https://support.apple.com/en-us/HT201214
I wonder what percentage of emails to security@... (apple.com or otherwise) are sent encrypted...
How dare you publicly shame him and risk his future employability like this? It'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's like there's one rule for the negligent global corporation which happens to work in the corporation'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.
Source: Information Security 101
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...
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.
First, he is an active developer - his resume cites big shops such as ebay and Sony (many years). It's possible that most of his bug reports at those places come through tweets, but it's more likely he's had some exposure to formal disclosure processes.
Second, he follows some thousand people on twitter, has been active in IT for nearly two decades, is a founder of a couple of tech / dev groups. As I say, it's possible he's unaware that there are mechanisms to advise vendors of major security holes beyond tweeting to the world.
Third, I wonder what he was thinking when he did post that on twitter. As in, even being unaware of generic, or Apple-specific, responsible disclosure mechanisms, what does one imagine will happen when you discover a massive hole in a popular platform and decide to just tell the world. I'm disturbed that someone with this level of IT experience and credentials didn't consider consequences here.
Fourth, a corollary to that last one, if you do spend a brief moment contemplating the consequences, it should be a fairly short process to then wonder if there's a better mechanism, and that mechanism is pretty easy to discover.
From his Twitter account, he's not just some layman stumbling across it.
Agile Software Craftsman, iyzicoder @ http://www.iyzico.com , Founder of Software Craftsmanship Turkey @scturkey, The community guy http://bit.ly/lemiorhan
I'm not convinced private disclosure is without its downsides nor a panacea.
It's a big world out there, especially nowadays. And nothing I've seen in recent history suggests to me the average user knows or cares about infosec concerns beyond basic hindsight understandings.
Agile Software Craftsman, iyzicoder @ http://www.iyzico.com , Founder of Software Craftsmanship Turkey @scturkey, The community guy http://bit.ly/lemiorhan
He's a manager. CSM, PSM1, PSD1, Scrum Master, Kanban Practitioner. Code retreat facilitator. Translated Agile Manifesto into Turkish. The only thing that immediately makes me think he even touches code is "git trainer and lover." Notably lacking from his résumé: references to specific open source projects he's worked on or code he's written (though personally, I'd be concerned because his résumé does list "Restful Services" and I'd expect that to have given him a taste of infosec basics, but maybe it's a bit of résumé padding... shouldn't it be spelled "RESTful services?" ;) ).
It feels weird to say for those of us deeply immersed in the internet / telecoms / web app side of software development, but depending on your focus, you can do an awful lot of software development without ever brushing up against the sharp edge of infosec.
https://twitter.com/a_hailes/status/935601901839806464
Anyone who does this should probably set a password for now and then disable the root user account once it has been patched.
[1] https://support.apple.com/en-us/HT204012
sudo passwd -u root
It's sad we have to do this, though.
Unlike doing this through the GUI, this seems to retain the root password and prevent this vuln from re-occuring.
I've tested both approaches - disabling via the GUI causes this bug to re-occur next time you try, disabling via the shell does not.
My hope in recommending people disable this way is that with the additional scrutiny on this subsystem, accounts disabled this way will remain genuinely disabled in a future update. Either way this doesn't seem to reintroduce the bug.
... but the whole thing is a mess overall.
To be flippant, I might say HN discussions seem to QA using Apple methods.
/System/Library/CoreServices/Applications/Directory Utility.app
Edit > Change Root Password