KR102358108B1 - 소스코드 내 cpu 취약점 탐색 방법 - Google Patents

Abstract

본 발명은 소스코드 내 CPU 취약점 탐색 방법에 관한 것으로서, 색인부가 분석대상 소스코드를 색인하여 로드하는 (a) 단계; 분류부가 로드된 소스코드에 포함된 함수들을 기 설정된 단위별로 분류하는 (b) 단계; 분석부가 분류된 함수들 중에 분석 대상 함수가 존재하는지 여부를 판단하는 (c) 단계; (c) 단계의 판단결과, 분석 대상 함수가 존재하는 경우, 분석부가 해당 함수에 배열이 사용되었는지 여부를 판단하는 (d) 단계; (d) 단계의 판단결과, 함수에 배열이 사용된 경우 분석부가 파라미터 중 하나 이상이 배열의 index로 사용되었는지 여부를 판단하는 (e) 단계; (e) 단계의 판단결과, 파라미터가 배열의 index로 사용된 경우, 분석부가 해당 배열이 2중 배열인지 여부를 판단하는 (f) 단계; (f) 단계의 판단결과, 해당 배열이 2중 배열인 경우, 분석부가 해당 파라미터를 data Spectre 후보로 설정하는 (g) 단계를 포함한다.

Description

소스코드 내 CPU 취약점 탐색 방법{CPU vulnerability search method in source code}

본 발명은 소스코드 내 CPU 취약점 탐색 방법에 관한 것으로 더욱 상세하게는, CPU 취약점을 탐색하기 위한 쿼리를 소스코드로 입력받아 CPU 취약점 후보를 탐색하고, 이를 통해 프로그램에 존재할 수 있는 CPU 취약점 후보를 탐색하는 기술에 관한 것이다.

CPU 취약점은 2018년 01월 처음 공개되었고, 2018년 11월에는 다수의 변종 취약점들이 공개되었다. 그리고 2019년 03월에는 Intel spoiler, 2019년 05월에는 Intel MDS, 2019년 08월에는 SWAPGS라는 취약점이 계속해서 공개되고 있다. 따라서 앞으로 몇 년간은 CPU 취약점에 대한 변종이 계속 발견될 것을 예측할 수 있다.

도 1은 CPU 취약점의 변종 기술 흐름을 도시한 도면이다. 2017년 기준으로 국내 6세 이상의 스마트폰 보급률은 89.5%에 달하고 있는바, 대다수의 사람이 CPU를 사용하여 네트워크에 접속하거나 정보를 저장하고 있다.

이러한 스마트폰은 대부분 ARM 아키택쳐 CPU를 사용하고 있는데, ARM 아키택쳐 CPU가 안전하지 않다면 스마트폰 사용자가 위험에 노출되어 있다는 것으로 해석할 수 있다. 따라서, CPU 취약점에 대한 연구를 통해 CPU 취약점 대응 기술을 확보하는 것이 필요하다.

한국공개특허 제10-2019-0105507호(2019.09.17)

본 발명의 목적은, CPU 취약점을 탐색하기 위한 쿼리를 소스코드로 입력받아 CPU 취약점 후보를 탐색하여, 함수 내 배열 사용여부, 배열의 index가 함수의 파라미터인지 여부, 및 배열 index에 배열이 사용되었는지 여부(2중 배열)를 판단하여, 2중 배열일 경우 data Spectre 후보로 저장하고, 2중 배열이 아닌 경우 address Spectre 후보로 저장함으로써, 사전에 프로그램에 존재할 수 있는 CPU 취약점 보완이 가능하게 하는데 있다.

