KR101921052B1

KR101921052B1 - 바이너리에 대한 보안 취약점 및 그 원인 위치의 식별 방법 및 그 장치

Info

Publication number: KR101921052B1
Application number: KR1020170152288A
Authority: KR
Inventors: 김환국; 김태은; 오상환; 윤수진; 전지수; 나건배
Original assignee: 한국인터넷진흥원
Priority date: 2017-11-15
Filing date: 2017-11-15
Publication date: 2018-11-22
Also published as: US10339322B2; US20190147168A1

Abstract

바이너리에 존재하는 취약점 및 그 취약점의 원인이 되는 위치를 판정하는 자동화 된 방법이 제공된다. 본 발명의 일 실시예에 따른 바이너리 취약점 분석 방법은, 분석 대상인 바이너리(binary)의 실행을 통한 테인트 분석(taint analysis)을 수행하여, 상기 바이너리에 대하여 크래쉬(crash)를 유발하는 실행 흐름 경로(execution flow path) 및 상기 실행 흐름 경로 상의 의심 요소(suspicious element)와 관련된 취약점의 기호 제약조건(symbolic constraint)을 기록하는 1차 실행 단계와, 상기 바이너리의 상기 실행 흐름 경로에 대하여 기호 실행(symbolic execution) 방식의 2차 실행을 수행하되, 상기 기호 제약조건을 만족하는 인스트럭션 발견 시, 상기 발견된 인스트럭션과 상기 의심 요소의 비교 결과에 기반하여 상기 바이너리에 상기 취약점이 존재하는 것으로 판정하는 2차 실행 단계를 포함한다.

Description

바이너리에 대한 보안 취약점 및 그 원인 위치의 식별 방법 및 그 장치 {Method and apparatus for identifying security vulnerability and cause point thereof of executable binaries}

본 발명은 바이너리에 대한 보안 취약점 및 그 원인 위치의 식별 방법 및 그 장치에 관한 것이다. 보다 상세하게는, 실행 바이너리(executable binary)에 존재하는 취약점 및 그 취약점의 원인이 되는 위치를 판정하는 자동화 된 방법에 관한 것이다.

소프트웨어는 컴파일이 완료된 후의 결과물인 실행 바이너리(이하, '바이너리'라 함)의 형태로 배포된다. 상기 바이너리가 스토리지 장치에서 메모리에 로드 되고, 상기 메모리에서 상기 바이너리의 일부 인스트럭션이 프로세서에 페치(fetch) 됨으로써, 상기 소프트웨어가 실행된다.

한편, 상기 바이너리에 대한 분석을 통하여 상기 바이너리에 존재하는 취약점(vulnerability)을 파악하기 위한 다양한 방법론이 제시되고 있다. 상기 취약점은, 예를 들어 버퍼 오버플로우(buffer overflow), 정수 오버플로우(integer overflow), 메모리 익셉션(memory exception), 레이스 컨디션(race condition), 기형 입력(Malformed-input), 기호 링크(symbolic link) 및 널 포인터(null pointer) 등 다양한 유형이 알려져 있다. 상기 취약점으로 인하여 상기 바이너리의 일부 기능이 부적절한 목적으로 무단 수정될 수도 있고, 상기 바이너리가 실행되는 시스템에 보안상 문제를 일으킬 수 있으므로, 보안상 중요한 시스템에서 실행되는 바이너리는 신속하고 정확하게 취약점이 식별되어야 할 것이다.

그런데, 현재는 전문가의 지식에 의존하여 바이너리에 존재하는 취약점 및 그 취약점의 원인 위치를 찾고 있는 실정이다. 따라서, 전문가의 개인적인 역량에 따라 취약점이 발견되지 않을 위험도 존재하고, 취약점 및 그 원인 위치를 신속하게 찾기 어렵다.

따라서, 바이너리에 존재하는 취약점 및 그 취약점의 원인이 되는 부분을 자동화 된 방식으로 찾아내는 기술의 제공이 요청된다.

한국등록특허 제10-1530132호

본 발명이 해결하고자 하는 기술적 과제는, 바이너리에 대한 공격을 통하여 취약점을 찾는 것이 아니라, 바이너리 자체에 대한 동적 분석을 통하여 상기 바이너리에 내제된 취약점을 자동화 된 방식으로 식별하는 방법 및 그 장치를 제공하는 것이다.

본 발명이 해결하고자 하는 다른 기술적 과제는, 바이너리에 내제된 취약점을 식별하는데 그치는 것이 아니라, 그 취약점을 야기한 부분까지도 자동화된 방식으로 식별하는 방법 및 그 장치를 제공하는 것이다.

본 발명의 기술적 과제들은 이상에서 언급한 기술적 과제로 제한되지 않으며, 언급되지 않은 또 다른 기술적 과제들은 아래의 기재로부터 본 발명의 기술분야에서의 통상의 기술자에게 명확하게 이해 될 수 있을 것이다.

상기 기술적 과제를 해결하기 위한, 본 발명의 일 실시예에 따른 바이너리 취약점 분석 방법은, 분석 대상인 바이너리(binary)의 실행을 통한 테인트 분석(taint analysis)을 수행하여, 상기 바이너리에 대하여 크래쉬(crash)를 유발하는 실행 흐름 경로(execution flow path) 및 상기 실행 흐름 경로 상의 의심 요소(suspicious element)와 관련된 취약점의 기호 제약조건(symbolic constraint)을 기록하는 1차 실행 단계와, 상기 바이너리의 상기 실행 흐름 경로에 대하여 기호 실행(symbolic execution) 방식의 2차 실행을 수행하되, 상기 기호 제약조건을 만족하는 인스트럭션 발견 시, 상기 발견된 인스트럭션과 상기 의심 요소의 비교 결과에 기반하여 상기 바이너리에 상기 취약점이 존재하는 것으로 판정하는 2차 실행 단계를 포함한다.

일 실시예에서, 상기 2차 실행 단계는, 상기 기호 제약조건을 만족하는 인스트럭션 발견 시, 상기 발견된 인스트럭션이 상기 의심 요소와 같은 위치의 것이라면, 상기 바이너리에 상기 취약점이 존재하는 것으로 판정하는 단계를 포함한다.

일 실시예에서, 상기 2차 실행 단계는, 상기 기호 제약조건을 만족하는 인스트럭션 발견 시, 상기 발견된 인스트럭션이 상기 의심 요소의 피연산자가 실행된 후에 실행된 인스트럭션이라면, 상기 바이너리에 상기 취약점이 존재하는 것으로 판정하는 단계를 포함한다.

일 실시예에서, 상기 2차 실행 단계는, 상기 바이너리의 상기 실행 흐름 경로에 한정하여 상기 2차 실행을 수행하는 단계를 포함한다.

일 실시예에서, 상기 1차 실행 단계는, 상기 테인트 분석의 결과 출력된 정보를 이용하여 테인트 된 요소를 기록하되, 상기 테인트 된 요소는 테인트 된 피연산자, 테인트 된 메모리 주소 및 테인트 된 레지스터를 포함하는 단계와, 상기 테인트 된 요소 중 적어도 일부를 의심 요소로 결정하는 의심 요소 판정 단계를 포함한다. 이 때, 상기 의심 요소 판정 단계는, 상기 바이너리를 수도 코드(pseudo code)로 변환하는 단계와, 상기 변환 된 바이너리의 수도 코드 중 상기 테인트 된 요소에 대응되는 부분 중에서, 기 저장된 의심 수도 코드 패턴에 매치되는 부분의 테인트 된 요소를 의심 요소로 판정하는 단계를 포함하거나, 상기 테인트 된 요소 중에서, 기 저장된 의심 피연산자 패턴에 매치되는 부분의 테인트 된 요소를 의심 요소로 판정하는 단계를 포함하거나, 상기 테인트 된 요소 중에서, 기 저장된 의심 인스트럭션 패턴에 매치되는 부분의 테인트 된 요소의 인스트럭션을 의심 요소로 판정하는 단계를 포함할 수 있다.

