अगर आप 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 तक पहुंचने तक इंतजार किया जाता, या फिर यह साफ बताया जाता कि जल्दी खुलासा क्यों जरूरी था, लेकिन दोनों में से कोई भी शर्त पूरी नहीं हुई

[GN⁺]

Hacker News की राय

• यह समझ नहीं आया कि स्थिर रिलीज़ के लिए अभी तक patch नहीं आया था, फिर इसे अभी सार्वजनिक क्यों किया गया। upstream को रिपोर्ट हुए सिर्फ़ 18 दिन हुए थे, और ब्लॉग पोस्ट सार्वजनिक commit से कहीं ज़्यादा विस्तार में थी, इसलिए लगा कि इससे वास्तविक दुरुपयोग की संभावना बढ़ी। लेखक ने यह दिखाया कि सिर्फ़ upstream commit के आधार पर भी LLM का इस्तेमाल करके exploit बनाया जा सकता था, लेकिन फिर भी मुझे लगा कि इस पोस्ट ने vulnerability की visibility और बढ़ा दी

  • मैं vulnerability खोजने वाला नहीं, बल्कि ब्लॉग लेखक हूँ। सिर्फ़ upstream commit से भी exploit बनाया जा सकता था, और मेरा मानना है कि iTerm2 commits पर नज़र रखने वाला कोई भी व्यक्ति ऐसा कर सकता था। इरादा इस vulnerability की visibility बढ़ाने का था, और वैसा हुआ भी। iTerm2 के लेखक ने पहले इसे इतना गंभीर नहीं माना कि emergency release की ज़रूरत पड़े, लेकिन अब लगता है कि वे इस पर फिर से विचार कर रहे हैं
  • अगर वास्तविक active exploitation का संदेह हो, या fix पहले से git commit की तरह सार्वजनिक हो और उससे तेज़ी से exploit बन सकना संभव हो, तो disclosure delay के अपवाद होने चाहिए। ऐसी स्थिति में community अक्सर vulnerability disclosure को ही पसंद करती है
  • मेरा मानना है कि commit सार्वजनिक होते ही राज़ खत्म हो जाता है। बेवजह चुप रहने से सिर्फ़ attackers की मदद होती है और defenders की security कमज़ोर पड़ती है
  • पारंपरिक disclosure embargo period शायद AI की वजह से धीरे-धीरे अर्थ खो देगा। अगर सस्ते public models भी vulnerabilities ढूँढ सकते हैं, तो यह मानना स्वाभाविक है कि attackers भी वही तरीका पहले ही अपना चुके होंगे
  • लगा कि यह bug मेरे update window छोटा करने वाले तर्क को मज़बूत करता है। बहुत कठिन bugs शायद पहले Claude जैसे मज़बूत models ढूँढें, लेकिन patch git पर आते ही छोटे models भी उन्हें आसानी से फिर से खोज लेंगे। अगले 1-2 साल में commit public होने से लेकर वास्तविक port scan शुरू होने तक का अंतर कुछ घंटों, बल्कि कुछ मिनटों तक सिमट जाए तो हैरानी नहीं होगी। इस मामले में closed SaaS फ़ायदेमंद है, क्योंकि changes दिखाई नहीं देते और deploy के बाद जान लेने पर भी बहुत व्यावहारिक लाभ नहीं मिलता

• यह काम शानदार है, लेकिन बहुत चौंकाने वाला नहीं। feature-rich terminal apps में यह समस्या बार-बार दिखी है, और पिछले 15 साल में ऐसी कई vulnerabilities सामने आ चुकी हैं। less या vim जैसे tools भी अपवाद नहीं रहे, और इन समस्याओं में से काफ़ी memory safety से कम, logic bug से ज़्यादा जुड़ी होती हैं, इसलिए सिर्फ़ Rust में rewrite करने से वे अपने-आप हल नहीं होंगी। एक तरफ़ हम चाहते हैं कि OS-स्तर के tools सरल और predictable हों, दूसरी तरफ़ सुंदर colors, animation और अंतहीन customization भी चाहते हैं। अब जब AI agents भी आ गए हैं, तो हम उस दौर में पहुँच रहे हैं जहाँ किसी malicious text file में सिर्फ़ "ignore previous instructions" जैसा वाक्य होना भी काफ़ी हो सकता है

  • मेरे हिसाब से iTerm2 का मसला, prompt injection, SQL injection और XSS आखिरकार एक ही तरह की गलती हैं। असली समस्या यह है कि in-band data और out-of-band control data को एक ही stream में मिला दिया जाता है। अगर हम इस pattern को warning sign की तरह पहचानना सीखें, तो user content के बगल में control commands यूँ ही घुसा देने की आदत कम होगी
  • समस्या का एक हिस्सा शायद पुराने interfaces में है। ऐसे modern terminal API की ज़रूरत है जो in-band command sequences पर निर्भर न हो, और GUI की तरह programmable होते हुए भी पुराने remote terminal जैसी सरल usability बनाए रखे
  • सोचा कि Claude Code जैसे rich terminal UI में भी ऐसी vulnerabilities हैं या नहीं। text-based terminal protocol के ऊपर जबरन features चढ़ाने के बजाय, शुरुआत से ही types और semantics साफ़ रखने वाले GUI protocol के रूप में डिज़ाइन करना बेहतर हल लगता है। तभी user data और core UI code को मिलाकर interpret करने से बचा जा सकता है। लेकिन व्यवहार में economics की वजह से नया protocol लाने के बजाय पुराने को सुधारना ज़्यादा चुना जाता है
  • HAL 9000 वाला मज़ाक याद आ गया: "माफ़ कीजिए डेव, मैं यह अनुमति नहीं दे सकता"
  • याद है कि पहले xterm में भी window title escape code का दुरुपयोग करके ऐसा हमला संभव था

