การกำจัดช่องโหว่ด้านความปลอดภัยของหน่วยความจำตั้งแต่ต้นทาง

 (security.googleblog.com)
5 คะแนน โดย GN⁺ 2024-09-27 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

กำจัดต้นตอของช่องโหว่ด้านความปลอดภัยของหน่วยความจำ

ผลลัพธ์ที่ดูย้อนแย้ง

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

คำอธิบายทางคณิตศาสตร์

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

กรณีใช้งานจริงใน Android

  • ตั้งแต่ปี 2019 ทีม Android เริ่มเปลี่ยนงานพัฒนาใหม่ไปใช้ภาษาที่ปลอดภัยต่อหน่วยความจำ
  • ณ ปี 2024 ช่องโหว่ด้านความปลอดภัยของหน่วยความจำลดลงจาก 76% เหลือ 24%
  • เมื่อช่องโหว่ด้านความปลอดภัยของหน่วยความจำลดลง ความเสี่ยงด้านความปลอดภัยโดยรวมก็ลดลงด้วย

วิวัฒนาการของกลยุทธ์ด้านความปลอดภัยของหน่วยความจำ

  • รุ่นที่ 1: การแพตช์เชิงรับ - ค้นพบช่องโหว่แล้วจึงแก้ไข
  • รุ่นที่ 2: การบรรเทาเชิงรุก - ทำให้การใช้ประโยชน์จากช่องโหว่ทำได้ยากขึ้น
  • รุ่นที่ 3: การค้นหาช่องโหว่เชิงรุก - ค้นหาช่องโหว่ล่วงหน้า
  • รุ่นที่ 4: การป้องกันที่เชื่อถือได้สูง - เปลี่ยนไปใช้ภาษาที่ปลอดภัยต่อหน่วยความจำเพื่อป้องกันไม่ให้ช่องโหว่เกิดขึ้นตั้งแต่แรก

ข้อดีของการป้องกันที่เชื่อถือได้สูง

  • ตัดวงจรการแข่งขันที่ไม่มีวันจบระหว่างผู้ป้องกันกับผู้โจมตี
  • เพิ่มความปลอดภัยและลดต้นทุนผ่านภาษาที่ปลอดภัยต่อหน่วยความจำ
  • เพิ่มความถูกต้องของโค้ดและประสิทธิภาพการทำงานของนักพัฒนา

จากบทเรียนสู่การลงมือปฏิบัติ

  • ไม่จำเป็นต้องทิ้งหรือเขียนใหม่ทั้งหมดสำหรับโค้ดเดิมที่ไม่ปลอดภัยต่อหน่วยความจำ
  • เร่งการเปลี่ยนผ่านไปสู่ภาษาที่ปลอดภัยต่อหน่วยความจำด้วยการปรับปรุงการทำงานร่วมกัน
  • พัฒนาเครื่องมือเพื่อปรับปรุงการทำงานร่วมกันระหว่าง Rust กับ C++ และ Rust กับ Kotlin

บทบาทของแนวทางรุ่นก่อนหน้า

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

บทสรุป

  • การใช้ภาษาที่ปลอดภัยต่อหน่วยความจำกับโค้ดใหม่ทำให้ช่องโหว่ลดลงแบบเอ็กซ์โปเนนเชียล
  • ผลลัพธ์ที่สม่ำเสมอตลอดกว่า 6 ปีใน Android พิสูจน์ประสิทธิผลของแนวทางนี้