이러한 기술적 과제를 달성하기 위한 본 발명의 소스코드 내 CPU 취약점 탐색 방법은, 색인부가 분석대상 소스코드를 색인하여 로드하는 (a) 단계; 분류부가 로드된 소스코드에 포함된 함수들을 기 설정된 단위별로 분류하는 (b) 단계; 분석부가 분류된 함수들 중에 분석 대상 함수가 존재하는지 여부를 판단하는 (c) 단계; (c) 단계의 판단결과, 분석 대상 함수가 존재하는 경우, 분석부가 해당 함수에 배열이 사용되었는지 여부를 판단하는 (d) 단계; (d) 단계의 판단결과, 함수에 배열이 사용된 경우 분석부가 파라미터 중 하나 이상이 배열의 index로 사용되었는지 여부를 판단하는 (e) 단계; (e) 단계의 판단결과, 파라미터가 배열의 index로 사용된 경우, 분석부가 해당 배열이 2중 배열인지 여부를 판단하는 (f) 단계; (f) 단계의 판단결과, 해당 배열이 2중 배열인 경우, 분석부가 해당 파라미터를 data Spectre 후보로 설정하는 (g) 단계를 포함하는 것을 특징으로 한다.

바람직하게는, (g) 단계의 판단결과, 해당 배열이 2중 배열이 아닌 경우, 분석부가 해당 파라미터를 address Spectre 후보로 설정하는 (h) 단계를 더 포함하는 것을 특징으로 한다.

상기와 같은 본 발명에 따르면, CPU 취약점을 탐색하기 위한 쿼리를 소스코드로 입력받아 CPU 취약점 후보를 탐색하여, 함수 내 배열 사용여부, 배열의 index가 함수의 파라미터인지 여부, 및 배열 index에 배열이 사용되었는지 여부(2중 배열)를 판단하여, 2중 배열일 경우 data Spectre 후보로 저장하고, 2중 배열이 아닌 경우 address Spectre 후보로 저장함으로써, 사전에 프로그램에 존재할 수 있는 CPU 취약점 보완이 가능한 효과가 있다.

도 1은 CPU 취약점의 변종의 기술 흐름을 도시한 도면.
도 2는 CPU의 처리 속도를 높이기 위해 명령어 처리 과정을 5개의 단계로 분리해 동시에 실행하는 CPU 파이프라인을 도시한 예시도.
도 3은 분기 헤저드의 코드를 도시한 예시도.
도 4는 2-bit 분기 예측기를 도시한 예시도.
도 5는 Address tag로 주소 중 일부를 저장하고, 2bit Branch Predictor를 통해 분기를 예측하는 Branch History Table을 도시한 예시도.
도 6은 Address tag에 주소를 넣고 목적지 주소를 가지며 분기를 예측하는 Branch Taget Buffer를 도시한 예시도.
도 7은 캐시 부채널 공격의 예시 1을 도시한 도면.
도 8은 캐시 부채널 공격의 예시 2를 도시한 도면.
도 9는 Prime+Probe 기법을 도시한 예시도.
도 10은 Spectre Variant 1 코드 패턴을 도시한 예시도.
도 11은 CVE-2015-3874 패치 디핑 코드를 도시한 예시도.
도 12는 aacDecoder_AncDataGet() 함수의 코드 패턴을 도시한 예시도.
도 13은 본 발명의 일 실시예에 따른 소스코드 내 CPU 취약점 탐색 시스템을 도시한 블록도.
도 14는 본 발명의 일 실시예에 따른 소스코드 내 CPU 취약점 탐색 방법을 도시한 순서도.

본 발명의 구체적인 특징 및 이점들은 첨부도면에 의거한 다음의 상세한 설명으로 더욱 명백해질 것이다. 이에 앞서, 본 명세서 및 청구범위에 사용된 용어나 단어는 발명자가 그 자신의 발명을 가장 최선의 방법으로 설명하기 위해 용어의 개념을 적절하게 정의할 수 있다는 원칙에 입각하여 본 발명의 기술적 사상에 부합하는 의미와 개념으로 해석되어야 할 것이다. 또한, 본 발명에 관련된 공지 기능 및 그 구성에 대한 구체적인 설명이 본 발명의 요지를 불필요하게 흐릴 수 있다고 판단되는 경우에는, 그 구체적인 설명을 생략하였음에 유의해야 할 것이다.

