จากกรณีช่องโหว่ Flash ที่ค้นพบจากเอกสารของ Hacking Team จนสุดท้าย Adobe ต้องออก Flash เวอร์ชัน 18.0.0.209 มาแก้ไข ทางโครงการ Project Zero ของกูเกิลก็ออกมาอธิบายว่า Flash เวอร์ชันนี้ได้ปรับปรุงเทคนิคด้านหน่วยความจำหลายอย่าง ช่วยให้ Flash ปลอดภัยมากขึ้น
เทคนิคด้านหน่วยความจำเหล่านี้เป็นผลงานร่วมกันของกูเกิลกับ Adobe ทำให้มีเฉพาะ Chrome เท่านั้นที่ได้ประโยชน์จากเทคนิคเหล่านี้อย่างเต็มที่ (เพราะ Chrome ใช้ Flash เวอร์ชันพิเศษของตัวเอง) ส่วนเบราว์เซอร์ตัวอื่นๆ จะใช้ได้เฉพาะเทคนิคของฝั่ง Adobe บางอันเท่านั้น
หมายเหตุ: ข่าวนี้อ้างถึงหลักการด้านหน่วยความจำ ผู้อ่านควรมีพื้นเรื่อง data structure มาบ้างครับ
ช่องโหว่ของ Flash เรื่องหน่วยความจำ
กูเกิลอธิบายช่องโหว่ของ Flash ทั้งที่พบจากกรณีของ Hacking Team และพบในช่องโหว่อื่นๆ ว่ามักอยู่ในรูปการโจมตีแบบ Buffer overflow โดยผู้ประสงค์ร้ายจะนำวัตถุของตัวเองไปวางต่อท้ายหน่วยความจำ Heap ของ Flash แล้วพยายามให้ Flash เรียกหน่วยความจำเกินตำแหน่ง เพื่อรันโค้ดที่วางไว้
จากภาพด้านล่าง ผู้ประสงค์ร้ายจะวางวัตถุประเภท Vector ไปต่อท้าย Heap แล้วหาทางทำให้เกิด Buffer overflow ข้ามตำแหน่งไปยังวัตถุที่วางเอาไว้

เทคนิคอีกแบบที่คล้ายกันคือหาวิธีให้หน่วยความจำบริเวณ Buffer ถูกทำให้ว่าง (โดยที่ Flash เข้าใจว่ายังใช้งานอยู่ และมีอ้างอิงไปถึง) จากนั้นก็ใช้เทคนิคการเขียนข้อมูลทับลงไปในตำแหน่งเดิม ทำให้ Flash เผลอเรียกโค้ดที่แอบเอาไปใส่ในพื้นที่หน่วยความจำนั้น
เทคนิคนี้ใช้งานในช่องโหว่ของ Hacking Team

