SSH ສຳລັບການປິດປະຕູທາງຫຼັງ
ຜູ້ຮັກສາທີ່ຊົ່ວຮ້າຍ ຫຼື ຖືກໂຈມຕີໄດ້ໃສ່ພຶດຕິກຳທີ່ເປັນອັນຕະລາຍໃນຫ້ອງສະໝຸດທີ່ມີຊື່ວ່າ liblzma, ສ່ວນໜຶ່ງຂອງເຄື່ອງມືບີບອັດ ແລະ ຫ້ອງສະໝຸດ xz, ເຊິ່ງເຮັດໃຫ້ເກີດ backdoor ໃນ SSH. ນີ້ແມ່ນການໂຈມຕີລະບົບຕ່ອງໂສ້ການສະໜອງຊອບແວຂັ້ນສູງ ຍ້ອນວ່າຫ້ອງສະໝຸດໄດ້ຖືກດັດແປງໂດຍເຈດຕະນາສຳລັບ backdoor, ດ້ວຍເຕັກນິກການປິດບັງ ແລະ ການລັກລອບເພື່ອເຊື່ອງ payload ການໂຈມຕີຈາກຜູ້ທົບທວນ.
ມັນໄດ້ຖືກຄົ້ນພົບ ແລະ ເປີດເຜີຍເມື່ອບໍ່ດົນມານີ້ (ໃນວັນທີ 29 ມີນາ ທີ່ຜ່ານມາ), ແລະ ການຈັດການການໂຈມຕີຍັງດຳເນີນຢູ່. ເຖິງຢ່າງໃດກໍ່ຕາມ, ມັນໄດ້ຖືກຄວບຄຸມຢ່າງໄວວາ ຍ້ອນວ່າມັນເບິ່ງຄືວ່າຈະສົ່ງຜົນກະທົບຕໍ່ພຽງແຕ່ລຸ້ນກ່ອນການປ່ອຍຂອງຊຸດສະພາບແວດລ້ອມທີ່ຈຳກັດ (ແພັກເກດ DEB ແລະ RPM, ສຳລັບສະຖາປັດຕະຍະກຳ x86_64, ແລະ ສ້າງດ້ວຍ GCC). ເຖິງຢ່າງໃດກໍ່ຕາມ, CVE ໄດ້ຖືກມອບໃຫ້ ຄະແນນພື້ນຖານ CVSS ຂອງ 10, ເຊິ່ງສະຫງວນໄວ້ສຳລັບຊ່ອງໂຫວ່ຄວາມປອດໄພທາງໄຊເບີທີ່ສຳຄັນທີ່ສຸດ. ຖ້າມັນເຂົ້າສູ່ການແຈກຢາຍທີ່ໝັ້ນຄົງ, ຜົນກະທົບຈະຮ້າຍແຮງຫຼາຍ.
ການວິເຄາະດ້ານເຕັກນິກຂອງການໂຈມຕີ, ລວມທັງ ອະທິບາຍລາຍລະອຽດກ່ຽວກັບປະຕູຫລັງ xz, ໄດ້ຖືກວິເຄາະຢູ່ບ່ອນອື່ນ. ໂພສນີ້ຈະສຸມໃສ່ເສັ້ນເວລາຂອງການໂຈມຕີ, ວິທີການກວດພົບມັນ, ວິທີການຈັດການກັບເຫດການໃນປະຈຸບັນ, ແລະບົດຮຽນໃດແດ່ທີ່ອາດຈະສະກັດອອກມາຈາກການໂຈມຕີ.
ຫາງຍາວຂອງປະຕູຫຼັງຍັງສືບຕໍ່ຜ່ານການແກ້ໄຂເບື້ອງຕົ້ນໄປດົນແລ້ວ. ໃນເດືອນສິງຫາ 2025, ຫຼາຍກວ່າໜຶ່ງປີຫຼັງຈາກ CVE-2024-3094 ໄດ້ຖືກເປີດເຜີຍ, ນັກຄົ້ນຄວ້າຄວາມປອດໄພທີ່ Binarly ພົບວ່າປະຕູຫຼັງຍັງຄົງມີຢູ່ໃນຮູບພາບ Debian Docker ຫຼາຍສິບຮູບທີ່ເຜີຍແຜ່ໃນ Docker Hub, ໂດຍທີມງານຂອງ Debian ປະຕິເສດທີ່ຈະລຶບພວກມັນອອກ, ໂດຍຖືວ່າພວກມັນເປັນສິ່ງປະດິດການພັດທະນາທາງປະຫວັດສາດແທນທີ່ຈະເປັນຄວາມສ່ຽງທີ່ມີການເຄື່ອນໄຫວ. ແຍກຕ່າງຫາກ, OpenSSF ແລະ OpenJS ໄດ້ອອກຄຳເຕືອນຮ່ວມກັນບໍ່ດົນຫຼັງຈາກເຫດການ XZ ວ່າຄວາມພະຍາຍາມເຂົ້າຄວບຄຸມໂຄງການວິສະວະກຳສັງຄົມທີ່ຄ້າຍຄືກັນນີ້ໄດ້ແນໃສ່ໂຄງການ JavaScript ແລ້ວ, ເຊິ່ງຊີ້ໃຫ້ເຫັນວ່າຮູບແບບການໂຈມຕີແບບ maintainer-trust ທີ່ໃຊ້ຢູ່ນີ້ກຳລັງຖືກນຳໃຊ້ຄືນຢູ່ບ່ອນອື່ນ.
ວິທີການສັກຢາເຂົ້າປະຕູຫຼັງຂອງ XZ
ໝາຍເຫດ: ບ່ອນເກັບມ້ຽນ git ຢູ່ໃນ git.tukaani.orgທີ່ຢູ່ ເຖິງຢ່າງໃດກໍ່ຕາມ, ຍັງມີ ບ່ອນເກັບມ້ຽນຂໍ້ມູນ GitHub ທີ່ໂຮດຢູ່ (ປະຈຸບັນຖືກບລັອກ) ບ່ອນທີ່ບັນຊີ GitHub ກຳລັງໂພສການປ່ຽນແປງທີ່ຕໍ່ມາໄດ້ຖືກລວມເຂົ້າໃນບ່ອນເກັບມ້ຽນ Git.
ສ່ວນໜຶ່ງຂອງປະຕູຫຼັງເບິ່ງຄືວ່າຈະຢູ່ໃນ tarballs ແບບກະຈາຍສຳລັບລຸ້ນ 5.6.0 ແລະ 5.6.1 ເທົ່ານັ້ນ, ບໍ່ແມ່ນຢູ່ໃນບ່ອນເກັບມ້ຽນ git ແລະອີງໃສ່ ແຖວດຽວໃນ build-to-host.m4 ໄຟລ໌ macro ທີ່ໃຊ້ໂດຍ autoconf. ສ່ວນອື່ນແມ່ນຢູ່ໃນສອງໄຟລ໌ທົດສອບທີ່ຄາດວ່າຈະເປັນ bad-3-corrupt_lzma2.xz ແລະ good-large_compressed.lzma
ວ່າແມ່ນ committed ໂດຍບັນຊີ GitHub “Jia Tan” (JiaT75) ໃນ ບ່ອນເກັບມ້ຽນ xz ໃນວັນທີ 23 ກຸມພາ. ມັນເປັນການປ່ຽນແປງທີ່ບໍ່ເປັນອັນຕະລາຍໂດຍການເພີ່ມໄຟລ໌ທົດສອບ (ຄາດວ່າຈະເປັນບລັອກບີບອັດ .lzma ແລະ .xz). ໜ້າສົນໃຈພໍສົມຄວນ, ໄຟລ໌ທົດສອບບໍ່ໄດ້ຖືກນຳໃຊ້ໂດຍການທົດສອບ! ແຖວໃນໄຟລ໌ .m4 ໃສ່ສະຄຣິບທີ່ສັບສົນ (ລວມຢູ່ໃນ tarball) ເພື່ອປະຕິບັດໃນຕອນທ້າຍຂອງ configure ຖ້າເງື່ອນໄຂບາງຢ່າງກົງກັນ. ມັນດັດແປງ Makefile ສຳລັບ liblzma ຫ້ອງສະໝຸດເພື່ອບັນຈຸລະຫັດທີ່ສະກັດຂໍ້ມູນຈາກໄຟລ໌ .xz, ເຊິ່ງຫຼັງຈາກການຖອດລະຫັດອອກຈາກໄຟລ໌ .xz ສິ້ນສຸດລົງ ໃນສະຄຣິບນີ້, ຖືກເອີ້ນໃຊ້ໃນຕອນທ້າຍຂອງ configure. ມັນຕັດສິນໃຈວ່າຈະດັດແປງຂະບວນການສ້າງເພື່ອສີດລະຫັດ: ສະເພາະພາຍໃຕ້ GCC ແລະ GCC linker, ພາຍໃຕ້ Debian ຫຼື rpm, ແລະສະເພາະສຳລັບ x86_64 Linux. ເມື່ອຈັບຄູ່, ລະຫັດທີ່ສີດເຂົ້າໄປຈະສະກັດກັ້ນການປະຕິບັດໂດຍການທົດແທນສອງ ອິຟັນ ຕົວແກ້ໄຂ ດັ່ງນັ້ນການເອີ້ນບາງຢ່າງຈຶ່ງຖືກປ່ຽນແທນ. ສິ່ງນີ້ເຮັດໃຫ້ຕາຕະລາງສັນຍາລັກຖືກວິເຄາະໃນໜ່ວຍຄວາມຈຳ (ສິ່ງນີ້ໃຊ້ເວລາ, ເຊິ່ງນຳໄປສູ່ການກວດສອບ, ດັ່ງທີ່ໄດ້ອະທິບາຍໃນພາຍຫຼັງ).
ຫຼັງຈາກນັ້ນສິ່ງຕ່າງໆກໍ່ໜ້າສົນໃຈ: ປະຕູຫຼັງຕິດຕັ້ງຕົວເຊື່ອມຕໍ່ການກວດສອບເຂົ້າໄປໃນຕົວເຊື່ອມຕໍ່ແບບໄດນາມິກ, ລໍຖ້າສັນຍາລັກຟັງຊັນ RSA_public_decrypt ມາຮອດ, ເຊິ່ງຖືກໂອນໄປຫາຈຸດໜຶ່ງເຂົ້າໄປໃນລະຫັດປະຕູຫຼັງ, ເຊິ່ງຈະເອີ້ນກັບຄືນ. libcrypto, ສົມມຸດວ່າເພື່ອປະຕິບັດການພິສູດຢືນຢັນຕົວຕົນຕາມປົກກະຕິ. ແລະ payload ຈະເປີດໃຊ້ງານຖ້າໂປຣແກຣມທີ່ກຳລັງແລ່ນມີຊື່ຂະບວນການ. /usr/sbin/sshdມັນເປັນທີ່ຊັດເຈນວ່າເຊີບເວີ SSH ແມ່ນເປົ້າໝາຍ. ຕາມປະເພນີ, ssh ເຊີບເວີຕ່າງໆເຊັ່ນ OpenSSH ບໍ່ໄດ້ຖືກເຊື່ອມໂຍງກັບ liblzma, ແຕ່ sshd ແມ່ນ ມັກຈະຖືກແກ້ໄຂ ເພື່ອຮອງຮັບ systemd-notify ເພື່ອໃຫ້ການບໍລິການອື່ນໆສາມາດເລີ່ມຕົ້ນໄດ້ເມື່ອ sshd ກຳລັງເຮັດວຽກຢູ່. ແລະຫຼັງຈາກນັ້ນ liblzma ແມ່ນຖືກໂຫຼດໂດຍທາງອ້ອມ systemd, ປິດວົງມົນ.
ປະຕູຫຼັງຍັງບໍ່ທັນໄດ້ຖືກວິເຄາະຢ່າງຄົບຖ້ວນ, ແຕ່ມັນເບິ່ງຄືວ່າ ອະນຸຍາດໃຫ້ປະຕິບັດຄຳສັ່ງຈາກໄລຍະໄກ (RCE) ດ້ວຍສິດທິພິເສດຂອງ daemon sshd, ເຮັດວຽກຢູ່ໃນສະພາບການກ່ອນການກວດສອບຄວາມຖືກຕ້ອງ. ຂໍ້ມູນຈາກໃບຢັ້ງຢືນໄລຍະໄກ, ເມື່ອຈັບຄູ່ໂດຍ backdoor, ຈະຖືກຖອດລະຫັດດ້ວຍ ChaCha20, ແລະເມື່ອມັນຖອດລະຫັດສຳເລັດແລ້ວ ມັນຈະຖືກສົ່ງໄປຫາ ລະບົບ()ສະນັ້ນ, ນີ້ແມ່ນ RCE ທີ່ມີຮົ້ວກັ້ນ, ຮ້າຍແຮງກວ່າການຂ້າມກະແຈສາທາລະນະຫຼາຍ.
tarball 5.6.1 ຕໍ່ມາໄດ້ສະແດງໃຫ້ເຫັນຄວາມພະຍາຍາມເພີ່ມເຕີມເພື່ອເຊື່ອງຮ່ອງຮອຍ, ເພີ່ມການປິດບັງຊື່ສັນຍາລັກຕື່ມອີກ, ແລະພະຍາຍາມແກ້ໄຂຂໍ້ຜິດພາດທີ່ເຫັນ. ກົນໄກການຂະຫຍາຍ ບ່ອນທີ່ໄຟລ໌ທົດສອບເພີ່ມເຕີມຖືກຊອກຫາລາຍເຊັນທີ່ແນ່ນອນເພື່ອເພີ່ມໃສ່ປະຕູຫຼັງກໍ່ຖືກວາງໄວ້.
ການໂຈມຕີທີ່ຊັບຊ້ອນພໍສົມຄວນນີ້ອາດຈະບໍ່ຖືກສັງເກດເຫັນຈົນກວ່າການແຈກຢາຍ Linux ທີ່ໝັ້ນຄົງຈະບັນລຸໄດ້. ໂຊກດີ, ບາງຄົນມັກກວດສອບວ່າເປັນຫຍັງສິ່ງທີ່ຜິດປົກກະຕິຈຶ່ງເກີດຂຶ້ນ.
ການຄົ້ນພົບການໂຈມຕີ Backdoor XZ
ຫຼາຍຄັ້ງທີ່ມີພຶດຕິກຳທີ່ເປັນອັນຕະລາຍທີ່ຖືກສັກເຂົ້າໄປນັ້ນຖືກຄົ້ນພົບໂດຍບັງເອີນ ຫຼື ໂດຍອຸບັດຕິເຫດ. ຕົວຢ່າງທີ່ດີແມ່ນ ຄຳເຕືອນກ່ຽວກັບການຍົກເລີກການນຳໃຊ້ (“ໃຜສົນໃຈຄຳເຕືອນ?”) ທີ່ນຳໄປສູ່ການຄົ້ນພົບ ການໂຈມຕີແບບກະແສເຫດການ ໃນເດືອນຕຸລາ 2018. ອີກອັນໜຶ່ງແມ່ນຜູ້ໃຊ້ທີ່ເຕືອນ ໂຄດໂຄດ ໃນເດືອນເມສາ 2021 ວ່າສະຄຣິບອັບໂຫລດ bash ຂອງເຂົາເຈົ້າບໍ່ຜ່ານ checksum (“ໃຜກວດສອບຄວາມສົມບູນຂອງສິ່ງປະດິດດ້ວຍ checksum”) ຄວາມຜິດປົກກະຕິ ແລະ ອາການແປກໆກັບ ssh logins (loginໃຊ້ CPU ຫຼາຍ ແລະ ເວລາທີ່ຜ່ານໄປເພີ່ມຂຶ້ນ, ຄວາມຜິດພາດຂອງ valgrind) ກະຕຸ້ນຄວາມຢາກຮູ້ຢາກເຫັນຂອງ Andres Freund, ນັກພັດທະນາ PostgreSQL ທີ່ລະມັດລະວັງ ແຕ່ບໍ່ແມ່ນນັກວິເຄາະຄວາມປອດໄພ (ດັ່ງທີ່ລາວໄດ້ລະບຸໄວ້ຫຼັງຈາກການສືບສວນບາງຢ່າງກັບ OpenSSH ໃນ Debian Sid, ລາວໄດ້ສະຫຼຸບວ່າບັນຫາເວລາຕອບສະໜອງແມ່ນຂຶ້ນກັບຫ້ອງສະໝຸດ, liblzma, ສ່ວນຫນຶ່ງຂອງ XZ, utils ຫ້ອງສະໝຸດບີບອັດ. ເຫດຜົນ: “ບ່ອນເກັບມ້ຽນ xz ທາງເທິງ ແລະ tarballs xz ໄດ້ຖືກບລັອກໄວ້ທາງຫຼັງແລ້ວ". ການວິນິດໄສນີ້ແມ່ນຖືກຕ້ອງຫຼາຍ! ໃນວັນທີ 29 ມີນາ 2024 Andres ໄດ້ລົງການວິເຄາະຄັ້ງທຳອິດໃນ Openwall ວ່າ: “ປະຕູຫລັງໃນ upstream xz/liblzma ນຳໄປສູ່ການປະນີປະນອມເຊີບເວີ ssh"ຄວາມຈິງ: tarballs ຂອງ XZ Utils 5.6.0 ແລະ 5.6.1 ມີ backdoor. tarballs ເຫຼົ່ານີ້ຖືກສ້າງຂຶ້ນ ແລະ ລົງນາມໂດຍບັນຊີ Jia Tan ທີ່ໄດ້ກ່າວມາຂ້າງເທິງ. He ລົງໃນ Mastodon ຕໍ່ມາໃນມື້ນັ້ນ, ໂດຍຮັບຮູ້ວ່າການຄົ້ນພົບດັ່ງກ່າວແມ່ນບັງເອີນ ແລະ ຕ້ອງການຄວາມບັງເອີນຫຼາຍຢ່າງ. ຄຳເຫັນຈາກຜູ້ໃຊ້ຄົນອື່ນໆກໍ່ຄຸ້ມຄ່າທີ່ຈະອ່ານ. ຜູ້ໃຊ້ GitHub ເທຊາມີແຊມ (ຫຼື Sam James) ໄດ້ເຜີຍແຜ່ບົດສະຫຼຸບທີ່ດີ ຄຳຖາມທີ່ຖືກຖາມເລື້ອຍໆກ່ຽວກັບປະຕູຫຼັງ xz-utils ບ່ອນທີ່ການໂຈມຕີໄດ້ຖືກສະຫຼຸບ, ເຊື່ອມໂຍງເຂົ້າໄປໃນເພີ່ມເຕີມ ການວິເຄາະຄວາມເລິກ ຂອງພາລະການໂຈມຕີ. ການວິເຄາະເຫຼົ່ານີ້ແມ່ນມີຄວາມລະອຽດທາງດ້ານເຕັກນິກ, ແລະຊ່ວຍໃຫ້ພວກເຮົາເຂົ້າໃຈການສັກຢາໄດ້ດີຂຶ້ນ, ເຊິ່ງໄດ້ຮັບການອະທິບາຍຢ່າງລະອຽດ:- xz/liblzma: ອະທິບາຍການປິດບັງຂັ້ນຕອນການປະທະກັນການວິເຄາະທີ່ດີກ່ຽວກັບການລຶບລ້າງຄວາມມົວໂດຍສະຄຣິບສີດ, ໃນສີ່ "ຂັ້ນຕອນ".
- ກະທູ້ bluesky ຂອງ Filippo Valsorda ການວິເຄາະປະຕູຫຼັງໃນ RSA_public_decrypt, ເຊິ່ງສະແດງໃຫ້ເຫັນລັກສະນະຂອງມັນ: RCE, ບໍ່ແມ່ນການຂ້າມການອະນຸມັດ, ແລະ gated (ຍອມຮັບລະຫັດສ່ວນຕົວຂອງຜູ້ຂຽນ ແລະ ຖ້າບໍ່, ຈະກັບຄືນສູ່ພຶດຕິກຳປົກກະຕິ) / ບໍ່ສາມາດຈ່າຍຄືນໄດ້. ຜູ້ຂຽນມີຈຸດປະສົງທີ່ຈະໄປ low profile ເພື່ອຫຼີກເວັ້ນການກວດພົບ!
- ການວິເຄາະປະຕູຫຼັງ XZ ໂດຍ @smx-smx (WIP) - ການວິເຄາະເພີ່ມເຕີມກ່ຽວກັບ backdoor (ຂ້ອຍເກືອບຈະຫຼົງທາງໃນຕອນເລີ່ມຕົ້ນ 😀)
- ວິກິພີເດຍເອກະສານປະຕູຫຼັງ xz, ການວິເຄາະອີກອັນໜຶ່ງຂອງສະຄຣິບການສີດ 5.6.1.
ວິທີການຈັດການເຫດການດັ່ງກ່າວ
ການເປີດເຜີຍໂດຍ Andreas Freund ມີຄວາມລະມັດລະວັງເພາະວ່າໃນຄໍາເວົ້າຂອງລາວເອງ:"ເນື່ອງຈາກມີການມີສ່ວນຮ່ວມຂອງ upstream ທີ່ເຫັນໄດ້ຊັດເຈນ, ຂ້ອຍຍັງບໍ່ທັນໄດ້ລາຍງານຂໍ້ຜິດພາດຂອງ upstream. ໃນເບື້ອງຕົ້ນຂ້ອຍຄິດວ່າມັນເປັນບັນຫາສະເພາະຂອງ debian, ຂ້ອຍຈຶ່ງໄດ້ສົ່ງລາຍງານເບື້ອງຕົ້ນໄປທີ່ security@...ian.org. ຕໍ່ມາ, ຂ້ອຍໄດ້ລາຍງານບັນຫາໄປທີ່ distros@." CISA ໄດ້ຮັບແຈ້ງຈາກການແຈກຢາຍ.”
ໃຜຢູ່ພາຍໃຕ້ການໂຈມຕີ?
ບໍ່ວ່າບັນຊີ GitHub JiaT75 ຈະຖືກໂຈມຕີ (ຈົ່ງຈື່ໄວ້ວ່າ GitHub ໄດ້ບັງຄັບໃຫ້ໃຊ້ 2FA ເມື່ອບໍ່ດົນມານີ້) ຫຼື ຜູ້ໃຊ້ທາງກາຍະພາບທີ່ເປັນໜີ້ບັນຊີໄດ້ໄປສູ່ດ້ານມືດ. ແຕ່ມີເຫດຜົນທີ່ໜ້າສົນໃຈທີ່ຈະຄິດກ່ຽວກັບໄພຂົ່ມຂູ່ທີ່ຍືນຍົງຂັ້ນສູງ (APT), ບາງທີອາດຈະໄດ້ຮັບການສະໜັບສະໜູນຈາກລັດ, ເນື່ອງຈາກຄວາມຊັບຊ້ອນທາງດ້ານເຕັກນິກຂອງການໂຈມຕີ. ການສືບສວນຕື່ມອີກໂດຍອົງການຄວາມປອດໄພທາງໄຊເບີ ແລະ ການບັງຄັບໃຊ້ກົດໝາຍຈະບອກ... ເຂົ້ານີ້ ໃນ YCombinator Hacker News ກ່ຽວກັບ Jia Tan ໃຫ້ຄວາມกระจ่างກ່ຽວກັບ “ຜູ້ທີ່” ແລະກິດຈະກຳຂອງລາວ. ແນະນຳ! ມັນໃຫ້ຂໍ້ມູນຫຼາຍຢ່າງກ່ຽວກັບວິທີທີ່ຄົນບໍ່ດີພະຍາຍາມຫຼອກລວງຜູ້ໃຊ້ຄົນອື່ນໂດຍໃຊ້ວິສະວະກຳສັງຄົມ."ໜ້າລຳຄານຫຼາຍ - ຜູ້ຂຽນ backdoor ທີ່ເຫັນໄດ້ຊັດເຈນໄດ້ຕິດຕໍ່ສື່ສານກັບຂ້ອຍ (rwmj) ເປັນເວລາຫຼາຍອາທິດເພື່ອພະຍາຍາມເພີ່ມ xz 5.6.x ໃສ່ Fedora 40 & 41 ເນື່ອງຈາກ "ຄຸນສົມບັດໃໝ່ທີ່ດີເລີດ". ພວກເຮົາຍັງໄດ້ເຮັດວຽກຮ່ວມກັບລາວເພື່ອແກ້ໄຂບັນຫາ valgrind (ເຊິ່ງມັນປາກົດວ່າເກີດຈາກ backdoor ທີ່ລາວໄດ້ເພີ່ມ). ພວກເຮົາຕ້ອງແຂ່ງຂັນໃນຄືນທີ່ຜ່ານມາເພື່ອແກ້ໄຂບັນຫາຫຼັງຈາກການຢຸດການຫ້າມໂດຍບໍ່ໄດ້ຕັ້ງໃຈ. ລາວໄດ້ເປັນສ່ວນໜຶ່ງຂອງໂຄງການ xz ເປັນເວລາ 2 ປີ, ໂດຍໄດ້ເພີ່ມໄຟລ໌ທົດສອບໄບນາຣີທຸກປະເພດ, ແລະ ເພື່ອຄວາມຊື່ສັດກັບລະດັບຄວາມຊັບຊ້ອນນີ້ ຂ້ອຍຈະສົງໄສ xz ລຸ້ນເກົ່າກວ່າຈົນກວ່າຈະພິສູດໄດ້ວ່າເປັນຢ່າງອື່ນ."
ເຈຍ ທານ ໄດ້ໃຊ້ມາດຕະການເພື່ອປ້ອງກັນການຕິດຕາມ: ເບິ່ງຄືວ່າໄດ້ໃຊ້ VPN (vpn.singapore.witopia.net) ເພື່ອເຊື່ອມຕໍ່ - ເຊິ່ງກໍ່ບໍ່ເປັນຫຍັງ. ແລະການປ່ຽນແປງຫຼາຍຢ່າງເບິ່ງຄືວ່າໄດ້ຮັບການສະໜັບສະໜູນຈາກອີເມວຊົ່ວຄາວທີ່ໃຊ້ໄດ້ຄັ້ງດຽວ (ຈາກ ProtonMail ໃນກໍລະນີນີ້) ທີ່ຮຽກຮ້ອງໃຫ້ລວມການປ່ຽນແປງເຂົ້າກັນ.
ນັກສະແດງອາດຈະຕັ້ງໃຈທີ່ຈະເຂົ້າໄປເລິກກວ່າເກົ່າ, ຈົນເຖິງ kernel Linux, ໃນຖານະຜູ້ປະກອບສ່ວນເຂົ້າໃນ ຝັງ xy ໂຄງການ. ການວິເຄາະໃນເບື້ອງຕົ້ນບໍ່ພົບຫຼັກຖານຂອງການຫຼຸລູກ, ມາຮອດມື້ນີ້.
ໝາຍເຫດ: ອີກຢ່າງໜຶ່ງ ຜູ້ປະກອບສ່ວນ XZ ທີ່ມີໂປຣໄຟລ໌ຕ່ຳ “Hans Jansen“ (ຜູ້ໃຊ້ GitHub “hansjans162”) ແມ່ນ ພາຍໃຕ້ການພິຈາລະນາບັນຊີຂອງມັນຢູ່ debian ຕອນນີ້ແມ່ນ ຖືກບລັອກລາວໄດ້ອັບເດດ Debian Games ຫຼາຍຢ່າງເພື່ອປິດບັງອັນທີ່ລາວຕ້ອງການໃນ debian/xz-utils, ການອັບເດດເປັນ upstream 5.6.1 ເພື່ອເລັ່ງການແຈກຢາຍ backdoor ໃຫ້. ເດບຽນ/ບໍ່ໝັ້ນຄົງ.
ສິ່ງທີ່ພວກເຮົາສາມາດເວົ້າໄດ້ໃນຕອນນີ້ແມ່ນວ່ານີ້ແມ່ນ APT (ຍັງບໍ່ສາມາດລະບຸຕົວຕົນໄດ້) ທີ່ໃຊ້ບັນຊີທີ່ແຕກຕ່າງກັນ, ເຮັດວຽກຢ່າງໜ້ອຍສອງປີໃນແຄມເປນນີ້, ແລະເຮັດວຽກຢ່າງອົດທົນເພື່ອຝັງ RCE ໃນ SSH.
ມາຮອດປະຈຸບັນ, ຕົວຕົນທີ່ຢູ່ເບື້ອງຫຼັງ “Jia Tan” ຍັງບໍ່ທັນໄດ້ຮັບການຢືນຢັນເທື່ອ. ບໍ່ມີການຢືນຢັນທີ່ໜ້າເຊື່ອຖືຕໍ່ບຸກຄົນ, ອົງການຈັດຕັ້ງ ຫຼື ຜູ້ກະທຳຂອງລັດໃດໜຶ່ງທີ່ໄດ້ຮັບການຢືນຢັນຕໍ່ສາທາລະນະ, ເຊິ່ງເປັນການຢືນຢັນໃຫ້ເຫັນວ່າລະບຽບວິໄນການດຳເນີນງານຂອງບຸກຄົນດັ່ງກ່າວມີປະສິດທິພາບແນວໃດ.
ການໂຈມຕີທາງຫຼັງຂອງ XZ ສາມາດປ້ອງກັນໄດ້ບໍ?
ຂ້ອນຂ້າງຍາກ.
ທຳອິດ, ສ່ວນໜຶ່ງຂອງ backdoor ທີ່ຖືກສັກເຂົ້າມານັ້ນໄດ້ເຂົ້າໄປໃນໄຟລ໌ທົດສອບທີ່ຖືກບີບອັດທີ່ບໍ່ໄດ້ຖືກນຳໃຊ້ໂດຍການທົດສອບ. ເມື່ອຫວນຄືນໄປເບິ່ງ, ສິ່ງນັ້ນອາດຈະເຮັດໃຫ້ເກີດສັນຍານເຕືອນ (ທີ່ມີສຽງດັງ), ແຕ່ໃຜສົນໃຈທີ່ຈະກວດສອບວ່າໄຟລ໌ທົດສອບທັງໝົດຖືກນຳໃຊ້ໂດຍການທົດສອບຕົວຈິງໃນໂລກແຫ່ງຄວາມເປັນຈິງ? ອັນທີສອງ, ສ່ວນໜຶ່ງຂອງ backdoor ທີ່ຖືກສັກເຂົ້າມານັ້ນໄດ້ເຂົ້າໄປໃນໄຟລ໌ macro ເຂົ້າໄປໃນ tarballs ຂອງການປ່ອຍ, ແລະມັນຍາກທີ່ຈະກວດສອບດ້ວຍຕົນເອງສຳລັບຄວາມແຕກຕ່າງກັບ tarballs ທີ່ຄາດໄວ້. ລະບົບອັດຕະໂນມັດຍັງມີຄວາມສັບສົນ, ຍ້ອນວ່າຜົນໄດ້ຮັບທີ່ຄາດຫວັງຈາກການສ້າງເອງ (ສຳລັບທຸກຄົນທີ່ຮູ້ວ່າ automake/autoconf ເຮັດວຽກແນວໃດ) ແມ່ນຍາກທີ່ຈະສ້າງແບບຈຳລອງສຳລັບການວິເຄາະວ່າ tarball ທີ່ແທ້ຈິງກົງກັບຄວາມຄາດຫວັງຫຼືບໍ່. ບາງຄົນໄດ້ວາງມັນໄວ້ as "ການບໍ່ກົງກັນຂອງ tarballs ຈາກຕົ້ນໄມ້ git ແມ່ນລັກສະນະ, ບໍ່ແມ່ນຂໍ້ຜິດພາດ"ຕົ້ນກຳເນີດຂອງ tarballs ແບບໄບນາຣີຈາກລະຫັດແຫຼ່ງຂອງມັນແມ່ນບັນຫາທີ່ຍັງບໍ່ໄດ້ຮັບການແກ້ໄຂ.
ຊື່ສຽງຂອງຜູ້ໃຊ້ບໍ? ດີ, ບັນຊີ JiaTan75 GitHub ບໍ່ໄດ້ເຮັດສິ່ງທີ່ບໍ່ດີຕາມອະດີດ commits. ມັນໄດ້ຖືກໂຈະຫຼັງຈາກຫຼັກຖານສະສົມແລ້ວ, ແຕ່ຈົນຮອດວັນທີ 29 ມີນາ ນັ້ນແມ່ນຜູ້ໃຊ້ປົກກະຕິທີ່ດຳເນີນທຸລະກິດປົກກະຕິ. ດີ, ບໍ່ປົກກະຕິປານໃດ. ຕໍ່ມາ commits (ນີ້, ນີ້, ນີ້, ແລະ ນີ້ ເຊິ່ງໄດ້ປັບປຸງລະຫັດ exploit) ໄດ້ພະຍາຍາມແກ້ໄຂຂໍ້ຜິດພາດ valgrind ແລະ ການຂັດຂ້ອງໃນບາງການຕັ້ງຄ່າ, ເນື່ອງຈາກຄວາມແຕກຕ່າງກັບຮູບແບບ stack ທີ່ຄາດຫວັງໂດຍ backdoor. Commit ການທົບທວນຄືນສາມາດກວດພົບສິ່ງນີ້ໄດ້, ແຕ່ໃຜມີຄວາມອົດທົນໃນການວິເຄາະການປ່ຽນແປງໃນໄຟລ໌ທົດສອບໄບນາຣີ ຫຼື ແຮງຈູງໃຈທີ່ແທ້ຈິງສຳລັບການປ່ຽນແປງຄຸນລັກສະນະ GCC ໃນລະຫັດແຫຼ່ງ C?
ຄວນແຈ້ງເຕືອນເມື່ອ SSH ເກີດຂຶ້ນບໍ? login ໃຊ້ເວລາ 800 ms ແທນທີ່ຈະເປັນ 300 ms ບໍ? ອາດຈະມີແຕ່ຄົນທີ່ມີສະຕິປັນຍາສູງເທົ່ານັ້ນທີ່ຈະຮັບຮູ້. ຊີເຊໂຣ ກ່າວວ່າ, "ຄວາມຫຸນຫງາຍເປັນຂອງໄວໜຸ່ມ; ຄວາມຮອບຄອບເປັນຂອງໄວຊະລາ."
ໂຄງສ້າງພື້ນຖານ ifunc ໄດ້ຖືກເພີ່ມເຂົ້າໃນເດືອນມິຖຸນາ 2023 ໂດຍ “Hans Jansen” ແລະ “Jia Tan”. ນີ້ແມ່ນຄັ້ງທຳອິດ commit ກຳລັງເພີ່ມການຮອງຮັບ ifunc ໃສ່ crc64_fast.c (ຕໍ່ມາໃຊ້ເພື່ອສັກ backdoor). ຫຼາຍເດືອນກ່ອນທີ່ຈະສັກ backdoor binaries ໃນໄຟລ໌ທົດສອບ!
ໝາຍເຫດ: ຜູ້ຂຽນ ແລະ commitມີຄວາມແຕກຕ່າງຢູ່ທີ່ນີ້, ແຕ່ນີ້ແມ່ນເລື່ອງປົກກະຕິ: Lasse Collin ເປັນຜູ້ຮັກສາໂຄງການ, ແລະລາວໄດ້ລວມການປ່ຽນແປງຕ່າງໆເຂົ້າກັນ. ລາວຍັງຂອບໃຈ “Hans Jansen” …
ບໍ່ມີໃຜຍົກຄວາມກັງວົນກ່ອນໂພສຂອງ Andres Freund ແລະ CVE ທີ່ສ້າງຂຶ້ນໂດຍ RedHat. ຖ້າທ່ານເຫັນເຄື່ອງມືຫຼາຍອັນທີ່ຈະຈັບສິ່ງນີ້ໄດ້, ພວກມັນກວດພົບອົງປະກອບທີ່ໄດ້ຮັບຜົນກະທົບດຽວນີ້, ex post facto.
ບາງທີການປ້ອງກັນທີ່ດີທີ່ສຸດອາດຈະມາຈາກລັກສະນະຂອງການແຈກຢາຍ Linux, ແລະວິທີທີ່ລຸ້ນທີ່ບໍ່ໝັ້ນຄົງ, ລຸ້ນ bleeding edge ຈະຜ່ານໄປຫາການແຈກຢາຍທີ່ໝັ້ນຄົງຢູ່ທາງລຸ່ມຫຼັງຈາກຂະບວນການທີ່ວ່ອງໄວ.
ບົດຮຽນທີ່ໄດ້ຮຽນຮູ້ຈາກການໂຈມຕີ XZ bBackdoor
ພວກເຮົາໄດ້ສັງເກດເຫັນວ່າມັນຍາກທີ່ຈະກວດພົບ intentionally ປະຕູຫຼັງ. ປະຕູຫຼັງຄວນຖືກພິຈາລະນາວ່າເປັນໄພຂົ່ມຂູ່ພາຍໃນ, ຍ້ອນວ່າພວກມັນຖືກຕິດຕັ້ງໂດຍພະນັກງານພາຍໃນ ຫຼື ຜ່ານບັນຊີພາຍໃນທີ່ຖືກໂຈມຕີ. ແລະ ຄົນເຫຼົ່ານັ້ນສ່ວນຫຼາຍແມ່ນໄດ້ຮັບຄວາມໄວ້ວາງໃຈ. ແລະ ເມື່ອປະຕູຫຼັງຖືກຝັງຢູ່ໃນສິ່ງປະດິດທີ່ແຈກຢາຍ, ມັນເຮັດໃຫ້ມັນຍາກທີ່ຈະກວດພົບ.
ນັກຂຽນບາງຄົນເຊັ່ນ Kevin Beaumont ຊີ້ໃຫ້ເຫັນ ລະບົບ, ເຊິ່ງເປີດພື້ນທີ່ໂຈມຕີຂະໜາດໃຫຍ່ຂອງການບໍລິການພາກສ່ວນທີສາມໄປສູ່ປະຕູຫຼັງ. ນີ້ແມ່ນສິ່ງທີ່ຜູ້ກະທຳທີ່ບໍ່ດີໄດ້ໃຊ້ໃນທາງທີ່ຜິດຢູ່ທີ່ນີ້. Systemd ມີສາຍຕາຫຼາຍ, ແຕ່ XZ ເປັນຫ້ອງສະໝຸດທີ່ບໍ່ຄ່ອຍຈະແຈ້ງຂຶ້ນໄປ. “ເມື່ອຕົ້ນນ້ຳມີມົນທິນ, ທຸກຄົນດື່ມນ້ຳທີ່ເປັນພິດລົງໄປທາງລຸ່ມ”.
ການຮ້ອງຂໍການປ່ຽນແປງທີ່ບໍ່ກ່ຽວຂ້ອງໃນລະບົບສຳລັບ ກຳລັງໂຫຼດຫ້ອງສະໝຸດການບີບອັດແບບໄດນາມິກ, ເຊິ່ງຈະລຶບ backdoor, ໄດ້ຖືກລວມເຂົ້າກັບລະບົບແລ້ວແຕ່ຍັງບໍ່ທັນໄດ້ສົ່ງມອບເທື່ອ. ການເພິ່ງພາອາໄສເພີ່ມເຕີມທີ່ນຳສະເໜີໂດຍ libsystemd ອາດເປັນແຫຼ່ງທີ່ມາຂອງຊ່ອງໂຫວ່, ແລະມື້ວານນີ້ ຄຳຮ້ອງຂໍນີ້ຖືກເປີດແລ້ວ.
A ຄວາມຄິດເຫັນ ໃນ “xz: ປິດການໃຊ້ງານ ifunc ເພື່ອແກ້ໄຂບັນຫາ” commit ໄດ້ໃຫ້ຄວາມເຂົ້າໃຈຢ່າງຈະແຈ້ງກ່ຽວກັບບ່ອນທີ່ຄວນສຸມໃສ່ຖ້າພວກເຮົາຕ້ອງການປ້ອງກັນກິດຈະກຳດັ່ງກ່າວ (ເນັ້ນໜັກແມ່ນຂອງຂ້ອຍ):
“ບົດຮຽນທີ່ພວກເຮົາຄວນຮຽນຮູ້ໃນຖານະຊຸມຊົນແມ່ນເພື່ອຮັບປະກັນຄວາມປອດໄພຫຼາຍຂຶ້ນ” software supply chain security ໂດຍລວມແລ້ວ, ການກວດສອບລະບົບການສ້າງນອກເໜືອໄປຈາກລະຫັດແຫຼ່ງ. ເຊັ່ນດຽວກັບການລະເມີດ SolarWinds ບ່ອນທີ່ຜູ້ໂຈມຕີໄດ້ດັດແປງການອັບເດດຊອບແວສຳລັບການສະເໜີຊອບແວຕິດຕາມກວດກາແບບປິດຂອງ SolarWinds.”
FAQ
ປະຕູຫຼັງຂອງ XZ ຍັງມີຄວາມສ່ຽງຢູ່ບໍໃນທຸກມື້ນີ້?
ສ່ວນຫຼາຍຖືກກັກຂັງໄວ້, ແຕ່ບໍ່ໄດ້ຫາຍໄປໝົດ. ໃນເດືອນສິງຫາ 2025, ນັກຄົ້ນຄວ້າພົບວ່າປະຕູຫຼັງຍັງມີຢູ່ໃນຮູບພາບ Debian Docker Hub ຫຼາຍຮູບ, ເຊິ່ງ Debian ຖືວ່າມັນເປັນສິ່ງປະດິດທາງປະຫວັດສາດທີ່ບໍ່ມີການເຄື່ອນໄຫວ. ທີມງານຄວນກວດສອບວ່າພວກເຂົາບໍ່ໄດ້ສ້າງຮູບພາບພື້ນຖານທີ່ລ້າສະໄໝ, ບໍ່ໄດ້ຮັບການແກ້ໄຂແທນທີ່ຈະສົມມຸດວ່າການແກ້ໄຂປີ 2024 ໄດ້ປິດປະຕູຢ່າງສິ້ນເຊີງ.
