안전한 코드도 컴파일러가 망친다

Chris Domas는 Mop Obfuscator라는 단일 명령어 C 컴파일러를 개발했습니다. 이는 C 소스 코드를 단 하나의 기계어 명령어로 반복적으로 변환하는 도구입니다.

또한 Sand Sifter라는 CPU 퍼저를 개발하여 하드웨어 취약점을 탐색하고 있으며, 제어 흐름 그래프 시각화 도구인 Recyc도 함께 연구하고 있습니다.

CPU에는 '머신 체크 예외'라는 기능이 있어 심각한 문제가 발생하면 모든 작업을 중단하고 비상 처리기를 작동시킵니다. 이 예외는 CPU 과열이나 비트 플립과 같은 외부 요인으로 강제로 발생시킬 수 있습니다.

연구자들은 이렇게 발생한 예외 처리 코드 내에 존재하는 취약점을 활용하여 시스템을 해킹할 수 있는 가능성을 발견했습니다.

개발자들은 안전한 소스 코드를 작성하려 노력하지만, 실제 CPU에서 실행되는 것은 소스 코드가 아닌 컴파일러가 생성한 바이너리 파일입니다. 이 과정에서 개발자의 의도와 다르게 보안 기능이 무력화될 수 있습니다.

C 명세는 추상 머신에 따라 컴파일러가 코드를 재구성할 수 있도록 허용하기 때문에, 소스 코드의 안전성이 실제 실행 환경인 바이너리에서는 보장되지 않을 수 있습니다.

C 명세는 700페이지 분량의 규칙으로 '추상 머신'이라는 가상 컴퓨터를 정의합니다. 컴파일러는 이 추상 머신에서 코드가 실행될 때의 결과만 보장하면, 실제 구현 방식은 자유롭게 최적화할 수 있습니다.

이러한 자유 덕분에 컴파일러는 루프나 재귀, 단순 출력 등에서 결과만 같다면 코드를 임의로 변경하여 실행 속도를 높일 수 있습니다. 이 과정에서 개발자가 의도한 보안 관련 코드가 제거될 여지가 생깁니다.

과거에는 `memset` 함수나 반복문을 사용하여 메모리의 민감 데이터를 삭제하는 코드를 작성했지만, 실제 프로그램 실행 시 데이터가 메모리에 남아있는 문제가 발생했습니다. 이는 컴파일러가 `memset`이나 0을 쓰는 코드를 '아무런 도움이 안 된다'고 판단하여 삭제해 버리기 때문입니다.

이러한 현상은 비밀번호와 같은 민감 정보가 메모리에서 완전히 제거되지 않고 잔존하게 만들어 보안 취약점을 유발합니다. 이는 소스 코드와 CPU 실행 코드 간의 추상화 계층에서 발생하는 문제입니다.

어떤 프로그래밍 언어를 사용하든, 작성된 고수준 코드와 CPU에서 직접 실행 가능한 기계어 코드 사이에는 일대일 변환이 존재하지 않습니다.

이는 모든 프로그래밍 언어가 CPU에서 실행되기 위해 컴파일러를 통해 여러 변환 과정을 거쳐야 한다는 것을 의미합니다. 이 변환 과정에서 원래 코드의 의미가 달라질 수 있습니다.

메모리 삭제 코드 무력화와 같은 최적화는 GCC나 Clang 등 특정 컴파일러만의 문제가 아니라, 모든 컴파일러가 실행 속도 향상을 위해 수행하는 일반적인 동작입니다. 이러한 변환은 오히려 예상되는 정상적인 작동으로 간주됩니다.

컴파일러의 주된 목표 중 하나는 코드 실행 속도를 높이는 것이므로, 최적화를 수행하지 않는 컴파일러는 좋은 컴파일러로 평가받기 어렵습니다.

대규모 코드 베이스에서는 수천 번의 유사한 패턴 중 1%만이 심각한 보안 문제로 이어집니다. 그러나 보안 코드를 작성하려는 개발자의 노력은 나머지 99%의 잠재적 문제를 해결하는 데 크게 기여합니다.

컴파일러는 이러한 보안 코드를 최적화하는 과정에서 의도치 않게 오류를 삽입하거나 보안 기능을 무력화할 가능성이 존재합니다.

제로 트러스트 보안 모델은 기본적으로 애플리케이션을 신뢰하지 않고 허용된 작업만 수행하도록 제한합니다. 이는 애플리케이션이 임의로 작동하거나 불필요한 접근을 하는 것을 차단하여 데이터 유출 위험을 줄입니다.

David Bombal은 PowerShell 및 파이썬 스크립트 실행을 제어하고 ThreatLocker와 같은 도구를 활용하여 학습 기반의 애플리케이션 접근 통제를 구현함으로써 제로 트러스트 원칙을 적용할 수 있다고 설명했습니다.

