Rust와 C/C++의 메모리 안전성 CVE는 왜 다르게 집계되는가

• Rust와 C/C++의 CVE 숫자를 그대로 비교하면,
  메모리 안전성 취약점을 “라이브러리 문제”로 보는 기준 차이를 놓치기 쉬움
• C/C++에서는 잘못된 API 호출로 UB나 세그폴트가 나도 대개
  사용자 코드의 오용으로 처리되며, 가능성 자체를 전부 CVE로 등록하지 않음
  libcurl

의 curl_getenv(NULL)

호출은 경고 없이 빌드되고 실행 시 세그폴트가 날 수 있지만, 보통 curl

취약점으로 보지는 않음

• Rust에서는 사용자 코드에
  unsafe

가 없는데 안전한 API 호출만으로 메모리 버그가 발생하면, 라이브러리의 soundness bug로 간주함

• 그래서 Rust의 일부 CVE는 C/C++보다 더 엄격한 기준으로 기록되며,
  원시 CVE 수 비교만으로 메모리 안전성을 판단하기 어려움

CVE 숫자 비교가 흔들리는 이유

• CVE는 소프트웨어 보안 취약점을 분류하고 보고하는 데이터베이스임
• 취약점은 단순한 프로그램 로직 버그에서 생길 수도 있고, 익스플로잇으로 이어지기 쉬운
  메모리 안전성 문제에서 비롯될 수도 있음
• Rust와 C/C++의 CVE 수를 비교하며 Rust가 “실제로는 메모리 안전하지 않다”거나 “도입할 가치가 없다”는 주장도 나옴
• 하지만 메모리 안전성과 관련된 잠재 취약점을 두 생태계가 다루는 방식에는 큰 차이가 있음

Rust에서도 취약점은 가능함

• Rust 프로그램도
  UB와 메모리 안전성 버그를 일으킬 수 있음
• 대부분의 경우 이런 문제에는
  unsafe

키워드가 필요함

• Rust 프로그램이 UB를 전혀 겪을 수 없다는 주장은 틀림
• 메모리 안전성과 무관한 일반 취약점도 Rust에서 가능함
• 관리자 대시보드 접근 권한 검사를 빠뜨리는 문제는 어떤 언어에서도 생길 수 있음

C 라이브러리 예시: curl_getenv(NULL)

curl

은 널리 쓰이고 잘 관리되는 C 기반 네트워킹 라이브러리임
libcurl

의 curl_getenv

는 여러 운영체제에서 환경 변수 값을 가져오는 이식성 있는 추상화 함수임

• 다음 C 프로그램은
  curl_getenv

에 NULL

포인터를 넘김

#include <curl/curl.h>
int main(void) {
curl_getenv(NULL);
}

• 이 프로그램은
  gcc test.c -otest -lcurl -Wall -Wextra

로 경고 없이 컴파일될 수 있음

• 실행하면 세그폴트가 발생할 수 있고, 이는
  메모리 안전성 버그이자 잠재 취약점으로 볼 수 있음
• 하지만 이런 예시는 보통
  curl

의 취약점으로 보고할 사안이 아님

C/C++에서는 오용 가능성만으로 CVE를 만들지 않음

curl_getenv(NULL)

처럼 문제가 생기는 경우는 일반적으로 API의 잘못된 사용으로 간주됨

• 결함의 위치도 라이브러리나 API가 아니라 애플리케이션 코드 쪽으로 봄

• 이런 관행에는 두 가지 이유가 있음

• C의 제한적인 타입 시스템으로는 API의 계약, 불변식, 사전조건, 사후조건을 정밀하게 표현하기 어려움

• 가능한 모든 잘못된 사용을 문서화하는 것도 실용적이지 않음

• 실제로
  curl_getenv

문서는 NULL

호출이 금지되며 세그폴트로 이어질 수 있다고 말하지 않음

• C/C++에서는 UB를 우연히 유발하기가 매우 쉬워, 모든 잠재적 취약 가능성을 CVE로 보고하면 대부분의 라이브러리가 막대한 수의 CVE에 휩쓸릴 수 있음
• 따라서 C/C++에서는 보통 “오용 가능한 API의 존재”가 아니라 특정
  오용 사례를 중심으로 CVE를 만듦

Rust에서는 안전한 API의 책임 경계가 다름

• Rust에서
  hyper::foo(None)

같은 안전한 호출만으로 프로그램이 세그폴트난다고 가정하면, 이는 hyper

의 CVE가 될 수 있음

• 사용자 프로그램에
  unsafe

블록이 없는데 메모리 버그가 발생했다면, 해당 라이브러리에 soundness bug가 있어야 하기 때문임

• Rust에서는 안전한 라이브러리 API를 어떤 방식으로든 사용했을 때 메모리 버그가 날 수 있다면, 이를 사용자 코드가 아니라 라이브러리 버그로 봄
• 이런 API는
  unsound하거나 soundness hole이 있다고 말함
• 실제 프로그램에서 아직 문제가 발견되지 않았더라도, 안전한 API 사용만으로 메모리 버그를 일으킬 수 있으면 CVE가 만들어질 수 있음

safe

와 unsafe

가 책임을 드러냄

• Rust에서는 “이 함수를 메모리 안전성 관점에서 올바르게 쓰고 있는가”에 대한 답이 C/C++보다 명확함
• 호출하는 함수가
  unsafe

로 표시되지 않았다면 안전하게 사용할 수 있어야 함

• 호출하는 함수가
  unsafe

라면 호출 지점에 unsafe

블록이 필요하고, 코드 리뷰와 코드베이스에서 위험 지점이 분명해짐

• 이 구분이 Rust의 메모리 안전성을 실무적으로 확장 가능하게 만드는 요소임
• 사용자 코드가
  unsafe

를 쓰지 않고 컴파일러 버그도 없다면, 잠재적 메모리 안전성 원인을 사용자 코드 책임으로 보기 어려움

• 라이브러리가
  unsafe

인터페이스를 노출하지 않는다면, 사용자는 그 라이브러리를 메모리 버그를 일으키는 방식으로 사용할 수 없어야 함

• 라이브러리가 내부적으로
  unsafe

를 사용하다 버그를 내더라도, 수정은 라이브러리 안에서 이루어지고 사용자는 다시 메모리 버그로부터 안전해짐

원시 CVE 수만으로는 메모리 안전성을 비교하기 어려움

• 같은 논리를 C에 적용하면
  curl_getenv

도 curl

의 CVE로 표시해야 하지만, C에는 Rust의 safe

와 unsafe

같은 구분이 없음

• 사실상 모든 C 코드는 암묵적으로
  unsafe

에 가깝기 때문에, Rust식 기준을 그대로 적용하기 어렵음

• C/C++ 라이브러리 개발자가 안전하고 견고한 라이브러리를 만들더라도, 이를 사용하는 수많은 C 프로그램은 API를 잘못 다루는 방식으로 쉽게 메모리 안전성 문제를 만들 수 있음
• 이 차이는
  curl

뿐 아니라 거의 모든 C/C++ 라이브러리와 두 언어의 표준 라이브러리에도 적용됨

• Rust와 C/C++의 코드 라인당 CVE 수 같은
  원시 숫자 비교는 메모리 안전성을 평가할 때 오해를 부를 수 있음