TECH 으로 돌아가기
TECH HACKER NEWS 오늘 6분 읽기 21 READS

11년 묵은 Rust 빌림 검사기 결함, 메모리 안전성의 전제를 다시 묻다

11년 묵은 Rust 빌림 검사기 결함, 메모리 안전성의 전제를 다시 묻다
SOURCE IMAGE · HACKER NEWS

Rust가 개발자들에게 약속해 온 핵심 가치는 unsafe 블록 밖에서는 메모리 안전성을 컴파일러가 보장한다는 것이다. 그런데 최근 rust-lang/rust 저장소에 올라온 이슈 #164250은 그 보장에 11년 동안 숨어 있던 구멍이 있었음을 드러냈다. 제보된 코드는 컴파일러가 거부해야 마땅한 패턴인데도 아무 오류 없이 빌드되어 실행되며, 반복된 문자만 출력되는 것처럼 보이지만 AddressSanitizer를 켜고 실행하면 stack-use-after-scope, 즉 이미 수명이 끝난 스택 영역을 참조하는 오류로 프로그램이 멈춘다. 제보자가 확인한 범위만 해도 현재 nightly는 물론 적어도 안정판 1.85.0까지 영향을 받으며, 특정 버전은 2017년 1.18.0부터, 또 다른 변형은 1.4 시절부터 같은 증상을 보였다.

왜 '치명적'이 아니라 '높음'인가

이 결함은 우선순위상 P-high로 분류됐다. Rust 팀은 이 정도 사안이라면 본래 P-critical이 맞다고 인정하면서도, 등급을 한 단계 낮춘 이유를 11년이라는 세월에서 찾았다. 그렇게 오랜 기간 누구도 실무에서 걸려 넘어지지 않았다는 사실 자체가, 우연히 마주치기는 어려운 버그임을 방증한다는 논리다. 실제로 이 취약점이 메모리 안전성을 실수로 깨뜨렸을 가능성은 낮다고 보는데, 겉보기에 재현이 쉬워 보여도 실제로 악용하려면 의도적으로 설계된 악의적 Drop 구현이 필요하기 때문이다. 다시 말해 평범한 코드를 짜다가 이 문제로 데이터가 손상되는 상황은 거의 생기지 않고, 공격자가 작정하고 소멸자 동작을 조작해야 비로소 위험이 현실화된다.

근본 원인에 대한 제보자의 진단은 타입 추론 과정의 단일화(unification)가 타입에 걸린 수명(lifetime) 제약을 제대로 검사하지 않는다는 것이다. 필드 대입 없이 단일화 강제 변환(coercion)만으로도 문제를 재현하는 예시가 함께 제시됐다. 즉 서로 다른 수명을 가진 값을 하나로 합칠 때 컴파일러가 수명의 유효성을 끝까지 따지지 않아, 이미 해제되었거나 범위를 벗어난 메모리를 가리키는 참조가 안전한 것처럼 통과해 버리는 구조다. 이는 빌림 검사기가 다루는 영역 중에서도 추론 엔진 깊숙한 곳의 문제이며, 표면적인 문법 검사로는 잡아내기 어려운 종류의 결함이다.

팀이 이미 손대고 있던 영역

주목할 점은 이 버그가 완전히 예상 밖의 영역에서 터진 것이 아니라는 것이다. Rust의 Types 팀은 차세대 트레이트 솔버(next-generation trait solver), 리전 제약 재설계(region constraint rework), 그리고 보다 포괄적으로 Project Zero라 불리는 작업을 이미 진행해 왔다. 이 모두가 타입 시스템의 건전성(soundness) 결함을 전수 해결하고, 아직 발견되지 않은 결함의 위험까지 최소화할 견고한 토대를 만들겠다는 목표에서 출발한 것이다. 이번 사안은 그런 작업이 왜 필요한지를 역설적으로 증명한 셈이다. 수정 방향으로는 두 프런트엔드 양쪽에서 집계형 저장소(aggregate storage)에 핸들을 받아들이지 않도록 막는 접근이 거론됐다.

실무자 입장에서 이 소식을 어떻게 받아들여야 할까. 우선 과도한 불안은 금물이다. 당장 프로덕션 코드가 이 결함 때문에 무너질 가능성은 매우 낮고, 악용에는 고의적 조작이 전제되기 때문이다. 다만 공급받은 외부 크레이트나 신뢰 수준이 불확실한 코드에서 소멸자 동작까지 통제당할 수 있는 환경이라면, 안전하다고 여겨 온 추상화의 경계가 생각보다 얇을 수 있음을 염두에 둘 필요가 있다. 메모리 안전성이 민감한 프로젝트라면 AddressSanitizer 같은 런타임 검증 도구를 CI에 포함시키는 것이 이런 숨은 결함을 조기에 포착하는 현실적 방어선이 된다.

안전 보장은 완성형이 아니라 과정

이번 사건이 던지는 더 큰 메시지는, 안전성을 핵심 가치로 내세우는 언어라 해도 그 보장이 한 번에 완결되는 것이 아니라 끊임없는 검증과 재설계를 통해 유지된다는 점이다. 11년 동안 묵은 결함이 존재했다는 사실은 Rust의 약점이면서 동시에, 그런 결함조차 공개적으로 추적하고 우선순위를 매겨 처리하는 투명한 프로세스가 작동한다는 증거이기도 하다. Rust 팀은 스팸과 소모적 댓글을 막기 위해 해당 이슈의 댓글을 선제적으로 잠갔는데, 이는 관심이 집중된 사안을 차분히 해결하려는 조치로 읽힌다. 언어 생태계를 선택할 때 중요한 것은 결함이 전혀 없다는 비현실적 약속이 아니라, 결함이 드러났을 때 그것을 다루는 조직의 태도와 역량이다. 그 기준에서 보면 이번 대응은 신뢰를 흔들기보다 오히려 그 신뢰가 어떤 토대 위에 서 있는지를 보여 준다.

SOURCE · HACKER NEWS
원문 전체 보기 → https://github.com/rust-lang/rust/issues/164250
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기 →
처리 중...