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

 (openwall.com)
2 पॉइंट द्वारा GN⁺ 2025-05-14 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • GNU Screen सुरक्षा समीक्षा में Screen 5.0.0 और setuid-root इंस्टॉलेशन पर केंद्रित होकर local privilege escalation, TTY hijacking, information disclosure, signal भेजने की race condition, और command भेजने पर crash की पुष्टि हुई
  • सबसे गंभीर CVE-2025-23395 में logfile_reopen() user-provided path को root privileges के साथ process करता है, जिससे किसी भी location पर root-owned file बनाई जा सकती है या मौजूदा file में logs append किए जा सकते हैं
  • multiuser mode का पुराना behavior भी समस्या के रूप में सामने आया; Attach() TTY को अस्थायी रूप से 0666 में बदलता है, जिससे दूसरे users के read/write और input injection की संभावना बनती है
  • distribution-wise risk installation method पर निर्भर करता है; Arch Linux और NetBSD 10.1 Screen 5.0.0 को setuid-root के रूप में provide करते हैं, इसलिए major vulnerabilities से काफी प्रभावित हैं
  • मौजूदा recommendation है कि Screen को setuid-root के रूप में install न किया जाए; multiuser feature के लिए trusted group-based opt-in, default privilege dropping, limited privilege escalation, और environment variable cleanup की जरूरत है

सार्वजनिक पृष्ठभूमि और patches

  • जुलाई 2024 में upstream Screen maintainer ने current codebase review का अनुरोध किया, और actual security review जनवरी 2025 में शुरू हुआ
  • review में Screen 5.0.0 major update में setuid-root distributions को प्रभावित करने वाला local root exploit मिला
  • इसके अलावा कम severity वाली समस्याएँ भी मिलीं, जिनमें से कुछ कई distributions में मौजूद Screen 4.9.1 और पुराने versions को भी प्रभावित करती हैं
  • समस्याएँ 30 अप्रैल 2025 को distros mailing list पर share की गईं, और 12 मई 2025 को public की गईं
  • report के साथ version-specific patch bundles attach किए गए

Screen configuration और multiuser mode

  • Screen 5.0.0 अगस्त 2024 में upstream से major release के रूप में आया, और Arch Linux, Fedora 42, NetBSD 10.1 यह version provide करते हैं
  • कई Linux और UNIX distributions लिखे जाने के समय अभी भी Screen 4.9.1 का उपयोग करते हैं
  • Screen का multiuser mode उचित credentials होने पर दूसरे user के owned Screen session से attach करने देता है
    • यह feature केवल तब available है जब Screen setuid-root bit के साथ installed हो
    • complex Screen code root privileges के साथ चलता है, इसलिए attack surface बढ़ जाता है
  • review किए गए systems में Arch Linux, FreeBSD, NetBSD Screen को setuid-root के रूप में install करते हैं
  • Gentoo Linux में "multiuser" USE flag set होने पर setuid-root bit apply होता है
  • कुछ distributions setuid के बजाय setgid का use करते हैं
    • Gentoo Linux default setgid-utmp है, जिससे Screen system-wide utmp database में login records बना सकता है
    • Fedora Linux setgid-screen है, जिससे Screen /run/screen की system-wide directory में sockets रख सकता है

CVE-2025-23395: logfile_reopen() local root exploit

  • CVE-2025-23395 तब प्रभावित करता है जब Screen 5.0.0 setuid-root privileges के साथ चलता है
  • logfile_reopen() function user-provided path process करते समय privileges drop नहीं करता
  • unprivileged user किसी भी location पर निम्न properties वाली file बना सकता है
    • owner: root
    • group: caller user का real group
    • file mode: 0644
  • पहले से मौजूद file का भी दुरुपयोग संभव है
    • Screen PTY में लिखा data उस file में append होता है
    • existing file का mode और ownership नहीं बदलता
  • Screen log file पहली बार खोलते समय privileges सही तरह drop करता है, लेकिन जैसे ही वह log file फिर से खोलने की जरूरत मानता है, privilege escalation की संभावना बनती है
  • stolen_logfile() check में original log file का link count 0 हो जाए या size अप्रत्याशित रूप से बदल जाए, तो logfile_reopen() call होता है
  • यह condition unprivileged user जानबूझकर trigger कर सकता है
  • Screen 5.0.0 के लिए patch 0001 log file reopen process में safe file handling वापस introduce करता है
  • यह issue पुराने commit 441bca708bd में lf_secreopen() हटाए जाने से पैदा हुआ, और वह change 5.0.0 release में शामिल था