สรุปโดย GN⁺

  • การเปลี่ยนไปใช้ภาษาที่ปลอดภัยต่อหน่วยความจำมีความสำคัญต่อการลดช่องโหว่ด้านความปลอดภัยของหน่วยความจำ
  • กรณีของทีม Android แสดงให้เห็นว่าช่องโหว่ด้านความปลอดภัยของหน่วยความจำลดลงอย่างมาก
  • การปรับปรุงการทำงานร่วมกันเป็นแนวทางที่ใช้งานได้จริงกว่าการเขียนโค้ดเดิมใหม่ทั้งหมด
  • การใช้ภาษาที่ปลอดภัยต่อหน่วยความจำอย่าง Rust สามารถเพิ่มทั้งความปลอดภัยและประสิทธิภาพการทำงานได้พร้อมกัน

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-09-27
ความคิดเห็นบน Hacker News
  • การเปลี่ยนงานพัฒนาใหม่ไปใช้ภาษาแบบ memory-safe สามารถนำไปสู่การปรับปรุงที่มีความหมายได้
    • ง่ายกว่าและมีต้นทุนต่ำกว่าการพอร์ตทุกอย่างมาก
  • กราฟในบทความชัดเจนและกระชับ
    • การเลือกข้อมูลและการใส่ป้ายกำกับอย่างรอบคอบช่วยสื่อแนวคิดที่ต้องการได้อย่างง่ายดาย
  • ช่องโหว่ลดลงแบบเอ็กซ์โพเนนเชียล
    • การโฟกัสกับโค้ดใหม่เป็นเรื่องสำคัญ
    • โปรเจ็กต์ RiiR แบบหว่านแหเป็นการสิ้นเปลืองทรัพยากร
    • กลยุทธ์ที่ผู้เชี่ยวชาญ Rust แนะนำมีประสิทธิภาพที่สุดในการลดช่องโหว่ด้านหน่วยความจำให้น้อยที่สุด
  • ทีม Android สังเกตว่าอัตราการ rollback ของการเปลี่ยนแปลงใน Rust ต่ำกว่าครึ่งหนึ่งของ C++
  • มีความสัมพันธ์ระหว่างโค้ดใหม่กับช่องโหว่ด้านหน่วยความจำ
    • โค้ดที่เกี่ยวข้องกับฟีเจอร์ใหม่มีแนวโน้มรวมช่องโหว่มากกว่า
    • โค้ดเก่ามักค้นพบ edge case ผ่านการใช้งานจริง
  • ยากที่จะสรุปตายตัวว่าโค้ดใหม่เป็นสาเหตุของช่องโหว่ด้านหน่วยความจำ
    • มีช่องโหว่ที่มีผลกระทบสูงอย่างบั๊ก Heartbleed
  • ช่องโหว่ลดลงแบบเอ็กซ์โพเนนเชียล
    • การหยุดเพิ่มฟีเจอร์ใหม่อาจดีกว่าต่อความปลอดภัย
    • Windows LTSC อาจเป็นเวอร์ชันที่ปลอดภัยที่สุด
  • การเขียนโค้ดอย่างปลอดภัยช่วยเพิ่มทั้งความถูกต้องของโค้ดและประสิทธิภาพการทำงานของนักพัฒนา
    • ย้ายการพบบั๊กให้เกิดขึ้นก่อนการเช็กอินโค้ด
    • ทีม Android สังเกตว่าอัตราการ rollback ของการเปลี่ยนแปลงใน Rust ต่ำกว่าครึ่งหนึ่งของ C++
  • หลังจากค้นพบ Rust ก็ได้ความหลงใหลในการเขียนโปรแกรมกลับคืนมา
  • ในบรรดาภาษาแบบ memory-safe (MSL) มีการพูดถึงแค่ Rust
    • มีการกล่าวถึง Kotlin ด้วย แต่ความสามารถด้าน memory safety ไม่แข็งแกร่งเท่า Rust
  • อายุของช่องโหว่มีการกระจายแบบเอ็กซ์โพเนนเชียล
    • การทำให้โค้ดใหม่มี memory safety นั้นคุ้มค่ามาก
    • มีประโยชน์แม้ใน codebase แบบ legacy ขนาดใหญ่
  • โค้ดเก่าอาจไม่ได้รับการทบทวนอย่างเพียงพอ
    • มีการตรวจดู commit log ล่าสุดบ่อยกว่า
  • ความแตกต่างของภาษาที่ใช้เขียนโค้ดระหว่าง Mac กับ Windows
    • Mac ใช้ Swift ที่ memory-safe ส่วน Windows ใช้ C หรือ C++ เป็นหลัก
  • ยิ่งช่องโหว่หายากขึ้น ก็ยิ่งมีมูลค่าสูงขึ้น
    • ช่องโหว่ที่เหลืออยู่อาจถูกใช้โดยรัฐชาติในการโจมตีเป้าหมายมูลค่าสูง
    • อาจต้องมีฟีเจอร์อย่าง Lockdown Mode ของ iOS
    • ผู้ใช้ที่ใส่ใจความปลอดภัยสามารถติ๊กตัวเลือกความปลอดภัยเพื่อแลกกับประสิทธิภาพที่ลดลง
    • ตรวจจับการโจมตีและส่งต่อให้ทีมความปลอดภัยวิเคราะห์
    • ส่งคำเตือนไปยังผู้ใช้และแจ้งว่าตรวจพบการโจมตี
    • แทนที่จะเฝ้าติดตามกิจกรรมของผู้ใช้อย่างเงียบ ๆ ให้แจ้งผู้ใช้เมื่อมีการตรวจพบการโจมตี