Example: quiz answers

Revisiting iOS Kernel (In)Security: Attacking the early ...

Revisiting iOS Kernel (In) security : Attacking theearlyrandom()PRNGT arjei MandtAzimuth is by many considered to be one of the most secure mo-bile platforms due to its stringent security features and relatively strongfocus on mitigation technology. In an effort to improve Kernel security ,iOS 6 introduced numerous mitigations including verification cookies andmemory layout randomization. Conceptually, these mitigations seek tocomplicate Kernel exploitation by leveraging non-predictable data andtherefore require sufficient entropy to be provided at boot time. In thispaper, we evaluate the security of the early random pseudorandom num-ber generator.

Revisiting iOS Kernel (In)Security: Attacking the early random() PRNG Tarjei Mandt Azimuth Security tm@azimuthsecurity.com Abstract. iOS is by many considered to be one of …

Tags:

  Security, Early, Kernel, Random, Revisiting, Attacking, Revisiting ios kernel, Attacking the early random

Information

Domain:

Source:

Link to this page:

Please notify us if you found a problem with this document:

Other abuse

Transcription of Revisiting iOS Kernel (In)Security: Attacking the early ...

1 Revisiting iOS Kernel (In) security : Attacking theearlyrandom()PRNGT arjei MandtAzimuth is by many considered to be one of the most secure mo-bile platforms due to its stringent security features and relatively strongfocus on mitigation technology. In an effort to improve Kernel security ,iOS 6 introduced numerous mitigations including verification cookies andmemory layout randomization. Conceptually, these mitigations seek tocomplicate Kernel exploitation by leveraging non-predictable data andtherefore require sufficient entropy to be provided at boot time. In thispaper, we evaluate the security of the early random pseudorandom num-ber generator.

2 The early random PRNG is fundamental in supportingthe mitigations leveraged by the iOS Kernel . Notably, we show how anattacker can recover arbitrary outputs generated by the early randomPRNG in iOS 7 without being assisted by additional vulnerabilities orhaving any prior knowledge about the Kernel address space. Recoveringthese outputs essentially allows an attacker to bypass a variety of exploitmitigations, such as those designed to mitigate specific exploitation tech-niques or whole classes of vulnerabilities. In turn, this may allow trivialexploitation of vulnerabilities previously deemed :iOS, Kernel , mitigations, pseudorandom number generator1 IntroductionOver the past few years, several improvements have been made to the iOS kernelin order to address the increasing number of attacks (primarily motivated byjailbreaks) targeting the iOS platform.

3 For the most part, this includes a hostof new mitigations, primarily designed to break known exploitation techniques(such as the zone free list pointer overwrite) and make it more difficult for anattacker to predict the layout of the Kernel address space. Fundamentally, thesemitigations rely on non-predictable data and therefore require sufficient entropyto be provided at boot time. Thus, in order to support the initialization ofthese mitigations, Apple introduced theearlyrandom()pseudorandom pseudorandom number generator (PRNG) is an algorithm for generat-ing a sequence of random numbers that approximates the properties of ran-dom numbers.

4 PRNGs differ from truly random number generators in that theyare deterministic and seeded with an initial state, but are commonly employedin software for their speed and reproducibility. Although both iOS and OS Xprovide pseudorandom number generation through the cryptographically secureYarrow generator [5], Kernel level mitigations require random values very earlyin the boot process, before the Kernel entropy pool is available. As such, the earlyrandom PRNG serves as a temporary replacement for the Yarrow generator inorder to supply the Kernel with acceptable entropy at boot of the most challenging aspects of boot time random value generation isfinding good sources of entropy.

5 Desktop operating systems such of Windows [6]and Linux commonly leverage a variety of sources such as timing information,device configuration, and dedicated random number generators provided by re-cent Intel CPUs as well as the Trusted Platform Module. Currently, embeddedoperating systems such as iOS appear to have less options for finding viablesources of entropy, especially in the absence of dedicated hardware. In iOS 6,the early random PRNG solely relied on timing (clock) information for generat-ing random values. This resulted in well-correlated output, especially in the caseof successively generated values.

6 Thus, in an effort to improve the entropy andleverage a more widely understood algorithm, iOS 7 switched to using a linearcongruential generator (LCG).An LCG is an algorithm that yields a sequence of random numbers calculatedwith a linear equation. LCGs are one of the oldest and best-known pseudoran-dom number generator algorithms, and are commonly leveraged in standardlibraries and applications for being fast and easy to implement. Although thesealgorithms perform well in resource-constrained environments and have appeal-ing statistical properties, they exhibit some severe defects and are easily brokenwhen confronted by an adversary who can monitor outputs [7][2].

7 As such, LCGsshould not be used for cryptographic applications or security related this paper, we evaluate the security of the early random PRNG. Notably,we show how an attacker can recover arbitrary outputs generated by the earlyrandom PRNG in iOS 7 without being assisted by additional vulnerabilities orhaving any prior knowledge about the Kernel address space. Recovering theseoutputs essentially allows an attacker to bypass a variety of exploit mitigations,such as those designed to mitigate specific exploitation techniques or classesof vulnerabilities.

8 In turn, this may allow trivial exploitation of vulnerabilitiespreviously deemed rest of this paper is organized as follows. In Section 2, we examine thedifferences between the early random PRNG in iOS and OS X, and describe thechanges made in iOS 7. In Section 3, we survey the various security featuresand mitigations that rely on the output provided by the early random Section 4, we perform a thorough analysis of the early random PRNG iniOS 7 and assess ways where an attacker may be able to predict PRNG , in Section 5 we demonstrate how the findings presented in Section4 can be applied to a real world attack, without relying on additional infor-mation leaks or vulnerabilities.

9 Finally, in Section 6 and 7, we discuss possibleimprovements and provide a conclusion of the ImplementationAs embedded and desktop platforms run on different hardware (ARM vs. x86),the early random PRNG is implemented differently in iOS and OS X. In thisSection, we examine both implementations and look at their early random PRNG in OS XThe early random PRNG is commonly accessed via theearlyrandom()func-tion. On Intel platforms, this function is written entirely in assembly and can bereviewed in the open source release of the XNU (ml_early_random)mov %rbx, %rsimov $1, %eaxcpuidmov %rsi, %rbxtest $(1 << 30), %ecxjz Lnon_rdrandRDRAND_RAX /* RAX := 64 bits of DRBG entropy */jnc Lnon_rdrandretLnon_rdrand:rdtsc /* EDX:EAX.

10 = TSC *//* Distribute low order bits */mov %eax, %ecxxor %al, %ahshl $16, %rcxxor %rcx, %raxxor %eax, %edx/* Incorporate ASLR entropy, if any */lea (%rip), %rcxshr $21, %rcxmovzbl %cl, %ecxshl $16, %ecxxor %ecx, %edxmov %ah, %clror %cl, %edx /* Right rotate EDX (TSC&0xFF ^ (TSC>>8 & 0xFF))&1F */shl $32, %rdxxor %rdx, %raxmov %cl, %alretListing 1:earlyrandom()in OS X [osfmk/x8664 ]As can be seen from Listing 1,earlyrandom()in OS X first checks if therunning processor supports theRDRAND instruction by requesting processor iden-tification and feature information fromCPUID(EAX=1).


Related search queries