Ubuntu Question posted in
The official Ubuntu documentation can be found here.

CSAPP Attack Lab Phase1 Segmentation Fault on Ubuntu22.04

I’m a beginner recently working on CSAPP attack lab on Ubuntu22.04.
I download the files and run ctarget in terminal,

./ctarget

Typically, CTARGET is expected to receive stdin as code injection , and injecting too much characters leads to segmentation fault .
However, without typing anything , the program terminates suddenly with :

Ouch!: You caused a segmentation fault!
Better luck next time
FAILED

I tried to use GDB to checkout what’s wrong , I checked the stack frame when it terminated:

(gdb) bt
#0  0x00007ffff7c750d0 in __vfprintf_internal (
    s=0x7ffff7e1a780 <_IO_2_1_stdout_>, 
    format=format@entry=0x4044bc "Type string:", ap=ap@entry=0x556311b8, 
    mode_flags=mode_flags@entry=0)
    at ./stdio-common/vfprintf-internal.c:1244
#1  0x00007ffff7c6079f in __printf (
    format=format@entry=0x4044bc "Type string:")
    at ./stdio-common/printf.c:33
#2  0x00000000004022c3 in launch (offset=<optimized out>)
    at support.c:293
#3  0x000000000040233d in stable_launch (offset=<optimized out>)
    at support.c:340

But there’s no more I can do to cope with it .o(╥﹏╥)o
Is it possible due to ubuntu system? Will it work if I switch to other Linux distros?

Thanks a lot for answering my question .

Tags:

2

Answers


  1. Chosen as BEST ANSWER
    0

    Figured it out myself! It turns out that the reason it was failing was due to the operating system that I selected. None of the Ubuntu versions that I tried (20.04, 21.03, 21.10, and 22.04) worked; however, Fedora 39 allowed it to run properly. This leads me to suspect that the ctarget application was specifically built to run on Fedora, or perhaps requires specific dependencies or dependency versions that the Ubuntu operating systems I downloaded did not have.


  2. 0

    I met the same problem. And my resolution is as follows:

    Reason for segmentation fault

    Using gdb, I found that it is a movaps %xmm1, 0x10(%rsp) instruction in my glibc that causes the failure. I guess that the align requirement of movaps is not satisfied, because the glibc version when compiling the ctarget is so old that the requirement that the size of each frame shall be a multiple of 16 have not been standard. Then I force the rsp to be a multiple of 16 before the program enters __printf_chk@plt in gdb, and it works out and confirm my reasoning.

    Use LD_PRELOAD to force the alignment of rsp

    A resolution is that we can add an abstraction layer, providing a adaptive printf interface.

    First of all, we write such code in printf.c:

    #include <stdio.h>
#include <stdarg.h>

int __printf_chk(int flag, const char *fmt, ...) {
  va_list ap;
  int ret;
  va_start(ap, fmt);
  ret = vfprintf(stdout, fmt, ap);
  va_end(ap);
  return ret;
}

    Then compile it to get printf.s:

    $ gcc -shared -fPIC -S printf.c -O2

    After that, we modify the printf.s file to ensure the low 4 bit of rsp be 1000B:

    --- printf_old.s    2024-01-17 21:03:58.615062917 +0800
+++ printf.s    2024-01-17 21:00:24.983879497 +0800
@@ -7,6 +7,10 @@
 .LFB23:
    .cfi_startproc
    endbr64
+  pushq %rbp
+  movq  %rsp, %rbp
+  andq  $-0x10, %rsp
+  subq  $-0x8, %rsp
    subq    $216, %rsp
    .cfi_def_cfa_offset 224
    movq    %rsi, %r10
@@ -44,6 +48,7 @@
    subq    %fs:40, %rdx
    jne .L6
    addq    $216, %rsp
+  leave
    .cfi_remember_state
    .cfi_def_cfa_offset 8
    ret

    and get the final printf.so:

    $ gcc -shared -fPIC -o printf.so printf.s

    Finally, use LD_PRELOAD to replace the __printf_chk provided in glibc with ours:

    $ LD_PRELOAD=./printf.so ./ctarget -q

    and it works.

    Login or Signup to reply.
Please signup or login to give your own answer.

Back To Top
Search