CVE-2025-46802: multiuser session attach के दौरान TTY hijacking

  • CVE-2025-46802 multiattach flag set होने पर Attach() function में होता है
  • Screen multiuser session attach करते समय current TTY के लिए chmod() से mode को 0666 में बदलता है
  • TTY path /dev के नीचे है या नहीं और isatty() conditions आदि से validate होता है, इसलिए सिर्फ यह behavior अलग से local root exploit नहीं बनता
  • समस्या यह है कि TTY permissions अस्थायी रूप से relaxed रहने के दौरान दूसरे users उस TTY को read/write कर सकते हैं, यानी race condition बनती है
  • Linux inotify API based simple test में Python script हर दो-तीन attempts में affected TTY खोल पा रही थी
  • attacker ये कर सकता है
    • TTY में enter किया जा रहा data intercept करना
    • TTY में data inject करना
    • user को password enter करने के लिए mislead करना
    • control sequences inject करके victim को confuse करना या related terminal emulator issues को target करना
  • Attach() के कुछ return paths में original TTY mode restore नहीं होता
    • उदाहरण: target session नहीं मिला और "quiet" argument set है
  • patches temporary chmod() हटाते हैं
    • Screen 4.9.1 के लिए patch 0001
    • Screen 5.0.0 के लिए patch 0004
  • public disclosure से ठीक पहले यह पता चला कि यह patch कुछ reattach use cases तोड़ सकता है, लेकिन वे use cases Screen 4.9.1 में भी पहले से broken थे
  • यह issue कम से कम 2005 से Screen versions में मौजूद था, और setuid-root के साथ multiuser support provide करने वाले Linux distributions और BSD को प्रभावित करता है
  • setuid-root न होने पर भी user को अपने TTY का mode बदलने की permission होती है, इसलिए theoretically impact है, लेकिन Screen दूसरे user के session में root privileges के बिना आगे नहीं बढ़ता

CVE-2025-46803: Screen 5.0.0 में world-writable PTY default

  • CVE-2025-46803 Screen 5.0.0 में Screen द्वारा allocate किए जाने वाले PTY का default mode 0620 से 0622 में बदलने की समस्या है
  • इस default में system में कोई भी Screen PTY पर write कर सकता है
  • security के लिहाज से CVE-2025-46802 जैसी समस्या बनती है, लेकिन information leak वाला हिस्सा नहीं है
  • Screen 4.9.1 में code-level default 0622 था, लेकिन autotools configuration का default 0620 apply होकर safe default use होता था
  • Screen 5.0.0 में configure.ac rewrite होने से autoconf-level 0620 default गायब हो गया, और बाद में pty-mode configure switch default 0622 के साथ फिर से introduce हुआ
  • 5.0.0 release notes नहीं मिले और ChangeLog में केवल कुछ entries थीं; PTY mode default change intentional decision नहीं लगता
  • Screen 5.0.0 के लिए patch 0002 configure.ac में safe default PTY mode restore करता है
    • change apply करने के लिए autoreconf चलाना जरूरी है
  • packagers को --with-pty-mode=0620 configure switch explicitly pass करने की recommendation है
  • Gentoo Linux और Fedora Linux safe --with-pty-mode explicitly pass करते हैं
  • Arch Linux और NetBSD यह switch pass नहीं करते, इसलिए नया default apply होता है और वे vulnerable हैं

