Názory k článku
Copy Fail: devět let stará díra umožňuje získat roota ve všech distribucích
-
problém není ani tak v tom, jestli to funguje nebo nefunguje, nýbrž v tom, že to tam bylo 9 let, aniž na to někdo přišel. ta proklamovaná výhoda OSS (že to může kontrolovat kdokoli) je do značné míry iluzorní, protože to skoro nikdo fakticky nedělá.
stejně jako dlouhý léta propagovaná údajná bezpečnost MacOSu, která ale měla původ především v tom, že nikomu nestálo za to na MacOS útočit.
a kromě toho je nejslabším místem stejně vždycky člověk. -
To se úplně neslučuje s tím, že si linuxáci vždycky dělali srandu z microsoftu, kolik aktualizací vydává, a kolik chyb a slabin má nahlášeno. Představa, že ten nepoměr je dán tím, že zlej kořistnickej kapitalista platí špatný programátory, je dost scestná; daleko realističtější je, že ten zlej bohatej kapitalista má prachy na to, aby partu těch kteří to budou dělat na plný úvazek skutečně zaplatil, místo by to dělali zadax ve svým volným čase pro dobrej pocit.
-
Tohle je ale fail jak kráva. A to, že se někdo tak dlouho neptal, jestli je ta ochrana proti zápisu dostatečná (obzvlášť po zkušenostech s meltdown) je alarmující. Jako nechci být generál po bitvě, ale z toho, že je takhle lehkovážně namapovaná page cache, mě otřásla zimnice.
IMHO tady jde o to, že tak velký projekt, byť OS, se už kontroluje dost špatně. -
a tady nastupuje kouzlo toho zlýho tlustýho kapitálu. bystander effect vyloučí jednoduše tím, že někdo zcela konkrétní dostane přidělen úkol se na to podívat, a pak se pod výsledek podepsat, a dostane zaplaceno za to, že to udělá dobře. a pokud se časem přijde na to, že se na to vyignoroval a prostě zkasíroval prachy, má fakticky na krku trestný čin podvodu. a zrovna v USA se sazbou podstatně tvrdší než tady, takže se dá daleko spíš spolehnout na to, že to fakt udělal.
-
Ne. Jak tady někdo postnul přehled Security Trackery, kde by měl být Debian vulnerable, ale ne již up-to-date Sid. Takži Sid jasné. Ale já mám starší server a tam to nejde taky:
zito@jira-scan:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 12 (bookworm)
Release: 12
Codename: bookworm
zito@jira-scan:~$ uname -a
Linux jira-scan 6.1.0-42-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.159-1 (2025-12-30) x86_64 GNU/Linux
zito@jira-scan:~$ ./copy-fail.py
Password:
su: Authentication failure
zito@jira-scan:~$30. 4. 2026, 13:42 editováno autorem komentáře
-
Michal SmržStříbrný podporovatelZe stejného důvodu jsem si pomohl "uv run copy_fail_exp.py" a funguje.
-
V RHEL a klonech je modul součástí jádra, viz:
grep CONFIG_CRYPTO_USER_API_AEAD /boot/config-*
Deaktivace je přes již výše v diskuzi zmíněný parametr jádra, tj:
grubby --update-kernel=ALL --args="initcall_blacklist=algif_aead_init" reboot
Aby se změna projevila, je nutný reboot. Při použití kexec jsou typicky použity původní parametry jádra, nikoliv nové.
-
Michal ŠmucrBronzový podporovatel
Kdybyste chtěli mrknout na CVE trackery s informacemi o vydání oprav u distribucí...
RedHat
https://access.redhat.com/security/cve/cve-2026-31431
SUSE
https://www.suse.com/security/cve/CVE-2026-31431.html
Debian
https://security-tracker.debian.org/tracker/CVE-2026-31431
Ubuntu
https://ubuntu.com/security/CVE-2026-31431 -
-
Můj custom kernel vůbec nemá AF_ALG zakompilovanou.
To nepíšu jako plácnutí, že bych se jako chlubil, ale jako upozornění, že "kernel kompilují jen blázni, autisté a uživatelé Gentoo což jsou blázni a autisté, normální člověk to nechá na distribuci" je z pohledu bezpečnosti pěkně hloupý koncept, který pro trochu pohodlí zcela nepřiměřeně zvyšuje attack surface.
Vzpomene si někdo ještě na nedávný RCE na AF_SCTP? Lessons not learned.
-
Ondra Satai NekolaZlatý podporovatelJá teda nevěřím, že bych nakompiloval jádro lépe než správci mého distra, minimálně bez značného množství práce navíc.
-
Právě. Navíc když povypínám, co mi přijde zbytečné, mohu též snížit bezpečnost. Například mohu vypnout ASLR, nebo mohu vypnout něco, co je potřeba k lepšímu sandboxu.
Zkompilovat kernel do nějak funkčního stavu oproti tomu není až taková výzva, ostatně používal jsem Gentoo. Snad jediný nebootovatelný kernel byl, když jsem podporu root FS zkompiloval jako modul.
-
Tak to s tím ASLR je argument stylu, že když někdo přezouvá doma auto, tak mu může spadnout z heveru, nebo může urvat brzdovou hadičku.
Ten zbytek, ono je to věc priorit. Tvůrce distribucí, pochopitelně, obvykle usiluje o to, aby "to fungovalo na první dobrou", což je pravý opak "nemít tam kód, který se nepoužívá". Jeden pohled je "někdo tam strčil nějaké obskurní zařízení do USB, tak rychle modprobnout driver ať to funguje", něco jiného "někdo tam strčil obskurní zařízení, o něm nevím, takže asi jde o pokus o exploit a budu ho ignorovat, jen to lognu (což dělá kernel standardně)"
-
Ondra Satai NekolaZlatý podporovatel
On je to argument, že musíš věnovat netriviální množství práce k tomu, abys to nepojebal. A nejspíš se to pořádně naučíš až když to několikrát pojebeš.
-
Právě.
> A nejspíš se to pořádně naučíš až když to několikrát pojebeš.
A možná ani to ne. Poučit se z toho, že mi kernel nenabootuje, je snadné. Poučit se z toho, že mám v něčem horší defense-in-depth, je už těžší. A i když bych se měl poučit z průniku, může si to vyžádat docela náročnou analýzu.
OK, možná vyjít z distribučního kernelu a ořezat jej o zbytečnosti by nějak ještě šlo. A pak mergovat konfigurace při každé aktualizaci.
-
Jop s tím distro kernelem za základ a odebírat (a někde i dost důrazně, typicky v různých net* subsystémech) máte svatou pravdu.
Projít komplet konfiguraci a volit přesně jen nutné šlo v době 2.4 až 2.6 kernelů, v dnešní době už je krajně netriviální z nuly dojít i do bashe v textovém režimu, navíc to i omezuje případné chyby tím, že o vypnutí věci člověk obvykle ví, co dělá, což rozhodně neplatí pro nezapnutí jedné z tisíce voleb.ad mergovat - no s vanila kernelem pak drtivou většinu pak už řeší zcat /proc/config.gz >.config && make menuconfig
-
> ad mergovat - no s vanila kernelem pak drtivou většinu pak už řeší zcat /proc/config.gz >.config && make menuconfig
To mi nepřijde jako dobré řešení – znamená to, že jakmile proběhne nějaká volba, už se k ní nevracíte. Tedy může nastat situace:
1. Do kernelu přibyde nějaká defense-in-depth volba (ve stylu ASLR)
2. Distribuce na to bude zpočátku opatrnější – budete mít volbu zpočátku vypnutou.
3. Později se v distribuci rozhodnou tuto volbu zapnout. Jenže zmíněným postupem si to nezapnete, pokud se tomu nebudete iniciativně věnovat. -
když se tomu nevěnuješ, tak nemá smysl to diskutovat, jdi do placené podpory nebo vezmi distribuci jako default a spoléhej, pak tě ale čekají tyhle rychlá a nečekaná kolečka aktualizací.
Linux je dnes strašný nepořádek, ty spousty špatných rozhodnutí se postupně nabalovaly až dnes je těžké to držet v nějakém rozumném determistickém stavu.
-
nikoliv lépe, ale mnohem specifičtěji. Sníží se tím velikost i vektor útoku. Při automatizované infra to nemusí být takový zásah. Kernel od správců distribuce se snaží být co nejkompatibilnější na různém HW, proto i občas vydávají tenké obrazy jen s drivery pro pro běh jako VM.
Přesně proto si kernel kompilujeme, sníží se tím množství rozhraní, které je možné zneužít a je potřeba je hlídat.
-
MalekBronzový podporovatel
Opensuse ma jiz fixle
https://bugzilla.suse.com/show_bug.cgi?id=CVE-2026-31431#c8
