Lucene search

K
zdtGoogle Security Research1337DAY-ID-26046
HistoryJun 10, 2016 - 12:00 a.m.

Android - /system/bin/sdcard Stack Buffer Overflow

2016-06-1000:00:00
Google Security Research
0day.today
30

0.002 Low

EPSS

Percentile

60.2%

Exploit for Android platform in category dos / poc

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
r10            0xbee4c9ac   3202664876
r11            0xb6943180   3063165312
r12            0xb6e3c908   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
#0  0xb6e06ade in pthread_getspecific (key=11) at bionic/libc/bionic/pthread_key.cpp:160
#1  0xb6e1daac in je_tsd_wrapper_get () at external/jemalloc/include/jemalloc/internal/tsd.h:609
#2  je_tsd_get () at external/jemalloc/include/jemalloc/internal/tsd.h:609
#3  je_tsd_fetch () at external/jemalloc/include/jemalloc/internal/tsd.h:614
#4  imalloc_body (usize=<synthetic pointer>, tsd=<synthetic pointer>, size=4) at external/jemalloc/src/jemalloc.c:1401
#5  je_malloc (size=4) at external/jemalloc/src/jemalloc.c:1423
#6  0xb6f3bb3e in handle_open (fuse=0xbee478c8, hdr=0xbee4c984, req=<optimized out>, handler=<optimized out>)
    at system/core/sdcard/sdcard.c:1193
#7  0x41414140 in ?? ()
 
 
Proof of Concept:
https://github.com/offensive-security/exploit-database-bin-sploits/raw/master/sploits/39921.zip

#  0day.today [2018-03-12]  #

0.002 Low

EPSS

Percentile

60.2%

Related for 1337DAY-ID-26046