GNU Screen में मिली कई सुरक्षा समस्याएँ

• GNU Screen 5.0.0 और setuid-root इंस्टॉलेशन में गंभीर सुरक्षा कमजोरियाँ पाई गईं
• लोकल root privilege escalation, TTY hijacking, world-writable PTY बनना आदि प्रमुख मुद्दे हैं
• कई Linux और UNIX distributions आंशिक या पूर्ण रूप से प्रभावित हैं
• अस्थायी patch उपलब्ध है और कई distributions में प्राथमिकता के आधार पर कार्रवाई की आवश्यकता है
• Screen की setuid-root डिज़ाइन में ही मूलभूत सुरक्षा जोखिम मौजूद है

---

1. परिचय

• जुलाई 2024 में Screen के upstream maintainer ने code review अनुरोध किया, जिसके बाद सुरक्षा समीक्षा शुरू हुई
• पहले कोई खास समस्या नहीं मिली थी, लेकिन इस बार Screen 5.0.0 में setuid-root कॉन्फ़िगरेशन के दौरान गंभीर root privilege escalation कमजोरी मिली
• इसके अतिरिक्त, पुराने versions (4.9.1 आदि) को भी प्रभावित करने वाली कई अपेक्षाकृत हल्की सुरक्षा कमजोरियाँ मिलीं
• रिपोर्ट में version-specific vulnerability patch sets (4.9.1, 5.0.0) संलग्न हैं
• इसमें distribution के अनुसार Screen configuration और version, प्रमुख कमजोरियाँ, setuid-root से जुड़े विकासगत जोखिम, security hardening सिफारिशें, disclosure coordination प्रक्रिया की समस्याएँ, और impact matrix शामिल हैं

2. Screen configuration और version का अवलोकन

• अगस्त 2024 में Screen 5.0.0 रिलीज़ हुआ और Arch Linux, Fedora 42, NetBSD 10.1 में शामिल किया गया
• 5.0.0 में बड़े पैमाने पर refactoring शामिल थी, जिनमें कुछ code 10 साल से भी पुराना था
• कुछ कमजोरियाँ 5.0.0 में नई आईं, जबकि कुछ पुराने versions (4.9.1 आदि) में भी मौजूद थीं
• अधिकांश distributions अभी भी 4.9.1 का उपयोग कर रहे हैं
• Screen multi-user mode केवल setuid-root इंस्टॉलेशन में उपयोग किया जा सकता है, और code की जटिलता के कारण attack surface काफी बढ़ जाता है
• प्रमुख distributions में Arch Linux, FreeBSD, NetBSD Screen को setuid-root के रूप में इंस्टॉल करते हैं; Gentoo में यह केवल “multiuser” USE flag पर setuid-root के रूप में इंस्टॉल हो सकता है

3. सुरक्षा मुद्दों का विवरण

3.a) logfile_reopen() के जरिए लोकल root प्राप्त करना (CVE-2025-23395)

• Screen 5.0.0 को setuid-root के रूप में चलाने पर logfile_reopen() फ़ंक्शन privileges गिराए बिना user-input path पर फ़ाइल बनाता है
• हमलावर root-owned किसी भी फ़ाइल को बनाकर terminal data रिकॉर्ड और उसका दुरुपयोग कर सकता है
• पहले से मौजूद फ़ाइलों का भी दुरुपयोग संभव है; उदाहरण के लिए privileged shell script में code injection जैसे हमले किए जा सकते हैं
• Arch Linux, NetBSD 5.0.0 पूरी तरह संवेदनशील हैं, जबकि Fedora और Gentoo के कुछ environments में आंशिक असर है
• patch secure file handling को बहाल करके लागू किया गया, और distribution के अनुसार प्रभाव अलग-अलग है

3.b) multi-user session attach के समय TTY hijacking (CVE-2025-46802)

• Attach() फ़ंक्शन में multiattach flag सक्रिय होने पर TTY permissions अस्थायी रूप से 0666 कर दी जाती हैं
• इस प्रक्रिया में race condition के कारण तीसरा user उस TTY पर read/write access पा सकता है
• input data snooping, data tampering, password theft जैसी जोखिमें मौजूद हैं
• कुछ code paths में TTY permissions वापस restore भी नहीं होतीं
• patch में chmod 666 manipulation हटाई गई; हालांकि कुछ reconnect use cases टूट सकते हैं, लेकिन वे पहले भी सही से काम नहीं कर रहे थे

