14 ms·

About the security content of Security Update 2017-001

337 points by cmg 9y ago

m6g6a 9y ago
Kinda aggressive. I don't even clicked on update and they already did that for me.
- sillysaurus3 9y ago
  They force-pushed code to your box without you agreeing to this? Can anyone else confirm?
  - bpicolo 9y ago
    It's a massive global security vulnerability with huge amounts of public exposure (so any malicious user is well aware they can take advantage). If they did, wouldn't be surprised and I'd be glad they did.
    - inetknght 9y ago
      If they did for this, great. But the fact that they could for any other update, too, is what's scary.
      - 0x0 9y ago
        They do this all the time with invisible updates. Click AppleMenu > About this mac > System Report, and scroll down to Software > Installations, and click on the "Install Date" column header twice to sort by install date descending, and you will discover apple pushing updates very frequently for things like "MRTConfigData", "XProtectPlistConfigData", "Voice Update - Samantha", "Gatekeeper Configuration Data", "Chinese word list update" etc etc. It's not without flaws; at least once they slipped up and pushed a blacklist for their own ethernet adapter driver (cutting off their own patch life-line, I guess, for those affected) : https://www.digitaltrends.com/computing/mac-update-breaks-ethernet-fix/ https://www.digitaltrends.com/computing/mac-update-breaks-et...
      - mikeash 9y ago
        It's an option that this person enabled. Nothing scary.
  - robin_reala 9y ago
    I opened App Store, found the package waiting and hit install, waited for a few minutes until it finished. So not automatically for me.
  - andreasley 9y ago
    The update didn't auto-install for me. I suppose it only does that when "Install system data files and security updates" is enabled in System Preferences -> App Store.
    - therealmarv 9y ago
      right, for me neither. I can choose.
  - cmg 9y ago
    There are options in macOS to automatically install various types of updates, labeled as 'app updates', 'macOS updates', 'system data files and security updates'. Maybe m6g6a has the last one checked. I opened App Store and just had it waiting for me. Where the name would normally be in the Updates tab, it just reads "Install this update as soon as possible." [0] [0] https://imgur.com/a/bMUKO https://imgur.com/a/bMUKO Edit: According to Apple's statement, they will automatically start installing the update on systems running 10.3.1 later today.
  - Milner08 9y ago
    Not for me, it's waiting for me to click install in the App Store. Its pretty well highlighted though.
    - SOLAR_FIELDS 9y ago
      It almost shouts at you. Mine says "Install this update as soon as possible"
  - deleted 9y ago
    [deleted]
  - deleted 9y ago
    [deleted]
  - Someone 9y ago
    Whoever installed the OS agreed to it. http://images.apple.com/legal/sla/docs/macOS1013.pdf http://images.apple.com/legal/sla/docs/macOS1013.pdf: ”Q. Automatic Updates. The Apple Software will periodically check with Apple for updates to the Apple Software. If an update is available, the update may automatically download and install onto your computer and, if applicable, your peripheral devices. _By using the Apple Software, you agree that Apple may download and install automatic updates onto your computer and your peripheral devices_. You can turn off automatic updates altogether at any time by changing the automatic updates settings found within System Preferences.”
  - matthew-wegner 9y ago
    They do have this capability, and have for years, although they rarely use it. They're force-pushing this update later today. It says so right in their statement: "the update is available for download, and starting later today it will be automatically installed on all systems running the latest version (10.13.1) of macOS High Sierra"
  - deleted 9y ago
    [deleted]
- kogir 9y ago
  Is it possible that "Automatically check for updates" and "Install system data files and security updates" are set in your system preferences? I have that enabled because this is exactly the kind of thing I want patched ASAP.
  - m6g6a 9y ago
    Yes, you right. I checked them.
- compiler-guy 9y ago
  Apple has used the force-upgrade path which you cannot opt out of (at least not easily) and which is permitted by their TOU, exactly twice, both to address serious security vulnerabilities. Once for this problem, and once for the NTP security bug in 2014. That is it. https://support.apple.com/en-us/HT204425 https://support.apple.com/en-us/HT204425
