SSH-ийн арын хаалга
Хорлонтой эсвэл эвдэрсэн засвар үйлчилгээ үзүүлэгч нь нэртэй номын санд хортой зан үйл оруулсан. liblzma, xz шахалтын хэрэгслүүд болон сангуудын нэг хэсэг бөгөөд SSH-д арын хаалга үүсгэдэг. Энэ нь дэвшилтэт програм хангамжийн хангамжийн сүлжээний халдлага бөгөөд номын санг арын хаалганд зориулж санаатайгаар өөрчилсөн бөгөөд халдлагын ачааллыг хянагчдаас нуухын тулд будлиантай болон нууцлагдмал аргуудыг ашигласан.
Үүнийг саяхан (3-р сарын 29-ний өдөр) илрүүлж, задруулсан бөгөөд халдлагыг зохицуулах ажил үргэлжилж байна. Гэсэн хэдий ч энэ нь зөвхөн хязгаарлагдмал орчны (x86_64 архитектурт зориулсан DEB болон RPM багцууд, мөн GCC-тэй хамт бүтээгдсэн) өмнөх хувилбаруудад нөлөөлдөг бололтой тул хурдан хязгаарлагдсан. Ямартай ч, CVE өгөгдсөн CVSS суурь оноо 10-ын 10 нь хамгийн чухал кибер аюулгүй байдлын эмзэг байдалд зориулагдсан. Хэрэв энэ нь тогтвортой тархалтад орвол нөлөөлөл нь асар их байх болно.
Халдлагын техникийн шинжилгээ, үүнд дараахь зүйлс орно xz арын хаалганы талаар дэлгэрэнгүй тайлбарласан, өөр газар дүн шинжилгээ хийсэн. Энэ нийтлэлд халдлагын хугацаа, хэрхэн илрүүлж болох, уг явдлыг өнөөг хүртэл хэрхэн зохицуулсан, мөн халдлагаас ямар сургамж авч болох талаар анхаарлаа хандуулах болно.
Арын хаалганы урт сүүл нь анхны засвараас хамаагүй удаан үргэлжилсэн. 2025 оны 8-р сард, CVE-2024-3094-ийг ил болгосноос хойш нэг жил гаруйн дараа Binarly-ийн аюулгүй байдлын судлаачид Docker Hub дээр нийтлэгдсэн Debian Docker-ийн арван хоёр зурганд арын хаалга байсаар байгааг олж мэдсэн бөгөөд Debian-ийн баг тэдгээрийг идэвхтэй эрсдэл биш харин түүхэн хөгжлийн олдвор гэж үзэж, устгахаас татгалзжээ. Тус тусад нь, OpenSSF мөн OpenJS нь XZ-ийн хэрэг явдлын дараахан хамтарсан анхааруулга гаргасан бөгөөд ижил төстэй нийгмийн инженерчлэлийн эзэмшлийн оролдлогууд аль хэдийн JavaScript төслүүдийг чиглүүлсэн байсан бөгөөд энэ нь энд ашигласан засварлагч-итгэмжлэлийн халдлагын загварыг өөр газар дахин ашиглаж байгааг харуулж байна.
XZ арын хаалгыг хэрхэн оруулсан бэ
Тэмдэглэл: git репозитор дотор байна git.tukaani.org. Гэсэн хэдий ч, бас байсан GitHub-д байршуулсан репозитор (одоогоор хаагдсан) GitHub бүртгэл нь Git репозиторт нэгтгэгдсэн өөрчлөлтүүдийг нийтэлж байсан.
Арын хаалганы нэг хэсэг нь зөвхөн 5.6.0 болон 5.6.1 хувилбаруудын тархсан tarballs-д байгаа бололтой, git репозиторт байхгүй бөгөөд ... дээр тулгуурладаг. build-to-host.m4 файл дахь ганц мөр autoconf-ын ашигласан макро файл. Нөгөө хэсэг нь хоёр тест файлд байсан гэж үздэг муу-3-эвдрэлтэй_lzma2.xz болон сайн-том_шахагдсан.lzma
байв commitТед GitHub-ын “Жиа Тан” бүртгэлээр (JiaT75) дахь xz репозитор 2-р сарын 23-нд testfile-уудыг (.lzma болон .xz шахагдсан блокууд гэж таамаглаж байна) нэмж оруулсан нь гэм хоргүй өөрчлөлт байв. Сонирхолтой нь, test файлуудыг tests ашиглаагүй! .m4 файл дахь мөр нь тохиргооны төгсгөлд зарим нөхцөл таарвал гүйцэтгэх бүдгэрсэн скриптийг (tarball-д багтсан) оруулдаг. Энэ нь Makefile-г дараах байдлаар өөрчилдөг. liblzma deobfuscation дууссаны дараа .xz файлаас өгөгдөл гаргаж авдаг кодыг агуулсан номын сан энэ скриптэд, тохиргооны төгсгөлд дуудагддаг. Энэ нь бүтээх процессыг код оруулахаар өөрчлөх эсэхийг шийддэг: зөвхөн GCC болон GCC холбогч дор, Debian эсвэл rpm дор, зөвхөн x86_64 Linux-д. Тохирох үед оруулсан код нь хоёрыг орлуулснаар гүйцэтгэлийг тасалдуулдаг ifunc тодорхойлогчдыг ашигладаг тул тодорхой дуудлагууд солигддог. Энэ нь тэмдэгтийн хүснэгтүүдийг санах ойд задлан шинжлэхэд хүргэдэг (энэ нь цаг хугацаа шаарддаг бөгөөд дараа нь тайлбарласны дагуу илрүүлэхэд хүргэсэн).
Дараа нь бүх зүйл сонирхолтой болж эхэлдэг: Арын хаалга нь динамик холбогч руу аудит дэгээ суулгаж, RSA_public_decrypt функцийн тэмдэг ирэхийг хүлээдэг бөгөөд энэ тэмдэг нь арын хаалганы код руу чиглэсэн цэг рүү чиглүүлэгддэг бөгөөд энэ нь эргээд буцааж дууддаг. libcrypto, магадгүй ердийн баталгаажуулалтыг гүйцэтгэхийн тулд. Хэрэв ажиллаж байгаа програм нь процессын нэртэй бол ашигтай ачаалал идэвхждэг /usr/sbin/sshdSSH серверүүд бай болсон нь тодорхой байсан. Уламжлал ёсоор, sshd OpenSSH гэх мэт серверүүд холбогдоогүй байсан liblzma, гэхдээ sshd нь ихэвчлэн нөхөөстэй sshd ажиллаж байх үед бусад үйлчилгээнүүд ажиллаж эхлэхийн тулд systemd-notify-г дэмжих. Дараа нь liblzma шууд бусаар ачаалагддаг системд, тойргийг хааж байна.
Арын хаалгыг хараахан бүрэн шинжлээгүй байгаа ч гэсэн тийм юм шиг санагдаж байна алсаас команд гүйцэтгэхийг зөвшөөрөх (RCE) sshd дэмоны эрхүүдтэй, урьдчилсан баталгаажуулалтын нөхцөлд ажиллаж байна. Алсын гэрчилгээнээс авсан мэдээлэл нь арын хаалгаар таарсан үед ChaCha20-ээр тайлагдаж, амжилттай тайлагдах үед дамжуулагдана. систем()Тиймээс энэ нь үндсэндээ хаалттай RCE бөгөөд зүгээр л нийтийн түлхүүрийг тойрч гарахаас хамаагүй муу юм.
Хожим нь гарсан 5.6.1 хувилбарт ул мөрийг нуух нэмэлт оролдлогууд гарч ирсэн бөгөөд энэ нь тэмдэгтийн нэрсийг улам бүр будлиантай болгож, харагдсан алдааг засахыг оролдсон байна. сунгах механизм Арын хаалган дээр нэмэх тодорхой гарын үсэг байгаа эсэхийг шалгах нэмэлт туршилтын файлуудыг мөн байрлуулсан.
Энэхүү нэлээд боловсронгуй халдлага нь тогтвортой Линукс дистрибьютерүүд гарч иртэл анзаарагдахгүй өнгөрч магадгүй юм. Аз болоход зарим хүмүүс яагаад хэвийн бус зүйлс болж байгааг шалгах дуртай байдаг.
XZ арын хаалганы халдлагын нээлт
Хортой зан авирыг олон удаа тохиолдлоор эсвэл санамсаргүйгээр илрүүлдэг. Сайн жишээ бол ... хэрэглээнээс гарсан тухай анхааруулга ("Сэрэмжлүүлгийг хэн тоодог вэ?") нь ... гэсэн нээлтэд хүргэсэн үйл явдлын урсгалын халдлага 2018 оны 10-р сард. Өөр нэг нь анхааруулсан хэрэглэгч юм Codecov 2021 оны 4-р сард тэдний bash байршуулагч скрипт нь шалгах нийлбэрийг даваагүй гэж мэдэгдсэн ("Хэн шалгах нийлбэрээр эд өлгийн зүйлсийн бүрэн бүтэн байдлыг баталгаажуулдаг вэ?") Ssh-тэй холбоотой гажиг ба хачин шинж тэмдгүүд logins (loginмаш их CPU зарцуулж, хугацаа нь нэмэгдсэн, valgrind алдаанууд) нь сониуч занг төрүүлсэн. Андрес Фрейнд, сонор сэрэмжтэй PostgreSQL хөгжүүлэгч боловч аюулгүй байдлын шинжээч биш (түүний хэлсэнчлэн)). Debian Sid дээр OpenSSH-тэй хэсэг судалгаа хийсний дараа тэрээр хариу өгөх хугацааны асуудал нь номын сангаас хамааралтай гэж дүгнэжээ. liblzma, xz-utils шахалтын сан. Учир нь: “дээд урсгалын xz репозитор болон xz tarballs нь арын хаалгаар хаагдсан байна"Энэ оношлогоо маш нарийвчлалтай байсан! 2024 оны 3-р сарын 29-нд Андрес Openwall дээр анхны дүн шинжилгээгээ нийтэлсэн: “дээд урсгал xz/liblzma дахь арын хаалга нь ssh серверийн эвдрэлд хүргэж байна"Баримт: XZ Utils 5.6.0 болон 5.6.1 tarballs нь арын хаалгатай. Эдгээр tarballs-ийг дээр дурдсан Жиа Тан бүртгэл үүсгэж, гарын үсэг зурсан. He Мастодон дээр нийтлэгдсэн тэр өдрийн сүүлээр уг нээлт санамсаргүй бөгөөд олон давхцал шаардсан гэдгийг хүлээн зөвшөөрсөн. Бусад хэрэглэгчдийн сэтгэгдлийг унших нь зүйтэй. GitHub хэрэглэгч thesamesam (өөрөөр хэлбэл Сэм Жэймс) сайхан Gist нийтэлсэн xz-utils арын хаалганы талаар байнга асуудаг асуултууд халдлагыг нэгтгэн дүгнэсэн, илүү олон зүйлтэй холбосон газар гүнзгий дүн шинжилгээ халдлагын ачааны. Эдгээр шинжилгээнүүд нь техникийн хувьд ашигтай байсан бөгөөд бидэнд тарилгыг илүү сайн ойлгоход тусалсан бөгөөд энэ нь маш нарийн боловсруулагдсан байв:- xz/liblzma: Bash үе шатны обфускацийн тайлбарТарилгын скриптээр деобфускацийн талаар дөрвөн "үе шаттай" хийсэн сайхан дүн шинжилгээ.
- Филиппо Валсордагийн блюскийн утас RSA_public_decrypt дахь арын хаалганы өөрийнх нь шинжилгээ нь түүний мөн чанарыг харуулж байна: RCE, auth bypass биш, gated (зохиогчийн хувийн түлхүүрийг хүлээн авдаг бөгөөд хэрэв үгүй бол хэвийн байдалд буцаана) / төлбөр төлөх боломжгүй. Зохиогч илрүүлэхээс зайлсхийхийн тулд нууцлахыг зорьсон!
- @smx-smx-ийн XZ Backdoor шинжилгээ (WIP) – Арын хаалганы нэмэлт дүн шинжилгээ (Би бараг эхэндээ төөрөлдсөн 😀)
- xz арын хаалганы баримтжуулалтын вики, 5.6.1 тарилгын скриптийн өөр нэг шинжилгээ.
Энэ явдлыг хэрхэн зохицуулсан бэ
Андреас Фройнд өөрийн үгээр болгоомжилсон тул мэдэгдэлдээ:"Дээд урсгалын илэрхий оролцоог харгалзан үзвэл би дээд урсгалын алдааны талаар мэдээлээгүй байна. Анхандаа үүнийг debian-тай холбоотой асуудал гэж бодож байсан тул security@...ian.org хаягаар урьдчилсан тайлан илгээсэн. Үүний дараа би энэ асуудлыг distros@ хаягаар мэдээлсэн." CISА-д түгээлтээс мэдэгдсэн.
Хэн халдлагад өртөж байна вэ?
GitHub JiaT75 бүртгэл эвдэрсэн (GitHub саяхан 2FA-г шаардсан гэдгийг санаарай) эсвэл бүртгэлтэй холбоотой бодит хэрэглэгч харанхуй тал руу орсон. Гэхдээ халдлагын техникийн нарийн төвөгтэй байдлаас шалтгаалан магадгүй муж улсын дэмжлэгтэй, дэвшилтэт байнгын аюул заналхийлэл (APT) гэж бодох үндэслэл бий. Кибер аюулгүй байдлын агентлагууд болон хууль сахиулах байгууллагуудын цаашдын мөрдөн байцаалт үүнийг харуулах болно ... Энэ оруулга Жиа Тангийн тухай YCombinator хакерын мэдээнд "хэн" болон түүний үйл ажиллагааны талаар бага зэрэг тодруулга оруулсан. Санал болгож байна! Энэ нь муу санаатнууд нийгмийн инженерчлэлийг ашиглан бусад хэрэглэгчдийг хэрхэн хуурахыг оролддог талаар маш их мэдээлэл өгдөг."Маш ядаргаатай юм - арын хаалганы зохиогч нь Fedora 40 & 41 дээр xz 5.6.x-ийг нэмэхийн тулд хэдэн долоо хоногийн турш надтай (rwmj) харилцаж байсан, учир нь энэ нь "гайхалтай шинэ боломжууд" юм. Бид түүнтэй valgrind-ийн асуудлыг засахын тулд хамтран ажилласан (одоо түүний нэмсэн арын хаалганаас үүдэлтэй болох нь тогтоогдсон). Хоригийг санамсаргүйгээр зөрчсөний дараа бид өнгөрсөн шөнө асуудлыг засахын тулд уралдах хэрэгтэй болсон. Тэрээр 2 жилийн турш xz төслийн нэг хэсэг болж, бүх төрлийн хоёртын тест файлуудыг нэмж байгаа бөгөөд үнэнийг хэлэхэд энэ түвшний нарийн төвөгтэй байдалд би өөрөөр батлагдах хүртэл xz-ийн хуучин хувилбаруудыг ч сэжиглэх болно."
Жиа Тан мөрдөгдөхөөс урьдчилан сэргийлэх арга хэмжээ авсан: Холбогдохын тулд VPN (vpn.singapore.witopia.net) ашигласан бололтой - энэ нь өөрөө зүгээр юм. Мөн олон өөрчлөлтүүд нь өөрчлөлтийг нэгтгэхийг шаардсан түр зуурын, нэг удаагийн хэрэглээний имэйлүүдээр (энэ тохиолдолд ProtonMail-ээс) баталгаажсан бололтой.
Жүжигчин хувь нэмэр оруулагчийн хувьд Linux цөм хүртэл бүр гүнзгийрэхийг хүсч магадгүй юм. xy-суулгагдсан төсөл. Өнөөдрийн байдлаар анхны шинжилгээгээр зулбалт илрээгүй байна.
Тэмдэглэл: өөр нэг XZ-ийн нэр хүндгүй хувь нэмэр оруулагч “Ханс Янсен” (GitHub хэрэглэгч “hansjans162”) нь хяналт дорТүүний debian дээрх бүртгэл одоо байна блоклосонТэрээр debian/xz-utils дээр хүссэн хувилбараа нуухын тулд Debian Games дээр олон шинэчлэлт хийсэн бөгөөд арын хаалгыг тараахыг яаравчлуулахын тулд дээд урсгалын 5.6.1 хувилбарт шинэчлэлт хийсэн. debian/тогтворгүй.
Одоогоор бидний хэлж чадах зүйл бол энэ бол өөр өөр бүртгэл ашигладаг, энэ кампанит ажилд дор хаяж хоёр жил ажилласан, SSH дээр RCE суулгахын тулд тэвчээртэй ажиллаж байгаа (одоогоор тодорхойгүй) APT юм.
Энэ бичвэрийг бичиж байх үед “Жиа Тан”-ы ард байгаа хэн болох нь батлагдаагүй хэвээр байна. Тодорхой хувь хүн, байгууллага эсвэл төрийн зүтгэлтний талаарх ямар ч итгэл үнэмшилтэй мэдээлэл олон нийтэд батлагдаагүй байгаа нь уг хүний үйл ажиллагааны сахилга бат хэр үр дүнтэй байсныг баталж байна.
XZ-ийн арын хаалганы халдлагаас урьдчилан сэргийлэх боломжтой байсан уу?
Хэцүү.
Нэгдүгээрт, тарьсан арын хаалганы нэг хэсэг нь туршилтаар ашиглагдаагүй шахсан туршилтын файлууд руу орсон. Эргээд харахад энэ нь зарим (шуугиантай) дохиолол үүсгэж болох ч бодит ертөнцөд бүх туршилтын файлууд бодит туршилтаар ашиглагдаж байгаа эсэхийг хэн шалгах талаар санаа тавьдаг вэ? Хоёрдугаарт, тарьсан арын хаалганы нэг хэсэг нь макро файлуудаар хувилбарын tarballs руу орсон бөгөөд хүлээгдэж буй tarballs-тай ялгааг гараар шалгахад хэцүү байдаг. Автоматжуулалт нь бас төвөгтэй, учир нь угсралтын өөрөөс нь хүлээгдэж буй үр дүн (automake/autoconf хэрхэн ажилладагийг мэддэг хүн бүрийн хувьд) нь жинхэнэ tarball нь хүлээлттэй тохирч байгаа эсэхийг шинжлэхэд загварчлахад хэцүү байдаг. Зарим нь тавьсан as “Git модноос таарахгүй байгаа tarballs нь алдаа биш, харин онцлог шинж чанар юм”Хоёртын tarballs-ийн эх кодоос үүсэл нь шийдэгдээгүй асуудал юм.
Хэрэглэгчийн нэр хүнд үү? За, JiaTan75 GitHub бүртгэл өнгөрсөн үеийнх шигээ луйвар хийдэггүй байсан. commitс. Нотлох баримт цугларсны дараа л түдгэлзүүлсэн боловч 3-р сарын 29 хүртэл хэвийн үйл ажиллагаа явуулдаг байнгын хэрэглэгч байсан. За, тийм ч хэвийн биш. Дараа нь commits (энэ, энэ, энэБолон энэ exploit кодыг тохируулсан) арын хаалгаар хүлээгдэж буй стекийн зохион байгуулалтаас ялгаатай байдлаас болж зарим тохиргоонд valgrind алдаа болон ослыг засахыг оролдсон. Commit Тоймууд үүнийг илрүүлж болох ч хоёртын тест файл дахь өөрчлөлтийг эсвэл C эх кодын GCC шинж чанаруудын өөрчлөлтийн жинхэнэ сэдлийг шинжлэх тэвчээр хэнд байгаа юм бэ?
SSH үед дохиолол дуугарах ёстой юу? login 300 мс-ийн оронд 800 мс авдаг уу? Зөвхөн хэт болгоомжтой хүмүүс л анзаарах байх. Цицерон хэлэхдээ, "Түргэх нь залуу насанд, ухаалаг байдал нь хөгшрөлтөд хамаарна."
IFunc-ийн дэд бүтцийг 2023 оны 6-р сард “Hans Jansen” болон “Jia Tan” нар нэмсэн. Энэ бол анхных нь юм. commit crc64_fast.c файлд ifunc дэмжлэг нэмж байна (хожим нь арын хаалга оруулахад ашигласан). Туршилтын файлуудад арын хаалганы хоёртын файлуудыг оруулахаас хэдэн сарын өмнө!
Тэмдэглэл: Зохиогч болон commitЭнд ялгаа байгаа ч энэ бол хэвийн зүйл: Лассе Коллин бол төслийн засвар үйлчилгээ хариуцсан хүн бөгөөд тэрээр өөрчлөлтүүдийг нэгтгэсэн. Тэр бүр "Ханс Янсен"-д талархал илэрхийлсэн ...
Андрес Фройундийн бичлэг болон RedHat-ийн бүтээсэн CVE-ээс өмнө хэн ч санаа зовоосон асуудал үүсгээгүй. Хэрэв та үүнийг илрүүлэх хэрэгслүүдийн каскадыг харвал тэд нөлөөлөлд өртсөн бүрэлдэхүүн хэсгийг одоо илрүүлдэг. экс пост факто.
Магадгүй хамгийн сайн урьдчилан сэргийлэх арга нь Линуксийн дистрибьютерийн мөн чанар, мөн тогтворгүй, хэт захтай хувилбарууд нь зөвхөн хурдацтай үйл явцын дараа л тогтвортой дистрибьютерүүд рүү шилждэгтэй холбоотой байсан байх.
XZ bBackdoor Attack-аас сурсан сургамжууд
Үүнийг илрүүлэхэд хэр хэцүү болохыг бид тэмдэглэсэн санаатай байна Арын хаалга. Арын хаалгануудыг дотоод ажилтнууд эсвэл алдагдсан дотоод дансуудаар дамжуулан суулгадаг тул дотоод аюул занал гэж үзэх хэрэгтэй. Эдгээр хүмүүст ихэвчлэн итгэдэг. Арын хаалга нь тархсан эд өлгийн зүйлд суулгагдсан үед илрүүлэхэд хэцүү болгодог.
Кевин Бомонт зэрэг зарим зохиолчид зааж өгсөн систем, энэ нь гуравдагч талын үйлчилгээний томоохон халдлагын гадаргууг арын хаалга руу нээж өгдөг. Муу этгээд энд үүнийг буруугаар ашигласан. Systemd нь маш их нүдтэй боловч XZ нь сүлжээний дагуу тодорхойгүй номын сан юм. "Дээд урсгал бохирдсон үед хүн бүр доод урсгалд хортой ус уудаг."
Систем дэх холбоогүй өөрчлөлтийн хүсэлт шахалтын сангуудыг динамикаар ачаалж байна, арын хаалгыг арилгах бөгөөд системд аль хэдийн нэгтгэгдсэн боловч хараахан хүргүүлээгүй байна. libsystemd-ийн нэвтрүүлсэн нэмэлт хамаарлууд нь эмзэг байдлын эх үүсвэр байж болох юм., мөн өчигдөр энэ хүсэлтийг нээсэн.
A сэтгэгдэл "xz: Асуудлыг засахын тулд ifunc-г идэвхгүй болгох" хэсэгт commit Хэрэв бид ийм үйл ажиллагааг зогсоохыг хүсвэл анхаарлаа хаана төвлөрүүлэх талаар тодорхой ойлголт өгсөн (онцлон тэмдэглэх нь минийх):
"Бидний нийгэмлэгийн хувьд сурах ёстой хичээл бол илүү аюулгүй байдлыг хангах явдал юм software supply chain security цогцоор нь, зөвхөн эх кодоос гадна бүтээх системийг аудит хийх. Халдагчид SolarWinds-ийн хаалттай эхийн хяналтын програм хангамжийн санал болгож буй програм хангамжийн шинэчлэлтийг өөрчилсөн SolarWinds-ийн халдлага шиг.
тусламж
XZ-ийн арын хаалга өнөөдөр ч эрсдэлтэй хэвээр байна уу?
Ихэнх нь агуулагдсан боловч бүрэн алга болоогүй. 2025 оны 8-р сард судлаачид Debian-ы идэвхгүй түүхэн эд өлгийн зүйлс гэж үздэг хэд хэдэн Debian Docker Hub зурагт арын хаалга байсаар байгааг олж мэджээ. Багууд 2024 оны засвар хаалгыг бүрэн хаасан гэж үзэхийн оронд хуучирсан, нөхөөсгүй үндсэн зургууд дээр бүтээгээгүй гэдгээ баталгаажуулах хэрэгтэй.
