You also want an ePaper? Increase the reach of your titles
YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.
In order to find <str<strong>on</strong>g>the</str<strong>on</strong>g> kernel, Stage 2 begins by opening a port to <str<strong>on</strong>g>the</str<strong>on</strong>g> IOKit subsystem. Failing this,<br />
Stage 2 calls <str<strong>on</strong>g>the</str<strong>on</strong>g> assert callback and exits. A call to IOServiceMatching for <str<strong>on</strong>g>the</str<strong>on</strong>g> service<br />
named AppleKeyStore is made by Stage 2, and <str<strong>on</strong>g>the</str<strong>on</strong>g> results <str<strong>on</strong>g>of</str<strong>on</strong>g> <str<strong>on</strong>g>the</str<strong>on</strong>g> call are given to<br />
IOServiceGetMatchingService in order to obtain a io_service_t object c<strong>on</strong>taining <str<strong>on</strong>g>the</str<strong>on</strong>g><br />
desired registered IOKit IOService (in this case, AppleKeyStore). With <str<strong>on</strong>g>the</str<strong>on</strong>g> IOService handle,<br />
Stage 2 calls io_service_open_extended and passes a specially crafted properties field to<br />
<str<strong>on</strong>g>the</str<strong>on</strong>g> service. The properties field is a (serialized) binary representati<strong>on</strong> <str<strong>on</strong>g>of</str<strong>on</strong>g> XML data that<br />
io_service_open_extended ultimately passes to <str<strong>on</strong>g>the</str<strong>on</strong>g> OSUnserializeBinary functi<strong>on</strong><br />
located in <str<strong>on</strong>g>the</str<strong>on</strong>g> kernel 2 . Within <str<strong>on</strong>g>the</str<strong>on</strong>g> OSUnserializeBinary functi<strong>on</strong> is a switch statement that<br />
handles <str<strong>on</strong>g>the</str<strong>on</strong>g> various types <str<strong>on</strong>g>of</str<strong>on</strong>g> data structures found within a binary XML data structure. The data<br />
type for kOSSerializeNumber blindly accepts <str<strong>on</strong>g>the</str<strong>on</strong>g> length <str<strong>on</strong>g>of</str<strong>on</strong>g> <str<strong>on</strong>g>the</str<strong>on</strong>g> data without performing any<br />
type <str<strong>on</strong>g>of</str<strong>on</strong>g> reas<strong>on</strong>able bound checking, which ultimately gives <str<strong>on</strong>g>the</str<strong>on</strong>g> caller <str<strong>on</strong>g>the</str<strong>on</strong>g> ability to request more<br />
memory than should be allowed. This c<strong>on</strong>diti<strong>on</strong> occurs due to <str<strong>on</strong>g>the</str<strong>on</strong>g> following code fragments:<br />
len = (key & kOSSerializeDataMask);<br />
...<br />
case kOSSerializeNumber:<br />
bufferPos += size<str<strong>on</strong>g>of</str<strong>on</strong>g>(l<strong>on</strong>g l<strong>on</strong>g);<br />
if (bufferPos > bufferSize) break;<br />
value = next[1];<br />
value