Rust 11년 된 건전성 버그 — 공변 필드 대입으로 'static 제약을 우회한다

rust-lang/rust 이슈 #164250. 제목은 "구조체의 수명 요구를 공변 필드 대입으로 우회할 수 있다"입니다. 라벨에 I-unsound와 P-high가 붙었습니다.

버그

struct Q<T: 'static>(Option<T>) 같은 구조체가 있을 때, q.0 = Some(&l)처럼 필드에 직접 대입하면 'static이 아닌 참조가 'static 제약을 통과해 들어갑니다. 구조체 생성 시점에는 검사되는 제약이 필드 대입 경로에서는 빠지는 것입니다.

그 자체로는 아무 일도 없습니다. 문제는 Drop입니다. Q의 Drop 구현이 그 값을 전역 static 컨테이너에 저장하면, 참조 대상 l이 스코프를 벗어난 뒤에도 전역을 통해 접근할 수 있습니다. 프로그램은 컴파일되고, 틀린 값을 출력하고, AddressSanitizer는 stack-use-after-scope를 보고합니다. unsafe 없이 일어납니다.

얼마나 오래됐나

재현 메타데이터는 1.85.0 이상 stable과 nightly입니다. 댓글에서 보고자는 자기 코드가 **1.18.0(2017년)**부터 컴파일됐다고 밝혔고, 컴파일러 팀의 lcnr는 "11년 된" 문제라고 적었습니다. 분산(variance)과 Drop 검사의 상호작용에서 생긴 구멍입니다.

위험 평가

lcnr의 설명: 트리거는 쉽지만 실제 악용에는 의도적으로 악의적인 Drop 구현이 필요합니다. 우연히 밟을 종류가 아니라는 뜻입니다. 원래 P-critical이어야 했지만 11년간 발견되지 않았다는 이유로 P-high로 뒀다고 했습니다. 수정 PR #164277이 열려 있고, 넓게는 차세대 트레이트 솔버와 리전 제약 재작업의 맥락에 있습니다.

글에 없는 것

수정 PR의 내용, 포함될 릴리스 버전, CVE 부여 여부, 실제 악용 사례 — 모두 없습니다. 1.85 이전 버전에서의 공식 재현 확인도 없습니다(보고자 주장과 메타데이터가 다른 범위를 말합니다).

실무에서 할 일

코드를 고칠 일은 없습니다. 악의적인 Drop을 직접 쓰지 않는 한 영향이 없습니다. 이 건은 의존성 감사의 관점에서 의미가 있습니다 — 신뢰하지 않는 크레이트가 unsafe 없이도 메모리 안전을 깰 수 있는 경로가 하나 더 확인된 것입니다. cargo-geiger로 unsafe만 세는 감사는 이런 걸 못 잡습니다. 수정이 들어간 버전이 나오면 툴체인을 올리면 됩니다.