Skip to content
New issue

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

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

Already on GitHub? Sign in 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 `./login'.
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants