Názory k článku
Chyba v Log4j je ve velkém hledána a zneužívána útočníky

Ta interpretace muze byt i uzitecna. My jsme to pouzili pro to aby bylo mozne do logu vlozit sessionId, REST API url, celkovou dobu trvani, a podobne veci. Bohuzel nikoho na prvni pohled nenapadne, ze by se takova vec dala zneuzit.
K tomu ale nepotřebujete interpretaci. To se normálně řeší tak, že přidáte tyto informace do MDC (Mapped Diagnostic Context) a ty se pak vypisují spolu s logovací zprávou.

Pokud autory logovací knihovny nenapadne, že by se to dalo zneužít, je lepší se od takové knihovny držet co nejdál.

souhlasím, vzhledem k tomu, že autoři takovéhle chování považovali za správné a dnes se vyjadřují, že to tam chtěji vrátit až vyřeší jako to udělat bezpečně, raději pryč.

Ukazuje to i poměrně silnou neznalost knihoven, které se používají, tohle byla dokumentovaná vlastnost, jen nikdo (vč. mě) jí dopředu nečetl.

V kódu a dokumentace o všem mluví jako o message a o tom, že to je string, přitom s tím pracují jako se vstupem, který dále interpretují, to mi moc jako prostá message nepřipadá.

Stejný problém mimochodme nastavává i při zpracování textových logů a jejich parsování, běžně nástroje na parsování špatně interpretují některé znaky, překládají řídící znaky jako \r, \0 a jiné, to může vést také k pěkným zranitelnostem. Stejně tak aplikace, které sice do logů dávají json, ale skládají ho ze stringu (pro nginx docela oblíbené řešení v kubernetes).

Ono to tiez dokazuje, ze ta domnela vlastnost OpenSource kniznic, ze kazdy sa moze pozriett na zdrojaky a nast chyby preto su bezpecne moc v prxy nefunguje.

No a ted si vemte, že něco takového bude v něčem co je closed source a jste úplně v pytli, protože s tím toho moc neuděláte, když se něco takového objeví.

open source podle mě podobným chybám nebrání, ale zjendodušuje jejich opravování. Takhle jsme byli schopní hned v pátek udělat analýzu a zvolit odpovídající obranu.

Zatímco u uzavřeného kódu bychom neudělali nic, placený support ani v tomhle případě neodpovídá hodiny, dny. Návod a patche ještě nejsou pro všechny placené komponenty a přitom open source je již opravený a vyřešený během hodin.

„...kazdy sa moze pozriett na zdrojaky a nast chyby preto su bezpecne moc v prxy nefunguje.“

U mnoha knihoven to tak skutečně funguje, u ostatních je vždy ta možnost (ne povinnost), u uzavřeného kódu se můžete koukat tak doma do trouby.

Po bitvě každý generálem, ale tady to na mne působí, že někdo porušil princip KISS, což bylo po zásluze potrestáno. Od logovací knihovny čekám, že bude zapisovat logovací hlášky, a to je vše. To s tím jndi: resolvingem na mne působí jako "extra chytristika".

Skóre 10.0 z 10.0 CVSS, odhad počtu zranitelných systémů v řádu vyšších stovek milionů, to je velmi slušné.

https://www.nukib.cz/download/uredni_deska/2021-12-15_RO-NUKIB-Log4Shell.pdf

Je kam jinam jít. slf4j nemá šíleně zastaralé API – „chybí“ mu jediná věc, a to je efektivnější zápis pro lazy získávání parametrů pro logovací zprávy. Což je pouhá optimalizace. Používá se to výjimečně, což je v pořádku, protože to logování posouvá směrem, kde je dnes Log4j 2 – že se během logování provádí kód, o kterém nikdo nic neví.

Takže není žádný problém slf4j používat. Je to pořád milionkrát lepší, než mít kvůli logovací knihovně v aplikaci vzdálené spuštění kódu. Navíc pokud by někdo tak šíleně toužil po těch lazy parametrech, nic mu nebrání napsat wrapper kolem slf4j a klidně ho zveřejnit jako opensource knihovnu. Bylo by to pár řádek kódu – místo psaní komentářů už byste ten wrapper měl napsaný.

Vy se pořád tváříte, že ta chyba Log4j 2 je ojedinělá chyba, která se může stát každému. Evidentně vás nezviklalo ani to, že se další velmi podobná chyba objevila hned po pár dnech. Pořád si odmítáte připustit, že to je chyba v návrhu Log4j 2, dokonce chyba v definici požadavků, co má logovací knihovna dělat. Že se takovéhle chyby objevily v Log4j 2 není náhoda. A riziko, že tam budou další podobné chyby, je velké. Logovací knihovna nemá text, který má zalogovat, nijak interpretovat, má ho co nejrychleji dostat do logu. Pokud na vstupu dostane něco jiného, než text, má to co nejbezpečněji převést na text a dále postupovat podle předchozí věty.

