Bezpečnostní chyby v terminálovém multiplexoru GNU Screen

V terminálovém multiplexoru GNU Screen byly nalezeny a v upstreamu ve verzi 5.0.1 už opraveny bezpečnostních chyby CVE-2025-23395, CVE-2025-46802, CVE-2025-46803, CVE-2025-46804 a CVE-2025-46805. Podrobnosti na blogu SUSE Security Teamu.

13.5.2025 04:33 | Ladislav Hagara | Bezpečnostní upozornění

Komentáře

[Ivan]

V RHEL9 uz screen neni, pry kvuli architekture a moznym bezpecnostnim problemum. Asi mi fakt nezbude nic jineho nez se naucit zkratky tmux-u.

[Max]

epel?
Zdar Max

[Valgrind]

Kvuli jake architekture??? Jak je to mysleno?

[Ivan2]

The `screen` package is deprecated and not included in RHEL8.0.0.

https://access.redhat.com/solutions/4136481

After careful consideration, the decision was made to deprecate the screen package and instead recommend the tmux package. The screen utility has an old code base that is not easy to maintain and with little activity in the upstream community. The tmux package was viewed as having a better code base to maintain and build new features upon. Maintaining both within RHEL was becoming increasingly unfeasible when considering keeping up with CVE security errata, government security certifications, and similar requirements. For those concerned with DISA STIG requirements, tmux satisfies the requirement as an alternative to screen.

Mozna to nebyla architektura, ale kvalita kodu.

[Valgrind]

Jasne, dekuji, takto to dava smysl.

[fe]

V epel je 4.08.00 takže nic moc.

[Jan Marek]

tmux lze nastavit v podstatě kompatibilně se screen-em:

https://thoughtbot.com/blog/migrating-from-screen-to-tmux

[X]

Ten "programator" Amadeusz Sławiński amade@asmblr.net ocividne skodil i jinde.

[alfonz]

Btw je tu někdo, kdo vlastně stále dnes používá tmux/screen? Jaké pro to máte využití/cíle? Já to před asi 10 lety používal nárazově > kvůli doporučení. Cca před 4-5 lety jsem to všude smazal.

[k3dAR]

pouzivam Byobu s tmux backendem, vsude... na serverech u zakazniku, na osobnim NB's, Desktopu/HTPC, serveru a dokonce i na nekolika domacich routerech s OpenWRT
Vyuziti je jednoduche, rozdeleni na okna, a casti oken, a zustavani vseho v nich bezicich i pri SSH odpojeni...
Nna vicemene vsech (i tech routerech) pouzivam zaroven ukladani/obnovu tmux session pres tmux-resurrect...

[alfonz]

promiňte - napsal jsem to špatně. Myslel jsem co v tom screenu/tmuxu takto spouštíte? Já, že už od doby upstartu, bylo vlastně jednoduší mít prostě servicu, místo to toho screen/tmuxu. Asi bych chápal ještě to openwrt, jelikož tam je to takové všelijaké/správa úloh je tam špatná. Na běžném serveru si ale moc nedovedu představit co mi to vlastně přináší/co mi chybí za možnost. Tzn, jestli můžete prosím zkusit napsat jak to vlastně použijete/co s tím děláte?

[Heron]

Já mám user systemd service právě na tmux.

[Unit]
Description=First test service

[Service]
Type=forking
User=lancer
ExecStart=/usr/bin/tmux new-session -s test1 -d
ExecStop=/usr/bin/tmux kill-session -t test1

[Install]
WantedBy=multi-user.target

sudo systemctl enable --now tmux.service

[vlk]

a preco rovno nespustat takto ten program, ktory chcem nechat bezat aj po odhlaseni ? (pokial nieje interaktivny)

[Heron]

Ano, jde to a systémová systemd služba vydrží i po ohlášení. A výsledek se uloží do logu.

[alfonz]

přežije i uživatelská instance systemd pokud se použije loginctl enable-linger user a poté i uživatelská služba/app a pak se opět může použít systemd-run --user

[rad]

Trochu mě mate, že má někdo problém chápat přínosy terminálových multiplexorů obecně. Typicky potřebujete spustit něco na vzdáleném stroji, odpojit se a pak průběžně kontrolovat, jak si úloha vede. Druhým typickým příkladem pak bude práce ve více terminálech v rámci jednoho sezení/spojení (a s tím spojená možnost dlaždicového zobrazení, což třeba zrovna já moc nepoužívám).

