3 คะแนน โดย GN⁺ 2024-04-02 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

เหตุการณ์แบ็กดอร์ xz Utils: สิ่งที่เรารู้เกี่ยวกับเหตุการณ์ที่เกือบจะแพร่เชื้อไปทั่วโลก

  • xz Utils เป็นยูทิลิตีบีบอัดข้อมูลที่ติดตั้งอยู่ในลินุกซ์รวมถึงระบบปฏิบัติการตระกูลยูนิกซ์แทบทั้งหมด
  • เกิดเหตุที่ซอฟต์แวร์นี้เกือบถูกอัปเดตอย่างมุ่งร้ายจนฝังแบ็กดอร์ลงไปได้
  • นักพัฒนาของ Microsoft ค้นพบและเปิดโปงแบ็กดอร์นี้ ทำให้สามารถหยุดวิกฤตไว้ได้ก่อนที่มันจะถูกรวมเข้าไปในดิสทริบิวชันลินุกซ์หลักอย่าง Debian และ Red Hat

แบ็กดอร์ทำงานอย่างไร?

  • โค้ดอันตรายที่ถูกเพิ่มเข้ามาในเวอร์ชัน 5.6.0 และ 5.6.1 จะดัดแปลง sshd ซึ่งเป็นไฟล์ปฏิบัติการสำหรับการเชื่อมต่อ SSH
  • ผู้ที่มีคีย์เข้ารหัสเฉพาะสามารถซ่อนโค้ดไว้ในใบรับรองการยืนยันตัวตนสำหรับการล็อกอินผ่าน SSH แล้วอัปโหลดไปเพื่อรันบนอุปกรณ์ที่ติดตั้งแบ็กดอร์ได้
  • ยังไม่ทราบว่าในทางปฏิบัติมีการอัปโหลดโค้ดใดจริงบ้าง แต่ในทางทฤษฎีสามารถทำได้ตั้งแต่การขโมยคีย์เข้ารหัสไปจนถึงการติดตั้งมัลแวร์

เส้นทางที่แบ็กดอร์ถูกฝังเข้าไป

  • แบ็กดอร์นี้ดูเหมือนถูกสร้างขึ้นอย่างต่อเนื่องตลอดหลายปี
  • ในปี 2021 ผู้ใช้ชื่อ JiaT75 เริ่มมีส่วนร่วมกับโครงการโอเพนซอร์สเป็นครั้งแรก
  • ในเดือนมกราคม 2023 JiaT75 ได้มีส่วนร่วมกับ xz Utils ครั้งแรก และหลังจากนั้นก็รับบทบาทมากขึ้นเรื่อย ๆ ภายใต้ชื่อ Jia Tan
  • Tan ได้เปลี่ยนข้อมูลติดต่อของ Collins ในโครงการ oss-fuzz ให้เป็นของตนเอง และขอให้ปิดใช้งานฟังก์ชัน ifunc ระหว่างการทดสอบ
  • การเปลี่ยนแปลงเหล่านี้ขัดขวางการตรวจจับเมื่อ Tan ทำการแก้ไขที่เป็นอันตรายใน xz Utils