일 실시예에서, 상기 1차 실행 단계는, 상기 바이너리의 실행을 위한 실행 파라미터를 이용하여 상기 제1 차 실행을 수행하는 단계와, 상기 실행 파라미터를 이용하여 상기 테인트 분석을 위한 테인트 소스를 세팅하는 단계를 포함할 수 있다. 이 때, 상기 테인트 소스를 세팅하는 단계는, 상기 바이너리의 디버그 심볼(debug symbol)에 "main"이 존재하지 않는 경우, 상기 제1 차 실행 과정에서 상기 실행 파라미터를 로드 하는 위치를 테인트 소스로 세팅하는 단계를 포함할 수 있다.

일 실시예에서, 상기 바이너리 취약점 분석 방법은 상기 크래쉬의 발생에 따라 강제 종료될 때의 피연산자 값인 크래쉬 유발 값의 상기 테인트 분석에 따른 테인트 기록에 따를 때 상기 크래쉬 유발 값이 변화되지 않는 경우, 상기 실행 흐름 경로 상의 상기 강제 종료 지점에서 가장 가까운 의심 요소의 위치를 상기 취약점의 원인 위치로 결정하는 취약점 원인 위치 파악 단계를 더 포함할 수 있다.

일 실시예에서, 상기 위치 파악 단계는, 상기 취약점의 원인 위치의 타입을 상기 강제 종료 지점에서 가장 가까운 상기 크래쉬 유발 값의 변화 지점인 제1 타입과, 상기 강제 종료 지점에서 가장 가까운 의심 요소의 위치인 제2 타입으로 구별하여 출력하는 단계를 포함할 수 있다.

상기 기술적 과제를 해결하기 위한, 본 발명의 다른 실시예에 따른 바이너리 취약점 분석 방법은, 분석 대상인 바이너리(binary)의 실행을 통한 테인트 분석(taint analysis)을 수행하여, 상기 바이너리에 대하여 크래쉬(crash)를 유발하는 실행 흐름 경로(execution flow path) 및 상기 실행 흐름 경로 상의 의심 요소(suspicious element)를 기록하는 단계와, 상기 크래쉬의 발생에 따라 강제 종료될 때의 피연산자 값인 크래쉬 유발 값의 상기 테인트 분석에 따른 테인트 기록에 따를 때 상기 크래쉬 유발 값이 변화되지 않는 경우, 상기 실행 흐름 경로 상의 상기 강제 종료 지점에서 가장 가까운 의심 요소의 위치를 크래쉬 원인 위치로 결정하는 단계를 포함할 수 있다.

상기 기술적 과제를 해결하기 위한, 본 발명의 다른 실시예에 따른 전자 장치는 프로세서와, 상기 프로세서에서 실행 되는 하나 이상의 인스트럭션 및 하나 이상의 분석 대상 바이너리를 저장하는 메모리를 포함할 수 있다. 이 때, 상기 하나 이상의 인스트럭션은, 상기 분석 대상 바이너리에 실행 현황을 파악하는 코드를 삽입 하여 상기 분석 대상 바이너리를 실행하는 제1 인스트럭션과, 분석 대상인 바이너리의 1차 실행을 통한 테인트 분석(taint analysis)을 수행하여, 상기 바이너리에 대하여 크래쉬를 유발하는 실행 흐름 경로에 대한 정보를 출력하는 제2 인스트럭션과, 상기 실행 흐름 경로 상의 의심 요소를 판정하고, 상기 의심 요소와 관련된 취약점의 기호 제약조건을 생성하는 제3 인스트럭션과, 상기 바이너리의 상기 실행 흐름 경로에 대하여 기호 실행 방식의 2차 실행을 수행하고, 상기 기호 제약조건을 만족하는 인스트럭션 발견 시 상기 제3 인스트럭션에 통지하는 제4 인스트럭션을 포함할 수 있다. 이 때, 상기 제3 인스트럭션은 상기 제4 인스트럭션의 통지를 제공 받아 상기 기호 제약조건을 만족하는 피연산자 발견 시, 상기 발견된 피연산자와 상기 의심 요소의 비교 결과에 기반하여 상기 바이너리에 상기 취약점이 존재하는 것으로 판정할 수 있다.

일 실시예에서, 상기 하나 이상의 인스트럭션은, 상기 크래쉬의 발생에 따라 강제 종료될 때의 피연산자 값인 크래쉬 유발 값의 상기 테인트 분석에 따른 테인트 기록에 따를 때 상기 크래쉬 유발 값이 변화되지 않는 경우, 상기 실행 흐름 경로 상의 상기 강제 종료 지점에서 가장 가까운 의심 요소의 위치를 상기 취약점의 원인 위치로 결정하는 제5 인스트럭션을 더 포함할 수 있다.

도 1은 본 발명의 일 실시 예에 따른 바이너리 취약점 분석 시스템의 구조를 도시한 구성도이다.
도 2는 본 발명의 다른 실시예에 따른 바이너리 취약점 분석 장치의 블록 구성도이다.
도 3은 본 발명의 또 다른 실시 예에 따른 바이너리 취약점 분석 방법의 순서도이다.
도 4는 도 3의 제1 실행 관련 동작을 자세히 설명하기 위한 순서도이다.
도 5는 도 4의 일부 동작을 자세히 설명하기 위한 순서도이다.
도 6은 도 4의 일부 동작을 자세히 설명하기 위한 순서도이다.
도 7은 도 3의 제2 실행 관련 동작을 자세히 설명하기 위한 순서도이다.
도 8은 도 3의 취약점 원인 위치 분석 관련 동작을 자세히 설명하기 위한 순서도이다.
도 9는 본 발명의 또 다른 실시예에 따른 바이너리 취약점 분석 방법의 순서도이다.
도 10은 본 발명의 또 다른 실시예에 따른 바이너리 취약점 분석 장치의 하드웨어 구성도이다.

이하, 첨부된 도면을 참조하여 본 발명의 바람직한 실시예들을 상세히 설명한다. 본 발명의 이점 및 특징, 그리고 그것들을 달성하는 방법은 첨부되는 도면과 함께 상세하게 후술되어 있는 실시 예들을 참조하면 명확해질 것이다. 그러나 본 발명은 이하에서 게시되는 실시 예들에 한정되는 것이 아니라 서로 다른 다양한 형태로 구현될 수 있으며, 단지 본 실시 예들은 본 발명의 게시가 완전하도록 하고, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 발명의 범주를 완전하게 알려주기 위해 제공되는 것이며, 본 발명은 청구항의 범주에 의해 정의될 뿐이다. 명세서 전체에 걸쳐 동일 참조 부호는 동일 구성 요소를 지칭한다.

다른 정의가 없다면, 본 명세서에서 사용되는 모든 용어(기술 및 과학적 용어를 포함)는 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자에게 공통적으로 이해될 수 있는 의미로 사용될 수 있다. 또 일반적으로 사용되는 사전에 정의되어 있는 용어들은 명백하게 특별히 정의되어 있지 않는 한 이상적으로 또는 과도하게 해석되지 않는다. 본 명세서에서 사용된 용어는 실시예들을 설명하기 위한 것이며 본 발명을 제한하고자 하는 것은 아니다. 본 명세서에서, 단수형은 문구에서 특별히 언급하지 않는 한 복수형도 포함한다.

이하, 도면들을 참조하여 본 발명의 몇몇 실시예들을 설명한다.

