IMChecker
1.0.0
Thu, Imchecker Group, ติดต่อเราที่ [email protected]
ไลบรารีเสนอฟังก์ชั่นการใช้ซ้ำได้ผ่านอินเตอร์เฟสการเขียนโปรแกรมแอปพลิเคชัน (APIs) ที่มีข้อ จำกัด การใช้งานเช่นเงื่อนไขการโทรหรือคำสั่งซื้อ การละเมิดข้อ จำกัด เช่นการใช้ API ในทางที่ผิดมักจะนำไปสู่ข้อบกพร่องและปัญหาด้านความปลอดภัย แม้ว่านักวิจัยได้พัฒนาเครื่องตรวจจับ API-misuse ต่าง ๆ ในช่วงไม่กี่ทศวรรษที่ผ่านมาการศึกษาล่าสุดแสดงให้เห็นว่าการใช้ API ในทางที่ผิดนั้นแพร่หลายในโครงการจริง วิธีการที่มีอยู่อาจประสบกับปัญหาการใช้งานที่กระจัดกระจาย (เช่นข้อบกพร่องที่ไม่ค่อยเกิดขึ้น) หรือรายงานการเตือนที่ผิดพลาดเนื่องจากความหมายที่ไม่ถูกต้อง เพื่อเอาชนะข้อ จำกัด เหล่านี้เราแนะนำ Imchecker เพื่อตรวจจับข้อบกพร่อง API-misuse ได้อย่างมีประสิทธิภาพ ข้อมูลเชิงลึกที่สำคัญที่อยู่เบื้องหลัง Imchecker คือเทคนิคการวิเคราะห์แบบคงที่แบบ จำกัด ที่ขับเคลื่อนโดยภาษาเฉพาะโดเมน (DSL) สำหรับการระบุข้อ จำกัด การใช้ API ผ่านการศึกษาข้อบกพร่อง API-Misuse ในโลกแห่งความเป็นจริงเราเสนอ IMSPEC DSL ซึ่งครอบคลุมข้อ จำกัด การใช้ API ส่วนใหญ่และช่วยให้ข้อกำหนดที่เรียบง่าย แต่แม่นยำ นอกจากนี้เรายังออกแบบและใช้ Imchecker เพื่อแยกวิเคราะห์ IMSPEC โดยอัตโนมัติในการตรวจสอบเป้าหมายและใช้เอ็นจิ้นการวิเคราะห์แบบคงที่เพื่อระบุการใช้ API ที่อาจเกิดขึ้น เราได้สร้างอินสแตนซ์ Imchecker สำหรับโปรแกรม C และประเมินผลในมาตรฐานที่ใช้กันอย่างแพร่หลายและโปรแกรมในโลกแห่งความเป็นจริงขนาดใหญ่
ปัจจุบันพบข้อบกพร่องที่ไม่รู้จักก่อนหน้านี้ 75 ข้อและ 61 คนได้รับการยืนยันและแก้ไขในเคอร์เนล Linux, OpenSSL และแพ็คเกจใน Ubuntu 16.04 เราพยายามอย่างเต็มที่ที่จะใช้ Imchecker กับโปรแกรมเพิ่มเติม เราอัปโหลดรายละเอียดใน evaluation_data/new_bugs
ต้นฉบับการวิจัยของเราและต้นฉบับเครื่องมืออยู่ระหว่างกระบวนการตรวจสอบของ ICSE'19 เราจะอัปโหลดทันทีที่กระบวนการตรวจสอบเสร็จสิ้น (คุณสามารถส่งอีเมลถึงเราเพื่อเข้าถึงพวกเขาโดยวัตถุประสงค์ทางวิชาการเท่านั้น)
วิดีโอสาธิตเครื่องมือของเรามีอยู่ในเวอร์ชันภาษาอังกฤษ: https://youtu.be/ygdxeyoevim เวอร์ชันภาษาจีน: https://www.youtube.com/watch?v=3ZANEGTWUTO https://pan.baidu.com/S/1DIGQ0R6WK5SHHMLOTK9
การใช้เครื่องมือของเราที่เครื่องมือ/readme.md
Imchecker ยังอยู่ระหว่างการพัฒนาและมีข้อบกพร่องมากมายและรายการสิ่งที่ต้องทำ ข้อบกพร่องหรือคำขอคุณสมบัติใด ๆ อย่าลังเลที่จะส่งอีเมลถึงเราที่ [email protected] หรือปัญหาเปิด
เพื่อให้เข้าใจได้ดีขึ้นว่าข้อบกพร่องประเภท API-misuse เกิดขึ้นในโครงการจริง C และวิธีที่นักพัฒนาแก้ไขในทางปฏิบัติเราได้ศึกษาประวัติศาสตร์เวอร์ชันสองปีของโครงการโอเพนซอร์ซสามโครงการและปีครึ่งของ Linux-Kernel ในปี 2560 ดังที่แสดงในตารางต่อไปนี้ ประวัติศาสตร์เหล่านี้ถูกเลือกเนื่องจากการพัฒนาอย่างต่อเนื่องและเนื่องจากพวกเขามักถูกกล่าวถึงในงานตรวจจับข้อผิดพลาดที่หลากหลาย โดยรวมแล้วเราได้ศึกษา LOC ประมาณ 13.57 ม. และ 51.1K Commits
| โครงการ | LOC | ระยะเวลาศึกษา | การกระทำทั้งหมด | แก้ไขข้อบกพร่อง | API Misuses |
|---|---|---|---|---|---|
| ขด | 112.8K | 20160101-25601231 | 2613 | 135 | 38 |
| gnutls | 35.8K | 20160101-25601231 | 2769 | 86 | 30 |
| openssl | 454.2K | 20160101-25601231 | 6487 | 344 | 115 |
| ลินเวกซ์ | 12.96m | 20170701-20171231 | 39295 | 995 | 362 |
| ทั้งหมด | 15.57m | สองปี | 51.1k | ค.ศ. 1560 | 509 |
เพื่อช่วยให้ผู้อ่านแยกข้อความที่มีการเปลี่ยนแปลงไฟล์และไฟล์แพตช์เราเปิดแหล่งข้อมูล GitGrabber ของเรา นอกจากนี้เรายังอัปโหลดการกระทำทั้งหมดที่เกี่ยวข้องกับข้อบกพร่อง API-misuse ในวิชาที่ศึกษาเพื่อใช้งานต่อไป
ผู้อ่านสามารถค้นหาได้ในโฟลเดอร์ Empirical_Study ปัญหาใด ๆ เกี่ยวกับ Gitgrabber โปรดติดต่อเรา!
เราเลือกเกณฑ์มาตรฐานที่ใช้กันอย่างแพร่หลายเช่น Juliet Test Suite v1.3 และสองโปรแกรมในโลกแห่งความจริงในเวอร์ชันล่าสุดของพวกเขา: Linux Kernel-4.18-RC4 เปิดตัวเมื่อปี 2018-7-9 และ OpenSSL-1-1-1-Pre8 ที่วางจำหน่ายเมื่อปี 2018-6-20 เพื่อประเมินแนวทางของเรา เราประเมินวิธีการของเราจากสองมุมมอง
นอกจากนี้เรายังทดสอบกรณีนี้เกี่ยวกับ APISAN เครื่องมือตรวจจับการใช้ API Sanitizing ผ่านการตรวจสอบข้ามความหมายและ Clang-SA เครื่องมือการวิเคราะห์แบบคงที่โอเพ่นซอร์ส
เราอัปโหลดมาตรฐาน API-MISUSE และผลลัพธ์ดั้งเดิมที่ Evaluation_Data
แรงจูงใจหลักของ Imchecker คือการตรวจจับข้อบกพร่อง API-Misuse ในโปรแกรมโลกแห่งความเป็นจริงกล่าวคือเพื่อตรวจสอบว่า Imchecker สามารถหาข้อบกพร่องที่ไม่รู้จักมาก่อนได้หรือไม่ ดังนั้นเราจึงใช้ Imchecker กับเวอร์ชันล่าสุดของสองโปรแกรมโอเพนซอร์ซที่รู้จักกันดี: Linux Kernel-4.18-RC4 และ OpenSSL-1-1-1-Pre8 และแพ็คเกจใน Ubuntu 16.04 APIs เป้าหมายได้รับการคัดเลือกจากการใช้งานที่ผิดจากการศึกษาเชิงประจักษ์
ถึงตอนนี้พบข้อบกพร่องที่ไม่รู้จัก 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) |
| อุปกรณ์เปิด VM | 2 (0/0/2) |
| IRSSI | 2 (1/1/0) |
| เก็บไว้ | 2 (0/0/2) |
| THC-IPV6 | 2 (0/0/2) |
| Freeradius-Server | 2 (0/0/2) |
| ผู้ค้ามนุษย์ | 3 (3/0/0) |
| Tinc | 2 (0/0/2) |
| sslplit | 2 (0/0/2) |
| Rdesktop | 2 (2/0/0) |
| พร็อกซีทูเนล | 2 (2/0/0) |
| ทั้งหมด | 75 (16/29/32) |
เราอัปโหลดรายละเอียดใน evaluation_data/new_bugs
ข้อมูลจำเพาะเชิงพฤติกรรมที่อธิบายถึงข้อ จำกัด การใช้ API ได้แสดงให้เห็นว่ามีประโยชน์สำหรับนักพัฒนาในการใช้ API อย่างมีประสิทธิภาพเช่นเดียวกับการรับมือกับปัญหาการใช้งานที่กระจัดกระจายโดยการตรวจสอบความถูกต้องของการใช้งานของ API เป้าหมาย ตัวอย่างเช่น Bodden นำเสนอ Crysl เพื่อเชื่อมช่องว่างทางปัญญาระหว่างผู้เชี่ยวชาญด้านการเข้ารหัสและนักพัฒนา อย่างไรก็ตามภาษาสเปคปัจจุบันได้รับการออกแบบมาสำหรับคุณสมบัติโปรแกรมเต็มรูปแบบเช่น BLAST, JML หรือเฉพาะเจาะจงเกินกว่าที่จะนำไปใช้กับการตรวจจับ API-usage ทั่วไปเช่น SLIC เราแนะนำภาษาเฉพาะโดเมนที่มีน้ำหนักเบาสำหรับข้อ จำกัด การใช้ API ชื่อ IMSPEC IMSPEC พร้อมกันทำให้มั่นใจได้ว่า API เป้าหมายได้รับการตรวจสอบความถูกต้องแม้จะมีการใช้งานน้อยและเป็นแนวทางในการตรวจจับการใช้ในทางที่ผิด อินสแตนซ์ของ IMSPEC เป็นรูปแบบที่เต็มไปด้วยชุดของข้อ จำกัด ในการใช้ API อย่างถูกต้องและการละเมิดใด ๆ จะส่งผลให้เกิดข้อผิดพลาด API-misuse
เราอัปโหลดอินสแตนซ์ IMSPEC ลงในโฟลเดอร์ IMPSEC เราจะอัปเดตโฟลเดอร์นี้เพิ่มขึ้นสำหรับ API เพิ่มเติม นอกจากนี้ IMSPEC สามารถใช้เพื่อวัตถุประสงค์อื่นเช่นสร้างกรณีการทดสอบการตรวจสอบและอื่น ๆ นอกจากนี้เรายังมีนักเขียน GUI IMSPEC ที่เครื่องมือ
ปัจจุบัน IMSPEC ถูกสร้างขึ้นโดยการเขียนด้วยตนเอง อย่างไรก็ตามเรามั่นใจได้ว่าสามารถสร้างได้โดยอัตโนมัติจากเทคนิคการขุดข้อมูลจำเพาะ เราพยายามอย่างเต็มที่ที่จะทำการทดลองและใช้พาร์สเซอร์เพื่อแปลผลลัพธ์จากเครื่องมือขุดลงใน IMSPEC เช่น APEX แต่เครื่องมือเหล่านี้ไม่สามารถแก้ข้อ จำกัด การใช้งานทั้งหมดได้ นอกจากนี้เรายังขอเชิญชวนนักพัฒนาเพื่อช่วยเราปรับแต่งอินสแตนซ์ IMSPEC ที่สร้างขึ้นตามคู่มือผู้ใช้เช่น OpenSSL
API-usage ที่ถูกต้องจะต้องตอบสนองข้อ จำกัด การใช้งานนั่นคือการละเมิดข้อ จำกัด อาจส่งผลให้เกิดข้อบกพร่อง API-Misuse Imchecker ตรวจพบข้อบกพร่องเหล่านี้ในซอร์สโค้ดโดยอัตโนมัติโดยใช้ข้อกำหนดของ IMSPEC ในการประมวลผลโปรแกรมที่ซับซ้อนในโลกแห่งความเป็นจริงกลไกพื้นฐานของ Imchecker จะต้องปรับขนาดได้ในขณะที่ลดความแม่นยำน้อยที่สุด เราอธิบายรายละเอียดการออกแบบของ Imchecker รวมถึงการดำเนินการเชิงสัญลักษณ์ที่ไม่ จำกัด ด้วยเทคนิคการวิเคราะห์แบบคงที่เพื่อสร้างบริบทการวิเคราะห์วิธีการตรวจจับข้อบกพร่อง API-misuse ในบริบทการวิเคราะห์และวิธีการกรองผลบวกปลอมโดยใช้ข้อมูลความหมายและสถิติการใช้งาน
เราใช้ตัวอย่างที่สร้างแรงบันดาลใจเพื่อแสดงให้เห็นถึงเวิร์กโฟลว์ของ Imchecker นี่คือข้อผิดพลาด API-misuse ใน OpenSSL ที่รายงานใน CVE-2015-0288 การตรวจสอบรหัสข้อผิดพลาดที่ขาดหายไปของ X509_get_pubkey() ส่งผลให้เกิดข้อผิดพลาด dereference ตัวชี้ที่เป็นโมฆะที่ LINE-4
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-misuse ในสามขั้นตอน (1) ในเฟส 1 บริบทการวิเคราะห์ถูกสร้างขึ้นโดยการสร้างกราฟการควบคุมการไหลและการสร้างร่องรอยเส้นทางของโปรแกรมสำหรับแต่ละ API เป้าหมายที่กำหนดไว้ในข้อกำหนดโดยใช้การดำเนินการเชิงสัญลักษณ์ภายใต้ข้อ จำกัด ด้วยการวิเคราะห์แบบจุดต่อช่วงและเส้นทางที่ไวต่อเส้นทาง ในตัวอย่างนี้มีการสร้างร่องรอยสองตัว T1 และ T2 ดังที่แสดงในกล่องด้านบนร่องรอยเส้นทางของโปรแกรม ด้วยวิธีนี้ Imchecker สามารถจับบริบทการใช้งานของ X509_get_pubkey() , EVP_PKEY_free() และในระหว่างนั้น (2) ในระยะที่ 2 Imchecker ใช้ร่องรอยในการตรวจจับการละเมิดข้อ จำกัด เป็นข้อบกพร่องที่อาจเกิดขึ้น Forexample, อินสแตนซ์สองตัวของ MISUSE ของ X509_get_pubkey() พบว่ามีการตรวจสอบรหัสข้อผิดพลาดที่ขาดหายไปที่ระบุว่าเป็นข้อบกพร่องที่อาจเกิดขึ้น (3) ในเฟส -3 Imchecker ปรับปรุงความแม่นยำในการตรวจจับโดยใช้ประโยชน์จากอินสแตนซ์การใช้งานหลายครั้งและข้อมูลความหมาย จากนั้นการใช้งานในทางที่ผิดครั้งที่สองจะถูกกรองออกสำหรับเช็คที่ดำเนินการใน X509_to_X509_REQ() ที่ LINE-25
การใช้เครื่องมือของเราสามารถพบได้ที่นี่: เครื่องมือ/readme.md
ในขณะที่ตรวจสอบรายงานข้อผิดพลาดที่สร้างโดย Imchecker เราพบข้อบกพร่องที่น่าสนใจหลายประการและได้รับประสบการณ์ที่เป็นประโยชน์ในกระบวนการรายงานข้อผิดพลาดกับนักพัฒนาโอเพนซอร์ส เราแบ่งปันประสบการณ์ต่อไปนี้ของเรา
ผู้เขียนขอขอบคุณนักพัฒนาของ Linux Kernel และ OpenSSL เพื่อช่วยเราปรับแต่ง IMSPEC และยืนยันรายงานข้อผิดพลาด
