แบ็กดอร์ xz ที่ถูกตรวจพบด้วย NixOS และการบิลด์ที่ทำซ้ำได้

 (luj.fr)
1 คะแนน โดย GN⁺ 2025-03-24 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ในเดือนมีนาคม 2024 มีการค้นพบแบ็กดอร์ในซอฟต์แวร์ xz ที่ใช้สำหรับแตกไฟล์ source tarball ในลินุกซ์ดิสทริบิวชัน
  • แบ็กดอร์นี้ถูกแทรกอย่างลับ ๆ ตลอด 3 ปีโดยผู้ดูแลที่มีเจตนาร้าย Jia Tan
  • เหตุการณ์นี้ส่งผลกระทบอย่างมากเพราะเปิดทางให้เกิดการรันโค้ดจากระยะไกลได้ และตรวจจับได้ยากมาก
  • Andres Freund นักพัฒนา Postgres ของ Microsoft บังเอิญพบมันระหว่างตรวจสอบปัญหาประสิทธิภาพตกต่ำ จึงช่วยหลีกเลี่ยงหายนะครั้งใหญ่ได้

วิธีการทำงานของการโจมตี

  • แบ็กดอร์จะไฮแจ็กโปรแกรม ssh เพื่อเปิดทางให้เกิดการรันโค้ดจากระยะไกล
  • มันแก้ไขฟังก์ชัน RSA_public_decrypt เพื่อให้ผู้โจมตีสามารถรันคำสั่งใดก็ได้เมื่อมีการล็อกอินด้วยคีย์ RSA ที่กำหนดไว้
  • มันประกอบด้วยสององค์ประกอบหลัก:
    1. สคริปต์ที่ติดตั้งไฟล์อ็อบเจ็กต์อันตรายให้เป็นส่วนหนึ่งของกระบวนการบิลด์ xz
    2. ขั้นตอนที่ hook ฟังก์ชัน RSA_public_decrypt

1. สคริปต์ติดตั้งไฟล์อ็อบเจ็กต์อันตราย

  • ไฟล์อ็อบเจ็กต์อันตรายถูกซ่อนไว้ในไฟล์ทดสอบของที่เก็บ git ของ xz
  • แบ็กดอร์จะทำงานเฉพาะใน release tarball ที่ผู้ดูแลเป็นผู้จัดเตรียมเท่านั้น

2. ขั้นตอนการ hook ฟังก์ชัน RSA_public_decrypt

  • ใช้ความสามารถ ifunc ของ glibc เพื่อบังคับให้โค้ดที่รันในช่วงเวลา dynamic loading ถูกเรียกใช้งาน
  • เมื่อ ssh ทำงาน libsystemd และ liblzma จะถูกโหลด และในกระบวนการนี้แบ็กดอร์จะรันโค้ดตามอำเภอใจ

วิธีหลีกเลี่ยงหายนะ xz

  • ต้องจัดการทั้งปัญหาทางสังคมและปัญหาทางเทคนิคเพื่อเพิ่มความน่าเชื่อถือของซอฟต์แวร์โอเพนซอร์ส
  • ควรปรับปรุงกระบวนการความปลอดภัยของซัพพลายเชนซอฟต์แวร์

บิลด์ซอฟต์แวร์จากแหล่งที่เชื่อถือได้

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

เมื่อสถานการณ์เอื้ออำนวย...

  • NixOS เป็นดิสทริบิวชันที่อิงกับโมเดลการจัดการแพ็กเกจแบบ functional และแต่ละแพ็กเกจถูกนิยามด้วยภาษาโปรแกรมเชิงฟังก์ชันชื่อ Nix
  • NixOS มีวัฒนธรรมการใช้ source archive ที่สร้างอัตโนมัติจาก GitHub

สร้างความเชื่อถือให้ release tarball ที่ไม่น่าเชื่อถือ

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

1. เปรียบเทียบซอร์ส

  • การตรวจสอบว่า source tarball ที่ดิสทริบิวชันใช้นั้นตรงกับของ GitHub หรือไม่เป็นสิ่งสำคัญ
  • อย่างไรก็ตาม release tarball มักแตกต่างจากซอร์ส และนั่นไม่ใช่ปัญหา

2. ใช้ประโยชน์จากการทำซ้ำได้ระดับบิต

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

