XZ बैकडोर घटना: शुरुआती विश्लेषण के नतीजे

 (securelist.com)
2 पॉइंट द्वारा GN⁺ 2024-04-13 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • XZ Utils/liblzma बैकडोर 29 मार्च 2024 को Openwall OSS-security mailing list पर सार्वजनिक हुआ, और हमलावर का अंतिम लक्ष्य संभवतः systemd-आधारित distributions के OpenSSH server sshd में remote code execution क्षमता जोड़ना था
  • infection chain XZ repository की test files और build infrastructure का उपयोग करने वाले multi-stage insertion से बना था, और build-to-host.m4, bad-3-corrupt_lzma2.xz, good-large_compressed.lzma के जरिए malicious object file build के दौरान liblzma से link हो गई
  • बैकडोर वाली XZ 5.6.0 और 5.6.1 कुछ प्रमुख vendors के beta और experimental builds के रूप में वितरित हुईं, और CVE-2024-3094 को severity 10 points दी गई
  • binary backdoor GLIBC के IFUNC और cpuid call path का दुरुपयोग करके load होता है, और बाद में OpenSSL/libcrypto से जुड़े functions को hook कर संक्रमित machines के connections की निगरानी करने की कोशिश करता है
  • malicious code /usr/bin/sshd के चलने और kill switch environment variable की जांच करता है, और trie-आधारित string processing, dynamic symbol resolution, और rtdl-audit runtime patching के जरिए analysis और detection को कठिन बनाता है

घटना का सार और प्रभाव का दायरा

  • 29 मार्च 2024 को Openwall OSS-security mailing list के message के जरिए XZ backdoor की खोज सार्वजनिक हुई
  • XZ कई प्रमुख Linux distributions में शामिल एक compression utility है
  • जोखिम का मुख्य बिंदु यह है कि backdoor वाला liblzma कुछ systemd-आधारित distributions में OpenSSH server process sshd से जुड़ सकता था
    • Ubuntu, Debian, RedHat/Fedora Linux में OpenSSH को systemd functions इस्तेमाल करने के लिए patch किया गया है, इसलिए वे इस library पर निर्भर हैं
    • Arch Linux और Gentoo को प्रभावित नहीं माना गया
  • हमलावर का अंतिम लक्ष्य संभवतः ऐसा sshd remote code execution feature डालना था, जिसे बाकी लोग इस्तेमाल न कर सकें
  • single malicious patch, fake package, या typosquatting package पर केंद्रित दूसरे supply chain attacks से अलग, यह घटना दुनिया भर के SSH servers को compromise करने के बेहद करीब पहुंच चुका multi-stage operation लगती है

बैकडोर कैसे डाला गया

  • liblzma backdoor को build process और test files, दोनों का उपयोग करके दो स्तरों पर insert किया गया
    • final package बनाने वाले build infrastructure source code को build-to-host.m4 जोड़कर बदला गया
    • test case files के अंदर छिपे scripts और binary components को build के दौरान extract किया गया
  • infection flow तीन files पर केंद्रित था
    • build-to-host.m4: अगले stage का script extract करने वाला build script
    • bad-3-corrupt_lzma2.xz: shell script छिपी हुई test file
    • good-large_compressed.lzma: malicious binary object छिपी हुई test file
  • extract किए गए malicious binary components compilation के दौरान normal library से link होकर Linux repositories तक पहुंच सकते थे
  • प्रमुख vendors ने इस malicious component को beta और experimental builds में शामिल करके distribute किया
  • XZ Utils compromise को CVE-2024-3094 assign किया गया, और severity अधिकतम 10 points है