3.c) PTY default permissions कमजोरी (CVE-2025-46803)

• 5.0.0 में PTY की default permissions 0620 → 0622 (world-writable) कर दी गईं
• इससे संभावित सुरक्षा जोखिम बढ़ गया, खासकर क्योंकि सभी users दूसरे PTY में लिख सकते हैं
• यह बदलाव गलती से जोड़ा गया लगता है, और patch compile समय safe default (0620) बहाल करके इसे ठीक करता है
• Arch Linux, NetBSD मुख्य रूप से प्रभावित हैं

3.d) socket error message के जरिए फ़ाइल के अस्तित्व की जानकारी लीक होना (CVE-2025-46804)

• SCREENDIR environment variable और Error message का उपयोग करके वास्तविक फ़ाइल/डायरेक्टरी के अस्तित्व की root privileges के साथ पुष्टि की जा सकती है
• यह एक minor information leak है, लेकिन सभी setuid-root इंस्टॉलेशन environments में जोखिम मौजूद है

3.e) signal भेजने में TOCTOU race condition (CVE-2025-46805)

• CheckPid() और Kill() फ़ंक्शनों के बीच समय-अंतर के कारण, इच्छित PID के बजाय किसी दूसरे PID को root privileges के साथ signal भेजे जाने का जोखिम है
• मुख्यतः केवल SIGCONT, SIGHUP आदि की अनुमति है, इसलिए प्रभाव सीमित है, लेकिन denial of service (DoS) या हल्की integrity हानि संभव है

3.f) strncpy() के गलत उपयोग से command transfer के दौरान overflow

• 5.0.0 में strncpy() के गलत उपयोग से buffer overflow और program crash होता है
• यदि इसे सही ढंग से patch न किया जाए, तो command transfer के दौरान MAXPATHLEN के बाद memory overwrite होकर service unavailability हो सकती है
• यह सुरक्षा समस्या नहीं है, लेकिन stability के लिहाज़ से तेज़ी से सुधार जरूरी है

4. setuid-root implementation से जुड़े अतिरिक्त जोखिम

• multi-user mode में multiple user UID handling logic की कमजोरी पाई गई
• setuid-root स्थिति में privilege drop logic पूरी तरह सही नहीं है
• root द्वारा बनाए गए session में effective privilege reduction ठीक से नहीं होती, इसलिए समग्र जोखिम अधिक है

5. सुरक्षा मज़बूती के लिए सामान्य सिफारिशें

• बड़े स्तर के code refactoring के दौरान मौजूदा security logic टूटने की पुष्टि हुई
• setuid-root binaries की प्रकृति को देखते हुए security test suite लाना और सभी filesystem/environment variable handling को conservative तरीके से डिज़ाइन करना ज़रूरी है
• विशेष रूप से full setuid-root execution की सिफारिश नहीं की जाती, और multi-user फीचर को केवल trusted group opt-in तरीके तक सीमित रखना चाहिए
• environment variables (PAH आदि) को केवल trusted paths तक सीमित करना अनिवार्य रूप से enforce किया जाना चाहिए

6. vulnerability disclosure coordination प्रक्रिया की समस्याएँ

• Upstream के साथ coordination प्रक्रिया अप्रभावी रही, जिससे patch development और disclosure में देरी हुई
• Upstream की code understanding और क्षमता सीमित होने के कारण करीबी प्रतिक्रिया कठिन रही
• अंततः distributions की ओर से patch development का नेतृत्व किया गया और समन्वित समय-सारणी के अनुसार रिपोर्ट जारी हुई
• Screen project की maintenance और management क्षमता की कमी भी सामने आई

7. impact matrix