ดิสทริบิวชันที่ได้รับผลกระทบ

  • Fedora Rawhide, Fedora 41, Debian testing/unstable/experimental, openSUSE Tumbleweed และ MicroOS, Kali Linux เป็นต้น มี xz เวอร์ชันที่ฝังแบ็กดอร์รวมอยู่

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

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

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

 
GN⁺ 2024-04-02
ความเห็นจาก Hacker News
  • OpenSSH เป็นอิมพลีเมนเทชันของ sshd ที่ได้รับความนิยมมากที่สุด และไม่ได้ลิงก์กับไลบรารี liblzma โดยตรง แต่ Debian และดิสทริบิวชันลินุกซ์อื่น ๆ อีกมากได้เพิ่มแพตช์ที่เชื่อม sshd เข้ากับ systemd ซึ่ง systemd ลิงก์กับ liblzma อยู่ จึงทำให้ xz Utils สามารถส่งผลกระทบต่อ sshd ได้

  • Xz เป็นทั้งโปรแกรมบีบอัดแบบโอเพนซอร์สและไลบรารี ซึ่งช่วยให้เขียนโปรแกรมของตนเองเพื่อจัดการข้อมูลที่ถูกบีบอัดได้ และถูกใช้งานโดยโปรแกรมอื่นจำนวนมาก รวมถึง OpenSSH

  • binutils ของ GNU ก็ลิงก์กับ liblzma เช่นกัน และถูกใช้งานแพร่หลายยิ่งกว่า OpenSSH อีก ในกรณีส่วนใหญ่ binutils ถูกใช้ในการคอมไพล์ OpenSSH, ระบบปฏิบัติการที่รัน sshd และอื่น ๆ สิ่งนี้บ่งชี้ว่าผู้ไม่หวังดีได้เลือกโปรเจ็กต์ที่เหมาะมากสำหรับการแทรกซึมลึกเข้าไปในซอฟต์แวร์โอเพนซอร์ส

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

  • แทบไม่มีการพูดถึงกลไกการลิงก์ที่สามารถเชื่อมไปยังฟังก์ชัน RSA_public_decrypt ได้เลย มีการถกเถียงมากเกี่ยวกับสิ่งที่ทำได้ผ่านการแยกโปรเซสและแนวทางคล้ายกัน แต่พูดถึงการรีไดเรกต์การเรียกฟังก์ชันนี้น้อยมาก จึงมีคำถามว่าเราจะกำหนดวิธีลิงก์คอมโพเนนต์สำคัญด้วยลำดับชั้นความเชื่อถือได้หรือไม่

  • บอกว่าเกือบทำให้ทั้งโลกติดเชื้อ แต่ความจริงคือดิสทริบิวชันลินุกซ์ยอดนิยมอย่าง Arch, Gentoo และ openSUSE Tumbleweed ได้ปล่อยแพ็กเกจที่มีแบ็กดอร์รวมอยู่ด้วยมาหลายสัปดาห์แล้ว และบน Tumbleweed มันทำงานได้แน่นอน ดังนั้นคำว่า "เกือบ" จึงไม่เหมาะสม

  • มีการคาดการณ์ว่าจะพบกรณีคล้ายกันอีกภายใน 12 เดือนข้างหน้า โดยจะเริ่มจากเหล่าผู้ดูแลเริ่มตั้งข้อสงสัยต่อคอมมิตเก่า ๆ ของกันและกัน

  • บทเรียนส่วนตัวที่ได้จากเหตุการณ์นี้:

    • source distribution tarball ที่มีโค้ดต่างจาก source repository เป็นสิ่งที่ไม่ดี และควรเลิกใช้แนวทางนี้
    • อาร์ติแฟกต์ที่ถูกสร้างขึ้นอัตโนมัติควรถูกคอมมิตเสมอ
    • อาร์ติแฟกต์ที่ถูกสร้างอัตโนมัติและทุกคนมักเลื่อนผ่านตอนรีวิวโค้ดอาจเป็นปัญหาได้ หากมีไฟล์ประเภทนี้อยู่ใน repository ก็ควรมีการทดสอบอัตโนมัติเพื่อตรวจสอบว่าไม่มีใครแก้ไขมัน
    • autotools และวัฒนธรรมของ autotools เป็นสิ่งที่ไม่ดี
    • libsystemd ก่อปัญหาให้กับ ecosystem แม้คนที่วิจารณ์ systemd มักถูกมองข้าม แต่ systemd มีขนาดใหญ่ ซับซ้อน มี dependency จำนวนมาก และโปรแกรมส่วนใหญ่ก็ใช้เพียงบางส่วนของมันเท่านั้น
    • วัฒนธรรมที่มองว่าการนำโค้ดกลับมาใช้ซ้ำเป็นเรื่องดีเสมอ และการพึ่งพาไลบรารีขนาดใหญ่เพื่อฟังก์ชันเล็กน้อยเป็นเรื่องเหมาะสม เป็นความคิดที่ผิด dependency นำมาซึ่งภาระในการดูแลรักษาและความเสี่ยงด้านความปลอดภัย จึงต้องชั่งน้ำหนักกับประโยชน์ด้านฟังก์ชัน
    • การที่ผู้ดูแลดิสทริบิวชันใส่แพตช์จำนวนมากให้กับแพ็กเกจอาจเป็นปัญหาได้ เพราะเท่ากับสร้าง de facto fork ที่ถูกใช้กว้างขวางแต่ไม่มีใครดูแลจริงจัง
    • ควรทำให้นักพัฒนาสามารถทำงาน OSS ได้อย่างยั่งยืนทางการเงิน liblzma และ xz-utils ถูกติดตั้งอยู่หลายสิบล้านแห่ง แต่กลับมีผู้ดูแลเพียงคนเดียวที่มีปัญหาด้านสุขภาพจิต
    • การรีวิวโค้ดและการเปลี่ยนตัวผู้ดูแลควรคำนึงถึงปัจจัยทางภูมิรัฐศาสตร์ในปัจจุบันด้วย
  • มีการแสดงความขอบคุณที่ผู้พบปัญหาเป็นวิศวกรของ Microsoft ที่ทำงานกับ Azure Postgres ทำให้ตอนนี้เริ่มชอบ Azure แล้ว

  • ผู้ดูแลดั้งเดิมของ xz อาจส่งต่อความรับผิดชอบให้ Jia Tan โดยที่อาจไม่เคยพบตัวจริงหรือแม้แต่คุยโทรศัพท์กันเลย มีการตั้งคำถามว่าการสื่อสารกันผ่านอีเมล/GitHub อย่างเดียวเป็นเรื่องปกติหรือไม่ และคาดว่าหลังจากเรื่องนี้ผู้ดูแลโปรเจ็กต์โอเพนซอร์สจะระมัดระวังมากขึ้น

  • แม้จะมีคนคิดว่าแบ็กดอร์นี้ถูกค้นพบได้เร็ว แต่ก็อาจบรรลุเป้าหมายไปแล้ว โดยเฉพาะหากเป้าหมายคือเหล่านักพัฒนาที่ใช้ดิสทริบิวชันแบบ rolling release อย่าง Kali และ Debian

  • มีการชี้ว่าข้อกล่าวหาที่ว่า Lasse Collin ผู้ดูแล xz Utils มาอย่างยาวนาน อัปเดตซอฟต์แวร์ไม่บ่อยหรือไม่เร็วพอนั้นเป็นความเข้าใจผิด