컴파일러는 수백만 줄의 코드로 이루어져 있으며 수십 년에 걸쳐 복잡하게 진화해 왔습니다. 이러한 복잡성 때문에 컴파일러 내에 존재하는 보안 취약점을 해결하는 것은 하루아침에 새로운 컴파일러를 만드는 것만큼 어렵습니다.

컴파일러 개발자와 보안 연구자들은 협력하여 취약점을 해결하려 노력하고 있지만, 새로운 컴파일러 플래그나 경고 기능을 도입하는 것만으로는 한계가 있습니다. 문제는 깊이 있고 근본적인 영역에 있습니다.

현재 연구자들은 컴파일러 최적화가 보안 취약점을 어떻게 유발하는지 상관관계를 파악하고, 이를 방어하기 위한 방법을 모색하고 있습니다.

C 명세는 컴파일러가 겉보기에 안전한 코드를 검사 시점(Time-of-Check) 또는 사용 시점(Time-of-Use) 취약점으로 변환하는 것을 허용합니다. 이는 레지스터 압력과 같은 특정 상황에서 발생합니다.

이러한 변환은 컴파일러의 최적화 과정에서 발생하며, 개발자가 의도하지 않은 보안 약점을 초래할 수 있습니다.

컴파일러가 CPU 레지스터가 부족한 '레지스터 압력' 상황에 처하면, 데이터를 지역 변수에 복사하는 것을 무의미하다고 판단하여 생략할 수 있습니다.

이로 인해 이전에 사용했던 신뢰할 수 없는 데이터를 다시 읽어 들이게 되면서 검사 시점-사용 시점 취약성이 노출될 수 있습니다. 이는 데이터를 한 번 확인한 후 다시 사용하기 전에 변경될 가능성이 생기는 상황입니다.

컴파일러는 레지스터를 효율적으로 사용하기 위해 최적화를 수행하지만, 이 과정에서 코드의 안전성이 저하될 수 있습니다.

컴파일러를 업그레이드하면 이전 버전과 다른 최적화 방식을 사용하게 되므로, 같은 최적화 플래그를 사용하더라도 과거에는 없었던 검사 시점-사용 시점(TOCTOU) 취약점이 발생할 수 있습니다. 반대로 다운그레이드 시에는 과거 버전의 취약점이 재현될 가능성도 있습니다.

현재 이러한 특정 취약점에 대한 효과적인 대응책은 아직 부재한 상황입니다.

컴파일러가 검사 시점 취약점이나 사용 시점 취약점을 의도적으로 무시하는 경우는 매우 드뭅니다. 연구자들도 실제로 컴파일러가 이러한 동작을 하도록 만드는 데 상당한 어려움을 겪었습니다.

또한 공격자가 600만 줄에 달하는 리눅스 코드와 같은 거대한 코드 베이스에서 이러한 희귀한 취약점을 찾아내 악용하는 것 또한 현실적인 난관이 따릅니다. 아직 알려지지 않은 부분들이 많아 연구가 더 필요합니다.

수만 개의 바이너리에서 1% 미만의 희귀 취약점을 수동으로 분석하는 것은 사실상 불가능합니다. 따라서 이러한 복잡한 바이너리에서 취약점을 탐지하기 위해서는 자동화된 리버스 엔지니어링 방법이 필수적입니다.

이는 효율적인 보안 검증을 위해 대규모 코드 베이스에 대한 자동 분석 기술 개발이 시급함을 의미합니다.

AI 기술은 방어자 입장에서도 보안을 강화하는 데 유용합니다. 특히 일반 프로그래머들은 작성하는 코드의 모든 줄을 일일이 확인하고 고려해야 할 다양한 보안 취약점을 일일이 신경 쓸 시간이 부족합니다.

AI는 이러한 프로그래머의 시간 부족을 보완하여 취약점을 탐지하고 해결책을 제시함으로써 방어 측면에서 큰 도움이 될 수 있습니다.

컴파일러 변환으로 인한 보안 문제에 대응하기 위해서는 빌드 환경의 일관성을 유지하는 것이 중요합니다. 최적화가 적용되지 않은 디버그 빌드에서 모든 것을 테스트한 후, 최적화 빌드로 전환하여 테스트 없이 배포하는 것은 위험합니다.

또한 컴파일러의 경고 기능을 활성화하고 새니타이저(Sanitizer)와 같은 최신 보안 도구를 적극적으로 활용하여 잠재적인 취약점을 사전에 탐지하고 예방해야 합니다.

보안 연구를 성장시키는 핵심 동력은 어떤 문제든 무모한 호기심으로 접근하는 자세입니다. 아무도 묻지 않는 질문을 던지고 숨겨진 비밀을 파헤치는 탐구 정신이 중요합니다.

시간 낭비처럼 보일지라도 무작정 뛰어들어 탐색하는 것이 결국 새로운 발견으로 이어질 수 있다고 크리스 도마스는 강조했습니다.