บัฟเฟอร์ล้นใน curl และ libcurl ซึ่งแสดงออกมาเมื่อเข้าถึงผ่านพร็อกซี SOCKS5

ช่องโหว่ (CVE-2023-38545) ได้รับการระบุในยูทิลิตี้สำหรับรับและส่งข้อมูลผ่านเครือข่าย Curl และไลบรารี libcurl ซึ่งกำลังได้รับการพัฒนาแบบคู่ขนาน ซึ่งอาจนำไปสู่การบัฟเฟอร์ล้นและอาจเรียกใช้โค้ดของผู้โจมตีได้ ฝั่งไคลเอ็นต์เมื่อเข้าถึงโดยใช้ยูทิลิตี้ curl หรือแอปพลิเคชันที่ใช้ libcurl ไปยังเซิร์ฟเวอร์ HTTPS ที่ควบคุมโดยผู้โจมตี ปัญหาจะปรากฏขึ้นเฉพาะเมื่อมีการเปิดใช้งานการเข้าถึงผ่านพร็อกซี SOCKS5 ใน Curl เมื่อเข้าถึงโดยตรงโดยไม่ใช้พรอกซี ช่องโหว่จะไม่ปรากฏ ช่องโหว่ได้รับการแก้ไขแล้วในรุ่น curl 8.4.0 นักวิจัยด้านความปลอดภัยที่ค้นพบข้อผิดพลาดนี้ได้รับรางวัลมูลค่า 4660 ดอลลาร์สหรัฐฯ ซึ่งเป็นส่วนหนึ่งของโครงการ Internet Bug Bounty ของ Hackerone

ช่องโหว่นี้เกิดจากข้อผิดพลาดในรหัสการแก้ไขชื่อโฮสต์ก่อนเข้าถึงพร็อกซี SOCKS5 หากชื่อโฮสต์มีความยาวสูงสุด 256 อักขระ Curl จะส่งชื่อไปยังพร็อกซี SOCKS5 ทันทีเพื่อแก้ไขที่ด้านข้าง และหากชื่อมีความยาวมากกว่า 255 อักขระ ก็จะสลับไปที่ตัวแก้ไขในเครื่องและส่งที่อยู่ที่กำหนดไว้แล้วไปยัง SOCKS5 . เนื่องจากข้อผิดพลาดในโค้ด การตั้งค่าสถานะที่ระบุถึงความจำเป็นในการแก้ปัญหาเฉพาะที่อาจถูกตั้งค่าที่ไม่ถูกต้องในระหว่างการเจรจาการเชื่อมต่อที่ช้าผ่าน SOCKS5 ซึ่งนำไปสู่การบันทึกชื่อโฮสต์แบบยาวในบัฟเฟอร์ที่จัดสรรด้วยความคาดหวัง ในการจัดเก็บที่อยู่ IP หรือชื่อ ไม่เกิน 255 ตัวอักษร

เจ้าของไซต์ที่เข้าถึงโดย curl ผ่านพร็อกซี SOCKS5 สามารถทริกเกอร์บัฟเฟอร์ล้นฝั่งไคลเอ็นต์ได้โดยการส่งคืนรหัสการเปลี่ยนเส้นทางคำขอ (HTTP 30x) และตั้งค่าส่วนหัว "ตำแหน่ง:" เป็น URL ที่มีชื่อโฮสต์อยู่ในช่วง 16 ขึ้นไป ถึง 64 KB (16 KB คือขนาดขั้นต่ำที่จำเป็นสำหรับการล้นบัฟเฟอร์ที่จัดสรร และ 65 KB คือความยาวชื่อโฮสต์สูงสุดที่อนุญาตใน URL) หากเปิดใช้งานการเปลี่ยนเส้นทางคำขอในการตั้งค่า libcurl และพร็อกซี SOCKS5 ที่ใช้ช้าเพียงพอ ชื่อโฮสต์แบบยาวจะถูกเขียนลงในบัฟเฟอร์ขนาดเล็ก ซึ่งเห็นได้ชัดว่ามีขนาดเล็กกว่า

ช่องโหว่ส่วนใหญ่ส่งผลกระทบต่อแอปพลิเคชันที่ใช้ libcurl และปรากฏในยูทิลิตี้ curl เฉพาะเมื่อใช้ตัวเลือก “--limit-rate” ที่มีค่าน้อยกว่า 65541 - libcurl โดยค่าเริ่มต้นจะจัดสรรบัฟเฟอร์ขนาด 16 KB และในยูทิลิตี้ curl มันคือ 100 KB แต่ขนาดจะเปลี่ยนไปตามค่าของพารามิเตอร์ "-limit-rate"

Daniel Stenberg ผู้เขียนโครงการกล่าวว่าช่องโหว่ดังกล่าวยังคงตรวจไม่พบเป็นเวลา 1315 วัน นอกจากนี้ยังระบุด้วยว่า 41% ของช่องโหว่ที่ระบุก่อนหน้านี้ใน curl น่าจะสามารถหลีกเลี่ยงได้หาก curl ถูกเขียนในภาษาที่ปลอดภัยสำหรับหน่วยความจำ แต่ไม่มีแผนที่จะเขียน curl ใหม่เป็นภาษาอื่นในอนาคตอันใกล้ เพื่อเป็นมาตรการในการปรับปรุงความปลอดภัยของฐานโค้ดจึงเสนอให้ขยายเครื่องมือสำหรับการทดสอบโค้ดและใช้การพึ่งพาที่เขียนในภาษาการเขียนโปรแกรมอย่างแข็งขันมากขึ้นเพื่อให้แน่ใจว่าการทำงานที่ปลอดภัยด้วยหน่วยความจำ นอกจากนี้ ยังพิจารณาถึงความเป็นไปได้ในการค่อยๆ แทนที่ส่วนต่างๆ ของ curl ด้วยตัวเลือกที่เขียนด้วยภาษาที่ปลอดภัย เช่น แบ็กเอนด์ Hyper HTTP รุ่นทดลองที่ใช้งานใน Rust

ที่มา: opennet.ru

เพิ่มความคิดเห็น