Jedná se pořád o tu samou chybu. Schválně jsem se koukal na počet chyb v logback a je to skoro to samé jako log4j2.

Těch věcí co slf4j nepodporuje je mnohem více. Např. CloseableThre­adContext o tom se slf4j může jenom zdát, Message API, Garbage-free Steady State Logging.

Je celkem štěstí, že se ta chyba objevila v log4j 2 a ne v logback, protože si nedokážu představit, co by se dělo. kdyby to bylo opačně. Protože spousta lidí co používá logback ani o tom neví a nebyla by schopná to opravit.

Jedná se pořád o tu samou chybu.
Jenže pořád tu samou chybu se pokusili opravit, a neúspěšně. Dokonce se ukázalo, že nepomáhá ani konfigurační property, která měla tuhle super funkci vypnout.

Schválně jsem se koukal na počet chyb v logback a je to skoro to samé jako log4j2.
To myslíte vážně? Vážně naházíte na jednu hromadu chyby se skórem 1 i 10?

CloseableThre­adContext
To jste si popletl. To neumělo log4j 1.x, slf4j s tím pak přišlo a nazvalo to MDC. Log4j 2 to jen okopírovalo.

Message API
Díkybohu, že to nepodporuje.

Garbage-free Steady State Logging
To zní docela úsměvně v kontextu této chyby. „Nevytvoříme žádný nový objekt, tedy s výjimkou případů, kdy si stáhneme úplně celou třídu odkudkoli z internetu“.

Je celkem štěstí, že se ta chyba objevila v log4j 2 a ne v logback, protože si nedokážu představit, co by se dělo.
To není štěstí, to je důsledek přístupu autorů.

Protože spousta lidí co používá logback ani o tom neví a nebyla by schopná to opravit.
Stejné je to ale i s Log4j 2. Ty knihovny jsou často součástí nějaké aplikace, kde provozovatel možná ví, kde má konfigurační soubor logování (často ani to ne).

Jenže pořád tu samou chybu se pokusili opravit, a neúspěšně. Dokonce se ukázalo, že nepomáhá ani konfigurační property, která měla tuhle super funkci vypnout.
To druhé CVE má score 3.5 a zrovna není snadné to udělat. Je to asi stejné jako kdybyste v logback změnil logger na JNDI. Takže i logback měl podporu pro JNDI.

To myslíte vážně? Vážně naházíte na jednu hromadu chyby se skórem 1 i 10?

OMG CVE-2017-5929 7.5 .

To jste si popletl. To neumělo log4j 1.x, slf4j s tím pak přišlo a nazvalo to MDC. Log4j 2 to jen okopírovalo.
Nepopletl zkuste si tam dát víc hodnot.

To zní docela úsměvně v kontextu této chyby. „Nevytvoříme žádný nový objekt, tedy s výjimkou případů, kdy si stáhneme úplně celou třídu odkudkoli z internetu“.
Holinky jako hodinky, obojí se natahuje. Ještě bych dodal varargs, protože slf4j umí jenom dva argumenty.

Stejné je to ale i s Log4j 2. Ty knihovny jsou často součástí nějaké aplikace, kde provozovatel možná ví, kde má konfigurační soubor logování (často ani to ne).
Měl jsem na mysli úplně jiný případ a to, že vyvíjí aplikaci a vůbec netuší co mají za použitý logger. Zejména u Spring Boot.

Nepopletl zkuste si tam dát víc hodnot.
Budou tam. A dál? S čím máte problém?

Ještě bych dodal varargs, protože slf4j umí jenom dva argumenty.
Aha, už chápu, v čem je problém. Vy jste nepostřehl, že není rok 2011 ale rok 2021. slf4j od verze 1.7.0, která vyšla v roce 2012, podporuje varargs (musela se kvůli tomu zvýšit minimální podporovaná verze Javy na 1.5).

Měl jsem na mysli úplně jiný případ a to, že vyvíjí aplikaci a vůbec netuší co mají za použitý logger. Zejména u Spring Boot.
Ano, vím, že jste myslel jenom na část aplikací a dělal z toho závěry pro všechny. To, že logování prostě funguje a vývojář to nemusí nijak speciálně řešit, považuji za dobré.