먼저, 이하, 본 발명의 소스코드 내 CPU 취약점 탐색 시스템의 추측 실행에 대해 살피면 아래와 같다.

현대 CPU에서는 CPU의 처리 속도를 높이기 위해 명령어 처리 과정을 여러 단계로 분리해 동시에 실행하는 파이프라인 기술을 사용하고 있고, 안드로이드 환경에서 사용하는 ARM 아키택처에서도 기본적으로 5단계의 파이프라인을 사용한다. 도 2는 한 클럭에서 여러 명령어가 동시에 처리되는 모습을 도시한 도면이다.

도 2에 도시된 바와 같이, IF, ID, EX, MEM, WB가 5단계의 예시이다. 먼저, IF(instruction Fetch)는 메모리에서 실행할 명령어를 가져오고, ID(Instruction Decode)는 명령어를 CPU에서 사용하는 표현으로 해독한다. 또한, EX(EXecution)는 실제로 명령을 실행하고, MEM(MEMory access)은 메모리에 접근하여 데이터를 읽거나 저장하며, WB(Write Back)는 레지스터에 연산 결과를 저장한다.

파이프라인에서 성능을 떨어트리는 요인을 해저드라고 하는데, 그 중 제어 해저드(분기 명령어 문제)는 분기 명령어의 다음 명령어를 알 수 없어서 생기는 문제이다.

도 3은 분기 헤저드를 도시한 예시 코드를 살피면, 조건문을 실행 중일 때 분기가 완전히 끝나기 전까지 실행흐름을 알 수 없는데, 이처럼 실행흐름을 알 수 없으면 파이프라인은 분기문과 함께 실행시킬 명령어를 고를 수 없다. 따라서, CPU는 분기문이 끝날 때까지 기다리게 되고 이 기다리는 시간만큼 CPU의 성능이 저하된다. 이를 보완하기 위해 나온 기법이 추측실행이다.

추측 실행(Speculative Execution)은 파이프라인의 속도향상을 위해 나온 기법으로 예측 실행 등으로도 불린다. 조건문이 어디로 분기할지 예측하는 분기 예측(Branch prediction)을 사용해서 다음 명령을 추론한 후 이 명령을 미리 실행시킨다.

이때, 분기 예측이 맞으면 파이프라인에서 낭비되는 시간 없이 명령어를 병렬적으로 실행할 수 있다. 반면에, 분기 예측이 틀렸을 경우 미리 실행된 명령어를 모두 취소시킨 후 올바른 명령이 다시 실행되며, 분기 예측이 틀렸을 경우 낭비되는 시간이 크지만 분기가 반복적으로 일어난 경우 다음 실행에도 분기할 확률이 더 높다.

반복문의 경우 반복 횟수만큼 같은 주소로 분기하는 것이 그 예이다. 따라서 추측 실행에 의하면 분기 예측이 맞는 경우가 더 많아 전체적인 파이프라인 성능이 증가하고, 이러한 분기 예측은 크게 직접 분기, 간접 분기, 및 무조건 분기로 나뉘며 예측에는 분기 예측기(Branch Predictor)가 사용된다.

먼저, 직접 분기 예측은, 조건문의 참, 거짓에 따라 분기할 주소가 정해진 것이다. 따라서 직접 분기의 분기 예측은 이전 실행에서 조건문이 참이었는지 거짓이었는지 기억하고 이를 기반으로 다음 실행이 분기를 할지 하지 않을지 예측한다.

이러한 직접 분기 예측을 수행하는 분기 예측기는 명령어 주소와 과거 분기 여부를 기록한 테이블(BHT: Branch History Table)을 통해 분기를 예측한다.