CVE-2025-46804: socket path error message से file existence disclosure

  • CVE-2025-46804 Screen के setuid-root privileges के साथ चलने पर होने वाला minor information disclosure है
  • older Screen versions और 5.0.0 दोनों में confirmed है
  • Screen SocketPath को root privileges के साथ check करता है, और unprivileged user को सामान्यतः न पता चलने वाली path information error message में expose करता है
  • SCREENDIR environment variable का उपयोग करके निम्न जानकारी infer की जा सकती है
    • /root/.lesshst regular file है या नहीं
    • /root/.cache directory मौजूद है या नहीं
    • /root/test path मौजूद नहीं है या नहीं
  • patches setuid-root installation में target path process के real UID द्वारा controlled न होने पर केवल generic error message output करने के लिए बदलते हैं
    • Screen 4.9.1 के लिए patch 0002
    • Screen 5.0.0 के लिए patch 0005
  • review किए गए सभी distributions प्रभावित हैं

CVE-2025-46805: signal sending TOCTOU race condition

  • CVE-2025-46805 setuid-root context में user-provided PID को signal भेजते समय बनने वाली TOCTOU race condition है
  • CheckPid() real user ID से privileges lower करने के बाद check करता है कि kernel target PID को signal भेजने की अनुमति देता है या नहीं
  • actual signal बाद में Kill() के जरिए भेजा जाता है, और उस समय root privileges use हो सकते हैं
  • check और actual sending के बीच पहले check किया गया PID किसी दूसरे privileged process से replace हो सकता है
  • privileged Screen daemon process को खुद को signal भेजने के लिए trick करने की possibility भी है
  • अभी केवल SIGCONT और SIGHUP भेजे जा सकते हैं, इसलिए impact local denial of service या minor integrity violation के क्षेत्र में रहने की संभावना ज्यादा है
  • यह issue CVE-2023-24626 के incomplete fix से आया
    • उस fix से पहले race condition के बिना भी arbitrary processes को ये signals भेजे जा सकते थे
  • patches actual signal को भी CheckPid() की तरह real UID privileges से भेजने के लिए बदलते हैं
    • Screen 4.9.1 के लिए patch 0003
    • Screen 5.0.0 के लिए patch 0006
  • review किए गए सभी distributions प्रभावित हैं

Screen 5.0.0 में strncpy() usage के कारण command sending crash

  • Screen 5.0.0 में strncpy() से जुड़ी समस्या है जिसे security issue नहीं माना गया, लेकिन priority से fix करना चाहिए
  • commit 0dc67256 में कई strcpy() calls को strncpy() से replace किया गया
  • strncpy() safe string handling के लिए function नहीं, बल्कि fixed-length buffer को zero-padding करने वाला function है; इसलिए पहले \0 byte के बाद भी target buffer के end तक 0 लिखता है
  • attacher.c के command-line argument processing loop में पहले iteration के बाद भी MAXPATHLEN को destination size के रूप में pass किया जाता है
  • pointer p पहले ही बढ़ चुका होने पर भी वही size pass करने से बाद के strncpy() calls buffer end से आगे \0 bytes लिखते हैं
  • Arch Linux पर running Screen session को एक से ज्यादा command arguments भेजने पर _FORTIFY_SOURCE enabled build में निम्न error observe हुआ
    • *** buffer overflow detected***: terminated
    • Aborted (core dumped)
  • _FORTIFY_SOURCE न हो तो visible error नहीं हो सकता, और -fsanitize=address में भी error नहीं दिख सकता
  • caller cmd buffer के बाद के MAXPATHLEN bytes को 0 से overwrite कर सकता है, लेकिन उसके बाद same size का writeback[MAXPATHLEN] buffer है, इसलिए attacker के लिए इसे लाभकारी रूप से exploit करने की संभावना नहीं मानी गई
  • Screen 5.0.0 के लिए patch 0003 strncpy() को snprintf() से बदलता है और remaining target buffer size सही-सही pass करता है
  • Screen 5.0.0 provide करने वाले सभी distributions प्रभावित हैं

distribution-wise impact scope

system Screen version special privileges impact
Arch Linux 5.0.0 setuid-root 3.a, 3.b, 3.c, 3.d, 3.e, 3.f
Debian 12.10 4.9.0 none 3.b partial
Ubuntu 24.04.2 4.9.1 none 3.b partial
Fedora 42 5.0.0 setgid-screen 3.b partial, 3.f
Gentoo 4.9.1 setgid-utmp, multiuser USE flag set होने पर setuid-root 3.b partial
openSUSE TW 4.9.1 none 3.b partial
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 none 3.b partial

