Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

cg (character device) issues #1938

Closed
zonkzonk opened this issue Jan 6, 2015 · 8 comments
Closed

cg (character device) issues #1938

zonkzonk opened this issue Jan 6, 2015 · 8 comments

Comments

@zonkzonk
Copy link
Contributor

zonkzonk commented Jan 6, 2015

morrn,

cg [path] where path is /dev/urandom, with 32 bit:

[0xb772d840]> cg /dev/urandom
Segmentation fault (core dumped)
zlul@debian:/tmp$ gdb -c core
...
Core was generated by `./#'.
Program terminated with signal 11, Segmentation fault.
#0  0xb7737a72 in ?? ()
(gdb) bt
#0  0xb7737a72 in ?? ()
#1  0x00000001 in ?? ()
#2  0xb774a908 in ?? ()
#3  0xb772ffd0 in ?? ()
#4  0xb774a908 in ?? ()
#5  0xb7741821 in ?? ()
#6  0x08048034 in ?? ()
#7  0xb772dc5d in ?? ()
#8  0xb772d847 in ?? ()
(gdb) up
#1  0x00000001 in ?? ()
(gdb) i r
eax            0x0      0
ecx            0xb774a908       -1217091320
edx            0xb774a908       -1217091320
ebx            0xb7749ff4       -1217093644
esp            0xbfba13e4       0xbfba13e4
ebp            0xbfba1484       0xbfba1484
esi            0x0      0
edi            0xb774a908       -1217091320
eip            0x1      0x1
eflags         0x210202 [ IF RF ID ]
cs             0x73     115
ss             0x7b     123
ds             0x7b     123
es             0x7b     123
fs             0x0      0
gs             0x33     51
(gdb) 

however since last commit, I could not reproduce(*) with
while :; do sleep 0.1 && r2 -qc 'cg /dev/urandom' /bin/ls; done.

wat do ? :)

Greetings
--zlul

ofc, I can provide core file in private

@zonkzonk
Copy link
Contributor Author

found a different crash this time (64bit). we should not allow character devices for cg as workaround.
wat do others ( @pancake @crowell @jvoisin @Maijin @XVilka ) think about that ?

,r2 -d ./a.out.bak
[..]
[0x7fb61684adc0]> cg /dev/urandom
Oops. unsupported opcode
^[[ASegmentation fault (core dumped)
Core was generated by `r2 -d ./a.out.bak'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f6edc317250 in assemble (a=0xa57560, op=0xffffffff, str=0xa57560 "@u\245") at p/asm_rar.c:21
21              return op->size = rarvm_assemble (&b, str);
(gdb) bt
#0  0x00007f6edc317250 in assemble (a=0xa57560, op=0xffffffff, str=0xa57560 "@u\245") at p/asm_rar.c:21
#1  0x00007f6eddfae100 in r_bin_object_new (binfile=0xa57560, plugin=0x947d30, baseaddr=4194304, loadaddr=0, offset=0, sz=0) at bin.c:853
#2  0x00007f6eddfae759 in r_bin_file_new_from_bytes (bin=0x96b320, file=0xa573b0 "/dev/urandom", bytes=0x0, sz=0, file_sz=0, rawstr=0, baseaddr=4194304, loadaddr=0, fd=18, pluginname=0x0, xtrname=0x0, offset=0) at bin.c:978
#3  0x00007f6eddfad539 in r_bin_load_io_at_offset_as_sz (bin=0x96b320, desc=0xa57410, baseaddr=4194304, loadaddr=0, xtr_idx=0, offset=0, name=0x0, sz=0) at bin.c:584
#4  0x00007f6eddfad5b7 in r_bin_load_io_at_offset_as (bin=0x96b320, desc=0xa57410, baseaddr=4194304, loadaddr=0, xtr_idx=0, offset=0, name=0x0) at bin.c:599
#5  0x00007f6eddfad079 in r_bin_load_io (bin=0x96b320, desc=0xa57410, baseaddr=4194304, loadaddr=0, xtr_idx=0) at bin.c:498
#6  0x00007f6edeb109fd in r_core_file_do_load_for_io_plugin (r=0x9ab8d0, baseaddr=4194304, loadaddr=0) at file.c:340
#7  0x00007f6edeb10de7 in r_core_bin_load (r=0x9ab8d0, filenameuri=0x94deb3 "/dev/urandom", baddr=4194304) at file.c:472
#8  0x00007f6edeae94c9 in cmd_cmp (data=0x607980 <r>, input=0x94deb1 "g /dev/urandom") at cmd_cmp.c:469
#9  0x00007f6edeb2eadb in r_cmd_call (cmd=0x84c0f0, input=0x94deb0 "cg /dev/urandom") at cmd_api.c:179
#10 0x00007f6edeb0ddc5 in r_core_cmd_subst_i (core=0x607980 <r>, cmd=0x94deb0 "cg /dev/urandom", colon=0x0) at cmd.c:1421
#11 0x00007f6edeb0c516 in r_core_cmd_subst (core=0x607980 <r>, cmd=0x94deb0 "cg /dev/urandom") at cmd.c:974
#12 0x00007f6edeb0e95e in r_core_cmd (core=0x607980 <r>, cstr=0x864d90 "cg /dev/urandom", log=1) at cmd.c:1627
#13 0x00007f6edead74cf in r_core_prompt_exec (r=0x607980 <r>) at core.c:983
#14 0x0000000000404ee0 in main (argc=3, argv=0x7fffdaab2558, envp=0x7fffdaab2578) at radare2.c:741
(gdb) x/i $pc
=> 0x7f6edc317250 <assemble+64>:        mov    %edx,(%rax)
(gdb) i r
rax            0xffffffff       4294967295
rbx            0x96b320 9876256
rcx            0x7f6edac19470   140114093249648
rdx            0x0      0
rsi            0x7f6edc48fc00   140114118900736
rdi            0x0      0
rbp            0x7fffdaab1110   0x7fffdaab1110
rsp            0x7fffdaab10e0   0x7fffdaab10e0
r8             0x19     25
r9             0x7f6edaedc700   140114096146176
r10            0x1      1
r11            0x246    582
r12            0x4028f0 4204784
r13            0x7fffdaab2550   140736862037328
r14            0x0      0
r15            0x0      0
rip            0x7f6edc317250   0x7f6edc317250 <assemble+64>
eflags         0x10246  [ PF ZF IF RF ]
cs             0x33     51
ss             0x2b     43
ds             0x0      0
es             0x0      0
fs             0x0      0
gs             0x0      0