Budou tam. A dál? S čím máte problém?
Do jednoho MDCClosable jde dát jenom jedna hodnota, takže když jich chcete víc, tak jich musíte vytvořit několik MDCCloasable. Ale chápu, že vám to nevadí a stále místo try-with-resources používáte close() a finally, kvůli zpětné kompatibilitě a že to dělá něco co vy nevidíte.
Aha, už chápu, v čem je problém. Vy jste nepostřehl, že není rok 2011 ale rok 2021. slf4j od verze 1.7.0, která vyšla v roce 2012, podporuje varargs (musela se kvůli tomu zvýšit minimální podporovaná verze Javy na 1.5).
Spíš jste to totálně nepochopil vy. log4j 2 umí až 10 argumentu na rozdíl od pouhých dvou co umí slf4j , pro víc se musí použít varargs.

Do jednoho MDCClosable jde dát jenom jedna hodnota, takže když jich chcete víc, tak jich musíte vytvořit několik MDCCloasable.
A v čem je tedy ten problém?

Ale chápu, že vám to nevadí a stále místo try-with-resources používáte close() a finally
To chápete špatně.

Spíš jste to totálně nepochopil vy. log4j 2 umí až 10 argumentu na rozdíl od pouhých dvou co umí slf4j , pro víc se musí použít varargs.
Jasně, čím víc pruhů, tím víc Addidas. Už si vymýšlíte úplné nesmysly. Když napíšu logger.debug("…", arg1, arg2, arg3), je v drtivé většině případů úplně jedno, jestli je to metoda s varargs nebo se čtyřmi parametry. Pokud v některých velmi výjimečných případech vadí, že se tam vytváří nové pole, pořád si to pole můžete předalokovat předem.

CloseableThre­adContext.put(ke­y1, value1).put(key2, value2)
vs MDC.MDCCloseable closable1 = MDC.putClosea­ble(key1, value1), MDC.MDCCloseable closable2 = MDC.putClosea­ble(key2, value2)
Je to mapa/set resp. stack.

Jasně, čím víc pruhů, tím víc Addidas. Už si vymýšlíte úplné nesmysly. Když napíšu logger.debug("…", arg1, arg2, arg3), je v drtivé většině případů úplně jedno, jestli je to metoda s varargs nebo se čtyřmi parametry. Pokud v některých velmi výjimečných případech vadí, že se tam vytváří nové pole, pořád si to pole můžete předalokovat předem.
Neřekl bych ani popel, kdyby těch argumentu bylo aspoň 5 ale 2 je opravdu málo. A k čemu je mi předalokování pole, vždyť to vůbec nic neřeší? Je jedno jestli se mi alokuje dopředu nebo až po zavolání. Ve velmi výjimečných případech, mě to teda vadí pokaždé, proč se má dělat něco co se dělat nemusí?

CloseableThre­adContext.put(ke­y1, value1).put(key2, value2)
vs MDC.MDCCloseable closable1 = MDC.putClosea­ble(key1, value1), MDC.MDCCloseable closable2 = MDC.putClosea­ble(key2, value2)
Je to mapa/set resp. stack.
Vím. Ten problém teda spočívá v čem?

Neřekl bych ani popel, kdyby těch argumentu bylo aspoň 5 ale 2 je opravdu málo.
K tomu, aby metody mohly mít proměnlivý počet argumentů, slouží varargs. Vytvářet vedle toho další metody s pevně daným počtem parametrů kvůli jakési optimalizaci je antipattern.

Je jedno jestli se mi alokuje dopředu nebo až po zavolání.
Myslel jsme, že vám vadí, že se během logování alokuje nový objekt. Pokud vám nevadí ani to, netuším, co s tím vlastně máte za problém.

Ve velmi výjimečných případech, mě to teda vadí pokaždé, proč se má dělat něco co se dělat nemusí?
Ano, to je dobrá otázka, proč se mají do API logovací knihovny přidávat nějaké metody, které tam být nemusí. Na odpověď stále čekám.

K tomu, aby metody mohly mít proměnlivý počet argumentů, slouží varargs. Vytvářet vedle toho další metody s pevně daným počtem parametrů kvůli jakési optimalizaci je antipattern.
Tak určitě. Jaká si nepodstatné optimalizaci, něčeho co se používá tak často, že už to má vliv. Kecy o antipatternu si nechte pro někoho jiného, protože to samé je udělané i v JDK např. List.of().

Myslel jsme, že vám vadí, že se během logování alokuje nový objekt. Pokud vám nevadí ani to, netuším, co s tím vlastně máte za problém.
Mě vadí, že se alokuje nový objekt, když nemusí.

