Názory k článku
Log4j 2.15.0 a 1.x jsou stále zranitelné, aktualizujte na 2.16.0

kde stačí dát na dobré slovo autora knihovny a neřešit, co v tom je
To je drtivá většina aplikací. Včetně těch, kde se dbá na bezpečnost a SLA.

- "Kluci, už na tom programu děláte přes dva měsíce, to už ho budete mít pomalu hotový, ne?"
- "No to úplně ne, ale už máme skoro hotový logovací framework pro něj!"

Říkám vybrali si špatně. A to ze udržuje s svůj vlastní logovaci nástroj je sice frajerina ale dost neefektivní.

Jinak řečeno by uživatele mělo trknout, že ačkoliv je logování pouze podpůrnou a principiálně nijak složitou činností, zařazení takto obrovské knihovny neodpovídá přínosu a aplikaci (jestli předtím byla) činí neauditovatelnou.

Ano, to je hezká teorie. Jenže v praxi je to pak ten textový řádek a grep.

Navíc i kdyby si někdo opravdu dal tu práci a vypisoval z aplikace třeba LNJSON, pořád to neřeší ten problém, že by musel takhle vypisovat na úrovni debug nebo dokonce trace a pak byste zase všechny ty zprávy zahazoval. Nehledě na to, že jste psal o logování do souboru – jenže to vám pak ten soubor poroste donekonečna. Nebo musíte do aplikace implementovat rotování logovacích souborů – a to už je zase v rozporu s tím vaším principem, že každý program má dělat jenom jednu věc.

Ono to v reálném světě bohužel není tak jednoduché, nestačí se řídit primitivními poučkami a je potřeba správně navrhnout, co vše aplikace má dělat a co už má dělat někdo jiný.

Na rotování logu je odjakživa logrotate.

druhá, na rotování logů mám asi 3 řádky kódu navíc

za třetí, pokud jde o logování na úrovni debug, většinou mi zas tak o výkon nejde.

pokud jde o filtrování úrovní, pak při jiné úrovni se ten JSON ani nesestaví. Logovat lze i přes lambda funkci (která se nezavolá, když není level aktivní). Případně ve své knihovně mám funkci isXXXLevelActive, která vrací false, když je daný level vypnutý, do kdyby třeba někdo prováděl složitý výpočet pro účely zalogování.

Ale vy se řiďte čím chcete. Je to vaše víra. Protože je to víra, která teď ničí pověst programátorů a přijde mi to, jako když se liní programátoři kteří použijí děravé frameworky teď kopají do programátorů, kteří si to napíšou sami s argumentem "taky tam nasekáte takové chyby".

Problém je, že tohle vzniklo jako feature creep. Parta maníku, co si sedla a řekla si "čím bychom to ještě vylepšili". Takovou chybu tam neudělám, protože takovou featuru většinou nebudu potřebovat

logrotate, logování do souboru, tailf. Zkoušel jsi někdy tohle udělat pro vícevláknovou aplikaci? Zkoušel jsi někdy implementovat logrotate, tak abys neztratil ani řádek a aplikace začala zapisovat do nového souboru? Zkoušel jsi někdy použít tailf, tak abys dokázal proces restartovat a nic nevynechal a ani nenačetl nic dvakrát?

Ty algoritmy jsou poměrně složité, stejně jako variabilita použití, proto ty knihovny nabírají na velikosti.

Ano zkoušel, není to problém.

Narozdíl od Vás, já těm algoritmum rozumím. Pro Vás to je magie. Logrotate nikdy neztratí ani řádku. Dokud nedostanu signál, loguje se do starého souboru, i když už ho logrotate přejmenoval. Jakmile dostanu signál, soubor zavřu a otevřu nový. Tahle operace je pod zámkem - případně logování má vlastní vlákno, do kterého se posílají jednotlivé záznamy a to vlákno ho zapisuje a tam zvládne i rotate.

Další věcí samozřejmě je účel logování.

Pokud někdo do logu loguje bysnys logiku, pak asi používá špatný nástroj.

Dokud nedostanu signál, loguje se do starého souboru, i když už ho logrotate přejmenoval.
A pak zkusíte aplikaci spustit na Windows.

FYI ve windows funguje prejmenování při otevřeném souboru (je třeba si pohrát s nastavením sharing)

v tom případě ale musíš vědět, že to udělat napříč různymi verzemi OS či jen linux kernelu není vůbec snadné, stejně tak zajistit funkčnost napříč celým životním cyklem aplikace (co když požadavek na rotování proběhne hned při bootstrapu?). Ono vůbec použití nespolehlivého signal(2) vede k sigaction(2) a to už je kousek k implementaci vlastního přerušení a ošetřování chyb a hned za rohem tě čekají věci jako signal-safety(7), v kombinaci se zámky se v tom dá nasekat neskutečně chyb.

