New issue
Advanced search Search tips
Starred by 2 users
Status: Fixed
Owner:
Closed: Mar 2017
Cc:



Sign in to add a comment
MacOS/iOS kernel memory corruption due to off-by-one in SIOCGIFORDER socket ioctl
Project Member Reported by ianbeer@google.com, Feb 2 2017 Back to list
SIOCSIFORDER and SIOCGIFORDER allow userspace programs to build and maintain the
ifnet_ordered_head linked list of interfaces.

SIOCSIFORDER clears the existing list and allows userspace to specify an array of
interface indexes used to build a new list.

SIOCGIFORDER allow userspace to query the list of interface identifiers used to build
that list.

Here's the relevant code for SIOCGIFORDER:

    case SIOCGIFORDER: {    /* struct if_order */
      struct if_order *ifo = (struct if_order *)(void *)data;
      
      u_int32_t ordered_count = if_ordered_count;   <----------------- (a)
      
      if (ifo->ifo_count == 0 ||
          ordered_count == 0) {
        ifo->ifo_count = ordered_count;
      } else if (ifo->ifo_ordered_indices != USER_ADDR_NULL) {
        u_int32_t count_to_copy =
        MIN(ordered_count, ifo->ifo_count);          <---------------- (b)
        size_t length = (count_to_copy * sizeof(u_int32_t));
        struct ifnet *ifp = NULL;
        u_int32_t cursor = 0;
        
        ordered_indices = _MALLOC(length, M_NECP, M_WAITOK);
        if (ordered_indices == NULL) {
          error = ENOMEM;
          break;
        }
        
        ifnet_head_lock_shared();
        TAILQ_FOREACH(ifp, &ifnet_ordered_head, if_ordered_link) {
          if (cursor > count_to_copy) {            <------------------ (c)
            break;
          }
          ordered_indices[cursor] = ifp->if_index; <------------------ (d)
          cursor++;
        }
        ifnet_head_done();


at (a) it reads the actual length of the list (of course it should take the lock here too,
but that's not the bug I'm reporting)

at (b) it computes the number of entries it wants to copy as the minimum of the requested number
and the actual number of entries in the list

the loop at (c) iterates through the list of all entries and the check at (c) is supposed to check that
the write at (d) won't go out of bounds, but it should be a >=, not a >, as cursor is the number of
elements *already* written. If count_to_copy is 0, and cursor is 0 the write will still happen!

By requesting one fewer entries than are actually in the list the code will always write one interface index
entry one off the end of the ordered_indices array.

This poc makes a list with 5 entries then requests 4. This allocates a 16-byte kernel buffer to hold the 4 entries
then writes 5 entries into there.

tested on MacOS 10.12.3 (16D32) on MacbookAir5,2
 
sioctl_off_by_one.c
3.6 KB View Download
Project Member Comment 1 by ianbeer@google.com, Feb 2 2017
Labels: Id-658482813 Reported-2016-Feb-02
Project Member Comment 2 by ianbeer@google.com, Feb 10 2017
Labels: -Reported-2016-Feb-02 Reported-2017-Feb-02
Project Member Comment 3 by ianbeer@google.com, Mar 31 2017
Labels: Fixed-2017-Mar-27 CVE-2017-2474
Status: Fixed
Fixed in MacOS 10.12.4: https://support.apple.com/en-us/HT207615
Fixed in iOS 10.3: https://support.apple.com/en-us/HT207617
Project Member Comment 4 by ianbeer@google.com, Apr 3 2017
Labels: -Restrict-View-Commit
Sign in to add a comment