Blognone เสนอข่าว "ช่องโหว่" ความปลอดภัยซอฟต์แวร์เป็นจำนวนมาก แม้ช่องโหว่หลายอย่างมาจากการวิเคราะห์ทางคณิตศาสตร์ของกระบวนการเข้ารหัสที่ซับซ้อนแต่ในความเป็นจริงแล้ว ช่องโหว่ส่วนมากมาจากปัญหาเหมือนๆ กันคือการไม่ระวังการใช้บัฟเฟอร์ ทำให้ข้อมูลที่วางลงไปยังบัฟเฟอร์มีขนาดเกินที่เผื่อไว้ ทำให้แฮกเกอร์เข้ามาวางโค้ดเอาไว้ และควบคุมให้มีการรันโค้ดนั้นๆ ได้

กระบวนการแฮกจากช่องโหว่บัฟเฟอร์เป็นกระบวนพื้นฐานอันหนึ่งที่ควรรู้เพื่อจะศึกษาและป้องกันช่องโหว่ในซอฟต์แวร์

Stack Buffer Overflow

{syntaxhighlighter brush:cpp}#include <string.h>

void foo (char *bar)
{
char c[12];
strcpy(c, bar); // ไม่ตรวจขนาด input
}

int main (int argc, char **argv)
{
foo(argv[1]);
}{/syntaxhighlighter}

ปัญหาช่องโหว่บัฟเฟอร์เกิดได้ง่ายๆ จากความไม่ระมัดระวังในการนำข้อมูลเข้าสู่บัฟเฟอร์ ตัวอย่างข้างต้นเพียงแค่โปรแกรมเมอร์ไม่ยอมตรวจสอบก่อนว่าข้อมูลที่รับเข้ามาขนาดเกินบัฟเฟอร์ที่เตรียมไว้หรือไม่ ก็สร้างช่องโหว่นี้ได้ โดยหากเป็นการนำข้อมูลเข้าบัฟเฟอร์ที่เป็น stack (ตัวแปรที่ประกาศพื้นที่แน่นอนในฟังก์ชั่น) ก็จะเรียกว่า stack buffer overflow ส่วนถ้าเป็นตัวบัฟเฟอร์ที่ขอพื้นที่ใหม่ภายหลัง (ผ่าน malloc/new/HeapAlloc) ก็จะเรียกว่า heap buffer overflow


โดยปกติแล้ว โครงสร้างของ stack จะประกอบด้วยตัวแปรของแต่ละฟังก์ชั่น พร้อมกับจุดย้อนกลับ (return address) ซึ่งเป็นจุดของโค้ดที่เรียกฟังก์ชั่นเข้ามา เพื่อให้โปรแกรมสามารถย้อนกลับไปเมื่อออกจากฟังก์ชั่นได้ เมื่อแฮกเกอร์สามารถสร้างข้อมูลที่เขียนทับ return address นี้ได้ ก็จะกำหนดได้ว่าต้องการใช้โปรแกรมไปรันโค้ดส่วนใดก็ได้ ในกรณีนี้โปรแกรมตัวอย่างสร้าง char bar[12] เอาไว้ เราจะเห็นว่าจริงๆ แล้วภายในโครงสร้างหน่วยความจำมันเป็นพอยเตอร์วางคู่กับพื้นที่หน่วยความจำจริงๆ ด้านบนเป็นหน่วยความจำที่ยังไม่ได้ใช้งาน โดยจะถูกเรียกใช้เมื่อมีการเรียกฟังก์ชั่น ด้านล่างพื้นที่ของฟังก์ชั่นที่เรียกฟังก์ชั่นปัจจุบัน


การทำงานโดยปกติ ข้อมูลอินพุตจะถูกวางเข้าไปในบัฟเฟอร์ โดยไม่รบกวนตัวแปรรอบข้าง


แต่เนื่องจากไม่มีการตรวจสอบให้ดี ผู้เรียกใช้ฟังก์ชั่น (ที่อาจจะเรียกผ่านเครือข่ายจากระยะไกล) สามารถวางข้อมูลอย่างจงใจ ให้ข้อมูลล้นเกินบัฟเฟอร์ที่เตรียมไว้ แล้วเปลี่ยน return address ไป ในกรณีตัวอย่างคือเปลี่ยนค่าให้กลับไปรันในข้อมูลบัฟเฟอร์ที่เพิ่งใส่ให้เอง ทำให้สามารถกำหนดให้โปรแกรมรันอะไรก็ได้ตามที่แฮกเกอร์ต้องการ

