GrapheneOS, 최근 리눅스 커널 메모리 취약점 3종 영향 안 받는다고 밝힘

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

• 핵심 방어 전략은 공격 표면 축소임

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

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