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

 (daniel.haxx.se)
1 คะแนน โดย GN⁺ 2024-03-10 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • curl ที่ Apple บันเดิลมากับ macOS จัดการตัวเลือก --cacert แตกต่างจากบิลด์โอเพนซอร์ส ทำลายความคาดหวังในการตรวจสอบ TLS ที่ว่าผู้ใช้จะเชื่อถือเฉพาะ CA ที่ระบุเท่านั้น
  • --cacert เป็นตัวเลือกที่ทำให้ตรวจสอบใบรับรองเซิร์ฟเวอร์ด้วย ชุดใบรับรอง CA ที่ระบุ เท่านั้น และหากการตรวจสอบล้มเหลว curl ควรส่งคืนข้อผิดพลาด
  • curl ที่ Apple จัดให้ดูเหมือนจะตรวจสอบ คลัง CA ของระบบ เพิ่มเติม แม้การตรวจสอบด้วย CA ที่ระบุจะล้มเหลว พฤติกรรมนี้ไม่ได้ถูกร้องขอและไม่มีการบันทึกไว้ในเอกสาร
  • Apple Product Security ตอบว่า LibreSSL ซึ่งเป็น OpenSSL ของ Apple ตั้งใจใช้คลังความเชื่อถือของระบบที่ฝังมาเป็นแหล่งความเชื่อถือเริ่มต้น จึงไม่ใช่สิ่งที่ต้องแก้ไข
  • เนื่องจากไม่ใช่ช่องโหว่ในดิสทริบิวชันของโปรเจกต์ curl จึงไม่มีการออก CVE แต่ผลการตรวจสอบ CA ของ curl ที่บันเดิลมากับ macOS อาจแตกต่างจากเอกสาร

จุดเริ่มต้นของอิชชู 12604

  • วันที่ 28 ธันวาคม 2023 มีการลงทะเบียน bugreport 12604 ในตัวติดตามอิชชูของ curl
  • หัวข้ออิชชูคือ “flag --cacert behavior isn’t consistent between macOS and Linux” และรายงานโดย Yuedong Wu
  • แม้รัน curl เวอร์ชันเดียวกันบนเครื่อง macOS เครื่องเดียวกัน พฤติกรรมของ curl ที่ Apple บันเดิลมาและไบนารี curl ที่บิลด์จากโอเพนซอร์สก็แตกต่างกัน

การรับประกันที่ --cacert ทำให้คาดหวัง

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

พฤติกรรมยกเว้นของ curl ที่บันเดิลมากับ macOS

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

คำตอบจาก Apple Product Security

  • วันที่ 29 ธันวาคม 2023 เวลา 08:30 UTC มีการส่งอีเมลรายงานปัญหาความปลอดภัยไปยัง Apple Product Security
  • Apple Product Security ตอบกลับเมื่อวันที่ 8 มีนาคม 2024
  • คำตอบของ Apple สรุปได้เป็นสองประเด็น
    • LibreSSL ซึ่งเป็น OpenSSL ของ Apple ตั้งใจใช้คลังความเชื่อถือของระบบที่ฝังมาเป็นแหล่งความเชื่อถือเริ่มต้น
    • เนื่องจากใบรับรองเซิร์ฟเวอร์สามารถตรวจสอบได้สำเร็จด้วยคลังความเชื่อถือของระบบที่ฝังมา จึงไม่มองว่าเป็นปัญหาที่ต้องจัดการบนแพลตฟอร์มของ Apple
  • Apple ปิดเคสนี้

