Apple macos < 10.14.5 / ios < 12.3 xnu wildread due to bad cast in stf_ioctl Vulnerability / Exploit
/
/
/
Exploits / Vulnerability Discovered : 2019-05-21 |
Type : dos |
Platform : multiple
This exploit / vulnerability Apple macos < 10.14.5 / ios < 12.3 xnu wildread due to bad cast in stf_ioctl is for educational purposes only and if it is used you will do on your own risk!
# Explanation
SIOCSIFADDR is an ioctl that sets the address of an interface.
The stf interface ioctls are handled by the stf_ioctl function.
The crash occurs in the following case where a `struct ifreq`
is read into kernel memory and then casted to the incorrect
`struct ifaddr` type. I suspect this ioctl is not intended to
be reachable by the user, but is unintentionally exposed without
the necessary translation from `ifreq` to `ifaddr`, e.g. as it is
done in `inctl_ifaddr`.
case SIOCSIFADDR:
ifa = (struct ifaddr *)data;
if (ifa == NULL) {
error = EAFNOSUPPORT;
break;
}
IFA_LOCK(ifa);
if (ifa->ifa_addr->sa_family != AF_INET6) { // <- crash here
IFA_UNLOCK(ifa);
error = EAFNOSUPPORT;
break;
}
Note that IFA_LOCK is called on user-provided data; it appears that there
is an opportunity for memory corruption (a controlled write) when using
indirect mutexes via LCK_MTX_TAG_INDIRECT (see lck_mtx_lock_slow).
# Explanation
SIOCSIFADDR is an ioctl that sets the address of an interface.
The stf interface ioctls are handled by the stf_ioctl function.
The crash occurs in the following case where a `struct ifreq`
is read into kernel memory and then casted to the incorrect
`struct ifaddr` type. I suspect this ioctl is not intended to
be reachable by the user, but is unintentionally exposed without
the necessary translation from `ifreq` to `ifaddr`, e.g. as it is
done in `inctl_ifaddr`.
case SIOCSIFADDR:
ifa = (struct ifaddr *)data;
if (ifa == NULL) {
error = EAFNOSUPPORT;
break;
}
IFA_LOCK(ifa);
if (ifa->ifa_addr->sa_family != AF_INET6) { // <- crash here
IFA_UNLOCK(ifa);
error = EAFNOSUPPORT;
break;
}
Note that IFA_LOCK is called on user-provided data; it appears that there
is an opportunity for memory corruption (a controlled write) when using
indirect mutexes via LCK_MTX_TAG_INDIRECT (see lck_mtx_lock_slow).