This post is about a bug I found in the xnu kernel affecting the SIOCSIFORDER call. The bug affected both OS X and iOS. In iOS it affects iOS 10.3 and below so obviously it has been fixed in the lastest version of iOS.
The bug id referencing the bug was 663014551, however upon reporting I was told it was a duplicate so i guess it was a rediscovery 😒 .
Anyways , since it was my first bug report to apple I thought it was worth a blog post.
Lets begin 😃 .
So what’s SIOCSIFORDER?
SIOCSIFORDER is often used in networking and is quite helpful/useful when creating an ip address. It has been implemented in many unix systems from the linux kernel to the XNU kernel.
Below is an example of how to implement SIOCSIFORDER in c and the best example would be its implementation in creating a socket.
|
|
Bug discovery
Earlier this year, Ian Beer reported a bunch of vulnerabilities to apple that affeted the IOKit among them were SIOCSIFORDER related bugs.
Around the same time I was looking for bugs in the same area. I happened to come across a specific code section in the XNU Kernel that caught my attention.
Below is the XNU code section for SIOCSIFORDER
|
|
Looking at this piece of code i asked myself what could I control from the structure. It was pretty clear that I could control ifo_count
.
The next question was are there any boundary and type casting checks that are related with the specific element u_int32_t ifo_count
The logical flaw
if ((int)ifo->ifo_count > if_index)
is captured as an int, whilst its of type u_int32_t
hence this check is not sufficient
|
|
Take a look at the piece of code below, can you spot the problem ?
|
|
The trigger
Taking a look at ordered_indices = _MALLOC(length, M_NECP, M_WAITOK);
It’s quite evident that doing a memory alloaction with an undersired length would lead to a memory corruption which if well implemented could lead to a kernel leak.
Code Sample with trigger
|
|