• Arch Linux (5.0.0, setuid-root): 3.a, 3.b, 3.c, 3.d, 3.e, 3.f सभी कमजोरियों से प्रभावित
• Debian/Ubuntu सहित कई distributions: 3.b (आंशिक प्रभाव)
• Fedora 42 (5.0.0, setgid-screen): 3.b (आंशिक प्रभाव), 3.f प्रभावित
• Gentoo (4.9.1, setgid-utmp): 3.b (आंशिक प्रभाव), unstable ebuild + multiuser USE flag पर 5.0.0 जैसा ही प्रभाव
• FreeBSD 14.2 (4.9.1, setuid-root): 3.b, 3.d, 3.e प्रभावित
• NetBSD 10.1 (5.0.0, setuid-root): 3.a, 3.b, 3.c, 3.d, 3.e, 3.f प्रभावित
• OpenBSD 7.7 (4.9.1): 3.b (आंशिक प्रभाव)
• openSUSE TW: 3.b (आंशिक प्रभाव)

8. समयरेखा

• 2024-07-01: upstream से code review अनुरोध प्राप्त हुआ
• 2025-01-08: review शुरू
• 2025-02-07: upstream को निजी रूप से कमजोरियों की रिपोर्ट दी गई, coordinated disclosure का अनुरोध किया गया
• 2025-02~04: patch पर चर्चा चली, embargo अवधि से जुड़े मुद्दों के कारण समय-सारणी फिर से तय की गई
• 2025-05-12: यह रिपोर्ट और आधिकारिक घोषणा जारी की गई

9. संदर्भ लिंक

• GNU Savannah [Screen project page]
• openSUSE Bugzilla, संबंधित patches, संदर्भ CVE, bug reports और दस्तावेज़ links शामिल

[GN⁺]

Hacker News की राय

• Screen में एक multi-user mode है, जो कई users को एक ही session में साथ में connect होने देता है। मेरा मानना है कि इसी feature की वजह से tmate जैसे tools संभव हैं। सोच रहा हूँ कि क्या tmux में भी यही vulnerability है।
  • tmux Unix domain socket का उपयोग करता है। समझ नहीं आता कि screen ने setuid तरीका क्यों अपनाया; इसमें root privileges की ज़रूरत नहीं दिखती। TFA में दी गई व्याख्या के अनुसार, लगता है कि मौजूदा screen developers codebase को पूरी तरह नहीं समझते, इसलिए setuid-root तरीका feature को जल्दी implement करने के लिए चुना गया।
  • यह feature वाकई शानदार है। training sessions में मैं हर student को अपने laptop पर उसका खुद का login account देता हूँ और ssh shell को screen -x <किसी विशेष user की window> तक सीमित कर देता हूँ, ताकि student केवल वही windows इस्तेमाल कर सके जिन्हें उस screen ACL में अनुमति मिली हो। फिर मैं projector पर हर student की screen एक-एक करके देखकर दिखाता हूँ। लेकिन यह security holes से भरा हुआ है, यह सुनकर हैरानी नहीं होती।
  • screen -x command इस्तेमाल करने का अनुभव है।
• Debian में GNU screen setuid root privileges के साथ install नहीं होता।
  • Debian Stable(bookworm) package बहुत पुराना है, इसलिए 5.0.0 vulnerability से प्रभावित नहीं है। पहले मुझे Debian में software versions बहुत धीमे लगने से नफ़रत थी, लेकिन अब मैं केवल कुछ ज़रूरी applications के लिए अलग package sources से नए versions इस्तेमाल करता हूँ, और बाकी चीज़ें पुराने versions के साथ भी ठीक चलती हैं।
  • Gentoo में भी यही स्थिति है, लेकिन Gentoo में utmp group पर SETGID set होता है। इसका क्या मतलब है, यह मुझे ठीक से नहीं पता।
  • Slackware 15 में screen में suid नहीं है।
  • Fedora में यह setuid के साथ install होता दिखता है।
• blog post का rendered version: https://security.opensuse.org/2025/05/12/screen-security-issues.html
• GNU Screen की log file writing feature पर documentation की कमी के बारे में मैंने post के लेखक को email भेजा। मुझे लगता है GNU को एक बेहतर issue tracking system की ज़रूरत है। संबंधित सामग्री: http://www.zoobab.com/screenrc
  • tmux के लेखक के साथ एक Q&A भी था, और 16 साल पहले से documentation की कमी को लेकर शिकायत थी। संबंधित सामग्री: https://undeadly.org/cgi?action=article&sid=20090712190402
