अगर आप iTerm2 इस्तेमाल करते हैं, तो `cat readme.txt` भी सुरक्षित नहीं है

• SSH integration रिमोट shell से संवाद करने के लिए टर्मिनल escape sequence का उपयोग करता है, और इसी संरचना की वजह से सामान्य टर्मिनल output भी conductor protocol की तरह इंटरप्रेट किया जा सकता है
• मुख्य समस्या trust failure है, जहां असली रिमोट conductor न होकर malicious file·banner·MOTD·server response भी forged DCS 2000p और OSC 135 के जरिए conductor की तरह व्यवहार कर सकते हैं
• सिर्फ cat readme.txt चलाने भर से भी अगर fake conductor transcript render हो जाए, तो iTerm2 अपने-आप getshell·pythonversion·run(...) flow आगे बढ़ाता है, और attack output को केवल responses का नाटक करना होता है
• exploit, PTY में लिखे गए base64 command के उस भ्रम का फायदा उठाता है जहां असली SSH conductor न होने पर वे local shell plain-text input की तरह गिर जाते हैं, और आखिरी chunk के ace/c+aliFIo path के रूप में इंटरप्रेट होने पर execution संभव हो जाता है
• fix 31 मार्च के commit a9e745993c2e2cbb30b884a16617cd5495899f86 में शामिल किया गया था, लेकिन खुलासे के समय तक यह stable release में शामिल नहीं था, जिससे patch rollout से पहले exposure gap बन गया

---

iTerm2 के SSH integration की पृष्ठभूमि

• iTerm2 SSH integration रिमोट session को अधिक समृद्ध तरीके से समझने के लिए बना फीचर है, और यह रिमोट shell पर छोटे helper script conductor को अपलोड करके काम करता है
  • it2ssh के जरिए SSH integration शुरू होता है
  • मौजूदा SSH session के जरिए conductor नाम का remote bootstrap script भेजा जाता है
  • यह remote script iTerm2 protocol में counterpart की भूमिका निभाता है
• iTerm2 और remote conductor सामान्य network service की तरह नहीं, बल्कि terminal I/O पर escape sequence का आदान-प्रदान करके संवाद करते हैं
  • login shell detection
  • Python मौजूद है या नहीं इसकी जांच
  • directory बदलना
  • file upload
  • command execution

PTY कैसे काम करता है

• आधुनिक terminal emulator पुराने hardware terminal का software version हैं, जो screen output, keyboard input, और terminal control sequence की interpretation संभालते हैं
• shell और command-line program आज भी ऐसे device की अपेक्षा करते हैं जो असली terminal जैसा दिखे, इसलिए OS PTY उपलब्ध कराता है
  • PTY, terminal emulator और foreground process के बीच स्थित pseudoterminal होता है
• सामान्य SSH session में iTerm2 bytes को PTY में लिखता है, foreground process ssh उन्हें remote machine तक पहुंचाता है, और remote conductor उन्हें stdin से पढ़ता है
• iTerm2 जब remote conductor को command भेजता है, तो local स्तर पर अंततः वह PTY में bytes लिखने का ही काम करता है

conductor protocol

• SSH integration protocol का transport terminal escape sequence पर आधारित है
• इसमें दो मुख्य तत्व हैं
  • DCS 2000p का उपयोग SSH conductor को hook करने के लिए होता है
  • OSC 135 का उपयोग pre-framer conductor message के लिए होता है
• source स्तर पर DCS 2000p iTerm2 को conductor parser बनाने के लिए प्रेरित करता है, और उसके बाद parser OSC 135 message को process करता है
  • begin <id>
  • command output lines
  • end <id> <status> r
  • unhook
• सामान्य remote conductor सिर्फ terminal output के जरिए iTerm2 से संवाद कर सकता है

मुख्य भेद्यता

• इस vulnerability का सार trust failure है: iTerm2, भरोसेमंद conductor session न होने पर भी terminal output को SSH conductor protocol की तरह स्वीकार कर लेता है
• नतीजतन untrusted terminal output remote conductor का रूप धर सकता है
  • malicious file
  • server response
  • banner
  • MOTD
• attack input forged DCS 2000p hook और forged OSC 135 response output कर सकता है, और तब iTerm2 ऐसे व्यवहार करता है मानो असली SSH integration exchange चल रहा हो

exploit कैसे काम करता है

• exploit file में fake conductor transcript शामिल होता है
• जब user cat readme.txt चलाता है, iTerm2 फाइल को render करता है, लेकिन फाइल में साधारण text नहीं बल्कि ये तत्व मौजूद होते हैं
  • fake conductor session का संकेत देने वाली fake DCS 2000p line
  • iTerm2 request का जवाब देने वाले fake OSC 135 message
• hook स्वीकार होते ही iTerm2 सामान्य conductor workflow शुरू कर देता है, और upstream source में Conductor.start() तुरंत getshell() भेजने के बाद, सफलता मिलने पर pythonversion() भेजता है
• attack को इन requests को inject करने की जरूरत नहीं पड़ती; iTerm2 खुद request जारी करता है, और malicious output को केवल responses की नकल करनी होती है

state machine की प्रगति

• fake OSC 135 message कम-से-कम लेकिन सटीक क्रम में बनाए जाते हैं
  • getshell के command body की शुरुआत
  • shell detection output जैसा दिखने वाली line return करना
  • उस command का successful end
  • pythonversion के command body की शुरुआत
  • उस command का failed end
  • unhook
• सिर्फ इस flow से भी iTerm2 सामान्य fallback path में प्रवेश कर जाता है, और फिर यह मान लेता है कि SSH integration workflow पर्याप्त रूप से पूरा हो चुका है, इसलिए वह अगले चरण पर बढ़ता है
• अगला चरण run(...) command को बनाकर भेजने का है

sshargs की भूमिका

• forged DCS 2000p hook में कई field शामिल होते हैं, जिनमें attacker-controlled sshargs भी मौजूद होता है
• बाद में iTerm2 जब conductor का run ... request बनाता है, तब यह मान command material के रूप में इस्तेमाल होता है
• exploit ऐसा sshargs चुनता है कि iTerm2 जब नीचे दिया data base64 encode करे
  • run <padding><magic-bytes>
• तब आखिरी 128-byte chunk ace/c+aliFIo बन जाए
• यह string कोई मनमाना मान नहीं, बल्कि इसे इस तरह चुना गया है कि यह एक साथ दो शर्तें पूरी करे
  • conductor encoding path का valid output
  • valid relative pathname

PTY भ्रम जो exploit को संभव बनाता है

• सामान्य SSH integration session में iTerm2 base64-encoded conductor command को PTY में लिखता है, और ssh उसे remote conductor तक पहुंचाता है
• exploit की स्थिति में भी iTerm2 वही command PTY में लिखता है, लेकिन असली SSH conductor न होने के कारण local shell उसे plain-text input की तरह प्राप्त कर लेता है
• रिकॉर्ड किए गए session में निम्न रूप दिखाई देता है
  • getshell base64 रूप में दिखता है
  • pythonversion base64 रूप में दिखता है
  • उसके बाद लंबा base64-encoded run ... payload आता है
  • आखिरी chunk ace/c+aliFIo होता है
• पहले वाले chunk अर्थहीन command की तरह fail हो जाते हैं, जबकि आखिरी chunk तब काम करता है जब वह path local में मौजूद हो और executable हो

पुनरुत्पादन प्रक्रिया

• मूल file-based PoC को genpoc.py से reproduce किया जा सकता है
  • python3 genpoc.py
  • unzip poc.zip
  • cat readme.txt
• इस प्रक्रिया से ये दो फाइलें बनती हैं
  • ace/c+aliFIo नाम का executable helper script
  • malicious DCS 2000p और OSC 135 sequence वाली readme.txt
• पहली फाइल iTerm2 को fake conductor से संवाद करने के लिए उकसाती है, और दूसरी फाइल आखिरी chunk पहुंचने पर shell को वास्तव में चलाने के लिए target देती है
• exploit के सफल होने के लिए cat readme.txt को उसी directory में चलाना होगा जहां ace/c+aliFIo मौजूद हो, ताकि आखिरी attacker-crafted chunk सचमुच executable path के रूप में इंटरप्रेट हो सके

खुलासा और patch timeline

• 30 मार्च को iTerm2 को bug report किया गया
• 31 मार्च को commit a9e745993c2e2cbb30b884a16617cd5495899f86 में fix पूरा किया गया
• लेखन के समय तक यह fix अभी stable release में शामिल नहीं था
• patch commit के बाद, केवल patch को आधार बनाकर शुरुआत से exploit फिर से बनाने की कोशिश की गई
  • इस प्रक्रिया के prompt prompts.md में हैं
  • परिणाम genpoc2.py है
  • यह genpoc.py से बहुत मिलते-जुलते तरीके से काम करता है

खुलासे के समय पर सवाल

• stable release तक fix पहुंचने से पहले disclosure होने के कारण, ज्यादातर users के लिए वास्तविक सुरक्षा उपलब्ध न होने की स्थिति में vulnerability सार्वजनिक हो गई
• ऐसे disclosure timing के टकराव के लिए स्पष्ट औचित्य जरूरी है
• 2 हफ्ते न तो सार्थक rollout की उम्मीद के लिए काफी हैं, और न ही इतनी जल्दी disclosure करके response मजबूर करने के औचित्य के लिए
• नतीजतन vulnerability तो व्यापक रूप से ज्ञात हो गई, लेकिन fix व्यवहारिक रूप से जिन users को चाहिए था उन्हें अभी तक नहीं मिला, यानी एक public exposure gap बन गया
• बेहतर विकल्प यह हो सकता था कि fix सचमुच users तक पहुंचने तक इंतजार किया जाता, या फिर यह साफ बताया जाता कि जल्दी खुलासा क्यों जरूरी था, लेकिन दोनों में से कोई भी शर्त पूरी नहीं हुई