Poté tě čeká minové pole kolem iops, když tvoje aplikace hodlá hodně logovat, o multithread komunikaci ani nemluvě, vždyť i v c++ to není zrovna lahoda, byl jsem v počátku u vývoje pantheios.

Rád bych tvoji impelemtanci viděl, mohli bychom se naživo o těch složitých zákoutích pobavit a mohl bys vidět, že to opravdu může být složitější, proto ty frameworky vznikají, proto mají tolik řádků kódů.

Na rotování logu je odjakživa logrotate.
To jako myslíte vážně? Používat něco, co vyžaduje restart aplikace kvůli logování? A když ne restart aplikace, tak musí ta aplikace správně reagovat na signál, což ale porušuje ten váš princip, že má dělat jenom jednu věc.

druhá, na rotování logů mám asi 3 řádky kódu navíc
To bych ty tři řádky chtěl vidět. Navíc tím porušujete váš princip, že by aplikace měla dělat jen jednu věc.

za třetí, pokud jde o logování na úrovni debug, většinou mi zas tak o výkon nejde.
Asi jste nepochopil, jak logování funguje. Logování funguje tak, že ve zdrojovém kódu jsou na zajímavých místech rozmístěné příkazy pro zalogování informací podstatných v daném místě programu. Ty příkazy logují na různých úrovních podrobnosti a jsou součástí přeloženého programu. Teprve po překladu se nakonfiguruje, na jaké úrovni se má skutečně logovat – a logovací knihovna zajistí, aby se logovací zprávy, které podle konfigurace nemají být vypisovány, nebyly nikam odesílány ani ukládány.

Kdybyste to řešil vaším způsobem, musela by aplikace do souboru neustále vypisovat všechny zprávy. Teprve následně byste ty nepotřebné (třeba na úrovni debug) odstraňoval.

pokud jde o filtrování úrovní, pak při jiné úrovni se ten JSON ani nesestaví. Logovat lze i přes lambda funkci (která se nezavolá, když není level aktivní). Případně ve své knihovně mám funkci isXXXLevelActive, která vrací false, když je daný level vypnutý, do kdyby třeba někdo prováděl složitý výpočet pro účely zalogování.
Aha, takže nakonec vaše aplikace nedělá jenom jednu věc, používáte v ní také logovací knihovnu, akorát jste si tu knihovnu napsal sám.

taky tam nasekáte takové chyby
Což je pravda.

Problém je, že tohle vzniklo jako feature creep. Parta maníku, co si sedla a řekla si "čím bychom to ještě vylepšili". Takovou chybu tam neudělám, protože takovou featuru většinou nebudu potřebovat
Já jsme nikdy netvrdil, že něco takového mělo v Log4j 2 být – právě naopak, kritizuju to. Ale myslet si, že si to sám napíšete líp, je naivní. Uděláte tam jiné boty, protože to nebudete řešit, je to přece jenom pro jeden projekt a nebudete to nějak zvlášť ošetřovat, musíte přece dělat hlavně na funkcionalitě samotné aplikace, zabývat se logováním nemáte čas.

tak logrotate je potřeba vždy.. protože můžeš proces přerušit kdykoliv..

To vaše za druhé... Na to abys udělal svíčkovou, taky potřebuješ udělat přípravu a postup, aby docílil výsledku... Svíčkovou neděláš stylem, že vše syrové rozmixuješ, dáš to ohřát na sporák a podáváš... Vše má svůj postup...

Za třetí... asi bych moc nevyčetl... ale taková logovací knihovna o které nevíš kde co dělá (určitě si projíždíš kód knihovny, jako časopis playboy...). Né vždy je to správné řešení, ale to je zase věc názoru...

A k tomu konci... můžu si napsat vlastní knihovnu, kterou budu implentovat dál a dál.. s tím, že budu postupně upravovat.. Výhoda vlastní knihovny je ta, že někomu jinému to dá práci rozlušťit, protože jede práci podle papíru a nepřemýšlí nad tím..

Byl tu sice dávno článek o člověku co si napsal celou Photopea hezky doma a píše si knihovny sám.. Taky to mohl převzít od jinud.. ale takhle by to nevylepšil.. Jde o to,že můžeš něco využít, ale musí to mít hlavu a patu...

