Core dump not written on segmentation fault

Question

I'm now reading The Shellcoder's Handbook: Discovering and Exploiting Security Holes, 2nd Edition.

In the second chapter considered the simple buffer overflow problem like this (C code):

int main () {
    int array[5];
    int i;
    for (i = 0; i <= 255; i++ ) {
        array[i] = 10;
    }
}

Author compiled the code with cc and execute it:

shellcoders@debian:~/chapter_2$ cc buffer2.c
shellcoders@debian:~/chapter_2$ ./a.out
Segmentation fault (core dumped)

then had a peek at written core dump with gdb:

shellcoders@debian:~/chapter_2$ gdb -q -c core
Program terminated with signal 11, Segmentation fault.
#0 0x0000000a in ?? ()
(gdb)

The problem is that core dump haven't been written in my case. I have only message: zsh: segmentation fault ./a.out.

I use Kali 2021.4a in VirtualBox. I have been tried to change default shell with chsh -s /bin/bash but it change nothing and terminal keep opens as zsh.

How to make core dump written on fault? Looks it's should be file written in the same directory with executable file.

Answer 1

First of all, you need to check the core file size in your limits using ulimit command (in bash or in zsh).

# ulimit -c
0

If it's zero, you need to increase it. For instance, to increase it to unlimited:

# ulimit -c unlimited
# ulimit -c          
unlimited

Secondly, you need to check where the coredump is created. On older distros, the default was usually a file called "core" in the CWD. That was probably the default when the book was written.

# /sbin/sysctl kernel.core_pattern
kernel.core_pattern = core

However, today it isn't true anymore on most distros. Today usually the core is generated using systemd-coredump(8).

# /sbin/sysctl kernel.core_pattern
kernel.core_pattern = |/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %e

From man systemd-coredump(8):

By default, systemd-coredump will log the core dump to the journal, including a backtrace if possible, and store the core dump (an image of the memory contents of the process) itself in an external file in /var/lib/systemd/coredump.

You can either find the core dump in that directory, or you can use coredumpctl to list those (you might require sudo or run it as root):

# coredumpctl list
TIME                            PID   UID   GID SIG PRESENT EXE
Wed 2022-01-26 12:53:06 IST   10347   111   222 11  *       /tmp/a.out

The * under the "PRESENT" indicates that a core dump file was created.

You could see the location of the (compressed) coredump by using coredumpctl info <pid>:

# coredumpctl info 10347 |grep Coredump
      Coredump: /var/lib/systemd/coredump/core.a\x2eout.111.1bd8e22a25e844f1b03a87d378b4ed9b.10347.1643194386000000.xz

You can decompress this file using xz command:

# xz --decompress --stdout '/var/lib/systemd/coredump/core.a\x2eout.111.1bd8e22a25e844f1b03a87d378b4ed9b.10347.1643194386000000.xz' > core

Or use the following command to dump the core to some destination.

# coredumpctl -o core dump 10347

Either of those commands will create the file:

# gdb -q -c core
[New LWP 10347]
Core was generated by `/tmp/a.out'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0000000af7a56725 in ?? ()

Answer 2

According to man core, There are various circumstances in which a core dump file is not produced:

   *  The process does not have permission to write the core file.…

   *  A (writable, regular) file with the same name as would be used
      for the core dump already exists, but there is more than one
      hard link to that file.

   *  The filesystem where the core dump file would be created is
      full; or has run out of inodes; or is mounted read-only; or
      the user has reached their quota for the filesystem.

   *  The directory in which the core dump file is to be created
      does not exist.

   *  The RLIMIT_CORE (core file size) or RLIMIT_FSIZE (file size)
      resource limits for the process are set to zero;…

   *  The binary being executed by the process does not have read
      permission enabled.…

   *  The process is executing a set-user-ID (set-group-ID) program
      that is owned by a user (group) other than the real user
      (group) ID of the process, or the process is executing a
      program that has file capabilities…

   *  /proc/sys/kernel/core_pattern is empty and
      /proc/sys/kernel/core_uses_pid contains the value 0.  

   *  (Since Linux 3.7) The kernel was configured without the
      CONFIG_COREDUMP option.

So you should first check for these conditions, in particular, the most probable, the last one : the CONFIG_COREDUMP kernel option.

BTW, also take note that :

On systems that employ systemd(1) as the init framework, core dumps may instead be placed in a location determined by systemd(1).

which, under many implementations corresponds to some /var/lib/systemd subdirectory.