Greetings
--zlul

@radare
Copy link
Collaborator

radare commented Jan 10, 2015

this crash exposes a random bug which cant be reproduced all the time. i
got a crash, but i was not able to reproduce
again, and it was crashing somewhere else.

This crash happens in a really wtf situation because op is -1, and all
those addresses look like 32bit, not 64bit as you mention.

we can try to fuzz the assemblers, but assembling @U\245 doesnt crashes
rarvm_assemble. the crash is somewhere else, without having the
disassembly and the reg values its hard to tell whats' going on here,
but looks like a memory corruption.

but if i run this with valgrind i always get the same output :/ so its
probably related to uniniitalized memory too. :?

On 01/10/2015 07:51 PM, zonkzonk wrote:

found a different crash this time (64bit). we should not allow
character devices for cg as workaround.
wat do others ( @pancake https://github.com/pancake @crowell
https://github.com/crowell @jvoisin https://github.com/jvoisin
@Maijin https://github.com/Maijin ) think about that ?

|,r2 -d ./a.out.bak
[..]
[0x7fb61684adc0]> cg /dev/urandom
Oops. unsupported opcode
^[[ASegmentation fault (core dumped)
Core was generated by `r2 -d ./a.out.bak'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x00007f6edc317250 in assemble (a=0xa57560, op=0xffffffff, str=0xa57560 "@U\245") at p/asm_rar.c:21
21 return op->size = rarvm_assemble (&b, str);
(gdb) bt
#0 0x00007f6edc317250 in assemble (a=0xa57560, op=0xffffffff, str=0xa57560 "@U\245") at p/asm_rar.c:21
#1 0x00007f6eddfae100 in r_bin_object_new (binfile=0xa57560, plugin=0x947d30, baseaddr=4194304, loadaddr=0, offset=0, sz=0) at bin.c:853
#2 0x00007f6eddfae759 in r_bin_file_new_from_bytes (bin=0x96b320, file=0xa573b0 "/dev/urandom", bytes=0x0, sz=0, file_sz=0, rawstr=0, baseaddr=4194304, loadaddr=0, fd=18, pluginname=0x0, xtrname=0x0, offset=0) at bin.c:978
#3 0x00007f6eddfad539 in r_bin_load_io_at_offset_as_sz (bin=0x96b320, desc=0xa57410, baseaddr=4194304, loadaddr=0, xtr_idx=0, offset=0, name=0x0, sz=0) at bin.c:584
#4 0x00007f6eddfad5b7 in r_bin_load_io_at_offset_as (bin=0x96b320, desc=0xa57410, baseaddr=4194304, loadaddr=0, xtr_idx=0, offset=0, name=0x0) at bin.c:599
#5 0x00007f6eddfad079 in r_bin_load_io (bin=0x96b320, desc=0xa57410, baseaddr=4194304, loadaddr=0, xtr_idx=0) at bin.c:498
#6 0x00007f6edeb109fd in r_core_file_do_load_for_io_plugin (r=0x9ab8d0, baseaddr=4194304, loadaddr=0) at file.c:340
#7 0x00007f6edeb10de7 in r_core_bin_load (r=0x9ab8d0, filenameuri=0x94deb3 "/dev/urandom", baddr=4194304) at file.c:472
#8 0x00007f6edeae94c9 in cmd_cmp (data=0x607980 , input=0x94deb1 "g /dev/urandom") at cmd_cmp.c:469
#9 0x00007f6edeb2eadb in r_cmd_call (cmd=0x84c0f0, input=0x94deb0 "cg /dev/urandom") at cmd_api.c:179
#10 0x00007f6edeb0ddc5 in r_core_cmd_subst_i (core=0x607980 , cmd=0x94deb0 "cg /dev/urandom", colon=0x0) at cmd.c:1421
#11 0x00007f6edeb0c516 in r_core_cmd_subst (core=0x607980 , cmd=0x94deb0 "cg /dev/urandom") at cmd.c:974
#12 0x00007f6edeb0e95e in r_core_cmd (core=0x607980 , cstr=0x864d90 "cg /dev/urandom", log=1) at cmd.c:1627
#13 0x00007f6edead74cf in r_core_prompt_exec (r=0x607980 ) at core.c:983
#14 0x0000000000404ee0 in main (argc=3, argv=0x7fffdaab2558, envp=0x7fffdaab2578) at radare2.c:741
(gdb) x/i $pc
=> 0x7f6edc317250 <assemble+64>: mov %edx,(%rax)
(gdb) i r
rax 0xffffffff 4294967295
rbx 0x96b320 9876256
rcx 0x7f6edac19470 140114093249648
rdx 0x0 0
rsi 0x7f6edc48fc00 140114118900736
rdi 0x0 0
rbp 0x7fffdaab1110 0x7fffdaab1110
rsp 0x7fffdaab10e0 0x7fffdaab10e0
r8 0x19 25
r9 0x7f6edaedc700 140114096146176
r10 0x1 1
r11 0x246 582
r12 0x4028f0 4204784
r13 0x7fffdaab2550 140736862037328
r14 0x0 0
r15 0x0 0
rip 0x7f6edc317250 0x7f6edc317250 <assemble+64>
eflags 0x10246 [ PF ZF IF RF ]
cs 0x33 51
ss 0x2b 43
ds 0x0 0
es 0x0 0
fs 0x0 0
gs 0x0 0
|

Greetings
--zlul


Reply to this email directly or view it on GitHub
#1938 (comment).

@zonkzonk
Copy link
Contributor Author

I thought, checking wat to return could be a good idea. I will save bufs from
urandom and look for more reproducible crashes.

19 static int assemble(RAsm *a, RAsmOp *op, const char *str) {
20 Bitbuf b = {.out = op->buf, .bits = 0};
21 return op->size = rarvm_assemble (&b, str);
22 }

@crowell
Copy link
Collaborator

crowell commented Jan 10, 2015

I'm on linux_64, and am seeing this bug manifested in a few ways.
repeated
cg /dev/zero
is causing a crash. but this is not always repeatable and happens at different places...

@crowell
Copy link
Collaborator

crowell commented Jan 10, 2015

I've gotten this particular crash a few times, working on a fix now

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x00007f7a96d31d13 in r_io_mmap_read (io=0x29b1320, fd=0xffffffff, buf=0x29b1320 "", count=0x29af740)
    at p/io_mmap.c:98
98              if (!fd || !fd->data || !buf)
gdb-peda$ bt
#0  0x00007f7a96d31d13 in r_io_mmap_read (io=0x29b1320, fd=0xffffffff, buf=0x29b1320 "", count=0x29af740)
    at p/io_mmap.c:98
#1  0x00007f7a96d32239 in __read (io=0x29b1320, fd=0xffffffff, buf=0x29b1320 "", len=0x29af740)
    at p/io_mmap.c:203
#2  0x00007f7a97e93c1b in r_bin_object_new (binfile=0x29b1320, plugin=0x25a3040, baseaddr=0x400000, 
    loadaddr=0x0, offset=0x0, sz=0x0) at bin.c:851
#3  0x00007f7a97e94308 in r_bin_file_new_from_bytes (bin=0x2929e00, file=0x29b1280 "/dev/zero", bytes=0x0, 
    sz=0x0, file_sz=0x0, rawstr=0x0, baseaddr=0x400000, loadaddr=0x0, fd=0x18, pluginname=0x0, xtrname=0x0, 
    offset=0x0) at bin.c:976
#4  0x00007f7a97e93057 in r_bin_load_io_at_offset_as_sz (bin=0x2929e00, desc=0x29a5b10, baseaddr=0x400000, 
    loadaddr=0x0, xtr_idx=0x0, offset=0x0, name=0x0, sz=0x0) at bin.c:582
#5  0x00007f7a97e930d7 in r_bin_load_io_at_offset_as (bin=0x2929e00, desc=0x29a5b10, baseaddr=0x400000, 
    loadaddr=0x0, xtr_idx=0x0, offset=0x0, name=0x0) at bin.c:597
#6  0x00007f7a97e92b7d in r_bin_load_io (bin=0x2929e00, desc=0x29a5b10, baseaddr=0x400000, loadaddr=0x0, 
    xtr_idx=0x0) at bin.c:496
#7  0x00007f7a98a00cc3 in r_core_file_do_load_for_io_plugin (r=0x283b870, baseaddr=0x400000, loadaddr=0x0)
    at file.c:340
#8  0x00007f7a98a010ad in r_core_bin_load (r=0x283b870, filenameuri=0x2581e63 "/dev/zero", baddr=0x400000)
    at file.c:472
#9  0x00007f7a989d60e6 in cmd_cmp (data=0x607580 <r>, input=0x2581e61 "g /dev/zero") at cmd_cmp.c:451
#10 0x00007f7a98a205ab in r_cmd_call (cmd=0x22813a0, input=0x2581e60 "cg /dev/zero") at cmd_api.c:179
#11 0x00007f7a989fde5d in r_core_cmd_subst_i (core=0x607580 <r>, cmd=0x2581e60 "cg /dev/zero", colon=0x0)
    at cmd.c:1421
#12 0x00007f7a989fc2ab in r_core_cmd_subst (core=0x607580 <r>, cmd=0x2581e60 "cg /dev/zero") at cmd.c:974
#13 0x00007f7a989feb2a in r_core_cmd (core=0x607580 <r>, cstr=0x2247b90 "cg /dev/zero", log=0x1) at cmd.c:1627
#14 0x00007f7a989c2bf3 in r_core_prompt_exec (r=0x607580 <r>) at core.c:948
#15 0x00000000004052a7 in main (argc=0x2, argv=0x7fff0a318e58, envp=0x7fff0a318e70) at radare2.c:741
#16 0x00007f7a94e1eec5 in __libc_start_main (main=0x40311a <main>, argc=0x2, argv=0x7fff0a318e58, 
    init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7fff0a318e48)
    at libc-start.c:287
#17 0x0000000000402a79 in _start ()
gdb-peda$ 

@crowell
Copy link
Collaborator

crowell commented Jan 10, 2015

bunch of things changed since I last synced... still going to fix the issue with /dev/zero I saw

@zonkzonk zonkzonk changed the title cg issue cg (character device) issues Jan 10, 2015
@Maijin Maijin added the bug label Jan 11, 2015
@zonkzonk
Copy link
Contributor Author

wrong patch

@radare
Copy link
Collaborator

radare commented Jan 16, 2015

Theres nothing wrong in opening a device. Its also a file

On 16 Jan 2015, at 22:49, zonkzonk notifications@github.com wrote:

ok, just for folks that want to exclude character devices:

diff --git a/libr/core/cmd_cmp.c b/libr/core/cmd_cmp.c
index 3d675fa..c9e5454 100644
--- a/libr/core/cmd_cmp.c
+++ b/libr/core/cmd_cmp.c
@@ -420,6 +420,8 @@ static int cmd_cmp(void *data, const char *input) {
int diffops = 0;
RCore *core2;
char *file2 = NULL;
+

                  switch (input[1]) {
                  case 'o':
                          file2 = (char_)r_str_chop_ro (input+2);

@@ -433,6 +435,10 @@ static int cmd_cmp(void *data, const char *input) {
return R_FALSE;
case ' ':
file2 = (char_)r_str_chop_ro (input+2);

  •                            if (strstr(file2,"/dev")) {
    
  •                            eprintf ("Won't read from character device\n");
    
  •                           return R_FALSE;
    
  •                            }
                            r_anal_diff_setup (core->anal, R_FALSE, -1, -1);
                            break;
                    default: {
    


Reply to this email directly or view it on GitHub.

@radare radare closed this as completed in 1ccd0e3 Jan 17, 2015
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants