---
title: "GrapheneOS, 최근 리눅스 커널 메모리 취약점 3종 영향 안 받는다고 밝힘"
published: 2026-05-08T22:23:08.000Z
canonical: https://jeff.news/article/2534
---
# GrapheneOS, 최근 리눅스 커널 메모리 취약점 3종 영향 안 받는다고 밝힘

GrapheneOS 쪽은 최근 공개된 리눅스 커널 취약점 Copy Fail, Copy Fail 2, Dirty Frag 3종이 GrapheneOS에 적용되지 않는다고 설명했어. 핵심은 GrapheneOS만의 추가 방어 이전에, 현대적인 안드로이드 오픈소스 프로젝트(AOSP)의 SELinux 정책과 GKI 커널 설정만으로도 공격 표면이 꽤 줄어든다는 점이야.

- GrapheneOS는 최근 공개된 리눅스 커널 취약점 3종, Copy Fail, Copy Fail 2, Dirty Frag에 취약하지 않다고 밝힘
  - 이유는 단순히 GrapheneOS가 별도 패치를 빨리 넣어서가 아니라, 현재 안드로이드 오픈소스 프로젝트(AOSP)의 SELinux 정책이 3개 버그의 악용을 모두 막고 있기 때문임
  - 표준 AOSP GKI 커널 설정도 취약한 기능 3개 중 2개를 기본적으로 꺼둔 상태라고 함

> [!IMPORTANT]
> 이번 건은 “GrapheneOS가 특수해서만 안전하다”가 아니라, 현대적인 AOSP의 SELinux 정책과 GKI 커널 설정만으로도 특정 커널 취약점 악용 경로를 막을 수 있다는 사례에 가까움.

- 핵심 방어 전략은 공격 표면 축소임
  - GrapheneOS는 사용하지 않는 커널 기능을 설정에서 제거하고, SELinux 정책으로 앱과 시스템 프로세스가 접근 가능한 기능을 아주 세밀하게 제한함
  - seccomp-bpf도 여러 표준 샌드박스에서 쓰이지만, 이 글에서는 대부분의 공격 표면 축소가 SELinux를 통해 이뤄진다고 설명함

- AOSP의 SELinux 정책은 생각보다 꽤 촘촘하게 동작함
  - 드라이버에 보내는 ioctl 명령, 허용되는 소켓 타입 같은 것들을 allowlist 방식으로 제한함
  - 취약점이 자주 나오는 기능인 user namespaces와 io_uring도 앱이나 거의 모든 기본 운영체제 프로세스에서 사용할 수 없게 막아둠

- GrapheneOS는 이번 3개 취약점에 대해서는 “추가 방어까지 가지 않아도 충분했다”는 입장임
  - GrapheneOS 자체도 커널 공격 표면을 더 줄이는 작업을 하고 있음
  - 다만 이번 사례에서는 최신 AOSP GKI 커널과 SELinux 정책만으로도 방어가 성립했다고 봄

- 리눅스 커널의 로컬 권한 상승 취약점은 흔하지만, 이번처럼 메모리 관련 로직 오류인 경우는 상대적으로 드묾
  - 대부분의 심각한 커널 취약점은 전통적인 메모리 손상 버그라고 함
  - GrapheneOS는 이런 메모리 손상 버그에 대해 하드웨어 메모리 태깅, zero-on-free 같은 일반화된 exploit 방어를 강화하고 있음

- 글쓴이는 리눅스 커널 구조 자체에 꽤 날카롭게 문제를 제기함
  - 리눅스는 코어 커널과 하드웨어 드라이버 코드가 엄청나게 크고, 이 코드들이 대부분 격리 없이 전체 권한으로 실행된다는 점을 지적함
  - 마이크로커널 구조였다면 이번 3개 취약점도 격리된 프로세스 안에 갇혔을 거라고 봄

