Het blijft maar doorgaan. Dit wordt bijna een dagelijks klusje. Tegen de tijd dat je alles geupdate hebt, kun je met de volgende rond starten. Eindeloos.

Voor Linux Ubuntu kan de volgende Terminal opdracht ingegeven worden.


Dan volgt op het scherm of je de kwetsbare versie op je systeem hebt of niet.

Meer fixes met CVE-nummers vindt men op:
https://wiki.ubuntu.com/SecurityTeam/KnowledgeBase/Log4Shell

Begint een beetje op Exchange en LPR? te lijken

Het allerergste is dat als je door al die rijstebreiwerken van updates heen bent, je al lang vergeten bent wat je ook al weer ZELF wou doen met die software!

Hmmm... Weer updaten; dit begint - inderdaad - onderhand enigszins irritant te worden.

Corona-achtig...

Ben wel benieuwd waarom die beveiligingslekken gemaakt worden.

Bij het fixen van vulnerabilities is het dan ook veel te veel een kwestie van brandjes blussen ipv. kijken waar de aansteker ligt.

ik zou me kunnen voorstellen dat iedereen die de vorige CVE's serieus nam, nu wel weet waar zijn of haar 2.17.0'en uithangen, en patchen vergeleken met de vorige een fluitje van een cent is.

Wat zijn we weer negatief...
Is patch management niet altijd een taak die je geregeld moet uitvoeren waarbij je kijkt naar de impact voor jouw organisatie en dan bepaald hoe snel je dit wilt/moet oppakken?
Dit zou dus gewoon in een standaard proces meegenomen moeten worden. Als je dit proces niet hebt ingericht, snap ik jullie reactie, maar dan ligt mijns inzien het probleem bij jullie (organisatie) en niet bij hoe vaak er een update komt...

Nee, het is de frequentie waarmee die gaten nu ontdekt worden. Dat vergt uiteindelijk hoe dan ook extra tijd omdat alles weer gepatcht én getest moet worden.
Ook al heb je je proces ingericht, dan nog zijn het elke keer extra handelingen, die bovenop het andere werk komen. En waarbij we deels ook weer afhankelijk zijn van leveranciers met hun eigen hot-fixes of patches.
En dat in een periode met minder bezetting agv de feestdagen en vakanties. :-)
Je komt nu niet aan het geplande werk toe, door steeds maar weer dit soort brandjes te moeten blijven blussen.

En het lijkt wel whack-a-mole. Het blijft maar doorgaan.

Hoeveel gaten kan 1 module eigenlijk maximaal bevatten? Is het einde al in zicht?
(how many angels can dance on the head of a pin)

En nog belangrijker:
Weet iemand of Apache de hele module op korte termijn nog een keer van de grond af aan veilig gaat herbouwen.
Dat lijkt me uiteindelijk een efficiëntere oplossing.

Dat natuurlijk inderdaad wel maar ik vind het toch irritant worden.

Er zijn nu zoveel mensen in de wereld die naar dit stukje software kijken ... dat de kans natuurlijk veel groter is ... dat er nog iets kwetsbaars wordt gevonden....

Als de wereld klaar is met log4j ... dan is het , het meest veilige stukje software .... tot de volgende patch uitkomt :D

Dat is juist het hele probleem. De module is niet door Apache geschreven maar door een clubje hobbyisten ('community-driven repository').
https://www.nrc.nl/nieuws/2021/12/14/log4j-hoe-zes-mensen-het-web-moeten-redden-a4068878

Gaat inmiddels niet 80% van de tijd in dit soort "onderhoud" zitten: impact in kaart brenegen, deployment in acceptatie, testen, deployment in productie. en weer opnieuw..
Je moet je afvragen of het gehele deployment proces van incomplete software niet anders kan & of er niet strengere eisen aan software (doet het wat het moet doen en niets anders: referentie uit het verleden Edsger Dijkstra) gesteld moeten worden.

