리눅스 커널을 흔드는 3종 세트, Copy Fail · Dirty Frag · Fragnesia 취약점 정리

한꺼번에 터진 커널 취약점 세 개

이번 주 리눅스 커뮤니티가 술렁이고 있어요. Gentoo가 공식 채널을 통해 Copy Fail, Dirty Frag, Fragnesia 라는 이름의 세 가지 커널 취약점을 공개했거든요. 이름만 봐도 살벌하죠. 특히 "Dirty"라는 단어가 들어간 순간 보안 쪽에서 일하는 분들은 트라우마가 떠오르실 거예요. 2016년의 Dirty COW, 2022년의 Dirty Pipe처럼 이름에 Dirty가 붙은 커널 버그는 죄다 권한 상승(privilege escalation)이 가능한 무시무시한 녀석들이었거든요.

이번 세 개도 비슷한 결을 갖고 있어요. 일반 사용자 권한만 있어도 root로 올라설 수 있거나, 커널 메모리를 읽어내서 비밀 정보를 빼내거나, 시스템 전체를 멈춰버릴 수 있는 가능성이 있는 버그들이에요. 이게 왜 중요하냐면, 클라우드 환경에서 한 컨테이너에서 다른 컨테이너로 탈출하거나, 공유 호스팅에서 다른 사용자의 데이터를 들여다보는 시나리오가 가능해지기 때문이에요.

Copy Fail이 뭔가요

이름 그대로 "복사가 실패"하는 버그예요. 좀 더 정확히 말하면, 커널이 사용자 공간(우리가 쓰는 일반 프로그램 영역)과 커널 공간(운영체제 핵심 영역) 사이에서 데이터를 주고받을 때 쓰는 copy_from_user나 copy_to_user 같은 함수가 있는데, 특정 조건에서 이 함수의 반환값을 제대로 검사하지 않아서 생기는 문제예요.

이게 뭐냐면, 보통 사용자 프로그램이 "내 메모리에서 이 주소의 데이터를 커널로 가져가"라고 시스템 콜을 부르면 커널이 데이터를 복사해와요. 그런데 사용자가 일부러 잘못된 주소나 권한 없는 영역을 가리키면 복사가 실패해요. 이때 실패를 무시하면 커널은 "복사한 데이터가 유효하다"고 착각하고 쓰레기값으로 작업을 계속해요. 운이 나쁘면 그 쓰레기값이 권한 검사를 우회하는 마법의 숫자가 되거나, 커널 메모리의 다른 영역을 덮어쓰는 발판이 돼요.

Dirty Frag와 Fragnesia

나머지 두 개는 둘 다 패킷 단편화(fragmentation) 처리와 관련이 있어요. 네트워크에서 큰 패킷은 여러 조각으로 나뉘어 전송되고 받는 쪽에서 다시 조립되는데, 이 조립 과정을 처리하는 커널 코드에 문제가 있어요.

Dirty Frag는 조각을 재조립하는 버퍼 관리에서 use-after-free 형태의 버그를 만들 수 있는 케이스로 보여요. 사용한 다음 해제한 메모리를 다시 참조하는 고전적인 버그 패턴인데, 공격자가 그 사이에 자기가 원하는 데이터를 그 메모리 자리에 끼워 넣으면 커널이 그걸 그대로 신뢰하고 사용해요. 결과적으로 커널 안에서 임의 코드 실행으로 이어질 수 있어요.

Fragnesia는 이름이 재미있는데 "Fragment + Amnesia(기억상실)"의 합성어예요. 조각들을 재조립하다가 어느 시점에 커널이 이전 조각의 메타데이터를 잊어버리거나 잘못 기억해서 정보 유출(information leak)로 이어지는 패턴이에요. 정보 유출이 별거 아닌 것 같지만, 현대 커널은 KASLR(주소 무작위화) 같은 방어 기법을 쓰기 때문에 메모리 주소 하나만 새어 나가도 다른 익스플로잇의 결정적인 재료가 돼요.

비슷한 사건들과 비교해보면

리눅스 커널은 매년 수십 개의 CVE가 보고되는데, 그중에서 진짜 "위험한" 녀석은 손에 꼽혀요. Dirty COW(CVE-2016-5195) 는 9년 묵은 버그로 모든 안드로이드 기기까지 영향을 줬고, Dirty Pipe(CVE-2022-0847) 는 read-only 파일을 덮어쓰게 만들어서 SUID 바이너리를 통해 root를 얻을 수 있었어요. 작년에 화제가 됐던 StackRot이나 PwnKit 계열도 같은 카테고리예요.

이번 세 개가 그 정도 임팩트일지는 아직 분석이 더 필요하지만, 패치가 메인라인 커널에 머지된 속도와 배포판들의 긴급 업데이트 양상을 보면 결코 가볍지 않다는 신호로 읽혀요. 특히 단편화 관련 버그는 원격 공격 가능성이 있다는 점에서 로컬 권한 상승만 되는 버그보다 한 단계 더 무서워요.

한국 개발자가 지금 해야 할 일

첫째, 서버 커널 버전 확인이에요. uname -r로 현재 커널 버전을 확인하고, 디스트리뷰션 보안 공지를 들여다보세요. Ubuntu는 USN, RHEL/Rocky/Alma는 RHSA, Debian은 DSA를 보면 돼요. 패치된 버전이 나왔다면 즉시 적용하고 재부팅 일정을 잡으세요. "재부팅 없이 커널 패치"가 되는 라이브 패치 기능(Canonical Livepatch, kpatch 등)이 있다면 더 좋고요.

둘째, 컨테이너 환경 점검이에요. Docker나 쿠버네티스 노드는 호스트 커널을 공유하기 때문에 호스트 커널이 취약하면 컨테이너 격리가 의미를 잃어요. 노드 OS 업데이트 정책을 다시 한번 들여다보고, 가능하면 seccomp와 AppArmor/SELinux로 시스템 콜 노출을 최소화해두세요.

셋째, 임베디드와 IoT예요. 이쪽은 보통 업데이트가 느리고, 한 번 출하되면 몇 년씩 그대로 쓰는 경우가 많아요. 회사에서 임베디드 리눅스 기반 제품을 다루고 있다면 이번 취약점이 자사 제품에 어떻게 영향을 주는지 SoC 벤더의 BSP(Board Support Package) 패치 가능 시점부터 확인해두세요.

마무리

커널 취약점은 "내 코드와 상관없어" 같은 영역이 아니에요. 우리가 짠 애플리케이션이 아무리 안전해도, 그 밑의 커널이 뚫리면 모든 게 무너지거든요. 여러분의 회사는 커널 패치 주기를 어떻게 운영하고 있나요? 그리고 자동화된 취약점 스캐닝과 패치 배포 파이프라인이 있는 곳, 혹시 노하우를 공유해주실 수 있으세요?