บทสรุป

  • เหตุการณ์แบ็กดอร์ xz เป็นเครื่องเตือนถึงความสำคัญของความปลอดภัยในซัพพลายเชนซอฟต์แวร์โอเพนซอร์ส
  • ระบบอย่าง NixOS สามารถเสริมความปลอดภัยได้ด้วย reproducible builds.

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

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

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

  • NixOS และ reproducible builds ไม่ได้ตรวจพบ xz backdoor โดย NixOS แจกจ่าย xz build ที่เป็นอันตราย แต่ไม่มีปัญหาเพราะมันไม่ได้มุ่งเป้าไปที่ NixOS

    • นักพัฒนา NixOS รู้สึกตกใจเมื่อพบว่า xz เวอร์ชันที่เป็นอันตรายถูกแจกจ่ายถึงผู้ใช้ตอนที่ backdoor ถูกเปิดเผย
    • ทฤษฎีกับความเป็นจริงไม่เหมือนกัน และสาเหตุที่ xz ทำได้สำเร็จไม่ใช่เพราะช่องโหว่ทางเทคนิค แต่เป็นปัญหาใน "โลกความเป็นจริง" มีความยากในการยอมรับว่าเราไม่สามารถแพตช์โลกความจริงด้วยซอฟต์แวร์ได้

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

    • ในฐานะผู้ใช้ NixOS คิดว่ามีความเป็นไปได้สูงที่ NixOS จะจับสิ่งนี้ไม่ได้ การไว้วางใจ NixOS โดยไม่มีหลักฐานเป็นเรื่องไม่ฉลาด

  • NixOS ไม่ได้เกี่ยวข้องเพราะ xz backdoor มุ่งเป้าไปที่ RedHat และ Debian ที่น่าแดกดันคือ backdoor นี้ถูกค้นพบโดยพนักงาน Microsoft

  • บทความกล่าวถึงว่าดิสโทรควรดึงซอร์สโค้ดโดยตรงจาก VCS (เช่น Github) แทน tarball สำหรับติดตั้งแบบดั้งเดิม

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

  • ถ้าจะโฟกัสที่เหตุการณ์ที่ NixOS อาจป้องกันได้ ควรไปโฟกัสที่เหตุการณ์ CrowdStrike มากกว่า ถ้าบูตด้วยการตั้งค่าของเมื่อวานได้ ปัญหาส่วนใหญ่ก็น่าจะบรรเทาได้

  • NixOS คอมไพล์ทุกอย่างจากซอร์ส ตรวจสอบทางคริปโตกราฟีว่าซอร์สที่ใช้ไม่ถูกดัดแปลง และมี version dependency ระหว่างแพ็กเกจ ส่วน Debian ก็มี reproducible builds เช่นกัน

    • ปัญหาคือระบบ build ไม่ได้ลบไฟล์ object ที่คอมไพล์ไว้ล่วงหน้าก่อนจะ build จากซอร์ส หากไม่มีใครตรวจดูซอร์สโค้ด ก็สามารถเพิ่ม backdoor เข้าไปได้ และทั้ง NixOS หรือดิสโทรอื่นก็ป้องกันเรื่องนี้ไม่ได้

  • คำว่า "ทำได้" หมายความว่ายังไม่ได้พิสูจน์ และในความเป็นจริงพวกเขาก็แจกจ่ายมันออกไป

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

    • เน้นย้ำความจำเป็นและการใช้งานของเครื่องมือ build manager โดยควรสร้างกราฟการติดตามเหตุและผลอย่างชัดเจนว่าไฟล์ไหนมีผลต่อไฟล์ไหนในกระบวนการ build แล้วบังคับใช้กราฟนั้น หรือสร้างวิธีรายงานความเบี่ยงเบนจากกราฟการติดตามก่อนหน้า

  • หาก PR ของ Jia Tan ได้รับการอนุมัติ อาร์ติแฟกต์ที่เป็นอันตรายก็อาจถูกปล่อยผ่าน Github release ได้ง่ายพอ ๆ กับ tarball จึงยากจะเข้าใจว่า Github release เป็นการบรรเทาด้านความปลอดภัยได้อย่างไร

  • ประเด็นคือ release tarball แตกต่างจากซอร์ส

    • หาก tarball ที่ผู้ดูแลให้มาถูกสร้างจากซอร์สโค้ดต้นฉบับอย่างซื่อสัตย์ ก็ยากจะเข้าใจว่าเวอร์ชันที่ต่างกันหรืออย่างอื่นจะเป็นปัญหาได้อย่างไร
    • ควรทำให้ tarball ที่สร้างขึ้นสามารถสร้างได้จากซอร์สโค้ดเอง โดยไม่ตัดอะไรออก และต้อง git add & commit ด้วย ถึงอย่างนั้นก็ยังต้องตรวจประวัติ commit อยู่ดี และเพราะมันดูไม่เป็นอันตรายด้วยตาเปล่า จึงสงสัยว่าจะตรวจสอบได้อย่างไร
    • หาก tarball ที่ดูแลอยู่ถูกสร้างจากซอร์สโค้ดของเจ้าของและไม่ได้อยู่บน Github นั่นคือปัญหา

  • มันมีปัญหามากกว่าแค่การ push ไฟล์ทดสอบที่มีพิษ แต่ก็ยังยากจะเข้าใจว่า Nix จะป้องกันสิ่งนี้ได้อย่างไร

    • ถ้าโปรเจ็กต์ดังเปลี่ยนผู้นำ ก็คงต้องดู commit อย่างระมัดระวังและตรวจสอบว่าใครเป็นผู้นำ

  • สงสัยว่าตัวเองเข้าใจบทความผิดไปหรือพลาดอะไรบางอย่างหรือไม่