도 1은 본 발명의 일 실시 예에 따른 바이너리 취약점 분석 시스템의 구성도이다. 도 1에 도시된 바와 같이, 본 실시예에 따른 시스템은 서버 역할을 하는 바이너리 취약점 분석 장치(100) 및 클라이언트 역할을 하는 하나 이상의 전자 장치(10a, 10b, 10c, 20)를 포함할 수 있다. 상기 클라이언트는, 스마트 폰, 태블릿, 노트북, PC 등의 사용자 단말(10a, 10b, 10c)일 수 있으나, 다른 서비스를 제공하는 서버 장치(20)일 수도 있는 점을 유의한다.

바이너리 취약점 분석 장치(100) 및 클라이언트 역할을 하는 하나 이상의 전자 장치(10a, 10b, 10c, 20)는 전자 장치로서, 예를 들어 연산 프로세서를 구비한 컴퓨팅 장치일 수 있다.

본 실시예에 따른 시스템에서 클라이언트는 분석이 요구되는 바이너리를 서버(100)에 제공하는 동작을 수행한다. 상기 클라이언트는 서버(100)로부터 분석 결과를 제공 받을 수 있다. 서버(100)는 제공 받은 바이너리를 자동화 된 방식으로 분석하여 바이너리에 내제된 취약점을 식별할 수 있다. 일 실시예에서, 서버(100)는 식별된 취약점의 원인이 되는 위치를 식별할 수도 있다. 또한, 일 실시예에서, 서버(100)는 제공 받은 바이너리의 크래쉬(crash)를 유발하는 원인 위치를 식별할 수도 있다.

본 실시예에 따른 서버(100)는 클라이언트에 의하여 바이너리를 제공 받는 것이 아니라, 스스로 분석 대상 바이너리를 수집할 수도 있음을 유의한다.

서버(100)는 바이너리에 대한 분석 결과를 클라이언트(10a, 10b, 10c, 20)에 제공하거나, 자체적으로 데이터베이스 화 하여 관리할 수 있다.

이하, 도 2를 참조하여 본 발명의 다른 실시예에 따른 바이너리 취약점 분석 장치(100)의 구성 및 동작을 설명한다. 도 2에 도시된 바와 같이, 본 실시예에 따른 바이너리 취약점 분석 장치(100)는 바이너리 실행기(110), 기호 실행기(120), 테인트 분석기(130), 취약점 분류기(140), 의심 요소 DB(160), 취약점 원인 위치 파악기(150) 및 인터페이스(170) 중 적어도 하나를 포함할 수 있다. 인터페이스(170)는 바이너리 취약점 분석 장치(100)에 입력되거나, 바이너리 취약점 분석 장치(100)가 출력되는 것을 중개하는 동작을 수행하는 소프트웨어 또는 하드웨어 모듈을 가리킨다.

바이너리 실행기(110), 기호 실행기(120), 테인트 분석기(130), 취약점 분류기(140), 의심 요소 DB(160) 및 취약점 원인 위치 파악기(150)는 각각 물리적으로 분리된 전용 컴퓨팅 장치로 구성될 수도 있고, 적어도 일부가 소프트웨어 모듈 또는 하드웨어 모듈 부품의 형태로 하나의 컴퓨팅 장치에 함께 구성될 수도 있는 점을 유의한다.

바이너리 실행기(110)는 분석 대상 바이너리를 제공 받고, 제공된 바이너리 파일을 실행시키는 바이너리 실행 모듈(111) 및 바이너리 코드에 바이너리 현황 정보를 파악하는 코드를 삽입(instrumentation)하는 바이너리 현황 파악 코드 삽입 모듈(112)을 포함한다.

바이너리 실행 모듈(111)은 상기 제공된 바이너리를 환경에 맞춰 실행시켜준다. 바이너리 실행 모듈(111)은 상기 제공된 바이너리와 함께 제공된 실행 파라미터를 이용하여 상기 제공된 바이너리를 실행시킬 수 있다. 상기 실행 파라미터는 크래쉬(crash)를 유발하는 것으로 확인 된 것으로서, 바이너리의 실행 시 바이너리 내부 로직에 유입되는 데이터이다.

바이너리 현황 파악 코드 삽입 모듈(112)은 바이너리 제어 및 정보 취득을 위한 'Binary Code Instrumentation' 기능을 제공한다. 상기 바이너리에 삽입되는 코드는, 제공된 바이너리의 실행에 따른 내부 상황을 출력하는 역할을 수행한다.

테인트 분석기(130)는 어떤 요소로부터 다른 요소들이 영향을 받는지 여부를 파악하여 의심스러운 요소에 의해 오염(Taint, 영향을 받음)이 된 경우를 이용하여 문제의 원인 및 영향력을 파악하는 테인트 분석을 수행한다. 테인트 분석의 방법은 공지된 다양한 기술이 차용될 수 있다. 테인트 분석과 관련하여, 문헌 "http://valgrind.org/docs/newsome2005.pdf", "https://en.wikipedia.org/wiki/Taint_checking" 등 다양한 공지 문헌들이 참조될 수 있다.

테인트 분석기(130)는 테인트 분석을 수행하는 메인 로직인 테인트 엔진(131) 및 기존의 Taint 방식으로는 탐지 되지 않는 패턴에 대응하기 위하여 적합화 된 방식을 적용하기 위한 테인트 옵티마이저(optimizer)(132)를 포함할 수 있다. 기존 테인트 엔진에서는 어셈블리 코드의 Source(이하, 테인트 소스)와 Destination가 연결된 경우에만 오염되었다고 판단하였다. 테인트 옵티마이저(132)는 오염된 요소를 조건문으로 사용하고 해당 조건문에 의해 영향을 받는 요소도 오염으로 처리하도록 적합화 방식을 적용하기 위한 로직을 수행한다. 상기 적합화 방식에 대한 자세한 설명은 논문 'DTA++: dynamic taint analysis with targeted control-flow propagation'을 참고 한다. 상기 테인트 소스는 상기 분석 대상 바이너리의 실행 파라미터를 로드 하는 부분일 수 있다. 상기 테인트 소스를 세팅하는 방법은 후술한다.

취약점 분류기(140)는 상기 분석 대상 바이너리의 예상 취약점을 판정 한다. 취약점 분류기(140)는 의심 요소 확인 모듈(Suspicious Element Checker)(141), 기호 제약조건 생성기(Symbolic Constraint Generator)(142) 및 취약점 판정 모듈(143)을 포함할 수 있다.

취약점 분류기(140)는 테인트 분석기(130)로부터 상기 분석 대상 바이너리의 테인트 분석 결과를 제공받고, 제공 된 테인트 분석 결과를 재분석하며, 재분석 결과를 이용하여 상기 분석 대상 바이너리의 취약점을 식별하기 위한 2차 실행의 조건을 설정하며, 상기 설정된 조건을 기호 실행기(120)에 제공한다. 즉, 상기 2차 실행은 기호 실행기(120)가 주가 되어 수행된다.

도 2에 도시된 각각의 요소(110, 120, 130, 140, 150, 160, 170)는, 실제 실행 될 때 상호 연동되면서 동작하기 때문에, 다른 모듈보다 반드시 먼저 실행되어서 종료되거나 후에 실행되는 형태는 아니다. 특히, 취약점 분류기(140)는 일종의 서비스 데몬(daemon)과 유사한 역할을 수행한다.

