Tags:
Node Thumbnail

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

No Description

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

No Description

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

No Description

แต่เนื่องจากไม่มีการตรวจสอบให้ดี ผู้เรียกใช้ฟังก์ชั่น (ที่อาจจะเรียกผ่านเครือข่ายจากระยะไกล) สามารถวางข้อมูลอย่างจงใจ ให้ข้อมูลล้นเกินบัฟเฟอร์ที่เตรียมไว้ แล้วเปลี่ยน 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# กระบวนการเหล่านี้ช่วยลดช่องโหว่จากโปรแกรมเมอร์มือใหม่ได้เป็นอย่างดี แต่พร้อมๆ กันก็สร้างช่องโหว่จากแพลตฟอร์มที่มีการใช้งานอย่างกว้างขวางอย่างในกรณีของจาวาเอง

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

Get latest news from Blognone

Comments

By: 0FFiiz
Windows PhoneAndroidWindows
on 3 November 2012 - 17:19 #501036
0FFiiz's picture

สุดยอดครับ

By: narate
AndroidUbuntu
on 3 November 2012 - 17:39 #501039
narate's picture

ขอบคุณสำหรับบาทความครับ

By: Charin Tapang
ContributorAndroidRed HatUbuntu
on 3 November 2012 - 17:51 #501045
Charin Tapang's picture

โอ้เกิดอาการอยากแฮกขึ้นมาเลยครับ

By: iStyle
ContributoriPhoneAndroidSymbian
on 3 November 2012 - 17:53 #501047
iStyle's picture

บทความนี้มัน @_@

แต่ชอบนะครับ ขอบคุณสำหรับบทความ


May the Force Close be with you. || @nuttyi

By: kswisit
ContributoriPhoneAndroidIn Love
on 3 November 2012 - 19:09 #501079

เคยทำ method replacer (เอา address ของ method ของเราไปแทนที่ method เดิมของโปรแกรมที่เรียกใช้)

แล้วก็ work ซะด้วย :)


^
^
that's just my two cents.

By: caznova
AndroidRed HatUbuntuWindows
on 3 November 2012 - 20:45 #501099
caznova's picture

งงคำนี้ คับ

" โดยหลังครั้งที่หนวยความจําที่ตอทาย บัฟเฟอรเป็นพอยเตอรไปยังฟังกชั่น"

By: lew
FounderJusci&#039;s WriterMEconomicsAndroid
on 5 November 2012 - 15:40 #501781 Reply to:501099
lew's picture

แก้แล้วนะครับ


lewcpe.com, @wasonliw

By: EThaiZone
ContributorAndroidUbuntuWindows
on 3 November 2012 - 22:29 #501130
EThaiZone's picture

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

ทุกวันนี้โปรแกรมที่ทนทานที่สุดคือ.... Hello world!

ปล. กลัวพวกตรรกะเมพบอกยูนิกส์/ลินุกส์อันตรายเพราะเปิดโค้ดคนอ่านได้หมด ส่วนวินโดวส์ปลอดภัยสุดๆ เพราะไม่มีคนรู้ว่าโปรแกรมเมอร์เขียนอะไรลงไปเลยเดาไม่ได้


มันไม่ง่ายเลยที่จะทำ GIF ให้มีขนาดน้อยกว่า 20kB

By: Charin Tapang
ContributorAndroidRed HatUbuntu
on 3 November 2012 - 23:07 #501145 Reply to:501130
Charin Tapang's picture

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

By: BLiNDiNG
AndroidUbuntuWindowsIn Love
on 4 November 2012 - 02:47 #501205 Reply to:501130
BLiNDiNG's picture

ต้องมองว่า Open Source พวกนี้เหมือน wiki ครับ (ผมเดาว่าจริงๆแล้ว wiki เอาไอเดียมาจาก Open Source)

เพราะมันเปิดไว้ทำให้มีคนไปดูเยอะ มีคนไปเจอข้อผิดพลาดได้ง่าย เหมือนช่วยกันตรวจ (จริงๆแล้วคือช่วยตรวจเพราะตัวเองจะเอาไปใช้เลยกลัวเหมือนกัน 55)

แต่ของ windows คนตรวจได้ลำบาก คนที่เจอได้ก็คือคนที่ตั้งใจจะหาให้ได้นั่งทดลองไปเรื่อยแต่ละวิธี ซึ่งมักจะเป็นผู้มีจุดประสงค์อยู่แล้ว

By: lew
FounderJusci&#039;s WriterMEconomicsAndroid
on 4 November 2012 - 19:35 #501335 Reply to:501130
lew's picture

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

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


lewcpe.com, @wasonliw

By: SaMzAn
Windows PhoneWindows
on 3 November 2012 - 22:45 #501136
SaMzAn's picture

ขอบคุณครับ สำหรับบทความดีๆ ^^

By: picharnan
iPhoneWindows PhoneAndroidRed Hat
on 3 November 2012 - 23:59 #501163
picharnan's picture

ขอบคุณมากครับสำหรับบทความ ทำให้ได้ทราบแนวทางในการปรับแต่ง Code ชาวบ้านเค้า ถึงแม้ว่าจะรู้ว่าทำไงบ้างก็เถอะแต่ก็ไม่ง่ายเลยที่จะสามารถทำได้ :)

By: Perl
ContributoriPhoneUbuntu
on 4 November 2012 - 08:59 #501229
Perl's picture

ประเทืองปัญญาดี ขอบคุณครับผม

By: POR2U
iPhoneWindows PhoneAndroidBlackberry
on 4 November 2012 - 15:07 #501291
POR2U's picture

เป็นบทความที่มีประโยชน์ต่อคนจำนวนมาก เป็นบทความที่ดีจริงๆครับ

By: lovemoon
UbuntuWindows
on 4 November 2012 - 15:38 #501300
lovemoon's picture

ขอบคุณครับ แต่อ่านแล้วงง ความรู้คงไม่ถึง

By: Go-Kung
iPhoneWindows PhoneAndroidBlackberry
on 5 November 2012 - 17:41 #501833

ใบหน้าอ.ที่สอนวิชา Programming Language ลอยขึ้นมาในหัวทันที

แต่ผมกลับจำได้แต่หน้าของอ.ท่าน ส่วนเนื้อหาลืมไปหมดแล้ว T T

By: dangsystem
iPhoneAndroidBlackberryWindows
on 5 November 2012 - 23:06 #501981
dangsystem's picture

ไม่เคยสนใจเลย สงสัยต้องดูๆบ้างและ