Sophos Cloud Optix
Did you just download the quarter-gigabyte iTunes 11.2 update for your Mac?
If so, consider it a practice run: you need to do it all over again.
It seems there was a rather spectacular permissions blunder in the iTunes 11.2 update, forcing Apple to rush out iTunes 11.2.1 for OS X within two days.
According to Apple’s security bulletin:
Upon each reboot, the permissions for the /Users and /Users/Shared directories would be set to world-writable, allowing modification of these directories.
Is this a dangerous hole?
For many users, not really.
If you only have one user account on your Mac, because you don’t let anyone else use it, you’re able to write to your own files at any time anyway.
But if you have a Mac with more than one user account, you don’t want those accounts to be able to interfere with one another’s data, even though they may be known (and trusted) local users rather than unknown attackers from outside.
The bad side of this bug is that you would quite reasonably expect this sort of fault to show up in testing.
The good side, if bugs can have good sides, is that Apple fixed it very quickly.
In 2013, in contrast, Apple dithered for more than six months over fixing a serious elevation of privilege hole in sudo, a tool used in system adminstration to authorise individual commands to run as root.
This latest update proves that Cupertino can move swiftly to fix security problems when it wants, so let’s hope that attitude is something we see more of.
By the way, eagle eyed readers will notice that this update applies to the most recent four versions of OS X, namely 10.6 (Snow Leopard), 10.7 (Lion), 10.8 (Mountain Lion) and 10.9 (Mavericks).
We’ve suggested several times that you should consider Snow Leopard “unofficially unsupported” because it hasn’t been getting security fixes since 10.9 came out.
We stand by that assessment, even though OS 10.6 is covered in this case: although this is a security fix, it’s not really a fix for the operating system components themselves, just for one of the many applications that run on it.
Having said that: if you have already installed iTunes 11.2 and have a Mac with more than one user account, consider this a critical update and grab it right away.
Note. This bug and the associated update apply only to iTunes on OS X. iTunes on Windows is not affected.
You have to question why iTunes is a 250MB download on what is essentially a linux/unix OS… Me thinks apple software engineers need tome lessons on who to save memory in their coding
Ahem. OS X is not in any way, shape or form a Linux OS. By all means call it “a UNIX,” but, whatever you do, don’t risk the wrath of the GNU faithful and call it “a Linux” 🙂
I have a Windows laptop & the last “update” I installed completely wiped out the iTunes Library. I am still putting playlists back together again. (over a month!)
This one is for OS X only. Of course, there’s 11.2 for Windows…that was listed in an Apple security bulletin, and there’s a not unimportant hole patched – potential credential leak. Not sure what to say…hold your breath and “just do the update,” I suppose.
Strange. I did update my Mac with the Quarterly update. And I have checked that I still have iTunes 11.2. All correct. But I do not have my /Users or /Users/Shared directory word writable. Proof here:
ll -d /Users /Users/Shared
drwxr-xr-x 8 root admin 272 Apr 7 23:13 /Users
drwxrwxrwt 16 root wheel 544 May 10 13:36 /Users/Shared
And even if /Users would be word writable, the individual user’s folders aren’t, so the risk would only be for those who do not have FileVault activated and would have a guest account. The risk would be that the guest account could modify files in /Users/Shared.
I am waiting to see the official security annoucement from Apple on this update.
It went live since I wrote the article:
http://support.apple.com/kb/HT6251
Says word-for-word what I quoted above. And the general (non-security-related) announcement, ultra-brief though it might be, seems to confirm that this only started with 11.2:
http://support.apple.com/kb/TS5434
Probably best to err on the side of caution, as they say. (It does say that the world writability only happens after a reboot…did you reboot _after_ the reboot necessitated by the update?)
Yep, I had the Mac shutdown yesterday evening. And I booted up to verify which version of iTunes I had and if I was affected or not. (saw this news on Zite on my iPad).
I did perform the update since my last post. But are curious to know more.
Yup – this affected me – big time – and exactly as described. I take great pains to keep my standard user account limited, and sure enough, /Users is world writable. Not only that – /Users/root is world writable, but all the standard user and admin accounts are still protected. LOL. I suppose that if root is pwned, the DudleyDoright account is immaterial.
I’ll be blunt – these sorts of errors are far too convenient for the spooks. A buddy of mine, years ago, did an IT article in one of the IT webzine weekly mags (might have been eWeek), which is impossible to find now, but he basically ratted out NSA compromises through leveraged and persuaded employees. We are NOT going to get a handle on this stuff until the small fish are slightly fried for their parts in these incidents. I know that the spooks generally make these things impossible to differentiate from honest mistakes, so we’re just going to have to deal with the inevitable reality that some good guys will get caught up in the dragnet. But the bottom line is that securing public code (both open source and proprietary) will involve the public de-spooking it, by moving both the real and fake code klutzes away from the heartbeat stuff. It’s a real war out there. Time to start acting like it.
Correction – that was just the Shared subdirectory – still world-writable, as it should be. But the update moved /Users back to 755 permissions. Thank you, Apple!
Annoyingly, since I have a monthly data limit, the 11.2 version downloaded all my purchases to the tune of almost 18GB. Thank you very much Apple.
Rather than use the App Store, my advice is to download all software as standalone .dmg zip files, so that you can choose when to install upgrades and keep an eye on the process. In this instance Sophos kindly published a link to iTunes11.2.1.dmg, which now sits on my desktop awaiting my attention; I can also copy it by USB stick to my other Mac. This saves download time because it took 2 hours to download at 0.3 Kbps via the 6 km copper and aluminium telephone line from the roadside cabinet!
“… you would quite reasonably expect this sort of fault to show up in testing.”
Xactly !!
Can you please explain this sentence when the only two permission related things that changed are /Users 777 instead of 755 and /Users/Shared 777 instead of 1777:
“But if you have a Mac with more than one user account, it means that anyone can modify anyone else’s files, just like in the old days of DOS.”
How should granted _write_-permissions of an enclosing folder affect the permissions of the folders contained (eg. /Users/admin)? None of the user’s homedir’s permissions had changed. No way to alter their contents in any way due to write permissions in the /Users parent dir. The conclusion is wrong isn’t it?
I will admit that I didn’t apply the 11.2 update myself (I now have 11.2.1), so I don’t know exactly what changed…
I have ditched the comparison to DOS so that sentence now merely echoes Apple’s warning, “local users can compromise others’ accounts.”
Hope that reads better.
Thank you. After some investigation on saturday I believe an Apple employee wrote the security advisory by accident (they were in a hurry to release the 11.2.1 fix). I diffed the installer contents from both 11.2 and 11.2.1 and the whole fixup for messed permissions and visibility was in the fixpermissions.sh postinstall script:
chflags nohidden /Users /Users/Shared
chmod 755 /Users
chmod +t /Users/Shared
(make folders visible, remove write permissions für /Users, reapply sticky bit to /Users/Shared). That’s all. Permissions/Ownerships of individual homedirs weren’t affected at all. The only security related stuff has been the ability to create new objects in /Users (but no accounts because /var/db/dslocal is only writeable by root).
The ability to create new objects in a directory where you aren’t supposed to is a fairly big security hole, though 🙂 Especially if you can delete an existing version first.
Creating new objects inside /Users shouldn’t be an issue at all (because account data is stored inside /var/db/dslocal if I remember correctly)?
And I still don’t get how I should be able to delete a user’s homedir when it is protected by an ACL? Are all the machines we support different from ‘Mavericks in the wild’? I’m not able to reproduce the conclusion that I should be able to compromise user accounts when /Users is set to 777 _in Mavericks_ (due to ACLs protecting homedirs).
MacOS X is based on Unix (the Mach microkernel version, specifically).
In all known versions of Unix (including all flavors of Linux), if you have write access to a directory, that gives you access to create files in that directory and, more importantly, to delete any files in that directory, regardless of the ownership or permissions on the files themselves.
The one exception is if the “sticky bit” (the leading “1” in the “1777” on /Users/Shared) is set; in that case, only the owner of a file in the common directory may delete that file.
This doesn’t allow you to write to an existing file in the directory without already having write permissions on the file itself, but it does allow you to delete the file outright and replace it with one of your own choosing, which has almost the same effect.
Ok, this means if /Users is set to 777 instead of 755 I’m able to delete a subfolder (eg. /Users/mary) but not to change it in any other way, correct?
If that would be true I wouldn’t still be able to alter important contents by recursively copy the contents, delete /Users/mary and replace it with my modified copy (because /Users/mary retained its permissions which are 700 owned by mary). Even after that mary won’t be able to login because her homedir is owned by someone else.
But most importantly: The bug only affected Mavericks. And in all the 10.9 installations we support one specific ACL is attached to each user’s homedir:
0: group:everyone deny delete
And when I try to delete a homedir the doesn’t belong to me I simply get a ‘Permission denied’ message.
I’m still not able to understand how I should be able to ‘compromise other local user accounts’ if /Users is world-writeable _in 10.9_. Please help me to understand the issue — what am I’m doing wrong?
At the moment I believe the whole security advisory is based on a misunderstanding (common knowledge about POSIX permissions without checking the impact in detail and ignoring ACLs)
Correct. You would be able to delete the subdirectory (Mary’s home directory) just like any other file, but if you do not have read/execute permission on the subdirectory, you wouldn’t be able to copy it and would have to fabricate its contents from some other source. Also, without those permissions you would not be able to recursively delete the directory, and you can’t delete a non-empty directory as an unprivileged user.
The ACL you describe does mitigate the security gap created by opening the permissions to 777 if applied consistently. The key issue is that although there were other protections in place, the permissions being given were inappropriate and rely on the ACLs, which are not commonly used on other Unix-like systems. Correcting the permissions is a best practice and restores a posture of defense in depth.
I totally agree that permissions should be fixed (and the iTunes 11.2.1 installer tried to do that). But I still don’t get the reason why someone at Apple used a CVE ID and wrote a security advisory because due to homedir ACLs there existed no security hole at all?
The whole thing was limited to 10.9 and occured when either “find my mac” has been activated (manually in system preferences or caused by a restart) or maybe when “enable guest account” was invoked (“find my mac” activates the guest account). And since the user’s homedirs permissions/ACLs weren’t affected by the ‘iTunes 11.2 flaw’ permissions/ACLs of each homedir itself prevented unprivileged users from compromising other accounts.
From my limited investigations I believe the change of permissions has something to do with user template stuff altered by iTunes 11.2 (either by the installation or first launch). When the guest account is activated immediately /private/var/db/dslocal/nodes/Default/users/Guest.plist will be read and /System/Library/PrivateFrameworks/SystemAdministration.framework/XPCServices/writeconfig.xpc/Contents/MacOS/writeconfig is called many times. And maybe a specific rule to adjust permissions on the guest account’s homedir was malformed and changed /Users and /Users/Shared?
Unfortunately I trashed the 11.2 installer in the meantime (saved only the results of “pkgutil –expand”) so I can not dig deeper into it. And Apple’s security advisory is obviously wrong (‘the permissions for the /Users and /Users/Shared directories would be set to world-writable’ — /Users/Shared has to be worl-writable and it just lost its sticky bit due to the bug)
I guess you can argue that a directory with permissions 0777 is “more world writable” than one with 1777 permissions [*], since the sticky bit limits tampering with existing files by non-owners. I think it’s fair to say that: it was a bug; it shouldn’t have happened, it’s mildly worrying that it got past QA; and it’s good work by Apple to fix it in double-quick time.
[*] Setting the directory flag in the bit position denoted by 0 and 1 above turns on the so-called “sticky bit,” which means that although anyone can write a new file into the directory, only the user who actually wrote the file in the first place can later delete or rename it. (That precludes “modifying” it by deleting it and making a new version with the same name.)
Agreed. 🙂
But I’m still unable to follow the conclusion regarding compromising local user accounts (due to the bug being limited to 10.9 where homedirs are protected by an ACL even if the parent dir is world-writable). The wordings of Apple’s security advisory let me still believe the person in question didn’t get the whole thing since permissions of /Users and /Users/Shared were mixed up in the description and ACLs not been considered.
But given the short amount of time it took to provide the fix, support article and security advisory (involving different departments) I believe it’s better to be somewhat inaccurate describing potential impacts than delaying the roll-out of the fix.
Regarding the bug itself it was really interesting to have a look how/why the ‘installation of iTunes’ (in reality a huge metapackage containing CoreADI.pkg, CoreFP.pkg, MobileDevice.pkg containing new versions of AppleMobileDevice.kext and AppleUSBEthernetHost.kext, iTunesAccess.pkg and iTunesX.pkg) might affect boundary conditions of the “find my mac” functionality (FMM) or maybe activation of the guest account (and how resetting NVRAM helped people let adjusted permissions persist over reboots due to deleting FMM related settings from NVRAM)
All that to listen to some music, eh 🙂