प्रमुख timeline

  • 19 जनवरी 2024: नए maintainer jiaT75 ने XZ website को GitHub Pages पर migrate किया
  • 15 फरवरी 2024: build-to-host.m4 को .gitignore में जोड़ा गया
  • 23 फरवरी 2024: malicious script stages वाली दो “test files” जोड़ी गईं
  • 24 फरवरी 2024: XZ 5.6.0 release हुआ
  • 26 फरवरी 2024: CMakeLists.txt में Landlock security feature में बाधा डालने वाला commit शामिल हुआ
  • 4 मार्च 2024: backdoor ने Valgrind से जुड़ी समस्या पैदा की
  • 9 मार्च 2024: दोनों test files update की गईं, CRC function बदला गया, और Valgrind issue “fix” किया गया
  • 9 मार्च 2024: XZ 5.6.1 release हुआ
  • 28 मार्च 2024: bug मिला और Debian और RedHat को सूचना दी गई
  • 28 मार्च 2024: Debian ने XZ 5.6.1 को 5.4.5-0.2 version पर rollback किया
  • 29 मार्च 2024: OSS-security mailing list पर सार्वजनिक mail post की गई
  • 29 मार्च 2024: RedHat ने पुष्टि की कि Fedora Rawhide और Fedora Linux 40 beta में backdoor वाला XZ distribute हुआ था
  • 30 मार्च 2024: Debian ने builds रोक दिए और rebuild प्रक्रिया शुरू की
  • 2 अप्रैल 2024: XZ के main developer ने backdoor घटना को स्वीकार किया

infection chain के 3 stage

  • Stage 1: बदला हुआ build-to-host.m4

    • XZ के official GitHub repository releases में malicious test files शामिल थीं, लेकिन उन files के execute होने का मौका नहीं था, इसलिए शुरुआत में वे harmless थीं
    • infection को bootstrap करने वाला malicious code संभवतः jiaT75 के control वाले xz[.]tukaani.org से दिए गए releases में शामिल था
    • अधिकांश distributions ने इसी URL का उपयोग किया, और downloaded release में malicious code वाली build-to-host.m4 file शामिल थी
    • build-to-host.m4 build process के दौरान execute होता है और bad-3-corrupt_lzma2.xz के “broken” data को tr से ठीक करने के बाद xz -d से decompress करता है
    • decompression result में एक shell script होता है, जिसे बाद में /bin/bash से execute किया जाना था

  • Stage 2: insert किया गया shell script

    • malicious .m4 file द्वारा insert किया गया script जांचता है कि वह Linux machine पर चल रहा है या नहीं, और intended build process के अंदर चल रहा है या नहीं
    • अगले stage के execution के लिए good-large_compressed.lzma इस्तेमाल होता है
    • यह file XZ से सामान्य रूप से compressed है, लेकिन decompressed data के अंदर junk data है
    • script data extract करने के लिए head pipeline को eval से execute करता है
    • हर head command अगले 1024 bytes को ignore करता है या अगले 2048 bytes या 724 bytes extract करता है
    • कुल 33,492 bytes extract होते हैं
    • tail file के अंतिम 31,265 bytes रखता है और बाकी को ignore करता है
    • इसके बाद tr से basic substitution लागू कर obfuscation हटाई जाती है, और दूसरा XZ command बदले हुए bytes को raw lzma stream के रूप में decompress करके result को shell में भेजता है

  • Stage 3: backdoor object extraction

    • अंतिम stage का shell script कई conditions check करता है कि वह expected environment में चल रहा है या नहीं
    • यह check करता है कि project IFUNC इस्तेमाल करने के लिए configured है या नहीं
    • यह check करता है कि compilation GCC से हो रहा है या नहीं
    • इसके बाद script जांचता है कि project में उसके द्वारा इस्तेमाल की जाने वाली खास file मौजूद है या नहीं
    • यह stage good-large_compressed.lzma के अलग offset में छिपी object file extract करता है
    • extraction process कई commands क्रम से चलाता है, और हर command का output अगले command के input में देता है
    • XZ tool से good-large_compressed.lzma extract किया जाता है
    • eval $i और कई head calls इस्तेमाल होते हैं
    • RC4 जैसे custom algorithm से binary data decrypt किया जाता है
    • decrypted compressed file को फिर से XZ से extract किया जाता है
    • शुरुआत के कुछ bytes हटाने के बाद result को liblzma_la-crc64-fast.o के रूप में save किया जाता है
    • अंत में script liblzma की crc_x86_clmul.h file में is_arch_extension_supported function को modify करता है
    • __get_cpuid call को _get_cpuid से बदलकर एक underscore हटाता है
    • इस बदलाव से backdoor object library में link हो सकता है

