|
The iPhone Wiki is no longer updated. Visit this article on The Apple Wiki for current information. |
Difference between revisions of "Timezone Vulnerability"
(reference CVE-2013-0979) |
m (change to past tense) |
||
| (7 intermediate revisions by 2 users not shown) | |||
| Line 1: | Line 1: | ||
| + | There was a flaw in [[lockdownd]], fixed in iOS 6.1.3: |
||
| − | According the the Accuvant Labs analysis, sending [[lockdownd]] a malformed [[PairRequest]] command causes [[lockdownd]] to change the permissions like <code>chmod 777 file</code> making it accessible to mobile (and all users). It isn't clear whether this vulnerability is in [[lockdownd]] or in an underlying library or framework, so more analysis of this vulnerability is necessary. |
||
| + | MOVW R0, #(aPrivateVarDbTi-0x4DB8A) ; "/private/var/db/timezone" |
||
| + | MOVW R1, #0x1FF ; mode_t -> 0777 |
||
| + | MOVT.W R0, #4 |
||
| + | ADD R0, PC ; char * |
||
| + | BLX _chmod |
||
| + | This means <code>chmod("/private/var/db/timezone",0777)</code> without any further checks and is executed on every launch. By setting a symbolic link on <code>/var/db/timezone</code> though [[MobileBackup]] and pointing the symlink to any other file and crashing [[lockdownd]] by sending it a malformed property list (see [[Malformed PairRequest]]) to make it relaunch causes it to perform the actual permission change on any file. |
||
| − | This vulnerability (or together with [Symbolic Link Vulnerability]?) is CVE-2013-0979. |
||
| − | + | This vulnerability is '''CVE-2013-0979''' and Apple describes it in the iOS 6.1.3 security fixes like this: |
|
<cite> |
<cite> |
||
| Line 11: | Line 16: | ||
</cite> |
</cite> |
||
| + | Note: |
||
| + | At [[WWJC]] 2013 [[pimskeks]] mentioned that the description in Apple's security fix is wrong. It says "when restoring from backup", although this is totally unrelated to the backup, as the only thing that needs to be done is to restart [[lockdownd]]. In [[evasi0n]] this was done with a restore (to set a symbolic link to the file), but this vulnerability here is not related to the backup/restore. |
||
| + | |||
| + | __NOTOC__ |
||
== Usage == |
== Usage == |
||
* [[evasi0n|evasi0n jailbreak]] |
* [[evasi0n|evasi0n jailbreak]] |
||
== Credits == |
== Credits == |
||
| − | * |
+ | * [[evad3rs]] |
== See Also == |
== See Also == |
||
* [[Symbolic Link Vulnerability]] |
* [[Symbolic Link Vulnerability]] |
||
| + | * [[Malformed PairRequest]] |
||
== References == |
== References == |
||
| + | * [http://conference.hitb.org/hitbsecconf2013ams/materials/D2T1%20-%20Pod2g,%20Planetbeing,%20Musclenerd%20and%20Pimskeks%20aka%20Evad3rs%20-%20Swiping%20Through%20Modern%20Security%20Features.pdf Slides from HITB presentation in Amsterdam 2013] |
||
| − | * [http://blog.accuvantlabs.com/blog/bthomas/evasi0n-jailbreaks-userland-component Accuvant Labs analysis of evasi0n] |
||
| + | * [http://blog.accuvant.com/bthomasaccuvant/evasi0n-jailbreaks-userland-component/ Accuvant Labs analysis of evasi0n] |
||
* [http://support.apple.com/kb/HT5704 Apple's iOS 6.1.3 security fixes] |
* [http://support.apple.com/kb/HT5704 Apple's iOS 6.1.3 security fixes] |
||
* [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0979 NIST Reference CVE-2013-0979] |
* [http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2013-0979 NIST Reference CVE-2013-0979] |
||
Latest revision as of 17:34, 10 October 2017
There was a flaw in lockdownd, fixed in iOS 6.1.3:
MOVW R0, #(aPrivateVarDbTi-0x4DB8A) ; "/private/var/db/timezone" MOVW R1, #0x1FF ; mode_t -> 0777 MOVT.W R0, #4 ADD R0, PC ; char * BLX _chmod
This means chmod("/private/var/db/timezone",0777) without any further checks and is executed on every launch. By setting a symbolic link on /var/db/timezone though MobileBackup and pointing the symlink to any other file and crashing lockdownd by sending it a malformed property list (see Malformed PairRequest) to make it relaunch causes it to perform the actual permission change on any file.
This vulnerability is CVE-2013-0979 and Apple describes it in the iOS 6.1.3 security fixes like this:
Lockdown
Impact: A local user may be able to change permissions on arbitrary files
Description: When restoring from backup, lockdownd changed permissions on certain files even if the path to the file included a symbolic link. This issue was addressed by not changing permissions on any file with a symlink in its path.
Note: At WWJC 2013 pimskeks mentioned that the description in Apple's security fix is wrong. It says "when restoring from backup", although this is totally unrelated to the backup, as the only thing that needs to be done is to restart lockdownd. In evasi0n this was done with a restore (to set a symbolic link to the file), but this vulnerability here is not related to the backup/restore.
