Azimuth Security: Attacking the iOS 7 early_random() PRNG <body onload='MM_preloadImages(&apos;;,&apos;;,&apos;;,&apos;;)'><script type="text/javascript"> function setAttributeOnload(object, attribute, val) { if(window.addEventListener) { window.addEventListener('load', function(){ object[attribute] = val; }, false); } else { window.attachEvent('onload', function(){ object[attribute] = val; }); } } </script> <div id="navbar-iframe-container"></div> <script type="text/javascript" src=""></script> <script type="text/javascript"> gapi.load("", function() { if (gapi.iframes && gapi.iframes.getContext) { gapi.iframes.getContext().openChild({ url: '\x3d509652393303233687\x26blogName\x3dAzimuth+Security\x26publishMode\x3dPUBLISH_MODE_HOSTED\x26navbarType\x3dBLUE\x26layoutType\x3dCLASSIC\x26searchRoot\x3d\x26blogLocale\x3den\x26v\x3d2\x26homepageUrl\x3d\x26vt\x3d1038547295672672920', where: document.getElementById("navbar-iframe-container"), id: "navbar-iframe" }); } }); </script>
azimuth security services training resources about BLOG
project zeus
"You will not be informed of the meaning of Project Zeus until the time is right for you to know the meaning of Project Zeus."
Current Posts
April 2010
May 2010
August 2010
September 2012
February 2013
March 2013
April 2013
May 2013
June 2013
December 2013
March 2014
January 2015
Attacking the iOS 7 early_random() PRNG
Attacking the iOS 7 early_random() PRNG
posted by Tarjei Mandt @ 3/12/2014 09:04:00 PM  

Back in 2012, Mark and I detailed a number of iOS kernel mitigations that were introduced in iOS 6 to prevent an attacker from leveraging well-known exploitation techniques such as the zone free list pointer overwrite. Most of these mitigations rely on entropy (of varying degree) provided by the kernel, and are therefore supported by a separate random number generator known as the early_random() PRNG. As this generator is fundamental to the robustness of these mitigations, and has received additional improvements in iOS 7, it is unarguably a very interesting target that deserves further study.

The initial version of the early random PRNG, found in iOS 6, leveraged a fairly simple generator that derived values directly from the CPU tick count and a seed (provided by iBoot). Although the generator was able to create somewhat unpredictable values, it had a serious defect in that the outputs were well-correlated, especially in the case of successively generated values. Additionally, the seed was only combined with the higher 32 bits of the output, hence the lower bits (typically the only part used on 32-bit iOS devices) were unaffected by the seed value. Thus, in an attempt to improve the early random PRNG in iOS 7, Apple decided to leverage an entirely new generator. Specifically, iOS 7 uses a linear congruential generator, a PRNG well-known both for its strengths and (notable) weaknesses.

An LCG's quality is essentially determined by its choice of parameters. Although the early random PRNG is clearly inspired by glibc random_r() and ANSI C rand(), it is alarmingly weak in practice. Notably, early_random() in iOS 7 can only produce 2^19 unique outputs, with a maximum period of 2^17 (length of sequence of unique outputs, before it starts over). This is well below the size of the possible output space (64-bits), and may allow an attacker to predict values with very little effort. In particular, we found that an unprivileged attacker, even when confined by the most restrictive sandbox, can recover arbitrary outputs from the generator and consequently bypass all the exploit mitigations that rely on the early random PRNG. These findings have been detailed in the following slides and white paper, and includes suggestions on how to improve early_random() in future iOS versions.

iPhone5S:~ mobile$ uname -a
Darwin iPhone5S 14.0.0 Darwin Kernel Version 14.0.0: Fri Sep 27 23:08:32 PDT 2013; root:xnu-2423.3.12~1/RELEASE_ARM64_S5L8960X iPhone6,2 arm64 N53AP Darwin
iPhone5S:~ mobile$ ./prng -n 12 -v
[+] Attempting to recover permutation value
[+] Created pipe descriptor: 0x3
[+] Pipe inode: abd3422bc9e617e1
[+] Brute-forcing discarded bits
[+] Found match. Computing remaining states.
[+] PRNG output: abd342ab3da7acc1
[+] Backtracking to seed
[+] Dumping PRNG outputs
 ## | Raw Output       | Value            | Type
  0 |            32c98 |            32c98 | Initial seed (19 bits)
  1 |  f9e9a1a49ea4f48 |  f9e9a1a49ea0048 | Stack check guard
  2 | dee5a48c513eded6 |  535218c513eded7 | Zone poisoned cookie
  3 | 1b25a4953a4999bb |               10 | Zone factor
  4 | 9bdc5bb7688ddd79 | 3f0011b7688ddd78 | Zone nopoison cookie
  5 | 308c2370f7885f8e |              18e | Kernel map offset
  6 | 20b36d423abcad7c | 20b36d423abcad7c | Yarrow seed
  7 | abd342ab3da7acc1 | abd342ab3da7acc1 | VM permutation value
  8 | 896ac52d43cb1adf | 896ac52d43cb1adf | Buf permutation value
  9 | 68faae4648a60d54 | 68faae4648a60d54 | 
 10 | 7201cf787fba71a2 | 7201cf787fba71a2 | 
 11 | c4019241d4858d47 | c4019241d4858d47 |

Labels: , , ,


At March 16, 2014 at 8:22 PM , Anonymous Anonymous said...

I'm not convinced that a cryptographically secure RNG is needed for any of the features that you mention. So I doubt that you've exploited anything. ou need to take a course that explains when to use statistically random numbers vs cryptographically random numbers...

Post a Comment

Subscribe to Post Comments [Atom]

<< Home

© Copyright 2013 Azimuth Security Pty Ltd