Source: https://bugs.chromium.org/p/project-zero/issues/detail?id=798
Android: Stack-buffer-overflow in/system/bin/sdcard
There's an integer overflow issue in get_node_path_locked, which results in
a buffer overflow. For all of the calling paths, this is going to overflow a
stack bufferin the parent function:
static ssize_t get_node_path_locked(struct node* node, char* buf, size_t bufsize){
const char* name;
size_t namelen;if(node->graft_path){
name = node->graft_path;
namelen = node->graft_pathlen;}elseif(node->actual_name){
name = node->actual_name;
namelen = node->namelen;}else{
name = node->name;
namelen = node->namelen;}// when bufsize == namelen +1if(bufsize < namelen +1){return-1;}
ssize_t pathlen =0;if(node->parent && node->graft_path == NULL){// bufsize - namelen -2 overflows to SIZE_MAX
pathlen = get_node_path_locked(node->parent, buf, bufsize - namelen -2);if(pathlen <0){return-1;}
buf[pathlen++]='/';}
memcpy(buf + pathlen, name, namelen +1);/* include trailing \0*/return pathlen + namelen;}
This can be triggered by a malicious app creating a directory structure in/sdcard with a total path length longer than PATH_MAX, which can be achieved by
creating a directory heirarchy starting with several directories with short
names and later renaming these parent directories to have longer names. See the
attached POC, which can be run from the 'untrusted_app' selinux domain.
It appears that the overflow is close enough to the bottom of the stack that
with a large overflow we can corrupt thread data that is used before the stack
cookie is checked, suggesting that this issue is possibly exploitable despite
the presence of stack cookies.(gdb) i r
r0 0xb11
r1 0x11
r2 0x414141991094795673
r3 0x414141411094795585
r4 0x800000002147483648
r5 0x00
r6 0xb6e40ec03068399296
r7 0xb6cbe8603066816608
r8 0xb6e4930c3068433164
r9 0xb6e3c5943068380564
r100xbee4c9ac 3202664876
r110xb6943180 3063165312
r120xb6e3c908 3068381448
sp 0xb6cbe7a00xb6cbe7a0
lr 0xb6e1daad-1226712403
pc 0xb6e06ade0xb6e06ade<pthread_getspecific(pthread_key_t)+34>
cpsr 0x80070030-2147024848(gdb) x/10i $pc
=>0xb6e06ade<pthread_getspecific(pthread_key_t)+34>: ldr r4,[r2,#100] ; 0x640xb6e06ae0<pthread_getspecific(pthread_key_t)+36>:cmp r4, r1
0xb6e06ae2<pthread_getspecific(pthread_key_t)+38>: bne.n 0xb6e06aec<pthread_getspecific(pthread_key_t)+48>0xb6e06ae4<pthread_getspecific(pthread_key_t)+40>: ldr r0,[r2,#104] ; 0x680xb6e06ae6<pthread_getspecific(pthread_key_t)+42>: pop {r4, pc}0xb6e06ae8<pthread_getspecific(pthread_key_t)+44>: movs r0,#00xb6e06aea<pthread_getspecific(pthread_key_t)+46>: pop {r4, pc}0xb6e06aec<pthread_getspecific(pthread_key_t)+48>: adds r0,#120xb6e06aee<pthread_getspecific(pthread_key_t)+50>: add.w r12, r3, r0, lsl #30xb6e06af2<pthread_getspecific(pthread_key_t)+54>: movs r0,#0(gdb) bt
#00xb6e06ade in pthread_getspecific (key=11) at bionic/libc/bionic/pthread_key.cpp:160#10xb6e1daac in je_tsd_wrapper_get () at external/jemalloc/include/jemalloc/internal/tsd.h:609#2je_tsd_get () at external/jemalloc/include/jemalloc/internal/tsd.h:609#3je_tsd_fetch () at external/jemalloc/include/jemalloc/internal/tsd.h:614#4imalloc_body (usize=<synthetic pointer>, tsd=<synthetic pointer>, size=4) at external/jemalloc/src/jemalloc.c:1401#5je_malloc (size=4) at external/jemalloc/src/jemalloc.c:1423#60xb6f3bb3e in handle_open (fuse=0xbee478c8, hdr=0xbee4c984, req=<optimized out>, handler=<optimized out>)
at system/core/sdcard/sdcard.c:1193#70x41414140 in ?? ()
Proof of Concept:
https://gitlab.com/exploit-database/exploitdb-bin-sploits/-/raw/main/bin-sploits/39921.zip