| 01 |
02 |
03 |
04 |
05 |
06 |
07 |
08 |
09 |
10 |
11 |
12 |
13 |
14 |
15 |
16 |
17 |
18 |
19 |
20 |
21 |
22 |
23 |
24 |
25 |
26 |
27 |
28 |
29 |
30 |
17-Sep-2014 [18:11] -- XNU Kernel stack and heap information leaks
Today Apple released IOS8 and then credited a lot of vulnerability researchers for fixed bugs. Find more information at
http://support.apple.com/kb/HT6441
Here I am going to present details of 4 of them where I was credited:
CVE-2014-4371, CVE-2014-4419, CVE-2014-4420 and CVE-2014-4421. As weird as it sounds, I found them on a plane reading the XNU kernel code :S
One of those is a "kernel stack content information leak" and was confirmed on latest version of MacOSX and IOS at the time I reported to Apple (May 8th 2014). PoC here:
ntstat-x.c
$ ./ntstat_x
Leaked 4 bytes at the kernel stack: 0xd5d38dfd
$
The problem resides at the very end of the file
http://www.opensource.apple.com/source/xnu/xnu-2050.48.11/bsd/net/ntstat.c.
When going back to user mode you do not clear the err.hr.pad field leaving it with the original stack contents.
if (result != 0)
{
struct nstat_msg_error err;
err.hdr.type = NSTAT_MSG_TYPE_ERROR;
err.hdr.context = hdr->context;
err.error = result;
result = ctl_enqueuedata(kctl, unit, &err, sizeof(err), CTL_DATA_EOR);
}
Fix should be to zero out the entire structure before setting fields and returning from kernel mode.
The other three instances of this info leak lead to another two kernel stack info leak and a more interesting heap info leak. I am pretty sure the last one can be used to leak pointers to the kernel and bypass K-ASLR.
Stack content leak: nstat_control_send_counts
Heap content leak: nstat_control_send_description
Stack content leak: nstat_control_send_removed
Fermin J. Serna - @fjserna
Comments (0)