binary backdoor loading का तरीका

  • मूल XZ code में CRC calculation के लिए special functions lzma_crc32 और lzma_crc64 हैं
  • दोनों functions ELF symbol table में GLIBC के IFUNC type के रूप में stored हैं
    • IFUNC dynamic linker को shared library load करते समय इस्तेमाल किए जाने वाले function को dynamically select करने देता है
    • XZ यह feature इसलिए इस्तेमाल करता है ताकि processor की modern capabilities CLMUL, SSSE3, SSE4.1 check करके तय कर सके कि optimized CRC function इस्तेमाल करना है या नहीं
  • processor capability check करने के लिए cpuid command की जरूरत होती है, और GLIBC द्वारा दिया गया __get_cpuid wrapper call होता है
  • malicious script ने __get_cpuid को _get_cpuid में बदल दिया, जिससे code call backdoor object file के अंदर मौजूद _get_cpuid symbol से जुड़ गया
  • शुरुआती backdoor code दो बार call होता है क्योंकि lzma_crc32 और lzma_crc64 दोनों वही modified function _get_cpuid इस्तेमाल करते हैं
    • simple counter से जांचता है कि पहले से execute हुआ है या नहीं
    • अगर lzma_crc64 IFUNC _get_cpuid call करता है और counter value 1 है, तो final entry point पर redirect करने वाला stage शुरू होता है

runtime behavior और hooking targets

  • backdoor चल रहे process की key information रखने वाले structures initialize करता है
  • hardcoded offsets से Global Offset Table(GOT) address ढूंढता है, और उसके अंदर cpuid pointer खोजता है
  • इसके बाद pointer को main malicious function से बदलकर ऐसे malicious function call करता है जैसे cpuid call हो रहा हो
  • मुख्य लक्ष्य कुछ functions को hook करना है ताकि infected machine पर आने वाले connections की निगरानी की जा सके
  • target functions libcrypto से संबंधित हैं
    • RSA_public_decrypt: private key से signed ciphertext decrypt करते समय इस्तेमाल होता है
    • EVP_PKEY_set1_RSA: किसी specific context की RSA key set करते समय इस्तेमाल होता है
      • modern SSH server versions में नहीं है, लेकिन standalone SSH key generation tool में इस्तेमाल होता है
    • RSA_get0_key: RSA key प्राप्त करने के लिए इस्तेमाल होता है
  • hooking process में कई internal structures तक पहुंच और process-specific structures में manipulation की जरूरत होती है, और malicious code analysis avoidance checks भी करता है

execution environment checks और analysis evasion techniques

  • sshd और kill switch की जांच

    • backdoor सबसे पहले symbol addresses को dynamically resolve करने वाले ld-linux dynamic linker को parse करता है
    • यह check करता है कि current runtime environment criteria से match करता है या नहीं
    • यह check करता है कि current process /usr/bin/sshd है या नहीं
    • यह check करता है कि kill switch मौजूद है या नहीं
    • current process name argv[0] से extract किया जाता है
    • process environment variables सभी parse किए जाते हैं और internal string table में मौजूद values से match हैं या नहीं, यह जांचा जाता है
    • अगर कोई matching environment variable हो या process sshd न हो, तो malicious code execution रोक देता है
    • internal table का एकमात्र variable yolAbejyiejuvnup=Evjtgvsh5okmkAvj इस context में kill switch की तरह काम करता है

  • trie-आधारित string processing

    • backdoor की एक खासियत यह है कि string operations के लिए single trie structure इस्तेमाल करता है
    • function names जैसे constants को सीधे compare करने या string hash से compare करने के बजाय, यह check करता है कि trie lookup result किसी specific constant value के बराबर है या नहीं
    • ELF header का magic value trie से 0x300 लौटाता है
    • system function name 0x9F8 return value से match होता है
    • trie सिर्फ comparison के लिए नहीं, host binary के अंदर strings खोजने के लिए भी इस्तेमाल होता है
    • उदाहरण के लिए ssh-2.0 जैसे string pointer इस्तेमाल करने वाला function host binary में string खोजता है ताकि backdoor body में suspicious data न बचे
    • implementation 16-byte bitmask इस्तेमाल करता है
    • हर half input byte ranges 0x00-0x3F, 0x40-0x7F से correspond करता है
    • trie leaf node 2-byte होता है, जिसमें 3 bits flags के लिए इस्तेमाल होते हैं और बाकी value या next node location के लिए reserved होते हैं

