https://dreamhack.io/lecture/courses/277 을 토대로 작성한 글입니다.

1. Introduction

이번엔 SigReturn-Oriented Programming(SROP)에 대해 알아보자.

이 전에 Signal 부터 알아보자.

2. Signal

2.1 시그널 설명

운영 체제는 크게 유저 모드(User Mode)와 커널 모드(Kernel Mode)로 나뉘어 진다.

실제로 파일을 생성하고, 프로그램을 실행하는 모든 작업은 이 두 개의 모드가 서로 상호 작용하면서 이뤄진다.

시그널은 프로세스에 특정 정보를 전달하는 매개체로, 공격할 때, 보이는 SIGSEGV 또한 시그널에 포함된다.

리눅스에서는 다양한 시그널을 제공한다.

시그널이 발생하면 시그널에 해당하는 코드가 커널 모드에서 실행되고, 다시 유저 모드로 복귀한다.

2.2 시그널 동작 방식

문제를 풀 때, 프로그램의 정상 종료를 위해 alarm 함수를 호출하고,

지정한 시간이 지나면 프로그램을 종료하기 위한 시그널 핸들러를 호출하는 코드를 자주 볼 수 있다.

// Name: sig_alarm.c
// Compile: gcc -o sig_alarm sig_alarm.c 
#include<stdio.h>
#include<unistd.h>
#include<signal.h>
#include<stdlib.h> 
void sig_handler(int signum) {
	printf("sig_handler called.\n");
    exit(0);
}

int main() {
	signal(SIGALRM,sig_handler);
    alarm(5);
    getchar();
    return 0;
}

코드를 보면,

signal 함수를 사용해 SIGALRM 시그널이 발생하면 sig_handler 함수를 실행한다.

프로세스에서 이 모든 것을 처리하는 것처럼 보일 수 있지만,

SIGALRM 시그널이 발생하면 "커널 모드"로 진입한다.

시그널을 커널 모드에서 처리하고 나서 다시 유저 모드로 돌아와 프로세스의 코드를 실행해야 한다.

즉, 유저 모드의 상태를 모두 기억하고 되돌아올 수 있어야한다.

유저 모드의 상태란, 시그널이 발생했을 때 프로세스의 메모리, 레지스터 등이 포함된다.

커널에서는 유저 모드로 되돌아가야 하는 상황을 고려해 유저 프로세스의 상태를 저장하는 코드가 구현되어 있다.

2.3 do_signal

do_signal 함수는 시그널을 처리하기 위해 제일 먼저 호출되는 함수이다.

리눅스 5.8 버전 이하에서는 do_dignal, 리눅스 커털 5.10 이하 버전에서는 arch_do_signal,

상위 버전에서는 arch_do_signal_or_restart로 함수 이름이 변경되었따.

linux/arch/x86/kernel/signal.c 내 arch_do_signal_or_restart 함수

void arch_do_signal_or_restart(struct pt_regs *regs, bool has_signal)
{
	struct ksignal ksig;
	if (has_signal && get_signal(&ksig)) {
		/* Whee! Actually deliver the signal.  */
		handle_signal(&ksig, regs);
		return;
	}

	/* Did we come from a system call? */
	if (syscall_get_nr(current, regs) >= 0) {
		/* Restart the system call - no handlers present */
		switch (syscall_get_error(current, regs)) {
		case -ERESTARTNOHAND:
		case -ERESTARTSYS:
		case -ERESTARTNOINTR:
			regs->ax = regs->orig_ax;
			regs->ip -= 2;
			break;

		case -ERESTART_RESTARTBLOCK:
			regs->ax = get_nr_restart_syscall(regs);
			regs->ip -= 2;
			break;
		}
	}

	/*
	 * If there's no signal to deliver, we just put the saved sigmask
	 * back.
	 */

	restore_saved_sigmask();
}

위의 코드는 arch_do_signal_or_restart 함수로, 시그널이 발생했다면 시그널에 대한 정보를 인자로 get_signal 함수를 호출한다.

해당 함수에서는 시그널에 해당하는 핸들러가 등록되어 있는지 확인한다.

만약 핸들러가 등록되어 있다면 시그널에 대한 정보와 레지스터 정보를 인자로 handle_signal 함수를 호출한다.

2.4 handle_signal

linux/arch/x86/kernel/signal.c 내 handle_signal 함수

static void

handle_signal(struct ksignal *ksig, struct pt_regs *regs)
{
    ...
	failed = (setup_rt_frame(ksig, regs) < 0);
	if (!failed) {
		fpu__clear_user_states(fpu);
	}
	signal_setup_done(failed, ksig, stepping);
}

signal handler 호출 과정

regs->si = (unsigned long)&frame->info;
regs->dx = (unsigned long)&frame->uc;
regs->ip = (unsigned long) ksig->ka.sa.sa_handler;
regs->sp = (unsigned long)frame;

handle_signal 함수의 일부로, setup_rt_frame 함수를 호출하는 것을 볼 수 있다.

handle_signal 함수는 signal handler 호출 과정에서 처럼 시그널에 적용된 핸들러가 존재할 경우,

핸들러의 주소를 다음 실행 주소로 삽입한다.

2.3의 예제에서는 SIGALRM이 발생할 경우 해당 코드를 통해 sig_handler 함수가 호출된다.

3. sigreturn

3.1 설명

현재 프로세스가 바뀌는 것을 "Context Switching(컨텍스트 스위칭)"이라고 한다.

앞서 분석해본 것처럼 커널이 유저가 실행한 프로세스를 관리하기 위해 다양한 코드를 실행한다.

컨텍스트 스위칭이 일어나면 다시 유저 프로세스로 복귀해야한다.

따라서 스위칭이 일어날 때의 상황을 커널에서 기억하고, 커널 코드의 실행을 마치면 기억한 정보를 되덜려 복귀해야한다.