도 4는 2-bit 분기 예측기를 도시한 것으로, 최초 실행시 Weakly Taken 상태에서 실행되며, 분기했을 때(Taken)와, 분기하지 않았을 때 NT(Not Taken) 방향으로 상태가 이동해 모두 4개로 2bit로 표현된다.

또한, 도 5에 도시된 BHT(Branch History Table)는 Address tag로 주소 중 일부를 저장하고, 2bit Branch Predictor를 통해 분기를 예측한다.

한편, 간접 분기 예측은 런타임 환경에서의 결과에 따라 임의의 주소로 분기함에 따라, 직접 분기와 다르게 상태를 2bit로 표현할 수 없어 Address tag에 주소를 넣고 목적지 주소를 가지는 BTB(Branch Taget Buffer)를 사용한다.

이러한 BTB는 도 6에 도시된 바와 같이 Address tag로 34값을 가지고 있는데, 이는 Process1이 분기하는 패턴을 CPU가 기억한 것으로, 이 BTB 값에 의해 Process2가 추측 실행으로 385 주소로 분기하여 코드를 실행하게 된다.

이하, 본 발명의 소스코드 내 CPU 취약점 탐색 시스템의 캐시 부채널 공격에 대해 살피면 아래와 같다.

캐시 부채널 공격(cache side channel attack)은 프로그램의 알고리즘과 무관한 공격 기법을 말한다. CPU가 동작할 때 생기는 전자파, 온도 상승, 전력 소모 등으로 현재 컴퓨터가 동작하고 있는 상태를 추측해낼 수 있다. 그 중에서도 타이밍 어택이 Spectre 등 CPU 취약점에 주로 사용된다.

도 7 및 도 8은 캐시 부채널 공격의 예를 도시한 도면으로, 공격자는 CPU 내부 상태를 알 수 없다. 하지만 캐싱되지 않은 메모리 값을 요청할 경우 반환까지 걸리는 시간이 1000ms가 걸린다고 가정했을 때, 캐싱된 메모리 값을 요청할 경우 도 8과 같이 유독 반환이 빠른 값이 있다. CPU 캐시 값을 볼 수 없더라도 캐시 부채널 공격을 통해 캐싱된 값을 추측해낼 수 있다.

한편, Prime + Probe 기법은 해당 메모리에 접근 권한이 없을 경우 사용하는 공격 기법이다. 도 9에 도시된 바와 같이 공격자는 Process A로 필요한 모든 메모리에 계속 접근한다. 이렇게 되면 CPU의 모든 캐시를 Process A가 점유하게 된다. 희생자인 Process B가 프로세서를 점유하고 메모리를 사용하는 순간 캐시 중 일부가 Process B에 메모리 값으로 변경된다. 이후 Process A가 다시 모든 메모리를 접근하게 되면 유독 반환이 느린 메모리가 생기고 해당 메모리가 Process B에 의해 사용된 메모리 인 것을 알 수 있다.

이하, 본 발명의 소스코드 내 CPU 취약점 탐색 시스템의 Spectre 후보 탐색 응용 기술을 Spectre Variant 1, CVE-2015-3874, 및 aacDecoder_AncDataGet()을 참조하여 살피면 아래와 같다.

먼저, Spectre Variant 1은 Spectre Variant 중 가장 기본이 되는 방식으로 도 10에 도시된 코드 패턴을 갖는다.

사용자가 접근 가능한 변수인 input이 조건문을 통해 검사되고 이것이 배열의 index로 사용되고 있다. 코드로 봤을 때는(소프트웨어적으로) 취약점이 없어 보이지만 추측 실행을 통해 범위 밖의 값을 캐시에 로드할 수 있다. 따라서 조건문을 통한 범위 제한 후 배열에 접근하는 패턴이 기본적인 Spectre Variant 1에 해당한다고 볼 수 있다.

