radareorg / radare2

UNIX-like reverse engineering framework and command-line toolset
https://www.radare.org/
GNU Lesser General Public License v3.0
20.3k stars 2.97k forks source link

r2 hotpatcher victim? :) #3709

Closed zonkzonk closed 8 years ago

zonkzonk commented 8 years ago

Hi, playing around with some silly lib and hotpatcher I get r2 to dump core:

http://sprunge.us/WLih

r2 -v
radare2 0.10.0-git 9740 @ linux-little-x86-64 git.0.9.9-1625-g7f903ce
commit: 7f903ce58907cc876ecf1d96b3d06201f99760d8 build: 2015-11-19

ulimit -a
core file size          (blocks, -c) 100000
data seg size           (kbytes, -d) 100000
scheduling priority             (-e) 100000
file size               (blocks, -f) 100000
pending signals                 (-i) 14570
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) 100000
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) 100000
max user processes              (-u) 14570
virtual memory          (kbytes, -v) 1000000000
file locks                      (-x) 100000
uname -ra

Linux S 4.2.0-16-generic #19-Ubuntu SMP Thu Oct 8 15:35:06 UTC 2015 x86_64  GNU/Linux

can anyone reproduce? I can share that lib aswell.

Greetings --zlul

radare commented 8 years ago

how can i reproduce this if you didnt provide the commands or the file?

also, drop all the ulimit restrictions, sometimes a small stack size or cpu time are the reasons why r2 fails. your crash backtrace makes not much sense as long as rcoresetup is not called from cons.set_raw, and the eip points to 0 so this seems like a null ptr call. but there's no such thing in r_cons_set_raw... so i can't guess whats going on in there with that info

#1  0x00005555f22550d0 in r_core_setup_debugger@plt ()
#2  0x00007fb14d7f9f20 in _dl_runtime_resolve () at ../sysdeps/x86_64/dl-trampoline.S:87
#3  0x00007fb14ce57eb7 in r_cons_set_raw (is_raw=32689) at cons.c:784
zonkzonk commented 8 years ago

morrn,

There is no radare commands at this time. To reproduce:

r2 -& [pid] hotpatcher -l /some/lib/in/usr/lib [pid] fg Segfault

Get hotpatcher here: https://github.com/vikasnkumar/hotpatch

Greetings --zlul

btw. all segfaults have error 14 and instruction pointer = (null) and stack pointer som value like 00007ffeb9144720

radare commented 8 years ago

You mean that u are patching an r2 library at runtime, while r2 is running? This is normal reason to make any program crash

On 19 Nov 2015, at 19:21, zonkzonk notifications@github.com wrote:

morrn,

There is no radare commands at this time. To reproduce:

r2 -& [pid] hotpatcher -l /some/lib/in/usr/lib [pid] fg Segfault

Get hotpatcher here: https://github.com/vikasnkumar/hotpatch

Greetings --zlul

— Reply to this email directly or view it on GitHub.

zonkzonk commented 8 years ago

No. It's an arbitrary library against r2. Can't we protect against this?

radare commented 8 years ago

Wat? Are you loading that lib in r2 i dont see this in the commands u listed

On 19 Nov 2015, at 21:52, zonkzonk notifications@github.com wrote:

No. It's an arbitrary library against r2. Can't we protect against this?

— Reply to this email directly or view it on GitHub.

zonkzonk commented 8 years ago

this is what hotpatcher does, afaik, so not sure what to do? colse?

radare commented 8 years ago

this is a bug in hotpatcher, not in r2. you are modifying a stopped process in memory, and r2 crashes after returning because the addresses in memory was fuckedup. if you do the same without stopping r2 the hotpatching works as expected, so this is not an issue for r2.

the same happens with any other program like vim, less, etc..