1

I obtained an ELF core dump that was provoked by fuzzing a proprietary server. As I do not have access anymore to the machine that hosted this server, and the server is part of a tightly coupled set of binaries that would be hard to emulate, I can't rely much on reproducing dynamically the crash in better conditions.

The core dump does not have much debugging information, mostly basic info about the registers' state at the moment of the crash, for each of the threads:

Displaying notes found at file offset 0x000034a0 with length 0x000045b8:
  Owner                 Data size       Description
  CORE                 0x00000150       NT_PRSTATUS (prstatus structure)
  CORE                 0x00000088       NT_PRPSINFO (prpsinfo structure)
  CORE                 0x00000130       NT_AUXV (auxiliary vector)
  CORE                 0x00000200       NT_FPREGSET (floating point registers)
  CORE                 0x00000150       NT_PRSTATUS (prstatus structure)
  CORE                 0x00000200       NT_FPREGSET (floating point registers)
  CORE                 0x00000150       NT_PRSTATUS (prstatus structure)
(...)
  CORE                 0x00000150       NT_PRSTATUS (prstatus structure)
  CORE                 0x00000200       NT_FPREGSET (floating point registers)

When I load the core dump into gdb, I can see only the backtraces for each thread, most are not interesting as they only contain the mention of an address located in shared object memory I can't fetch:

(gdb) thread 3
[Switching to thread 3 (LWP 9593)]
#0  0x00007fa5eb282489 in ?? ()
(gdb) bt
#0  0x00007fa5eb282489 in ?? ()
#1  0x0000000000000000 in ?? ()
(gdb) x/i 0x00007fa225bce99d
=> 0x7fa5eb282489:  Cannot access memory at address 0x7fa5eb282489

One of the threads, however, is slightly more interesting as it contains an address contained in the binary proper. However, this address turns out to be located in the middle of a signal handler, and no to be the latest called function, as the binary jumped again already in a library at the time of the crash.

The rest of the backtrace does not look more interesting - except for a few addresses that look like they were fetched out of initialized memory (0x3030303000000009 - 0x30 is ASCII "0", it the reason for this documented somewhere?).

(gdb) thread 1
[Switching to thread 1 (LWP 9593)]
#0  0x00007fa324ee2617 in ?? ()
(gdb) bt
#0  0x00007fa324ee2617 in ?? ()
#1  0x000000000073c0a9 in sigrecv ()
#2  0x3030303000000009 in ?? ()
#3  0x0000246830303030 in ?? ()
#4  0x0000000000000000 in ?? ()
(gdb) frame 1
#1  0x000000000073c0a9 in sigrecv ()
(gdb) info frame
Stack level 1, frame at 0x7fa1cf1d3828:
 rip = 0x73c0a9 in sigrecv; saved rip = 0x3030303000000009
 called by frame at 0x7fa1cf1d3830, caller of frame at 0x7fa1cf1d3820
 Arglist at 0x7fa1cf1d3818, args: 
 Locals at 0x7fa1cf1d3818, Previous frame's sp is 0x7fa1cf1d3828
 Saved registers:
  rip at 0x7fa1cf1d3820

When jumping at the outlined point of the signal handler using IDA, i call see it is part of a large function and located just after a call to kill(gettid(), SIGQUIT). The core dump's metadata indicates indeed a SIGQUIT, albeit I guess this SIGQUIT was triggered after the actual crash that would then be a SIGSEGV.

I thought about writing a script for scanning the core dump for the presence of siginfo_t or ucontext_t, but I think it could be painful if not impossible as these structures do not seem to have very distinctive marks.

So, what can I do to troubleshoot further the origin of the crash?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.