symbol resolution और rtdl-audit hooking

  • symbol resolution routines

    • backdoor में ELF Symbol structure खोजने के लिए कम से कम 3 symbol resolution routines हैं
    • सभी symbol resolution functions input के रूप में trie में search की जाने वाली key लेते हैं
    • एक resolver सभी symbols पर iterate करके desired key वाला symbol खोजता है, और मिलने पर Elf64_Sym structure return करता है
    • यह structure बाद में backdoor के internal structures fill करने और required function pointers store करने के लिए इस्तेमाल होता है
    • यह process Windows threats में आम तौर पर दिखने वाले API hashing routine जैसा है
    • backdoor बाद में cryptographic routines में इस्तेमाल होने वाले कई OpenSSL libcrypto functions खोजता है
    • खोजे और resolved किए गए functions की संख्या track की जाती है, और इसी value से तय होता है कि normal execution होगा या रुकना है

  • lzma_alloc का दुरुपयोग करने वाला fake allocator

    • एक और symbol resolver liblzma के अपने function lzma_alloc का दुरुपयोग करता है
    • lzma_alloc एक function है जो default allocator malloc या custom allocator इस्तेमाल करके memory efficiently allocate करने में मदद करता है
    • XZ backdoor में fake allocator के जरिए यह function एक और symbol resolver की तरह काम करता है
    • मूल रूप से “allocation size” के लिए इस्तेमाल parameter असल में trie के अंदर symbol key के रूप में इस्तेमाल होता है
    • इस trick का मकसद backdoor analysis को कठिन बनाना है
    • backdoor runtime के दौरान dynamically symbols resolve करता है, और यह इस तरीके तक सीमित नहीं है कि सभी symbols एक साथ resolve करे या केवल जरूरत के समय resolve करे
    • resolution targets में normal OpenSSL functions से लेकर machine पर command execute करने वाले system जैसे functions तक शामिल हैं

  • rtdl-audit runtime patching

    • backdoor function hooking के लिए dynamic linker के rtdl-audit feature का इस्तेमाल करता है
    • आम तौर पर rtdl-audit एक feature है जिससे developers custom shared library बनाकर symbol resolution जैसे linker events की notifications पा सकते हैं
    • XZ backdoor अलग shared library बनाने के बजाय memory में पहले से registered default interface को runtime patch करके symbol resolution routines hijack करता है
    • dynamic linker memory area के dl_audit global variable में stored malicious audit_iface structure में symbind64 callback address होता है
    • जब dynamic linker यह callback call करता है, तो सभी symbol information backdoor के control में चली जाती है, और target functions के लिए malicious address return करके hooking हासिल होती है
    • dl_audit और dl_naudit addresses dl_main और dl_audit_symbind_alt functions को disassemble करके प्राप्त किए जाते हैं
    • backdoor में instruction decoding के लिए internal minimal disassembler शामिल है, और *audit address जैसे specific values खोजने में इसका बड़े पैमाने पर इस्तेमाल होता है

पुष्टि किए गए backdoor distributions और detection information

  • backdoor वाले source distributions

    • xz-5.6.0
      • MD5: c518d573a716b2b2bc2413e6c9b5dbde
      • SHA1: e7bbec6f99b6b06c46420d4b6e5b6daa86948d3b
      • SHA256: 0f5c81f14171b74fcc9777d302304d964e63ffc2d7b634ef023a7249d9b5d875
    • xz-5.6.1
      • MD5: 5aeddab53ee2cbd694f901a080f84bf1
      • SHA1: 675fd58f48dba5eceaf8bfc259d0ea1aab7ad0a7
      • SHA256: 2398f4a8e53345325f44bdd9f0cc7401bd9025d736c6d43b372f4dea77bf75b8

  • विश्लेषित प्रमुख artifacts

    • bad-3-corrupt_lzma2.xz: 86fc2c94f8fa3938e3261d0b9eb4836be289f8ae
    • build-to-host.m4: b4dd2661a7c69e85f19216a6dbbb1664
    • good-large_compressed.lzma: 540c665dfcd4e5cfba5b72b4787fec4f
    • liblzma_la-crc64-fast.o: 212ffa0b24bb7d749532425a46764433

  • ज्ञात backdoor वाली libraries

    • Debian Sid liblzma.so.5.6.0
      • MD5: 4f0cf1d2a2d44b75079b3ea5ed28fe54
      • SHA1: 72e8163734d586b6360b24167a3aff2a3c961efb
      • SHA256: 319feb5a9cddd81955d915b5632b4a5f8f9080281fb46e2f6d69d53f693c23ae
    • Debian Sid liblzma.so.5.6.1
      • MD5: 53d82bb511b71a5d4794cf2d8a2072c1
      • SHA1: 8a75968834fc11ba774d7bbdc566d272ff45476c
      • SHA256: 605861f833fc181c7cdcabd5577ddb8989bea332648a8f498b4eef89b8f85ad4

  • detection names

    • Kaspersky products हमले से जुड़े malicious objects को HEUR:Trojan.Script.XZ और Trojan.Shell.XZ के रूप में detect करते हैं
    • Kaspersky Endpoint Security for Linux, Critical Areas Scan task के हिस्से के रूप में SSHD process memory में मौजूद malicious code को MEM:Trojan.Linux.XZ के रूप में detect करता है
    • प्रदान किया गया Yara rule CVE-2024-3094 से संबंधित malicious get_cpuid function खोजने के लिए liblzma_get_cpuid_function rule है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-04-13