Er is geen probleem want log4j zit best goed in elkaar (op een paar probleempjes na maar die worden er nu snel uitgehaald). En de software is door trained professionals geschreven. Weliswaar in hun vrije tijd maar dat is vanuit hun idealen en alleen maar bewonderingswaardig. Nee, als je dergelijke gratis beschikbaar gestelde software gebruikt dan moet je kijken naar hoe het is gesteld met onderhoud en ondersteuning en je kan beter voorbereid zijn op het moeten installeren van nieuwe versies in geval van problemen. Je bent toch geen scriptkiddie?

Jij bent blijkbaar wel een scriptkiddie want je copy-paste inherent onveilige code mee in je eigen product en zit nu constant te updaten.
Veel succes daarmeee.

Daarom zitten we nu al weer op een nieuwe versie?

Kwaliteit past anders redelijk bij consumenten software. Als je zoveel grote bugs vind in zo'n korte tijd, dan is er het nodige mee mis.

Hier zie je dus ook mooi direct wat open source kan betekenen.

Maar je kunt inderdaad maar beter voorbereid zijn, waarschijnlijk is dit nog niet de laatste bug die gevonden is/was?
Blijkbaar is de kwaliteit van dit stukje software, wat overal in het enterprise segment gebruikt wordt, kwalitatief uitermate teleurstellend.
Ondanks dat iedereen de code kon zien, zijn er in zeer korte tijd heel veel grote fouten gevonden, nadat er een nieuwe versie gereleased was.

Heel de bedrijfswereld was voorbereid op het implementeren van updates en fixes. Toch werden ze met de broek op de enkels betrapt toen deze reeks aan kwetsbaarheden boven water kwamen en dit per gisteren allemaal gerepareerd moest worden.
Want het was toen niet duidelijk waar het allemaal in verstopt zat. En ook leveranciers van software hadden moeite om hun software park helemaal door te lichten. (en zeker grote jongens als bv IBM)

Met elke nieuw lek, moet er weer een fix of update geïmplementeerd worden.
Op zich niets mis mee, maar met beperkte bezetting én bijna dagelijks nieuwe lekken, hakt dat er toch in. Vooral omdat nu blijkt dat het in veel systemen verborgen zat.
En die kun je dan meestal niet allemaal in een keer updaten, omdat leveranciers weer verschillende protocollen en uitlever mechanismen hebben, waar je ook weer rekening mee moet houden.
En ja, dan gaat het de keel uit hangen.

We zijn aan het einde van het jaar.
Dan staan er bij ons (andere) reguliere eindejaars werkzaamheden gepland die ook uitgevoerd moeten worden.
Die komen nu keer op keer in de verdrukking. Wat dan weer overwerken betekent.
En dat vindt het thuisfront ook hééél leuk.
Vooral met kerst en 31 december.

Ja misschien toch maar eens een beter distribuitiemechanisme regelen he?
Onee, daar is Toje tegen. Of hij denkt dat dat niet kan.
Hopelijk dat de rest van de wereld het alsnog oppakt.

Heeft niks met open source te maken. Als het closed source was geweest had men het nog een tijdje kunnen uitbuiten.
Gelukkig is het wel opensource en kan men er naar kijken om het op te lossen en of het opgelost is.

Geen professional die 300.000+ regels code gaat 'reviewen' met de verwachting iets te vinden. Door het open source zijn van log4j zijn de problemen echter wel veel sneller en beter opgelost dan bij closed source het geval zou zijn geweest. Dan had je er niets van gehoord totdat het echt niet anders kon en dan had je moeten wachten op die magische dinsdag.

En log4j zit best goed in elkaar (op een paar probleempjes na maar die worden er nu snel uitgehaald).


Copy-paste van onveilige code? Waar heb je het nou weer over? Zit het hier dan vol met scriptkiddies die geen verstand hebben van moderne softwareontwikkeling?


En stug volhouden dat het een distributieprobleem zou zijn, tegen de feiten in. #wappie

Mijn windows collega's zijn er maar druk mee. Ik ben al lang klaar omdat de applicatie beheerder het pakketje heeft gebruikt wat mee komt met OS packagemanagement.