• PDP-10 के ज़माने की बात याद आ गई। एक सहकर्मी ने पता लगाया था कि अगर backspace लगातार दबाते रहो तो terminal handler buffer की शुरुआत से पहले के characters भी मिटा देता था, और आगे चलकर एक पूरी लाइन मिटाने वाले escape character का उपयोग करने पर OS ही क्रैश हो जाता था

  • यह सुनकर Real Life Tron on an Apple IIgs याद आ गया, और ऐसा लगा कि system memory के ग़लत interpretation में एक अजीब-सी आकर्षण होती है
  • line-kill के लिए control+u का उपयोग शायद अपेक्षाकृत नई आदत है। पहले @ line-kill और # erase होता था, और आज भी systems के बीच key behavior काफ़ी अलग महसूस होता है

• 6 साल पहले भी लगभग यही iTerm2 security issue था

  • इसलिए लगा कि जैसे कुछ सीखा ही नहीं गया

• मैं iTerm2 का लेखक हूँ। यह issue exploit chain की एक कड़ी के रूप में इस्तेमाल हो सकता है, लेकिन title की तरह इसे अकेले ही बहुत बड़े ख़तरे के रूप में पेश करना बढ़ा-चढ़ाकर कहना है। मैं अभी family trip पर हूँ और लौटकर fix release जारी करूँगा

  • मैं vulnerability finder नहीं, ब्लॉग लेखक हूँ। fix release निकालने के लिए धन्यवाद। यह देखकर हैरानी हुई कि यह bug आम और harmless दिखने वाले workflows को भी प्रभावित कर रहा था, फिर भी कोई official release नहीं था, और patch commit में इसे hypothetical जैसा बताया गया था, इसलिए मैं दिखाना चाहता था कि मामला वैसा नहीं है। fix release निकालने का फ़ैसला स्वागतयोग्य है
  • मैं iTerm2 का आभारी उपयोगकर्ता हूँ। जवाब देने के लिए धन्यवाद, और आपकी छुट्टी अच्छी गुज़रे
  • मुझे iTerm2 सच में बहुत पसंद है, धन्यवाद

• bootstrap scripts, remote conductor agent, escape sequences वगैरह का उपयोग करने वाले complex systems में ऐसा subtle bug आना चौंकाने वाला नहीं। components को उस तरह इस्तेमाल करने पर जिसके लिए वे मूल रूप से बने नहीं थे, ऐसी समस्याएँ आसानी से आ जाती हैं। समझ यह है कि text files या server banners जैसी स्क्रीन पर दिखने वाली untrusted output में special codes हों, तो संरचना उन्हें source verify किए बिना ही process कर देती है

• यह पहले सुनी हुई कहानी जैसा लगा। iTerm2 की SSH integration पहले भी किसी CVE का कारण रही थी, और CVE-2025-22275 भी याद आया। पहले भी ऐसे मामले रहे हैं, और इस thread में जिस पुराने issue का ज़िक्र हुआ वह tmux integration से जुड़ा था। शायद ऐसी integration features को थोड़ा कम आक्रामक तरीके से जोड़ना बेहतर होगा

  • ghostty की SSH integration approach को लेकर भी ऐसी ही चिंता है। बेहतर होगा कि upstream ncurses के साथ मिलकर terminfo को सुधारा जाए
  • ऐसा बार-बार होता आया है

• title बहुत sensational है। समस्या बिल्ली नहीं, iTerm की SSH integration है, और data stream से अलग न होने वाला control channel ढाँचा ही ख़तरनाक लगता है। अगर यह feature इस्तेमाल न किया जाए और सिर्फ़ सामान्य SSH इस्तेमाल हो, तो ज़्यादातर स्थिति में ठीक होना चाहिए

  • इसलिए HN title को थोड़ा नरम शब्दों में बदल दिया गया

• पुराने terminal emulators escape codes के ज़रिए keyboard rebinding तक की अनुमति देते थे। इसलिए untrusted files को cat करने के बजाय less जैसे tools में खोलना लगभग सामान्य समझ माना जाता था

  • याद है कुछ terminals में सिर्फ़ escape sequence से file write करना या program run करना भी संभव था। आज भी arbitrary bytes को सीधे terminal stream में बहने न देना पूरी तरह उचित सलाह है

• लेख की wording सटीक नहीं है। दूसरा paragraph ऐसा पढ़ा जाता है जैसे "iTerm2 इस्तेमाल करना सुरक्षित नहीं है", जबकि अधिक सटीक बात यह होगी कि optional Shell Integration feature का उपयोग करने पर समस्या आ सकती है। अगर यह feature default से disabled है, तो असर का दायरा सीमित माना जा सकता है। अगर मैं ग़लत हूँ तो सुधार चाहूँगा

  • एक वाक्य की अतिशयोक्ति की वजह से पूरे लेख को बेकार कहना ज़्यादा है
  • वह feature default से enabled था, और इसे सीधे जाँचकर पुष्टि की जा सकती है