Linuxové jádro je možné shodit pomocí série paketů, chyba je stará 10 let

Tech problemu/utoku je vic - viz originalni oznameni https://github.com/Netflix/security-bulletins/blob/master/advisories/third-party/2019-001.md (kde jsou rovnez popsany zpusoby mozne mitigace, pokud neni mozne hned aktualizovat kernel - jinak zaplaty jsou uz venku (a v distribucich - Debian, Redhat - taky uz jsou). Zminovane zpomaleni je jine CVE, nez ten panic. A jako bonus tam je low-slow utok postaveny na manipulaci s TCP MSS.

Spíš bych to formuloval obráceně: všechny tři problémy jsou založené na zneužití absurdně malé MSS, SACK je jen pomůcka, jak to dovést až do extrému, kdy se vyvolá ten BUG_ON() check.

Z tohohle workaroundu nemám dobrý pocit, jsem zvědav, kolik lidí si to v panice nastaví někde v sysctl.d a pak to po updatu zapomenou vrátit zpátky. (A už vůbec si nedělám iluze, kolik si jich nastaví tcp_min_snd_mss, pokud to za ně neudělá distribuce.)

Tak zrovna u TCP SACK je naopak obecne doporucovano jej v nekterych (bezne provoznich) situacich vypinat, takze zas takove drama bych z toho nedelal :-) Obecne plati, ze ne vse defaulne nastavene v distribuci je univerzalne optimalni - a dopady tohoto kroku (pozitiva i negativa zmeny s ohledem na lokalni prostredi) by si kazdy mel zhodnotit sam dle sveho prostredi nezavisle na tom, ze zrovna vysla nejaka bezpecnostni advisory...

Kdysi dávno se opravdu doporučovalo zakazovat SACK, ale to bylo hlavně kvůli rozbitým implementacím a už je to opravdu hodně dávno. Bohužel se občas setkám s tím, že to někdo doporučuje ještě dnes, ale to už svědčí spíš o tom, jak moc dotyčný zaspal dobu.

Kvuli zmrsenym implementacim stejne tak muzou nastat problemy pri zahazovani paketu s nizkym MSS v duchu mitigacnich kroku k CVE-2019-11479 - a zde se mnohdy argumentuje modernim IoT, kde to muze byt problem. Jak uz jsem psal, aplikace workaroundu vzdy zalezi na konkretnich podminkach.
Stejne tak duvodem pro vypnuti TCP SACK v kernelu muze byt nejen zmrsena implementace, ale nekdy i vykonnova optimalizace - ono si to vezme nejaky ten procesorovy cyklus navic, zapnute to dava smysl hlavne na linkach s vysokou latenci, nebo tam kde je packet-loss.. Ostatne to, ze to je dobry sluha, ale nekdy zly pan dokazuje treba i lonsky commit do 4.18, kde to je pekne i popsane (fuel to fire) - ale zas muzeme obratem vest flame o tom, ktere distribuce maji tak "cerstvy" kernel ;-)

Nevite, jestli se ten problem tyka IPv6-only serveru?

IIRC nic z toho nezávisí na tom, jestli jde o TCP nad IPv4 nebo IPv6. To nové sysctl je sice pod net/ipv4, ale to je jen proto, že z historických důvodů jsou tam všechna nastavení pro TCP, i když většina z nich není specifická pro IPv4.

V tom pripade u workaroundu pomoci iptables je nebo neni potreba pridat stejne pravidlo pres ip6tables?

Nevím, který workaround přesně máte na mysli, ale jestli používá příkaz iptables, tak to na IPv6 vliv mít nebude (s nft by mělo jít definovat společná pravidla pro IPv4 i IPv6).

Myslel jsem tenhle workaround. Puvodne tam ip6tables nebylo, tak me to nechalo na pochybach. Dekuji!