의심 요소 확인 모듈(141)은 크래쉬를 유발하는 실행 파라미터의 로드 위치를 이용하여 세팅 된 테인트 소스로부터 테인트 된 요소(피연산자, 메모리 주소, 레지스터 포함)가 기존에 알려진 취약점에 매치 되는지 여부를 판정한다. 구체적으로, 의심 요소 확인 모듈(141)은 악용 가능성이 있는 피연산자(operand) 유무, 피연산자 패턴, 인스트럭션(instruction) 및 수도(Pseudo) 코드 패턴 중 적어도 하나를 기준으로 테인트 된 요소가 의심 요소인지 여부를 판정한다. 수도 코드는 분석 대상 바이너리의 어셈블리 언어를 수도 코드로 변환 가능할 경우 분석된다. 의심 요소 확인 모듈(141)은 의심 요소 DB(160)로부터 기존에 알려진 취약점에 대한 정보를 얻을 수 있다.

기호 제약조건 생성기(142)는 의심 요소 확인 모듈(141)에 의하여 판정된 의심 요소에 대응되는 취약점을 파악할 수 있는 기호 제약조건(symbolic constraint)을 설정하여 기호 실행기(120)에 제공한다. 상기 기호 제약조건은 기호 실행(symbolic execution)의 실행 대상 실행 흐름 경로(execution flow path)에 조건식을 부여하는 것이다.

기호 실행기(120)는 상기 분석 대상 바이너리를 기호 실행한다. 기호 실행이란 바이너리에서 쓰이는 값을 특정 값(concrete value)이 아닌 기호(symbol)로 대체하여 실행하는 것을 가리킨다. 이는, 수식에서 미지수를 이용하여 수식을 전개하는 것과 비슷하다. 기호 실행 엔진(121)은 바이너리 실행 과정에서 기호로 값 들을 대체한다. 따라서, 상기 분석 대상 바이너리에 포함된 조건문(conditional statement) 등에서 기호에 따른 분기 조건이 파악된다. SOLVER(122)는 특정 실행 흐름 경로에 따른 기호의 값을 구한다.

간단한 바이너리가 아니라면, 기호 실행기(120)가 상기 바이너리의 모든 가능한 실행 흐름 경로에 대하여 그 기호의 값을 구하는 것은 상당한 컴퓨팅 자원을 요구한다. 본 실시예의 바이너리 취약점 분석 장치(100)는 분석 대상 바이너리의 모든 가능한 실행 흐름 경로를 확인할 필요는 없다. 크래쉬가 발생하는 실행 파라미터에 따른 실행 흐름 경로를 확인하기만 하면 된다. 그리고, 이러한 실행 흐름 경로는 테인트 분석기(130)의 테인트 기록이 가리킨다. 따라서, 기호 실행기(120)는 테인트 기록이 가리키는 실행 흐름 경로에 한하여 기호 실행을 수행하고, 그 기호 실행 과정에서, 취약점 분류기(140)가 제공하는 기호 제약조건을 만족하는 인스트럭션이 발견되는지 확인한다. 상기 기호 제약조건을 만족하는 인스트럭션이 발견되면, 기호 실행기(120)는 취약점 분류기(140)에 이를 통지한다. 취약점 분류기(140)의 취약점 판정 모듈(143)은 기호 실행기(120)로부터 상기 통지를 제공 받고, 분석 대상 바이너리에 상기 취약점이 존재하는지 여부를 판정한다.

이하, 취약점 판정의 순차적 과정에 대하여 상세히 설명한다.

분석 대상 바이너리에 크래쉬를 유발하는 실행 파라미터를 입력하면, 제1 실행 흐름 경로로 실행이 이뤄지는 점을 상기 테인트 기록을 통하여 확인할 수 있고, 상기 제1 실행 흐름 경로에 존재하는 제1 의심 요소가 의심 요소 확인 모듈(141)에 의하여 확인된다. 의심 요소 확인 모듈(141)은 의심 요소 DB(160)의 기 알려진 취약점 관련 정보를 참조한다.

상기 제1 의심 요소에 대응되는 취약점 역시 의심 요소 DB(160)에 매칭되어 저장되어 있다. 상기 제1 의심 요소의 취약점이 버퍼 오버플로우인 것으로 가정하면, 기호 제약조건 생성기(142)가 상기 제1 실행 흐름 경로에서 버퍼 오버플로우가 발생되는 기호 제약조건을 생성한다.

그 후, 기호 실행기(120)는 상기 제1 실행 흐름 경로에 따른 기호 실행을 실행하되, 상기 기호 제약조건이 만족되는 피연산자가 발견되면, 취약점 판정 모듈(143)에 이를 통지한다.

버퍼 오버플로우가 발생되는 기호 제약조건을 만족시키는 인스트럭션이 발견되었다는 것은, 상기 분석 대상 바이너리에 버퍼 오버플로우의 취약점이 존재할 개연성이 존재한다는 것이다. 취약점 판정 모듈(143)은 상기 기호 제약조건을 만족하는 인스트럭션과 상기 제1 의심 요소 간의 비교를 통하여, 상기 분석 대상 바이너리에 버퍼 오버플로우의 취약점이 존재하는지 여부를 최종 판정한다.

예를 들어, 취약점 판정 모듈(143)은 상기 기호 제약조건을 만족하는 인스트럭션과 상기 제1 의심 요소가 같은 위치의 것인 경우, 상기 분석 대상 바이너리에 버퍼 오버플로우의 취약점이 존재하는지 여부를 최종 판정할 수 있다. 또한, 예를 들어, 취약점 판정 모듈(143)은 상기 기호 제약조건을 만족하는 인스트럭션이 상기 제1 의심 요소가 실행 된 후의 것인 경우, 상기 분석 대상 바이너리에 버퍼 오버플로우의 취약점이 존재하는지 여부를 최종 판정할 수 있다.

취약점 원인 위치 파악기(150)는 취약점의 원인 위치를 파악한다. 취약점 원인 위치 파악기(150)는 테인트 분석기(130)에 의한 테인트 분석과 기호 실행기(120)에 의한 기호 실행이 종료되면 해당 결과를 가지고 취약점의 위치를 파악한다.

취약점 분류기(140)는 분석 대상 바이너리에 포함된 것으로 판정된 취약점에 대한 정보를 인터페이스(170)를 통해 출력할 수 있다.

예를 들어, 취약점 원인 위치 파악기(150)는 크래쉬가 발생된 위치와 관련된 테인트 피연산자를 파악하고 상기 테인트 피연산자의 값이 상기 크래쉬를 유발한 값(테인트 분석을 위한 1차 실행에서 크래쉬 발생으로 강제 종료될 때의 피연산자, 레지스터 등의 값)으로 변화하는 시점을 상기 취약점의 위치로 파악한다.

또한, 예를 들어, 취약점 원인 위치 파악기(150)는 상기 크래쉬를 유발한 값의 파악이 안 되거나, 상기 크래쉬를 유발한 값의 변화가 포착되지 않는 경우에는 상기 크래쉬에 의한 상기 크래쉬 발생 시의 실행 흐름 경로 상에서 강제 종료 위치로부터 가장 가까운 의심 요소(의심 요소 확인 모듈(141)에 의하여 식별된)의 위치를 상기 취약점의 원인 위치로 파악할 수도 있다. 취약점 원인 위치 파악기(150)는 파악된 결과, 즉 취약점 원인 위치 관련 정보를 인터페이스(170)를 통해 출력할 수 있다.

다음으로, 도 3 내지 도 8을 참조하여, 본 발명의 다른 실시예에 따른 바이너리 취약점 분석 방법을 설명한다. 본 실시예에 따른 바이너리 취약점 분석 방법은 전자 장치에 의하여 수행될 수 있다. 상기 전자 장치는, 예를 들어 컴퓨팅 장치일 수 있다. 상기 컴퓨팅 장치는, 예를 들어 도 1 내지 도 2를 참조하여 설명한 바이너리 취약점 분석 장치일 수 있다. 상기 바이너리 취약점 분석 방법에 도 1 내지 도 2를 참조하여 설명한 바이너리 취약점 분석 장치의 동작이 적어도 일부 포함될 수 있음을 유의한다. 따라서, 이하 설명되는 바이너리 취약점 분석 방법에 대한 설명에서 별도의 개시가 없더라도, 도 1 내지 도 2를 참조하여 설명한 바이너리 취약점 분석 장치의 동작이 상기 바이너리 취약점 분석 방법에 포함될 수 있다. 또한, 이하 상기 방법에 대한 설명에서, 동작의 주체에 대한 기재가 존재하지 않는 경우, 상기 주체는 상기 바이너리 취약점 분석 장치로 해석될 수 있다.

