[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Mon, 6 Jul 2015 12:58:07 +0000
From: "jean-marie.bourbon@...aturetech.com"
<jean-marie.bourbon@...aturetech.com>
To: "oss-security@...ts.openwall.com" <oss-security@...ts.openwall.com>
Subject: TR : CVE request for dash 0.5.7-3 x86-64 local buffer overflow
Date d'envoi : mardi 30 juin 2015 15:40
À : cve-assign@...re.org
Objet : CVE request for dash 0.5.7-3 x86-64 local buffer overflow
Context:
- GLIBC: 2.13
- DASH: 0.5.7-3
- Kernel: 3.18.0 amd64
Tested on Debian based distribution.
Bug explanation:
Hi,
I request a CVE id number for the following vulnerability : dash x86-64 local buffer overflow.
I discover it using bash who sent me a SIGKILL (no real crash) and closed my shell in certain circumstances:
kmkz@...z:/tmp$ `perl -e '$i=0;while($i<= 500){print"DEAD"x10;}'`
bash: xrealloc : ../bash/subst.c:5184 : impossible d'allouer 2097152 octets (4460544 octets alloués)
So I wanted to try using my /bin/dash and... I had a local crash !
In fact, it comsume all the memory before to freeze the computer.
Thereafter I also tested it with VALGRIND and GDB to investigate as shown here and with a non privilegied user:
# su kmkz // my user
$ /bin/bash // to have completion ... :-/
kmkz@...z:/home$ id
uid=1001(kmkz) gid=1002(kmkz) groupes=1002(kmkz)
kmkz@...z:/home$ valgrind --tool=memcheck --leak-check=yes /bin/dash // launch vlagrind in debbug mode on /bin/dash
==6033== Memcheck, a memory error detector
==6033== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==6033== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==6033== Command: /bin/dash
==6033==
$ `perl -e '$i=0;while($i<= 500){print"DEAD"x10;}'`
--9241-- REDIR: 0x4eb0300 (strcmp) redirected to 0x4a22750 (_vgnU_ifunc_wrapper)
--9241-- REDIR: 0x4f45130 (__strcmp_sse42) redirected to 0x4c2b8d0 (strcmp)
--9241-- REDIR: 0x4eadae0 (realloc) redirected to 0x4c2a430 (realloc)
--9263-- REDIR: 0x4eb3900 (strpbrk) redirected to 0x4a22750 (_vgnU_ifunc_wrapper)
--9263-- REDIR: 0x4f4cab0 (__strpbrk_sse42) redirected to 0x4c2d7d0 (strpbrk)
--9263-- REDIR: 0x4eb3fe0 (bcmp) redirected to 0x4a22750 (_vgnU_ifunc_wrapper)
--9263-- REDIR: 0x4f672f0 (__memcmp_sse4_1) redirected to 0x4c2c9c0 (bcmp)
==8875== Warning: set address range perms: large range [0x7862b048, 0x97e2b048) (undefined)
==8875== Warning: set address range perms: large range [0x3962a028, 0x58e2a060) (noaccess)
==8875== Warning: set address range perms: large range [0xd6e2c048, 0x115e2c048) (undefined)
==8875== Warning: set address range perms: large range [0x58e2b028, 0x97e2b060) (noaccess)
==8875== Warning: set address range perms: large range [0x193e2d048, 0x211e2d048) (undefined)
==8875== Warning: set address range perms: large range [0x97e2c028, 0x115e2c060) (noaccess)
==8875== Warning: set address range perms: large range [0x540e7c048, 0x63ce7c048) (undefined)
==8875== Warning: set address range perms: large range [0x115e2d028, 0x211e2d060) (noaccess)
/* The real problem */
==9241== Stack overflow in thread 1: can't grow stack to 0x7fe801ef8
==9241==
==9241== Process terminating with default action of signal 11 (SIGSEGV): dumping core
==9241== Access not within mapped region at address 0x7FE801EF8
==9241== at 0x4E7540A: vfprintf (printf-parse.h:99)
==9241== If you believe this happened as a result of a stack
==9241== overflow in your program's main thread (unlikely but
==9241== possible), you can try to increase the size of the
==9241== main thread stack using the --main-stacksize= flag.
==9241== The main thread stack size used in this run was 8388608.
==9241== Stack overflow in thread 1: can't grow stack to 0x7fe801ef0
==9241==
==9241== Process terminating with default action of signal 11 (SIGSEGV)
==9241== Access not within mapped region at address 0x7FE801EF0
==9241== at 0x4A226E0: _vgnU_freeres (vg_preloaded.c:58)
==9241== If you believe this happened as a result of a stack
==9241== overflow in your program's main thread (unlikely but
==9241== possible), you can try to increase the size of the
==9241== main thread stack using the --main-stacksize= flag.
==9241== The main thread stack size used in this run was 8388608.
==9241==
==9241== HEAP SUMMARY:
==9241== in use at exit: 8,455,718,298 bytes in 43 blocks
==9241== total heap usage: 72 allocs, 29 frees, 33,822,869,786 bytes allocated
==9241==
==9241== Searching for pointers to 43 not-freed blocks
==9241== Checked 8,459,779,640 bytes
==9241==
==9241== LEAK SUMMARY:
==9241== definitely lost: 0 bytes in 0 blocks
==9241== indirectly lost: 0 bytes in 0 blocks
==9241== possibly lost: 0 bytes in 0 blocks
==9241== still reachable: 8,455,718,298 bytes in 43 blocks
==9241== suppressed: 0 bytes in 0 blocks
==9241== Reachable blocks (those to which a pointer was found) are not shown.
==9241== To see them, rerun with: --leak-check=full --show-reachable=yes
==9241==
==9241== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
--9241--
--9241-- used_suppression: 4 dl-hack3-cond-1
==9241==
==9241== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 4 from 4)
/* SEGFAULT */
Erreur de segmentation
kmkz@...z:/home$ ls
30M -rw------- 1 kmkz kmkz 36M juin 30 14:06 vgcore.9241 // my cheer core dump
Once this core dump generated, I made a quick research with GDB-PEDA ( as a root user now):
root@...z:/tmp# gdb -q -c vgcore.9241
[New LWP 9241]
Core was generated by `'.
Program terminated with signal 11, Segmentation fault.
#0 0x0000000004e7540a in ?? ()
gdb-peda$ i s
#0 0x0000000004e7540a in ?? ()
Cannot access memory at address 0x7fe801ef8
root@...z:/tmp# gdb -q /bin/dash vgcore.9241
[New LWP 9241]
Core was generated by `'.
Program terminated with signal 11, Segmentation fault.
#0 __find_specmb (format=<optimized out>) at printf-parse.h:99
99 printf-parse.h: Aucun fichier ou dossier de ce type.
gdb-peda$ checksec
CANARY : disabled
FORTIFY : disabled
NX : ENABLED
PIE : disabled
RELRO : disabled
gdb-peda$ x/i $rip
=> 0x4e7540a <_IO_vfprintf_internal+154>: call 0x4ebb5b0 <strchrnul>
gdb-peda$ start
warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7ffff7ffa000
[----------------------------------registers-----------------------------------]
RAX: 0x1c
RBX: 0x0
RCX: 0x4127e0 (mov QWORD PTR [rsp-0x28],rbp)
RDX: 0x7fffffffe478 --> 0x7fffffffe6ef ("/bin/dash")
RSI: 0x1
RDI: 0x4022c0 (push rbx)
RBP: 0x0
RSP: 0x7fffffffe458 --> 0x4024a5 (hlt )
RIP: 0x401f80 (<__libc_start_main@plt>: jmp QWORD PTR [rip+0x217692] # 0x619618 <__libc_start_main@....plt>)
R8 : 0x4127d0 (repz ret )
R9 : 0x7ffff7deb310 (push rbp)
R10: 0xd ('\r')
R11: 0x4
R12: 0x40247c (xor ebp,ebp)
R13: 0x7fffffffe470 --> 0x1
R14: 0x0
R15: 0x0
EFLAGS: 0x202 (carry parity adjust zero sign trap INTERRUPT direction overflow)
[-------------------------------------code-------------------------------------]
0x401f70 <read@plt>: jmp QWORD PTR [rip+0x21769a] # 0x619610 <read@....plt>
0x401f76 <read@...+6>: push 0x2c
0x401f7b <read@...+11>: jmp 0x401ca0
=> 0x401f80 <__libc_start_main@plt>: jmp QWORD PTR [rip+0x217692] # 0x619618 <__libc_start_main@....plt>
| 0x401f86 <__libc_start_main@...+6>: push 0x2d
| 0x401f8b <__libc_start_main@...+11>: jmp 0x401ca0
| 0x401f90 <memcmp@plt>: jmp QWORD PTR [rip+0x21768a] # 0x619620 <memcmp@....plt>
| 0x401f96 <memcmp@...+6>: push 0x2e
|-> 0x401f86 <__libc_start_main@...+6>: push 0x2d
0x401f8b <__libc_start_main@...+11>: jmp 0x401ca0
0x401f90 <memcmp@plt>: jmp QWORD PTR [rip+0x21768a] # 0x619620 <memcmp@....plt>
0x401f96 <memcmp@...+6>: push 0x2e
JUMP is taken
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffe458 --> 0x4024a5 (hlt )
0008| 0x7fffffffe460 --> 0x7fffffffe468 --> 0x1c
0016| 0x7fffffffe468 --> 0x1c
0024| 0x7fffffffe470 --> 0x1
0032| 0x7fffffffe478 --> 0x7fffffffe6ef ("/bin/dash")
0040| 0x7fffffffe480 --> 0x0
0048| 0x7fffffffe488 --> 0x7fffffffe6f9 ("ORBIT_SOCKETDIR=/tmp/orbit-root")
0056| 0x7fffffffe490 --> 0x7fffffffe719 ("SSH_AGENT_PID=3474")
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Temporary breakpoint 1, 0x0000000000401f80 in __libc_start_main@plt ()
gdb-peda$ vmmap
Start End Perm Name
0x00400000 0x0041a000 r-xp /bin/dash
0x00619000 0x0061a000 rw-p /bin/dash
0x0061a000 0x0061d000 rw-p [heap]
0x00007ffff7a52000 0x00007ffff7bd3000 r-xp /lib/x86_64-linux-gnu/libc-2.13.so
0x00007ffff7bd3000 0x00007ffff7dd3000 ---p /lib/x86_64-linux-gnu/libc-2.13.so
0x00007ffff7dd3000 0x00007ffff7dd7000 r--p /lib/x86_64-linux-gnu/libc-2.13.so
0x00007ffff7dd7000 0x00007ffff7dd8000 rw-p /lib/x86_64-linux-gnu/libc-2.13.so
0x00007ffff7dd8000 0x00007ffff7ddd000 rw-p mapped
0x00007ffff7ddd000 0x00007ffff7dfd000 r-xp /lib/x86_64-linux-gnu/ld-2.13.so
0x00007ffff7fd4000 0x00007ffff7fd7000 rw-p mapped
0x00007ffff7ff6000 0x00007ffff7ff8000 rw-p mapped
0x00007ffff7ff8000 0x00007ffff7ffa000 r--p [vvar]
0x00007ffff7ffa000 0x00007ffff7ffc000 r-xp [vdso]
0x00007ffff7ffc000 0x00007ffff7ffd000 r--p /lib/x86_64-linux-gnu/ld-2.13.so
0x00007ffff7ffd000 0x00007ffff7ffe000 rw-p /lib/x86_64-linux-gnu/ld-2.13.so
0x00007ffff7ffe000 0x00007ffff7fff000 rw-p mapped
0x00007ffffffde000 0x00007ffffffff000 rw-p [stack]
0xffffffffff600000 0xffffffffff601000 r-xp [vsyscall]
gdb-peda$ bt
#0 0x0000000000401f80 in __libc_start_main@plt ()
#1 0x00000000004024a5 in ?? ()
#2 0x00007fffffffe468 in ?? ()
#3 0x000000000000001c in ?? ()
#4 0x0000000000000001 in ?? ()
#5 0x00007fffffffe6ef in ?? ()
#6 0x0000000000000000 in ?? ()
It appear that the binary has only the NoeXecutable protection (and ASLR) with an interesting buffer overflow... that's why I'd like to
know how to make my small contribution on this subject.
Finaly, you can reproduce this bug easily whit a (so basic) Perl line in your dash shell :
`perl -e '$i=0;while($i<= 500){print"DEAD"x10;}'`
Hoping to read you soon,
Best regards,
Mr BOURBON Jean-marie (kmkz)
BOURBON Jean-marie
ARMATURE Technologies
Fixe : +33 1 44 51 92 61
Fax : +33 9 85 69 68 85
www.armaturetech.com
55 rue de la Boétie, 75008 Paris
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