[alfonz]

sorry, za zmatení. Avšak já prostě služby nebo průběh pipeline/skriptu a podobně kontroluju prostě z systemd. a uživatelé docker/k8s asi řeknou podobný závěr, tzn používají běžný job/spuštěný kontejner ve kterém jim aplikace běží. A ty upgrady/instalace, tak ty se snažím dělat, aby se to dalo spustit znovu (podobně jako se o to snaží ansible)

[xkucf03]

Ono se hodí oboje. Opakovaně pouštěné věci si nastavím jako systémovou službu a výstup sleduji v logách. Na druhou stranu, když pouštím něco jednou, tak na to nebudu zakládat službu a pustím to spíš ve screenu.

A ty upgrady/instalace, tak ty se snažím dělat, aby se to dalo spustit znovu (podobně jako se o to snaží ansible)

Idempotence je fajn a pokud jde o nějaké malé rychlé změny, tak ať se to klidně pustí celé znova. Ale když ta úloha trvá hodiny, tak to fakt nechci pouštět znovu, jen proto, že někde spadlo spojení k terminálu.

[Heron]

Ano a je velmi výhodné mít malé služby většího počtu. Logy klidně analyzovat v průběhu. Ansible se také velmi hodí pro co nejmenší skripty.

tak ať se to klidně pustí celé znova

Ano, jedna data, jedno opakování a potom chyba do logu. Služba se vypne.

Tmux/screen je super, jen na ty logy. Může běžet nonstop.

[rad]

A jak to vypadá v reálu? Pro každý script, který potřebujete spustit vytvoříte ad-hoc systemd službu (bavíme se třeba o desítkách zcela odlišných úloh denně) a výstupy sypete do logů? A pak se v těch lozích/logách přehrabujete?

Já se přihlásím k běžícímu tmux sezení pro každou novou úlohu otevřu vlastní okno a v něm ten script prostě spustím. Nemusím řešit žádné služby ani logování. A pokud potřebuji, mohu průběh více úloh monitorovat paralelně pomocí dlaždicového zobrazení jednotlivých oken. Navíc mi to umožňuje s úlohami interaktivně pracovat, potřebuji-li.

Jistě, pro automatizované, rutinní spouštění identických úloh je systemd jistě vhodný, ale pro to, co já bych v mém případě nazval prací se hodí o něco méně méně.

[alfonz]

Mno, já prostě používám systemd přímo.

#systemd-run --unit=myupgrade1  -p User=ubuntu sleep 3000
Running as unit: myupgrade1.service; invocation ID: 35b332afb1de4db59a7e13d95eb2c7a7
#systemctl status myupgrade1.service
● myupgrade1.service - /usr/bin/sleep 3000
     Loaded: loaded (/run/systemd/transient/myupgrade1.service; transient)
  Transient: yes
    Drop-In: /run/systemd/system/service.d
             └─zzz-lxc-service.conf
     Active: active (running) since Wed 2025-05-14 12:46:55 UTC; 13s ago
   Main PID: 252 (sleep)
        CPU: 2ms
     CGroup: /system.slice/myupgrade1.service
             └─252 /usr/bin/sleep 3000


#systemctl stop myupgrade1.service
#journalctl -u myupgrade1.service
May 14 12:46:55 test2 systemd[1]: Started myupgrade1.service - /usr/bin/sleep 3000.
May 14 12:47:23 test2 systemd[1]: Stopping myupgrade1.service - /usr/bin/sleep 3000...
May 14 12:47:23 test2 systemd[1]: myupgrade1.service: Deactivated successfully.
May 14 12:47:23 test2 systemd[1]: Stopped myupgrade1.service - /usr/bin/sleep 3000.

Další možnost je template unit, která prostě vezme parameter název skriptu. To je vhodné hlavně na opakující se obdobné úkony. Ta hlavní výhoda, je že je dostupná cgroup/firewall/omezení a další podobné věci, logování, správa, ukončení, není potřeba hlídat pid a podobně. Btw pokud použijete uživatelskou instanci systemd s lingeringem, tak to samé může dělat uživatel.

[rad]

