นักวิเคราะห์ยินดีรับคำแนะนำจาก NSA สำหรับนักพัฒนาในการใช้ภาษาที่ปลอดภัยต่อหน่วยความจำ

นักวิเคราะห์ด้านความปลอดภัยยินดีกับคำแนะนำจากสำนักงานความมั่นคงแห่งชาติของสหรัฐฯ (NSA) เมื่อสัปดาห์ที่แล้วสำหรับนักพัฒนาซอฟต์แวร์ในการพิจารณาเลือกใช้ภาษาต่างๆ เช่น C#, Go, Java, Ruby, Rust และ Swift เพื่อลดช่องโหว่ที่เกี่ยวข้องกับหน่วยความจำในโค้ด

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

กรณีสำหรับภาษาที่ปลอดภัยต่อหน่วยความจำ

คำแนะนำที่ค่อนข้างผิดปกติของ NSA เมื่อวันที่ 10 พ.ย. ชี้ไปที่ภาษาที่ใช้กันอย่างแพร่หลาย เช่น C และ C++ เช่น พึ่งพาโปรแกรมเมอร์มากเกินไป เพื่อไม่ให้เกิดข้อผิดพลาดเกี่ยวกับหน่วยความจำซึ่งยังคงเป็นสาเหตุอันดับต้น ๆ ของช่องโหว่ด้านความปลอดภัยในซอฟต์แวร์ การศึกษาก่อนหน้า — หนึ่งโดย Microsoft ในปี 2019 และอื่น ๆ จาก Google ในปี 2020 ที่เกี่ยวข้องกับเบราว์เซอร์ Chrome ตัวอย่างเช่น ช่องโหว่ทั้งสองพบว่า 70% เป็นปัญหาด้านความปลอดภัยของหน่วยความจำ NSA กล่าว

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

C#, Go, Java, Ruby, Rust, Swift และภาษาที่ปลอดภัยต่อหน่วยความจำอื่น ๆ ไม่สามารถขจัดความเสี่ยงของปัญหาเหล่านี้ได้อย่างสมบูรณ์ NSA กล่าวในคำแนะนำ ตัวอย่างเช่น ส่วนใหญ่มีคลาสหรือฟังก์ชันอย่างน้อยสองสามคลาสที่ไม่ปลอดภัยสำหรับหน่วยความจำ และอนุญาตให้โปรแกรมเมอร์ดำเนินการฟังก์ชันการจัดการหน่วยความจำที่อาจไม่ปลอดภัย บางครั้งภาษาที่ปลอดภัยต่อหน่วยความจำอาจรวมถึงไลบรารีที่เขียนด้วยภาษาที่มีฟังก์ชันหน่วยความจำที่อาจไม่ปลอดภัย

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

Tim Mackey หัวหน้านักกลยุทธ์ด้านความปลอดภัยของ Synopsys Cybersecurity Research Center ยินดีกับคำแนะนำของ NSA การใช้ภาษาที่ปลอดภัยต่อหน่วยความจำควรเป็นค่าเริ่มต้นสำหรับแอปพลิเคชันส่วนใหญ่ เขากล่าว “เพื่อวัตถุประสงค์ในทางปฏิบัติ การพึ่งพานักพัฒนาเพื่อให้ความสำคัญกับปัญหาการจัดการหน่วยความจำแทนที่จะเขียนโปรแกรมฟีเจอร์ใหม่ๆ เจ๋งๆ ถือเป็นภาษีสำหรับนวัตกรรม” เขากล่าว Mackey กล่าวว่าด้วยภาษาการเขียนโปรแกรมที่ปลอดภัยต่อหน่วยความจำและเฟรมเวิร์กที่เกี่ยวข้อง ผู้เขียนภาษาคือผู้รับรองการจัดการหน่วยความจำที่เหมาะสม ไม่ใช่ผู้พัฒนาแอปพลิเคชัน Mackey กล่าว

การเปลี่ยนแปลงสามารถท้าทายได้

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

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

Mike Parkin วิศวกรด้านเทคนิคอาวุโสของ Vulcan Cyber ​​กล่าวว่ามีตัวแปรมากมายให้เล่นเมื่อพยายามพอร์ตแอปพลิเคชันจากภาษาหนึ่งไปยังอีกภาษาหนึ่ง “ในกรณีที่ดีที่สุด การเปลี่ยนแปลงนั้นเรียบง่าย และองค์กรสามารถบรรลุผลสำเร็จได้ค่อนข้างไม่ลำบาก” Parkin กล่าว “ในที่อื่น ๆ แอปพลิเคชันอาศัยคุณสมบัติที่ไม่น่าสนใจในภาษาต้นฉบับ แต่ต้องการการพัฒนาที่กว้างขวางและมีราคาแพงเพื่อสร้างใหม่ในภาษาใหม่”

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

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

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

การย้าย

ข้อมูลล่าสุดจาก Statista แสดงให้เห็นว่า นักพัฒนาหลายคนใช้อยู่แล้ว ภาษาที่ถือว่าปลอดภัยในหน่วยความจำ ตัวอย่างเช่น เกือบสองในสาม (65.6%) ใช้ JavaScript เกือบครึ่ง (48.06%) ใช้ Python หนึ่งในสามใช้ Java และเกือบ 28% ใช้ C# ในขณะเดียวกัน สัดส่วนจำนวนมากยังคงใช้ภาษาที่ไม่ปลอดภัย เช่น C++ (22.5%) และ C (19.25%)

Johannes Ullrich คณบดีฝ่ายวิจัยของ SANS Technology Institute กล่าวว่า "ผมคิดว่าหลายองค์กรได้เปลี่ยนจากการใช้ C/C++ แล้ว ไม่เพียงเพราะปัญหาด้านความปลอดภัยของหน่วยความจำเท่านั้น แต่ยังรวมถึงความง่ายในการพัฒนาและบำรุงรักษาโดยรวมอีกด้วย" “แต่จะยังมีฐานรหัสดั้งเดิมที่จะต้องได้รับการบำรุงรักษาเป็นเวลาหลายปี”

คำแนะนำของ NSA ให้ข้อมูลเชิงลึกเล็กน้อยเกี่ยวกับสิ่งที่อาจกระตุ้นให้เกิดคำแนะนำในช่วงหัวเลี้ยวหัวต่อนี้ แต่ John Bambenek หัวหน้านักล่าภัยคุกคามที่ Netenrich แนะนำว่าองค์กรต่างๆ อย่าเพิกเฉย “ความเปราะบางของหน่วยความจำและการโจมตีได้แพร่หลายมาตั้งแต่ปี 1990 ดังนั้นโดยทั่วไปแล้ว นี่เป็นคำแนะนำที่ดี” เขากล่าว “ตามที่กล่าวมา เนื่องจากสิ่งนี้มาจาก NSA ฉันเชื่อว่าคำแนะนำนี้ควรได้รับการเร่งด่วนเพิ่มเติม และขับเคลื่อนด้วยความรู้ที่พวกเขามีและเราไม่”