Gallopsled/pwntools

crash when parsing ELF

Kyle-Kyle opened this issue · 9 comments

Reproduce:

[ins] In [1]: from pwn import *
[ins] In [2]: ELF('ALLSTAR_aplus-fsf-el_libMSTypes.so.0.0.0')
Aborted (core dumped)

where the binary is from https://allstar.jhuapl.edu/repo/p1/amd64/aplus-fsf/libMSTypes.so.0.0.0

The coredump suggests this is a libunicorn bug

gef➤  bt
#0  __pthread_kill_implementation (no_tid=0x0, signo=0x6, threadid=<optimized out>) at ./nptl/pthread_kill.c:44
#1  __pthread_kill_internal (signo=0x6, threadid=<optimized out>) at ./nptl/pthread_kill.c:78
#2  __GI___pthread_kill (threadid=<optimized out>, signo=signo@entry=0x6) at ./nptl/pthread_kill.c:89
#3  0x000073349fe4527e in __GI_raise (sig=sig@entry=0x6) at ../sysdeps/posix/raise.c:26
#4  0x000073349fe288ff in __GI_abort () at ./stdlib/abort.c:79
#5  0x0000733494dba299 in temp_load[cold] () from /home/kylebot/.virtualenvs/angr/lib/python3.12/site-packages/unicorn/lib/libunicorn.so.2
#6  0x0000733494df95b9 in tcg_gen_code_x86_64 () from /home/kylebot/.virtualenvs/angr/lib/python3.12/site-packages/unicorn/lib/libunicorn.so.2
#7  0x0000733494e210b7 in tb_gen_code_x86_64 () from /home/kylebot/.virtualenvs/angr/lib/python3.12/site-packages/unicorn/lib/libunicorn.so.2
#8  0x0000733494e054af in cpu_exec_x86_64 () from /home/kylebot/.virtualenvs/angr/lib/python3.12/site-packages/unicorn/lib/libunicorn.so.2
#9  0x0000733494dcb034 in resume_all_vcpus_x86_64 () from /home/kylebot/.virtualenvs/angr/lib/python3.12/site-packages/unicorn/lib/libunicorn.so.2
#10 0x0000733494dbe906 in uc_emu_start () from /home/kylebot/.virtualenvs/angr/lib/python3.12/site-packages/unicorn/lib/libunicorn.so.2
#11 0x000073349f0bfb16 in ?? () from /lib/x86_64-linux-gnu/libffi.so.8
#12 0x000073349f0bc3ef in ?? () from /lib/x86_64-linux-gnu/libffi.so.8
#13 0x000073349f0bf0be in ffi_call () from /lib/x86_64-linux-gnu/libffi.so.8
#14 0x000073349f0eb11c in ?? () from /usr/lib/python3.12/lib-dynload/_ctypes.cpython-312-x86_64-linux-gnu.so
#15 0x000073349f0e62af in ?? () from /usr/lib/python3.12/lib-dynload/_ctypes.cpython-312-x86_64-linux-gnu.so
#16 0x0000000000549185 in _PyObject_MakeTpCall ()
#17 0x00000000005d73c9 in _PyEval_EvalFrameDefault ()
#18 0x000000000054a9d2 in _PyObject_Call_Prepend ()
#19 0x000000000059e09f in ?? ()
#20 0x0000000000599b63 in ?? ()
#21 0x0000000000549185 in _PyObject_MakeTpCall ()
#22 0x00000000005d73c9 in _PyEval_EvalFrameDefault ()
#23 0x00000000005d58eb in PyEval_EvalCode ()
#24 0x00000000005d347c in ?? ()
#25 0x00000000005da8aa in _PyEval_EvalFrameDefault ()
#26 0x0000000000555b8f in ?? ()
#27 0x00000000005d9c5f in _PyEval_EvalFrameDefault ()
#28 0x000000000054cd94 in ?? ()
#29 0x000000000054b3b5 in PyObject_Call ()
#30 0x00000000005db55b in _PyEval_EvalFrameDefault ()
#31 0x00000000005d58eb in PyEval_EvalCode ()
#32 0x0000000000608b42 in ?? ()
#33 0x00000000006b4e93 in ?? ()
#34 0x00000000006b4bfa in _PyRun_SimpleFileObject ()
#35 0x00000000006b4a2f in _PyRun_AnyFileObject ()
#36 0x00000000006bca95 in Py_RunMain ()
#37 0x00000000006bc57d in Py_BytesMain ()
#38 0x000073349fe2a1ca in __libc_start_call_main (main=main@entry=0x5189b0, argc=argc@entry=0x2, argv=argv@entry=0x7ffe5160dcb8) at ../sysdeps/nptl/libc_start_call_main.h:58
#39 0x000073349fe2a28b in __libc_start_main_impl (main=0x5189b0, argc=0x2, argv=0x7ffe5160dcb8, init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>, stack_end=0x7ffe5160dca8)
    at ../csu/libc-start.c:360
#40 0x0000000000657ce5 in _start ()

I'm using the latest pwntools stable branch, commit 9e0ca3a

seems to only happen when installed alongside angr

What Unicorn version do you have? Looks a bit like #2560 and other Unicorn issues.

e.g. pip freeze |grep unicorn

the result shows unicorn==2.0.1.post1, which is likely the version pinned by angr

This very much looks like a duplicate of what I just wanted to report 😆

import unicorn as U

print("Unicorn version:", U.__version__)
uc = U.Uc(U.UC_ARCH_X86, U.UC_MODE_64)
uc.mem_map(0, 0x1000)
uc.mem_write(0, b"\xff\xef")
uc.emu_start(0, until=-1, count=1)

This fails with unicorn 2.0.1, but works with 2.1.x.
I'm getting a similar backtrace in gdb.

(This was reduced from parsing an ELF and the plt emulation)

There were other problems with unicorn 2.0.1 before (see #2296). Should we bump the minimum version in our dependencies to >= 2.1.0? The latest version 2.1.3 has a bug too (#2560) and I don't remember if 2.1.0 - 2.1.2 had other problems related to packaging on their own iirc. Does anyone remember the details?

Unicorn 2.1.4 is out and should solve this dilemma.

Oh no, the fix for #2560 was reverted by accident, so 2.1.4 still crashes - #2619
We'll have to wait for the next unicorn release.