Vlákno názorů k článku
Log4j 2.15.0 a 1.x jsou stále zranitelné, aktualizujte na 2.16.0
od cc - Myslím, že ta chyba a diskuze tady celkem...
-
Každý cpe do projektů knihovny, co umí všechno a mají desítky MB, aby pak použil 0.001% funkcionality a pak řešil CVE v podpoře něčeho co stejně nikdy nepotřeboval.
Fakt to nechápu, proč v Javě, kde package management je celkem v pohodě, lidi neumí udělat knihovny, které hezky definují interface a umožní tu funkcionalitu rozšířit i mimo tu knihovnu. Ale to asi není dost enterprise!
-
Filip JirsákStříbrný podporovatelTo, že takové knihovny neznáte, neznamená, že neexistují. Dokonce jsou docela běžné.
-
Problem je ze vy skutocne nechapete. Mate niekolko log frameworkov vacsina ma skutocne iba interface a skutocny vykon logovania mozu robit rozne implementacia. Takychto wrapperov je niekolko, SLF4J, Apache commons logging, ... a niekolko frameworkov ako log4j2 ktore sa az tak velmi nedaju ohybat. Problemy nastavaju ak integrujete niekolko kniznic pricom kazda pouziva iny log framework a vy chcete mat nejaku jednotnu spravu logovania. Pre mna je idealny SLF4J ktory ma implementaciu aj napriklad pre log4j a dokaze ho bridgovat na logback ale nie vzdy to ide a nie vzdy sa to da. Pretoze dochadzalo ku konfliktom medzi napriklad java servrami ako je tomcat, weblogic a aplikaciami tak si niektore firmy urobili kopiu logovacieho frameworku a presunuli do inehe package aby k tymto konfliktom nedochadzalo. Je to relativne komplikovany a komplexny problem.
Takze napriklad to ze na classpath nemate log4j neznamena ze niekde neciha premenovana nejaka stara verzia log4j v internom baliku (liferay napriklad). Takze ked sme uz trosku do toho nazreli este stale sme sa nedostali ku skutocnym problemom ako to opravit lebo opravit standardny balik je este relativne jednoduche oproti tomu opravit nejaku ohnutu verziu ktora si ciha v nejako servri a slabsi admin o nich ani nevie. A verte ze to este caka po oprave tych standardnych kniznic. -
Filip JirsákStříbrný podporovatel
Ano, můžete si vybrat takovou knihovnu, jaká vám vyhovuje. Pro někoho je to asi moc náročné.
-
Rozhodně to není problém Javy a jejího ekosystému.
1) Chyby jsou všude
2) Že se rozšířila demogogie mezi ne zcela svéprávnými programátory, že využívání cizích knihoven je "cool" a "trendy", a z toho plynoucí výšší riziko cizích chyb ve vašem projektu se ignorovalo, není problém Javy
3) Že díky buildovacím nástrojům typy Maven,Grandle a systému závislostí došlo ke zvýšení nepřehlednosti používáných knihoven v projektu, drastickému zvětšení velikostí projektů a tvz. classpathhell bylo způsobeho hlavně leností některých vývojářů, opět není problémem Javy.Zde pouze selhal lidský faktor, kde egocentrisus, ješitnost a lennost zvýtězila nad opatrností. Navíc stále ještě hraje roli, pozůstatek 90tek kdy do nativních jazyků kdy dominovaly desktopové aplikace šli lepší programátoři a na Javu většinou zbyli programátoři druhé kategorie.
-
Filip JirsákStříbrný podporovatel
Že se rozšířila demogogie mezi ne zcela svéprávnými programátory, že využívání cizích knihoven je "cool" a "trendy", a z toho plynoucí výšší riziko cizích chyb ve vašem projektu se ignorovalo, není problém Javy
Vůbec nejde o to, že by to bylo cool a trendy. Využívání sdílených knihoven je správné, protože je to kód, kterému se věnuje mnohem více pozornosti, než když tu samou funkcionalitu implementujete sám. Nejde o žádné riziko cizích chyb – riziko chyb je naopak menší, protože ten kód vidí víc lidí.Ne zcela svéprávní programátoři si myslí, že si všechno sami napíšou nejlépe a že je to nejefektivnější, když si to napíšou sami.
-
L.Stříbrný podporovatel
> Ne zcela svéprávní programátoři si myslí, že si všechno sami napíšou nejlépe a že je to nejefektivnější, když si to napíšou sami.
Dokonce to má jméno - NIH syndrom - Not Invented Here syndrom.
-
Filip JirsákStříbrný podporovatel
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.
-
L.Stříbrný podporovatel
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).
-
L.Stříbrný podporovatel
> 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.
-
"Nejde o žádné riziko cizích chyb – riziko chyb je naopak menší, protože ten kód vidí víc lidí."
Zbožné přání. Používání cizích řešení urychlý projekt, ušetří práci ale zvyšuje se riziko objevení cizích chyb = zhoršuje se bezpečnost. Nikdy nevíš kdo to programoval, nevíš jak je to kvalitní vývojář a kde jsou jeho slabiny kde tedy mohou vznikat chyby a tedy kde si na co dát pozor. Nejedná se o lineární závislost ale růst zde rozhodně je. A věřejná kontrola? Stejné jako s OpenSource, kdo z vás někdy kontroloval zdrojáky cizích projektů? Na např. Windows vs Linux (private vs public) jde vidět obou vývojovým konceptům se chyby nevyhnou.
Platí :
Tvůj projekt + tvoje knihovny = tvoje chyby
Tvůj projekt + cizí knihovny = tvoje chyby nebo nadřízeného jenž rozhodl o jejich používání. -
Filip JirsákStříbrný podporovatel
technomaniak: Vaše představa, že ostatní dělají více chyb, než vy, je chybná. Je úplně jedno, čí ta chyba je, jestli vaše nebo cizí, pořád je to chyba.
U open source nejde o to, že by někdo programově kontroloval jeho zdrojáky. 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á. Nemusí to být proto, že tam hledá chybu, ale třeba potřebuje vědět, jak je to napsané. Prostě když něco může vidět víc očí, zvyšuje se pravděpodobnost, že si někdo chyby všimne.
-
Filip JirsákStříbrný podporovatel
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. -
Filip JirsákStříbrný podporovatel
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. -
Filip JirsákStříbrný podporovatel
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?
-
Filip JirsákStříbrný podporovatel
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.
-
Ja bych rekl, ze naprosta vetsina projektu je tercem automatizovanych utoku cilicich na zname zranitelnosti. Proto je to pro ne presne naopak, nez pises - samodomo knihovna s 1000 radku bude bezpecnejsi protoze security by obscurity v tomto pripade zafunguje dobre.
Instituce jako banka, ktera by mohla byt tercem cileneho utoku, by zase nemela neauditovany moloch jako log4j pouzivat vubec.
Takze by to nemel ve vysledku pouzivat nikdo :-)
-
To je pouze vaše iluze, že je to bezpečnější. Stačí aby někde unikli zdrojové kódy a vaše security by obscurity je totálně v loji a klidně se vsadím, že tam budou možná ještě horší chyby než v řadě open source knihovnách. A že ty kódy se někde povalují je celkem normální, když banka má stovky vývojářů, že jeden to vynese a nemusí to být ani se špatným úmyslem. A pak co? Zahodíte celý codebase? Navíc log4j 2 bude nyní celkem prozkoumaný, takže bych se toho opravdu vůbec nebál.
-
Filip JirsákStříbrný podporovatel
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. -
Filip JirsákStříbrný podporovatel
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.
