Imchecker Group, [email protected]으로 문의하십시오
라이브러리는 호출 조건 또는 주문과 같은 사용 제약 조건이있는 응용 프로그램 프로그래밍 인터페이스 (API)를 통해 재사용 가능한 기능을 제공합니다. 제약 위반, 즉 API 오용은 일반적으로 버그 및 보안 문제로 이어집니다. 연구자들이 지난 수십 년 동안 다양한 API- 미사용 탐지기를 개발했지만 최근의 연구에 따르면 API 오용은 실제 프로젝트에서 널리 퍼져 있습니다. 기존 접근법은 드문 사용법 문제 (예 : 거의 발생하지 않는 버그)로 인해 부정확 한 의미로 인해 잘못된 경보를보고합니다. 이러한 한계를 극복하기 위해 API- 미사일 버그를 효과적으로 감지하기 위해 Imchecker를 소개합니다. Imchecker의 주요 통찰력은 API 사용 제약 조건을 지정하기위한 도메인 별 언어 (DSL)로 구동되는 제약 조건 지향 정적 분석 기술입니다. 실제 API 사용 버그를 연구함으로써 API 사용 구속 조건의 대부분을 다루고 간단하지만 정확한 사양을 활성화하는 IMSPEC DSL을 제안합니다. 또한, 우리는 IMChecker를 설계하고 구현하여 IMSPEC를 자동으로 대상을 확인하고 정적 분석 엔진을 사용하여 잠재적 인 API 오용을 식별하고 풍부한 시맨틱으로 잘못된 긍정을 잘라냅니다. 우리는 C 프로그램에 대한 Imchecker를 인스턴스화하고 널리 사용되는 벤치 마크 및 대규모 실제 프로그램에서 평가합니다.
현재 75 건의 알려지지 않은 버그가 발견되었으며 61 개가 Linux 커널에서 확인 및 고정되어 Ubuntu 16.04의 OpenSSL 및 패키지로 고정되었습니다. 우리는 더 많은 프로그램에 imchecker를 적용하기 위해 최선을 다하고 있습니다. Evaluation_Data/New_Bugs에 세부 사항을 업로드합니다
우리의 연구 원고 및 도구 원고는 ICSE의 검토 과정 아래 있습니다. 검토 프로세스가 완료 되 자마자 업로드하겠습니다. (글쎄, 당신은 우리에게 이메일을 보내도록 Accordic의 목적으로 만 액세스 할 수 있습니다.)
당사의 도구 데모 비디오는 영어 버전으로 제공됩니다 : https://youtu.be/ygdxeyoevim 중국어 버전 : https://www.youtube.com/watch?v=3zanegtwuto https://pan.baidu.com/s/1digq0r6wk5shhmlotk9kbg
도구/readme.md에서 도구 사용
Imchecker는 여전히 개발 중이며 많은 버그와 TODO 목록이 포함되어 있습니다. 버그 또는 기능 요청은 [email protected]으로 이메일을 보내 주시거나 열린 문제를 보내 주시기 바랍니다.
실제 C 프로젝트에서 어떤 유형의 API- 미사일 버그가 발생하고 개발자가 실제로 수정하는지 더 잘 이해하기 위해 다음 표에서 볼 수 있듯이 2017 년에 3 개의 오픈 소스 프로젝트와 1/2 년의 Linux-Kernel에 대한 2 년의 버전 역사를 수동으로 연구했습니다. 이러한 역사는 지속적인 개발로 인해 선택되며 다양한 버그 탐지 작업에서 자주 언급되어 있기 때문입니다. 전체적으로, 우리는 약 13.57m LOC와 51.1K 커밋을 연구했습니다.
| 프로젝트 | 로 로치 | 공부 기간 | 총 커밋 | 버그 수정 | API 오용 |
|---|---|---|---|---|---|
| 컬 | 112.8k | 20160101-20171231 | 2613 | 135 | 38 |
| gnutls | 35.8k | 20160101-20171231 | 2769 | 86 | 30 |
| OpenSSL | 454.2k | 20160101-20171231 | 6487 | 344 | 115 |
| 리눅스 | 12.96m | 20170701-20171231 | 39295 | 995 | 362 |
| 총 | 15.57m | 2 년 | 51.1k | 1560 | 509 |
독자가 커밋 메시지, 변경 파일 및 패치 파일을 추출 할 수 있도록 Gitgrabber 도구를 개방합니다. 또한 추가 사용을 위해 연구 된 대상의 API- 미사용 버그와 관련된 모든 커밋을 업로드합니다.
독자는 empirical_study 폴더에서 찾을 수 있습니다. Gitgrabber에 대한 모든 문제, 언제든지 저희에게 연락하십시오!
우리는 널리 사용되는 벤치 마크 (IE, Juliet Test Suite v1.3)와 최신 버전의 두 가지 실제 프로그램을 선택합니다 : Linux Kernel-4.18-RC4는 2018-7-9에 출시되어 2018-6-20에 릴리스 된 OpenSSL-1-1-PRE8을 우리의 접근 방식을 평가합니다. 우리는 두 가지 관점에서 우리의 접근 방식을 평가합니다.
우리는 또한 시맨틱 크로스 체크를 통해 Apisan A Sanitizing API 사용량 탐지 도구 에서이 사례를 테스트하고 Open-Source 정적 분석 도구 인 Clang-Sa.
API-Misuse-Benchmark 및 Original Results를 Evaluation_Data에서 업로드합니다.
Imchecker의 주요 동기는 실제 프로그램에서 API- 미사일 버그를 감지하여 즉, Imchecker가 이전에 알려지지 않은 버그를 찾을 수 있는지 여부를 결정하는 것입니다. 따라서 우리는 잘 알려진 두 가지 오픈 소스 프로그램의 최신 버전 인 Linux Kernel-4.18-RC4 및 OpenSSL-1-1-PRE8 및 Ubuntu 16.04의 패키지에 IMChecker를 적용합니다. 타겟 API는 경험적 연구에서 오용 된 API에서 선택됩니다.
지금까지 56 건의 이전에 알려지지 않은 버그가 발견되었으며 개발자는 36 개가 확인되었습니다.
| 프로젝트 | 버그 (대기 응답/확인/고정) |
|---|---|
| OpenSSL | 17 (0/5/12) |
| 리눅스 | 30 (5/20/5) |
| DMA | 1 (0/0/1) |
| exim | 2 (0/0/2) |
| hexchat | 2 (1/1/0) |
| httping | 1 (0/1/0) |
| ipmitool | 1 (0/1/0) |
| Open-VM-Tools | 2 (0/0/2) |
| IRSSI | 2 (1/1/0) |
| keepalive | 2 (0/0/2) |
| THC-IPV6 | 2 (0/0/2) |
| 프리 라디우스-서버 | 2 (0/0/2) |
| 트래픽 서버 | 3 (3/0/0) |
| 틴크 | 2 (0/0/2) |
| sslplit | 2 (0/0/2) |
| rdesktop | 2 (2/0/0) |
| proxyTunnel | 2 (2/0/0) |
| 총 | 75 (16/29/32) |
Evaluation_Data/New_Bugs에 세부 사항을 업로드합니다
API 사용 제약 조건을 설명하는 행동 사양은 개발자가 API를 효과적으로 활용하고 대상 API의 사용량 검증을 보장하여 드문 사용법 문제에 대처하는 데 유용한 것으로 나타났습니다. 예를 들어, Bodden은 Crysl이 암호화 전문가와 개발자 사이의인지 적 격차를 해소합니다. 그러나 현재 사양 언어는 Blast, JML과 같은 전체 프로그램 특성을 위해 설계되었거나 SLIC와 같은 일반 API-USAGE 검출에 적용하기에는 너무 구체적입니다. IMSPEC라는 API 사용 제약 조건에 대한 가벼운 도메인 별 언어를 소개합니다. IMSPEC는 동시에 사용량이 거의없이 대상 API가 검증되도록하고 오용 탐지를 안내합니다. IMSPEC 인스턴스는 API를 올바르게 사용하기위한 일련의 제약 조건으로 채워진 패턴이며, 위반으로 인해 API- 미사일 버그가 발생합니다.
IMSPEC 인스턴스를 IMPSEC 폴더에 업로드하면 더 많은 API를 위해이 폴더를 점진적으로 업데이트합니다. 또한 IMSPEC는 테스트 사례 생성, 검증 등과 같은 다른 목적으로 사용될 수 있습니다. 또한, 우리는 GUI IMSPEC 작가에게 도구를 제공합니다.
현재 IMSPEC는 수동 쓰기에 의해 만들어졌습니다. 그러나 사양 마이닝 기술로부터 자동으로 생성 될 수 있도록합니다. 우리는 실험을 수행하고 파서를 구현하여 채굴 도구의 결과를 Apex와 같은 IMSPEC로 변환하기 위해 최선을 다하고 있습니다. 그러나 이러한 도구는 모든 사용 제약을 해결할 수는 없습니다. 또한 OpenSSL과 같은 사용자 매뉴얼에 따라 생성 된 IMSPEC 인스턴스를 개선 할 수 있도록 개발자를 초대하고 싶습니다.
올바른 API-USAGE는 일련의 사용 제약 조건을 충족시켜야합니다. 즉, 제약 조건을 위반하면 API- 미사일 버그가 발생할 수 있습니다. Imchecker는 IMSPEC의 사양을 사용하여 소스 코드에서 이러한 버그를 자동으로 감지합니다. 복잡한 실제 프로그램을 처리하려면 Imchecker의 기본 메커니즘은 최소한의 정확도를 희생하면서 확장 가능해야합니다. 우리는 정적 분석 기술을 사용하여 제한되지 않은 상징적 실행을 포함하여 Imchecker의 설계 세부 사항을 자세히 설명하고 분석 컨텍스트를 구축하고 분석 컨텍스트에서 API- 미사일 버그를 감지하는 방법론 및 의미 론적 정보 및 사용 통계를 사용하여 허위 양성을 필터링하는 방법을 자세히 설명합니다.
우리는 동기 부여 예제를 사용하여 Imchecker의 워크 플로를 설명합니다. 이것은 CVE-2015-0288에서보고 된 OpenSSL의 API- 미사용 버그입니다. X509_get_pubkey() 의 누락 된 오류 코드 점검으로 Line-4에서 Null 포인터 Dereference 버그가 발생했습니다.
1 // Location: crypto/x509/x509_req.c: 70 2 X509_REQ *X509_to_X509_REQ(...){
3 ...
4 pktmp = X509 get pubkey ( x );
5 // missing error code check of pktmp
6 + if ( pktmp == NULL )
7 + goto err ;
8 i = X509_REQ_set_pubkey ( ret , pktmp ); 9 EVP_PKEY_free ( pktmp );
10 ...
11 }
12
13 // Location: /crypto/x509/x509_cmp.c: 390
14 int X509_chain_check_suiteb (...){
15 ...
16 // check error value in usage
17 pk = X509 get pubkey ( x );
18 rv = check_suite_b ( pk , -1 , & tflags );
19 ...
20 }
21 // Location: /crypto/x509/x509_cmp.c: 359
22 static int check_suite_b ( EVP_PKEY * pkey ,...){ 23 ...
24 // ensure pkey not NULL
25 if ( pkey && pkey -> type == EVP PKEY EC )
26 ... // usage of pkey
27 }Imchecker의 워크 플로우는 다음과 같습니다.