setuid-root design पर चिंताएँ और recommendations

  • Screen multiuser mode में तीन UID शामिल होते हैं
    • privileged operation के लिए effective UID 0
    • session बनाने वाले user का real UID
    • session से attach करने वाले user का real UID
  • मौजूदा Screen code इस distinction को ठीक से reflect करने के लिए मुश्किल structure वाला लगता है
  • root द्वारा बनाया गया Screen multiuser session session creator के real UID, यानी 0, पर “privilege drop” करता है, इसलिए practically privilege drop होता ही नहीं
  • Screen 5.0.0 के refactoring process में लंबे समय से मौजूद security logic टूट गया, और इसके परिणामस्वरूप CVE-2025-23395 और CVE-2025-46803 हुए
  • further refactoring से पहले implementation की security properties verify करने के लिए test suite की जरूरत है
  • setuid-root binaries पर काम करने वाले developers को इस area के risks समझने चाहिए
  • Screen elevated privileges के साथ चलता रहता है और केवल जिन operations को risky मानता है, उनमें selectively privileges lower करता है
  • robust setuid-root program को default रूप से privileges lower करने चाहिए, और केवल सच में elevated privileges की जरूरत वाले operations में privileges raise करने चाहिए
  • setuid-root context में explicitly allowed environment variables छोड़कर बाकी हटाने की logic जरूरी है
  • PATH जैसे environment variables को trusted system directories की ओर ही point करने के लिए sanitize करना चाहिए
  • फिलहाल Screen 5.0.0 ही नहीं, पुराने 4.9 series को भी setuid-root के रूप में install न करने की recommendation है
  • alternative के रूप में multiuser feature को opt-in mode में provide किया जा सकता है, और केवल trusted group members को multiuser version Screen run करने दिया जा सकता है

public coordination process और upstream status

  • फरवरी 2025 में Screen upstream को privately issues report किए गए और coordinated disclosure propose किया गया
  • upstream ने public disclosure से पहले bug fixes के लिए issues private रखने में interest दिखाया और 1–2 महीने चाहिए बताए
  • करीब एक महीने बाद upstream side activity और patch discussion शुरू हुए, लेकिन discussion पर्याप्त productive नहीं था
  • अधिकतम 90-day embargo period करीब आने तक further communication नहीं हुआ, और इस बीच NetBSD जैसे distributions Screen 5.0.0 में update होकर CVE-2025-23395 से fully प्रभावित हो गए
  • यह judgment बना कि upstream Screen codebase से पर्याप्त परिचित नहीं है और reported security issues को पूरी तरह समझ नहीं पा रहा
  • upstream कुछ issues unresolved रहते हुए earlier disclosure चाहता था, इसलिए draft तेजी से distros mailing list को भेजा गया
  • इसके बाद SUSE side ने missing fixes खुद develop किए, और upstream में draft form में discuss किए गए patches को भी adjust और document किया
  • dedicated upstream capacity होती तो coordinated disclosure process करीब 2 सप्ताह में complete हो सकता था, ऐसा माना गया
  • Screen upstream staffing और expertise की कमी से जूझता दिखता है, और widely used open-source utility होने के कारण यह बड़ी चिंता है

key timeline

  • 2024-07-01: upstream का review request मिला
  • 2025-01-08: security review work शुरू
  • 2025-02-07: Screen upstream को private report और coordinated disclosure proposal
  • 2025-02-11: GNU Savannah bug tracker में private bug create हुआ
  • 2025-04-30: CVE assignment decision और distros mailing list पर draft share
  • 2025-05-07: Screen 4.9.1 और 5.0.0 के लिए final patches distros mailing list और upstream से share किए गए
  • 2025-05-12: report blog और oss-security mailing list पर public हुई

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