การประเมินของฝั่งโปรเจกต์ curl และผลกระทบต่อผู้ใช้

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

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

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

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

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

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

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

    • นั่นแหละเหตุผลที่เลิกใช้ Apple ตัวเครื่องดูทำมาได้ดีจริง ๆ และระบบปฏิบัติการก็ขัดเกลามาดี แต่การบังคับให้อยู่ในวิธีและระบบนิเวศของตัวเอง แถมยังกันไม่ให้เข้าถึง ฮาร์ดแวร์ของตัวเอง ไม่เข้ากับการใช้ชีวิตเป็นแฮ็กเกอร์ตามความหมายแบบ HN
      อย่างน้อยก็ไม่เข้ากับส่วนนั้นของชีวิตดิจิทัล และเมื่อคิดถึงราคาแล้วก็ยากจะซื้อมาเป็นอุปกรณ์เสริมวางไว้ข้าง ๆ เคยคิดอยู่เรื่อย ๆ ว่าจะลองผลิตภัณฑ์ Apple ดีไหม ล่าสุดก็รวมถึงเฮดเซ็ต AR ด้วย แต่จนถึงตอนนี้มันดูเป็นปฏิปักษ์กับนักพัฒนาหรือคนชอบแกะชอบซ่อมมากเกินไป
    • ถ้ารัน curl แบบโอเพนซอร์ส ก็จะได้พฤติกรรมตามที่ต้องการ
    • น่าเสียดายที่มักมีคนอ่านการตัดสินใจทางเทคนิคระดับล่างเกินจริง เพื่อนำไป “พิสูจน์” อคติของตัวเองอยู่เสมอ
      การมองว่าบริษัทใหญ่ระดับ Apple ตัดสินใจแบบนี้เพื่อวิสัยทัศน์ใหญ่กว่าอย่าง “เป็นเจ้าของอุปกรณ์ของผู้ใช้” เท่ากับยกให้ Apple มีความสามารถด้านองค์กรและการประสานงานอย่างมหาศาล เป็นระดับที่ไม่เคยได้ยินแม้แต่ในองค์กรขนาดหนึ่งในสิบของ Apple แต่ก็เพราะเป็น Apple ใช่ไหม!?
    • เจ้าของคือ Apple ส่วนคุณเป็นแค่ผู้ใช้ ;)

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

    • ไม่ใช่ กรณีนั้นไม่ใช่ curl binary รู้ว่าควรเรียกไลบรารี libcurl อย่างไร

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

    • ดูเหมือนสิ่งที่ NSA น่าจะกดดันให้บริษัทเทคโนโลยีรายใหญ่ของสหรัฐฯ ทำแบบพอดิบพอดี

  • พฤติกรรมเริ่มต้นก็น่าสงสัยอยู่ แต่ผมไม่เห็นด้วยกับการประเมินนี้ทั้งหมด จริง ๆ แล้วนี่คือ ปัญหาการทำเอกสารของ curl
    curl เป็นไลบรารีหลายโปรโตคอล จึงไม่ได้ implement ทุกโปรโตคอลเอง และในกรณีส่วนใหญ่พึ่งพา “แบ็กเอนด์” ที่เป็น dependency ทางอ้อมซึ่งรับหน้าที่ตีความบิตระดับต่ำแทน โปรโตคอลบางตัวรองรับไลบรารีทางเลือกหลายตัวด้วยเหตุผลที่สมเหตุสมผล
    ข้อเสียของแนวทางนี้คือยากหรือเป็นไปไม่ได้ที่จะรับประกันพฤติกรรมร่วมกันระหว่างแบ็กเอนด์อิสระเหล่านี้ บางตัวอาจไม่มีฟีเจอร์เหมือนกันทั้งหมด API อาจไม่ครบถ้วน หรืออย่างกรณีนี้ อาจไม่เปิดทางให้ patch พฤติกรรมเริ่มต้นบางส่วนได้ LibreSSL ไม่ใช่การ reimplement OpenSSL แบบตรงกันทุกบิต และไม่ได้มีหน้าที่ต้องเลียนแบบ API ของมันให้ครบถ้วน
    ในกรณีแบบนี้ หาก upstream ไม่อยากแก้ curl ก็เหลือสองทางเลือก: ตัดการรองรับไลบรารีนั้นทิ้ง หรือทำเอกสารบอกพฤติกรรมเฉพาะนั้น อย่างแรกอาจทำให้โค้ดผู้ใช้พัง ดังนั้นอย่างน้อยก็ควรทำอย่างหลัง
    ถึงอย่างนั้น ผมเห็นด้วยกับภาพรวมว่าด้านความปลอดภัยของ LibreSSL วิธีนี้เป็นข้อบกพร่อง และอาจมีเหตุผลให้เปิด CVE ได้ เพียงแต่เป้าหมายควรเป็น LibreSSL

    • ถ้าต้นเหตุอยู่ที่ ไลบรารี SSL ของระบบ ผมยังไม่ค่อยเข้าใจว่าการ build curl จาก source จะหลบปัญหานี้ได้อย่างไร

  • นึกถึงกรณี F_BARRIERFSYNC ของ SQLite
    ก็แค่ไม่สนใจ
    https://bonsaidb.io/blog/acid-on-apple/

    • ทำให้นึกถึงครั้งก่อนที่ Apple ทำหนึ่งในเครื่องมือ Unix เก่า ๆ ที่พวกเขา bundle มาด้วยพัง โดยยัด option บางอย่างเข้าไปแบบลวก ๆ
      ท่าทีในการดูแลรักษาของพวกเขาอยู่ต่ำกว่ากรณีคน Debian ทำ OpenSSL พังสักสองระดับ

  • ถ้า Daniel บอกว่า curl ของพวกคุณพัง ก็แก้ซะ Apple ง่ายแค่นั้นเอง

    • Daniel ก็ผิดได้ แม้แต่เรื่อง curl ก็ผิดได้
      ในกรณีนี้ จากที่ตรวจอยู่ 2 นาที ดูเหมือนเขาน่าจะถูก แต่ตรรกะ “เพราะเป็น Daniel จึงถูก” เป็นตรรกะที่แย่ที่สุด
      นึกถึงบทสนทนาเก่า ๆ เกี่ยวกับประวัติของ C โดยเฉพาะ “คุณูปการ” ของ Eric S. Raymond: https://scienceblogs.com/deltoid/2011/10/14/dennis-ritchie-h...

  • ขอบคุณสำหรับคำเตือน อนึ่ง ผมใช้ MacPorts แทนเครื่องมือจำนวนมากที่ bundle มากับ macOS อยู่ curl ก็เป็นหนึ่งในนั้น
    เครื่องมือที่ bundle มาส่วนใหญ่ล้าสมัยหรือพังในรูปแบบอื่น ๆ ผมหมดความเชื่อใจซอฟต์แวร์ที่ Apple bundle มานานแล้ว

  • สงสัยว่า Apple กำลังพึ่งพาพฤติกรรมนี้กับอะไรสำคัญ ๆ อยู่หรือเปล่า

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

  • ที่ว่า Apple ใส่ใจความปลอดภัยของผู้ใช้ ก็คงประมาณนี้สินะ