นักพัฒนาโต้เถียงคำนิยามของ Memory Safety ขณะที่รัฐบาลผลักดันการใช้งาน

การผลักดันของรัฐบาลเมื่อเร็วๆ นี้เพื่อให้ใช้ภาษาโปรแกรมมิ่งที่มี memory safety ได้จุดประกายการโต้เถียงทางเทคนิคอย่างเข้มข้นในหมู่นักพัฒนาเกี่ยวกับสิ่งที่ถือว่าเป็น memory safety จริงๆ ในขณะที่หน่วยงานอย่าง NSA และ CISA สนับสนุนภาษาอย่าง Rust , Java และ C# เพื่อลดช่องโหว่ด้านความปลอดภัย ชุมชนโปรแกรมเมอร์กำลังตั้งคำถามว่าคำนิยามอย่างเป็นทางการนั้นมีความแม่นยำเพียงพอหรือไม่

สстатิสติกความปลอดภัยที่สำคัญ:

• 67% ของช่องโหว่ zero-day ที่ถูกค้นพบในปี 2021 เกี่ยวข้องกับความปลอดภัยของหน่วยความจำ
• เปอร์เซ็นต์นี้ยังคงสม่ำเสมอตลอด 20 ปีที่ผ่านมา
• ช่องโหว่ด้านความปลอดภัยของหน่วยความจำเป็นหนึ่งในประเภทที่ใหญ่ที่สุดของปัญหาความปลอดภัยซอฟต์แวร์

ความสับสนเรื่อง Data Race

ประเด็นหลักที่เป็นที่ถกเถียงกันคือการป้องกัน data race ควรถือว่าเป็นส่วนหนึ่งของ memory safety หรือไม่ นักวิจารณ์โต้แย้งว่าเอกสารของรัฐบาลมีการปฏิบัติต่อข้อกำหนดนี้อย่างไม่สอดคล้องกัน ภาษาอย่าง Java และ C# ถูกจัดอยู่ในกลุ่มที่มี memory safety แม้ว่าจะยอมให้เกิด data race ได้ ในขณะที่เอกสารบางครั้งแนะนำว่าการปลอดจาก data race เป็นสิ่งจำเป็นสำหรับ memory safety ที่แท้จริง

การโต้เถียงนี้เผยให้เห็นความไม่เห็นด้วยกันในเรื่องลำดับความสำคัญด้านความปลอดภัย นักพัฒนาบางคนโต้แย้งว่า data race ในภาษาที่มี garbage collection ไม่ค่อยนำไปสู่ช่องโหว่ที่สามารถถูกใช้ประโยชน์ได้ ทำให้มีความสำคัญน้อยกว่าบั๊กจากการเสียหายของหน่วยความจำแบบดั้งเดิมอย่าง buffer overflow คนอื่นๆ ยืนยันว่า data race สามารถสร้างช่องโหว่ด้านความปลอดภัยที่ร้ายแรงได้ โดยชี้ไปที่ตัวอย่างเช่นช่องโหว่ double-spending ในแอปพลิเคชันทางการเงินที่การดำเนินการพร้อมกันสามารถทำให้ยอดเงินในบัญชีเสียหายได้

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

ภาษาโปรแกรมที่ปลอดภัยต่อหน่วยความจำที่ระบุในเอกสารของรัฐบาล:

• Ada
• C
• Delphi/Object Pascal
• Go
• Java
• Python
• Ruby
• Rust
• Swift

วิธีแก้ปัญหาทางเลือกที่ถูกมองข้าม

การสนทนาในชุมชนยังเน้นย้ำถึงความหงุดหงิดกับการมุ่งเน้นแคบๆ ไปที่ภาษาที่มี memory safety ในกระแสหลัก นักพัฒนาบางคนชี้ไปที่โครงการทดลองอย่าง Fil-C ซึ่งมีเป้าหมายที่จะทำให้โค้ด C ที่มีอยู่มี memory safety ผ่านการปรับเปลี่ยน compiler และการตรวจสอบ runtime แม้ว่าโครงการดังกล่าวจะเผชิญกับความท้าทายในการใช้งานเนื่องจาก performance overhead และการสนับสนุนจากสถาบันที่จำกัด แต่ผู้สนับสนุนโต้แย้งว่าควรได้รับการพิจารณามากขึ้นสำหรับ legacy codebase

การแลกเปลี่ยนด้านประสิทธิภาพยังคงเป็นจุดติดขัด วิธีแก้ปัญหาที่เพิ่ม memory safety ให้กับ C มักจะมี performance penalty 20-50% ทำให้ไม่เหมาะสมสำหรับแอปพลิเคชันที่ต้องการประสิทธิภาพสูง อย่างไรก็ตาม ผู้สนับสนุนโต้แย้งว่าซอฟต์แวร์ส่วนใหญ่ไม่ได้มีความไวต่อประสิทธิภาพมากพอที่จะเป็นเหตุผลสำหรับความเสี่ยงด้านความปลอดภัย

การแลกเปลี่ยนด้านประสิทธิภาพ:

• Fil-C (โซลูชันความปลอดภัยหน่วยความจำ C แบบทดลอง): ค่าใช้จ่ายด้านประสิทธิภาพ 20-50%
• โซลูชันฮาร์ดแวร์อย่าง CHERI มีค่าใช้จ่ายที่ต่ำกว่าแต่ต้องใช้ฮาร์ดแวร์เฉพาะทาง
• โซลูชันความปลอดภัยหน่วยความจำแบบซอฟต์แวร์โดยทั่วไปจะเสียสละประสิทธิภาพเพื่อความปลอดภัย

ความท้าทายในการนำไปใช้จริง

นอกเหนือจากคำนิยามทางทฤษฎีแล้ว นักพัฒนายังต่อสู้กับกลยุทธ์การย้ายระบบในโลกแห่งความเป็นจริง ชุมชนแนะนำให้มุ่งเน้นไปที่แนวทางแบบค่อยเป็นค่อยไป เช่น การแทนที่ dependency ที่ไม่ปลอดภัยด้วยทางเลือกที่มี memory safety สำหรับส่วนประกอบที่สำคัญอย่าง file parser และ image processor แนวทางที่มีเป้าหมายชัดเจนนี้สามารถให้ประโยชน์ด้านความปลอดภัยโดยไม่ต้องเขียน codebase ขนาดใหญ่ใหม่ทั้งหมด

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

มองไปข้างหน้า

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

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

อ้างอิง: Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development