.jpg)
Windows 8.1 Update 3에 제어 흐름 탈취 공격의 대표적인 방어 기법 CFI 세계 최초로 상용화
상용화 기술들, 버그나 오류 등 여전히 보안 측면에서 취약...사용자에게 불편한 기능으로 인식
[보안뉴스= 정동재 KAIST CSRC 악성코드 분석팀장] 2014년 11월 마이크로소프트의 Windows 8.1 Update 3이 배포되면서 제어 흐름 탈취 공격의 대표적인 방어 기법인 CFI가 세계 최초로 상용화됐습니다. 이후 마이크로소프트에서는 WCFG(Windows Control Flow Guard)라는 이름으로 Visual Studio의 컴파일러에 기능을 적용해 지원하며, Windows 10의 커널이 WCFG로 컴파일되는 등 적극적으로 상용화되고 있습니다. 또한, 2015년 9월에는 LLVM라는 컴파일러가 버전 3.7을 배포하면서 CFI가 메인라인에 포함되는 등 다양한 컴파일러에서 CFI 기법이 활용되고 있습니다.
하지만, 이 상용화 기술들은 CFI 기법이 가지는 알고리즘 자체의 근본적인 취약점과 CFI를 구현하면서 내포될 수 있는 버그나 오류 등으로 인해 여전히 보안 측면에서 취약하며, WCFG로 인한 시스템 전체 성능에 안 좋은 영향을 미치기 때문에 상용화에 대한 부정적인 평가를 받고 있습니다. 일례로, IT/개발자 커뮤니티에서 WCFG에 대한 비활성화 방법을 문의하는 글을 쉽게 찾을 수 있을 만큼 사용자에게는 불편한 기능으로 인식됐습니다.
이러한 문제점을 개선하고자 지난 9월 하드웨어 기반의 CFI 기술인 Intel CET(control-flow enforcement technology)이라는 차세대 모바일 프로세서 ‘Tiger Lake’가 출시됐습니다. 하드웨어 기반의 CET 기술로 인해 이전과 비교했을 때 매우 향상된 성능을 제공하고, CFI 기법을 적용하는데 발생하는 구현상의 보안문제를 어느 정도 해결할 수 있지만, 이 또한 근본적인 CFI 기법의 알고리즘 자체의 취약점 문제는 여전히 해결할 수 없습니다.
CFI를 상용화하면서 발생한 문제점을 크게 둘로 나누면 첫 번째, CFI를 구현하면서 발생한 구현상의 취약점, 두 번째, 적용한 CFI 기법 자체의 취약점으로 구분할 수 있습니다. 구현상의 취약점은 하드웨어 기반으로 구현하거나 취약점 패치를 통해 충분히 해결이 가능합니다. 하지만 CFI 기법 자체가 보안적으로 취약한 요인이 내포되어 있다고 한다면 즉, 근본적인 CFI 기법의 보안성을 높이지 못한다면, 상용화된 어떤 CFI 기술도 해킹으로부터 안전하다고 할 수 없습니다.
지난 CFI 관련 칼럼(시스템 보안 향상 위한 제어 흐름 무결성)에서 살펴봤듯이 완벽한 보안을 보증하는 CFI를 만들기는 쉽지 않은 문제입니다. 이론상으로 완전무결한 CFI 기술이 적용되었다면, 해킹이 불가능할까요? 이에 대한 대답은 해킹이 “가능하다” 입니다. 모든 제어 흐름을 보호해서 제어 흐름 공격이 불가능하더라도 제어 흐름을 변경하지 않는 공격이 얼마든지 가능하기 때문입니다. 대표적인 예로, 비제어 데이터 공격(Non-control Data Attack)이 있는데, 이는 정상적인 프로그램의 실행 흐름과 똑같은 제어 흐름을 가지면서, 오직 데이터 값의 변조만으로 해킹을 하는 방식을 말합니다. 제어 흐름 공격에서는 비정상적인 제어 흐름이 나타나는 것이 특징이지만, 비제어 데이터 공격은 정상적인 제어 흐름이 나타나는 것이 특징이기 때문에, CFI 기법으로 보호하더라도 방어할 수 없습니다.
CFI와 해킹의 관계를 조금 달리 생각해 보겠습니다. 이론상으로 완전무결한 CFI를 지원할 수 있다면, 제어 흐름 공격이 불가능할까요? 이 의문의 답 또한 안타깝게도 “가능하다” 입니다. 제어 흐름 공격이 어떻게 가능한지 알아보기 위해 먼저 완전무결한 CFI에 대해 알아보겠습니다. 완전무결한 CFI를 구현하기 위해서 필요한 정확한 CFG(control flow graph)는 다음과 같이 정의할 수 있습니다. 정확한 CFG(precise CFG)는 어떤 간접 제어 흐름 전송에서 악의적인 실행 흐름 즉, 의도된 동작을 벗어나지 않은 실행 흐름이 존재하지 않고 정상적인 실행 흐름만을 따르는 경우를 뜻합니다.
이 정의를 바탕으로 생각해본다면, 정확한 CFG라고 하더라도 간접 제어 흐름 전송에서 실행할 수 있는 여러 개의 경로 후보군이 나타날 수 있습니다. 이들의 후보군은 모두 합법적인 후보로 어느 곳으로 실행되더라도 정상적인 실행 흐름입니다. 예를 들어, 함수 포인터 F가 간접 호출을 통해 A, B로 분기될 수 있을 때, 이 A, B는 정상적으로 프로그램에서 의도된 실행 흐름입니다. 하지만 런타임 시 F의 흐름은 하나의 특정 경로(A 또는 B)로 결정되며, 다른 하나는 악의적인 실행 흐름이 됩니다. 바꿔 말하면 간접 제어 흐름 전송이 실행되는 시점에서는 딱 하나의 실행 흐름을 제외하고 전부 다 거짓이 된다는 것입니다. 정확한 CFG만으로는 악의적인 실행 흐름인지 판단하는 것 자체가 매우 어렵다는 것을 알 수 있습니다. 결론적으로, 이렇게 완전무결한 CFI 기술을 적용하더라도 제어 흐름 공격이 가능한 것을 의미합니다.
이러한 문제점들로 인해 상용화된 CFI 기술들은 아직까지 보안 측면에서 볼 때 완벽한 해킹 대응 기술이라고 평가할 수 없습니다. 예를 들어, ASLR(Address Space Layout Randomization)이나 DEP(Data Execution Prevention)와 같은 보안 기술도 BOF(buffer overflow)등의 공격을 보다 더 어렵게 만들 뿐 완벽한 보안을 제공해 주지는 않습니다. 메모리 레이아웃을 변화하게 하고, 데이터 영역을 실행 불가능하게 만들어 해킹을 더욱 어렵게 만드는 것처럼, 제어 흐름을 변조하지 못하게 하여 코드 삽입 공격과 코드 재사용 공격을 어렵게 함으로써 해킹을 더욱 어렵게 만든다는 점에서 CFI 기술은 보안을 강화하는 데 큰 도움이 될 것입니다.
현재까지 상용화된 CFI 기술 수준과 달리 제어 흐름 공격을 완벽하게 방어할 수 있는 방법이 존재할까요? 더욱 완벽한 제어 흐름을 분석하기 위해서는 어떻게 해야 할까요? 다음 연재에서는 “어떻게 하면 더욱 완전무결한 CFI 기술을 구현할 수 있을까?”라는 주제를 가지고, 간접 제어 흐름 전송에서 특정 경로를 결정짓는 요소에 대해 살펴보고, 이를 바탕으로 정확한 제어 흐름을 판단할 수 있는 방식에 대해 살펴보도록 하겠습니다.
[글_ 정동재 KAIST 사이버보안연구센터 악성코드 분석팀 팀장]
상용화 기술들, 버그나 오류 등 여전히 보안 측면에서 취약...사용자에게 불편한 기능으로 인식
[보안뉴스= 정동재 KAIST CSRC 악성코드 분석팀장] 2014년 11월 마이크로소프트의 Windows 8.1 Update 3이 배포되면서 제어 흐름 탈취 공격의 대표적인 방어 기법인 CFI가 세계 최초로 상용화됐습니다. 이후 마이크로소프트에서는 WCFG(Windows Control Flow Guard)라는 이름으로 Visual Studio의 컴파일러에 기능을 적용해 지원하며, Windows 10의 커널이 WCFG로 컴파일되는 등 적극적으로 상용화되고 있습니다. 또한, 2015년 9월에는 LLVM라는 컴파일러가 버전 3.7을 배포하면서 CFI가 메인라인에 포함되는 등 다양한 컴파일러에서 CFI 기법이 활용되고 있습니다.
[이미지=utoimage]
하지만, 이 상용화 기술들은 CFI 기법이 가지는 알고리즘 자체의 근본적인 취약점과 CFI를 구현하면서 내포될 수 있는 버그나 오류 등으로 인해 여전히 보안 측면에서 취약하며, WCFG로 인한 시스템 전체 성능에 안 좋은 영향을 미치기 때문에 상용화에 대한 부정적인 평가를 받고 있습니다. 일례로, IT/개발자 커뮤니티에서 WCFG에 대한 비활성화 방법을 문의하는 글을 쉽게 찾을 수 있을 만큼 사용자에게는 불편한 기능으로 인식됐습니다.
이러한 문제점을 개선하고자 지난 9월 하드웨어 기반의 CFI 기술인 Intel CET(control-flow enforcement technology)이라는 차세대 모바일 프로세서 ‘Tiger Lake’가 출시됐습니다. 하드웨어 기반의 CET 기술로 인해 이전과 비교했을 때 매우 향상된 성능을 제공하고, CFI 기법을 적용하는데 발생하는 구현상의 보안문제를 어느 정도 해결할 수 있지만, 이 또한 근본적인 CFI 기법의 알고리즘 자체의 취약점 문제는 여전히 해결할 수 없습니다.
CFI를 상용화하면서 발생한 문제점을 크게 둘로 나누면 첫 번째, CFI를 구현하면서 발생한 구현상의 취약점, 두 번째, 적용한 CFI 기법 자체의 취약점으로 구분할 수 있습니다. 구현상의 취약점은 하드웨어 기반으로 구현하거나 취약점 패치를 통해 충분히 해결이 가능합니다. 하지만 CFI 기법 자체가 보안적으로 취약한 요인이 내포되어 있다고 한다면 즉, 근본적인 CFI 기법의 보안성을 높이지 못한다면, 상용화된 어떤 CFI 기술도 해킹으로부터 안전하다고 할 수 없습니다.
지난 CFI 관련 칼럼(시스템 보안 향상 위한 제어 흐름 무결성)에서 살펴봤듯이 완벽한 보안을 보증하는 CFI를 만들기는 쉽지 않은 문제입니다. 이론상으로 완전무결한 CFI 기술이 적용되었다면, 해킹이 불가능할까요? 이에 대한 대답은 해킹이 “가능하다” 입니다. 모든 제어 흐름을 보호해서 제어 흐름 공격이 불가능하더라도 제어 흐름을 변경하지 않는 공격이 얼마든지 가능하기 때문입니다. 대표적인 예로, 비제어 데이터 공격(Non-control Data Attack)이 있는데, 이는 정상적인 프로그램의 실행 흐름과 똑같은 제어 흐름을 가지면서, 오직 데이터 값의 변조만으로 해킹을 하는 방식을 말합니다. 제어 흐름 공격에서는 비정상적인 제어 흐름이 나타나는 것이 특징이지만, 비제어 데이터 공격은 정상적인 제어 흐름이 나타나는 것이 특징이기 때문에, CFI 기법으로 보호하더라도 방어할 수 없습니다.
CFI와 해킹의 관계를 조금 달리 생각해 보겠습니다. 이론상으로 완전무결한 CFI를 지원할 수 있다면, 제어 흐름 공격이 불가능할까요? 이 의문의 답 또한 안타깝게도 “가능하다” 입니다. 제어 흐름 공격이 어떻게 가능한지 알아보기 위해 먼저 완전무결한 CFI에 대해 알아보겠습니다. 완전무결한 CFI를 구현하기 위해서 필요한 정확한 CFG(control flow graph)는 다음과 같이 정의할 수 있습니다. 정확한 CFG(precise CFG)는 어떤 간접 제어 흐름 전송에서 악의적인 실행 흐름 즉, 의도된 동작을 벗어나지 않은 실행 흐름이 존재하지 않고 정상적인 실행 흐름만을 따르는 경우를 뜻합니다.
이 정의를 바탕으로 생각해본다면, 정확한 CFG라고 하더라도 간접 제어 흐름 전송에서 실행할 수 있는 여러 개의 경로 후보군이 나타날 수 있습니다. 이들의 후보군은 모두 합법적인 후보로 어느 곳으로 실행되더라도 정상적인 실행 흐름입니다. 예를 들어, 함수 포인터 F가 간접 호출을 통해 A, B로 분기될 수 있을 때, 이 A, B는 정상적으로 프로그램에서 의도된 실행 흐름입니다. 하지만 런타임 시 F의 흐름은 하나의 특정 경로(A 또는 B)로 결정되며, 다른 하나는 악의적인 실행 흐름이 됩니다. 바꿔 말하면 간접 제어 흐름 전송이 실행되는 시점에서는 딱 하나의 실행 흐름을 제외하고 전부 다 거짓이 된다는 것입니다. 정확한 CFG만으로는 악의적인 실행 흐름인지 판단하는 것 자체가 매우 어렵다는 것을 알 수 있습니다. 결론적으로, 이렇게 완전무결한 CFI 기술을 적용하더라도 제어 흐름 공격이 가능한 것을 의미합니다.
▲정동재 KAIST 사이버보안연구센터 악성코드 분석팀 팀장[사진=KAIST]
현재까지 상용화된 CFI 기술 수준과 달리 제어 흐름 공격을 완벽하게 방어할 수 있는 방법이 존재할까요? 더욱 완벽한 제어 흐름을 분석하기 위해서는 어떻게 해야 할까요? 다음 연재에서는 “어떻게 하면 더욱 완전무결한 CFI 기술을 구현할 수 있을까?”라는 주제를 가지고, 간접 제어 흐름 전송에서 특정 경로를 결정짓는 요소에 대해 살펴보고, 이를 바탕으로 정확한 제어 흐름을 판단할 수 있는 방식에 대해 살펴보도록 하겠습니다.
[글_ 정동재 KAIST 사이버보안연구센터 악성코드 분석팀 팀장]
<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>
원병철기자 기사보기
[2024-11-22] .jpg)
.jpg)
.jpg)
.jpg)
.jpg)