Hmm, nakonec asi proč ne. I když se přiznám, že moc nevidím výhodu (pro můj typický use case) v té mezivrstvě tvořené systemd (uznávám, že v opacném případě je tam ta mezivrstva tvořená tmuxem, ale ta mi tam běží tak jako tak). Přijde mi to užitečné spíš pro správu systému než pro samotnou práci v něm. Asi by mi trochu vadilo to míchání logů (některé úlohy mohou být dost ukecané, jiné mohou používat různé progress bary apod.), ale to bude nejspíš taky řešitelné. Vlastně mě nikdy nenapadlo řešit to jinak než tmuxem, třeba se to bude někdy na něco hodit, díky.

[Max]

Používám screen, a spouštím tam kritické věci, které nechci, aby se nějak přerušily, když by mi padlo spojení (výpadek proudu, výpadek na straně ISP apod.). Takže jakékoli složité upgrady různých app (např. instalace, patchování OracleDB...) apod.
Zdar Max

[alfonz]

aha, chápu že na interaktivní upgrady, je to asi dobré. Já už běžně upgrady, děláme jen ob jednu LTS verzi na ubuntu a jinak převážně čisté instalace - vlastně u všeho a instalace se téměř všechny mohou spustit znovu a běžný upgrade apt, prostě pouštím po serverech, které jsou odstavené. Jinak běžně už nic na serveru, vše spouštím jako spuštěné služby. k8s či nové kontejnery/lxc/lxd to samou sebou posouvají dále.

[Max]

Když člověk spravuje silně heterogenní prostředí, kde jsou aplikace náročné na upgrade a patchování, v několika krocích atd., takže není zbytí. Řešit to unitou je pro takový účel naprostý nesmysl.
A ano, máme i k8s, máme ansible atd., ale máme i jiné věci.
Zdar Max

[tom]

promiňte - napsal jsem to špatně. Myslel jsem co v tom screenu/tmuxu takto spouštíte? Já, že už od doby upstartu, bylo vlastně jednoduší mít prostě servicu, místo to toho screen/tmuxu. Asi bych chápal ještě to openwrt, jelikož tam je to takové všelijaké/správa úloh je tam špatná. Na běžném serveru si ale moc nedovedu představit co mi to vlastně přináší/co mi chybí za možnost. Tzn, jestli můžete prosím zkusit napsat jak to vlastně použijete/co s tím děláte?

Treba si vzdalene pustim torrent klienta, nejakou dlouhou kompilace a nebo test a nechci, aby to zdechlo, kdyz se odpojim. Sluzba je naprd na interaktivni praci a nebo na neco, co pustim jen jednou.

[Ivan2]

Screen jsem pouzival dost casto. byla to nutnost v minuly praci. Nejaci mozkovi giganti ze security vymysleli, ze vas odpoji od serveru pokud nejste minutu aktivni.

Kdyz jsem delal trobleshooting na 3 nodovym clusteru a na chvilku jsem se zapomel na 1. nodu tak me to odpojilo od nodu 2. a 3. Byla to totalni pakarna. Navic vam screen umoznuje psat kolegova terminalu anebo predat rozdelanou praci kolegovi v jinem casovem pasmu.

Dalsi skvela vlastnost screeny je moznost ulozit celou session do souboru. A z toho si pak udelat poznamky anebo napsat nejaky report.

Dneska v dobe Ansible uz to neni tak aktualni, ale jeste pred par lety byla screen nutnost, zvlast kdyz jste neco delali ve vetsim tymu.

[xkucf03]

+1

Nejaci mozkovi giganti ze security vymysleli, ze vas odpoji od serveru pokud nejste minutu aktivni.

To je dost otravné. Ale někdy to sleduje aktivitu v obou směrech, takže pro udržení spojení stačí spustit třeba top nebo watch date.

[Heron]

To je dost otravné

Jo, tohle mě štve ze všeho nejvíc. Sice jsou karty, ale v krizi bez karet se stejně nikam nejde dostat. Hesla se mění na každé připojení, a jsou tak dlouhá, že jenom to správně ručně napsat trvá cca 20minut. Mezitím, server stojí. Zbytečná komplikace. Tmux/screen je tiše tolerován a sledován.

Tohle je super v případě, že je vše kolem plně automatické. Takže jednou za 20 let to jde opravit i ručně. Ale ne každý den.

[xkucf03]

Nejaci mozkovi giganti ze security vymysleli…

Mimochodem, tady pozoruji podobný jev jako třeba u pedofilů – když se navrhne nějaké opatření „proti zneužívání dětí“, tak si málokdo troufne proti tomu protestovat. A v IT zase projde kdejaká pitomost vymyšlená ne zcela kompetentními lidmi, jen díky tomu, že je to v zájmu „počítačové bezpečnosti“.

