Vlákno názorů k článku
Log4j 2.15.0 a 1.x jsou stále zranitelné, aktualizujte na 2.16.0 od Keltek - Jestli tomu správně dle popisu CVE rozumím, tak...

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.