Tak to mate iste premakane dokaze to logovat aj do povedzme influxdb a umoznuje separatne logovat vybrate casti nasadenim standardnej sondy. Ano pokial ste si vy vyrobili vlastny logovaci system my sme z neho spravili standard vratane vzdialeneho nastavovania a zapinania a vypinania.
Viem viem, vy to dokaze lahko dorobit aj do toho vasho logovania ale v nasom svete to dokaze kazdy druhy admin bez toho aby sa s vami vobec bavil a dokaze si cez to a AOP komplet monitorovat a parovat logy z aplikacie napriklad z requestami (cez MDC) a detekovat napriklad nestandardne spravanie aplikacie a mnohe dalsie veci.
Viem viem aj to by ste tam dokazali pridat ale na to proste nemame cas. Pouzite LOG4J2 alebo SLF4J alebo si svoju aplikaciu nechajte. Takto to dnes chodi. A bude horsie, standardizuju sa prostredia pre beh (Docker, Kubernetes, ...) a vy proste musite tu kompatibilitu a standardizaciu splnat inac nepredate.

Ano, můžete si vybrat takovou knihovnu, jaká vám vyhovuje. Pro někoho je to asi moc náročné.

Platí ovšem obecné pravidlo, že použít knihovnu je výhodnější mnohem dřív, než si myslíte. Problém je totiž v tom, že vždy porovnáváte, co by to mohlo umět v ideálním případě, když to budete psát – a proti tomu reálný stav té knihovny. Bohužel toho ideálního stavu vlastního kódu se nikdy nedočkáte. Je to malá obměna známého bonmotu „nikdo vám nedá tolik, kolik my vám můžeme slíbit“.

Pouzit cizi knihovnu ma svoje pravidla. Nejdriv to chce fakt dukladne nastudovat. Pak pravidelne cist reporty nebo se spolehat na nekoho kdo to dela za vas.
Jsem celkem purista a nesnasim nic navic. Z projektu vyhodim i systemove knihovny kdyz je nepouzivam ale za ta leta vim ze se oplati pouzit neco co uz je a je to udelano dobre. log4j jde nastesti mimo mne. ;o)

Přesně. Musí to být kvalitní knihovna, a i tak pak člověk musí pořád sledovat vývoj, aktualizace, opravy… NIH se zveličuje, samozřejmě pokud tým juniorů píše webovku, poslepuje projekt z dostupných knihoven (a Stackoverflow). Velké projekty se seniorním týmem fungují podstatně jinak, ale tím si musí člověk projít, aby mu to docvaklo.

Jj, čas seniorních vývojářů je ještě dražší, takže tam vynalézat kolo má ještě menší smysl, než u juniorů (kteří by se na tom alespoň něco naučili).

Třeba teď jsem potřeboval vzít obrázek a změnit mu velikost podle nějakých kritérií. Vzal jsem na to knihovnu a do půl hodiny bylo hotovo, včetně vyhledání nejvhodnější knihovny. Kdybych to měl psát bez knihovny, dekódovat, změnit velikost (dle algoritmu), zase zakódovat... To by trvalo násobně déle a kód by nebyl bezpečnější, rozhodně ne bez velmi důkladných code review a auditů. Což by pracnost nadále zvyšovalo a pokud člověk nedělá něco fakt extra super bezpečnostně náročného, tak to prostě nemá smysl.

BTW, častým důvodem, proč člověk podlehne NIH syndromu je brutální podcenění pracnosti daného úkolu. Reálně se psaní vlastního řešení vyplatí pouze když máte nějaké opravdu velmi specifické požadavky (už jsem taky zažil).

“častým důvodem, proč člověk podlehne NIH syndromu je brutální podcenění pracnosti daného úkolu”

To je pravda, a to lépe posoudí senioři. Ale junioři se na něčem takovém dost naučí, pokud to tedy někdo zaplatí.

> To je pravda, a to lépe posoudí senioři.

Lépe ještě nemusí znamenat dobře :-) Dost seniorů to znovunalézání kola baví (protože si při tom typicky stanovují požadavky sami), takže si argumenty přihnou tak, aby jim vyšlo, že by to měli napsat in-house. Tahle diskuse je toho nakonec nejlepším důkazem :-)

Na druhou stranu hodně knihoven vzniká jako výsledek NIH v rámci jiných projektů, když se ukáže, že kód je dostatečně obecný, užitečný a použitelný i jinde.

Nebo na univerzitách, kde většinou nejsou kritické deadliny a peněz z grantů je nadbytek, doktorandi a postdoci často píší kód duplikující běžně používané knihovny, a většinou celkem kvalitně (co si budeme povídat, průměrného vývojáře intelektem citelně převyšují, takže si to můžou “dovolit”). Na MFF UK nebo CIIRCu takto vzniká spousta užitečného kódu.

