ผู้เขียน/โดย : เกริก ภิรมย์โสภา (Krerk Piromsopa)
เขียนเมื่อ/ปรับปรุง : 2007-11-24 15:47:24
เนื้อหาในส่วนนี้ รวบรวมขึ้นเพื่อประกอบความเข้าใจเรื่อง Buffer Overflow และ
Buffer-Overflow Attacks เริ่มต้นด้วยความหมายของ Buffer-Overflow จากนั้นเราจะวิเคราะห์ต่อไปว่าปัญหาง่ายๆ
นี้ นำไปสู่ความเสียหายอื่นๆ อันเป็นพื้นฐานของ Computer Viruses หรือ Computer
Worms ได้อย่างไร จากนั้นเราจะวิเคราะห์ปัญหา และลองศึกษาวิธีการป้องกันดู นอกจาก
Buffer-Overflow แล้ว ยังมีปัญหาอื่นๆ คล้ายคลังกันเช่น Integer Overflow หรือ
การใช้ printf ในภาษา C แบบไม่ถูกวิธี อย่างไรก็ตามเราจะไม่กล่าวถึงรายละเอียดปัญหาย่อยๆ
ที่คล้ายคลังกันในที่นี้ เมื่ออ่านจบเนื้อหาในหน้านี้แล้วผู้เขียนหวังเป็นอย่างยิ่งว่า
ผู้อ่านจะมีความเข้าใจในเรื่อง Buffer-Overflow และพัฒนา skill ในการเขียนโปรแกรมมากขึ้น
Buffer Overflow คืออะไร
หลายคนพยายามนิยามหรือให้ความหมายอย่างเป็นทางการของ Buffer Overflow จากการรวบรวมข้อมูลจากหลายๆ
แห่ง แล้ว สรุปใจความได้สั้นๆ ว่า
Buffer Overflow
เกิดขี้นเมื่อมีการเขียน(อ้างอิง)ข้อมูลเกินขอบเขตที่กำหนด
ผลที่เกิดขึ้นคือข้อมูลที่เขียนล้นเข้าไปทับข้อมูลอื่นที่อยู่ในระบบ
ผลที่ตามมาจากการ Overflow ดังกล่าวอาจจะเป็นไปได้ตั้งแต่ทำให้โปรแกรมประมวลผลข้อมูลผิดพลาด,
Segmentation False หรืออาจจะร้ายแรงถึง เปลี่ยนการทำงานของระบบให้ประมวลผล Code
ใดๆ ก็ได้ตามที่ Attackers ต้องการ
Buffer-Overflow Attacks สร้างความเสียหายอะไรได้บ้าง
เพื่อความสะดวกในการอธิบาย จะขอยกตัวอย่างประกอบนะที่นี้โดยเริ่มจากตัวอย่างแบบง่าย
ไปจนถึงการ Attack ที่ซับซ้อนยิ่งขึ้น โดยเริ่มต้นที่ตัวอย่าง Buffer Overflow
แบบง่ายๆ ก่อน แล้วค่อยๆ ยากขึ้นไปจนถึง Buffer-Overflow Attacks ที่ซัพซ้อน (สามารถผ่านระบบป้องกัน
Buffer Overflow บน Software ที่ใช้กันทั่วไป)
ตัวอย่างที่ 1 Buffer-Overflow Attacks แบบเบื้องต้น
ในตัวอย่างแรกนี้ (รูปที่ 1) เป็นตัวอย่างโปรแกรมภาษา C ง่ายๆ ที่เมื่อถูก Overflow
จะทำให้การทำงานบางอย่างผิดไป ในที่นี้ คือตัวแปร age ซึ่งเป็นตัวแปรเก็บตัวเลขจะถูก
Overflow จนค่าที่ได้เปลี่ยนไป ดังในตัวอย่างจะพบว่าอายุเปลี่ยนจาก 15 เป็น 49
(ทั้งที่ไม่ได้ทำการกำหนดค่าตัวแปร age เป็น 49)
#include int main(char argc,char *argv[]) {
int age;
char name[8];
char tmp[20];
printf(“Enter your age:”);
gets(tmp);
age=atoi(tmp);
printf(“Enter your name:”);
gets(name); /* 1 */
printf(“———– “);
printf(“%s is %d years old
” ,name,age);
}
|
$./a.out
Enter your age:15
Enter your name: Krerk.P01
-----------
Krerk.P01 is 49 years old |
รูปที่ 1 ตัวอย่าง Buffer-Overflow Attack แบบเบื้องต้น
**** ค่าที่ได้อาจจะแตกต่างกันไป ขึ้นอยู่กับ Processor, ระบบปฏิบัติการ และ ตัว
compiler *****
สิ่งที่เกิดขึ้นคือ คำสั่ง gets(name) (1) ซึ่งรับข้อมูล input ที่มีขนาด 10
ตัว (9 ตัวอักษร “Krerk.P01″ และ 1 terminator) มาเก็บไว้ในตัวแปร name แต่ตัวแปร
name นั้นมีขนาดเพียง 8 ตัวอักษร ทำให้ข้อมูลที่ได้มาเกิด Overflow ไปทับ age ผลที่ตามมาคือตัวแปร
age ซึ่งเดิมเก็บตัวเลข 15 ถูกเปลี่ยนเป็นเก็บตัวอักษร ‘1’ แทน เมื่อ age
ถูกอ้างอิงอีกครั้ง ตัวอักษร ‘1’ จึงถูกอ้างอิงเป็นตัวเลขซึ่งมีค่าเป็น
49 (ในที่นี้ถือตามมาตรฐานรหัส ASCII)
ตัวอย่างที่ 2 Stack Smashing
ในตัวอย่างนี้ จะเป็นทำงานที่ซับซ้อนยิ่งขึ้น โดยก่อนอื่นผู้อ่านจะต้องทำความเข้าใจเรื่องของ
Stack Frame นิดนึงก่อน ทุกครั้งที่โปรแกรมมีการเรียก sub routine ค่า parameters
และ ตำแหน่งการทำงานปัจจุบัน (Return Address) จะถูกเก็บไว้ที่ข้อมูลชั่วคราวคือ
Stack (memory เฉพาะ) หาก sub routine นั้นๆ มีตัวแปรที่เป็น local variable โปรแกรมก็จะจองเนื้อที่บน
Stack เพื่อใช้สำหรับเก็บตัวแปรดังกล่าว การทำงานลักษณะนี้ ทำให้โปรแกรมสามารถอ้างอิง
scope ของ variable ได้ (local variables อ้างอิงจาก stack frame ปัจจุบันเสมอ)
ในรูปที่ 2 ตัว function func ประกอบไปด้วยตัวแปร i, f, ptr, และ
buffer โดยในที่นี้ f เป็น function pointer (สำหรับผู้ที่ไม่คุ้นเคย
funtion pointer เป็น pointer ที่ใช้สำหรับการ dynamic bind ตัวแปร f
ให้เป็น funtion ใดๆ ก็ได้ ในตัวอย่างนี้ เรา bind f ให้เป็น printf) และ
ptr เป็น pointer ทั่วไป และ buffer เป็น array of characters ธรรมดา
เมื่อ func ถูกเรียกใช้งาน ระบบจะทำการสร้าง stack frame
ขึ้นเพื่อจำค่าตำแหน่งปัจจุบัน (ก่อนจะ call subroutine)
ที่โปรแกรมจะต้องกลับมาทำงานต่อ เมื่อเข้ามาสู่โปรแกรม ตัว subroutine
จะบันทึกค่า frame pointer funtion เดิม และจองเนื้อที่สำหรับ local
variables ดังแสดงได้ในด้านขวาของรูปที่ 2
เมื่อวิเคราะห์โปรแกรมดังกล่าว จะพบว่า หากเกิด overflow ที่ตัวแปร
buffer ค่าต่างๆ (อาทิ ptr, f , x, frame pointer, return address)
สามารถถูกเปลี่ยนเป็นค่าใดๆ ก็ได้ เมื่อมี input ที่เหมาะสม
Buffer-overflow attack แบบแรกๆ ที่พบมักจะแทรก code ที่ต้องการให้โปรแกรม
run ลงในตอนต้นของ buffer จากนั้นก็เขียน address ของ buffer
ดังกล่าวต่อท้ายไป ผลที่ได้คือ address ทั้งหลายจะถูกชี้กลับมาที่ buffer
ซึ่งมี code ที่ hacker ต้องการอยู่ เมื่อ address ดังกล่าวถูกอ้างอิง
code เหล่านี้ก็จะถูกประมวลผลโดยปริยาย buffer-overflow attack
ในลักษณะนี้ บางครั้งนิยมเรียกว่า stack smashing
เนื่องจากข้อมูลขนาดใหญ่ถูกปะลงบนเนื้อที่ Stack อย่างไรก็ตาม
บางคนจึงคิดว่าหากเราทำให้ stack ไม่สามารถ execute ได้ (เช่น AMD
non-executable area — NX หรือ patch ที่ Linux kernel บางอัน)
น่าจะสามารถหยุด buffer-overflow attack ได้
int func(char **argv) { int x;
int (*f) (const char *, ...);
char *ptr;
char buffer[30];
ptr=buffer;
f=& printf;
f("ptr %p - before ",ptr);
strcpy(ptr,argv[1]);
f(“ptr %p – after “,ptr);
strcpy(ptr,argv[2]);
} |
| return address |
| frame pointer |
| x |
| f |
| ptr |
| buffer |
|
| & buffer |
| & buffer |
| & buffer |
| & buffer |
| & buffer |
| Malicious Code |
|
รูปที่ 2 ตัวอย่าง Buffer overflow แบบซับซ้อนยิ่งขึ้น
ในความเป็นจริง การ injected code มิใช่สิ่งสำคัญ เพราะหากเราทราบว่ามี
code ที่เราต้องการให้โปรแกรมประมวลผล อยู่ที่ตำแหน่งอันใดอันหนึ่งใน
memory (เช่น code จาก share library หรือตัว code ของโปรแกรมเอง)
เราก็เพียงเปลี่ยนตำแหน่งของ pointers และ addresses ต่างๆ ให้ชี้ไปยัง
code ส่วนนั้น การ attack ในลักษณะนี้ บางคนเรียกว่า arc injection
ตัวอย่างที่ 3 Multi-stage attacks
ในหลายๆ กรณี buffer-overflow attacks จะเกิดขี้นจากการ overflow
หลายครั้งต่อกัน โดยทั่วไปการ overflow ครั้งแรกจะทำให้เกิด pointer
ชี้ไปยังที่ใดก็ได้ในตัวโปรแกรมนั้นๆ และการ overflow
อีกครั้งนึงจะเปลี่ยนค่าที่ pointer ชี้อยู่เป็นค่าที่ต้องการ
ตัวอย่างการ attack ที่พบเช่น Apache mod_SSL SLAPPER Worm ซึ่งการ
overflow ครั้งแรก ช่วยให้เกิด pointer ชี้ไปยัง global offset table
(jump table ที่ใช้อ้างอิงตัวโปรแกรมหลักกับ share library) ของ funtion
free จากนั้น การ overflow ครั้งที่ 2 จะเปลี่ยน entry ดังกล่าวให้มา run
remote shell
ลองพิจารณาโปรแกรมในตัวอย่างที่ 2 อีกครั้งหนึ่ง เราจะพบว่ามี strcpy 2
ครั้ง ในกรณีของ Multi-stage attacks นี้ strcpy ครั้งแรก จะoverflow ตัว
pointer ptr ให้ชี้ไปยังที่ใดก็ได้ของโปรแกรม สุมมุติว่าชี้ไปที่ jump
table ของ printf เมื่อมี strcpy ครั้งที่ 2 เราก็สามารถจะเขียนค่าใดๆ
ก็ได้ที่ entry นั้น ผลที่เกิดขึ้นก็คือ เมื่อเรียก printf ครั้งต่อไป
ตัวโปรมก็จะไปเรียกทำงานค่าที่ระบุแทนโปรแกรม printf ที่อ้างอิงกับ library
นักวิจัยหลายคนเสนอแนวทางการป้องกัน global offset table
โดยให้ทำส่วนดังกล่าวเป็น read only หลังจากที่ได้มีตัวค่าโดย loader
เรียบร้อยแล้ว อย่างไรก็การป้องกันดังกล่าว ก็มิได้ป้องกัน function
pointer หรือส่วนอื่นๆ แต่อย่างใด
ยิ่งไปกว่านั้น หลักการดังกล่าวยังใช้ attacks โปรแกรมที่มีการป้องกัน
Buffer Overflow ด้วยวิธีการที่นำเสนอกันหลายๆ แบบ เช่นการแทรกค่า cannary
เพื่อตรวจสอบว่า address มีการเปลี่ยนแปลงหรือไม่ได้อีกด้วย เช่น
การเปลี่ยนตัว error handling routine ให้เป็นของผู้บุกรุกเอง เป็นต้น
(ดูรายละเอียดเพิ่มเติมได้ที่
Secure Bit 2, และ
Buffer Overflow: the Fundamentals และ
Secure Bit)
หลักการสำคัญของ Buffer-Overflow
ถึงตรงนี้ บางคนอาจจะตั้งข้อสังเกตุว่า Buffer Overflow
ดูเหมือนจะเป็นปัญหาที่เกิดขึ้นจาก ภาษา C ซึ่งไม่มีระบบ Bound Checking
แต่ในความเป็นจริงคือ ทุกภาษาในปัจจุบัน มักจะถูกแปลงลงมาเป็นภาษาเครื่อง
หรือติดต่อกับระบบปฏิบัติการ ซึ่ง component ต่างๆ มักเขียนในภาษา C (และ
assembly) ตัวอย่างที่เห็นได้ชัดเช่น Buffer-overflow attacks ที่พบใน
Java, Perl, หรือแม้แต่ .Net
เมื่อวิเคราะห์ถึงประเด็นสำคัญที่ทำให้เกิด Buffer-Overflow Attacks
แล้ว เราจะพบว่าปัญหาโดยตรงเกิดจากการที่ Input
ซึ่งเป็นข้อมูลที่นอกเหนือความควบคุมของผู้เขียนโปรแกรม
เข้ามาทำให้เกิดความเสียหายในระบบ จนทำให้การทำงานของโปรแกรมผิดไป [Howard
and LeBlanc] จาก Microsoft กล่าวในหนังสือ Threat Model ว่า “All input
is evil until proven otherwise” และเสนอว่า
ข้อมูลทุกอันต้องมีการตรวจสอบเมื่อมีการส่งผ่านขอบเขตของโปรแกรม (“Data
must be validated as it crosses the boundary between untrusted and
trusted environments.”) ซึ่งข้อคิดนี้ มิใช่แนวคิดใหม่
หากแต่ผู้เขียนโปรแกรมทั่วไปมักมิได้คำนึงถึง
Secure Bit 2 ซึ่งเป็นงานวิจัยของผู้เขียนเอง
เป็นเทคโนโลยีที่จะฝังหลักการดังกล่าวลงในระบบโดยผู้พัฒนาโปรแกรม
ไม่จำเป็นต้องคอยระมัดระวังตรวจสอบ Input ของตัวเองตลอดเวลา
(เพราะแม้นักพัฒนาซอฟต์แวร์มืออาชีพหลายคน
ยังกล่าวว่ามีบ่อยครั้งที่ไม่สามารถตรวจสอบตัวโปรแกรมได้ครบทุกกรณีในขณะพัฒนาตัวโปรแกรม)
รายละเอียดเพิ่มเติมศึกษาได้ที่
Secure Bit 2
บทสรุป
ในโอกาสต่อไป ผู้เขียนจะนำเสนอแนวทางการป้องกัน buffer overflow
แบบต่างๆ ที่นักวิจัยทัวโลกพยายามพัฒนากันออกมา
พร้อมกับชี้ให้เห็นข้อดีข้อเสีย โดยสรุปแล้ว buffer overflow
เป็นปัญหาพื้นฐานของระบบคอมพิวเตอร์ตั้งแต่เรามีคอมพิวเตอร์จนถึงปัจจุบัน
ยิ่งมีคอมพิวเตอร์ต่อไว้กับ internet มากขึ้นเพียงใด ก็มีเป้านิ่งให้
hackers ทั้งหลายได้โจมตีมาขึ้น
ประกอบกับแต่เดิมผู้พัฒนาซอฟต์แวร์รายใหญ่ๆ (อาที MS) เน้นขาย funtioncs
ใช้งาน และ มิได้ใส่ใจกับปัญหาดังกล่าวมากนัก
แม้ปัจจุบันจะมีแนวทางที่เสนอออกมามากมาย
แต่ก็ยังไม่มีแนวทางใดที่สมบูรณ์แบบ ทางแก้ปัญหาที่ดีที่สุด
อาจจะเป็นพยายามฝึกให้
นักพัฒนาซอฟต์แวร์ทั้งหลายใส่ใจกับโปรแกรมที่ตัวเองเขียนมากขึ้น
อ้างอิง/อ่านเพิ่มเติม
- MSU-CSE-05-9: Secure Bit2 : Transparent, Hardware Buffer-Overflow Protection, Krerk Piromsopa and Richard J. Enbody
- MSU-CSE-04-47: Buffer Overflow: the Fundamentals, Krerk Piromsopa and Richard J. Enbody
- MSU-CSE-04-48: Secure Bit : Hardware, Buffer-Overflow Prevention, Krerk Piromsopa and Matthew R. Fletcher and Richard J. Enbody
การทดสอบแบบนี้จะใกล้เคียงกับพฤติกรรมของ Hacker มากที่สุดคับ เราเรียกมันว่ากล่องดำเพราะผู้ทดสอบระบบจะไม่ได้รับข้อมูลในระบบมาก่อนเลยคับ
มีกล่องดำก็ต้องมีกล่องขาวคับ การทดสอบแบบนี้จะตรงกันข้ามกับ Black-box ตรงที่ Tester จะได้รับข้อมูลทั้งหมดในระบบจาก Admin ไม่ว่าจะเป็นข้อมูลทางด้าน Network, System หรือ Infrastructure ดั้งนั้น Tester สามารถจัดทำโครงสร้างและแผนงานต่างๆในการทดสอบระบบง่ายขึ้นคับ
ในการทดสอบแบบ Gray-box นั้น สถาบัน EC-Council จัดให้เป็นการทดสอบระบบจำลองการโจมตีแบบภายใน ดังนั้นจุดประสงค์ของการทดสอบแบบนี้คือการทดสอบในการป้องกันการโจมตีจากภายในองค์กร ไม่ว่าจะเป็นพนักงานหรือผู้ไม่ประสงค์ดีที่เดินก้าวเท้าเข้ามาในองค์กรเราได้คับ
กันนั้น ล้วนแล้วแต่เป็น
• ความรู้ทางด้าน Router, Routing protocol และ Access control lists (ACLs)
สิ่งที่ทุกองค์กรกลัวที่สุดก็คือความเสียหายที่ออกมาในรูปของเงินทอง ผมอยากให้ลองคิดถึงความเสียหายที่จะเกิดขึ้นถ้าหากองค์กรถูก hacked คับ เช่น จะเกิดอะไรขึ้นถ้าหากมีใครที่สามารถโอนเงินเข้าบัญชีของตัวเองได้อย่างอำเภอใจ หรือจะเกิดอะไรขึ้นถ้าหากมีใครสามารถสั่งซื้อของ ชำระค่าน้ำค่า ไฟโดยไม่ต้องเสียเงินตัวเองซักบาทเดียว หรือเกิดมีใครสามารถเปลี่ยนให้ซิมโทรศัพท์มือถือของตัวเองกลายเป็นซิม pre-paid ที่ใช้โทรได้ไปอีกเป็นสิบๆปีไม่ต้องเติมเงินอีกเลย ตัวอย่างที่ผมพูดมานี้ไม่ใช่เหตุการณ์สมมุติที่ผมจินตนาการเอาเองหรอกนะคับ แต่มันคือเหตุการณ์ที่เกิดขึ้นจริงๆไม่ใกล้ไม่ไกลในเมืองไทยของเรานี่แหล่ะคับ ลองคิดถามดูนะคับว่าเม็ดเงินจำนวนเท่าไหร่กันที่ผู้ประกอบการจะต้องเสียไปฟรีๆให้กับ Hacker จอมโลภเหล่านี้
คุณอาจจะมี IDS, IPS วางอยู่ที่ประตูใหญ่ ก่อนที่จะทะลุเข้ามาจนถึงกำแพงไฟ (Firewall) อีกสี่ชั้น ก่อนที่จะมี dynamic password หรือ cryptographic token เป็นนายทหารคอยคุมในแต่ละประตูย่อยก่อนเข้าสู่ข้อมูลอีกที แต่นั่นไม่ได้หมายความว่าจะไม่มีผู้ใดที่สามารถผ่านเข้าไปจนถึงด่านสุดท้ายได้หรอกคับ เพราะยังมีความจริงอยู่ข้อนึงก็คือไม่ว่าระบบจะน่าเชื่อถือ ฉลาดและราคาแพงซักเพียงใด ระบบเหล่านั้นถูกคุมด้วย admin ซึ่งเป็นมนุษย์คับ ยิ่งระบบมีความซับซ้อนเท่าไหร่ ความผิดพลาดที่จะก่อให้เกิดช่องโหว่ก็มากเท่านั้นล่ะคับ การจัดการเรื่องพวกนี้มันก็เหมือนกับการเล่นเกมเดาใจนั่นแหล่ะคับ เปิด policy นี้ ปิด port นั้น hacker คงหาทางเข้ามาไม่ได้แล้วล่ะน่า แต่จะไล่ปิดแค่ไหนก็ตาม ยังไงคงต้องมีซักประตูที่คุณเว้นเอาไว้เพื่อให้คนของคุณสามารถติดต่อสื่อสารกับภายนอกได้อยู่ดีล่ะคับ hacker ก็คือมนุษย์เหมือนกับคับ แต่เค้าคือมนุษย์ที่ฉลาด วันนี้เข้าประตูนี้ไม่ได้ วันอื่นก็ต้องหาทางเข้ามาจนได้ล่ะคับ