- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Mint, amikor az Intel sebezhetosegeit kezdtek kapargatni. Most erre fokuszal a vilag...
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
A szomorú az egészben, hogy igaza van. Sajnos rengeteg olyan szoftver kering a világban, amik használják és soknak a támogatása már megszűnt, vagy egyéb okok miatt verzió lock van Java oldalról.
"Errors are red
My screen in blue
Someone help me
I've deleted Sys32"
- A hozzászóláshoz be kell jelentkezni
Nekem nem kell mesélni, pontosan tisztában vagyok vele. Szerinted mivel töltjük a napjainkat? Azzal, hogy felméréseket készítünk vállalatoknál, hogy az ezer éves szarjaikkal mi lesz.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Mondjuk nem nagy ugy a log4j lib-et kicserelni egy meglevo jar/war -ban az ujabbra. Zip file-ban elozo verzio class-ait torli, ujabb verzio class-ait bemasol, kesz. Az API-ja nem(igen) valtozott a log4j2 -nek, szoval 98%-ban mennie kell.
- A hozzászóláshoz be kell jelentkezni
Es a maradek 2%-al mi lesz? Titkositjuk 50 evre?
- A hozzászóláshoz be kell jelentkezni
Persze.... Ez így megy, hogy hipphopp túrkálunk a 3rd party fizetős app warjar csodafilejaiban.
- A hozzászóláshoz be kell jelentkezni
Nem kell ehhez túl nagy expertnek lenni csak egy picit bankban dolgozni.
Bármiféle "unsupported" saját kezű változtatás ki van zárva, tekintet nélkül arra, hogy ezzel nyitva hagyunk egy jól ismert security lukat kb. akármeddig.
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni
tekintet nélkül arra, hogy ezzel nyitva hagyunk egy jól ismert security lukat kb. akármeddig.
Ki hozza meg a felelős döntést erről?
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
MNB-s szabályozás definiálja mi az a supportált termék.
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
És mi van, ha közben kihasználják a hibát? Akkor ki viszi el a balhét?
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
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
- A hozzászóláshoz be kell jelentkezni
Tudom, hogy hogyan működik, csak kíváncsi voltam, hogy egy hogy néz ki leírva :D
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Annyival kiegészíteném hogy ha a vezér extra jó fej és előre egyeztetted h mit csinálsz, egyértelmű a jó szándék akkor lehet hogy megvéd. Mert erre is van pont az SZMSZ-ben :)
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni
Nem, mi nem igy csinaljuk.
De az is igaz, hogy nalunk dolgozik a log4j egyik contributora. :D
- A hozzászóláshoz be kell jelentkezni
Ahogy hallottam, az nagy szó, mert vannak vagy ketten összesen :D :D :D
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
"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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Banknál nem így van, per def minden szoftvernek supportáltnak kell lennie, azaz mindegyikhez van egy vendor.
Van hogy ez a saját IT cég, de akkor is van vendor.
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Jól látod, papíron kell vendornak lennie. Ez rizikó management, semmi más.
Léteznek erre egyébként szakmailag többé-kevésbé legitim megoldások is, pl. a csupa-luk webes motyó elé odateszel egy jó WAF-ot.
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Ha probléma van, megoldódni semmi nem fog, de lehet mutogatni a papírra.
Az pont elég. Nem igazán értem, hogy mi lenne szerinted megnyugtató egy ilyen helyzetben.
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Ha van néhány szakember (aki tud mondjuk google-zni) az adott cégnél akkor simán elég lehet szakmailag is.
Egyik-másik "nagy brand" supportja úgy konkrétan fabatkát se ér.
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Erről ez a story jut eszembe. Akkor is jó, ha fiktív.
- A hozzászóláshoz be kell jelentkezni
Szerintem ilyen faszokkal teli történetet nem lehet kitalálni, ezt a való élet kellett szülje.
- A hozzászóláshoz be kell jelentkezni
Khm. TI még mindig? :D
- A hozzászóláshoz be kell jelentkezni
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"
- A hozzászóláshoz be kell jelentkezni
Jó trükk. Advanced változat: tegyél bele egy hibát. Rárepülnek a szakértők és megcsinálják a többi munkát is helyetted :-)
- A hozzászóláshoz be kell jelentkezni
... 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
- A hozzászóláshoz be kell jelentkezni
ez nem hype. mar elesben kihasznaljak, napok ota, RCE-znek.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
Log4j
2.16.0
completely mitigates this issue byremoving 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? :)
- A hozzászóláshoz be kell jelentkezni
.. és miért nem az a default, hogy ki van kapcsolva? :)
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
A kis Bobby,drop table :)
- A hozzászóláshoz be kell jelentkezni
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?
- A hozzászóláshoz be kell jelentkezni
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.
- A hozzászóláshoz be kell jelentkezni
concatenate-re van értelmes magyar elnevezés? Összeillesztés? Egymásutánragasztás?
- A hozzászóláshoz be kell jelentkezni
Összefűzés? Bár az jelenthet zip-et is.
- A hozzászóláshoz be kell jelentkezni
magyar ekszel valaki?
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Nálam megy épp, azonban az AWS megint gyengélkedik, lehet azzal van összefüggésben.
- A hozzászóláshoz be kell jelentkezni
Nah, íme. Ehhez is elég tökösnek kell lenni mondjuk :)
Gábriel Ákos
- A hozzászóláshoz be kell jelentkezni
Kíváncsi lennék arra a vállalatra ahol ez belefér a policybe.
-pilisig-
- A hozzászóláshoz be kell jelentkezni
Szintén: Logout4Shell.
- A hozzászóláshoz be kell jelentkezni
A kétfarkúakat tudnám idézni:
olyan aranyos, biztos nem akar lopni!
https://www.deviantart.com/res2000/art/Olyan-aranyos-biztos-nem-akar-lo…
- A hozzászóláshoz be kell jelentkezni
Log4Shell Update: Publikáltak egy második log4j sebezhetőséget
Akkor ez most már a harmadik?
- A hozzászóláshoz be kell jelentkezni
Igen, van már 2.17 is...
- A hozzászóláshoz be kell jelentkezni