Hacker News की राय

  • लगता है यह वाक्य असल में जो हुआ, उसे कुछ कम करके बता रहा है
    backdoor के तकनीकी पहलू से ज्यादा डरावनी चीज social engineering की मात्रा और स्तर है। backdoor अंतिम product था, और उसे डाल पाना इसलिए संभव हुआ क्योंकि उस समय तक पूरा xz project लंबे समय से malicious actors, यानी “Jia Tan” और उसके आसपास के लोगों के कब्जे में आ चुका था। maintainer के खिलाफ एक साल से ज्यादा समय तक psychological operation चलाया गया, और maintainer या किसी और को पता नहीं चला
    यह spy novel जैसी बात है, और अगर ऐसी चीज संभव है, तो उत्सुकता होती है कि अभी दूसरे projects में और क्या-क्या चल रहा होगा
    backdoor code में भी वही सोच दिखती है। यह सिर्फ harmless दिखने की कोशिश नहीं करता, बल्कि commit messages, comments, variable names, command selection आदि के जरिए ऊपर से यह कहानी सक्रिय रूप से बनाता है कि वह क्या कर रहा है, जबकि असल में वह बिल्कुल अलग काम कर रहा होता है। संरचना ऐसी है कि code को पहले देखने वाला व्यक्ति पहले अपनी समझ पर शक करे, फिर bug पर शक करे, और काफी देर बाद जाकर malicious intent पर शक करे

    • सचमुच विश्वास करना मुश्किल स्तर है। यह conspiracy theory जैसा लग सकता है, लेकिन यह भी सोचने की बात है कि क्या real world में ऐसा कोई psychological operation था जिससे original author समय न दे पाए और अंत में ownership बुरे actor को सौंप दे
      उम्मीद है कि जो भी intelligence agencies हों, वे इस incident की और गहराई से जांच कर रही होंगी
    • उम्मीद है हम इससे सबक लेंगे। वास्तव में बहुत कुछ हो रहा है। दुनिया भर में government-backed agencies और black-market organizations में से कई का mission backdoor हासिल करना है, और उनके पास पर्याप्त funding भी है। यही उनका काम है
      backdoor से जुड़े हर HN thread में जब इस संभावना को paranoia या tinfoil-hat सोच बताकर नकारा जाता है, तो झुंझलाहट होती है। इसे ऐसे treat किया जाता है जैसे ऐसा होता ही नहीं, जबकि यह बस पकड़ा गया एक ठोस मामला है; जो अभी नहीं पकड़े गए हैं, वे अनगिनत हैं
      यह मामला open source project था, इसलिए discovery अपेक्षाकृत आसान थी, फिर भी किस्मत अच्छी रही। अब closed-source products के बारे में सोचें, तो backdoor डालना एक organization में घुसपैठ करने या उस पर दबाव डालने की समस्या भर रह जाता है। ऐसी चीजें अक्सर होती हैं। कोई मानना नहीं चाहता, लेकिन यह आम है। जिसने tech infrastructure company में काम किया हो, उसके पास कुछ कहानियां होंगी। NDA या उससे भी गंभीर वजहों से बताना मुश्किल होता है, लेकिन यह सच में होता है
    • मैं पूरी तरह सहमत हूं कि code देखने वाले को अपनी समझ पर शक करवाया गया। इसमें लगी manipulation, meticulousness, patience और persistence हैरान करने वाली है
      यह किसी व्यक्ति की obsession का परिणाम हो सकता है, या किसी private security firm या state actor का काम हो सकता है जो कई projects पर 9 से 5 की job की तरह ऐसी चीजें करता हो

  • अब तक ध्यान backdoor के सफलतापूर्वक काम करने और लक्ष्य हासिल करने के तरीके पर केंद्रित रहा है, यह स्वाभाविक है
    फिर भी गलतियों और over-engineered हिस्सों पर गहरी analysis देखना चाहूंगा। Bryan Cantril interview [1] में Andrés कहते हैं कि यह ऐसा लगता है जैसे off-the-shelf backdoor component हो, जो deployment method तक को ठीक से जानकर नहीं बनाया गया था, इसलिए इसमें कई बेवकूफी भरी चीजें थीं। उदाहरण के लिए symbol table lookup, जिसने उन्हें जांच करने पर मजबूर किया
    इसी तरह यह भी उत्सुकता है कि RC4 से 48 bytes क्यों काटे गए [2]
    अगर उनके पास और समय होता या बेहतर team होती, तो वे इसे कैसे बेहतर बना सकते थे, या कहां उन्होंने ज्यादा बड़ी गलती की, इस पर भी सुनना चाहूंगा
    [1] https://youtu.be/jg5F9UupL6I?si=gvXsYFXgagkGOMd4
    [2] https://twitter.com/matthew_d_green/status/17744729080201014...

  • अगर मैं सही समझा हूं, तो एक उपयोगी hardening यह हो सकती है कि हर dynamic link library की अपनी GOT हो, और dynamic linking खत्म होने के बाद table को read-only mark कर दिया जाए। यानी dynamic boundary के पार दूसरी तरफ के ifunc entries को patch न किया जा सके
    इससे ऐसे code की supply-chain security बेहतर हो सकती है जो कहीं link तो होता है, लेकिन execute नहीं होता
    आगे बढ़कर, ifunc को declarative तरीके से implement करना बेहतर हो सकता है, ताकि link की जा रही हर library में arbitrary code execution न हो सके। backward compatibility के कारण अभी implementation मुश्किल होगा, लेकिन लंबे समय में इसे layered तरीके से अपनाया जा सकता है। उदाहरण के लिए, अगर किसी library को “declarative link ifunc” feature bit के साथ build किया जाए, तो dynamic linker execution fail कर दे जब तक linked सभी libraries में वही feature flag न हो

    • एक और नजरिए से देखें तो build system ही समस्या है
      फिलहाल ज्यादातर library builds बेहद जटिल और अस्पष्ट scripts चलाते हैं, जिन्हें Turing-complete environment चाहिए। यह attacker को अंतहीन attack surface देता है, और build process hijack हो जाए तो मौका मिल जाता है
      runner को सीमित state machine तक रखने वाले declarative build process की तरफ जाना मददगार होगा। यह requirement भी सोचने लायक है कि source के हर chunk को reproducible होना चाहिए
    • सही भी है और नहीं भी, लेकिन कुल मिलाकर नहीं। यह तरीका ifunc को इस तरह सीधे इस्तेमाल करने से रोक देगा, लेकिन अहम बात यह है कि इस backdoor author ने sensitive process के address space में जाने वाली library में arbitrary code inject कर दिया था
      उस point से आगे सभी defenses बेअसर हो जाते हैं। चाहें तो GOT को फिर से writable map कर सकते हैं, और भले ही ऐसा व्यवहार “suspicious” के रूप में detect हो या OS transition को रोक सके, injected code control flow को सैकड़ों दूसरे तरीकों से पलट सकता है। arbitrary read/write, code execution, सब कुछ संभव है। इस स्तर की compromise को रोकने वाली कोई security mitigation नहीं है। चाहें तो private key leak करके सीधे attacker को भेज सकते हैं, या shell खोल सकते हैं। इस stage पर protection design करने की कोशिश बेकार है
    • dynamic linking पूरी होने के बाद table को read-only mark करना दुर्भाग्य से काम नहीं करेगा। dynamic linking lazy तरीके से होती है, इसलिए “पूरा” होने का कोई क्षण नहीं होता
      सही function pointer पहली बार call होने पर load होता है और stub की जगह table में डाल दिया जाता है, और वह समय मनमाने रूप से बहुत दूर future में हो सकता है। असल में gtk apps जैसे बड़े library ecosystems में linked functions में से ज्यादातर कभी call ही नहीं होते
    • अगर host architecture के लिए build कर रहे हैं, तो बिना नुकसान के ifunc को पूरी तरह बंद किया जा सकता है। Gentoo में -march=native से build करना आम है, और glibc के USE flag में -multiarch set करने से ifunc disable करना आसान है। कोई negative impact नहीं देखा
    • क्या कोई programming language है जो library imports को sandbox कर सकती हो?

  • पहले 3 चरणों के बारे में यह लेख पिछले 2 हफ्तों में जो जानकारी सामने आई है, उसमें बहुत कुछ नया नहीं जोड़ता। यह flowchart के साथ एक अच्छी summary जैसा है
    लेकिन binary को इतनी detail में analyze करने वाला हिस्सा नया लगता है
    उसमें दिखा source code कैसे बनाया गया होगा? Disassembler चलाकर, code क्या कर रहा है यह समझने के बाद, सभी नामों को descriptive नामों में बदल दिया गया? 2 हफ्तों में यह कर लेना काफी बड़ी उपलब्धि लगती है

    • लेखक GReAT हैं
      Global Research & Analysis Team, Kaspersky Lab
      https://securelist.com/author/great/
      लगता है लेख लिखने वाले Kaspersky Lab की malware analysis team हैं, इसलिए संभावना है कि वे binary reverse engineering में काफी अच्छे हों
    • सफेद screenshot में इस्तेमाल किया गया tool IDA Pro है, जो एक decompiler है
      https://hex-rays.com/ida-pro/

  • असली जिज्ञासा यह है कि xz की जांच शुरू करवाने वाली SSH initial delay ठीक किस वजह से हुई थी। क्या किसी ने पता लगाया?

    • हर connection पर अतिरिक्त ECC operation किया जाता है, लेकिन आधुनिक CPU पर इसमें 500ms लगने वाली बात नहीं है
      जिन लोगों ने code की reverse engineering की है, उनके मुताबिक command message को SSH host key से भी bind करना पड़ता है। इसलिए अगर host key RSA key हो, तो हर connection पर अतिरिक्त RSA decryption operation भी हुआ हो सकता है
      वह delay की वजह के लिए पर्याप्त लगता है
    • यह जानबूझकर किया गया हो सकता है
      पहले code injection की कोशिश किए बिना, बाहर से यह पता लगाने का आसान तरीका है कि server infected है या नहीं

  • लेखकों को glibc internals की बहुत गहरी जानकारी है। यह वैसी चीजें हैं जो source code में गले तक डूबे रहने पर ही पता चलती हैं, और इसमें कई नई techniques भी हैं
    custom ELF parser और disassembler इतने जटिल हैं कि यह कल्पना करना मुश्किल है कि उस code को पहले कहीं और इस्तेमाल नहीं किया गया होगा या आगे फिर इस्तेमाल नहीं किया जाएगा
    सोचता हूं कि क्या इस मामले की जितनी गंभीर investigation होनी चाहिए, उतनी होगी; लेकिन ऐसा लगता नहीं

  • आखिरकार, क्या किसी ने उस backdoor bug का analysis किया है जिसकी वजह से Valgrind error और SSH slowdown सामने आए?

    • लगता है यह साफ तौर पर गलत memory write था: https://www.mail-archive.com/valgrind-users@lists.sourceforg...
      Valgrind “fix” ifunc को disable करना था, और इसके परिणामस्वरूप backdoor disable हो गया और error गायब हो गया
      slowdown, मेरी जानकारी में, backdoor द्वारा किए गए सभी symbol और instruction lookups से आया

  • twist के तौर पर देखें तो, attacker ने scripts और code में detection से बचने के लिए जितनी मेहनत की, उसे देखते हुए यह पूरा project ध्यान भटकाने के लिए हो सकता है, या एक साथ चल रहे कई प्रयासों के बीच backup plan भी हो सकता है
    ऐसी चीजों से एक कदम आगे रहने के लिए क्या करना चाहिए? community का SSHD पर focus करना क्या पूरे system के दूसरे हिस्सों को प्रभावित करेगा? दूसरे technical या social पहलुओं पर?
    aluminium foil hat मजेदार है

    • मैं आशावादी नहीं हूं। Flathub के flatpak binaries की actual auditing करने वाले लोग भी बहुत कम हैं। क्या वे सच में source से build हुए हैं? बस author कहता है कि वह ऐसा साबित करता है। ऐसे backdoor जैसी sophisticated delivery mechanism की भी जरूरत शायद न पड़े
    • आप सब कुछ खुद लिख सकते हैं, और verified developers की dedicated team रख सकते हैं
      या Microsoft जैसी जगहों से closed source खरीदकर उम्मीद कर सकते हैं कि उनके पास code को ज्यादा सख्ती से review करने के संसाधन और इच्छा होगी
      और अजीब network activity और privilege escalation attempts detect करने के लिए एक अच्छी security operations team रखने वाला approach तो हमेशा है ही
    • मिलते-जुलते backdoors से एक कदम आगे रहने के तरीके के तौर पर मैं sshd traffic को spiped tunnel में wrap करने के बारे में सोचता हूं। Spiped को source से compile किया जाता है और statically link किया जाता है, और आखिरी stable version 2021 का है
    • open source contributors पर शक करना मेरा aluminium foil hat idea है। इसलिए नहीं कि वे किसी खास देश से हैं, और न इसलिए कि लगता है उनसे कभी असल में मुलाकात नहीं हुई
      बस जिन contributors का काम कर रहे project के बाहर कोई history या footprint नहीं है, उन्हें आगे से red flag माना जाना चाहिए
    • aluminium foil hat की जरूरत नहीं है। FOSS projects में उनके मशहूर होने से पहले से ही backdoors डाले जाते रहे हैं, और इस बार फर्क यह है कि इसे state-backed actors कर रहे हैं
      पुराने groups GOBBLES, ADM, ac1db1tch3z, ~el8 ने भी ऐसा किया था, और isec.pl जैसे private “security researchers” ने भी
      इस बार यह इसलिए समस्या है क्योंकि state actors उस corporate capitalism का फायदा उठा रहे हैं जिसने foundation projects को कम वेतन पर टिकाए रखने वाला दौर बनाया है। malicious actors के पास अपने targets हासिल करने के लिए practically unlimited resources हैं
      आखिरकार उसी ने NSO, Zerodium जैसे संगठनों की demand और जन्म पैदा किया
      उससे पहले exploits और backdoors की value लगभग नहीं थी, और hackers Qualys जैसी कंपनियों से sponsorship या hiring की उम्मीद करते थे

  • मैंने Google की zero-day vulnerability hacking analysis कुछ बार देखी हैं और वे भी unrealistically शानदार थीं, लेकिन यह hack अब तक के सबसे बड़े hacks में से एक लगता है

  • मैंने देखा कि xz repository फिर से GitHub पर आ गई है, और Lasse तथा एक नया contributor cleanup कर रहे थे। उन्होंने ifunc support हटा दिया है, और blobs के बिना test files बना सकें, इसके लिए test file generation code repository में commit किया है। लगता है काम सही दिशा में हो रहा है