robin_reala 9y ago
Earlier today I set a root password. Can anyone confirm what the steps are to get back to the original state of a disabled root account with no password?
- mikeash 9y ago
  Open Directory Utility.app, click the lock to make changes, then Edit -> Disable Root User.
  - robin_reala 9y ago
    Ah, looks like it was automatically disabled again by the patch, so nothing to do.
    - mikeash 9y ago
      That's interesting, it seems to have disabled mine as well, even on the computer that already had a root user enabled from before. I'd guess they can't distinguish between root accounts deliberately enabled by the user and accidentally enabled because of this bug. Fun stuff. No trouble for me, at least, I'm not even sure why I had it enabled in the first place.
tomduncalf 9y ago
See Apple's comment on this, given to BuzzFeed I assume: https://twitter.com/JohnPaczkowski/status/935909264362586112 https://twitter.com/JohnPaczkowski/status/935909264362586112 / https://www.buzzfeed.com/josephbernstein/apple-released-a-patch-for-that-massive-security-flaw-in https://www.buzzfeed.com/josephbernstein/apple-released-a-pa... "Security is a top priority for every Apple product, and regrettably we stumbled with this release of macOS. When our security engineers became aware of the issue Tuesday afternoon, we immediately began working on an update that closes the security hole. This morning, as of 8:00 a.m., the update is available for download, and starting later today it will be automatically installed on all systems running the latest version (10.13.1) of macOS High Sierra. We greatly regret this error and we apologize to all Mac users, both for releasing with this vulnerability and for the concern it has caused. Our customers deserve better. We are auditing our development processes to help prevent this from happening again." (posted to https://news.ycombinator.com/item?id=15808164 https://news.ycombinator.com/item?id=15808164 if separate discussion is preferred)
- nailer 9y ago
  Original source of Buzzfeed article, if you'd like to avoid giving them traffic: https://twitter.com/lemiorhan/status/935578694541770752 https://twitter.com/lemiorhan/status/935578694541770752 Demo: https://twitter.com/0xAmit/status/935607313368481793 https://twitter.com/0xAmit/status/935607313368481793
- blinkingled 9y ago
  > We are auditing our development processes to help prevent this from happening again. That's great to hear even if it took multiple stumbles for them to finally admit - but surely they should be also audit their QA/testing processes? Or does development in AppleSpeak mean everything?
  - Klathmon 9y ago
    It sound to me like the "development process" points to the whole soup-to-nuts system. From "brainstorming" and new feature development, to development, to testing, to QA, to deployment.
eklavya 9y ago
Haven't seen this mentioned anywhere so far but this was not a remote vulnerability right? Only from login screen, right !! ??
- bsaul 9y ago
  From what i understood it's not a remote vulnerability until someone actually activates the "root user with empty password" locally using the vulnerability.
  - xraystyle 9y ago
    You could exploit it with remote desktop. If it's enabled on the client, you can just connect with root/no password.
- lucideer 9y ago
  It's from any login prompt, and it gives root, so it's an elevation vulnerability that could be leveraged by a local or remote process with limited privileges to gain elevated privileges.
- mey 9y ago
  Once the exploit is done (clicking the unlock button w/ the user root on the settings pane), the root account is setup with a blank password. At this point any remote access methods that use the accounts on the system should allow access. Depending on SSH config, root may be disallowed. I've seen rumors otherwise, but until someone with experience verifies those pathways I can only guess.
  - pilsetnieks 9y ago
    Not any method. It worked for screen sharing but it did not for SSH, even after the bug was triggered locally.
    - jlgaddis 9y ago
      I'm not near a macOS box at the moment, but I believe that PermitRootLogin no is set in /private/etc/ssh/sshd_config
