macOS / iOS - Multiple Kernel Use-After-Frees due to Incorrect IOKit Object Lifetime Management in I

Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1377 
  
 IOTimeSyncClockManagerUserClient provides the userspace interface for the IOTimeSyncClockManager IOService. 
  
 IOTimeSyncClockManagerUserClient overrides the IOUserClient::clientClose method but it treats it like a destructor. 
 IOUserClient::clientClose is not a destructor and plays no role in the lifetime management of an IOKit object. 
  
 It is perfectly possible to call ::clientClose (via io_service_close) in one thread and call an external method in another 
 thread at the same time. 
  
 IOTimeSyncClockManagerUserClient::clientClose drops references on a bunch of OSArrays causing them to be free'd, 
 it also destroys the locks which are supposed to protect access to those arrays. This leads directly to multiple UaFs 
 if you also call external methods which manipulate those arrays in other threads. 
  
 For an exploit some care would be required to ensure correct interleaving such that the OSArray was destroyed and then 
 used *before* the lock which is supposed to be protecting the array is also destroyed, but it would be quite possible. 
  
 Tested on MacOS 10.13 (17A365) on MacBookAir5,2 
 */ 
  
 // ianbeer 
 // build: clang -o timesync_uaf timesync_uaf.c -framework IOKit -lpthread 
 // repro: while true; do ./timesync_uaf; done 
  
 #if 0 
 MacOS multiple kernel UAFs due to incorrect IOKit object lifetime management in IOTimeSyncClockManagerUserClient 
  
 IOTimeSyncClockManagerUserClient provides the userspace interface for the IOTimeSyncClockManager IOService. 
  
 IOTimeSyncClockManagerUserClient overrides the IOUserClient::clientClose method but it treats it like a destructor. 
 IOUserClient::clientClose is not a destructor and plays no role in the lifetime management of an IOKit object. 
  
 It is perfectly possible to call ::clientClose (via io_service_close) in one thread and call an external method in another 
 thread at the same time. 
  
 IOTimeSyncClockManagerUserClient::clientClose drops references on a bunch of OSArrays causing them to be free'd, 
 it also destroys the locks which are supposed to protect access to those arrays. This leads directly to multiple UaFs 
 if you also call external methods which manipulate those arrays in other threads. 
  
 For an exploit some care would be required to ensure correct interleaving such that the OSArray was destroyed and then 
 used *before* the lock which is supposed to be protecting the array is also destroyed, but it would be quite possible. 
  
 Tested on MacOS 10.13 (17A365) on MacBookAir5,2

#  0day.today [2018-03-20]  #