또한, CVE-2015-3874는 sonivox 라이브러리의 코드 중 미디어 파일을 파싱할 때 사용하는 코드에서 out-of-bound 취약점이 있었다. 이를 패치한 CVE-2015-3874은 도 11에 도시된 바와 같다. 여기서, CVE-2015-3874 패치 디핑은 if 문으로 waveIndex 조건을 검사하고 밑에서 wsmpData[waveIndex] 사용하였다.

그리고, 도 12에 도시된 바와 같은 aacDecoder_AncDataGet()는 소스코드 오디팅을 통해 찾은 코드이다. 이 코드에서 index가 파라미터로 들어오면 조건문을 통해 범위를 체크하고, index 변수를 통해 배열에 접근하며, Spectre 트리거에 성공한다면 범위 내의 입력을 지속하여 CPU를 학습시킨 이후 범위 밖의 값을 캐시에 로드할 수 있다.

여기서, 코드패턴은 조건문에서 index를 검사하고 ancData -> offset[index]와 ancData -> Buffer[ancData -> offset[index]] 두가지를 사용한다.

이하, 전술한 바와 같은 소스코드 내 CPU 취약점 탐색 배경을 기반으로 본 발명의 일 실시예에 따른 소스코드 내 CPU 취약점 탐색 시스템에 대해 살피면 아래와 같다.

도 13을 참조하면, 본 발명의 일 실시예에 따른 소스코드 내 CPU 취약점 탐색 시스템(S)은 소스코드를 로드하는 색인부(100)와, 로드된 소스코드 내의 함수를 단위별로 분류하는 분류부(200)와, 분류된 함수를 분석하는 분석부(300)를 포함하여 구성된다.

구체적으로, 색인부(100)는 저장소로부터 기 생성된 소스코드 중에 어느 하나의 분석대상 소스코드를 색인하여 로드하고, 분류부(200)는 로드된 소스코드에 포함된 함수들을 기 설정된 단위별로 분류한다.

그리고, 분석부(300)는 함수 내에 배열이 사용되었는지 여부를 판단하여 분석할 함수가 존재하는 경우, 함수에 배열이 사용되었는지 여부를 판단하고, 배열이 사용된 경우 파라미터 중 하나 이상이 배열의 index로 사용되었는지 여부를 판단한다.

또한, 분석부(300)는 파라미터가 배열의 index로 사용된 경우 해당 배열이 2중 배열인지 여부를 판단하되, 이 판단결과 2중 배열인 경우 해당 파라미터를 data Spectre 후보로 설정하고, 배열의 index로 사용된 파라미터가 2중 배열이 아닌 경우 해당 파라미터를 address Spectre 후보로 설정한다.

이처럼, 본 발명의 일 실시예에 따른 소스코드 내 CPU 취약점 탐색 시스템에 의하면, CPU 취약점을 탐색하기 위한 쿼리를 소스코드로 입력받아 CPU 취약점 후보를 탐색이 가능해 CPU 취약점을 미리 파악하고 대비할 수 있다.

이하, 도 14를 참조하여 본 발명의 일 실시예에 따른 소스코드 내 CPU 취약점 탐색 방법에 대해 살피면 아래와 같다.

먼저, 색인부(100)가 저장소로부터 기 생성된 소스코드 중에 어느 하나의 분석대상 소스코드를 색인하여 로드한다(S1402).

이어서, 분류부(200)가 로드된 소스코드에 포함된 함수들을 기 설정된 단위별로 분류한다(S1404).

뒤이어, 분석부(300)가 분류된 함수들 중에 분석 대상 함수가 존재하는지 여부를 판단한다(S1406).

제S1406단계의 판단결과, 분석 대상 함수가 존재하는 경우, 분석부(300)가 해당 함수에 배열이 사용되었는지 여부를 판단한다(S1408).

제S1408단계의 판단결과, 함수에 배열이 사용된 경우 분석부(300)가 파라미터 중 하나 이상이 배열의 index로 사용되었는지 여부를 판단한다(S1410).