• observed behaviour 2005 से Screen में मौजूद था। लंबे समय तक यह एक anti-pattern रहा, और rkhunter जैसे tools ने इसे cover किया। मुझे पूरा यक़ीन है कि 90s में भी screen setuid root था।
• यह आश्चर्य की बात है कि upstream(आधिकारिक development team) इस बार शामिल थी। लगभग 5 साल पहले मुझे लगा था कि GNU screen development पूरी तरह रुक गया है, और यह बात दुखद लगी थी। पता नहीं अब भी ऐसा ही है या नहीं। यह भी जानना चाहता हूँ कि क्या screen में attach किए बिना नई window जोड़ने की सुविधा है।
  • upstream ने SUSE team से review का अनुरोध किया था। development manpower कम है और अभी maintenance भी ठीक से नहीं हो रहा। अगर यह सच है तो अफ़सोस की बात है। tmux जैसे alternatives मौजूद हैं, लेकिन बहुत से लोग लंबे समय से Screen इस्तेमाल करते आए हैं। tools का पुराना पड़ जाना खलता है।
  • उन्होंने बस इसे setuid-root के साथ distribute किया, और involvement उतना ही था। केवल वही distributions vulnerable हैं जो इसे इस तरह configure करते हैं; बाकी प्रभावित नहीं हैं। जब official patches धीमे आते हैं, तो distributions खुद patch कर लेते हैं।
  • मेरा मानना है कि GNU tools का development रुक जाना (bug fixes को छोड़कर) हमेशा बुरी बात नहीं है; यह इस बात का संकेत भी हो सकता है कि features काफ़ी हद तक complete हो चुके हैं।
  • upstream के साथ communication मुश्किल है, इसलिए bug fixes/releases के बारे में विस्तृत जानकारी उपलब्ध नहीं है। security review का अनुरोध किया गया था, लेकिन लगता है संपर्क करना आसान नहीं है।
  • open source में यह समस्या है कि एक software के ख़त्म हो जाने और replacement आ जाने के बाद भी तुरंत switch करने की प्रेरणा कम होती है, इसलिए inertia बनी रहती है। दूसरी ओर, ऐसे मामले भी होते हैं जहाँ केवल trademark खरीदकर चीज़ को पूरी तरह बदल दिया जाता है (Audacity की तरह)। इसका कोई अच्छा समाधान नहीं है।
• rendered version का link: https://security.opensuse.org/2025/05/12/screen-security-issues.html
• सोचता हूँ कि कितने developers सच में सभी popular open source tools को खुद इस्तेमाल करके देखते हैं, और उन tools का उपयोग करने वाले क्षेत्रों में कितना पैसा घूमता है।
• याद पड़ता है कि tmux OpenBSD में 4.6 से default में शामिल था, और इसका audit भी हुआ था। जो लोग security पर थोड़ा ज़्यादा ध्यान देते हैं, उनके लिए यह एक अच्छा alternative है।
  • screen का ज़िक्र देखकर मुझे याद आया कि मैंने पहले tmux पर switch किया था, और फिर गलती से screen का इस्तेमाल न करने के कारण भ्रम हुआ था।
• screen और setuid का साथ में ज़िक्र दिलचस्प है। एक बार किसी अजीब issue को ठीक करने के लिए मैंने screen पर chmod u+s लगाया था। ऐसा करना अपने-आप में अटपटा लगा। लेकिन बाद में पता चला कि screen में कुछ features setuid पर निर्भर थे, और कुछ systems इसे default रूप से ऐसे ही distribute करते हैं। और u+s देने के बाद screen ने मेरे ~/.screenrc की जगह root का ~/.screenrc पढ़ा (मैंने इसे अस्थायी workaround मान लिया)। मुझे लगता है कि screen के अलग-अलग builds में setuid support अलग हो सकता है।
  • setuid मूल रूप से ऐसे ही काम करता है। binary पर special bit set करने का मतलब है कि उसे हमेशा दिए गए user के रूप में run किया जाए।