Let's talk about the "things" Of The osx sip mechanism"

Let's talk about the "things" Of The osx sip mechanism"
I. Preface

OSX is an exclusive operating system developed by Apple for Mac products. It is the first FreeBSD-based system to adopt an object-oriented operating system.

From the OSX V10.0-V10.8 version, OSX systems are all codenamed big cats, maybe old Joe is also a fan of cats (I am also a loyal fan of cats, haha ), the OSX system is evolved as follows:

2001Mac OSX 10.0 Cheeta Cheetah

2001Mac OSX 10.1 Puma

2002Mac OSX 10.2

2002Mac OSX 10.3 Panther

2005Mac OSX 10.4 Tiger

2006Mac OSX 10.5 Leopard

2009Mac OSX 10.6 Snow Leopard

2010Mac OSX 10.7 Lion

2012Mac OSX 10.8 Mountain Lion Puma

2013Mac OSX 10.9 Mavericks (name of the California attraction)

2014Mac OSX 10.10 Yosemite (launched a new flat interface)

2015Mac OSX 10.11 EI Capitan, a granite name in the National Park

From the above we can see that Apple's name for the operating system is quite interesting. I have been using the Apple system since the Mavericks system, and now I have more than three years of experience in using it, I personally feel that the apple system is quite convenient. This WWDC 2015 Apple brought osx ei Capitan system. As soon as it came out, I immediately updated my own MBP.

This change is also quite big, and the overall system performance has been improved. From the perspective of a security personnel, I will analyze the important security features in OSX EI Capitan: system Integrity Protection of SIP (SystemIntegrity Protection)

Ii. First knowledge of SIP

After upgrading the system, I encountered some problems when performing an operation. I was prompted that the system permissions were insufficient. However, when I upgraded to sudo, I still prompted: operation not permitted. At that time, I was quite depressed. What's the problem? After a google click, we found that a SIP function was added to osx ei Capitan. No matter whether you are su or not, it will prevent you from operating in the system directory ......

At that time, the only idea was: can this thing be shut down? How can this problem be solved? Or Google ...... The following method is found:

(1) restart the OSX system, and then press and hold Command + R

(2) After the page appears, select Terminal in Utilities menu

(3) Enter csrutil disable in Terminal to disable SIP (csrutil enable to enable SIP)

(4) Restart reboot OSX

This method has also been mentioned in the article "OSX kernel debugging technology sharing" (Link). In fact, this is also the case for disabling SIP on the Internet, haha) if you are not interested in OSX security and want to solve this problem, you can do it here, but as a security researcher, we are interested in and responsible for studying various security systems. If you are interested in SIP, you can continue to look at it!

Iii. How SIP works

The full name of SIP is System Integrity Protection (System Integrity Protection). It is used to protect System processes, files, and documents from being modified by other processes, whether it is root user or not, the SIP technology includes file system protection, runtime protection, kernel extension signature, and file system protection. The Sandbox mechanism is used to restrict root permissions and runtime protection, it is mainly to protect key processes from being injected by Process Code, hanging on the debugger and kernel debugging, and extending the signature of the kernel. all third-party kext must be installed in/Library/Extensions and use the signature forcibly.

In the official documentation provided by Apple, we can find the working principle of osx sip (). This document describes Apple's new OSX system, using the following OSX Security Model:

 

This security mode reduces the previous root permissions and uses the sandbox to protect the system by default. It provides a configuration mechanism that cannot be automatically penetrated by the root. We can use the command line tool to view the protected directory,

 

We can see that the system restricted directories marked with restricted are defined by the new OSX security model when the system is started, after that, no matter whether the user uses the root permission or not, they cannot operate on these directories. You can view the file information in the directory, and you can see that the file is also marked as restricted, for example:

 

SIP also protects the driver. When we used a third-party driver, we can use kext-dev-mode = 1 to load the Third-Party driver, SIP requires us to place the Third-Party driver in the/Library/Extensions directory, and disable the kext-dev-modeboot-arg startup Item. We can view the kext in this directory, no restricted is found, but the kext in the System directory is restricted. Which directories and files or drivers are protected? From the/System/Library/Sandbox directory, we can see rootless. conf, which is the configuration file of rootless, mainly used to describe which directories, programs, and symbolic links are protected, as shown in:

 

 

This file shows the overall configuration information protected by SIP in The OSX system. In fact, the SIP mechanism is Apple's hierarchical security mechanism, which sets a rootless configuration file at the underlying layer, and then in the system, add a restricted flag to the configuration file. This flag information cannot be copied. The default configuration of this flag exists. Apple uses the underlying sandbox for protection, no additional permission is required, which also reduces the permissions of the root user in OSX.

Iv. Analysis of SIP cracking principles

