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.

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

Komentáře

[dnes 08:07 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

[dnes 08:42 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.

[dnes 10:29 Valgrind]

Jasne, dekuji, takto to dava smysl.

[dnes 10:32 fe]

V epel je 4.08.00 takže nic moc.

[dnes 12:42 X]

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

[dnes 12:51 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...

[dnes 13:38 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

[dnes 14:29 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).

[dnes 17:05 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.

[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

[dnes 16:55 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.

[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.