การเจาะระบบ SSH
ผู้ดูแลระบบที่มีเจตนาร้ายหรือถูกแทรกแซงได้แทรกพฤติกรรมที่เป็นอันตรายเข้าไปในไลบรารีชื่อ... ลิบลซมาซึ่งเป็นส่วนหนึ่งของเครื่องมือและไลบรารีการบีบอัด xz ส่งผลให้เกิดช่องโหว่ใน SSH นี่คือการโจมตีห่วงโซ่อุปทานซอฟต์แวร์ขั้นสูง เนื่องจากไลบรารีถูกดัดแปลงโดยเจตนาเพื่อสร้างช่องโหว่ โดยใช้เทคนิคการปกปิดและการซ่อนเร้นเพื่อซ่อนเพย์โหลดการโจมตีจากผู้ตรวจสอบ
ช่องโหว่นี้ถูกค้นพบและเปิดเผยเมื่อเร็ว ๆ นี้ (เมื่อวันที่ 29 มีนาคมที่ผ่านมา) และกำลังอยู่ในระหว่างการดำเนินการแก้ไข อย่างไรก็ตาม ช่องโหว่นี้ถูกควบคุมได้อย่างรวดเร็ว เนื่องจากดูเหมือนว่าจะส่งผลกระทบเฉพาะเวอร์ชันก่อนวางจำหน่ายในสภาพแวดล้อมที่จำกัดเท่านั้น (แพ็กเกจ DEB และ RPM สำหรับสถาปัตยกรรม x86_64 และสร้างด้วย GCC) อย่างไรก็ตาม... CVE ได้รับ คะแนนพื้นฐานของ CVSS จากทั้งหมด 10 รายการ ซึ่งสงวนไว้สำหรับช่องโหว่ด้านความปลอดภัยทางไซเบอร์ที่ร้ายแรงที่สุด หากช่องโหว่นี้ถูกนำไปใช้ในระบบปฏิบัติการเวอร์ชันเสถียร ผลกระทบจะมหาศาล
การวิเคราะห์ทางเทคนิคของการโจมตี รวมถึง คำอธิบายโดยละเอียดเกี่ยวกับช่องโหว่ xzเรื่องนี้ได้รับการวิเคราะห์ไว้ในที่อื่นแล้ว บทความนี้จะเน้นไปที่ลำดับเหตุการณ์ของการโจมตี วิธีการตรวจจับ การจัดการเหตุการณ์จนถึงปัจจุบัน และบทเรียนที่สามารถเรียนรู้ได้จากการโจมตีครั้งนี้
ช่องโหว่นี้ยังคงมีอยู่ยาวนานหลังจากมีการแก้ไขครั้งแรกไปแล้ว ในเดือนสิงหาคม 2025 กว่าหนึ่งปีหลังจากที่ CVE-2024-3094 ถูกเปิดเผย นักวิจัยด้านความปลอดภัยจาก Binarly พบว่าช่องโหว่นี้ยังคงมีอยู่ในอิมเมจ Docker ของ Debian กว่าสิบรายการที่เผยแพร่บน Docker Hub โดยทีมงานของ Debian ปฏิเสธที่จะลบออก โดยถือว่าเป็นเพียงร่องรอยการพัฒนาในอดีตมากกว่าความเสี่ยงที่เกิดขึ้นจริง นอกจากนี้ OpenSSF และ OpenJS ได้ออกคำเตือนร่วมกันไม่นานหลังจากเหตุการณ์ XZ ว่าความพยายามในการเข้ายึดครองโดยใช้กลวิธีทางสังคมที่คล้ายคลึงกันได้เกิดขึ้นกับโครงการ JavaScript มาแล้ว ซึ่งบ่งชี้ว่ารูปแบบการโจมตีโดยอาศัยความไว้วางใจของผู้ดูแลโครงการที่ใช้ในที่นี้กำลังถูกนำไปใช้ซ้ำในที่อื่น
วิธีการที่ช่องโหว่ XZ ถูกแทรกเข้าไป
หมายเหตุ: ที่เก็บ Git อยู่ใน git.tukaani.org. อย่างไรก็ตาม นอกจากนี้ยังมี ที่เก็บข้อมูลบน GitHub (ปัจจุบันถูกบล็อก) ซึ่งบัญชี GitHub จะโพสต์การเปลี่ยนแปลงที่ต่อมาถูกรวมเข้ากับที่เก็บ Git
ส่วนหนึ่งของช่องโหว่ดูเหมือนจะอยู่ในไฟล์ tarball ที่แจกจ่ายสำหรับเวอร์ชัน 5.6.0 และ 5.6.1 เท่านั้น ไม่ได้อยู่ในที่เก็บ Git และอาศัยกลไกบางอย่าง บรรทัดเดียวในไฟล์ build-to-host.m4 ไฟล์มาโครที่ใช้โดย autoconf ส่วนอื่น ๆ อยู่ในไฟล์ทดสอบสองไฟล์ที่สมมติขึ้น bad-3-corrupt_lzma2.xz และ good-large_compressed.lzma
นั่นคือ commitเท็ด โดยบัญชี GitHub “Jia Tan” (เจียT75) ใน ที่เก็บ xz เมื่อวันที่ 23 กุมภาพันธ์ การเปลี่ยนแปลงครั้งนี้ดูเหมือนไม่มีพิษภัยอะไร เพียงแค่เพิ่มไฟล์ทดสอบ (ซึ่งคาดว่าเป็นไฟล์บีบอัด .lzma และ .xz) ที่น่าสนใจคือ ไฟล์ทดสอบเหล่านั้นไม่ได้ถูกนำไปใช้ในการทดสอบ! บรรทัดในไฟล์ .m4 นั้นเป็นการแทรกสคริปต์ที่ถูกเข้ารหัส (ซึ่งรวมอยู่ในไฟล์ tarball) เพื่อให้ทำงานเมื่อสิ้นสุดขั้นตอน configure หากตรงตามเงื่อนไขบางประการ โดยมันจะแก้ไขไฟล์ Makefile สำหรับ... ลิบลซมา ไลบรารีนี้ประกอบด้วยโค้ดที่ดึงข้อมูลจากไฟล์ .xz ซึ่งหลังจากกระบวนการถอดรหัสเสร็จสิ้นแล้ว ในสคริปต์นี้ฟังก์ชันนี้จะถูกเรียกใช้เมื่อสิ้นสุดการกำหนดค่า (configure) ฟังก์ชันนี้จะตัดสินใจว่าจะแก้ไขกระบวนการสร้างเพื่อแทรกโค้ดหรือไม่: เฉพาะภายใต้ GCC และตัวเชื่อมโยงของ GCC, ภายใต้ Debian หรือ rpm และเฉพาะสำหรับ Linux x86_64 เท่านั้น เมื่อตรงตามเงื่อนไข โค้ดที่แทรกเข้าไปจะดักจับการทำงานโดยการแทนที่สองส่วน ifunc ตัวแก้ไข (resolvers) จะทำให้การเรียกใช้บางอย่างถูกแทนที่ ซึ่งทำให้ตารางสัญลักษณ์ถูกแยกวิเคราะห์ในหน่วยความจำ (ซึ่งใช้เวลา และนำไปสู่การตรวจพบ ดังที่อธิบายไว้ในภายหลัง)
จากนั้นเรื่องราวก็เริ่มน่าสนใจ: แบ็กดอร์จะติดตั้งฮุกตรวจสอบลงในตัวเชื่อมโยงแบบไดนามิก รอรับสัญลักษณ์ฟังก์ชัน RSA_public_decrypt ซึ่งจะถูกส่งต่อไปยังจุดหนึ่งในโค้ดของแบ็กดอร์ และโค้ดนั้นก็จะเรียกกลับอีกครั้ง libcryptoเพื่อทำการตรวจสอบสิทธิ์ตามปกติ และเพย์โหลดจะทำงานหากโปรแกรมที่กำลังทำงานอยู่มีชื่อกระบวนการดังกล่าว /usr/sbin/sshdเป็นที่ชัดเจนว่าเป้าหมายคือเซิร์ฟเวอร์ SSH ตามธรรมเนียมแล้ว sshd เซิร์ฟเวอร์อย่าง OpenSSH ไม่ได้เชื่อมโยงกับ ลิบลซมาแต่ sshd คือ มักจะถูกแก้ไข เพื่อรองรับ systemd-notify เพื่อให้บริการอื่นๆ สามารถเริ่มต้นได้เมื่อ sshd ทำงานอยู่ จากนั้น liblzma จะถูกโหลดโดยอ้อม systemdปิดวงจรให้สมบูรณ์
ช่องโหว่นี้ยังไม่ได้รับการวิเคราะห์อย่างละเอียด แต่ดูเหมือนว่าจะมีอยู่จริง อนุญาตให้ดำเนินการคำสั่งจากระยะไกล (อาร์ซีอี) ด้วยสิทธิ์ของดีมอน sshdโดยทำงานในบริบทก่อนการตรวจสอบสิทธิ์ ข้อมูลจากใบรับรองระยะไกล เมื่อตรงกับแบ็กดอร์ จะถูกถอดรหัสด้วย ChaCha20 และเมื่อถอดรหัสสำเร็จแล้ว จะถูกส่งต่อไปยัง ระบบ()ดังนั้น นี่จึงเป็นช่องโหว่ RCE ที่มีระบบรักษาความปลอดภัย ซึ่งร้ายแรงกว่าการบายพาสด้วยคีย์สาธารณะธรรมดามาก
ไฟล์ tarball เวอร์ชัน 5.6.1 ที่ออกมาภายหลัง แสดงให้เห็นถึงความพยายามเพิ่มเติมในการปกปิดร่องรอย โดยเพิ่มการปกปิดชื่อสัญลักษณ์ให้มากขึ้น และพยายามแก้ไขข้อผิดพลาดที่พบ กลไกการขยาย นอกจากนี้ยังมีการตรวจสอบไฟล์ทดสอบเพิ่มเติมเพื่อหาลายเซ็นบางอย่างที่จะเพิ่มเข้าไปในแบ็กดอร์ด้วย
การโจมตีที่ค่อนข้างซับซ้อนนี้อาจผ่านไปโดยไม่มีใครสังเกตเห็นจนกว่าจะมีการใช้งานระบบปฏิบัติการ Linux ที่เสถียร โชคดีที่ยังมีบางคนชอบตรวจสอบว่าทำไมสิ่งผิดปกติจึงเกิดขึ้น
การค้นพบช่องโหว่การโจมตีแบบ XZ Backdoor
หลายครั้งที่พฤติกรรมที่เป็นอันตรายที่ถูกแทรกเข้าไปนั้นถูกเปิดเผยโดยบังเอิญหรือโดยอุบัติเหตุ ตัวอย่างที่ดีคือ... คำเตือนการเลิกใช้งาน (“ใครจะไปสนใจคำเตือนกันล่ะ?”) ซึ่งนำไปสู่การค้นพบ การโจมตีสตรีมเหตุการณ์ ในเดือนตุลาคม 2018 อีกรายคือผู้ใช้ที่เตือน โค้ดคอฟ ในเดือนเมษายน 2021 สคริปต์อัปโหลด Bash ของพวกเขาไม่ผ่านการตรวจสอบ checksum ("ใครเป็นผู้ตรวจสอบความถูกต้องของไฟล์ด้วย checksum?") ความผิดปกติและอาการแปลกๆ ที่พบร่วมกับ SSH logins (loginการที่ใช้ CPU จำนวนมากและใช้เวลานานขึ้น รวมถึงข้อผิดพลาดของ Valgrind ทำให้เกิดความสงสัยขึ้นมา อันเดรส ฟรอยด์เขาเป็นนักพัฒนา PostgreSQL ที่รอบคอบ แต่ไม่ใช่ผู้เชี่ยวชาญด้านความปลอดภัย (อย่างที่เขากล่าวไว้)หลังจากตรวจสอบ OpenSSH บน Debian Sid แล้ว เขาสรุปว่าปัญหาเรื่องเวลาตอบสนองนั้นเกิดจากไลบรารีตัวใดตัวหนึ่ง ลิบลซมาเป็นส่วนหนึ่งของ xz-ยูทิลิตี้ ไลบรารีการบีบอัด เหตุผล: “คลังเก็บข้อมูล xz ต้นทางและไฟล์ tarball ของ xz ถูกแทรกช่องโหว่แล้ว“ผลการวินิจฉัยแม่นยำมาก!” เมื่อวันที่ 29 มีนาคม 2024 Andres ได้โพสต์บทวิเคราะห์แรกใน Openwall ว่า: “พบช่องโหว่ใน xz/liblzma ต้นทาง ส่งผลให้เซิร์ฟเวอร์ SSH ถูกโจมตีข้อเท็จจริง: ไฟล์ tarball ของ XZ Utils เวอร์ชัน 5.6.0 และ 5.6.1 มีช่องโหว่ซ่อนอยู่ ไฟล์ tarball เหล่านี้ถูกสร้างและลงนามโดยบัญชี Jia Tan ที่กล่าวถึงข้างต้น He โพสต์ใน Mastodon ต่อมาในวันนั้น จึงได้รู้ว่าการค้นพบนั้นเป็นเรื่องบังเอิญและต้องอาศัยเหตุการณ์บังเอิญหลายอย่าง ความคิดเห็นจากผู้ใช้คนอื่นๆ ก็คุ้มค่าแก่การอ่านเช่นกัน ผู้ใช้ GitHub เหมือนกัน (หรือที่รู้จักกันในชื่อ แซม เจมส์) ได้เผยแพร่ Gist ที่ดี คำถามที่พบบ่อยเกี่ยวกับช่องโหว่ xz-utils โดยมีการสรุปเหตุการณ์โจมตีและเชื่อมโยงไปยังรายละเอียดเพิ่มเติม การวิเคราะห์เชิงลึก ของเพย์โหลดการโจมตี การวิเคราะห์เหล่านี้มีรายละเอียดทางเทคนิคที่น่าสนใจ และช่วยให้เราเข้าใจกระบวนการฉีดได้ดียิ่งขึ้น ซึ่งเป็นกระบวนการที่ซับซ้อนมาก:- xz/liblzma: คำอธิบายเกี่ยวกับการเข้ารหัสข้อมูลใน Bash-stageการวิเคราะห์ที่ดีเกี่ยวกับการถอดรหัสโดยสคริปต์แทรกแซง โดยแบ่งออกเป็นสี่ "ขั้นตอน"
- กระทู้ท้องฟ้าสีครามของฟิลิปโป วาลซอร์ดา การวิเคราะห์ช่องโหว่ใน RSA_public_decrypt แสดงให้เห็นถึงลักษณะของมัน: เป็นช่องโหว่ที่สามารถเรียกใช้โค้ดจากระยะไกลได้ (RCE) ไม่ใช่การข้ามการตรวจสอบสิทธิ์ และมีกลไกการทำงานแบบมีเงื่อนไข (ยอมรับคีย์ส่วนตัวของผู้เขียน และหากไม่ยอมรับ จะกลับไปทำงานตามปกติ) / ไม่สามารถกู้คืนได้ ผู้เขียนตั้งใจที่จะปกปิดตัวตนเพื่อหลีกเลี่ยงการตรวจจับ!
- การวิเคราะห์ช่องโหว่ XZ โดย @smx-smx (กำลังดำเนินการ) – การวิเคราะห์เพิ่มเติมเกี่ยวกับช่องโหว่ (ผมหลงทางเกือบตั้งแต่ช่วงแรกเลย 😀)
- เอกสารเกี่ยวกับช่องโหว่ xz ในวิกิการวิเคราะห์สคริปต์การฉีดเวอร์ชัน 5.6.1 อีกครั้ง
วิธีการจัดการเหตุการณ์ดังกล่าว
การเปิดเผยข้อมูลของแอนเดรียส ฟรอยด์นั้นค่อนข้างระมัดระวัง เนื่องจากตามคำพูดของเขาเอง:“เนื่องจากเห็นได้ชัดว่ามีส่วนเกี่ยวข้องจากต้นทาง ผมจึงไม่ได้รายงานบั๊กไปยังต้นทาง ในตอนแรกผมคิดว่าเป็นปัญหาเฉพาะของ Debian ดังนั้นผมจึงส่งรายงานเบื้องต้นไปที่ security@...ian.org ต่อมา ผมจึงรายงานปัญหาดังกล่าวไปยัง distros@. CISเอ ได้รับแจ้งจากฝ่ายจัดจำหน่าย”
ใครกำลังถูกโจมตี?
บัญชี GitHub JiaT75 อาจถูกแฮ็ก (โปรดจำไว้ว่า GitHub เพิ่งกำหนดให้ใช้ 2FA เมื่อเร็วๆ นี้) หรือผู้ใช้จริงที่เป็นเจ้าของบัญชีนั้นหันไปใช้ช่องโหว่ของระบบรักษาความปลอดภัยทางไซเบอร์ แต่มีเหตุผลที่น่าเชื่อถือให้คิดว่าอาจเป็นภัยคุกคามขั้นสูงแบบต่อเนื่อง (APT) ซึ่งอาจได้รับการสนับสนุนจากรัฐบาล เนื่องจากความซับซ้อนทางเทคนิคของการโจมตี การตรวจสอบเพิ่มเติมจากหน่วยงานด้านความปลอดภัยทางไซเบอร์และหน่วยงานบังคับใช้กฎหมายจะให้คำตอบ... รายการนี้ ใน YCombinator Hacker News เกี่ยวกับ Jia Tan ช่วยให้เข้าใจถึง "ตัวบุคคล" และกิจกรรมของเขาได้ดียิ่งขึ้น แนะนำเลย! ให้ข้อมูลมากมายเกี่ยวกับวิธีการที่ผู้ไม่หวังดีพยายามหลอกลวงผู้ใช้รายอื่นโดยใช้เทคนิคทางสังคม“น่าหงุดหงิดมาก – ผู้เขียนช่องโหว่ที่เห็นได้ชัดติดต่อกับผม (rwmj) มาหลายสัปดาห์เพื่อพยายามเพิ่ม xz 5.6.x ลงใน Fedora 40 และ 41 เพราะอ้างว่ามี “คุณสมบัติใหม่ที่ยอดเยี่ยม” เรายังร่วมมือกับเขาในการแก้ไขปัญหา Valgrind (ซึ่งตอนนี้ปรากฏว่าเกิดจากช่องโหว่ที่เขาเพิ่มเข้ามา) เราต้องเร่งแก้ไขปัญหาเมื่อคืนนี้หลังจากที่เผลอละเมิดข้อห้าม เขามีส่วนร่วมในโครงการ xz มา 2 ปีแล้ว โดยเพิ่มไฟล์ทดสอบไบนารีต่างๆ มากมาย และพูดตามตรง ด้วยระดับความเชี่ยวชาญเช่นนี้ ผมคงจะสงสัยแม้แต่เวอร์ชันเก่ากว่าของ xz จนกว่าจะได้รับการพิสูจน์เป็นอย่างอื่น”
เจีย ตัน ได้ดำเนินการเพื่อป้องกันการถูกติดตาม: ดูเหมือนว่าจะใช้ VPN (vpn.singapore.witopia.net) ในการเชื่อมต่อ ซึ่งก็ถือว่าโอเค และการเปลี่ยนแปลงหลายอย่างดูเหมือนจะได้รับการสนับสนุนด้วยอีเมลชั่วคราวที่ใช้ได้เพียงครั้งเดียว (ในกรณีนี้มาจาก ProtonMail) เพื่อกระตุ้นให้รวมการเปลี่ยนแปลงเข้าด้วยกัน
นักแสดงอาจตั้งใจที่จะเจาะลึกลงไปอีก จนถึงระดับเคอร์เนลของลินุกซ์ ในฐานะผู้มีส่วนร่วมในโครงการดังกล่าว ฝัง xy โครงการนี้ การวิเคราะห์เบื้องต้นไม่พบหลักฐานการแท้งบุตร ณ วันนี้
หมายเหตุ: อีกอย่างหนึ่ง ฮันส์ แจนเซ่น ผู้ร่วมงานของ XZ ที่ไม่ค่อยเปิดเผยตัวตน (ผู้ใช้ GitHub “hansjans162”) คือ ภายใต้การตรวจสอบข้อเท็จจริงบัญชีของมันใน Debian ตอนนี้คือ ที่ถูกบล็อกเขาทำการอัปเดต Debian Games หลายครั้งเพื่อปกปิดการอัปเดตที่เขาต้องการใน debian/xz-utils รวมถึงการอัปเดตเวอร์ชัน 5.6.1 ของต้นทาง เพื่อเร่งการเผยแพร่ช่องโหว่ เดเบียน/อันสเตเบิล.
สิ่งที่เราสามารถพูดได้ในตอนนี้คือ นี่คือกลุ่มแฮกเกอร์ APT (ที่ยังไม่สามารถระบุตัวตนได้) ที่ใช้บัญชีผู้ใช้หลายบัญชี ทำงานในโครงการนี้มาอย่างน้อยสองปี และค่อยๆ วางแผนเพื่อฝังช่องโหว่ RCE ใน SSH
ณ ขณะเขียนบทความนี้ ยังไม่มีการยืนยันตัวตนของ “เจีย ตัน” อย่างเป็นทางการ ไม่มีการระบุตัวบุคคล องค์กร หรือหน่วยงานรัฐใดอย่างน่าเชื่อถือ ซึ่งแสดงให้เห็นถึงประสิทธิภาพของกลไกการทำงานของตัวตนนี้
การโจมตีช่องโหว่ XZ สามารถป้องกันได้หรือไม่?
ค่อนข้างยาก
ประการแรก ส่วนหนึ่งของแบ็กดอร์ที่ถูกแทรกเข้าไปนั้นอยู่ในไฟล์ทดสอบที่ถูกบีบอัดซึ่งไม่ได้ถูกนำไปใช้ในการทดสอบจริง เมื่อมองย้อนกลับไป อาจทำให้เกิดสัญญาณเตือน (ที่ดังเกินจริง) แต่ใครจะสนใจตรวจสอบว่าไฟล์ทดสอบทั้งหมดถูกนำไปใช้ในการทดสอบจริงในโลกแห่งความเป็นจริงกันล่ะ? ประการที่สอง ส่วนหนึ่งของแบ็กดอร์ที่ถูกแทรกเข้าไปนั้นอยู่ในไฟล์มาโครในไฟล์ tarball ที่ใช้ในการเผยแพร่ และเป็นการยากที่จะตรวจสอบความแตกต่างกับไฟล์ tarball ที่คาดหวังไว้ด้วยตนเอง การทำงานแบบอัตโนมัติก็ซับซ้อนเช่นกัน เนื่องจากผลลัพธ์ที่คาดหวังจากการสร้าง (สำหรับผู้ที่รู้วิธีการทำงานของ automake/autoconf) นั้นยากที่จะสร้างแบบจำลองเพื่อวิเคราะห์ว่าไฟล์ tarball จริงตรงกับที่คาดหวังหรือไม่ บางคนตั้งคำถามนั้น as “การที่ไฟล์ tarball ไม่ตรงกับโครงสร้างไฟล์ของ git นั้นเป็นคุณสมบัติ ไม่ใช่ข้อผิดพลาด”แหล่งที่มาของไฟล์ไบนารีแบบ tarball จากซอร์สโค้ด ยังคงเป็นปัญหาที่ยังไม่ได้รับการแก้ไข
ชื่อเสียงของผู้ใช้? อืม ตามประวัติที่ผ่านมา บัญชี GitHub ของ JiaTan75 ไม่ได้ทำอะไรที่ผิดกฎหมาย commitบัญชีถูกระงับหลังจากมีหลักฐานสะสมมากขึ้น แต่จนถึงวันที่ 29 มีนาคม ผู้ใช้งานรายนั้นยังคงทำธุรกรรมตามปกติ แต่ที่จริงแล้วไม่ปกติเท่าไหร่ ต่อมา commits (นี้, นี้, นี้และ นี้ ซึ่งได้ปรับโค้ดการโจมตีแล้ว) พยายามแก้ไขข้อผิดพลาดและการหยุดทำงานของ Valgrind ในบางการตั้งค่า เนื่องจากความแตกต่างกับโครงสร้างสแต็กที่แบ็กดอร์คาดหวัง Commit การตรวจสอบอาจตรวจพบสิ่งนี้ได้ แต่ใครจะมีความอดทนมากพอที่จะวิเคราะห์การเปลี่ยนแปลงในไฟล์ทดสอบไบนารี หรือมีแรงจูงใจที่แท้จริงในการเปลี่ยนแปลงคุณสมบัติของ GCC ในซอร์สโค้ดภาษา C?
ควรแจ้งเตือนหรือไม่เมื่อมีการเชื่อมต่อ SSH ผิดพลาด login ใช้เวลา 800 มิลลิวินาที แทนที่จะเป็น 300 มิลลิวินาที? คงมีแต่คนรอบคอบมากๆ เท่านั้นที่จะสังเกตเห็น ซิเซโรกล่าวว่า... “ความใจร้อนเป็นของวัยหนุ่มสาว ความรอบคอบเป็นของวัยชรา”
โครงสร้างพื้นฐานของ ifunc ถูกเพิ่มเข้ามาในเดือนมิถุนายน 2023 โดย “Hans Jansen” และ “Jia Tan” นี่เป็นครั้งแรก commit เพิ่มการรองรับ ifunc ให้กับ crc64_fast.c (ซึ่งต่อมาใช้ในการแทรกแบ็กดอร์) หลายเดือนก่อนที่จะแทรกไบนารีแบ็กดอร์ลงในไฟล์ทดสอบ!
หมายเหตุ: ผู้เขียนและ commitอาจมีความเห็นต่างกันตรงนี้ แต่เป็นเรื่องปกติ: ลาสเซ่ คอลลิน เป็นผู้ดูแลโครงการ และเขารวมการเปลี่ยนแปลงต่างๆ เข้าไปด้วย เขายังขอบคุณ "ฮันส์ แจนเซ่น" อีกด้วย...
ไม่มีใครแสดงความกังวลมาก่อนโพสต์ของ Andres Freund และ CVE ที่สร้างโดย RedHat หากคุณเห็นเครื่องมือหลายตัวที่สามารถตรวจจับช่องโหว่นี้ได้ ตอนนี้พวกมันตรวจพบส่วนประกอบที่ได้รับผลกระทบแล้ว อดีตโพสต์พฤตินัย.
วิธีป้องกันที่ดีที่สุดน่าจะมาจากลักษณะเฉพาะของระบบปฏิบัติการลินุกซ์ และวิธีการที่เวอร์ชันที่ไม่เสถียรและล้ำสมัยจะถูกส่งต่อไปยังเวอร์ชันที่เสถียรในภายหลังตามกระบวนการที่เป็นขั้นเป็นตอน
บทเรียนที่ได้จาก XZ bBackdoor Attack
เราได้สังเกตเห็นแล้วว่าการตรวจจับนั้นยากเพียงใด โดยเจตนา ช่องโหว่ลับ (Backdoors) ควรถูกพิจารณาว่าเป็นภัยคุกคามภายใน เนื่องจากถูกสร้างขึ้นโดยพนักงานภายในหรือผ่านบัญชีภายในที่ถูกบุกรุก และคนเหล่านั้นส่วนใหญ่เป็นคนที่ได้รับความไว้วางใจ และเมื่อช่องโหว่ลับถูกฝังอยู่ในไฟล์ที่เผยแพร่แล้ว จะทำให้ตรวจจับได้ยากขึ้น
นักเขียนบางคน เช่น เควิน บิวโมนต์ ชี้ไปที่ ระบบซึ่งเปิดช่องโหว่ขนาดใหญ่ให้กับการโจมตีบริการของบุคคลที่สาม นี่คือสิ่งที่ผู้ไม่ประสงค์ดีใช้ประโยชน์ในกรณีนี้ Systemd มีผู้ใช้งานจำนวนมาก แต่ XZ เป็นไลบรารีที่ไม่ค่อยมีคนรู้จักในลำดับต้นๆ “เมื่อต้นน้ำปนเปื้อน ทุกคนก็ดื่มน้ำที่ปนเปื้อนพิษในปลายน้ำ”
คำขอเปลี่ยนแปลงที่ไม่เกี่ยวข้องในระบบสำหรับ การโหลดไลบรารีการบีบอัดแบบไดนามิกซึ่งจะช่วยกำจัดช่องโหว่นั้น ได้ถูกรวมเข้ากับระบบแล้ว แต่ยังไม่ได้ส่งมอบ การพึ่งพาเพิ่มเติมที่เกิดจาก libsystemd อาจเป็นสาเหตุของช่องโหว่และเมื่อวานนี้ คำขอนี้ถูกเปิดขึ้น.
A ความเห็น ในหัวข้อ “xz: ปิดใช้งาน ifunc เพื่อแก้ไขปัญหา” commit ให้มุมมองที่เฉียบคมเกี่ยวกับจุดที่ควรให้ความสำคัญหากเราต้องการป้องกันกิจกรรมดังกล่าว (เน้นข้อความโดยผู้เขียน):
“บทเรียนที่เราควรเรียนรู้ในฐานะชุมชนคือการรักษาความปลอดภัยให้มากขึ้น” software supply chain security ในภาพรวม การตรวจสอบระบบการสร้างซอฟต์แวร์นั้นครอบคลุมมากกว่าแค่ซอร์สโค้ด เช่น กรณีการละเมิดข้อมูลของ SolarWinds ที่ผู้โจมตีแก้ไขการอัปเดตซอฟต์แวร์สำหรับซอฟต์แวร์ตรวจสอบแบบปิดแหล่งที่มาของ SolarWinds”
คำถามที่พบบ่อย
ช่องโหว่ XZ ยังคงมีความเสี่ยงอยู่ในปัจจุบันหรือไม่?
ส่วนใหญ่ถูกควบคุมแล้ว แต่ยังไม่หายไปทั้งหมด ในเดือนสิงหาคม 2025 นักวิจัยพบว่าช่องโหว่ยังคงมีอยู่ในอิมเมจ Docker Hub ของ Debian หลายตัว ซึ่ง Debian ถือว่าเป็นสิ่งประดิษฐ์ทางประวัติศาสตร์ที่ไม่ได้ใช้งานแล้ว ทีมงานควรตรวจสอบให้แน่ใจว่าไม่ได้ใช้ภาพพื้นฐานที่ล้าสมัยและไม่ได้แก้ไขช่องโหว่ แทนที่จะคิดว่าแพทช์ปี 2024 ปิดช่องโหว่นั้นอย่างสมบูรณ์แล้ว