ปัญหา buffer overflow นี้ถูกใช้ในเวิร์มตัวแรกของโลก คือ Morris Worm ที่อาศัยฟังก์ชั่น gets ซึ่งไม่มีการกำหนดขนาดบัฟเฟอร์ และมีปัญหา stack buffer overflow เรื่อยมา จากโปรแกรม fingerd ที่เครื่องยูนิกซ์ในยุคนั้นมีรันทิ้งไว้แทบทุกเครื่อง ทำให้เวิร์มแพร่กระจายไปอย่างรวดเร็ว ในยุคหลัง คู่มือการเขียนโปรแกรมทั้งหมด จึงเตือนไม่ให้ใช้ฟังก์ชั่น gets และ puts อีกต่อไป

Arc Injection

การป้องกัน stack buffer overflow ในช่วงหลัง ทำโดยห้ามไม่ให้รันโค้ดใดๆ ในพื้นที่ที่เป็น stack อีกต่อไป (Data Execution Prevention - DEP) ทำให้การวางโค้ดลงในบัฟเฟอร์แล้วชี้กลับมาที่โค้ดเพื่อให้ซีพียูทำตาม ไม่สามารถทำได้อีกต่อไป กระบวนการแนวใหม่คือการวางข้อมูลที่จะกระตุ้นให้เกิดผลตามที่แฮกเกอร์ต้องการ

ตัวอย่างหนึ่งของการทำ Arc Injection คือ การเปลี่ยนค่า return address ให้กลายเป็นฟังก์ชั่น system พร้อมกับระบุค่าอาร์กิวเมนต์ของฟังก์ชั่นให้เป็นบัฟเฟอร์ที่ใส่เข้าไป ทำให้แฮกเกอร์สามารถเรียกคำสั่งอะไรก็ได้ ตามต้องการในเครื่องของเหยื่อ

การทำ Arc Injection อาจจะเป็นการใช้โค้ดของเหยื่อเอง เช่น ใส่ข้อมูลจนล้นเพื่อไปเปลี่ยนตัวแปรอื่นๆ แต่หากเป็นการเปลี่ยนข้อมูลเพื่อเรียกไลบรารี มักเรียกกันว่าการโจมตีแบบ return-to-libc

Pointer Subterfuge

นอกจากกระบวนการ "เติม" ข้อมูลเพื่อให้โปรแกรมทำงานตามที่แฮกเกอร์ต้องการแล้ว ยังมีอีกกระบวนการหนึ่ง คือการเปลี่ยนการทำงานของโปรแกรมด้วยการเปลี่ยนพอยเตอร์ ที่เรียกกระบวนการนี้ว่า Pointer Subterfuge ทำได้ในกรณีที่หน่วยความจำที่ต่อท้ายบัฟเฟอร์เป็นพอยเตอร์ไปยังฟังก์ชั่น กรณีเช่นนี้แฮกเกอร์สามารถเข้าไปกำหนดจุดที่ฟังก์ชั่นจะถูกเรียกได้

{syntaxhighlighter brush:cpp}void foo(void (*in_f)(),void * arg, size_t len)
{
char buf[256];
void (*f)() = in_f;

memcpy(buf,arg,len);
f();

return;

}{/syntaxhighlighter}

ฟังก์ชั่นตัวอย่างแสดงให้เห็นฟังก์ชั่นที่เสียงต่อการถูกเปลี่ยนค่าในพอยเตอร์ไปยังฟังก์ชั่น หากแฮกเกอร์สามารถรู้ได้ว่าฟังก์ชั่นที่ต้องการนั้นอยู่ที่พื้นที่หน่วยความจำใด ก็สามารถเรียกฟังก์ชั่นนั้นได้ตามใจชอบ