Imchecker는 소스 코드 및 API 사용 제약을 입력으로 가져 와서 구체적인 위치 및 출력으로 버그 보고서를 생성합니다. 먼저, API 사용 제약 조건은 IMSPEC라는 가벼운 도메인 별 언어로 작성됩니다. 예를 들어, "x509_get_pubkey ()의 반환 값은 NULL로 확인해야합니다." 이러한 사양을 사용함으로써 Imchecker는 대상 API의 사용법을 직접 검증하여 드문 사용 문제를 완화하고 버그 감지 프로세스를 안내합니다. 그런 다음 API- 미사일 버그를 3 단계로 감지합니다. (1) Phase-1에서, 분석 컨텍스트는 제어 흐름 그래프를 구성하고 포인트-투, 범위 및 경로 민감성 분석과 함께 제한되지 않은 상징적 실행을 사용하여 사양에 정의 된 각 대상 API에 대한 프로그램 경로 추적을 생성함으로써 구축된다. 이 예에서, 프로그램 경로 추적 위의 상자에 도시 된 바와 같이 두 가지 흔적 인 T1 및 T2가 생성된다. 이러한 방식으로 Imchecker는 X509_get_pubkey() , EVP_PKEY_free() 및 그 사이의 사용 컨텍스트를 성공적으로 캡처 할 수 있습니다. (2) 2 단계에서 Imchecker는 잠재적 인 버그로 제약 조건 위반을 감지하기 위해 흔적을 사용합니다. 외과, X509_get_pubkey() 의 TwoApi-misse 인스턴스는 잠재적 버그로 표시된 오류 코드 검사에 대해 찾을 수 있습니다. (3) Phase-3에서, Imchecker는 여러 사용법 인스턴스와 시맨틱 정보를 활용하여 감지 정밀도를 향상시킵니다. 그런 다음 Line-25에서 X509_to_X509_REQ() 에서 수행 된 검사를 위해 두 번째 오용이 필터링됩니다.
도구의 사용은 여기에서 찾을 수 있습니다 : 도구/readme.md
Imchecker가 생성 한 버그 보고서를 조사하는 동안 우리는 몇 가지 흥미로운 버그를 발견하고 오픈 소스 개발자와 함께 버그보고 프로세스에서 유용한 경험을 얻습니다. 우리는 다음 경험을 공유합니다.
저자는 Linux 커널 개발자와 OpensSL의 개발자에게 IMSPEC를 개선하고 버그 보고서를 확인하는 데 도움이됩니다.