- 장기적인 해법으로는 스마트폰의 하드웨어 기반 가상화가 중요하다고 봄
  - GrapheneOS 쪽은 스마트폰 가상화 성능과 기능이 계속 좋아지고 있고, 커널 보안 문제를 줄이는 데 큰 역할을 할 수 있다고 말함
  - 커널을 계속 보강하는 것만으로는 한계가 있고, 결국 더 강한 격리 모델이 필요하다는 얘기임

- 메모리 안전 언어도 도움이 된다고 인정함
  - 이번 취약점들이 전형적인 메모리 손상 버그는 아니지만, 더 나은 타입 시스템과 안전한 추상화는 여전히 효과가 있다고 설명함
  - 네트워킹, 디바이스 드라이버 같은 저수준 메모리 처리를 커널 전체가 아니라 훨씬 작은 영역으로 줄이는 방향이 필요하다는 주장임

- 상업용·정부용 exploit 체인에서도 리눅스 커널 메모리 손상 버그가 거의 빠지지 않는다고 함
  - 다만 이런 버그는 다양한 기기와 커널 버전에서 안정적으로 동작하는 exploit을 만들기 어렵다는 특징도 있음
  - 그래서 GrapheneOS는 공격 표면 축소와 범용 exploit 방어를 동시에 밀고 가는 쪽에 무게를 둠

---

## 기술 맥락

- 이번 사례에서 중요한 선택은 “취약한 기능을 패치할 때까지 기다리는 것”보다 “애초에 앱이 그 기능에 닿지 못하게 막는 것”이에요. 커널 취약점은 계속 나오기 때문에, 모든 버그를 사전에 없애겠다는 접근만으로는 방어가 힘들거든요.

- SELinux가 중심에 있는 이유는 정책 단위가 꽤 구체적이기 때문이에요. 앱이 어떤 ioctl을 호출할 수 있는지, 어떤 소켓 타입을 쓸 수 있는지, user namespaces나 io_uring 같은 위험한 기능에 접근 가능한지까지 제한할 수 있어요.

- AOSP GKI 설정도 의미가 있어요. 제조사나 운영체제별 추가 보안 기능이 없어도 표준 커널 설정에서 취약 기능 3개 중 2개가 꺼져 있었다는 건, 기본값이 보안 결과를 크게 바꿀 수 있다는 뜻이에요.

- GrapheneOS가 가상화를 강조하는 이유는 리눅스 커널과 드라이버 코드가 너무 넓은 권한을 갖고 실행되기 때문이에요. 커널 안에서 터지는 버그를 완전히 없애기 어렵다면, 기능을 더 잘게 격리해서 터져도 피해 범위를 줄이는 쪽이 현실적인 방향이에요.

- 메모리 안전 언어 이야기도 같은 맥락이에요. 모든 커널 코드를 당장 바꾸자는 얘기가 아니라, 위험한 저수준 메모리 처리를 좁은 영역에 가두고 나머지는 안전한 추상화로 다루자는 쪽에 가까워요.

## 핵심 포인트

- AOSP SELinux 정책이 취약점 3종의 악용 경로를 차단함
- 표준 AOSP GKI 커널 설정은 취약한 기능 3개 중 2개를 비활성화함
- GrapheneOS는 SELinux, seccomp-bpf, 커널 기능 제거로 공격 표면을 줄임
- 리눅스 커널 취약점의 대부분은 메모리 관련 로직 오류보다 메모리 손상 버그임
- 장기적으로는 가상화와 메모리 안전 언어가 커널 보안 개선의 핵심 방향으로 언급됨

## 인사이트

이 글의 포인트는 특정 취약점 3개를 피했다는 자랑보다, 모바일 운영체제에서 공격 표면 축소가 얼마나 실전적인 방어인지 보여준다는 데 있어. 커널 버그를 모두 없애는 건 현실적으로 어렵고, 결국 노출되는 기능 자체를 줄이는 설계가 중요하다는 얘기야.