Log4Shell Update: Publikáltak egy második log4j sebezhetőséget

Címkék
After the log4j maintainers released version 2.15.0 to address the Log4Shell vulnerability, an additional attack vector was identified and reported in CVE-2021-45046.
Részletek, technikai leírás stb. itt.

Hozzászólások

Kezd kicsit Monty Pythonosra fordulni a sztori...

Gábriel Ákos

Amikor ezt olvasom egy security vendor honlapján, hogy:

This vulnerability is a big concern for the security community because, firstly, it is already exploited in the wild and secondly, updates of all concerned software may take a long time.
Some experts think it may need several years to update every impacted software.

trey @ gépház

Tapasztalatom az, hogy ezek a típusú döntések "fel vannak dobva" aztán sose esnek le, mindenkinél csak minimális ideig vannak, mint a "forró krumpli" úgy dobálják. 

Általában akkor esik le amikor - finally - a szállító meghozza a patchet ami szükségtelenné teszi a döntést.

Ekkor ez konstatálva van és végre "leesik" az ügy - természetesen mint jól megoldott probléma.

Gábriel Ákos

Aki nem tartotta be az SZMSZ-t. Mivel mindenki betartotta ezért senki nem vonható felelősségre (mármint cégen belül).
Az nyilván szerződésfüggő hogy a vendor-on leverhető-e a balhé, általában nyilván nem.

Viszont ha saját hatáskörben megpatcheled a bármit, és _ezután_ történik a (már nem supportált) rendszerrel bármi, akkor garantáltan téged tesznek ki száradni.

End of story.

Félreértések elkerülése végett: minden nagy cég így működik, nem csak a bankok.

Gábriel Ákos

"Az nyilván szerződésfüggő hogy a vendor-on leverhető-e a balhé, általában nyilván nem."

Főleg egy open-source szoftver esetén nem jól definiált, hogy ki a vendor, aki felelősséget vállalna, de eleve a licencfeltételek kizárnak mindenféle felelősséget általában.

Itt a vendor általában nem log4jt adott, hanem valamit, amiben ő azt használta. A teljes opensource izéket meg épp ezért nem szeretik, és van a technikai emberek által lesajnált "csak a support miatt vették meg a hülyék, amit úgyse használunk" megoldás sokszor.

De akkor a saját IT cég felel azért, hogy az upstreamben lévő biztonsági hibákat felderíti és javítja? Mert ha nem, akkor az csak névleges támogatás és nem tényleges. Az, hogy valaki papíron vendor, még nem jelenti azt, hogy meg is lesz oldva a biztonsági probléma.

Azzal, hogy valami csak papíron vendor, semmilyen kockázat nincs kezelve, csak felelősség van áthárítva. Ez nem kockázatkezelés. Ha probléma van, megoldódni semmi nem fog, de lehet mutogatni a papírra. Menedzserek számára jól hangzik, de amikor tényleg beüt valamilyen biztonsági hiba, akkor meg mindenki néz ki a fejéből. Hamis biztonságérzet.

pont ezekben az esetekben jól definiált. hiszen a lincenben benne van, hogy nem vállalnak semmilyen felelőséget.

Egyértelműen az a vendor, aki a fizetős termékébe/szolgáltatásába beletette/használta ezeket a libeket. pont.

 

szerintem.

Ez ennek a velejárója. A képlet:

 

Végy egy random (sokak által hásznált) szoftvert/komponenst és találj benne egy hibát.

Csinálj neki egy kicsit nagyobb hype-ot.

Az összes biztonsági szakértő, script kiddie, programozó egyből rárepül és fedezik fel a többi hibát.

"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"

... most a log4j egy darabig jó lesz. :)

Pénteken volt egy olyan érzésem h szólni kéne h várjunk még pár napot a nagyüzemi peccseléssel, de miután az AWS is közölte, hogy máris peccselnek/peccseltek, nem mertem megkockáztatni. Aztán tessék.

Persze lehet mondani h az itsec ilyen szakma, de amúgy nem kéne h ilyen legyen. 
Valahogy úgy érzem ez az apache foundation-nek egy elég nagy blama, pontosan nem tudom mit adnak a projektjeiknek - lehet h semmit - de egy ekkora névhez sztem hozzá kéne tartozzon némi színvonal ha már egy x projektet a nevük alá vesznek.

Gábriel Ákos

nálunk ilyen eszetlen kapkodáskor valaki mindig bejátszotta a benny hill theme song-ot csapattagok között. Hetente lehetett hallani. Sajnos a marhák a middle mgmt-ben nem hallották, amúgysem értették/értékelték volna. Fejetlen csirke módjára jajveszékelve rohangál a menedzsment minden bazdmegnél, hiába járatja rongyosra a pofáját a barom mérnök, ha sokba kerül, a probléma  nem lesz megoldva. Aztán karácsony este jön a POC. Akit akkor el tudnak érni, mert volt olyan barom és nem kapcsolta ki a telefonját, az beszopta.

Log4j 2.16.0 completely mitigates this issue by removing support for message lookup patterns and disabling JNDI functionality by default.

Ilyenkor mindig felmerül bennem a kérdés, hogy ezeket a 'nélkülözhetetlen' fícsöröket valóban használta bárki is a hackereken kívül? :)

Mert a Develops bucikának nagyon drága ám az ideje (tőlük tudom), és nem tud ilyen picsogásokkal foglalkozni, minthogy dokumentáció, meg amit kell azt bekapcsolni. Justworks, plugandplay, ja és turnkeysolution kell kérem, kerülamibe kerül, pláne, hogy ő már 1-2 év múlva úgyis máshol lesz mégokosabb.

Fontos hozzatenni, hogy csak PatternLayout hasznalata eseten all fenn a problema. JsonLayout pl. hibamentes, igy a cloud -ban pl, ahol tobbnyire json alaput hasznalnak, nincsen gond.

Ahogy én értem a hibát úgy lehet kihasználni, ha valaki a pattern-t string concat-tal állítja elő, nem használja a {} paraméter behelyettesítést. Az mondjuk tény, hogy eléggé sok helyen valóban szarul állítják össze a pattern-t, de ilyet már látott az informatika: sql injection, command line injection, stb. Nyilván az sem előnyös, ha a String.format-nak a formátum stringje konkatenációval áll elő, és a user-t pedig "Pistike%s"-nek hívják.

Ezen én is elgondolkoztam, az önmagában egy súlyos hibának tűnik, ha a Log4j rekurzívan értelmezi a kapott stringet. Akkor egy üres JSON objektum logolása is problémát okozhatna. Van erről valahol infó, hogy helyesen alkalmazott értékbehelyettesítés esetén is sebezhető a Log4j?

Van erről valahol infó, hogy helyesen alkalmazott értékbehelyettesítés esetén is sebezhető a Log4j?

Nincs, de a leírásban is olyan példát hoznak, ami amúgy egy Log4j antipattern (string konkatenáció az üzenetben). De az is igaz, hogy amelyik projektre rátettek a munkahelyemen ott 90%-ban konkatenálás történik.

Log4Shell Update: Publikáltak egy második log4j sebezhetőséget

Akkor ez most már a harmadik?