เหตุการณ์ความปลอดภัย Apple curl 12604

 (daniel.haxx.se)
1 คะแนน โดย GN⁺ 2024-03-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

เหตุการณ์ความปลอดภัย Apple curl 12604

  • เมื่อวันที่ 28 ธันวาคม 2023 มีการส่งรายงานบั๊กหมายเลข 12604 ไปยัง issue tracker ของ curl
  • ชื่อปัญหาคือ "flag –cacert behavior isn’t consistent between macOS and Linux" ซึ่งชี้ให้เห็นว่าการทำงานของแฟลก --cacert ไม่สอดคล้องกันระหว่าง macOS และ Linux
  • ผู้รายงานแสดงให้เห็นว่า curl เวอร์ชันที่มากับ macOS ทำงานต่างจาก curl ไบนารีที่บิลด์จากโอเพนซอร์สแบบสมบูรณ์

เวอร์ชันของ Apple ตรวจสอบ system CA store เป็นลำดับที่สอง

  • ออปชันบรรทัดคำสั่ง --cacert เปิดทางให้ผู้ใช้สั่งให้ curl เชื่อถือเฉพาะชุดใบรับรอง CA ที่ระบุเท่านั้น
  • เมื่อใช้ curl เวอร์ชันที่ Apple จัดมาให้บน macOS ดูเหมือนว่าหากชุดใบรับรอง CA ที่ให้มาไม่สามารถตรวจสอบได้ ระบบจะไปตรวจสอบ system CA store เป็นลำดับที่สอง
  • พฤติกรรมนี้ไม่ได้มีการจัดทำเอกสารไว้ และเป็นสิ่งที่ผู้ใช้ไม่คาดคิด

นี่คือปัญหาด้านความปลอดภัย

  • เมื่อผู้ใช้รันการตรวจสอบด้วยไฟล์ใบรับรอง CA ที่ระบุไว้ หากใน system CA store มีใบรับรองที่สามารถตรวจสอบเซิร์ฟเวอร์ได้ การตรวจสอบจะไม่ล้มเหลว
  • ส่งผลให้เกิดปัญหาด้านความปลอดภัยที่การตรวจสอบใบรับรองซึ่งไม่ควรผ่านกลับผ่านได้

Apple บอกว่าไม่มีปัญหา

  • เมื่อวันที่ 8 มีนาคม 2024 ฝ่าย Product Security ของ Apple ตอบว่า OpenSSL เวอร์ชันนั้น (LibreSSL) ถูกออกแบบให้ใช้ system trust store ที่ฝังมากับระบบเป็นแหล่งความเชื่อถือหลักโดยเจตนา
  • เนื่องจากใบรับรองของเซิร์ฟเวอร์สามารถตรวจสอบได้สำเร็จด้วย system trust store ที่ฝังมากับระบบ จึงไม่มองว่านี่เป็นปัญหา

ไม่เห็นด้วย

  • ฟีเจอร์ที่ไม่ได้มีการจัดทำเอกสารนี้ทำให้การตรวจสอบใบรับรอง CA ด้วย curl บน macOS เชื่อถือได้ไม่เต็มที่ และไม่ตรงกับเอกสาร
  • มันอาจทำให้ผู้ใช้สับสนได้
  • ปัญหานี้ไม่ใช่ช่องโหว่ความปลอดภัยใน curl เวอร์ชันที่เราจัดจำหน่าย จึงจะไม่ออก CVE
  • หากพูดอย่างเคร่งครัด ปัญหาไม่ได้อยู่ในโค้ดของ curl แต่เกิดจาก LibreSSL เวอร์ชันที่ Apple จัดมาและใช้ในการบิลด์ curl

