Protecting Sierra: SIP and its vulnerability

System Integrity Protection (SIP) was thrust at us in El Capitan, and has been tightened up in Sierra. Its aim is to prevent anything – trusted software, malware, or users – from modifying those files and folders which are integral to macOS, including all its standard bundled apps. For the great majority of Mac users, SIP has worked entirely behind the scenes, and not caused any problems.

If you have tried to remove any of Apple’s bundled apps in Sierra, you will have clashed with SIP. For now every app installed with macOS is protected. That includes: App Store, Automator, Calculator, Calendar, Chess, Contacts, DVD Player, Dashboard, Dictionary, FaceTime, Font Book, Image Capture, Launchpad, Mail, Maps, Messages, Mission Control, Notes, Photo Booth, Photos, Preview, QuickTime Player, Reminders, Safari, Siri, Stickies, System Preferences, TextEdit, Time Machine, Activity Monitor, AirPort Utility, Audio MIDI Setup, Bluetooth File Exchange, Boot Camp Assistant, ColorSync Utility, Console, Digital Color Meter, Disk Utility, Grab, Grapher, Keychain Access, Migration Assistant, Script Editor, System Information, Terminal, and VoiceOver Utility.

The Finder, of course, won’t tell you that. If you want to see which files and folders are protected by SIP, you’ll have to open Terminal and ask at the command line, using
ls -laO path
to view settings for path.

For a few Mac users, though, SIP has been a real pain. One example is anyone trying to use an Apple USB SuperDrive with an older Mac. Apple deliberately prevents this, if that model of Mac was available at the time with an internal SuperDrive. So when the internal optical drive in a 2011 iMac fails, you cannot use the Apple USB SuperDrive for your more recent iMac as a replacement. A method to remove that absurd limitation was discovered, but requires modification of one of the files now protected by SIP, so it cannot readily be changed to enable use of the optical drive.

SIP has been much more of a headache to developers and system administrators, who do not infrequently have legitimate reasons for wanting to modify files and folders which are now protected by it. You can still turn SIP off if you need, but that is hardly a good solution in many cases. To do this, you must restart in Recovery mode, launch Terminal from the Utilities menu, and enter the command
csrutil disable

Normally a reboot is required after that to enforce the change. Once you have finished doing whatever you need to do in protected files/folders, to enable SIP again, you have to enter Recovery mode again, launch Terminal, and enter
csrutil enable

System administrators may need to configure Macs to use NetBoot, which requires use of the csrutil netboot options. Not that these are documented in a conventional man page: csrutil doesn’t have one, and you need to enter
csrutil
to see its terse help information.

What that information doesn’t tell you is that SIP control is more sophisticated than that on/off toggle. As I detailed here, you can control each of SIP’s different protection features individually. What’s more, you don’t have to start up from the standard Recovery partition in order to take control of SIP. The way that Apple’s own OS X and macOS installers obtain free access to files and folders normally protected by SIP is to bring their own Recovery partition, and start up from that.

Topher Nadauld, of the University of Utah, has worked out how to modify an OS X or macOS Installer to perform customised upgrades and leave SIP disabled: he details this in his blog article here.

Quite independently, Patrick Wardle of Objective-See has used the same underlying mechanism to demonstrate a zero-day vulnerability in SIP, which applies to both El Capitan and Sierra up to and including 10.12.1. This is not an attack which can be exploited remotely, but Patrick doesn’t think that the attack requires to be launched during a system update/upgrade.

This opens up its potential for self-installation through a Trojan, perhaps. I recommend that anyone interested in this read Patrick’s article detailing it: it is very well-written and should be completely accessible to most Mac users who understand a little about SIP.

It is now more than two months since Apple was informed of this zero-day vulnerability in El Capitan and Sierra. Although it is not being exploited at present, and in its current form requires local access to the system to be attacked, it is often only a matter of time before someone comes up with a far more threatening exploit which uses such a vulnerability. Let’s hope that it will be addressed in macOS Sierra 10.12.2, due out any day now.

4Comments

Add yours

1

Tony on December 5, 2016 at 3:34 pm

“It is now more than two months since Apple was informed of this zero-day vulnerability in El Capitan and Sierra. Although it is not being exploited at present…”

Is this not contradictory? I believe that a vulnerability is only ‘zero day’ if it is exploited without being previously known (that is, there were zero days in which to prevent/mitigate its effects). Zero day is not in itself a statement of seriousness and it would be sad to lose yet another clear term to hyperbole.

LikeLike
- 2
  
  hoakley on December 5, 2016 at 6:16 pm
  
  I do not believe that all zero-day vulnerabilities have to be exploited by malware. Wikipedia (quoting) explains “it is known as a ‘zero-day’ because it is not publicly reported or announced before becoming active, leaving the software’s author with zero days in which to create patches or advise workarounds to mitigate its actions.”
  Apple had zero days to address the vulnerability when it was notified of it over two months ago, as the vulnerability existed and was out there awaiting exploit. We presume that it has not been exploited yet, which would turn it into a zero-day attack.
  Howard.
  
  LikeLike
  - 3
    
    Tony on December 5, 2016 at 10:38 pm
    
    Yes, but I read “active” as meaning “exploited” (which is consistent with their section called Window of Vulnerability). Otherwise, all vulnerabilities are zero day when first discovered.
    
    I would also quote from Anderson (Security Engineering, 2nd edition p117): “There is a variant in which the vulnerability is exploited at once rather than reported – often called a zero-day exploit as attacks happen from day zero of the vulnerability’s known existence”.
    
    I am assuming that Patrick did not exploit the vulnerability 😉 I also think we can agree that it’s serious, however it is classified.
    
    LikeLike
    - 4
      
      hoakley on December 5, 2016 at 11:30 pm
      
      Although it is serious, I don’t think that there is any cause for alarm unless someone is able to chain the exploit to enable, say, a Trojan to use it – perhaps a bogus macOS updater like the many malware Flash updaters. Then we should get much more concerned.
      It is concerning that Apple seems to have taken so long to respond – we will see shortly in 10.12.2 just how long that will be!
      Howard.
      
      LikeLike

Share this:

Related