"Ale ten kód používá víc lidí, takže je pravděpodobnější, že na chybu někdo narazí před vámi, nebo že se na ten kód prostě podívá."

Ibaze prax ukazuje, ze toto sa nedeje. Ta strasna chyba v Log4j tam bola cez 5 rokov a nikto si ju v tak pouzivanej kniznici nevsimol.

Což možná vypovídá spíš o tom, že ten lookup nikdo nepoužívá.

Ibaze prax ukazuje, ze toto sa nedeje. Ta strasna chyba v Log4j tam bola cez 5 rokov a nikto si ju v tak pouzivanej kniznici nevsimol.
Ne, praxe nic takového neukazuje. Když si někdo takovouhle knihovnu napíše na koleně, bude tam mít takovýchhle chyb 10 a taky si toho nikdo nevšimne.

Navíc pokud někdo dbá na bezpečnost, je pravděpodobné, že se Log4j 2 rovnou vyhne, a pak nemá důvod studovat její zdrojový kód. Třeba já jsem dva dny před oznámením té zranitelnosti porovnával Log4j 2 a Logback, jestli má smysl začít pro nové projekty používat Log4j 2, které je novější. Když jsem si přečetl seznam vlastností Log4j 2, první věc, co mne napadla, bylo „ty jo, tohle je dost nebezpečné“. A to jsem ani nenarazil na tu část, co teď generuje jedno CVE za druhým. Ale do zdrojáků už jsem ani nešel, bylo to zbytečné, když jsem jako nebezpečný vyhodnotil už koncept té knihovny.

Navíc pokud někdo dbá na bezpečnost, je pravděpodobné, že se Log4j 2 rovnou vyhne, a pak nemá důvod studovat její zdrojový kód. Třeba já jsem dva dny před oznámením té zranitelnosti porovnával Log4j 2 a Logback, jestli má smysl začít pro nové projekty používat Log4j 2, které je novější. Když jsem si přečetl seznam vlastností Log4j 2, první věc, co mne napadla, bylo „ty jo, tohle je dost nebezpečné“. A to jsem ani nenarazil na tu část, co teď generuje jedno CVE za druhým. Ale do zdrojáků už jsem ani nešel, bylo to zbytečné, když jsem jako nebezpečný vyhodnotil už koncept té knihovny.
Což tady tvrdíte už týden, ale zatím jste s ničím nepřišel. Všechny ty chyby log4j se týkají pořád té samé věci lookupu. Navíc to druhé a třetí CVE nejspíš moc lidí nepostihlo, protože nepoužívají lookup v layoutu.

Což tady tvrdíte už týden, ale zatím jste s ničím nepřišel.
S čím bych měl přijít? Jasně jsem napsal, že když je ta knihovna na první pohled nebezpečná a existuje k ní srovnatelná ale bezpečnější alternativa, tou nebezpečnou knihovnou se dál nezabývám.

Všechny ty chyby log4j se týkají pořád té samé věci lookupu.
Což je ovšem v rozporu s vaším tvrzením, že teď bude Log4j 2 dobře prozkoumaná. Navíc tahle věc v logovací knihovně nikdy neměla být a když už tam byla a objevila se první chyba, měl se celý kookup zakázat. Pak bychom se tu nemuseli bavit o tom, kolik lidí postihlo druhé a třetí CVE, kolik čtvrté a páté, a tipovat, kolik těch CVE ještě bude. Vážně vám nepřipadá podezřelé, když se na té samé věci objeví 3 CVE během jednoho týdne?

S čím bych měl přijít? Jasně jsem napsal, že když je ta knihovna na první pohled nebezpečná a existuje k ní srovnatelná ale bezpečnější alternativa, tou nebezpečnou knihovnou se dál nezabývám.
Opět jenom blábolení.
Což je ovšem v rozporu s vaším tvrzením, že teď bude Log4j 2 dobře prozkoumaná.
Není.

Navíc tahle věc v logovací knihovně nikdy neměla být a když už tam byla a objevila se první chyba, měl se celý kookup zakázat.
Což se stalo.
Pak bychom se tu nemuseli bavit o tom, kolik lidí postihlo druhé a třetí CVE, kolik čtvrté a páté, a tipovat, kolik těch CVE ještě bude. Vážně vám nepřipadá podezřelé, když se na té samé věci objeví 3 CVE během jednoho týdne?
Ne divné mi to opravdu nepřijde a je to celkem běžné. Opravy přišli okamžitě. Pořád mi to přijde lepší než čekat týden na analýzu a vydat opravu až později.