[Heron]

Tak ona ta bezpečnost je OK, ale nesmí se to přehánět. K šifrování stačí klíč a druhý v trezoru. Bezpečnost ok, stejně jde vše s dokumentací nastavit jednou a správě. Zbytek automatika. Už ani na ssh doma nepoužívám tmux. Hesla vůbec a i MS to přestal nutit. Navíc dneska RFC/BT znamená automatické odhlášení po odložení mobilu. Doma to mám na BT, stačí zavřít dveře a PC je do minuty sleep. Skoro totéž v práci, ale s hesly. FIDO je také dostatek.

[Heron]

A k těm pedofilům, stejně žádní nejsou. Už jsem psal i Urbanové, že to zbytečně přehání.

[RealJ]

Njn, obvykle to rikaji lidi kteri bezpecnosti rozumi jako babca atomovce. Znal jsem jednoho, vypracoval se diky svym kecum o tom jak ostatni delaji uplny hovno az na pozici CTO v jednom megakorporatu kde pokracoval ve sve moudrosti a naridil odstraneni antiviru z pocitacu. Po ztrate dat, skode nekolika stamilionu $$$ ho vyrazili a ted co vim bruci v nejakem vezeni. Kazdy profesional v bezpecnosti se rozhoduje na zaklade rizika pro danou organizaci. Pro nektere organizace ani ten antivir neni zapotrebi zatimco pro jine organizace jsou i analni sondy malo. To, ze se najde i u bezpecaku spousta idiotu je normalni statistika.

[Heron]

Oni tomu rozumí velmi dobře a já taky, proto odmítám jakékoliv komplikované znaky. Stejně je to tam jen proto, že je heslo stejně v passkey. Heslo ani neznám ani doma. Ani pro linux a freebsd, tam stačí rsa-4096 nebo ed. A windows samotné to heslo nechtějí zobrazovat. Je to šifrované na disku, uživatel to nepotřebuje.

[Max]

Problém je u samotných norem. Pokud chceš plnit ISO27001, nebo na tebe padne i NIS2 (na nás padá), tak jsi prostě v řiti. A v našem případě na nás padá NIS2 v rámci asi 5 států. A fakt nechceš řešit 5x jednu věc, takže se to pak řeší kombinací nejtvrdších politik ze všech států a tím pádem jednotná politika napříč celou skupinou.
Zdar Max

[k8o]

Tmux stále používám, ale už spíš ze zvyku - třeba kvůli IRC, i když často mám všude bouncery. Byobu, ke kterému mě přivedl kdysi dávno Bystroushaak právě na IRC :), už mi dlouho smysl nedává. Co se týče práce s okny, kterou jsem dlouho řešil právě tmuxem, tak opravdu hodně používám Kitty (term emulator), který tohle umí velmi pěkně. Je pak příjemné, že v tilling managerech jako Hyprland/Sway pak hodně mé workflow je sdílené.

[Heron]

Já používám tmux více méně z pohodlnosti. Jinak vše automatické.

[pavele]

Používám screen, ve kterém mám spuštěné ssh na jednotlivé virtuály, takže se připojím na screen a přepínám si mezi virtuály, nemusím se pořád přihlašovat.

[xkucf03]

nemusím se pořád přihlašovat

Přemýšlím, co je na přihlašování tak hrozného, když může člověk použít SSH klíče (případně jsem viděl i funkční přihlašování na SSH přes Kerberos)…

Ten Screen mi přijde nejužitečnější tam, kde hrozí odpojení od rozdělané práce a přerušení úlohy. Případně na správu více „oken“ na jedné obrazovce (ale to má od dob vynalezení X11 menší význam).

[Heron]

Nic. Je to chce rozumné heslo. 256b se lépe napíše 0 a 1. Já nenávidím využití všech písmen na klávesnici CZ/Querty/z/ENG. Něco vůbec nejde napsat.

Proto klidně 8znaků a jeden pokus, pořád lepší než dlouhé heslo na náhodné klávesnici. Čip je hned.

[Heron]

A vůbec, už jen střídání z/y je prostě na nic.

[..... Izak .....]

Jaaaa na programy co musi bezet a bezi dlouho ... klasika nejaky restore pres ndmpcopy na netappu, nebo i jine veci co bezi opravdu dlouho, nebo je pruser, kdyz to spadne kvuli spojeni