As the saying goes: There are defenses and attacks, and there is always a way to crack the SIP. To study the mechanism of cracking the SIP, where should we start? Let's start with the method provided on foreign websites. How can this problem be solved? As mentioned above, to disable OSX, you must perform this command in the Recovery OS mode (is it in Windows security mode). Why? Here we will not operate this tool in the Recovery OS mode first, as shown below:

 

The help of the tool is clearly written, Only available inRecovery OS. If we run it directly, we will get the following results:

 

With the help above, we can use this tool to view the current SIP status ,:

 

Now we need to analyze the csrutil program. It is very simple to copy csrutil from/usr/bin to ida. The program is relatively small. From this, we can see that csrutil is mainly used to set IODeviceTree: in the/options item, we mainly look at two functions, one is the Clear SIP function, as follows:

 

Another is to set the SIP function, which can enable/disable SIP. It is mainly set by passing in different parameters, as shown below:

 

From the above, we can see that csrutil mainly modifies the sip settings by setting the value in IODeviceTree:/options, and uses the ioreg tool to check the value in IODeviceTree:/options. The command line is as follows: ioreg-l-p IODeviceTree. If the SIP is not disabled, the result is as follows:

 

As you can see, it is the same as the system startup item we obtained using nvram. You can try it on your own by using the command line:

Nvram-xp is mainly used to obtain the startup Item values of the system. You can check the information for reference.

We can find from the decompiled csrutil program that it enables/disables the SIP by setting the csr-data or csr-active-config items. we disable the SIP, then, use the iosreg tool to obtain the value of IODeviceTree:/options in the Recovery OS mode, as shown below:

 

The csr-active-config value in is set to <77000000>, So we disable the SIP, but why are we in IODeviceTree: after the csr-active-config value is set in/options, we disable the SIP?

In fact, the value of IODeviceTree:/options can be seen that this is the startup option of the operating system. When the startup option of the operating system contains the csr-active-config value, we closed the SIP. Fortunately, our OSX is an open-source project. We don't need to decompile OSX Kernel to find the answer, download the OSX system source code from apple's website, and then find the csr-related source code, soon we can find the following two codes:csr.h(xnu/bsd/sys/csr.h),csr.c(xnu/bsd/kern/kern_csr.c)To view the source code of kern_csr.c, we can find the following function:

When the system starts, there is a Syscall process (for details, there is a csrctl function, which is the Syscall entry function. The function code is as follows:

 

There is a syscall_csr_check function and syscall_csr_get_active_config. In fact, it is used to detect the system startup Item. When the system startup Item contains csr-active-config or csr-data, check the following function:

 

When the mask is zero, rootless enforcement is started. When the csr-active-config exists in the system startup Item, rootless is disabled and EPERM is returned.

Why do we set the value to <77000000> above? We can find the answer from the csr. h header file, as shown in:

When the BootArgs Flag is "kBootArgsFlagCSRBoot", the system is in RecoveryOS mode, and then the Rootless Configuration flags is set to disable SIP-related protection. When the value is 0 × 77 (1110111, the entire rootless system will disable various file protection and runtime protection.

In this way, we can basically figure out how the above mechanism is used to disable SIP. A few days ago, I saw a foreign cool man on Github, I wrote a SIP exploit (source code link). Here we will also analyze the principle of this exploit. First gitclone the code, and then we can view the code in it. The Code is also very simple, for a rough analysis, we can see from the main function that different statuses are returned through different parameters, and then map the osx kernel file (/System/Library/Kernels/kernel ), as follows:

 

Then, use the OSKextCopyLoadedKextInfo function to obtain the address of the kernel space ,:

 

Call the csr_set_allow_all function in the kernel through the drop technique, and pass in different parameters through different status values to enable/disable the SIP. The Code is as follows:

 

(If you are not familiar with the ROP technology, you can refer to some of the articles written by Dr. aliyun.com, which are well written.

When we call disable, status = 1, and then call the csr_set_allow_all function through the drop operation, we can disable the SIP, IDA decompile the kernel file, and then find the csr_set_allow_all as follows:

 

In this way, we can disable the SIP. Why? We can see that this csr_set_allow_all function is not very familiar, good, is the function we saw in kern_csr.c, as shown in:

 

When we call csr_allow_all and pass in the status = 1 parameter, the value of csr_allow_all is equal to 1. Let's look up the code below:

 

When csr_init is initialized, if csr_allow_all = 1, the system automatically closes the SIP when it starts. Is it a good time!

V. Summary

In this way, we have analyzed some things in the SIP in The OSX EICapitan system. In fact, there may be many places to mine. We need to mine them, maybe we can find out more exploits. There may be more and more people studying OSX/IOS security issues in the future!

The chicken soup of the soul will not be said, and the last sentence you have always liked is what xingye said: What is the difference between being a person without a dream and a salted fish? Whether you have money or a high position, your dream is something everyone should have. No matter how big it is, we are sticking to what we should stick to and trying to do our own thing!

The road is long, and I will go up and down to seek help. You are very welcome to exchange and learn with me!