제S1410단계의 판단결과, 파라미터가 배열의 index로 사용된 경우, 분석부(300)가 해당 배열이 2중 배열인지 여부를 판단한다(S1412).

제S1412단계의 판단결과, 해당 배열이 2중 배열인 경우, 분석부(300)가 해당 파라미터를 data Spectre 후보로 설정한다(S1414).

반면에, S1412단계의 판단결과, 해당 배열이 2중 배열이 아닌 경우, 분석부(300)가 해당 파라미터를 address Spectre 후보로 설정한다(S1416).

또한, 제S1406단계의 판단결과, 분류된 함수들 중에 분석 대상 함수가 존재하지 않는 경우, 분석부(300)가 분석을 종료한다.

그리고, 제S1410단계의 판단결과, 파라미터가 배열의 index로 사용되지 않은 경우 분석부(300)가 제S1406단계로 절차를 이행한다.

이처럼, 전술한 바와 같은 본 발명의 일 실시예에 따른 소스코드 내 CPU 취약점 탐색 시스템(S)에 의하면, CPU 취약점을 탐색하기 위한 쿼리를 소스코드로 입력받아 CPU 취약점 후보를 탐색이 가능해 CPU 취약점을 미리 파악하고 대비할 수 있다.

이상으로 본 발명의 기술적 사상을 예시하기 위한 바람직한 실시예와 관련하여 설명하고 도시하였지만, 본 발명은 이와 같이 도시되고 설명된 그대로의 구성 및 작용에만 국한되는 것이 아니며, 기술적 사상의 범주를 일탈함이 없이 본 발명에 대해 다수의 변경 및 수정이 가능함을 당업자들은 잘 이해할 수 있을 것이다. 따라서 그러한 모든 적절한 변경 및 수정과 균등 물들도 본 발명의 범위에 속하는 것으로 간주되어야 할 것이다.

S: 소스코드 내 CPU 취약점 탐색 시스템
100: 색인부
200: 분류부
300: 분석부

Claims (2)

1. aacDecoder_AncDataGet()의 소스코드 패턴의 조건문에서 index를 검사하고 ancData -> offset[index]와 ancData -> Buffer[ancData -> offset[index]] 두가지를 사용하는 소스코드 오디팅을 통해 소스코드 내 CPU 취약점 탐색 방법에 있어서,
   (a) 색인부가 분석대상 소스코드를 색인하여 로드하는 단계;
   (b) 분류부가 로드된 소스코드에 포함된 함수들을 기 설정된 단위별로 분류하는 단계;
   (c) 분석부가 분류된 함수들 중에 조건문에서 배열[index]의 존재 여부를 토대로 분석 대상 함수가 존재하는지 여부를 판단하는 단계;
   (d) 상기 (c) 단계의 판단결과, 분석 대상 함수가 존재하는 경우, 분석부가 해당 함수에 배열이 사용되었는지 여부를 판단하는 단계;
   (e) 상기 (d) 단계의 판단결과, 함수에 배열이 사용된 경우 분석부가 파라미터 중 하나 이상이 배열의 index로 사용되었는지 여부를 판단하는 단계;
   (f) 상기 (e) 단계의 판단결과, 파라미터가 배열 index로 사용된 경우, 분석부가 해당 배열이 2중 배열 index인지 여부를 판단하는 단계;
   (g) 상기 (f) 단계의 판단결과, 해당 배열이 2중 배열 index인 경우, 분석부가 해당 파라미터를 data Spectre 후보로 설정하는 단계를
   포함하는 것을 특징으로 하는 소스코드 내 CPU 취약점 탐색 방법.
   
2. 제1항에 있어서,
   (h) 상기 (g) 단계의 판단결과, 해당 배열이 2중 배열이 아닌 경우, 분석부가 해당 파라미터를 address Spectre 후보로 설정하는 단계를
   더 포함하는 것을 특징으로 하는 소스코드 내 CPU 취약점 탐색 방법.

Images