Test deseti webových prezentací politických stran odhalil v pěti případech kritické zranitelnosti, nejčastěji se jednalo o cross-site scripting, objevily se ale zranitelné zastaralé knihovny a v jednom případě také děravý jedenáct let starý Apache. Více ve zprávě na webu spajk.cz.
Tato zprávička byla zaslána čtenářem serveru Root.cz pomocí formuláře Přidat zprávičku. Děkujeme!
s tím 10 let zastaralým Apache http bych byl opatrný, RHEL 6 (a tím i CentOS 6) měli právě verzi 2.2.15 jako základ a sami si jí patchovali, podpora RHEL 6 a tím i CentOS 6 končila před rokem. Všechna CVE, která jsou na shodanu uvedena mají v rámci CentOS 6 aplikovaný patch, tenhle report je za mě chybný.
Automatické nástroje na sken jsou super, horší je brát z nich výsledky přímo a honit si na tom triko.
Pořád ale samozřejmě platí, že top09 by si měla webový server aktualizovat, mají tam i trochu jiné bezpečnostní pochybení a právě nedávno jsem jim report posílal a řešil jsem ten starší http server, ale určitě o nich neplatí, že mají 10 let starý webový server, naopak do nedávna byl plně aktualizovaný a všechna známá CVE backportovaná.
skvělé, díky za doplnění informací.
Skoro všechny ty CVE vyžadují nějakou špatnou konfiguraci na serveru, použití konkrétních modulů či nastavení nebo lokální přístup, to se blbě testuje, namátkou vidím CVE-2017-7668 nebo CVE-2011-3192, které jsou zneužitelné z venku, ani jedno se mi nepovedlo potvrdit testovací sadou, takže nejspíš opravdu používají patchovanou verzi.
Stáří SW by nemělo být důvodem ke kritice, spousty nástrojů a služeb zůstávají roky bez aktualizace, protože není co opravovat a funkce zatím dostačují, důležité je, jestli se o daný SW pořád někdo stará.
To, že je tady něco dlouho, neznamená, že to funguje. A váš komentář vlastně hezky ukazuje, proč to fungovat nemůže. Pro některé bezpečnostní opravy je totiž potřeba změna API nebo inovace.
Backportování patchů je založené na představě, že chyba je izolovaná v malé části kódu. Typický příklad takových chyb je buffer overflow nebo jiná chybná kontrola mezí. Jenže takových chyb je čím dál méně, protože se používají nástroje, které jim zabrání hned při vývoji. Za to je čím dál víc bezpečnostních chyb, které jsou v architektuře, v protokolu a podobně. Takovéhle chyby obvykle není možné opravit se zachováním zpětné kompatibility. Respektive můžete zpětnou kompatibilitu zachovat, ale ta zpětně kompatibilní větev je pak dále zranitelná. Takže pak sice můžete hezky backportovat příslušný patch, odškrtnete si „vyřešení“ CVE, jenže vše pak dál používá to staré děravé API…
> Takže pak sice můžete hezky backportovat příslušný patch, odškrtnete si „vyřešení“ CVE, jenže vše pak dál používá to staré děravé API…
To je dost odvážné tvrzení. Můžete doložit, řekněme, tři případy, kdy RHEL backportovalo opravu, která v upstreamu chybu řešila, ale v backportu nikoli? Jelikož je podle vás takových případů hodně, tak najít tři příklady jistě nebude těžké.
23. 9. 2021, 09:15 editováno autorem komentáře
L., …: Marně hledám ve svém komentáři slovo „hodně“. Nicméně uvedu nějaké příklady.
Jeden fiktivní příklad – knihovna pro hashování ve verzi 1 implementovala různé hashovací algoritmy, např. MD5 a SHA-1. MD5 je zastaralé, aplikace tak používají SHA-1. Pak se jednoho dne ukázalo, že SHA-1 je oslabená. Někdo na to určitě vytvoří CVE, knihovna implementuje SHA-2, vznikne tedy nová funkce v API knihovny verze 2 pro vytvoření SHA-256 hashe. Někdo vezme tuhle funkci a backportuje ji do verze 1 v nějaké distribuci. Hurá CVE je vyřešeno, můžeme si to odškrtnout, naše distribuce nepoužívá slabé SHA-1. Jenže ve skutečnosti všechny aplikace používající tu knihovnu dál používají SHA-1, a SHA-256 ani použít nemůžou – protože API verze 1, kterou používají, neobsahuje příslušnou funkci.
Jeden konkrétní případ: CVE-2020-10683. Knihovna dom4j ve výchozí konfiguraci volá výchozí konfiguraci XML parseru, který je součástí JDK – a tato výchozí konfigurace je náchylná na XXE. Změnit výchozí konfiguraci v dom4j není možné, protože by to rozbilo zpětnou kompatibilitu. Takže jsem přidal do rozhraní novou metodu, která má bezpečný default, původní metodu jsem označil jako deprecated a do release notes jsem napsal, že je doporučené přejít na tu novou metodu, protože stará má bezpečnostní problém. Maintainer dom4j v Debianu backportoval příslušný patch do starší verze, čímž v Debianu to CVE „vyřešil“. Že ten bezpečnostní problém je vyřešen teprve tím, že aplikace začne volat jinou metodu? Že aplikace přeložená proti starší verzi dom4j tuhle metodu nemůže nikdy zavolat, protože ta metoda nebyla v rozhraní starší verze? To nevadí, CVE je vyřešené.
Nijak to nevyčítám maintainerovi z Debianu. Je to jenom důsledek časté představy, že backportováním patchů lze opravit všechny bezpečnostní díry. Nelze, jak ukazují příklady výše. A ze zkušenosti, jakého charakteru jsou bezpečnostní chyby, dodávám, že těch, které je možné opravit backportováním, je čím dál méně. Protože chyby v programování umíme nalézat automaticky už v době psaní kódu, čím dál víc tak vystupují do popředí chyby v návrhu. Podobně to je vidět třeba na bezpečnostních protokolech – některé problémy TLS 1.0 a 1.1 prostě neopravíte zakázáním nějaké funkce nebo změnou implementace. Některé chyby jsou prostě chyby přímo návrhu protokolu a vyřešíte je jedině tak, že přejdete na protokol TLS 1.2 nebo dnes raději TLS 1.3. A to opět nevyřešíte backportováním implementace TLS 1.3 do staré verze knihovny OpenSSL – nestačí mít ten protokol k dispozici, je nutné ho začít používat. A to jsou ještě různé verze TLS ten jednodušší případ, kdy aplikace může začít používat novější verzi bez změny kódu. Někdy je potřeba ale i změna v návrhu aplikace.
Máš návrh na jiné řešení než backportování?
Především je potřeba si přiznat, že backportování často není řešením, protože backport ve skutečnosti nic neopraví. No a řešení je to, s čím přišly prohlížeče nebo proč je tak oblíbený Docker – nesnažit se držet iluzi starých stabilních verzí, ale naopak umět co nejrychleji přecházet na nové verze. že se může v nové verzi objevit chyba? Ano, může, ale stejně tak se může objevit v backportované verzi, která je navíc obvykle méně testovaná, než ta aktuální verze (protože backport se typicky dělá individuálně pro každou distribuci zvlášť, takže to testuje jenom ta jedna distribuce). Takže holt když se v nové verzi nějaká chyba objeví, v následující verzi, která bude rychle následovat, se to opraví.
Tedy abychom to shrnuli: Na začátku jste vydal silné prohlášení "Špatné je obojí. Jak pokoušet se opravovat bezpečnostní chyby backportováním patchů ...". Tedy backportování nemá jen určité nevýhody, ono má zásadní problém, protože je podle vás absolutně špatně.
V dalším příspěvku jste to vysvětlil tak, že při backportování se může stát, že je to tím, že backportujete jen část opravy, protože chyba není izolovaná.
Vyjádřil jsem pochybnost, že je to častý problém (musí být častý, aby způsobil absolutní špatnost backportování, jak tvrdíte).Tedy jsem vás vyzval, ať doložíte nějaké konkrétní, praktické příklady, kdy oprava v původní verzi chybu reálně opravovala, ale v backportu nikoli.
Přišel jste s jednou teoretickou konstrukcí, která není praktická a tedy nesplňuje podmínky.
Pak jste dal sice reálný příklad, nicméně ani ten nesplňoval dané podmínky - když přidáte opravené volání, tak aplikace nezačnou automaticky toto nové volání používat. Ani v mainline, ani v backportu. Tento příklad sice lze použít pro demonstraci toho, že pro opravu chyby je nutno opravit často více aplikací, ale to tu nikdo nerozporoval, s tím souhlasím. Nicméně vaše původní tvrzení, že backportovat je špatné nijak nepodporuje - mezi mainline a backportem rozdíl nebude.
Ještě k tomu "hodně": Na miskách vah dvě věci. Jednak takováto možnost utečeného backportu, která znevýhodňuje backporting. Nicméně mainline má zase nevýhodu v "čerstvých" chybách. A kdo někdy zkoušel sledovat vývoj, tak ví, že těch úplně málo není - stačí si projít release notes. Tedy pokud by měly "utečené backporty" tak výrazně převážit tyto nové chyby, aby backportovat bylo absolutně špatně (což je vaše tvrzení), musí jich být hodně. To je k tomu množství, které sice explicitně nezmiňujete, ale vyplývá z vaší logiky.
Nicméně jelikož jste dokázal přijít jen s jedním příkladem a to ještě takovým, který vaše tvrzení nepodporuje, tak myslím, že je závěr jasný.
Vidím, že zásadní rozdíl je v našem přístupu k bezpečnostním chybám. Já si myslím, že by se měly opravovat skoro za každou cenu. Vy si myslíte, že stačí předstírat jejich opravování, když to předstírání občas vede i ke skutečné opravě chyby. Takže pro mne je opravdu zásadní problém používat pro opravu bezpečnostních chyb způsob, u kterého nikdo neví a nezkoumá, které chyby opraví a které ne.
Kdyby někdo pečlivě zkoumal všechny změny v kódu a správně předvídal všechny možné dopady, bylo by backportování jedním z nástrojů, který se dá v některých případech použít pro vyřešení chyby ve staré verzi. Jenže kdyby někdo takový byl, může stejně tak stopnout patch s chybou přicházející do nové verze – a pak zase nebude důvod udržovat ty staré verze.
Vysvětlil jsem, že problém backportování je v tom, že bezpečnostní chyba nemusí být v kódu, ale v návrhu.
Příklad, který jsem uvedl, splňuje podmínky. V mainline je oprava, která jiným aplikacím umožňuje používat bezpečné řešení. Chyba nebyla zas tak závažná, aby kvůli ní bylo nutné potenciálně rozbít všechny stávající aplikace. Dál už je to na těch aplikacích, aby používaly bezpečná volání. Backport v tomhle případě ovšem neumožňuje používat bezpečné řešení. Rozdíl mezi tím, dza můžete nebo nemůžete používat bezpečné řešení mi připadá jako zásadní rozdíl.
Čerstvé chyby v mainline se obvykle budou týkat nových funkcí. Které nemusíte používat, když vám jde o stabilitu. Pokud nějaká chyba pronikne i do starší funkcionality, může se následně dostat i do backportu. Navíc pokud máte dva patche, jeden mění starou funkcionalitu bez dopadu na bezpečnost a druhý mění starou funkcionalitu s dopadem na bezpečnost, vy následně budete backportovat jenom ten jeden patch, je věcí náhody, jestli byla nějaká chyba v tom čistě funkčním patchi a backportem druhého patche se jí vyhnete, nebo jestli ten bezpečnostní patch závisel i na něčem z funkčního patche a backportováním jenom toho jednoho patche vytvoříte zcela novou chybu.
Takže vaše porovnání počtu chyb je úplně špatně. Potřebujete porovnat počet chyb, které v nových verzích rozbijí starou funkcionalitu, a na druhou misku vah dát počet chyb v backportovaném kódu, dále počet chyb, které backport ve skutečnosti neopraví a k němu počet chyb, které backportováním vzniknou (a v mainline neexistují).
Jaký je váš závěr je úplně jedno. Podstatné je, co se děje v reálném světě – prohlížeče, což je bezpečnostně asi nejexponovanější software dneška, přešly na časté vydávání nových verzí. Na serverech se hodně prosazují kontejnery, právě proto, aby se tam mohla používat jasně definovaná a pokud možno aktuální verze softwaru. Operační systémy se posouvají stejným směrem, k minimu podporovaných verzí s častými updaty. Protože backporty stojí na chybných předpokladech, nesplňují stoprocentně to, co slibují, a nikdo vlastně neví, jak jsou na tom z hlediska chyb doopravdy.
> V mainline je oprava, která jiným aplikacím umožňuje používat bezpečné řešení. ... Backport v tomhle případě ovšem neumožňuje používat bezpečné řešení.
Jak "neumožňuje"? Jako že když někdo v mainline začne používat opravené API a tu opravu backportuji, tak to fungovat nebude? Ugh?!
> Čerstvé chyby v mainline se obvykle budou týkat nových funkcí. Které nemusíte používat, když vám jde o stabilitu.
Takže když před pár lety Microsoft rozbil v nějakém updatu DHCP renew, takže jsem strávil pár hodin nevěřícným hledáním, co je proboha špatně, tak to bylo proto, že to byla nová funkcionalita? Samozřejmě ne, i existující funkcionalita se rozbíjí.
> prohlížeče, což je bezpečnostně asi nejexponovanější software dneška,
Další odvážné tvrzení bez zdroje. Jinak se bavíme primárně o serverových aplikacích. Uživatelské jsou jiná třída. Tam se opravdu na nějaké backporty moc nehraje, protože výrobci ve většině případů za chyby neručí, takže když zákazníkovi překotným aktualizováním něco rozbijí, tak se jim nic nestane. A tento model jim naopak umožňuje zavádět nejnovější "módu" - SW předplatné. Diskuse se pak hemží zoufalými dotazy "Včera mi X fungovalo a dneska mi to nefunguje, pomoc!" Osobně právě z těchto důvodů aktualizuji _velmi_ opatrně.
> Na serverech se hodně prosazují kontejnery, právě proto, aby se tam mohla používat jasně definovaná a pokud možno aktuální verze softwaru.
Nejen jasně definovaná, ale i jasně nakonfigurovaná, prostě aby odpadlo dohadování vývojáře s administrátorem jakou verzi SW potřebuje a jak má být nakonfigurovaná. Ale aktuální? To kontejnery spíš zhoršují. Zatímco dříve se o server a jeho aktualizace staral admin podle best practices, teď má programátor v Dockerfile nějaký výchozí image a neaktualizuje ho pokud ho k tomu někdo vyloženě nedokope.
> Operační systémy se posouvají stejným směrem, k minimu podporovaných verzí s častými updaty.
To platí pro OS pro BFU, například spotřebitelskou verzi Windows. Naopak před pár dny oznámil Canonical prodloužení LTS podpory Ubuntu: https://www.root.cz/zpravicky/podpora-ubuntu-14-04-lts-a-16-04-lts-se-prodluzuje-na-10-let/ tedy přesný opak toho, co tvrdíte.
Mimochodem, to je druhý konkrétní argument z praxe v tomto příspěvku. Zatímco vy argumentujete pouze svými dojmy a teoretickými konstrukcemi.
Jak "neumožňuje"? Jako že když někdo v mainline začne používat opravené API a tu opravu backportuji, tak to fungovat nebude? Ugh?!
Ano, neumožňuje. Když někdo v mainline začne používat API verze 2, a distribuce nabízí knihovnu s API verze 1, tak prostě ta nová verze aplikace v té distribuci nejde použít. Leda byste backportoval vše potřebné na obou stranách a řekl, že aplikace ve vaší distribuci závisí výhradně na knihovně z vaší distribuce. Takže by z toho byl už totální zmatek, čísla verzí by přestala dávat jakýkoli smysl. A hlavně by se takové distribuci obloukem vyhýbali všichni vývojáři, protože by nechtěli psát programy specifické jen pro danou distribuci.
Samozřejmě ne, i existující funkcionalita se rozbíjí.
Ano, to jsem psal. Není ale žádný důvod, proč by se tohle mělo vyhýbat backportovaným patchům. Právě naopak, takové programy jsou podstatně méně testované, takže je vyšší pravděpodobnost, že taková chyba pronikne až do produkce.
Nejen jasně definovaná, ale i jasně nakonfigurovaná, prostě aby odpadlo dohadování vývojáře s administrátorem jakou verzi SW potřebuje a jak má být nakonfigurovaná. Ale aktuální? To kontejnery spíš zhoršují. Zatímco dříve se o server a jeho aktualizace staral admin podle best practices, teď má programátor v Dockerfile nějaký výchozí image a neaktualizuje ho pokud ho k tomu někdo vyloženě nedokope.
Nebo se o to staral admin tak, že aktualizoval _velmi_ opatrně, pročež vývojář neustále řešil, jak tam dostat novější verze, administrátorovi navzdory. A administrátoři se pořád divili, proč komerční firmy dodávají komplexní balíčky se všemi závislostmi; později se divili, proč chtějí všichni vývojáři používat Docker, kam si dají svoje verze závislostí. Kdyby všichni chtěli používat staré verze, po Dockeru neštěkne ani pes – bezpečné oddělení kontejnerů (zrovna Docker) nepřináší, jediná jeho výhoda je možnost používat aktuální verze programů a knihoven a nečekat několik let, než se to objeví v distribuci.
Naopak před pár dny oznámil Canonical prodloužení LTS podpory Ubuntu: tedy přesný opak toho, co tvrdíte.
Žádný přesný opak. Serverová řešení se přesouvají do kontejnerů, distribuce se smrskává na jádro a kontejnerový engine. To, že staré systémy dožívají na LTS verzích není důležité, jejich počet se bude postupně zmenšovat.
Narážel jsem na tvrzení "10 let starý SW", což mělo implikovat, že je 10 let neudržovaný a neaktualizovaný, to ale není pravda a podle rychlých pokusů ani jedno z uvedených CVE na shodanu není pro danou verzi aktuální.
Samotná informace o stáří SW by měla být irelevantní, má hodnotu pouze pro vývojáře, aby věděli jak s ním pracovat a jakou podporu čeho má. Důležitá je informace, jestli daný SW je někým spravován a udržován, což tady nejspíš neplatí, ale to ví pouze provozovatel, je pak jedno, jestli je starý rok, pět let, týden, den.