ความเห็นของ GN⁺

  • เหตุการณ์นี้ตอกย้ำความสำคัญของความปลอดภัยและความน่าเชื่อถือของซอฟต์แวร์ เมื่อผู้ใช้ต้องการให้ใช้เฉพาะใบรับรอง CA ที่ตนเชื่อถืออย่างชัดเจน การที่ระบบยอมรับใบรับรองอื่นโดยปริยายอาจก่อให้เกิดข้อกังวลด้านความปลอดภัยอย่างร้ายแรง
  • คำตอบของ Apple แสดงให้เห็นว่ามีช่องว่างระหว่างมาตรฐานความปลอดภัยที่บริษัทกำหนดเองกับความคาดหวังของชุมชนโอเพนซอร์ส ซึ่งอาจจุดประกายการถกเถียงว่าผู้ใช้และนักพัฒนาควรมองและจัดการความปลอดภัยบนแพลตฟอร์มนั้นอย่างไร
  • ปัญหาแบบนี้เน้นให้เห็นถึงประเด็นเรื่อง dependency และการผสานรวมที่อาจเกิดขึ้นเมื่อใช้งานซอฟต์แวร์โอเพนซอร์ส นักพัฒนาควรตระหนักถึงความแตกต่างเหล่านี้เมื่อใช้ไลบรารีและเครื่องมือที่แพลตฟอร์มเฉพาะจัดมาให้ และตอบสนองอย่างเหมาะสม
  • โปรเจ็กต์อื่นที่ให้ความสามารถคล้ายกัน เช่น OpenSSL และ GnuTLS ต่างก็มีแนวคิดและวิธีการด้านความปลอดภัยของตนเอง ผู้ใช้และนักพัฒนาสามารถพิจารณาทางเลือกเหล่านี้ได้
  • เมื่อนำเทคโนโลยีมาใช้ ควรตรวจสอบโมเดลความปลอดภัยของเทคโนโลยีนั้นและความเข้ากันได้ข้ามแพลตฟอร์มอย่างรอบคอบ เหตุการณ์นี้เผยให้เห็นว่าการใช้งาน LibreSSL ของ Apple ทำงานแตกต่างจากพฤติกรรมมาตรฐานของ curl จึงย้ำให้เห็นถึงความสำคัญของการเลือกเทคโนโลยี

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

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

 
GN⁺ 2024-03-10
ความเห็นจาก Hacker News

  • คำวิจารณ์ต่อ "ฟีเจอร์" บางอย่างของ Apple

    • ฟีเจอร์นี้อาจเพิ่มการประมวลผลที่ไม่จำเป็น หรือทำลายโมเดลการตรวจสอบความถูกต้องที่คาดหวังไว้
    • เหตุผลที่ผู้ใช้อาจต้องการระบุ CA ของตนเองคือ CA นั้นไม่มีอยู่ในชุดที่มากับ OS หรืออาจต้องการตรวจสอบกับ CA เฉพาะบางตัว
    • พฤติกรรมแบบนี้ของ Apple ไม่ใช่ผลลัพธ์ที่คาดหมายไว้

  • นโยบายของ Apple มาก่อน ไม่ว่าความตั้งใจของเจ้าของอุปกรณ์ Apple จะเป็นอย่างไร

    • การที่นโยบายของ Apple มาก่อนโดยไม่สนใจสิ่งที่ "เจ้าของ" อุปกรณ์ Apple ต้องการ เป็นเรื่องที่พบได้ทั่วไปและไม่น่าแปลกใจ

  • คำอธิบายเกี่ยวกับการใช้ที่เก็บ CA ของ libcurl

    • เมื่อตั้งค่าออปชัน CURLSSLOPT_NATIVE_CA แล้ว libcurl จะใช้ที่เก็บ CA เริ่มต้นของระบบปฏิบัติการเพื่อตรวจสอบใบรับรอง
    • หากมีการตั้งค่าไฟล์หรือไดเรกทอรี CA certificate ไว้ สิ่งเหล่านี้จะถูกค้นหาร่วมกับที่เก็บ CA เริ่มต้นด้วย
    • หากใช้ร่วมกับออปชัน --cacert libcurl อาจพยายามเคารพทั้งสองการตั้งค่า ซึ่งบ่งชี้ว่าสองอย่างนี้อาจขัดแย้งกันเอง

  • สถานการณ์คล้ายกับกรณี SQLite F_BARRIERFSYNC

    • ดูเหมือนว่า Apple จะไม่ใส่ใจ

  • ความจำเป็นที่ Apple ต้องแก้ไข curl ตามข้อสังเกตของ Daniel

    • หาก Daniel ชี้ปัญหาใน curl ออกมา Apple ก็ควรต้องแก้ไข

  • ปัญหาในเอกสารของ curl และข้อบกพร่องด้านความปลอดภัยของ libcurl

    • curl ไม่ได้พัฒนาโปรโตคอลทุกตัวขึ้นมาเองโดยตรง แต่รองรับไลบรารีได้หลากหลาย
    • ข้อเสียของแนวทางนี้คือยากที่จะรับประกันพฤติกรรมที่สอดคล้องกันระหว่างแบ็กเอนด์ที่เป็นอิสระต่อกัน
    • libressl ไม่ใช่การนำ openssl มาทำใหม่แบบสมบูรณ์ และไม่มีภาระหน้าที่ต้องเลียนแบบ API ของมันทั้งหมด
    • curl มีทางเลือกอยู่สองทาง คือเลิกซัพพอร์ตไลบรารีนั้น หรือทำเอกสารอธิบายปัญหาไว้
    • เพื่อหลีกเลี่ยงการทำให้โค้ดของผู้ใช้พัง อย่างน้อยก็ควรทำเอกสารอธิบายปัญหาไว้
    • แนวทางของ libressl อาจมีข้อบกพร่องในเชิงความปลอดภัย และอาจมีเหตุผลเพียงพอที่จะเปิด CVE

  • ความไม่ไว้วางใจต่อซอฟต์แวร์ที่มากับ macOS

    • ใช้ MacPorts เพื่อเขียนทับเครื่องมือที่มากับ macOS (เช่น curl) เพราะมักล้าสมัยหรือมีปัญหา

  • พฤติกรรมเริ่มต้นของ Apple อาจถูกมองว่าเป็นแบ็กดอร์ได้

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

  • คำวิจารณ์ว่า Apple ไม่ให้ความสำคัญกับความปลอดภัยของผู้ใช้

    • พฤติกรรมเริ่มต้นกับพฤติกรรมทางเลือกเป็นคนละเรื่องกัน
    • ชวนให้สงสัยว่าทีมความปลอดภัยของ Apple อาจมีปัญหาเรื่องความเข้าใจในการอ่าน