Ano, dalo by se to dělat tak komplikovaně, jak to popisujete vy, a riskovat, že ten konfigurační parametr nebude fungovat. Ať už obecně, nebo že ho někdo špatně nastaví. A nebo se to dá udělat tak, že se vydá nová verze, kde je to natvrdo zakázané – a kdo to používá, tak prostě nebude aktualizovat.

Je rozdíl mezi logováním a konfigurací logování. Konfigurace logování se provede obvykle jednou při startu aplikace a pak už to má Logback uložené ve svých interních strukturách a nevstupuje do toho ani Joran ani Groovy. Ale jak vidíte, autoři Logbacku to v novém kontextu zvážili a usoudili, že i tak je to zbytečné riziko a podporu pro automatickou konfiguraci přes Groovy odstranili. Protože Logback vystavuje pro konfiguraci API, pokud chce, může Groovy nadále použít, ale už tam nebude ta automatická podpora, že když bylo Groovy dostupné na classpath, hledal se automaticky i konfigurační soubor logback.groovy a použil se, pokud byl dostupný.

Jak jsem psal tohle je řešení zmatkováním, honem všechno odstranit. Ten postup komplikovaný není. Co když se objeví chyba někde jinde, to budou mít pak uživatelé staré verze smůlu? Fascinuje mě, jak na jednu stranu strašně obhajujete zpětnou kompatibilitu a na druhou jste schopný podporovat vyhazování věcí bez zjevného důvodu, jenom, že si nejsou jistí.

Za mě je tohle úplně špatně, ten logovací framework by měl umět naprosté minimum a tohle všechno by mělo být jako pluginy. Chcete zápis do DB, jasně umíme, stačí přidat tenhle plugin. Chceš JNDI, jasně přidej tenhle plugin.

Ten postup komplikovaný není.
To, že vy spouštíte aplikaci z nějakého shell skriptu nebo systemd jednotky neznamená, že se tak spouštějí všechny aplikace na světě. Někdy není úplně snadné do cílové aplikace procpat systémovou vlastnost nebo proměnnou prostředí. Navíc vypínat něco nebezpečného tímhle způsobem je znovu nebezpečné, protože nemáte jistotu, že je to opravdu vypnuté. Nastavíte systémovou vlastnost a máte pocit, že máte vyřešeno – a přitom třeba nemáte vyřešeno nic, stačí hloupý překlep v názvu. A do třetice, jak je vidět na příkladu Log4j 2, ten kód rozhodující se podle té systémové vlastnosti může být zase chybný.

Co když se objeví chyba někde jinde, to budou mít pak uživatelé staré verze smůlu?
Je dost velká pravděpodobnost, že než se objeví chyba jinde, bude tohle vyřešené. V Logbacku už je JNDI zpět, omezené jen na protokol java. Pokud někdo opravdu potřebuje konfigurovat Logback pomocí Groovy, už pravděpodobně řeší, jak to udělat ve své aplikaci.

bez zjevného důvodu, jenom, že si nejsou jistí
Ano, je zjevné, že náš pohled na bezpečnost je zjevně dost odlišný. Já RCE opravované na několik pokusů nepovažuju za něco, nad čím lze mávnout rukou.

Za mě je tohle úplně špatně, ten logovací framework by měl umět naprosté minimum a tohle všechno by mělo být jako pluginy. Chcete zápis do DB, jasně umíme, stačí přidat tenhle plugin. Chceš JNDI, jasně přidej tenhle plugin.
Aspoň na něčem se shodneme.

útočník pošle nevalidní JWT token a ten může skončit v téhle property a zalogovat se. Mysli na to, že většinou loguješ co je špatně a nikoliv všechen uživatelský vstup, za poslední dny jsem viděl spousty pokusů v http hlavičkách, DNS záznamech, emailových hlavičkách, client certifikátech.

Je těžké to formálně z venku prokázat, takže je potřeba předpokládat, že se to tak děje a pokud někdo do patternu použije nějakou takovou konstrukci, je nutné říct, že je aplikace zranitelná bez ohledu na to odkud tam ten obsah jde.

Ten vstup by se musel dát do MDC a pokud vám někdo pošle JWT, tak první co uděláte, je že ověříte jestli je validní. Pokud není, tak ho maximálně zalogujete ale rozhodně z něj nebudete ukládat informace do MDC. To co je špatně se loguje přímo a je tedy postižitelné tou první chybou, ty ostatní musí být vloženy do MDC a ještě pro výpis musí být použit lookup.

