메모리 안전성 버그를 실제 공격으로 바꾸는 방식은 지난 20여 년간 크게 바뀌어 왔다. 과거에는 버그로 코드 포인터를 덮어써 프로그램의 제어 흐름을 탈취하고, 공격자가 심어둔 코드를 실행시키는 방식이 비교적 손쉬웠다. 그러나 DEP, CFI, CPI 같은 방어 기법이 축적되면서 프로그램이 의도한 코드 밖으로 실행 흐름을 돌리는 일은 실무적으로 매우 어려워졌다. USENIX Security 2024에서 발표된 한 연구는 바로 이 지점을 파고든다. 제어 흐름을 전혀 건드리지 않는 '데이터 전용 공격(data-only attack)'을, Einstein이라는 도구로 자동 생성해낸 것이다.
데이터 전용 공격은 프로그램이 원래 실행하려던 정당한 코드를 그대로 실행하게 두되, 그 코드가 다루는 데이터만 악의적으로 바꾸는 방식이다. 개념 자체는 새롭지 않다. 약 20년 전부터 알려져 있었지만, 학계와 업계의 통념은 이런 공격이 지나치게 애플리케이션 종속적이거나 복잡해서 실질적 위협이 되기 어렵다는 것이었다. 연구진의 핵심 주장은 이 통념이 더 이상 정당화되지 않는다는 데 있다. 마이크로소프트, 구글, 모질라 모두 자사 보안 버그의 약 70%가 메모리 안전성 문제라고 보고하는 상황에서, 이 버그들을 손쉽게 무기화할 수 있는 경로가 열려 있다면 그 파급은 결코 작지 않다.
고전적 사례가 보여주는 원리
연구가 드는 고전적 예시는 웹 서버다. 서버는 시작 시 설정 파일을 읽어 CGI-BIN 경로 같은 값을 초기화한다. 예컨대 cgi_bin_path 변수에 "/usr/local/server/cgi-bin"이 담기고, 이 디렉터리 안의 프로그램을 클라이언트 요청에 따라 실행한다. 그런데 서버에 버퍼 오버플로 같은 메모리 쓰기 버그가 있어 이 변수를 "/bin"으로 덮어쓸 수 있다면, 이후 요청 처리 과정에서 서버는 execve 시스템 콜의 인자만 바뀐 채 정상 코드를 그대로 실행한다. 공격자의 코드는 한 줄도 실행되지 않지만, 결과적으로 임의의 프로그램 실행이 가능해진다. 정상 실행과 악성 실행의 차이는 오직 syscall에 넘어가는 인자값뿐이다.
이런 공격이 위협적이지 않다고 여겨진 이유는 두 가지였다. 첫째, 애플리케이션 종속성이다. 공격자가 프로그램의 수많은 데이터 중 하필 cgi_bin_path가 보안상 결정적이라는 점, 그리고 특정하게 변형된 POST 요청이 그것을 건드린다는 점을 알아내려면 코드 리버스 엔지니어링이나 프로토콜 분석 같은 노동집약적 사전 작업이 필요했다. 둘째, 복잡성이다. 최근의 데이터 전용 공격 기법들은 무거운 데이터 흐름 제약 해석이나 튜링 완전한 기계 구성처럼 과도하게 복잡한 영역으로 나아갔고, 이것이 오히려 공격의 문턱을 높은 것처럼 보이게 만들었다.
Einstein의 두 가지 단순화
Einstein의 발상은 이런 복잡성을 걷어내는 데 있다. 알베르트 아인슈타인의 말로 알려진 '가능한 한 단순하게, 그러나 지나치게 단순하지는 않게'에서 이름을 따왔다. 첫째, 애플리케이션에 무관한 방식을 택한다. HTTP 프로토콜의 세부 예외 같은 애플리케이션 고유 의미를 파고드는 대신, 모든 프로그램이 커널과 통신할 때 공통으로 쓰는 인터페이스, 즉 시스템 콜을 표적으로 삼는다. execve로 임의 코드를 실행하거나 write로 파일을 조작하는 등, 보안에 민감한 syscall의 인자에 공격자가 조작 가능한 데이터가 흘러드는지를 추적한다. 둘째, 단순한 흐름만 노린다. 이미 유효한 실행 경로 위에서, 인자값이 공격자 제어 데이터로부터 그대로 복사되어 오는 경우를 겨냥한다. 연구진은 이를 '항등 데이터 흐름(identity data flow)'이라 부른다.
Einstein은 두 단계로 작동한다. 먼저 후보 공격을 생성한다. 바이너리 수준의 계측을 붙여 서버를 실행하고, 동적 오염 분석(taint analysis)으로 공격자가 손상시킬 수 있는 데이터에 표식을 붙인 뒤 정상 요청 워크로드를 처리시킨다. 오염된 데이터가 syscall 인자로 흘러드는 지점을 포착하고, 그 인자가 특정 변수와 단지 오염된 정도가 아니라 값 자체가 동일하다면 항등 흐름으로 판정해, 어느 주소를 어떤 값으로 덮어쓰면 되는지 (주소, 값) 쌍을 만든다. 다음은 확인 단계다. 항등 흐름이 있다고 해서 반드시 악용 가능한 것은 아니기에 — 서버가 실행 전 경로를 검증할 수도 있다 — 서버를 재시작해 실제로 해당 데이터를 덮어쓰고, 공격 워크로드를 보내 파일이 실제로 생성되는지 등으로 동작 여부를 검증한다.
실무자가 새겨야 할 함의
실측 대상은 웹 서버 httpd, lighttpd, nginx와 데이터베이스 postgres, redis였다. 워크로드는 각 프로그램의 테스트 스위트로 생성했다. 결과는 통념을 정면으로 반박한다. 공격자가 오염시킬 수 있는 보안 민감 syscall이 많았고, postgres를 제외하면 그중 84~98%가 항등 흐름을 가져 대부분에 대해 후보 공격을 만들어낼 수 있었다. 더 주목할 점은 테스트 스위트의 코드 커버리지가 27~49%에 그쳤음에도 이 정도 결과가 나왔다는 것이다. 커버리지를 높이면 더 많은 취약 지점이 드러날 여지가 크다.
다만 이 연구의 범위와 한계도 분명히 짚을 필요가 있다. Einstein은 공격자가 피해자와 동등한 프로그램을 로컬에서 분석할 수 있다는 전제 위에서 동작하며, 실측은 사용자 입력 상호작용이 풍부하고 위험한 syscall이 많은 서버 애플리케이션에 집중됐다. 사용자 입력이 제한적이거나 명백히 위험한 syscall이 적은 프로그램에서 같은 결과가 나온다고 단정할 수는 없다. 그럼에도 실무적 메시지는 명확하다. 코드 포인터 보호에 초점을 맞춘 기존 방어만으로는 충분치 않으며, 시스템 콜 인자로 흘러드는 데이터의 무결성, 실행 경로에 대한 화이트리스트 검증 같은 보완책을 함께 고려해야 한다. 메모리 안전성 버그를 여전히 다수 안고 있는 조직이라면, '제어 흐름을 지켰으니 안전하다'는 전제 자체를 재검토해야 할 시점이다.