แนวทางลดความเสียหายจากช่องโหว่
กูเกิลใช้วิธี Heap partitioning เพื่อแยกวัตถุของแต่ละ Heap ออกจากกัน และคั่นกลางด้วยพื้นที่ว่างที่ไม่ใช้ประโยชน์อะไร (No man's land) ดังนั้นต่อให้แฮ็กเกอร์หาวิธีให้ Flash ทำ buffer overflow ได้ ก็จะเจอแต่ความว่างเปล่า
ตำแหน่งการวาง Heap ในหน่วยความจำจะเป็นแบบสุ่ม ดังนั้นถ้าเบราว์เซอร์ Chrome และ Flash คอมไพล์มาเป็น 64 บิตทั้งคู่ ก็จะสามารถอ้างตำแหน่งหน่วยความจำได้มากขึ้นมาก ช่วยให้เทคนิคการวาง Heap ได้ผลยิ่งขึ้นเพราะโอกาสที่จะสุ่มไปเจอ Heap ที่ต้องการนั้นลดลง
เทคนิคการ Heap partitioning ถูกใช้ในวงการเบราว์เซอร์มานานแล้ว และเพิ่งเริ่มนำมาใช้กับ Flash โดยตอนนี้ยังรองรับเฉพาะ Chrome เท่านั้น (Adobe มีแผนจะปรับใช้กับเบราว์เซอร์ตัวอื่นๆ ในเดือนสิงหาคม)

นอกจากเทคนิคของกูเกิลแล้ว ฝั่ง Adobe เองยังเริ่มใช้เทคนิคการตรวจสอบความยาวของวัตถุประเภท Vector โดยเก็บความยาวของหน่วยความจำไว้เป็นความลับ ถ้าหากแฮ็กเกอร์สามารถแก้ไขค่า length ของวัตถุได้ ก็จะต้องผ่านการเทียบขนาดอีกรอบอยู่ดี และถ้าขนาดไม่ตรงกัน Flash ก็จะไม่อนุญาตให้รันโค้ดส่วนนี้ตอนรันไทม์
ที่มา - Google Project Zero
on
คืนครูไปหมดแล้วครับ
darkleonic Sun, 19/07/2015 - 19:38
คืนครูไปหมดแล้วครับ
ถ้าเดาไม่ผิด เทคนิคนี้ Chrome
LazarusSP1 Sun, 19/07/2015 - 23:14
ถ้าเดาไม่ผิด เทคนิคนี้ Chrome ก็จะกินแรมเยอะกว่าเดิม เพราะต้องจองที่ว่างมากัน HEAP overflow ของพวก Flash ต่างๆ
อะไรนะ ให้แรมเยอะขึ้นอีกแล้วเหรอ
ว่าแต่ Flash Object ถ้าต้องทำ Preparing Stage ก่อนแสดงผล จะกระทบกับประสิทธิภาพ และ การใช้ทรัพยากรหน่วยประมวลผลเยอะขึ้นแค่ไหนเนี่ย
ไม่กินแรมเพิ่มครับ
nat3738 Mon, 20/07/2015 - 00:26
In reply to ถ้าเดาไม่ผิด เทคนิคนี้ Chrome by LazarusSP1
ไม่กินแรมเพิ่มครับ เค้าแมพเป็นเพจว่างเปล่าใน virtual memory เวลา อ่าน/เขียน จะ segfault ครับ ไม่มีแรมอยู่ตรงนั้นจริงๆ
และน่าจะเสีย 1 op
wiennat Tue, 21/07/2015 - 15:22
In reply to ถ้าเดาไม่ผิด เทคนิคนี้ Chrome by LazarusSP1
และน่าจะเสีย 1 op สำหรับเชคนู่นนี่ป้องกัน overflow ด้วย
ไม่ได้กินหน่วยความจำเยอะขึ้น
takwing Tue, 21/07/2015 - 16:17
In reply to ถ้าเดาไม่ผิด เทคนิคนี้ Chrome by LazarusSP1
ไม่ได้กินหน่วยความจำเยอะขึ้น แต่แค่ใช้ประโยชน์จาก address space ของ process นั้นๆได้น้อยลงเท่านั้นครับ เพราะ address space บางส่วนไม่ได้รับอนุญาติให้ถูก map เพื่อป้องกัน exploit แบบเดิมๆ
ดังนั้นด้วยวิธีใหม่นี้ ถ้าเกิดมีการพยายามจะทำให้เกิด heap overflow แล้วต่อมามีการ read หรือ write บน page ที่เรียกว่า no man's land หน่วย mmu ใน processor มันก็จะตรวจจับ access violation ทำให้เกิด segmentation fault ให้โปรแกรมหยุดทำงานทันที
ถ้าเกิด Flash Object นั้นไม่ได้ใหญ่โตมหาศาล ก็ไม่มีผลอยู่แล้ว เพราะในกรณีของ address space แบบ 32 บิต ปกติก็จะอ้างอิงได้ 4GB ในปัจจุบันคงจะเป็นแบบ 64 บิต ดังนั้น address space ที่ใช้ได้ก็จะมหาศาลเป็นทวีคูณขึ้นไปด้วย
จนเนื้อที่ที่ถูกกันไว้ที่เรียกว่า no man's land แทบจะไม่มีนัยอะไร
เมื่อไหร่จะเลิกใช้แฟลชสักที
Dakenfuverymuch Sun, 19/07/2015 - 23:35
เมื่อไหร่จะเลิกใช้แฟลชสักที
รอวันที่ Facebook ได้ใช้
Mekokung Mon, 20/07/2015 - 00:06
In reply to เมื่อไหร่จะเลิกใช้แฟลชสักที by Dakenfuverymuch
รอวันที่ Facebook ได้ใช้ HTML5 ตอนนั้นละเลิกเลย(ซึ่งตอนนี้ดูวีดีโอยังใช้ Flsah อยู่เลย #เศร้าใจเบา)
+1 เล่นผ่าน FacebookCoreWWWi
hisoft Mon, 20/07/2015 - 00:10
In reply to รอวันที่ Facebook ได้ใช้ by Mekokung
+1 เล่นผ่าน FacebookCoreWWWi เวลาจะดูวิดีโอทีนี่เหนื่อยมาก - -"
แต่ทำไม ผมดูวิดีโอ เป็น HTML5
jaideejung007 Mon, 20/07/2015 - 08:18
In reply to รอวันที่ Facebook ได้ใช้ by Mekokung
แต่ทำไม ผมดูวิดีโอ เป็น HTML5 แล้วนะครับ หรือผมฝันไปนะ?
ผมก็เป็น html5 แล้วครับ
Zatang Mon, 20/07/2015 - 09:10
In reply to แต่ทำไม ผมดูวิดีโอ เป็น HTML5 by jaideejung007
ผมก็เป็น html5 แล้วครับ แต่เข้าใจว่าคงค่อยๆ เปลี่ยน เพื่อนผมได้หลายสัปดาห์ก่อน ผมเพิ่งได้สัปดาห์ที่แล้ว
ผมได้ VDO Facebook แบบ HTML5
doanga2007 Mon, 20/07/2015 - 11:53
In reply to แต่ทำไม ผมดูวิดีโอ เป็น HTML5 by jaideejung007
ผมได้ VDO Facebook แบบ HTML5 แล้ว โดยมีวิธีได้ คือ ถ้ายังไม่มา ให้แจ้งปัญหาเรื่อง VDO Facebook แบบ HTML5 ที่ Report a problem ได้เลยครับ
Heap ในที่นี้ไม่ใช่ data
takwing Mon, 20/07/2015 - 02:08
Heap ในที่นี้ไม่ใช่ data structure ประเภท Heap ตามที่คุณเจ้าของบทความอ้างอิงไปที่วิกินี่ครับ
Heap ในที่นี้คือ memory region นึงของ address space ของ process ที่มีไว้สำหรับ dynamic allocation/deallocation
ก็งงอยุ่ว่าไม่เห็นมีต้นไม้หว่
thanyadol Mon, 20/07/2015 - 16:59
In reply to Heap ในที่นี้ไม่ใช่ data by takwing
ก็งงอยุ่ว่าไม่เห็นมีต้นไม้หว่า
Browser อื่นประกาศว่า
Hadakung Mon, 20/07/2015 - 11:21
Browser อื่นประกาศว่า เราไม่จำเป็นต้องเทคนิคนี้เพราะเราแนะนำให้ลูกค้าเราปิดมันซะ:P