กระบวนการ Pointer Subterfuge นั้นแบ่งออกเป็นแบบย่อยๆ ได้อีกสามแบบ ได้แก่ Function Pointer Subterfuge ที่แสดงในตัวอย่าง, Data Pointer Subterfuge ที่เป็นการเปลี่ยนจุดชี้ข้อมูล ทำให้โปรแกรมทำงานตามที่ต้องการ คล้ายกับการทำ Arc Injection, และ VPTR Smashing ที่เป็นรูปแบบเฉพาะของภาษา C++ ที่ทุกออปเจกต์จะมีพอยเตอร์ไปยังตาราง virtual function (VTBL) เพราะแต่ละออปเจกต์นั้นอาจจะมีฟังก์ชั่นที่ต่างกันไป หากแฮกเกอร์สามารถย้ายจุดชี้ไปยังตารางนี้ได้ ก็เท่ากับสามารถทำให้โปรแกรมเรียกฟังก์ชั่นใดก็ได้ตามต้องการ

Heap Overflow

ส่วนสุดท้ายที่ยากที่สุดของการเจาะช่องโหว่ Buffer Overflow คือการเจาะผ่านหน่วยความจำ heap ที่ไม่ได้ป้องกันไว้ดีเพียงพอ โดยทั่วไปแล้ว บัฟเฟอร์ในหน่วยความจำ heap นี้ยากต่อการเจาะมาก เพราะหน่วยความจำที่ขอขึ้นใหม่ระหว่างการรันโปรแกรมผ่านฟังก์ชั่น malloc หรือฟังก์ชั่น HeapAlloc นั้นมีพื้นที่เปลี่ยนไปทุกครั้งที่โปรแกรมรัน

การทำ Heap Overflow อาศัยการขอหน่วยความจำแต่ละครั้ง ระบบปฎิบัติการจะคืนค่าหน่วยความจำที่มี header ของหน่วยความจำก้อนนั้นๆ มาด้วย เพื่อให้ระบบปฎิบัติการสามารถตรวจสอบได้ว่า หน่วยความจำส่วนใดเลิกใช้งานแล้ว และว่างเป็นพื้นที่เท่าใด การที่หน่วยความจำ heap ถูกเขียนจนเกินพื้นที่ จะทำให้ header ของก้อนหน่วยความจำถัดไปที่วางติดกันถูกเขียนทับ เมื่อมีการคืนหน่วยความจำ ทำให้ระบบปฎิบัติการพยายามคืนหน่วยความจำผิดไปจากที่ขอหน่วยความจำไว้ ทำให้โปรแกรมเกิด segmentation fault เวลาที่รายงานปัญหาประเภทนี้ จะมีรายงานว่าเกิด Denial-of-Service (DoS)

แต่ความอันตรายของ Heap Overflow ไม่ได้หยุดเพียงแค่นั้น แฮกเกอร์ที่เข้าใจกระบวนการทำงานของระบบปฎิบัติการเป็นอย่างดี จะรู้ที่ที่ส่วนหัวของหน่วยความจำนั้น เป็นพอยเตอร์ไปยังก้อนหน่วยความจำก่อนหน้า (bk - back pointer) และก้อนหน่วยความจำก้อนถัดไป (fd - forward pointer) เมื่อหน่วยความจำก้อนใดถูกคืนกลับสู่ระบบ ฟังก์ชั่น ulink ของระบบปฎิบัติการจะเข้าไปดูหน่วยความจำก้อนนั้นๆ แล้วเปลี่ยนตัวแปร fd ของหน่วยความจำก้อนก่อนหน้าให้กลายเป็น bk ของหน่วยความจำก้อนต่อไป และเปลี่ยน bk หน่วยความจำก้อนถัดไป ให้ชี้ไปที่หน่วยความจำก้อนก่อนหน้า

แฮกเกอร์บางคนอาศัยพฤติกรรมนี้ เปลี่ยนค่า fd และ bk ให้กลายเป็นตำแหน่งของฟังชั่นพื้นฐาน เช่น free โดยอาศัยความจริงที่ว่า การเรียกฟังก์ชั่นพื้นฐานจำนวนมาก จริงๆ แล้วเป็นการเรียกผ่านตารางพอยเตอร์ไปยังฟังก์ชั่น เรียกตารางนั้นว่า global offset table (GOT) เมื่อเปลี่ยนค่าพอยเตอร์ของตารางนี้ได้ผ่านกระบวนการ Heap Overflow ทำให้เมื่อมีการคืนความจำหลังจากถูกโจมตีด้วยฟังก์ชั่น free จะกลายเป็นการเรียกฟังก์ชั่นใดๆ ที่แฮกเกอร์ต้องการ เช่น คำสั่ง system