이 때, 사용되는 시스템 콜이 sigreturn 이다.

restore_sigcontext 함수

static bool restore_sigcontext(struct pt_regs *regs,
	struct sigcontext __user *usc,
    unsigned long uc_flags)

{
	struct sigcontext sc;
    
    /* Always make any pending restarted system calls return -EINTR */
    current->restart_block.fn = do_no_restart_syscall;
    
    if (copy_from_user(&sc, usc, CONTEXT_COPY_SIZE))
    	return false;
        
#ifdef CONFIG_X86_32
	set_user_gs(regs, sc.gs);
    regs->fs = sc.fs;
    regs->es = sc.es;
    regs->ds = sc.ds;
    
#endif /* CONFIG_X86_32 */
	regs->bx = sc.bx;
    regs->cx = sc.cx;
    regs->dx = sc.dx;
    regs->si = sc.si;
    regs->di = sc.di;
    regs->bp = sc.bp;
    regs->ax = sc.ax;
    regs->sp = sc.sp;
    regs->ip = sc.ip;
    
#ifdef CONFIG_X86_64
	regs->r8 = sc.r8;
    regs->r9 = sc.r9;
    regs->r10 = sc.r10;
    regs->r11 = sc.r11;
    regs->r12 = sc.r12;
    regs->r13 = sc.r13;
    regs->r14 = sc.r14;
    regs->r15 = sc.r15;
    
#endif /* CONFIG_X86_64 */

	/* Get CS/SS and force CPL3 */
    regs->cs = sc.cs | 0x03;
    regs->ss = sc.ss | 0x03;
    regs->flags = (regs->flags & ~FIX_EFLAGS) | (sc.flags & FIX_EFLAGS);
    /* disable syscall checks */
    regs->orig_ax = -1;
    
#ifdef CONFIG_X86_64
	/*
    * Fix up SS if needed for the benefit of old DOSEMU and	
    * CRIU.
    */
	
    if (unlikely(!(uc_flags & UC_STRICT_RESTORE_SS) && ser_64bit_mode(regs)))
    	force_valid_ss(regs);
        
#endif
	return fpu__restore_sig((void __user *)sc.fpstate,
    	IS_ENABLED(CONFIG_X86_32));
}

이 함수는 restore_sigcontext 함수 코드로,

sigreturn 시스템 콜을 호출하면 내부적으로 해당함수를 호출해

스택에 저장된 값을 각각의 복사하여 기존 상황과 기억을 복귀한다.

코드를 보면, sigcontext 구조체에 존재하는 각 멤버 변수에 값을 삽입하는 것을 볼 수 있다.

sigcontext 구조체를 보자

3.2 sigcontext

sigcontext 구조체

/* __x86_64__: */
struct sigcontext {
  __u64               r8;
  __u64               r9;
  __u64               r10;
  __u64               r11;
  __u64               r12;
  __u64               r13;
  __u64               r14;
  __u64               r15;
  __u64               rdi;
  __u64               rsi;
  __u64               rbp;
  __u64               rbx;
  __u64               rdx;
  __u64               rax;
  __u64               rcx;
  __u64               rsp;
  __u64               rip;
  __u64               eflags;     /* RFLAGS */
  __u16               cs;
  __u16               gs;
  __u16               fs;

  union {
      __u16           ss; /* If UC_SIGCONTEXT_SS */
      __u16           __pad0; /* Alias name for old (!UC_SIGCONTEXT_SS) user-space */
  };

  __u64               err;
  __u64               trapno;
  __u64               oldmask;
  __u64               cr2;

  struct _fpstate __user      *fpstate;   /* Zero when no FPU context */

#  ifdef __ILP32__
  __u32               __fpstate_pad;
#  endif
  __u64               reserved1[8];
};

위 코드는 sigcontext 구조체로, 보면, 레지스터 명칭을 가진 각각의 멤버 변수가 존재하는 것을 확인할 수 있다.

구조체의 멤버 변수 순서는 값 복사 순서와는 전혀 관계가 없기에 외우지 않아도 된다고 한다.(Dreamhack에서 ㅎㅎ)

표에 있는 코드는 x86_64 아키텍처에 해당하는 구조체이다.

따라서 이외 아키텍처의 바이너리를 공격할 때에는 대상 아키텍처를 파악하고 해당 구조체와 커널 코드를 분석해서 진행해야 한다.

4. SROP

4.1 SROP 설명

SigReturn-Oriendted Programming (SROP)는 컨텍스트 스위칭을 위해

사용하는 sigreturn 시스템 콜을 이용한 ROP 기법이다.

ROP는 코드 조각을 모아서 임의의 코드를 실행하는 공격 기법인 것을 생각해보면

이는 sigreturn 시스템 콜을 호출하고, 레지스터에 복사할 값을 미리 스택에 저장해 임의 코드를 실행하는 것을 알 수 있다.

4.2 예제

// Name: sigrt_call.c
// Compile: gcc -o sigrt_call sigrt_call.c
#include <string.h>

int main() {
	char buf[1024];
    memset(buf, 0x41, sizeof(buf));
    asm("mov $15, %rax;"
    	"syscall");
}

sigreturn 시스템 콜을 호출해 레지스터를 스택의 값으로 조작하는 예제 코드이다.

디버깅 결과를 보면 레지스터를 조작할 수 있는 것을 확인할 수 있다.

마치며

컨텍스트 스위칭 (Context Switching): 현재 실행되는 프로세스가 바뀌는 작업

SigReturn-Oriented Programming (SROP): 컨텍스트 스위칭을 위해 사용하는 sigreturn 시스템 콜을 이용한 ROP 기법

Refernce

https://dreamhack.io/lecture/courses/277