먼저, 도 3을 참조하여, 본 실시예에 따른 전체적인 동작을 개괄적으로 설명한다.

단계 S100에서, 분석 대상인 바이너리를 1차 실행한다. 이 때, 상기 바이너리에 대한 실행 파라미터로서, 상기 바이너리에 크래쉬를 야기한 실행 파라미터가 입력된다. 이 때, 상기 실행 파라미터를 테인트 소스로 하는 테인트 분석의 결과인 테인트 기록 및 상기 실행의 실행 흐름 경로 상에 존재하는 것으로 판정된 의심 요소가 출력된다. 또한, 상기 의심 요소에 대응되는 취약점에 대한 기호 제약조건이 출력된다. 상기 1차 실행은 도 2의 바이너리 실행기(110), 테인트 분석기(130) 및 취약점 분류기(140)에 의하여 수행될 수 있을 것이다. 이 동작에 대하여는 도 4 내지 도 6을 참조하여 자세히 후술한다.

단계 S200에서, 상기 바이너리를 2차 실행하되, 상기 1차 실행에서 출력된 테인트 기록을 이용하여 상기 1차 실행의 실행 흐름 경로에 한정하여 기호 실행한다. 또한, 상기 기호 실행의 과정에서, 상기 1차 실행에서 출력된 기호 제약조건을 만족하는 인스트럭션이 발견되는 경우, 상기 인스트럭션과 상기 1차 실행에서 출력된 의심 요소 간의 비교 결과에 기반하여 상기 바이너리에 상기 기호 제약조건을 만족하는 인스트럭션이 발견된 취약점이 존재하는지 여부를 최종 판정한다. 상기 1차 실행은 도 2의 바이너리 실행기(110), 기호 실행기(120) 및 취약점 분류기(140)에 의하여 수행될 수 있을 것이다. 이 동작에 대하여는 도 7을 참조하여 자세히 후술한다.

단계 S300에서, 상기 1차 실행의 결과 및 상기 2차 실행의 결과 중 적어도 하나를 이용하여, 취약점의 원인 위치를 결정한다. 이 동작에 대하여는 도 8을 참조하여 자세히 후술한다.

다음으로, 도 4를 참조하여 S100 단계를 보다 상세히 설명한다.

단계 S101에서, 분석 대상인 바이너리를 상기 바이너리의 크래쉬를 유발하는 실행 파라미터를 이용하여 실행시킨다. 이 때, 테인트 분석을 수행하기 위하여 테인트 소스를 세팅한다(S103). 상기 테인트 소스가 상기 바이너리의 실행 과정에서 다른 피연산자 등에 테인트 되는 과정이 추적되고, 그 결과는 테인트 기록으로서 기록되거나 출력될 것이다. 이하, 테인트 소스의 세팅 동작을 도 5를 참조하여 설명한다.

본 실시예에서, 테인트 소스의 세팅은 분석 대상인 바이너리의 디버그 심볼(debug symbol)에 "main" 심볼이 존재하는지 여부에 따라 달라진다. 즉, 상기 바이너리의 디버그 심볼에 "main"이 존재하는 경우(S1030), 테인트 소스는 "main" 심볼에 대응 되는 인스트럭션들 중 실행 파라미터를 불러오는(즉, load 하는) 인스트럭션의 위치(즉, 주소)로 세팅된다(S1032).

즉, 상기 바이너리의 디버그 심볼에 "main"이 존재하지 않는 경우(S1030), 상기 바이너리의 어느 부분에서 실행 파라미터를 불러올지 상기 바이너리의 실제 실행 전에는 알기 어렵다. 따라서, 이 경우에는 상기 바이너리의 실행 과정에서, 최초로 외부 값을 불러오는 인스트럭션의 위치를 상기 테인트 소스로 세팅한다(S1034). 최초로 외부 값을 불러온다면, 그 외부 값이 바로 실행 파라미터일 가능성이 높기 때문이다. 다시 도 4로 돌아가서 설명한다.

단계 S105에서, 상기 바이너리의 인스트럭션을 순서대로 하나씩 실행하면서, 실행된 인스트럭션에 포함된 피연산자가 이전 실행된 피연산자로부터 테인트 되는지 여부를 확인한다(S107). 실행된 피연산자가 테인트 되는 경우에 한하여 분석 대상이 된다. 따라서, 테인트 된 피연산자 또는 레지스터와 그 관련 인스트럭션의 메모리 주소를 기록한다(S109). 이러한 기록의 결과, 테인트 소스로부터의 테인트 기록이 아래의 표 1과 같이 생성된다.

단계 S111에서, 테인트 된 피연산자를 포함하는 인스트럭션 각각에 대하여는 의심 요소에 해당하는지 여부를 판정한다. 이 과정은, 예를 들어 의심 요소 확인 모듈(141)에 의하여 수행될 수 있다. 이하, 도 6을 참조하여 의심 요소 해당 여부 판정 과정에 대하여 자세히 설명한다.

단계 S1110에서, 의심 인스트럭션 패턴, 의심 피연산자 패턴 및 의심 수도(pseudo) 코드 패턴 중 적어도 하나를 의심 요소 DB에서 불러온다. 상기 의심 요소 DB에는 각각의 취약점 타입 별로 사전에 파악된 의심 인스트럭션 패턴, 의심 피연산자 패턴, 의심 수도 코드 패턴이 매칭되어 저장되어 있다.

단계 S1111에서, 상기 바이너리가 수도 코드로 변환 가능한지 확인한다. 변환이 가능할 경우 상기 바이너리를 수도 코드로 변환한다(S1112). 다음으로, 단계 S1113에서, 테인트 된 피연산자를 포함하는 인스트럭션에 대응되는 부분이 상기 의심 수도 코드 패턴과 일치하는지 판정되고, 일치하는 것으로 판정된 경우, 의심 수도 코드 패턴에 일치하는 부분을 의심 요소로 기록한다(S1114).

단계 S1115에서, 테인트 된 피연산자에 대응되는 부분이 상기 의심 피연산자 패턴과 일치하는지 판정되고, 일치하는 것으로 판정된 경우, 의심 피연산자 패턴에 일치하는 부분을 의심 요소로 기록한다(S1116).

단계 S1117에서, 테인트 된 피연산자에 대응되는 인스트럭션이 상기 의심 인스트럭션 패턴과 일치하는지 판정되고, 일치하는 것으로 판정된 경우, 테인트 된 피연산자에 대응되는 인스트럭션을 의심 요소로 기록한다(S1118). 의심 인스트럭션 패턴은, 예를 들어 "mov ecx, A"와 같은 인스트럭션에 있어서 A가 기 지정된 한계치를 초과하는 것일 수 있다. ecx 레지스터는 인덱스 조회에 많이 사용되는 레지스터인데, 그 인덱스 값으로 일반적이지 않은 큰 값이 입력되는 것은 문제 될 수 있는 인스트럭션이 될 것이다.

단계 S1119에서, 테인트 된 요소 중 아직 검사가 수행되어야 하는 부분이 있다면 그 부분으로 이동하고, 테인트 된 요소를 모두 검사 했다면 의심 요소 체크 동작이 종료된다.

