macOS/iOS Kernel 10.12.3 (16D32) - Double-Free Due to Bad Locking in fsevents Device

EDB-ID: 41804
Author: Google Security Research
Published: 2017-04-04
CVE: CVE-2017-2490
Type: Local
Platform: Multiple
Aliases: N/A
Advisory/Source: Link
Tags: N/A
Vulnerable App: N/A 

 Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=1129 
  
 fseventsf_ioctl handles ioctls on fsevent fds acquired via FSEVENTS_CLONE_64 on /dev/fsevents 
  
 Heres the code for the FSEVENTS_DEVICE_FILTER_64 ioctl: 
  
     case FSEVENTS_DEVICE_FILTER_64: 
       if (!proc_is64bit(vfs_context_proc(ctx))) { 
         ret = EINVAL; 
         break; 
       } 
       devfilt_args = (fsevent_dev_filter_args64 *)data; 
        
     handle_dev_filter: 
     { 
       int new_num_devices; 
       dev_t *devices_not_to_watch, *tmp=NULL; 
        
       if (devfilt_args->num_devices > 256) { 
         ret = EINVAL; 
         break; 
       } 
        
       new_num_devices = devfilt_args->num_devices; 
       if (new_num_devices == 0) { 
         tmp = fseh->watcher->devices_not_to_watch;   <------ (a) 
          
         lock_watch_table();                          <------ (b) 
         fseh->watcher->devices_not_to_watch = NULL; 
         fseh->watcher->num_devices = new_num_devices; 
         unlock_watch_table();                        <------ (c) 
          
         if (tmp) { 
           FREE(tmp, M_TEMP);                         <------ (d) 
         } 
         break; 
       } 
  
 There's nothing stopping two threads seeing the same value for devices_not_to_watch at (a), 
 assigning that to tmp then freeing it at (d). The lock/unlock at (b) and (c) don't protect this. 
  
 This leads to a double free, which if you also race allocations from the same zone can lead to an 
 exploitable kernel use after free. 
  
 /dev/fsevents is: 
 crw-r--r--  1 root  wheel   13,   0 Feb 15 14:00 /dev/fsevents 
  
 so this is a privesc from either root or members of the wheel group to kernel 
  
 tested on MacOS 10.12.3 (16D32) on MacbookAir5,2 
  
 (build with -O3) 
  
 The open handler for the fsevents device node has a further access check: 
  
   if (!kauth_cred_issuser(kauth_cred_get())) { 
     return EPERM; 
   } 
  
 restricting this issue to root only despite the permissions on the device node (which is world-readable) 
 */ 
  
  
 // ianbeer 
 #if 0 
 MacOS/iOS kernel double free due to bad locking in fsevents device 
  
 fseventsf_ioctl handles ioctls on fsevent fds acquired via FSEVENTS_CLONE_64 on /dev/fsevents 
  
 Heres the code for the FSEVENTS_DEVICE_FILTER_64 ioctl: 
  
     case FSEVENTS_DEVICE_FILTER_64: 
       if (!proc_is64bit(vfs_context_proc(ctx))) { 
         ret = EINVAL; 
         break; 
       } 
       devfilt_args = (fsevent_dev_filter_args64 *)data; 
        
     handle_dev_filter: 
     { 
       int new_num_devices; 
       dev_t *devices_not_to_watch, *tmp=NULL; 
        
       if (devfilt_args->num_devices > 256) { 
         ret = EINVAL; 
         break; 
       } 
        
       new_num_devices = devfilt_args->num_devices; 
       if (new_num_devices == 0) { 
         tmp = fseh->watcher->devices_not_to_watch;   <------ (a) 
          
         lock_watch_table();                          <------ (b) 
         fseh->watcher->devices_not_to_watch = NULL; 
         fseh->watcher->num_devices = new_num_devices; 
         unlock_watch_table();                        <------ (c) 
          
         if (tmp) { 
           FREE(tmp, M_TEMP);                         <------ (d) 
         } 
         break; 
       } 
  
 There's nothing stopping two threads seeing the same value for devices_not_to_watch at (a), 
 assigning that to tmp then freeing it at (d). The lock/unlock at (b) and (c) don't protect this. 
  
 This leads to a double free, which if you also race allocations from the same zone can lead to an 
 exploitable kernel use after free. 
  
 /dev/fsevents is: 
 crw-r--r--  1 root  wheel   13,   0 Feb 15 14:00 /dev/fsevents 
  
 so this is a privesc from either root or members of the wheel group to kernel 
  
 tested on MacOS 10.12.3 (16D32) on MacbookAir5,2 
  
 (build with -O3)
Related Posts