Opravy přišli okamžitě.
To jistě potěší všechny, kdo už potřetí přenasazují aplikace. Navíc já jsem neřešil, za jak dlouho přišly opravy (přičemž jak tady někdo psal, ta první nepřišla okamžitě hlavně bylo nezvládnuté její zveřejnění), ale to, kolik těch chyb je.

– Navíc tahle věc v logovací knihovně nikdy neměla být a když už tam byla a objevila se první chyba, měl se celý kookup zakázat.
– Což se stalo.
Když je podle vás celý lookup zakázaný, jak je možné, že se v něm objevují další chyby?

Pořád mi to přijde lepší než čekat týden na analýzu a vydat opravu až později.
To ovšem není jediná možnost. Další možnost je opravit to rovnou pořádně, a když je to obtížné, tak tu problematickou funkcionalitu, která se moc nepoužívá, úplně zakázat (a povolit ji třeba jen na základě nějakého příznaku).

"Ne, praxe nic takového neukazuje. Když si někdo takovouhle knihovnu napíše na koleně, bude tam mít takovýchhle chyb 10 a taky si toho nikdo nevšimne"

Laskavo prestane podsuvat veci co som nepovedal, ja som ani nespomunul pisanie vlastnej kniznice. Hovorim o tom falosnom pocite bzepenosti v open source komunite. Tie zavazne chyby su tam roky, hoci si ich moze kazdy vyvojar odhalit, tak preco su tam tak dlho, hoci ide o jednu s najpouzivanejsich kniznic na dany ucel v jave?

Hovorim o tom falosnom pocite bzepenosti v open source komunite. Tie zavazne chyby su tam roky, hoci si ich moze kazdy vyvojar odhalit, tak preco su tam tak dlho, hoci ide o jednu s najpouzivanejsich kniznic na dany ucel v jave?
Já jsem ovšem srovnával dva případy – vlastní kód a použití open source knihovny. Máte nějakou třetí variantu? Nebo co jste vašim komentářem chtěl říci? Já jsem nepsal nic o tom, že OSS knihovny jsou bezpečné, psal jsem, že jsou bezpečnější, než vlastní kód.

Proč jsou tam ty chyby tak dlouho jsem částečně vysvětlil v předchozím komentáři. Další podstatný díl skládačky je ten, že nikoho nenapadlo, že by logovací knihovna mohla dělat takovéhle šílenosti.

„Ta strasna chyba v Log4j tam bola cez 5 rokov a nikto si ju v tak pouzivanej kniznici nevsimol.“

Tak komu by se taky chtělo hrabat v 150 000 řádků, že?

Navíc log4j 2 bude nyní celkem prozkoumaný, takže bych se toho opravdu vůbec nebál.
Pokud je něco děravé z podstaty, žádný další průzkum tomu nepomůže. Navíc teď se v Log4j 2 nacházejí chyby, které je velmi snadné najít, nejsou to žádné okrajové případy. Je otázka, zda bude mít někdo důvod to zkoumat nějak víc do hloubky.

Ty chyby se týkají pořád toho samého lookupu. Zatím nic jiného se tam nenašlo. Logback je taky děravý z podstaty když používá groovy a JNDI?

To, že ten samý lookup byl opraven zatím třikrát během jednoho týdne, má svědčit o tom, že bezpečnost je u autorů Log4j 2 na prvním místě? „Zatím se tam našla jenom jedna chyba, teda dvě, teda tři“ mne tedy nijak neuklidňuje.

1. přišla okamžitá oprava s vypnutím log4shell
2. vypnutí lookupu v message

Co má co společného logování špatného vstupu a ukládání do MDC? Samozřejmě, že každý normální člověk špatný vstup zaloguje, ale nebude ho už cpát do MDC.

Každý normální člověk to nejprve dá do MDC, aby měl všechny následující logovací zprávy svázané s uživatelem. Když používá bezpečnou logovací knihovnu a ne shell, který bokem umí i logovat, nemusí se bát do MDC uložit cokoli. Jakmile to uděláte jinak, musíte složitě řešit pořadí, co kdy validovat a ukládat do MDC – a nejspíš se vám to nepodaří vyřešit správně, což zjistíte, až ty informace z logu budete potřebovat a zjistíte, že tam nejsou.