bsaul 9y ago
"Description: A logic error existed in the validation of credentials. This was addressed with improved credential validation." I hope they won't stop to this brief summary, because a "logic error in the validation of credentials" shouldn't be able to allow the creation of a root super user with empty password. I'm hope they'll go deep in the gory details, to show us how it's in fact much more complicated than a "if !password { createEmptySuper()}" line written by mistake.
- Bogdanp 9y ago
  That's kind of what it was: https://objective-see.com/blog/blog_0x24.html https://objective-see.com/blog/blog_0x24.html
  - zbentley 9y ago
    It seems to me that the biggest problem highlighted by the link in parent is backwards compatibility of authentication metchanisms. OSX seems to support typical /etc/passwd hashed-user-credential authentication. However, it tries to "upgrade" that authentication mode to "shadowhash or securetoken", which appear to be two new auth schemes integrated with Open Directory. All of those things might be fine, on their own. However, the biggest issue is that there are now more than one primary way to get authenticated on the system. This is likely true because network accounts need to be supported in addition to local ones (I.e. apple accounts, LDAP accounts, etc.). However, my (admittedly uneducated) impression is that the systems for handling those accounts are totally separate--the part of the auth system that is swappable between shadowhash/old-school-passwd/etc. is . . . basically the whole auth system. I'm sure that's a very quick and easy way to write authentication code, and it also preserves backwards compatibility of users doing the old method, but it seems inherently prone to more issues (even if you don't make screw-ups as obvious as this one). You have more auth stacks (and thus code) to debug in total, to say nothing of code that migrates credentials between different auth stacks. Preserving backwards compatibility is important, to be sure, but only sometimes. This seems like a case where things would have been easily mitigated if Apple had done something like "everyone must sign in with their Apple account, now, as the sole authenticating credential for this operating system" during some OS upgrade (or "/etc/passwd no longer works; all these systems have been refactored to use a single central credential database in Keychain Services, update any code that cares since it's being aggressively deprecated", though that would probably have been both harder to implement and harder to sell to the user/developer-base). However, I'm far from an expert here, so maybe the "just expand on the existing UNIX local auth system" option is less-infeasible than it seems (linux ditched this too for network accounts, though, which doesn't give me confidence). Either way, an old-auth-system removal like that would have crippled some of my workflows/code, and others', but it also would have allowed Apple (if they followed it up with a dead-systems-removal pass) to remove many of the then-redundant authentication systems in OSX. TL;DR Linus isn't always right, backwards/userland compatibility shouldn't always be held paramount, especially when you're developing parallel systems for something as critical as authentication. Sometimes the pain caused by deprecation is worth the removal of a security risk.
pandalicious 9y ago
Does their patch also disable root accounts that were enabled using the exploit?
- myfonj 9y ago
  That last sentence [0] suggests that the patch will disable every single activated root account. [0] > If you require the root user account on your Mac, you will need to re-enable the root user and change the root user's password after this update.
  - londons_explore 9y ago
    Which could lock some users out permanently if the root user was the only user they knew the password to.
    - geofft 9y ago
      It's impossible to have full-disk encryption with that config, right? (i.e., does FileVault work for the root user?) If you can get in from an install CD, you can reset passwords as needed. If I were writing this patch, I'd probably check to see if the root user's password was indeed blank, but given that use of the root account only is extremely unsupported I cannot get too upset about Apple breaking that use case as long as you can get back in.
      - comex 9y ago
        The issue wasn’t actually specific to a blank password. You could try to log in as root using any password, and as long as root had never had a password set, it would fail but set root’s password to whatever you entered.
- michrassena 9y ago
  I just installed the patch on a system where I had logged into root with a blank to confirm the issue. Root login no longer works in the unlock dialog. I didn't try a more sophisticated test.
deleted 9y ago
[deleted]
deleted 9y ago
[deleted]
ratsimihah 9y ago
Wow I'm glad that happened BEFORE Apple hired me. Not that they hired or will ever hire me but, just saying.
prophesi 9y ago
I heard the bug was working on El Capitan for some people [1]. Some Mac devices aren't able to upgrade past El Capitan; will they just forever have this vulnerability? [1] https://news.ycombinator.com/item?id=15800817 https://news.ycombinator.com/item?id=15800817
- lstamour 9y ago
  Apple says "Not impacted: macOS Sierra 10.12.6 and earlier" in their security advisory for the patch.
  - prophesi 9y ago
    My fear is that Apple doesn't know that it still affects El Capitan, though the poster I linked to could have just been lying.
    - macintux 9y ago
      Or mistaken, or confused, or... Apple knows when the bug materialized (sounds like it was part of a UX simplification of migration and/or upgrades) and I'm sure before getting embarrassed yet again they would have done due diligence. Probably.
    - spike021 9y ago
      It doesn't appear to affect (regular) Sierra, so if this issue exists on El Capitan, I'm guessing it's a separate, though relevant, problem, rather than being the exact same one.
    - mhandley 9y ago
      I can't reproduce it on El Capitan. Doesn't prove others can't, but I'm pretty sure Apple would patch it on El Capitan too if the bug was that old - they issued other security patches less than a month ago.
- geofft 9y ago
  The link you post claims that root/empty password worked on the first try, not the second, which probably means that the system in question had the root account enabled with an empty password already (which is a thing you can intentionally configure and then forget about).
exabrial 9y ago
> We are auditing our development processes to help prevent this from happening again The root of the problem is the CEO has put an emphasis on flashy useless features rather than quality. Jobs realized that quality was ultimately what sells first, followed by practicality, which was driven by need and innovation. The Steve Ballmer of Apple thinks has squeezed creativity at Apple dry. Sad to see problems from the hardware division start to creep into the software division. :(
sccxy 9y ago
Real problem is that if you are nobody then your private bug reports mean nothing. Only public shaming helps here. https://medium.com/@lemiorhan/the-story-behind-anyone-can-login-as-root-tweet-33731b5ded71 https://medium.com/@lemiorhan/the-story-behind-anyone-can-lo... Author of this tweet said that Apple was informed at least week before tweet, but zero response.
- londons_explore 9y ago
  Lots of companies are quite good at handling security vulnerabilities, but somehow still neglect to reply to the original reporter. Usually there's a long chain of people involved in creating tickets, allocating resources, finding the bug, fixing the bug, QA, release processes, documenting the problem, making security bulletins, translating security bulletins, etc. Each of those people communicates via internal processes the reporter doesn't have access to, and none of them think to ping the original reporter saying 'yo - bugfix complete, qa next, then release'
- deleted 9y ago
  [deleted]
- pkamb 9y ago
  > On Nov 23, the staff members informed Apple about it. For everyone kvetching yesterday about "responsible disclosure".
cptskippy 9y ago
> it will be automatically installed on all systems running the latest version (10.13.1) of macOS High Sierra So uh... where are all those people who lost their mind about Windows 10 forcing updates? http://i2.kym-cdn.com/photos/images/newsfeed/001/042/619/4ea.jpg http://i2.kym-cdn.com/photos/images/newsfeed/001/042/619/4ea...
- qubex 9y ago
  I realise that this is a facile topic for engendering scandal amongst our geek demographic (and rightly so), but given the gravity of the underlying issue it’s actually entirely reasonable and indeed preferable to the alternative scenario of N hundred million insouciant users lagging behind with a gaping security hole.
  - cptskippy 9y ago
    I don't disagree about the necessity of being able to force updates for bugs of this severity. I'm simply pointing out that, when Microsoft does forced updates, people lose their minds with outrage. You could argue that severity plays a role in the level opposition to such a feature however severity is an arbitrary assessment applied by the person issuing the update. > the alternative scenario of N hundred million insouciant users lagging behind with a gaping security hole. Last I checked macOS hadn't crossed the 50 million user mark. The combined iOS/macOS user base only just surpasses Windows.
- benchaney 9y ago
  People weren't upset about windows installing security updates. If this update adds nagware to OSX or forces people to restart their computer in the middle of whatever they are working on, your comment will be a fair point. Until then, it is an stupid comparison.
  - cptskippy 9y ago
    People were upset with Windows 10 for it's update policies for a number of different reasons but those very different reasons have all been lumped together into a singular general objection so that addressing one of those reasons will never solve the objection thus making the only possible solution disabling Windows Update. It's silly. Feature updates and quality updates are handled differently in Windows 10. You can delay feature updates for a year, quality updates (security) can only be delayed for a month. I'm not sure what specific thing you're referring to when you say "nagware", seem my first paragraph, but there's no persistent nagging in Windows 10.
bonaldi 9y ago
Apparently this forced update breaks file-sharing(!): https://forums.macrumors.com/threads/security-update-2017-001-breaks-file-sharing.2091913/ https://forums.macrumors.com/threads/security-update-2017-00... (SMB still works)
- LeoPanthera 9y ago
  NFS is still working for me. I thought "file sharing" was SMB. AFP is deprecated. What other kind of file sharing is there?
  - bonaldi 9y ago
    I think they're talking about AFP, which is still in use in a lot of places (you can't share ADFS over AFP, but you can connect to/share non-ADFS disks)
CantSQLIThis 9y ago
Awww what a shame
CantSQLIThis 9y ago
Awww what a shame.
spatulon 9y ago
Not to be confused with the other 2017-001 update they released one month ago: https://support.apple.com/en-gb/HT208221 https://support.apple.com/en-gb/HT208221 The App Store Updates page on my mum's Macbook Air now shows that she has installed two updates called "Security Update 2017-001", and she started to worry that she didn't have the correct update installed today. They both link to the same page (https://support.apple.com/en-gb/HT201222 https://support.apple.com/en-gb/HT201222), so it took me a while to figure out what was going on, and that she really had installed two distinct security patches (one before upgrading to High Sierra, one after).

337 points by cmg 9y ago

m6g6a 9y ago

Kinda aggressive. I don't even clicked on update and they already did that for me.

sillysaurus3 9y ago
They force-pushed code to your box without you agreeing to this? Can anyone else confirm?
- bpicolo 9y ago
  It's a massive global security vulnerability with huge amounts of public exposure (so any malicious user is well aware they can take advantage). If they did, wouldn't be surprised and I'd be glad they did.
  - inetknght 9y ago
    If they did for this, great. But the fact that they could for any other update, too, is what's scary.
    - 0x0 9y ago
      They do this all the time with invisible updates. Click AppleMenu > About this mac > System Report, and scroll down to Software > Installations, and click on the "Install Date" column header twice to sort by install date descending, and you will discover apple pushing updates very frequently for things like "MRTConfigData", "XProtectPlistConfigData", "Voice Update - Samantha", "Gatekeeper Configuration Data", "Chinese word list update" etc etc. It's not without flaws; at least once they slipped up and pushed a blacklist for their own ethernet adapter driver (cutting off their own patch life-line, I guess, for those affected) : https://www.digitaltrends.com/computing/mac-update-breaks-ethernet-fix/ https://www.digitaltrends.com/computing/mac-update-breaks-et...
    - mikeash 9y ago
      It's an option that this person enabled. Nothing scary.
- robin_reala 9y ago
  I opened App Store, found the package waiting and hit install, waited for a few minutes until it finished. So not automatically for me.
- andreasley 9y ago
  The update didn't auto-install for me. I suppose it only does that when "Install system data files and security updates" is enabled in System Preferences -> App Store.
  - therealmarv 9y ago
    right, for me neither. I can choose.
- cmg 9y ago
  There are options in macOS to automatically install various types of updates, labeled as 'app updates', 'macOS updates', 'system data files and security updates'. Maybe m6g6a has the last one checked. I opened App Store and just had it waiting for me. Where the name would normally be in the Updates tab, it just reads "Install this update as soon as possible." [0] [0] https://imgur.com/a/bMUKO https://imgur.com/a/bMUKO Edit: According to Apple's statement, they will automatically start installing the update on systems running 10.3.1 later today.
- Milner08 9y ago
  Not for me, it's waiting for me to click install in the App Store. Its pretty well highlighted though.
  - SOLAR_FIELDS 9y ago
    It almost shouts at you. Mine says "Install this update as soon as possible"
- deleted 9y ago
  [deleted]
- deleted 9y ago
  [deleted]
- Someone 9y ago
  Whoever installed the OS agreed to it. http://images.apple.com/legal/sla/docs/macOS1013.pdf http://images.apple.com/legal/sla/docs/macOS1013.pdf: ”Q. Automatic Updates. The Apple Software will periodically check with Apple for updates to the Apple Software. If an update is available, the update may automatically download and install onto your computer and, if applicable, your peripheral devices. _By using the Apple Software, you agree that Apple may download and install automatic updates onto your computer and your peripheral devices_. You can turn off automatic updates altogether at any time by changing the automatic updates settings found within System Preferences.”
- matthew-wegner 9y ago
  They do have this capability, and have for years, although they rarely use it. They're force-pushing this update later today. It says so right in their statement: "the update is available for download, and starting later today it will be automatically installed on all systems running the latest version (10.13.1) of macOS High Sierra"
- deleted 9y ago
  [deleted]
kogir 9y ago
Is it possible that "Automatically check for updates" and "Install system data files and security updates" are set in your system preferences? I have that enabled because this is exactly the kind of thing I want patched ASAP.
- m6g6a 9y ago
  Yes, you right. I checked them.
compiler-guy 9y ago
Apple has used the force-upgrade path which you cannot opt out of (at least not easily) and which is permitted by their TOU, exactly twice, both to address serious security vulnerabilities. Once for this problem, and once for the NTP security bug in 2014. That is it. https://support.apple.com/en-us/HT204425 https://support.apple.com/en-us/HT204425

robin_reala 9y ago

Earlier today I set a root password. Can anyone confirm what the steps are to get back to the original state of a disabled root account with no password?

mikeash 9y ago
Open Directory Utility.app, click the lock to make changes, then Edit -> Disable Root User.
- robin_reala 9y ago
  Ah, looks like it was automatically disabled again by the patch, so nothing to do.
  - mikeash 9y ago
    That's interesting, it seems to have disabled mine as well, even on the computer that already had a root user enabled from before. I'd guess they can't distinguish between root accounts deliberately enabled by the user and accidentally enabled because of this bug. Fun stuff. No trouble for me, at least, I'm not even sure why I had it enabled in the first place.

tomduncalf 9y ago

See Apple's comment on this, given to BuzzFeed I assume: https://twitter.com/JohnPaczkowski/status/935909264362586112 https://twitter.com/JohnPaczkowski/status/935909264362586112 / https://www.buzzfeed.com/josephbernstein/apple-released-a-patch-for-that-massive-security-flaw-in https://www.buzzfeed.com/josephbernstein/apple-released-a-pa... "Security is a top priority for every Apple product, and regrettably we stumbled with this release of macOS. When our security engineers became aware of the issue Tuesday afternoon, we immediately began working on an update that closes the security hole. This morning, as of 8:00 a.m., the update is available for download, and starting later today it will be automatically installed on all systems running the latest version (10.13.1) of macOS High Sierra. We greatly regret this error and we apologize to all Mac users, both for releasing with this vulnerability and for the concern it has caused. Our customers deserve better. We are auditing our development processes to help prevent this from happening again." (posted to https://news.ycombinator.com/item?id=15808164 https://news.ycombinator.com/item?id=15808164 if separate discussion is preferred)

nailer 9y ago
Original source of Buzzfeed article, if you'd like to avoid giving them traffic: https://twitter.com/lemiorhan/status/935578694541770752 https://twitter.com/lemiorhan/status/935578694541770752 Demo: https://twitter.com/0xAmit/status/935607313368481793 https://twitter.com/0xAmit/status/935607313368481793
blinkingled 9y ago
> We are auditing our development processes to help prevent this from happening again. That's great to hear even if it took multiple stumbles for them to finally admit - but surely they should be also audit their QA/testing processes? Or does development in AppleSpeak mean everything?
- Klathmon 9y ago
  It sound to me like the "development process" points to the whole soup-to-nuts system. From "brainstorming" and new feature development, to development, to testing, to QA, to deployment.

eklavya 9y ago

Haven't seen this mentioned anywhere so far but this was not a remote vulnerability right? Only from login screen, right !! ??

bsaul 9y ago
From what i understood it's not a remote vulnerability until someone actually activates the "root user with empty password" locally using the vulnerability.
- xraystyle 9y ago
  You could exploit it with remote desktop. If it's enabled on the client, you can just connect with root/no password.
lucideer 9y ago
It's from any login prompt, and it gives root, so it's an elevation vulnerability that could be leveraged by a local or remote process with limited privileges to gain elevated privileges.
mey 9y ago
Once the exploit is done (clicking the unlock button w/ the user root on the settings pane), the root account is setup with a blank password. At this point any remote access methods that use the accounts on the system should allow access. Depending on SSH config, root may be disallowed. I've seen rumors otherwise, but until someone with experience verifies those pathways I can only guess.
- pilsetnieks 9y ago
  Not any method. It worked for screen sharing but it did not for SSH, even after the bug was triggered locally.
  - jlgaddis 9y ago
    I'm not near a macOS box at the moment, but I believe that PermitRootLogin no is set in /private/etc/ssh/sshd_config

bsaul 9y ago

"Description: A logic error existed in the validation of credentials. This was addressed with improved credential validation." I hope they won't stop to this brief summary, because a "logic error in the validation of credentials" shouldn't be able to allow the creation of a root super user with empty password. I'm hope they'll go deep in the gory details, to show us how it's in fact much more complicated than a "if !password { createEmptySuper()}" line written by mistake.

Bogdanp 9y ago
That's kind of what it was: https://objective-see.com/blog/blog_0x24.html https://objective-see.com/blog/blog_0x24.html
- zbentley 9y ago
  It seems to me that the biggest problem highlighted by the link in parent is backwards compatibility of authentication metchanisms. OSX seems to support typical /etc/passwd hashed-user-credential authentication. However, it tries to "upgrade" that authentication mode to "shadowhash or securetoken", which appear to be two new auth schemes integrated with Open Directory. All of those things might be fine, on their own. However, the biggest issue is that there are now more than one primary way to get authenticated on the system. This is likely true because network accounts need to be supported in addition to local ones (I.e. apple accounts, LDAP accounts, etc.). However, my (admittedly uneducated) impression is that the systems for handling those accounts are totally separate--the part of the auth system that is swappable between shadowhash/old-school-passwd/etc. is . . . basically the whole auth system. I'm sure that's a very quick and easy way to write authentication code, and it also preserves backwards compatibility of users doing the old method, but it seems inherently prone to more issues (even if you don't make screw-ups as obvious as this one). You have more auth stacks (and thus code) to debug in total, to say nothing of code that migrates credentials between different auth stacks. Preserving backwards compatibility is important, to be sure, but only sometimes. This seems like a case where things would have been easily mitigated if Apple had done something like "everyone must sign in with their Apple account, now, as the sole authenticating credential for this operating system" during some OS upgrade (or "/etc/passwd no longer works; all these systems have been refactored to use a single central credential database in Keychain Services, update any code that cares since it's being aggressively deprecated", though that would probably have been both harder to implement and harder to sell to the user/developer-base). However, I'm far from an expert here, so maybe the "just expand on the existing UNIX local auth system" option is less-infeasible than it seems (linux ditched this too for network accounts, though, which doesn't give me confidence). Either way, an old-auth-system removal like that would have crippled some of my workflows/code, and others', but it also would have allowed Apple (if they followed it up with a dead-systems-removal pass) to remove many of the then-redundant authentication systems in OSX. TL;DR Linus isn't always right, backwards/userland compatibility shouldn't always be held paramount, especially when you're developing parallel systems for something as critical as authentication. Sometimes the pain caused by deprecation is worth the removal of a security risk.

pandalicious 9y ago

Does their patch also disable root accounts that were enabled using the exploit?

myfonj 9y ago
That last sentence [0] suggests that the patch will disable every single activated root account. [0] > If you require the root user account on your Mac, you will need to re-enable the root user and change the root user's password after this update.
- londons_explore 9y ago
  Which could lock some users out permanently if the root user was the only user they knew the password to.
  - geofft 9y ago
    It's impossible to have full-disk encryption with that config, right? (i.e., does FileVault work for the root user?) If you can get in from an install CD, you can reset passwords as needed. If I were writing this patch, I'd probably check to see if the root user's password was indeed blank, but given that use of the root account only is extremely unsupported I cannot get too upset about Apple breaking that use case as long as you can get back in.
    - comex 9y ago
      The issue wasn’t actually specific to a blank password. You could try to log in as root using any password, and as long as root had never had a password set, it would fail but set root’s password to whatever you entered.
michrassena 9y ago
I just installed the patch on a system where I had logged into root with a blank to confirm the issue. Root login no longer works in the unlock dialog. I didn't try a more sophisticated test.

deleted 9y ago

[deleted]

deleted 9y ago

[deleted]

ratsimihah 9y ago

Wow I'm glad that happened BEFORE Apple hired me. Not that they hired or will ever hire me but, just saying.

prophesi 9y ago

I heard the bug was working on El Capitan for some people [1]. Some Mac devices aren't able to upgrade past El Capitan; will they just forever have this vulnerability? [1] https://news.ycombinator.com/item?id=15800817 https://news.ycombinator.com/item?id=15800817

lstamour 9y ago
Apple says "Not impacted: macOS Sierra 10.12.6 and earlier" in their security advisory for the patch.
- prophesi 9y ago
  My fear is that Apple doesn't know that it still affects El Capitan, though the poster I linked to could have just been lying.
  - macintux 9y ago
    Or mistaken, or confused, or... Apple knows when the bug materialized (sounds like it was part of a UX simplification of migration and/or upgrades) and I'm sure before getting embarrassed yet again they would have done due diligence. Probably.
  - spike021 9y ago
    It doesn't appear to affect (regular) Sierra, so if this issue exists on El Capitan, I'm guessing it's a separate, though relevant, problem, rather than being the exact same one.
  - mhandley 9y ago
    I can't reproduce it on El Capitan. Doesn't prove others can't, but I'm pretty sure Apple would patch it on El Capitan too if the bug was that old - they issued other security patches less than a month ago.
geofft 9y ago
The link you post claims that root/empty password worked on the first try, not the second, which probably means that the system in question had the root account enabled with an empty password already (which is a thing you can intentionally configure and then forget about).

exabrial 9y ago

> We are auditing our development processes to help prevent this from happening again The root of the problem is the CEO has put an emphasis on flashy useless features rather than quality. Jobs realized that quality was ultimately what sells first, followed by practicality, which was driven by need and innovation. The Steve Ballmer of Apple thinks has squeezed creativity at Apple dry. Sad to see problems from the hardware division start to creep into the software division. :(

sccxy 9y ago

Real problem is that if you are nobody then your private bug reports mean nothing. Only public shaming helps here. https://medium.com/@lemiorhan/the-story-behind-anyone-can-login-as-root-tweet-33731b5ded71 https://medium.com/@lemiorhan/the-story-behind-anyone-can-lo... Author of this tweet said that Apple was informed at least week before tweet, but zero response.

londons_explore 9y ago
Lots of companies are quite good at handling security vulnerabilities, but somehow still neglect to reply to the original reporter. Usually there's a long chain of people involved in creating tickets, allocating resources, finding the bug, fixing the bug, QA, release processes, documenting the problem, making security bulletins, translating security bulletins, etc. Each of those people communicates via internal processes the reporter doesn't have access to, and none of them think to ping the original reporter saying 'yo - bugfix complete, qa next, then release'
deleted 9y ago
[deleted]
pkamb 9y ago
> On Nov 23, the staff members informed Apple about it. For everyone kvetching yesterday about "responsible disclosure".

cptskippy 9y ago

> it will be automatically installed on all systems running the latest version (10.13.1) of macOS High Sierra So uh... where are all those people who lost their mind about Windows 10 forcing updates? http://i2.kym-cdn.com/photos/images/newsfeed/001/042/619/4ea.jpg http://i2.kym-cdn.com/photos/images/newsfeed/001/042/619/4ea...

qubex 9y ago
I realise that this is a facile topic for engendering scandal amongst our geek demographic (and rightly so), but given the gravity of the underlying issue it’s actually entirely reasonable and indeed preferable to the alternative scenario of N hundred million insouciant users lagging behind with a gaping security hole.
- cptskippy 9y ago
  I don't disagree about the necessity of being able to force updates for bugs of this severity. I'm simply pointing out that, when Microsoft does forced updates, people lose their minds with outrage. You could argue that severity plays a role in the level opposition to such a feature however severity is an arbitrary assessment applied by the person issuing the update. > the alternative scenario of N hundred million insouciant users lagging behind with a gaping security hole. Last I checked macOS hadn't crossed the 50 million user mark. The combined iOS/macOS user base only just surpasses Windows.
benchaney 9y ago
People weren't upset about windows installing security updates. If this update adds nagware to OSX or forces people to restart their computer in the middle of whatever they are working on, your comment will be a fair point. Until then, it is an stupid comparison.
- cptskippy 9y ago
  People were upset with Windows 10 for it's update policies for a number of different reasons but those very different reasons have all been lumped together into a singular general objection so that addressing one of those reasons will never solve the objection thus making the only possible solution disabling Windows Update. It's silly. Feature updates and quality updates are handled differently in Windows 10. You can delay feature updates for a year, quality updates (security) can only be delayed for a month. I'm not sure what specific thing you're referring to when you say "nagware", seem my first paragraph, but there's no persistent nagging in Windows 10.

bonaldi 9y ago

Apparently this forced update breaks file-sharing(!): https://forums.macrumors.com/threads/security-update-2017-001-breaks-file-sharing.2091913/ https://forums.macrumors.com/threads/security-update-2017-00... (SMB still works)

LeoPanthera 9y ago
NFS is still working for me. I thought "file sharing" was SMB. AFP is deprecated. What other kind of file sharing is there?
- bonaldi 9y ago
  I think they're talking about AFP, which is still in use in a lot of places (you can't share ADFS over AFP, but you can connect to/share non-ADFS disks)

CantSQLIThis 9y ago

Awww what a shame

CantSQLIThis 9y ago

Awww what a shame.

spatulon 9y ago

Not to be confused with the other 2017-001 update they released one month ago: https://support.apple.com/en-gb/HT208221 https://support.apple.com/en-gb/HT208221 The App Store Updates page on my mum's Macbook Air now shows that she has installed two updates called "Security Update 2017-001", and she started to worry that she didn't have the correct update installed today. They both link to the same page (https://support.apple.com/en-gb/HT201222 https://support.apple.com/en-gb/HT201222), so it took me a while to figure out what was going on, and that she really had installed two distinct security patches (one before upgrading to High Sierra, one after).