Google Android – ‘/system/bin/sdcard’ Stack Buffer Overflow (PoC)

  • 作者: Google Security Research
    日期: 2016-06-10
  • 类别:
    平台:
  • 来源:https://www.exploit-db.com/exploits/39921/
  • 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 buffer in 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;
    } else if (node->actual_name) {
    name = node->actual_name;
    namelen = node->namelen;
    } else {
    name = node->name;
    namelen = node->namelen;
    }
    
    // when bufsize == namelen + 1
    if (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 0xb	11
    r1 0x1	1
    r2 0x41414199	1094795673
    r3 0x41414141	1094795585
    r4 0x80000000	2147483648
    r5 0x0	0
    r6 0xb6e40ec0	3068399296
    r7 0xb6cbe860	3066816608
    r8 0xb6e4930c	3068433164
    r9 0xb6e3c594	3068380564
    r100xbee4c9ac	3202664876
    r110xb6943180	3063165312
    r120xb6e3c908	3068381448
    sp 0xb6cbe7a0	0xb6cbe7a0
    lr 0xb6e1daad	-1226712403
    pc 0xb6e06ade	0xb6e06ade <pthread_getspecific(pthread_key_t)+34>
    cpsr 0x80070030	-2147024848
    (gdb) x/10i $pc
    => 0xb6e06ade <pthread_getspecific(pthread_key_t)+34>:	ldr	r4, [r2, #100]	; 0x64
     0xb6e06ae0 <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]	; 0x68
     0xb6e06ae6 <pthread_getspecific(pthread_key_t)+42>:	pop	{r4, pc}
     0xb6e06ae8 <pthread_getspecific(pthread_key_t)+44>:	movs	r0, #0
     0xb6e06aea <pthread_getspecific(pthread_key_t)+46>:	pop	{r4, pc}
     0xb6e06aec <pthread_getspecific(pthread_key_t)+48>:	adds	r0, #12
     0xb6e06aee <pthread_getspecific(pthread_key_t)+50>:	add.w	r12, r3, r0, lsl #3
     0xb6e06af2 <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