Saljack: Na tom je krásně vidět, jak je ten váš přístup nebezpečný. Co je validní JWT? Že má platný podpis? Nebo kontrolujete nějak i hodnoty uvnitř? Třeba jméno (občanské) uživatele nebo jeho přezdívku? Jako poznáte validní přezdívku od nevalidní? Nebo to, že se v přezdívce neobjeví dolar a složené závorky podle vás validuje vydavatel toho JWT? Jak moc jste si tím jistý?

Určitě namítnete, že přece přezdívku nebudete ukládat do MDC. Takže máte položky JWT pečlivě rozdělené na důvěryhodné a nedůvěryhodné, a podle toho je vkládáte do MDC? A jste si jistý, že ty nedůvěryhodné do MDC nevloží nikdo v žádné části aplikace? Co ty patří mezi ty důvěryhodné položky JWT? E-mail uživatele? Víte, jak ho poskytovatel JWT validuje?

A i kdyby pro vás poskytovatel JWT filtroval veškerý uživatelský vstup tak, aby vaše aplikace nebyla napadnutelná přes Log4j 2 – důvěřujete tomu poskytovateli JWT tak, že s ním budete sdílet proměnné prostředí vaší aplikace, třeba hesla nebo autentizační tokeny?

Bingo, pokud něčemu nevěřím, tak to nebudu takhle logovat. Ať si do MDC vkládá klidně kdo chce co chce, ale důležité je pořád co je v layoutu logu. Takže co když vám tam někdo vloží něco co není důvěryhodné, je úplně mimo.

Já si myslím, že přístup má být přesně opačný – logovat všechny údaje, které dostávám a mohly by se hodit. To, jestli těm údajům můžu nebo nemůžu věřit, se zjistí až následnou analýzou. Mimochodem, tohle je princip všech logů a deníčků, ne jen těch aplikačních – zaznamenávám to, co v tu chvíli vidím, interpretaci nechávám na později. Interpretace se může v čase vyvíjet a pokud zkreslím data interpretací už v okamžiku záznamu, nikdy z toho ta původní data nedostanu a to zkreslení tam budu mít navždy.

S tím vaším přístupem se třeba nikdy nedozvíte o pokusech o útok, protože je zahodíte dřív, než je zalogujete. A nebudete mít zalogovaný ani úspěšný útok, pokud půjde cestou, kterou jste neočekával (což je u útoků obvyklé).

Právě naopak vy zkreslujete, protože prohlašujete něco za informaci, která není pravdivá. Nikde není napsáno o tom, že to nemáte zalogovat ale pokud v logách něco tvrdíte, tak by to měla být ověřená informace.

S tím vaším přístupem se třeba nikdy nedozvíte o pokusech o útok, protože je zahodíte dřív, než je zalogujete. A nebudete mít zalogovaný ani úspěšný útok, pokud půjde cestou, kterou jste neočekával (což je u útoků obvyklé).

Nikdy a nikde jsem netvrdil, že se to nezaloguje a už vám to píšu po několikáte. Vše se zaloguje ale rozhodně to nebude mít nesmyslný kontext aby se to následně muselo analyzovat, zda ten context je pravdivý nebo není. Opět dodávám příklad abyste to konečně již pochopil:

[jirsak] Invalid login

[] Invalid login with username jirsak

Já do logů ve spoustě případů dávám jenom údaje, ne informace. Informaci je z toho potřeba teprve vytvořit. A protože nevím, jaké informace bude potřeba získávat, ukládám právě ty údaje, bez nějaké interpretace a filtrování.

Ten příklad nemusíte opakovat, já ho chápu. Akorát to, že vy něco logujete špatně, není důkazem toho, že je to principiálně špatně.

Říkejte si tomu klidně jak chcete údaje nebo informace. To, že ukládáte nesmysly, které jsou úplně k ničemu a navíc jsou nepravdivé a akorát vedou k následným problémům je váš problém a problém těch co s tím pak mají něco dělat (naštěstí ne můj). Co do toho plete nějaké filtrování, o tom jsem nikde nepsal. Psal jsem pouze o security filteru, který loguje přesně ty informace které má a právě, že se nesnaží interpretovat naopak od vás když tvrdíte, že se jedná o uživatele.
Příklad bohužel musím opakovat, protože ho stále nechápete.

Howgh

21. 12. 2021, 12:44 editováno autorem komentáře

Údaj (nebo data) jsou něco jiného, než informace. Informace získáte z dat tím, že použijete znalosti. Vy stále trváte na tom, že znalosti nemáte, pak ovšem opravdu z dat nemůžete získat informace. Pak samozřejmě nemůžete posoudit, jestli je něco pravdivé nebo nepravdivé ani jestli to k něčemu je nebo není.