|
|
MacOS/iOS kernel heap overflow due to lack of lower size check in getvolattrlist |
|||
Issue description
getvolattrlist takes a user controlled bufferSize argument via the fgetattrlist syscall.
When allocating a kernel buffer to serialize the attr list to there's the following comment:
/*
* Allocate a target buffer for attribute results.
* Note that since we won't ever copy out more than the caller requested,
* we never need to allocate more than they offer.
*/
ab.allocated = ulmin(bufferSize, fixedsize + varsize);
if (ab.allocated > ATTR_MAX_BUFFER) {
error = ENOMEM;
VFS_DEBUG(ctx, vp, "ATTRLIST - ERROR: buffer size too large (%d limit %d)", ab.allocated, ATTR_MAX_BUFFER);
goto out;
}
MALLOC(ab.base, char *, ab.allocated, M_TEMP, M_ZERO | M_WAITOK);
The problem is that the code doesn't then correctly handle the case when the user supplied buffer size
is smaller that the requested header size. If we pass ATTR_CMN_RETURNED_ATTRS we'll hit the following code:
/* Return attribute set output if requested. */
if (return_valid) {
ab.actual.commonattr |= ATTR_CMN_RETURNED_ATTRS;
if (pack_invalid) {
/* Only report the attributes that are valid */
ab.actual.commonattr &= ab.valid.commonattr;
ab.actual.volattr &= ab.valid.volattr;
}
bcopy(&ab.actual, ab.base + sizeof(uint32_t), sizeof (ab.actual));
}
There's no check that the allocated buffer is big enough to hold at least that.
Tested on MacOS 10.13.4 (17E199)
,
May 28
(It is possible to open '/' O_RDONLY from the Application Sandbox on iOS so you can reach this issue there)
,
Jun 5
Fixed in MacOS 10.13.5: https://support.apple.com/en-us/HT208849 Fixed in iOS 11.4: https://support.apple.com/en-us/HT208848
,
Jun 5
,
Jun 6
How can I leak kaslr?
,
Jun 6
Nice work..
,
Jun 6
Got it thanks
,
Jun 8
Love your work man
,
Jun 9
Very interesting
,
Jun 13
Exploit for iOS 11 through iOS 11.3.1
,
Jun 13
This is the VFS you where talking about?
,
Jun 13
Better Exploit
,
Jun 13
|
||||
►
Sign in to add a comment |
||||
Comment 1 by ianbeer@google.com
, Apr 19