다시 도 4로 돌아와서 설명한다. 테인트 된 피연산자를 포함하는 인스트럭션을 포함하는 일련의 인스트럭션이 의심 요소인 것으로 단계 S111에서 판정된 경우, 상기 의심 요소를 기록하고, 상기 의심 요소에 관련된 취약점을 상기 의심 요소 DB에서 조회한다(S113). 상기 바이너리 전체적으로 복수개의 의심 요소가 확인 될 수 있고, 의심 요소, 의심 요소의 위치(즉, 메모리 주소) 및 관련 취약점이 매치 되어 기록된다. 아래의 표 2는 의심 요소의 기록 예시이다.

의심 요소	의심 요소 위치	관련 취약점
strcpy	0x400x02	Buffer Overflow
Call malloc	0x400c5e	Memory Exception

단계 S115에서, 상기 기록된 의심 요소의 기호 제약조건(symbolic constraint가 조회되고 기록된다.

일 실시예에서, 상기 기호 제약조건은 상기 기록된 의심 요소의 관련 취약점과 일대일 대응하는 것일 수 있다. 예를 들어, 상기 기록된 의심 요소의 관련 취약점이 Null Pointer 오류인 경우, 그 기호 제약조건은 아래와 같다.

pc>higher_boundary_binary|pc<higher_boundary_binary&last_memory==null

상기 기호 제약조건은 pc값이 바이너리 실행 가능 영역의 밖을 가리키고, 마지막으로 접근한 메모리가 null 값인 것을 의미한다.

다른 실시예에서, 상기 기호 제약조건은 상기 기록된 의심 요소의 관련 취약점과 상기 기록된 의심 요소 및 상기 기록된 의심 요소의 위치에 따른 실행 흐름 경로를 모두 고려하여 생성되는 것일 수도 있다.

단계 S117에서, 상기 바이너리에 대하여 더 이상 실행할 인스트럭션이 존재하지 않는 경우, 기록된 의심 요소 및 기호 제약조건에 대한 데이터를 출력한다.

다음으로, 도 7을 참조하여 단계 S200의 2차 실행 단계를 상세히 설명한다.

단계 S201에서 분석 대상 바이너리 및 실행 파라미터를 제공받고, 단계 S203에서 1차 실행의 결과 출력된 의심 요소 별 기호 제약조건을 기호 실행기에 설정한다. 즉, 복수의 기호 제약조건이 병렬적으로 기호 실행기에 설정될 수 있다.

단계 S205에서 인스트럭션을 하나씩 기호 실행한다. 이미 설명한 바와 같이, 기호 실행 과정에서, 상기 분석 대상 바이너리의 모든 가능한 실행 흐름 경로를 확인할 필요는 없다. 따라서, 1차 실행의 결과로 출력된 테인트 기록이 가리키는 실행 흐름 경로에 한하여 기호 실행을 수행하고, 그 기호 실행 과정에서, 상기 설정된 기호 제약조건을 만족하는 인스트럭션이 발견되는지 확인할 수 있다.

기호 실행 과정에서, 설정된 기호 제약조건들 중 하나를 만족하는 인스트럭션이 발견되면(S207), 상기 발견된 인스트럭션과 기록된 의심 요소 간의 비교 결과에 기반하여 분석 대상 바이너리에 존재하는 취약점을 판정한다(S207). 일 실시예에서, 상기 기호 제약조건을 만족하는 인스트럭션 발견 시, 상기 발견된 피연산자가 상기 의심 요소와 같은 위치의 것이라면, 상기 바이너리에 상기 취약점이 존재하는 것으로 판정할 수 있다. 다른 실시예에서, 상기 발견된 인스트럭션이 상기 의심 요소가 실행된 후에 실행된 피연산자라면, 상기 바이너리에 상기 취약점이 존재하는 것으로 판정할 수 있다.

단계 S211에서, 상기 바이너리에 대하여 더 이상 실행할 인스트럭션이 존재하지 않는 경우, 상기 바이너리에 존재하는 것으로 판정된 취약점에 대한 정보를 출력하고, 2차 실행 과정을 종료한다.

다음으로, 도 8을 참조하여 취약점 원인 위치 식별 단계를 상세히 설명한다.

단계 S301에서, 1차 실행 과정에서 크래쉬로 인한 강제 종료 위치(즉, 강제 종료된 인스트럭션의 메모리 주소)에서 크래쉬를 유발한 값을 조회한다. 이때 테인트 분석 중에 강제 종료되는 경우에 기록된 값을 이용할 수 있다.

단계 S303에서, 상기 테인트 분석에 의하여 생성된 테인트 기록을 실행 역순으로 재정렬한다. 그 결과, 크래쉬 유발 값이 재정렬된 테인트 기록의 맨 앞에 위치할 것이다. 본 동작은 반드시 필요한 동작은 아니나 조회 과정에서 편리하게 크래쉬 유발 값의 변화 추이를 확인할 수 있도록 한다.

단계 S305에서, 크래쉬 유발값의 변화 추이를 추적한다. 상기 크래쉬 유발 값의 변화가 확인 된 경우(S307), 취약점의 원인 위치는 상기 재정렬 된 테인트 기록 상 상기 크래쉬 유발 값이 최초로 변화된 위치로 세팅된다(S309).

반면에, 상기 크래쉬 유발 값의 변화가 확인되지 않거나, 또는 상기 크래쉬 유발 값을 확인할 수 없는 경우에는, 상기 취약점 원인 위치는 상기 1차 실행 결과에 따른 실행 흐름 경로 상에서 상기 강제 종료 위치에 가장 가까운(즉, 상기 재정렬 된 테인트 기록에서 가장 앞에 위치한) 의심 요소의 위치로 세팅 된다(S311). 이 경우는 크래쉬가 특정 값 때문이 아니라, 상기 의심 요소의 행위 자체에 의하여 발생된 것으로 가정하는 것이다.

취약점의 원인 위치에 대한 정보가 출력될 때, 의심 원인 파악 방법(1: backward trace(단계 S309에 따른 것), 2: suspicious element location(단계 S311에 따른 것))과, 의심 원인 위치와 관련된 취약점의 종류에 대한 정보가 매치되어 출력될 수 있다.

예를 들어, 크래쉬 유발 값 변화를 역추적하여 Integer Overflow 취약점의 원인 위치 발견한 경우, 아래의 정보가 출력될 수 있다. 아래의 정보는 순서대로 [의심 원인 파악 방법, 취약점 원인 위치, 취약점 종류]를 가리킨다.

[1, 0x40012b, Integer Overflow]

다음으로, 도 9를 참조하여 본 발명의 또 다른 실시예에 따른 바이너리 취약점 분석 방법을 설명한다. 본 실시예에 따른 바이너리 취약점 분석 방법은 크래쉬의 원인 위치에 대한 데이터를 출력한다. 본 실시예에 따른 바이너리 취약점 분석 방법은, 크래쉬의 원인 위치만 판정하는 것으로서, 테인트 분석을 위한 1차 실행 및 상기 테인트 분석에 따른 테인트 기록을 이용한 크래쉬 원인 위치 파악을 포함할 수 있다.

단계 S400에서, 분석 대상인 바이너리(binary)의 실행을 통한 테인트 분석(taint analysis)을 수행하여, 상기 바이너리에 대하여 크래쉬(crash)를 유발하는 실행 흐름 경로(execution flow path) 및 상기 실행 흐름 경로 상의 의심 요소(suspicious element)를 기록한다. 본 단계의 동작은 도 4를 참조하여 설명된 방법이 일부 적용될 수 있음을 유의한다.

단계 S500에서, 상기 크래쉬의 발생에 따라 강제 종료될 때의 피연산자 값인 크래쉬 유발 값의 상기 테인트 분석에 따른 테인트 기록에 따를 때 상기 크래쉬 유발 값이 변화되지 않는 경우, 상기 실행 흐름 경로 상의 상기 강제 종료 지점에서 가장 가까운 의심 요소의 위치를 크래쉬 원인 위치로 결정한다. 본 단계의 동작은 도 8을 참조하여 설명된 방법이 일부 적용될 수 있음을 유의한다.

다음으로, 도 10을 참조하여 본 발명의 또 다른 실시예에 따른 바이너리 취약점 분석 장치의 구성 및 동작을 설명한다. 도 10에 도시된 바와 같이, 본 실시예에 따른 취약점 분석 장치(100)는 프로세서(101) 및 메모리(102)를 포함하고, 몇몇 실시예들에서 스토리지(103), 네트워크 인터페이스(105) 및 시스템 버스(104) 중 적어도 하나를 더 포함할 수 있다. 메모리(102)에 로드 되어 저장되는 하나 이상의 인스트럭션은 프로세서(101)를 통하여 실행된다. 본 실시예에 따른 바이너리 취약점 분석 장치(100)는 별도의 설명이 없더라도, 도 1 내지 도 2를 참조하여 설명한 바이너리 취약점 분석 장치 관련 동작 및 도 3 내지 도 9를 참조하여 설명한 바이너리 취약점 분석 방법 관련 동작을 수행할 수 있는 점을 유의한다.

네트워크 인터페이스(105)는 외부 장치로부터 네트워크를 통해 제공 된 분석 대상 바이너리(130a)를 수신하고, 수신된 분석 대상 바이너리(130a)가 스토리지(103)에 저장되도록 할 수 있다.

상기 하나 이상의 인스트럭션은, 상기 분석 대상 바이너리에 실행 현황을 파악하는 코드를 삽입 하여 분석 대상 바이너리(130a)를 메모리에 로드(130b)하여 실행하는 바이너리 실행 인스트럭션(110a), 분석 대상인 바이너리의 1차 실행을 통한 테인트 분석(taint analysis)을 수행하여, 상기 바이너리에 대하여 크래쉬를 유발하는 실행 흐름 경로에 대한 정보를 출력하는 테인트 분석 인스트럭션(130a), 상기 실행 흐름 경로 상의 의심 요소를 판정하고, 상기 의심 요소와 관련된 취약점의 기호 제약조건을 생성하는 취약점 분류 인스트럭션(140a), 및 상기 바이너리의 상기 실행 흐름 경로에 대하여 기호 실행 방식의 2차 실행을 수행하고, 상기 기호 제약조건을 만족하는 인스트럭션 발견 시 상기 제3 인스트럭션에 통지하는 기호 실행 인스트럭션(120a)을 포함할 수 있다.

일 실시예에서, 취약점 분류 인스트럭션(140a)은 스토리지(103)에 저장된 의심 요소 DB(160)를 이용하여 상기 실행 흐름 경로 상의 의심 요소를 판정한다.

일 실시예에서, 취약점 분류 인스트럭션(140a)은 상기 제4 인스트럭션의 통지를 제공 받아 상기 기호 제약조건을 만족하는 인스트럭션 발견 시, 상기 발견된 인스트럭션과 상기 의심 요소의 비교 결과에 기반하여 상기 바이너리에 상기 취약점이 존재하는 것으로 판정할 수 있다.

일 실시예에서, 상기 하나 이상의 인스트럭션은 상기 크래쉬의 발생에 따라 강제 종료될 때의 피연산자 값인 크래쉬 유발 값의 상기 테인트 분석에 따른 테인트 기록에 따를 때 상기 크래쉬 유발 값이 변화되지 않는 경우, 상기 실행 흐름 경로 상의 상기 강제 종료 지점에서 가장 가까운 의심 요소의 위치를 상기 취약점의 원인 위치로 결정하는 취약점 원인 위치 파악 인스트럭션(150a)을 더 포함할 수 있다.

지금까지 설명된 본 발명의 실시예에 따른 방법들은 컴퓨터가 읽을 수 있는 코드로 구현된 컴퓨터프로그램의 실행에 의하여 수행될 수 있다. 상기 컴퓨터프로그램은 인터넷 등의 네트워크를 통하여 제1 컴퓨팅 장치로부터 제2 컴퓨팅 장치에 전송되어 상기 제2 컴퓨팅 장치에 설치될 수 있고, 이로써 상기 제2 컴퓨팅 장치에서 사용될 수 있다. 상기 제1 컴퓨팅 장치 및 상기 제2 컴퓨팅 장치는, 서버 장치, 클라우드 서비스를 위한 서버 풀에 속한 물리 서버, 데스크탑 피씨와 같은 고정식 컴퓨팅 장치를 모두 포함한다.

상기 컴퓨터프로그램은 DVD-ROM, 플래시 메모리 장치 등의 기록매체에 저장된 것일 수도 있다.

이상 첨부된 도면을 참조하여 본 발명의 실시예들을 설명하였지만, 본 발명이 속하는 기술분야에서 통상의 지식을 가진 자는 본 발명이 그 기술적 사상이나 필수적인 특징을 변경하지 않고서 다른 구체적인 형태로 실시될 수 있다는 것을 이해할 수 있다. 그러므로 이상에서 기술한 실시예들은 모든 면에서 예시적인 것이며 한정적인 것이 아닌 것으로 이해해야만 한다.

Claims

컴퓨팅 장치에 의하여 수행되는 방법에 있어서,
분석 대상인 바이너리(binary)의 실행을 통한 테인트 분석(taint analysis)을 수행하여, 상기 바이너리에 대하여 크래쉬(crash)를 유발하는 실행 흐름 경로(execution flow path) 및 상기 실행 흐름 경로 상의 의심 요소(suspicious element)와 관련된 취약점의 기호 제약조건(symbolic constraint)을 기록하는 1차 실행 단계; 및
상기 바이너리의 상기 실행 흐름 경로에 대하여 기호 실행(symbolic execution) 방식의 2차 실행을 수행하되, 상기 기호 제약조건을 만족하는 인스트럭션(instruction) 발견 시, 상기 발견된 인스트럭션과 상기 의심 요소의 비교 결과에 기반하여 상기 바이너리에 상기 취약점이 존재하는 것으로 판정하는 2차 실행 단계를 포함하되,
상기 2차 실행 단계는,
상기 기호 제약조건을 만족하는 인스트럭션 발견 시, 상기 발견된 인스트럭션이 상기 의심 요소와 같은 위치의 것이라면, 상기 바이너리에 상기 취약점이 존재하는 것으로 판정하는 단계를 포함하는,
바이너리 취약점 분석 방법.
삭제
컴퓨팅 장치에 의하여 수행되는 방법에 있어서,
분석 대상인 바이너리(binary)의 실행을 통한 테인트 분석(taint analysis)을 수행하여, 상기 바이너리에 대하여 크래쉬(crash)를 유발하는 실행 흐름 경로(execution flow path) 및 상기 실행 흐름 경로 상의 의심 요소(suspicious element)와 관련된 취약점의 기호 제약조건(symbolic constraint)을 기록하는 1차 실행 단계; 및
상기 바이너리의 상기 실행 흐름 경로에 대하여 기호 실행(symbolic execution) 방식의 2차 실행을 수행하되, 상기 기호 제약조건을 만족하는 인스트럭션(instruction) 발견 시, 상기 발견된 인스트럭션과 상기 의심 요소의 비교 결과에 기반하여 상기 바이너리에 상기 취약점이 존재하는 것으로 판정하는 2차 실행 단계를 포함하되,
상기 2차 실행 단계는,
상기 기호 제약조건을 만족하는 인스트럭션 발견 시, 상기 발견된 피연산자가 상기 의심 요소의 인스트럭션이 실행된 후에 실행된 피연산자라면, 상기 바이너리에 상기 취약점이 존재하는 것으로 판정하는 단계를 포함하는,
바이너리 취약점 분석 방법.
제1 항에 있어서,
상기 2차 실행 단계는,
상기 바이너리의 상기 실행 흐름 경로에 한정하여 상기 2차 실행을 수행하는 단계를 포함하는,
바이너리 취약점 분석 방법.
제1 항에 있어서,
상기 1차 실행 단계는,
상기 테인트 분석의 결과 출력된 정보를 이용하여 테인트 된 요소를 기록하되, 상기 테인트 된 요소는 테인트 된 피연산자, 테인트 된 메모리 주소 및 테인트 된 레지스터를 포함하는 단계; 및
상기 테인트 된 요소 중 적어도 일부를 의심 요소로 결정하는 의심 요소 판정 단계를 포함하되,
상기 의심 요소 판정 단계는,
상기 바이너리를 수도 코드(pseudo code)로 변환하는 단계; 및
상기 변환 된 바이너리의 수도 코드 중 상기 테인트 된 요소에 대응되는 부분 중에서, 기 저장된 의심 수도 코드 패턴에 매치되는 부분의 테인트 된 요소를 의심 요소로 판정하는 단계를 포함하는,
바이너리 취약점 분석 방법.
제1 항에 있어서,
상기 1차 실행 단계는,
상기 테인트 분석의 결과 출력된 정보를 이용하여 테인트 된 요소를 기록하되, 상기 테인트 된 요소는 테인트 된 피연산자, 테인트 된 메모리 주소 및 테인트 된 레지스터를 포함하는 단계; 및
상기 테인트 된 요소 중 일부를 의심 요소로 결정하는 의심 요소 판정 단계를 포함하되,
상기 의심 요소 판정 단계는,
상기 테인트 된 요소 중에서, 기 저장된 의심 피연산자 패턴에 매치되는 부분의 테인트 된 요소를 의심 요소로 판정하는 단계를 포함하는,
바이너리 취약점 분석 방법.
제1 항에 있어서,
상기 1차 실행 단계는,
상기 테인트 분석의 결과 출력된 정보를 이용하여 테인트 된 요소를 기록하되, 상기 테인트 된 요소는 테인트 된 피연산자, 테인트 된 메모리 주소 및 테인트 된 레지스터를 포함하는 단계; 및
상기 테인트 된 요소 중 일부를 의심 요소로 결정하는 의심 요소 판정 단계를 포함하되,
상기 의심 요소 판정 단계는,
상기 테인트 된 요소 중에서, 기 저장된 의심 인스트럭션 패턴에 매치되는 부분의 테인트 된 요소의 인스트럭션을 의심 요소로 판정하는 단계를 포함하는,
바이너리 취약점 분석 방법.
제1 항에 있어서,
상기 1차 실행 단계는,
상기 바이너리의 실행을 위한 실행 파라미터를 이용하여 상기 바이너리를 실행하는 단계; 및
상기 실행 파라미터를 이용하여 상기 테인트 분석을 위한 테인트 소스를 세팅하는 단계를 포함하되,
상기 테인트 소스를 세팅하는 단계는,
상기 바이너리의 디버그 심볼(debug symbol)에 "main"이 존재하지 않는 경우, 상기 바이너리의 실행 과정에서 상기 실행 파라미터를 로드하는 위치를 테인트 소스로 세팅하는 단계를 포함하는,
바이너리 취약점 분석 방법.
제1 항에 있어서,
상기 크래쉬의 발생에 따라 강제 종료될 때의 피연산자 값인 크래쉬 유발 값의 상기 테인트 분석에 따른 테인트 기록에 따를 때 상기 크래쉬 유발 값이 변화되지 않는 경우, 상기 실행 흐름 경로 상의 상기 강제 종료 지점에서 가장 가까운 의심 요소의 위치를 상기 취약점의 원인 위치로 결정하는 취약점 원인 위치 파악 단계를 더 포함하는,
바이너리 취약점 분석 방법.
제9 항에 있어서,
상기 위치 파악 단계는,
상기 취약점의 원인 위치의 타입을 상기 강제 종료 지점에서 가장 가까운 상기 크래쉬 유발 값의 변화 지점인 제1 타입과, 상기 강제 종료 지점에서 가장 가까운 의심 요소의 위치인 제2 타입으로 구별하여 출력하는 단계를 포함하는,
바이너리 취약점 분석 방법.
컴퓨팅 장치와 결합하여,
제1 항 및 제3 항 내지 제10 항 중 어느 한 항의 방법을 실행시키기 위하여,
컴퓨터로 읽을 수 있는 기록 매체에 저장된 소프트웨어.
컴퓨팅 장치에 의하여 수행되는 방법에 있어서,
분석 대상인 바이너리(binary)의 실행을 통한 테인트 분석(taint analysis)을 수행하여, 상기 바이너리에 대하여 크래쉬(crash)를 유발하는 실행 흐름 경로(execution flow path) 및 상기 실행 흐름 경로 상의 의심 요소(suspicious element)를 기록하는 단계; 및
상기 크래쉬의 발생에 따라 강제 종료될 때의 피연산자 값인 크래쉬 유발 값의 상기 테인트 분석에 따른 테인트 기록에 따를 때 상기 크래쉬 유발 값이 변화되지 않는 경우, 상기 실행 흐름 경로 상의 상기 강제 종료 지점에서 가장 가까운 의심 요소의 위치를 크래쉬 원인 위치로 결정하는 단계를 포함하는,
바이너리 취약점 분석 방법.
프로세서; 및
상기 프로세서에 의하여 실행되는 컴퓨터 프로그램 및 하나 이상의 분석 대상 바이너리를 저장하는 메모리를 포함하되,
상기 컴퓨터 프로그램은,
상기 분석 대상 바이너리에 실행 현황을 파악하는 코드를 삽입하여 상기 분석 대상 바이너리를 실행하는 제1 동작;
상기 분석 대상 바이너리의 1차 실행을 통한 테인트 분석(taint analysis)을 수행하여, 상기 분석 대상 바이너리에 대하여 크래쉬를 유발하는 실행 흐름 경로에 대한 정보를 출력하는 제2 동작;
상기 실행 흐름 경로 상의 의심 요소를 판정하고, 상기 의심 요소와 관련된 취약점의 기호 제약조건을 생성하는 제3 동작; 및
상기 분석 대상 바이너리의 상기 실행 흐름 경로에 대하여 기호 실행 방식의 2차 실행을 수행하고, 상기 기호 제약조건을 만족하는 인스트럭션 발견 시 상기 발견된 인스트럭션과 상기 의심 요소의 비교 결과에 기반하여 상기 분석 대상 바이너리에 상기 취약점이 존재하는 것으로 판정하는 제4 동작을 수행하도록 하는 인스트럭션들을 포함하고,
상기 제4 동작은,
상기 기호 제약조건을 만족하는 인스트럭션 발견 시, 상기 발견된 인스트럭션이 상기 의심 요소와 같은 위치의 것이라면, 상기 분석 대상 바이너리에 상기 취약점이 존재하는 것으로 판정하는 동작을 포함하는,
전자 장치.
제13 항에 있어서,
상기 컴퓨터 프로그램은,
상기 크래쉬의 발생에 따라 강제 종료될 때의 피연산자 값인 크래쉬 유발 값의 상기 테인트 분석에 따른 테인트 기록에 따를 때 상기 크래쉬 유발 값이 변화되지 않는 경우, 상기 실행 흐름 경로 상의 상기 강제 종료 지점에서 가장 가까운 의심 요소의 위치를 상기 취약점의 원인 위치로 결정하는 제5 동작을 수행하도록 하는 인스트럭션들을 더 포함하는,
전자 장치.