ការចូលមើល SSH ខាងក្រោយ
អ្នកថែទាំដ៏អាក្រក់ ឬមានការសម្របសម្រួលបានបញ្ចូលឥរិយាបថព្យាបាទនៅក្នុងបណ្ណាល័យដែលមានឈ្មោះថា លីបលហ្សាម៉ាដែលជាផ្នែកមួយនៃឧបករណ៍បង្ហាប់ និងបណ្ណាល័យ xz ដែលបណ្តាលឱ្យមាន backdoor នៅក្នុង SSH។ នេះគឺជាការវាយប្រហារខ្សែសង្វាក់ផ្គត់ផ្គង់កម្មវិធីកម្រិតខ្ពស់ ដោយសារបណ្ណាល័យត្រូវបានកែប្រែដោយចេតនាសម្រាប់ backdoor ជាមួយនឹងបច្ចេកទេសបិទបាំង និងលួចលាក់សម្រាប់លាក់ payload វាយប្រហារពីអ្នកពិនិត្យ។
វាត្រូវបានគេរកឃើញ និងបង្ហាញថ្មីៗនេះ (នៅថ្ងៃទី 29 ខែមីនា) ហើយការដោះស្រាយការវាយប្រហារកំពុងបន្ត។ ទោះជាយ៉ាងណាក៏ដោយ វាត្រូវបានទប់ស្កាត់យ៉ាងឆាប់រហ័ស ព្រោះវាហាក់ដូចជាប៉ះពាល់តែកំណែមុនការចេញផ្សាយនៃសំណុំបរិស្ថានមានកំណត់ (កញ្ចប់ DEB និង RPM សម្រាប់ស្ថាបត្យកម្ម x86_64 និងបង្កើតឡើងជាមួយ GCC)។ យ៉ាងណាក៏ដោយ CVE ត្រូវបានផ្តល់ឱ្យ ពិន្ទុមូលដ្ឋាន CVSS នៃ 10 ដែលត្រូវបានរក្សាទុកសម្រាប់ភាពងាយរងគ្រោះខាងសន្តិសុខតាមអ៊ីនធឺណិតដ៏សំខាន់បំផុត។ ប្រសិនបើវាចូលទៅក្នុងការចែកចាយដែលមានស្ថេរភាព ផលប៉ះពាល់នឹងមានច្រើនលើសលប់។
ការវិភាគបច្ចេកទេសនៃការវាយប្រហារ រួមទាំង ការពន្យល់លម្អិតអំពីទ្វារខាងក្រោយ xzត្រូវបានវិភាគនៅកន្លែងផ្សេង។ អត្ថបទនេះនឹងផ្តោតលើពេលវេលានៃការវាយប្រហារ របៀបដែលវាអាចត្រូវបានរកឃើញ របៀបដែលឧប្បត្តិហេតុនេះត្រូវបានដោះស្រាយរហូតមកដល់បច្ចុប្បន្ន និងមេរៀនអ្វីខ្លះដែលអាចទាញយកបានពីការវាយប្រហារនេះ។
កន្ទុយវែងរបស់ Backdoor បានបន្តលើសពីបំណះដំបូង។ នៅក្នុងខែសីហា ឆ្នាំ២០២៥ ជាងមួយឆ្នាំបន្ទាប់ពី CVE-2024-3094 ត្រូវបានបង្ហាញ ក្រុមអ្នកស្រាវជ្រាវសន្តិសុខនៅ Binarly បានរកឃើញថា Backdoor នៅតែមានវត្តមាននៅក្នុងរូបភាព Debian Docker រាប់សិបដែលបានបោះពុម្ពផ្សាយនៅលើ Docker Hub ដោយក្រុមរបស់ Debian បានបដិសេធមិនលុបវាចេញទេ ដោយចាត់ទុកវាជាវត្ថុបុរាណនៃការអភិវឌ្ឍន៍ប្រវត្តិសាស្ត្រជាជាងហានិភ័យសកម្ម។ ដោយឡែកពីគ្នា OpenSSF ហើយ OpenJS បានចេញការព្រមានរួមគ្នាមួយភ្លាមៗបន្ទាប់ពីឧប្បត្តិហេតុ XZ ថាការប៉ុនប៉ងដណ្តើមយកវិស្វកម្មសង្គមស្រដៀងគ្នានេះបានកំណត់គោលដៅគម្រោង JavaScript រួចហើយ ដែលបង្ហាញថាគំរូវាយប្រហារ maintainer-trust ដែលប្រើនៅទីនេះកំពុងត្រូវបានប្រើឡើងវិញនៅកន្លែងផ្សេង។
របៀបដែលទ្វារក្រោយ XZ ត្រូវបានចាក់ចូល
ចំណាំ៖ ឃ្លាំង git ស្ថិតនៅក្នុង git.tukaani.org។ ទោះជាយ៉ាងណា, ក៏មានមួយ ឃ្លាំងផ្ទុកដែលបានបង្ហោះដោយ GitHub (បច្ចុប្បន្នត្រូវបានរារាំង) ជាកន្លែងដែលគណនី GitHub កំពុងបង្ហោះការផ្លាស់ប្តូរ ដែលក្រោយមកត្រូវបានបញ្ចូលទៅក្នុងឃ្លាំង Git។
ផ្នែកមួយនៃ Backdoor ហាក់ដូចជាមានតែនៅក្នុង tarballs ដែលបានចែកចាយសម្រាប់កំណែ 5.6.0 និង 5.6.1 មិនមែននៅក្នុងឃ្លាំង git ទេ ហើយពឹងផ្អែកលើ បន្ទាត់តែមួយនៅក្នុង build-to-host.m4 ឯកសារម៉ាក្រូដែលប្រើដោយ autoconf។ ផ្នែកមួយទៀតស្ថិតនៅក្នុងឯកសារសាកល្បងពីរដែលត្រូវបានសន្មត់ថា bad-3-corrupt_lzma2.xz និង ល្អ-ធំ_បង្ហាប់.lzma
នោះជា commitលោក Ted ដោយគណនី GitHub “Jia Tan” (JiaT75) ក្នុង ឃ្លាំង xz នៅថ្ងៃទី 23 ខែកុម្ភៈ។ វាគឺជាការផ្លាស់ប្តូរដែលគ្មានគ្រោះថ្នាក់ណាមួយឡើយ ដោយបន្ថែមឯកសារសាកល្បង (សន្មតថាប្លុកដែលបានបង្ហាប់ .lzma និង .xz)។ គួរឱ្យចាប់អារម្មណ៍គ្រប់គ្រាន់ ឯកសារសាកល្បងមិនត្រូវបានប្រើដោយការធ្វើតេស្តទេ! បន្ទាត់នៅក្នុងឯកសារ .m4 បញ្ចូលស្គ្រីបដែលបិទបាំង (រួមបញ្ចូលនៅក្នុង tarball) ដើម្បីប្រតិបត្តិនៅចុងបញ្ចប់នៃ configure ប្រសិនបើលក្ខខណ្ឌមួយចំនួនត្រូវគ្នា។ វាកែប្រែ Makefile សម្រាប់ លីបលហ្សាម៉ា បណ្ណាល័យដើម្បីមានកូដដែលស្រង់ទិន្នន័យចេញពីឯកសារ .xz ដែលបន្ទាប់ពីការលុបបំបាត់ការភាន់ច្រឡំបញ្ចប់ នៅក្នុងស្គ្រីបនេះ, ត្រូវបានហៅនៅចុងបញ្ចប់នៃ configure។ វាសម្រេចចិត្តថាតើត្រូវកែប្រែដំណើរការសាងសង់ដើម្បីចាក់កូដ៖ មានតែនៅក្រោម GCC និង GCC linker នៅក្រោម Debian ឬ rpm និងសម្រាប់តែ x86_64 Linux ប៉ុណ្ណោះ។ នៅពេលដែលត្រូវគ្នា កូដដែលចាក់នឹងស្ទាក់ចាប់ការប្រតិបត្តិដោយជំនួសពីរ អ៊ីហ្វុន ឧបករណ៍ដោះស្រាយ ដូច្នេះការហៅជាក់លាក់ត្រូវបានជំនួស។ នេះបណ្តាលឱ្យតារាងនិមិត្តសញ្ញាត្រូវបានវិភាគនៅក្នុងអង្គចងចាំ (វាត្រូវការពេលវេលា ដែលនាំឱ្យមានការរកឃើញ ដូចដែលបានពន្យល់នៅពេលក្រោយ)។
បន្ទាប់មកអ្វីៗកាន់តែគួរឱ្យចាប់អារម្មណ៍៖ ទ្វារខាងក្រោយដំឡើងទំពក់សវនកម្មទៅក្នុងតំណភ្ជាប់ថាមវន្ត ដោយរង់ចាំនិមិត្តសញ្ញាអនុគមន៍ RSA_public_decrypt មកដល់ ដែលត្រូវបានបញ្ជូនបន្តទៅចំណុចមួយចូលទៅក្នុងលេខកូដទ្វារខាងក្រោយ ដែលវានឹងហៅត្រឡប់មកវិញ។ libcryptoប្រហែលជាដើម្បីអនុវត្តការផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវធម្មតា។ ហើយ payload នឹងធ្វើឱ្យសកម្ម ប្រសិនបើកម្មវិធីដែលកំពុងដំណើរការមានឈ្មោះដំណើរការ។ /usr/sbin/sshdវាច្បាស់ណាស់ថាម៉ាស៊ីនមេ SSH គឺជាគោលដៅ។ តាមប្រពៃណី sshd ម៉ាស៊ីនមេដូចជា OpenSSH មិនត្រូវបានភ្ជាប់ជាមួយទេ លីបលហ្សាម៉ាប៉ុន្តែ sshd គឺ ជារឿយៗត្រូវបានជួសជុល ដើម្បីគាំទ្រ systemd-notify ដូច្នេះសេវាកម្មផ្សេងទៀតអាចចាប់ផ្តើមនៅពេលដែល sshd កំពុងដំណើរការ។ ហើយបន្ទាប់មក liblzma ត្រូវបានផ្ទុកដោយប្រយោលដោយ systemd, បិទរង្វង់។
ច្រកខាងក្រោយមិនទាន់ត្រូវបានវិភាគពេញលេញនៅឡើយទេ ប៉ុន្តែវាហាក់ដូចជា... អនុញ្ញាតឱ្យប្រតិបត្តិពាក្យបញ្ជាពីចម្ងាយ (RCE) ជាមួយនឹងសិទ្ធិពិសេសរបស់ដេមិន sshdកំពុងដំណើរការក្នុងបរិបទមុនពេលផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវ។ ព័ត៌មានពីវិញ្ញាបនបត្រពីចម្ងាយ នៅពេលដែលផ្គូផ្គងដោយទ្វារខាងក្រោយ ត្រូវបានឌិគ្រីបជាមួយ ChaCha20 ហើយនៅពេលដែលវាឌិគ្រីបដោយជោគជ័យ វាត្រូវបានបញ្ជូនទៅ ប្រព័ន្ធ()ដូច្នេះនេះគឺជា RCE ដែលមានច្រកទ្វារបិទជិត ដែលអាក្រក់ជាងការរំលងសោសាធារណៈទៅទៀត។
tarball 5.6.1 ក្រោយមកបានបង្ហាញពីកិច្ចខិតខំប្រឹងប្រែងបន្ថែមដើម្បីលាក់ដាន ដោយបន្ថែមការបិទបាំងបន្ថែមទៀតសម្រាប់ឈ្មោះនិមិត្តសញ្ញា និងព្យាយាមជួសជុលកំហុសដែលឃើញ។ យន្តការពង្រីក កន្លែងដែលឯកសារសាកល្បងបន្ថែមត្រូវបានស្វែងរកសម្រាប់ហត្ថលេខាជាក់លាក់ដើម្បីបន្ថែមទៅក្នុងទ្វារក្រោយក៏ត្រូវបានដាក់ឱ្យដំណើរការផងដែរ។
ការវាយប្រហារដ៏ស្មុគស្មាញនេះអាចមើលរំលងបានរហូតដល់ការចែកចាយ Linux មានស្ថេរភាព។ ជាសំណាងល្អ មនុស្សមួយចំនួនចូលចិត្តពិនិត្យមើលថាហេតុអ្វីបានជាមានរឿងមិនប្រក្រតីកើតឡើង។
ការរកឃើញការវាយប្រហារ Backdoor របស់ XZ
ជាច្រើនដង អាកប្បកិរិយាព្យាបាទដែលចាក់ចូលត្រូវបានលាតត្រដាងដោយចៃដន្យ ឬដោយចៃដន្យ។ ឧទាហរណ៍ដ៏ល្អមួយគឺ ការព្រមានអំពីការបោះបង់ចោល (“អ្នកណាខ្វល់ពីការព្រមាន?”) ដែលនាំឱ្យមានការរកឃើញ ការវាយប្រហារតាមស្ទ្រីមព្រឹត្តិការណ៍ នៅក្នុងខែតុលា ឆ្នាំ២០១៨។ ម្នាក់ទៀតគឺជាអ្នកប្រើប្រាស់ដែលបានព្រមាន កូឌិក នៅក្នុងខែមេសា ឆ្នាំ២០២១ ថាស្គ្រីប bash uploader របស់ពួកគេមិនបានឆ្លងកាត់ checksum (“តើអ្នកណាផ្ទៀងផ្ទាត់ភាពត្រឹមត្រូវនៃវត្ថុបុរាណជាមួយ checksum”) ភាពមិនប្រក្រតី និងរោគសញ្ញាចម្លែកៗជាមួយ ssh logins (logins ប្រើប្រាស់ CPU ច្រើន និងបង្កើនពេលវេលាកន្លងផុតទៅ កំហុស valgrind) បានជំរុញឱ្យមានការចង់ដឹងចង់ឃើញ Andres Freundជាអ្នកអភិវឌ្ឍន៍ PostgreSQL ដែលមានការប្រុងប្រយ័ត្ន ប៉ុន្តែមិនមែនជាអ្នកវិភាគសុវត្ថិភាពទេ (ដូចដែលគាត់បាននិយាយ)បន្ទាប់ពីការស៊ើបអង្កេតមួយចំនួនជាមួយ OpenSSH លើ Debian Sid គាត់បានសន្និដ្ឋានថាបញ្ហាពេលវេលាឆ្លើយតបពឹងផ្អែកលើបណ្ណាល័យមួយ។ លីបលហ្សាម៉ាជាផ្នែកមួយនៃ xz- ឧបករណ៍ប្រើប្រាស់ បណ្ណាល័យបង្ហាប់។ ហេតុផល៖ “ឃ្លាំងផ្ទុកទិន្នន័យ xz ខាងលើ និង tarballs xz ត្រូវបានលួចចូលពីក្រោយ"។ ការធ្វើរោគវិនិច្ឆ័យនេះពិតជាត្រឹមត្រូវណាស់! នៅថ្ងៃទី 29 ខែមីនា ឆ្នាំ 2024 Andres បានបង្ហោះនៅក្នុង Openwall នូវការវិភាគដំបូងថា៖ “ទ្វារក្រោយនៅក្នុង xz/liblzma ខាងលើនាំឱ្យមានការសម្របសម្រួលម៉ាស៊ីនមេ sshការពិត៖ tarballs របស់ XZ Utils 5.6.0 និង 5.6.1 មាន backdoor មួយ។ tarballs ទាំងនេះត្រូវបានបង្កើត និងចុះហត្ថលេខាដោយគណនី Jia Tan ដែលបានរៀបរាប់ខាងលើ។ He បានបង្ហោះនៅក្នុង Mastodon នៅពេលក្រោយនៃថ្ងៃនោះ ដោយទទួលស្គាល់ថាការរកឃើញនេះគឺចៃដន្យ ហើយតម្រូវឱ្យមានភាពចៃដន្យជាច្រើន។ មតិយោបល់ពីអ្នកប្រើប្រាស់ផ្សេងទៀតគឺមានតម្លៃអាន។ អ្នកប្រើប្រាស់ GitHub ថេសាមសាម (ហៅកាត់ថា Sam James) បានបោះពុម្ពផ្សាយ GIST ដ៏ល្អមួយ សំណួរដែលសួរញឹកញាប់អំពី xz-utils backdoor កន្លែងដែលការវាយប្រហារត្រូវបានសង្ខេប ដោយភ្ជាប់ទៅបន្ថែមទៀត ការវិភាគស៊ីជម្រៅ នៃបន្ទុកវាយប្រហារ។ ការវិភាគទាំងនេះមានលក្ខណៈបច្ចេកទេសច្បាស់លាស់ ហើយបានជួយយើងឱ្យយល់កាន់តែច្បាស់អំពីការចាក់ថ្នាំ ដែលត្រូវបានធ្វើការវិភាគយ៉ាងល្អិតល្អន់៖- xz/liblzma៖ ការពន្យល់អំពីការបិទបាំងដំណាក់កាល Bashការវិភាគដ៏ល្អមួយលើការបំបាត់ភាពមិនច្បាស់លាស់ដោយស្គ្រីបចាក់បញ្ចូល ក្នុង "ដំណាក់កាល" ចំនួនបួន។
- ខ្សែស្រឡាយ bluesky របស់ Filippo Valsorda ការវិភាគអំពី Backdoor ខ្លួនវានៅក្នុង RSA_public_decrypt ដែលបង្ហាញពីលក្ខណៈរបស់វា៖ RCE មិនមែនជា auth bypass ទេ ហើយ gated (ទទួលយក private key របស់អ្នកនិពន្ធ ហើយបើមិនដូច្នោះទេ នឹងត្រលប់ទៅឥរិយាបថធម្មតាវិញ) / មិនអាចសងវិញបាន។ អ្នកនិពន្ធមានបំណងចង់លាក់ខ្លួនដើម្បីជៀសវាងការរកឃើញ!
- ការវិភាគច្រកចូលខាងក្រោយ XZ ដោយ @smx-smx (WIP) – ការវិភាគបន្ថែមនៃ Backdoor (ខ្ញុំស្ទើរតែវង្វេងនៅដើមដំបូង 😀)
- ឯកសារវិគីអំពីទ្វារក្រោយ xzការវិភាគមួយផ្សេងទៀតនៃស្គ្រីបចាក់ 5.6.1។
របៀបដែលឧប្បត្តិហេតុនេះត្រូវបានដោះស្រាយ
ការបង្ហាញព័ត៌មានដោយលោក Andreas Freund មានការប្រុងប្រយ័ត្ន ពីព្រោះតាមពាក្យសម្ដីរបស់គាត់ផ្ទាល់ថា៖«ដោយសារមានការពាក់ព័ន្ធនៅខាងលើដែលមើលទៅហាក់ដូចជានៅខាងលើ ខ្ញុំមិនទាន់បានរាយការណ៍អំពីកំហុសនៅខាងលើនោះទេ។ ដោយសារដំបូងឡើយ ខ្ញុំគិតថាវាជាបញ្ហាជាក់លាក់របស់ debian ខ្ញុំបានផ្ញើរបាយការណ៍បឋមមួយទៅកាន់ security@...ian.org។ បន្ទាប់មក ខ្ញុំបានរាយការណ៍បញ្ហានេះទៅកាន់ distros@»។ CISលោក A ត្រូវបានជូនដំណឹងដោយការចែកចាយមួយ។
តើអ្នកណាស្ថិតនៅក្រោមការវាយប្រហារ?
ទាំងគណនី 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 ក្នុងករណីនេះ) ដែលជំរុញឱ្យបញ្ចូលការផ្លាស់ប្តូរ។
តារាសម្តែងរូបនេះអាចមានបំណងចង់ចូលទៅកាន់តែស៊ីជម្រៅ រហូតដល់ខឺណែលលីនុច ក្នុងនាមជាអ្នករួមចំណែកដល់ បង្កប់ដោយ xy គម្រោង។ ការវិភាគដំបូងមិនបានរកឃើញភស្តុតាងនៃការរលូតកូនទេ គិតត្រឹមថ្ងៃនេះ។
ចំណាំ៖ មួយទៀត អ្នករួមចំណែក XZ ដែលមានទម្រង់ទាប “Hans Jansen“ (អ្នកប្រើប្រាស់ GitHub “hansjans162”) គឺ ក្រោមការត្រួតពិនិត្យគណនីរបស់វានៅ debian ឥឡូវនេះគឺ បានទប់ស្កាត់គាត់បានធ្វើការអាប់ដេតជាច្រើនចំពោះ Debian Games ដើម្បីលាក់បាំងអ្វីដែលគាត់ចង់បាននៅលើ debian/xz-utils ដែលជាការអាប់ដេតទៅកាន់ upstream 5.6.1 ដើម្បីពន្លឿនការចែកចាយ backdoor ទៅ ដេបៀន/មិនស្ថិតស្ថេរ.
អ្វីដែលយើងអាចនិយាយបានសម្រាប់ពេលនេះ គឺថា នេះគឺជា APT (ដែលមិនទាន់កំណត់អត្តសញ្ញាណ) ដែលកំពុងប្រើប្រាស់គណនីផ្សេងៗគ្នា ធ្វើការយ៉ាងហោចណាស់ពីរឆ្នាំលើយុទ្ធនាការនេះ និងធ្វើការដោយអត់ធ្មត់ដើម្បីដាក់ RCE នៅក្នុង SSH។
គិតត្រឹមពេលសរសេរនេះ អត្តសញ្ញាណនៅពីក្រោយ "ជា តាន" នៅតែមិនទាន់ត្រូវបានបញ្ជាក់នៅឡើយទេ។ គ្មានការអះអាងដែលអាចទុកចិត្តបានចំពោះបុគ្គល អង្គការ ឬតួអង្គរដ្ឋជាក់លាក់ណាមួយត្រូវបានផ្ទៀងផ្ទាត់ជាសាធារណៈនោះទេ ដែលបញ្ជាក់ពីប្រសិទ្ធភាពនៃវិន័យប្រតិបត្តិការរបស់បុគ្គលនោះ។
តើការវាយប្រហារតាមទ្វារក្រោយរបស់ XZ អាចការពារបានដែរឬទេ?
ពិបាកណាស់។
ទីមួយ ផ្នែកមួយនៃ Backdoor ដែលបានចាក់ចូលបានចូលទៅក្នុងឯកសារសាកល្បងដែលបានបង្ហាប់ ដែលមិនត្រូវបានប្រើប្រាស់ដោយការធ្វើតេស្ត។ ត្រឡប់ទៅវិញ វាអាចបង្កើនសំឡេងរោទិ៍ (រំខាន) មួយចំនួន ប៉ុន្តែតើអ្នកណាខ្វល់អំពីការត្រួតពិនិត្យថាឯកសារសាកល្បងទាំងអស់ត្រូវបានប្រើប្រាស់ដោយការធ្វើតេស្តពិតប្រាកដនៅក្នុងពិភពពិត? ទីពីរ ផ្នែកមួយនៃ Backdoor ដែលបានចាក់ចូលបានចូលមកក្នុងឯកសារម៉ាក្រូចូលទៅក្នុង 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 ត្រូវបានបន្ថែមនៅក្នុងខែមិថុនា ឆ្នាំ២០២៣ ដោយ “Hans Jansen” និង “Jia Tan”។ នេះជាលើកដំបូង commit កំពុងបន្ថែមការគាំទ្រ ifunc ទៅ crc64_fast.c (ក្រោយមកត្រូវបានប្រើដើម្បីចាក់ចូល backdoor)។ ច្រើនខែមុនពេលចាក់ចូលប្រព័ន្ធគោលពីរ backdoor នៅក្នុងឯកសារសាកល្បង!
ចំណាំ៖ អ្នកនិពន្ធ និង commitមានភាពខុសគ្នានៅទីនេះ ប៉ុន្តែនេះជារឿងធម្មតា៖ Lasse Collin គឺជាអ្នកថែទាំគម្រោង ហើយគាត់បានបញ្ចូលការផ្លាស់ប្តូរទាំងនោះ។ គាត់ថែមទាំងអរគុណ “Hans Jansen” …
គ្មាននរណាម្នាក់បានលើកឡើងពីការព្រួយបារម្ភមុនពេលការបង្ហោះរបស់ Andres Freund និង CVE ដែលបង្កើតឡើងដោយ RedHat នោះទេ។ ប្រសិនបើអ្នកឃើញឧបករណ៍ជាច្រើនដែលនឹងចាប់បានបញ្ហានេះ ពួកគេរកឃើញសមាសធាតុដែលរងផលប៉ះពាល់ឥឡូវនេះ។ អតីតប្រកាសការពិត។.
ប្រហែលជាការបង្ការដ៏ល្អបំផុតបានមកពីលក្ខណៈនៃការចែកចាយ Linux និងរបៀបដែលកំណែដែលមិនស្ថិតស្ថេរ និងហួសសម័យ ឆ្លងទៅការចែកចាយដែលមានស្ថេរភាពនៅខាងក្រោមតែប៉ុណ្ណោះ បន្ទាប់ពីដំណើរការដែលមានល្បឿនលឿន។
មេរៀនដែលបានរៀនពីការវាយប្រហារ XZ bBackdoor
យើងបានកត់សម្គាល់ឃើញថាវាពិបាករកឃើញប៉ុណ្ណា ចេតនា ទ្វារក្រោយ។ ទ្វារក្រោយគួរតែត្រូវបានចាត់ទុកថាជាការគំរាមកំហែងផ្ទៃក្នុង ព្រោះវាត្រូវបានបង្កប់ដោយបុគ្គលិកផ្ទៃក្នុង ឬតាមរយៈគណនីផ្ទៃក្នុងដែលត្រូវបានសម្របសម្រួល។ ហើយមនុស្សទាំងនោះភាគច្រើនត្រូវបានគេទុកចិត្ត។ ហើយនៅពេលដែលទ្វារក្រោយត្រូវបានបង្កប់នៅក្នុងវត្ថុបុរាណដែលបានចែកចាយ វាធ្វើឱ្យវាកាន់តែពិបាកក្នុងការរកឃើញ។
អ្នកនិពន្ធមួយចំនួនដូចជា Kevin Beaumont ចង្អុលទៅ ប្រព័ន្ធដែលបើកផ្ទៃវាយប្រហារដ៏ធំមួយនៃសេវាកម្មភាគីទីបីទៅកាន់ backdoor។ នេះជាអ្វីដែលតួអង្គអាក្រក់បានរំលោភបំពាននៅទីនេះ។ Systemd មានភ្នែកច្រើន ប៉ុន្តែ XZ គឺជាបណ្ណាល័យដ៏មិនច្បាស់លាស់នៅខាងលើខ្សែសង្វាក់។ “នៅពេលដែលផ្នែកខាងលើមានមេរោគ មនុស្សគ្រប់គ្នាផឹកទឹកពុលនៅខាងក្រោម”។
សំណើសុំការផ្លាស់ប្តូរដែលមិនទាក់ទងគ្នានៅក្នុងប្រព័ន្ធសម្រាប់ ផ្ទុកបណ្ណាល័យបង្ហាប់ដោយថាមវន្តដែលនឹងលុប backdoor ត្រូវបានបញ្ចូលទៅក្នុងប្រព័ន្ធរួចហើយ ប៉ុន្តែមិនទាន់ត្រូវបានចែកចាយនៅឡើយទេ។ ភាពអាស្រ័យបន្ថែមដែលណែនាំដោយ libsystemd អាចជាប្រភពនៃភាពងាយរងគ្រោះនិងម្សិលមិញ សំណើនេះត្រូវបានបើក.
A ការអត្ថាធិប្បាយ នៅក្នុង “xz: បិទ ifunc ដើម្បីជួសជុលបញ្ហា” commit បានផ្តល់នូវការយល់ដឹងយ៉ាងច្បាស់អំពីកន្លែងដែលត្រូវផ្តោតការយកចិត្តទុកដាក់ ប្រសិនបើយើងចង់ទប់ស្កាត់សកម្មភាពបែបនេះ (ការសង្កត់ធ្ងន់គឺខ្ញុំ)៖
«មេរៀនដែលយើងគួររៀនក្នុងនាមជាសហគមន៍មួយ គឺត្រូវធានាឲ្យបាននូវសុវត្ថិភាព» software supply chain security ជារួម ការធ្វើសវនកម្មប្រព័ន្ធសាងសង់លើសពីកូដប្រភព។ ដូចជាការបំពាន SolarWinds ដែលអ្នកវាយប្រហារបានកែប្រែការអាប់ដេតកម្មវិធីសម្រាប់ការផ្តល់ជូនកម្មវិធីត្រួតពិនិត្យប្រភពបិទរបស់ SolarWinds។
សំណួរដែលត្រូវបានសួរជាញឹកញាប់
តើទ្វារខាងក្រោយរបស់ XZ នៅតែជាហានិភ័យនៅសព្វថ្ងៃនេះទេ?
ភាគច្រើនត្រូវបានទប់ស្កាត់ ប៉ុន្តែមិនទាន់បាត់ទាំងស្រុងនៅឡើយទេ។ នៅក្នុងខែសីហា ឆ្នាំ២០២៥ ក្រុមអ្នកស្រាវជ្រាវបានរកឃើញថា ទ្វារខាងក្រោយនៅតែមានវត្តមាននៅក្នុងរូបភាព Debian Docker Hub ជាច្រើន ដែលត្រូវបាន Debian ចាត់ទុកជាវត្ថុបុរាណប្រវត្តិសាស្ត្រអសកម្ម។ ក្រុមនានាគួរតែផ្ទៀងផ្ទាត់ថាពួកគេមិនកំពុងបង្កើតលើរូបភាពមូលដ្ឋានដែលហួសសម័យ និងមិនទាន់បានបំណះ ជាជាងសន្មតថាបំណះឆ្នាំ២០២៤ បានបិទទ្វារទាំងស្រុង។