1 टिप्पणियां

 
GN⁺ 2025-05-14
Hacker News की राय

  • मुझे पता नहीं था कि Screen में ऐसा multi-user mode है, लेकिन शायद इसी feature की वजह से tmate जैसे tools संभव होते हैं
    सही credentials हों तो आप किसी दूसरे user के owned Screen session से जुड़ सकते हैं, और कहा जाता है कि यह feature सिर्फ तब संभव है जब Screen setuid-root के रूप में install हो
    इसलिए सोच रहा हूं कि क्या tmux भी इसी तरह की vulnerability से प्रभावित होता है

    • tmux Unix domain sockets इस्तेमाल करता है, इसलिए यह लागू नहीं होता
      मुझे नहीं पता screen ने यहां setuid तरीका क्यों चुना; root privileges की कोई जरूरत नहीं लगती
      article के नीचे एक plausible explanation है कि मौजूदा screen developers codebase से पूरी तरह familiar नहीं हैं; अगर ऐसा है, तो feature को काम कराने का सबसे आसान तरीका setuid-root रहा होगा
    • यह काफी शानदार feature है
      education sessions में मैंने हर student को अपने laptop पर login account दिया था, SSH shell को screen -x तक restrict किया था, और screen की access control list से हर student को सिर्फ अपनी window इस्तेमाल करने दी थी
      practical के दौरान मैं, screen owner के रूप में, हर student की screen projector पर दिखा सकता था ताकि पूरी class results देख सके
      इसमें security holes ज्यादा हों तो हैरानी नहीं होगी
    • सही, screen -x

  • Debian में GNU screen setuid-root privileges के साथ install नहीं होता

    • Debian Stable, यानी bookworm का package इतना पुराना है कि 5.0.0 vulnerability से प्रभावित नहीं है
      पहले मुझे हमेशा बुरा लगता था कि Debian में software versions पीछे रह जाते हैं, लेकिन अब browser जैसी कुछ apps को छोड़कर—जिनमें मैं सचमुच बहुत पुराने software पर depend नहीं करना चाहता—बाकी के लिए मैं पुराने packages के साथ ठीक हूं और सिर्फ उन कुछ apps के लिए अलग package sources इस्तेमाल करता हूं
    • Slackware 15 में /usr/bin/screen screen-4.9.0 की ओर point करता है, और executable भी suid नहीं है
    • Gentoo में भी यही है
      हालांकि Gentoo में utmp group के लिए SETGID लगा है, लेकिन इसका असर क्या है मुझे ठीक से नहीं पता
    • Fedora में यह setuid-root दिखता है

  • Rendered blog post यहां है: https://security.opensuse.org/2025/05/12/screen-security-iss...

  • मैंने GNU Screen author को email किया था कि file logging feature की documentation ठीक से नहीं है: http://www.zoobab.com/screenrc
    GNU को बेहतर issue tracking system की जरूरत है

    • Tmux author के साथ एक Q&A था, और करीब 16 साल पहले भी वे documentation की कमी की शिकायत कर रहे थे
      https://undeadly.org/cgi?action=article&sid=20090712190402
    • GNU screen manual में यह विस्तार से documented है: https://www.gnu.org/software/screen/manual/screen.html#Log
    • कई पुराने projects में issue यह है कि बातें unindexed mailing lists की अंतहीन गहराइयों में दब जाती हैं
      Discord को ऐसी जानकारी inaccessible बनाने के लिए criticise करना सही है, लेकिन कुछ projects अभी भी जो IRC इस्तेमाल करते हैं, वह असल में उससे दुगना खराब है
      अच्छा होगा कि ऐसे projects Gitea, Forgejo, Codeberg, GitLab, GitHub जैसी जगहों पर move करें, ताकि related content एक जगह आए और discoverability मिले

  • Zellij, screen और tmux का modern alternative के रूप में काफी अच्छा है; defaults भी बढ़िया हैं और UI को आसानी से discover करने लायक बनाया गया है
    जिन लोगों को terminal multiplexer का effort बनाम payoff अस्पष्ट लगता था, उन्हें recommend करूंगा
    https://zellij.dev
    https://github.com/zellij-org/zellij

    • कुछ साल पहले इस्तेमाल किया था, काफी smooth लगा
      लेकिन tmux की तुलना में latency noticeable थी, और मैं अभी भी tmux ही इस्तेमाल कर रहा हूं
      उस समय मैं पहले से ही एक latent connection पर था, इसलिए शायद मैं थोड़ा sensitive भी था
    • आखिरी बार जब मैंने Zellij देखा था, तो यह multiplexer ecosystem में एक शानदार नया project लगा, लेकिन pure keyboard-based copy/paste mechanism support नहीं करता था
      मैं उस feature को बहुत ज्यादा इस्तेमाल करता हूं, इसलिए उसके बिना काम नहीं चल सकता; जब तक वह add नहीं होता, मुझे tmux ही इस्तेमाल करना पड़ेगा
    • अच्छा है, लेकिन मुझे screen सच में पसंद है और commands मेरी muscle memory में बैठ चुकी हैं
      20 साल से ज्यादा से इस्तेमाल कर रहा हूं

  • upstream का इसमें शामिल होना हैरान करने वाला है
    करीब 5 साल पहले मैंने दुख के साथ conclude किया था कि GNU screen development पूरी तरह रुक गया है; सोच रहा हूं क्या अब भी ऐसा नहीं है
    पता नहीं screen में अभी भी existing screen से attach किए बिना नई window जोड़ने का feature है या नहीं

    • upstream ने SUSE team से इसे देखने के लिए कहा था
      development manpower की कमी है, और लगता है upstream के पास इसे ठीक से maintain करने की expertise शायद नहीं है
      अगर यह सच है तो दुखद है। मुझे पता है tmux और दूसरे alternatives हैं, लेकिन बहुत से लोग Screen को बहुत लंबे समय से इस्तेमाल करते आए हैं, और किसी tool का धीरे-धीरे सड़ना अफसोसजनक है
    • इसमें लिखा है कि upstream से communication मुश्किल था, इसलिए उनके bug fixes और release के बारे में detailed information फिलहाल उनके पास नहीं है
      उन्होंने security review की request तो की थी, लेकिन लगता है contact बनाए रखना मुश्किल रहा; पूरी स्थिति मुझे नहीं पता
    • शामिल होना कहें तो बस इतना कि उन्होंने इसे setuid-root के रूप में distribute किया
      जिन distros ने इसे ऐसे configure किया है वे vulnerable हैं, और जिनमें ऐसा नहीं है वे vulnerable नहीं हैं
      मुझे यह बहुत shallow involvement लगता है। upstream बहुत slow हो तो distro patch कर देता है
    • GNU tools का development रुकना जरूरी नहीं कि दुखद हो। बेशक bug fixes को छोड़कर
      इसे basically finished tool का संकेत माना जा सकता है
    • open source में एक problem यह है कि जब एक software खत्म होता है और उसकी जगह लेने के लिए दूसरा software बनता है, तो inertia पैदा हो जाता है
      तुरंत switch करने का incentive नहीं होता, क्योंकि वह update नहीं बल्कि migration है
      दूसरी तरफ, अगर कोई existing software का trademark खरीदकर Audacity की तरह उसे पूरी तरह कुछ और बना दे, तो वह भी खराब है
      इसलिए कोई अच्छा solution नजर नहीं आता

  • Rendered version: https://security.opensuse.org/2025/05/12/screen-security-iss...

  • अगर मेरी याद सही है, तो tmux OpenBSD 4.6 से base system में शामिल है और इसका audit हुआ है या होता रहा है
    जो लोग थोड़ा ज्यादा secure alternative चाहते हैं, उनके लिए अच्छा है

    • screen को फिर से दिखते देख, वह समय याद आ गया जब मैं कभी tmux पर switch करके screen को भूल गया था

  • observed behavior कम से कम 2005 के बाद की Screen versions में था, और इतने लंबे समय से यह anti-pattern रहा है; rkhunter जैसे tools भी इसे handle करते रहे हैं
    फिर भी, मुझे लगता है screen 90s में भी setuid root था

  • सबसे popular open source tools को असल में कितने developers चला रहे हैं?
    उन tools का इस्तेमाल करने वाली industries में कितना पैसा है?