การป้องกัน Buffer Overflow

การป้องกัน Buffer Overflow ที่ดีที่สุดคงเป็นการเขียนโปรแกรมอย่างถูกต้อง รับรู้อย่างชัดเจนว่าข้อมูลส่วนใดที่เชื่อถือไม่ได้ เป็นข้อมูลจากผู้ส่งที่อาจจะเป็นผู้ไม่หวังดีต่อระบบ การตรวจสอบ และจำกัดพื้นที่การใช้หน่วยความจำอย่างระมัดระวังในภาษาโปรแกรมมิ่งใหม่ๆ ช่วยลดปัญหาเหล่านี้ได้เป็นอย่างดี

แต่ซอฟต์แวร์ที่ไม่มีบั๊กย่อมไม่มีในโลก ทุกวันนี้กระบวนการเพิ่มการตรวจสอบเพื่อให้การโจมตีแบบนี้ทำได้ยากขึ้นมีการพัฒนาขึ้นทุกวัน กระบวนการเหล่านี้อาศัยความร่วมมือกันระหว่างผู้ผลิตซีพียูและผู้ผลิตระบบปฎิบัติการ

ฟีเจอร์ NX (No Execution) ทำให้ระบบปฎิบัติการสามารถบอกซีพียูได้ว่า ส่วนใดของหน่วยความจำสามารถรันเป็นโปรแกรมได้ และส่วนใดห้ามรัน หากมีความพยายามจะรันโปรแกรมจากหน่วยความจำเหล่านั้นจะทำให้โปรแกรมหยุดทำงาน แต่แฮกเกอร์ก็พยายามรันผ่านระบบ shell ผ่านคำสั่ง system ได้

ฟีเจอร์ ASLR เป็นการสุ่มตำแหน่งของฟังก์ชั่นต่างๆ ในระบบรวมถึงฟังก์ชั่น system ที่มักใช้โจมตีระบบ แม้แฮกเกอร์จะสามารถเข้ามาแก้ไขให้รันโค้ดที่ตำแหน่งต่างๆ ได้เอง แต่ถ้าไม่สามารถหาตำแหน่งของฟังก์ชั่นที่ต้องการได้ ก็ยากที่จะควบคุมให้โปรแกรมทำงานตามที่ต้องการได้

การแข่งขัน

พัฒนาการของการป้องกันซอฟต์แวร์ยังคงมีไปอย่างต่อเนื่อง ทุกวันนี้กระบวนการสุ่มตำแหน่งของฟังก์ชั่นถูกตรวจสอบให้ "สุ่มให้คาดเดาได้ยาก" หลายระบบปฎิบัติการที่ยังยอมรับไลบรารีเก่าที่ไม่รองรับ ASLR เริ่มมีกระบวนการเปลี่ยนผ่าน ด้วยการไม่ยอมรับไลบรารีเก่าๆ เหล่านั้นเป็นค่าเริ่มต้น และโปรแกรมเมอร์ถูกฝึกให้พัฒนาโค้ดในระบบที่มีการป้องกันหลายชั้นก่อนโค้ดจะถูกรันในซีพียูจริง เช่น ภาษาสคริปต์ หรือภาษาที่มีการจัดการ (managed) อย่างจาวาหรือ C# กระบวนการเหล่านี้ช่วยลดช่องโหว่จากโปรแกรมเมอร์มือใหม่ได้เป็นอย่างดี แต่พร้อมๆ กันก็สร้างช่องโหว่จากแพลตฟอร์มที่มีการใช้งานอย่างกว้างขวางอย่างในกรณีของจาวาเอง

กระบวนการเจาะระบบด้วยบัฟเฟอร์เป็นเพียงรูปแบบหนึ่งของการเจาะระบบ ซอฟต์แวร์ที่ซับซ้อนขึ้นเรื่อยๆ สร้างช่องโหว่รูปแบบใหม่ๆ ที่ไม่มีใครคิดถึงในสิบปีก่อนได้ทุกวัน ทำให้ความปลอดภัยคอมพิวเตอร์ยังเป็นหัวข้อวิจัยที่ยังมีงานวิจัยใหม่ๆ จำนวนมากในทุกวันนี้