als je je netwerkverkeer en admin rechten goed beheerd heb je nergens last van. Als je alles openzet en direct naar vanuit het internet naar je applicatie server kan zonder proxies / dmz / router / gateways en firewalls tja dan heb je een probleem. verdere problemen zijn niet anders dat je op een server kan komen en daar met admin rechten trollen...

Dus is eigenlijk een wassen neus dat iedereen de code kan zien?

Je bedoelt sneller en beter, als in de 1ste, de 2de, 3de of .... fix binnen 2 weken? Ik weet niet eens meer hoeveel versies ze nu uitgebracht hebben.

Het is maar wat je probleempjes noemt, beetje onderschatting van het probleem denk ik. Het internet staat in brand, code rood bij menig bedrijf en jij noemt dit een paar probleempjes?

Ik heb al met diverse klanten overleg gehad, om servers maar gewoon uit te zetten om geen risico te nemen, preventief wachtwoorden te resetten voor gebruikers, scans moeten regelen om deze jar files te vinden op het applicatie servers of op de desktops. En dan waren er al cloud applicatie servers down waar men gebruik van maakte.

Ik had het rustiger met de Exchange patches dan met deze ellende.

Nee, hoezo? Het gaat erom dat je de broncode 'hebt' en niet afhankelijk bent van een louche softwarebedrijf dat alles wat geld kost zo lang mogelijk zal uitstellen (in ieder geval tot patchdinsdag). De gedachte dat je in staat zou zijn om eventjes door 300.000+ regels code te kijken, met jouw wijze blik, en er dan alle problemen uit zou halen is ontzettend naïef en getuigt van een totaal gebrek aan ervaring met softwareontwikkeling. Maar stel nu dat je het écht zat bent met die problemen in log4j en een flinke voorraad cola of energiedrankjes in huis hebt. En heel veel kennis en tijd. Dan zou je log4j kunnen forken, doorspitten en verbeteren en het resultaat aanbieden bij degenen die het onderhouden. De wereld zou je dankbaar zijn! Het is open source software, dus het is mogelijk en iedereen kan precies zien in de versiehistorie wat jij hebt gewijzigd. Bij closed source software kan je niets van dat alles. Je moet vertrouwen op de blauwe ogen van jouw softwareleverancier en die heeft je helemaal bij de ballen.


Kom, kom, je bent toch geen scriptkiddie?


Het echte probleem is natuurlijk het niet goed kunnen doorvoeren van wijzigingen van gebruikers van software die log4j aanroept. Voor de problemen met log4j zijn er toch al lang nieuwe versies waarin het is opgelost? Nou dan.


Tjeezus, wat een geknoei toch weer. Dat krijg je als beheerders gewend zijn om 'eventjes opnieuw te installeren' bij problemen. Dan weten ze niet meer hoe dingen normaal te onderzoeken en op te lossen.


Tja, je moet niet alleen verstand van Windows platformen hebben. Daarmee snijd je jezelf vroeg of laat in de vingers.

Er zijn lekken gedicht maar ik vraag me ernstig af of er geen ontwerpproblemen aan ten grondslag liggen die helemaal niet zijn opgelost en ook niet met een paar patches zijn op te lossen. Ik verbaasde me al over dat een logcomponent 300.000 regels code kan beslaan, en de aard van de lekken lijkt aan te geven dat er allerlei functies in vermengd zijn die uit oogpunt van veiligheid en beheersbaarheid beter gescheiden van het loggen geïmplementeerd hadden kunnen worden.

Gewetensvraag voor jou: is dit niet precies het soort ongewenste verwevenheid van zaken die beter gescheiden kunnen blijven, met alle gevolgen van dien, die jou met enige regelmaat wat van Microsoft komt als software voor lichte consumententoepassingen doet typeren?

De reeks gaten (of een deel) had ik al verwacht dat ze in de eerste patch gevonden zouden zijn door zelf grondig te testen en niet door aan crowd-testing te doen.