Tohle je blábol co nedává smysl. Takže mi přijde pokus o smazáni např. celé databáze, pro jednoduchost s basic auth (, kde nesedí username a třeba i password a já si zaloguju, že uživatel jirsak se snažil smazat celou databázi. 1. už by to měl zaříznout nějaký filter nebo tak něco, který to MDC bude plnit a že když to tím filterem neprojde, tak se neplní do MDC úplnými nesmysly (a předpokládám, že ani vy takhovouhle blbost nikde nemáte) 2. ta logováná informace je totálně špatně, protože má úplně nesmyslný context, jelikož to třeba nebyl uživatel jirsak ale poledny. Vůbec netvrdím, že byste se měl bát dávat do MDC cokoliv, ale měli by tam být informace, které jsou buď nějakým způsobem ověřené pokud se jedná o user input nebo informace které nepochází z user inputu, jinak si logujete naprosté nesmysly a vaše logy jsou úplně k ničemu.

Př.:

[jirsak] Invalid login
[] Invalid login with username jirsak

Teď hledejte co všechno dělal uživatel jirsak v logach v prvním případě vidíte, že udělal invalid login, ale to nemusí být vůbec pravda, to nemusel dělat vůbec jirsak.

Jestli ve vašem kódu nejprve zjistíte, že jde o pokus o smazání celé databáze, a teprve pak zjišťujete, jestli sedí jméno a heslo, tak tedy potěš pánbůh. A i kdybyste to dělal takhle nesmyslně a nebezpečně – co je podle vás lepší, mít v logu zprávu, že se neznámý uživatel pokusil smazat celou databázi, nebo je lepší tam mít, že se uživatel, který se sám identifikoval jako jirsak, pokoušel smazat databázi? Nebude náhodou to druhé lepší, protože budete schopen porovnávat různé z logy z různých systémů, odlišit od sebe alespoň některé požadavky apod.?

Do MDC se ukládají údaje, které slouží k identifikaci logovaných zpráv, které nějak patří k sobě. To, jestli ta informace je nebo není pravdivá, se může zjistit až následně při analýze logu.

Jestli ve vašem kódu nejprve zjistíte, že jde o pokus o smazání celé databáze, a teprve pak zjišťujete, jestli sedí jméno a heslo, tak tedy potěš pánbůh.

Laskavě si to přečtěte ještě jednou a nepište tu zase totální nesmysly. Nikde jsem nic takového nepsal.
Ještě jedno pro vás:

https://jirsak:heslo@xyz.com/deletedb

Přijde request na server a server aplikuje nejprve security filter. Uživatel jirsak bud neexistuje nebo nesedí heslo vrací se 401. Zaloguje se, že se někdo pokoušel o přihlášení s uživatelským jménem jirsak a tím to celé hasne. Proč bych proboha měl nastavovat do MDC, že se jedná o uživatele jirsak?
Dle vaší logiky se uživatel jirsak pokoušel zavolat endpoint, ale to vy nevíte, proto nemůžete tvrdit, že se to pokoušel uživatel jirsak, protože uživatel je neznámý.

Do MDC se ukládají údaje, které slouží k identifikaci logovaných zpráv, které nějak patří k sobě. To, jestli ta informace je nebo není pravdivá, se může zjistit až následně při analýze logu.

Omg .Chudáci co to po vás pak musí analyzovat.

20. 12. 2021, 15:18 editováno autorem komentáře

Proč bych proboha měl nastavovat do MDC, že se jedná o uživatele jirsak?
Protože do MDC se nastavují informace, které máte v tu chvíli k dispozici a tušíte, že by se mohly někdy později hodit. Abyste později u každého logovacího příkazu nemusel přemýšlet, jestli tam tahle informace je nebo není potřeba, rovnou ji vložíte všude.

Dle vaší logiky se uživatel jirsak pokoušel zavolat endpoint
Já jsem ale nic takového netvrdil.

Omg .Chudáci co to po vás pak musí analyzovat.
Aspoň je co analyzovat. Po vás není co analyzovat, protože do logu raději nic nezapíšete, aby to náhodou nemohlo být interpretováno špatně.

Aspoň je co analyzovat. Po vás není co analyzovat, protože do logu raději nic nezapíšete, aby to náhodou nemohlo být interpretováno špatně. A to je napsáno kde? Je rozdíl mezi (když máte layout [username] msg):

[jirsak] Invalid login

a

[] Invalid login with username jirsak

To první je nepravdivá informace, která musí být analyzována. U toho druhého nic takového dělat nemusíte. Takže ano není co analyzovat, protože je to jasné na rozdíl od vašeho nesmyslu, kde pak musíte řešit zda to opravdu byl jirsak nebo někdo, kdo se za něho vydával.

20. 12. 2021, 16:10 editováno autorem komentáře

To je ale váš problém, že ta data špatně interpretujete. Špatně můžete interpretovat i ten váš zápis.

Ne to nemůžete špatně interpretovat. Ten váš zápis má, ale dvě interpretace a nemáte šanci poznat, která je správná. Navíc tvrdit, že něco udělal user, který není autentizovaný je úplně mimo.

Oba dva zápisy se dají interpretovat mnoha různými způsoby. Pokud si nejsem jistý, která interpretace je správná, musím se podívat do dokumentace nebo i do zdrojáků.

Navíc tvrdit, že něco udělal user, který není autentizovaný je úplně mimo.
To ale pořád tvrdíte jen vy. Já tvrdím jenom to, že tohle jméno bylo uvedeno jako součást požadavku. To, že to byl opravdu daný uživatel, je jenom vaše interpretace.

Ne jenom ten váš se dá interpretovat mnoha způsoby a musí být následně analyzováno zda ty informace jsou pravdivé.

To ale pořád tvrdíte jen vy. Já tvrdím jenom to, že tohle jméno bylo uvedeno jako součást požadavku. To, že to byl opravdu daný uživatel, je jenom vaše interpretace.
Ne to je normální praxe. Pokud to děláte jinak, tak je to váš problém a zaděláváte si tím do budoucna, protože to někdo nezná a může to špatně interpretovat. Vezmu si napomoc třeba Spring Security (ale je to obecně všude obdobné Jakarta EE, Micronaut atp.), přece když je uživatel nevalidní/neau­tentikovaný, tak se vám nevytvoří security context s nevalidním uživatelem tj. nenaplní se vám SecurityContext abyste pak dále mohl s tímto contextem dále pracovat a prohlašovat, že to dělá tenhle uživatel. Nedělá se to už jenom z toho důvodu, že to může někdo špatně interpretovat. Co by vás možná mohlo trknout je tenhle log, který je totální nesmysl:

[jirsak] /deletedb - 401 Unauthorized

vs

[] /deletedb - 401 Unauthorized

Teď jistě namítnete, že to nemáte jak poznat, k čemu to patří, ale to je zase úplně jiná debata o tracing.

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

Saljack: To, že vy něco děláte špatně, vážně nedokazuje, že to tak musí dělat všichni. Já nevidím nic špatného na tom, že do kontextu vložím nejprve třeba UsernameFromHTTPRe­quest a když uživatele ověřím, tohle z kontextu vyhodím a přidám tam Username. Že vy jste si usmyslel, že neověřené a ověřené uživatelské jméno musí být v kontextu pod jedním klíčem, to je váš problém.

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

Fajn. Teď v té větě zkuste ještě najít slovo „Logback“.

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

20. 12. 2021, 15:16 editováno autorem komentáře

Ano, dal jste na hromadu všechny chyby v Logbacku a na druhou hromadu všechny chyby v Log4j. Aniž byste rozlišoval závažnost těch chyb. Což se dá také jinak vyjádřit uvedenou otázkou, jestli opravdu házíte na jednu hromadu chyby se skórem 1 i 10.

Ani náhodou, ten kontext byl naprosto jasný a opět se to akorát snažíte překrucovat (jak je u vás zvykem) nebo jste opět napsal totální blábol. Navíc jsem nikde netvrdil, že to házím na jednu hromadu (možná to děláte vy ve vaší hlavě) a stojím si za tím, že těch chyb bylo do log4shell +- stejně se stejným podobným score.

Ano, kontext byl naprosto jasný – mluvil jste o všech chybách v Logbacku a Log4j. A já jsem na to opáčil, že tam mohou být chyby z celé stupnice – nevím, zda v Logbacku nebo Log4j byla nalezena nějaká chyba s hodnocením 1 – je možné, že by se v takovém případě někdo ani neobtěžoval s přiřazením CVE. Ale nešlo o konkrétní chybu, šlo o všechny chyby.

To, že log4shell nepočítáte, je novinka. Chyb možná bylo stejně, protože v logovacím frameworku málokdo hledal bezpečnostní chyby – až do log4shell asi nikoho nenapadlo, že by logovací framework mohl být tak špatně navržený, jako Log4j 2. Každopádně vynechávat při hodnocení bezpečnosti jednu z celkově nejzávažnějších chyb posledních let, to je opravdu pozoruhodný výkon.

Ale je to vaše věc a váš problém, že nevidíte, že Log4j 2 má tu nebezpečnost zakódovanou v sobě – je to už v samotné definici cílů, co má Log4j 2 splňovat. Log4j 2 bylo nebezpečné už před tím, než se napsal první řádek kódu.

Ano, kontext byl naprosto jasný – mluvil jste o všech chybách v Logbacku a Log4j. A já jsem na to opáčil, že tam mohou být chyby z celé stupnice – nevím, zda v Logbacku nebo Log4j byla nalezena nějaká chyba s hodnocením 1 – je možné, že by se v takovém případě někdo ani neobtěžoval s přiřazením CVE. Ale nešlo o konkrétní chybu, šlo o všechny chyby.
Takže jste opět reagoval úplně na něco jiného a převzal jste si to po svém jako vždy. Obě knihovny obsahovaly chyby i se score 7 to je fakt.

To, že log4shell nepočítáte, je novinka. Chyb možná bylo stejně, protože v logovacím frameworku málokdo hledal bezpečnostní chyby – až do log4shell asi nikoho nenapadlo, že by logovací framework mohl být tak špatně navržený, jako Log4j 2. Každopádně vynechávat při hodnocení bezpečnosti jednu z celkově nejzávažnějších chyb posledních let, to je opravdu pozoruhodný výkon.
Opět překrucujete a nikde jsem to netvrdil. Jenom jsem napsal, že ty knihovny do objevení log4shell měli stejné/podobné bezpečnostní problémy. To, že logback měl JNDI a jiné appendery, které náhle odstranil jenom ukazuje, že ani je netrklo, že něco takového může nastat.

Obě knihovny obsahovaly chyby i se score 7 to je fakt.
Ale fakt, který se pořád snažíte nevidět, je to, že jenom jedna knihovna obsahuje chybu se skóre 10.

Jenom jsem napsal, že ty knihovny do objevení log4shell měli stejné/podobné bezpečnostní problémy.
Ne, log4shell byl v knihovně Log4j 2 od začátku. Nepleťte si to, zda bezpečnostní problém existuje nebo zda o něm víme.

To, že logback měl JNDI a jiné appendery, které náhle odstranil jenom ukazuje, že ani je netrklo, že něco takového může nastat.
Jenomže rozdíl je v tom něco takového. V případě Logbacku něco takového znamená, že provozovatel tu aplikaci špatně nakonfiguruje, nebo dokonce dovolí uživateli změnit konfiguraci. V případě Log4j 2 autory nenapadlo, že se v logovacích zprávách může objevit vstup od uživatele, který by bylo nutné validovat před tím, než bude nějak interpretován. A nikoho jiného zase nenapadlo, že by logovací knihovna mohla interpretovat logovací zprávy nějak víc, než že interpretuje co nejjednodušším způsobem formátovací string logovací zprávy.

Proč myslíte, že slf4j jako zástup pro argumenty ve formátovacím stringu používá {} a neumožňuje ani měnit pořadí argumentů, ani určovat jejich formát? Proč nepoužívá String.format nebo MessageFormat nebo něco podobného? Právě proto, aby interpretace formátovacího řetězce byla co nejjednodušší a co nejvíc se zmenšilo riziko chyb a režie kódu.

Důvod, proč se na chybu log4shell nepřišlo dřív, je ten, že nikoho příčetného nenapadlo, že by k tomuhle logovací knihovna mohla přistupovat jinak. Tohle je prostě zásadní chyba v návrhu Log4j 2 a zoufalá snaha posledních verzí tuhle funkcionalitu v knihovně udržet svědčí akorát o tom, že autoři nepochopili, v čem je podstata problému. Což je ta největší diskvalifikace Log4j 2 – CVE jsou chyby, o kterých už se ví a ty se dříve či později opraví. Může se objevit i CVE s vysokým skóre v projektu, který na bezpečnost dbá – prostě někde něco ulítne. Takové chyby má třeba i linuxové jádro a není to proto, že by to dělali matlalové. Pro mne je důležitější to, jaké jsou v projektu chyby, o kterých ještě nevíme. Z minulých CVE se snažím odhadovat, jaké je riziko budoucích CVE. Na Log4j 2 mi nevadí to jedno minulé CVE se skórem 10. Vadí mi to, že je to chyba v návrhu, ze které se autoři nijak nepoučili a snaží se to teď nějak látat. Nejspíš to postupně zalátají tak, že už nikoho nebude bavit hledat tam další chyby. Což ale pro mne nebude znamenat, že bych tu knihovnu považoval za bezpečnou.

Ale fakt, který se pořád snažíte nevidět, je to, že jenom jedna knihovna obsahuje chybu se skóre 10.
1. lžete protože ta chyba byla opravena 2. nikdy jsem nic takového netvrdil. Jak už jsem psal ta knihovna by měla mít různé moduly/pluginy, které si každý kdo je chce může přidat. Nikdy jsem se nevyjadřoval k tomu, že transformovat log message jakkoliv je nesmysl a myslím, že to ani není potřeba komentovat, to je každému jasné.

Ne, log4shell byl v knihovně Log4j 2 od začátku. Nepleťte si to, zda bezpečnostní problém existuje nebo zda o něm víme.
To lze ale aplikovat i na logback nebo cokoliv jiného.