Dat is niet pluis.

Google....


Is er al iets bekend m.b.t. van overheidswege gevraagde verplichting tot opening van zaken bij bedrijven, overheidsinstellingen, serviceverleners etc. die gebruik maken van de kwetsbare Java software?

Enkele dagen geleden las ik hier dat bijvoorbeeld ook (financiële) serviceverleners zoals banken, maar ook misschien - mijn gedachte - pensioenfondsen of overheidsinstellingen zoals het UVW of Waterschappen.. (enfin, vul maar in) zodanig getroffen kunnen worden dat ook de burger in het algemeen (vervolg)schade lijdt.

Dat krijg je nou als je een beroerd package management gebruikt waarin er van alle componenten copietjes worden meegenomen...
In een Linux package management systeem zit die log4j module gewoon in een apart package, en is al die javatroep die er gebruik gemaakt gewoon geconfigureerd met een afhankelijkheid van dat ene package.
Is er een probleem dan wordt dat package geupdate en is iedereen weer veilig.
Of je mikt dat ene package eraf en het package management systeem gooit automatisch alle software van je systeem die er gebruik van maakt (dat is de oplossing die ik gekozen heb, want er zat niks bij wat ik zelf bewust geinstalleerd had en waar ik gebruik van maak).

Ik snap even niet dat dit het geval is. Als ik Log4J in een software project gebruik link ik slechts in m'n .xml naar hun Library en maven download die toch tegen de tijd dat het nodig is?!

Dan zit Log4J toch niet in mijn project? Iedereen die mijn project wil gebruiken zal bij de originele bron toch log4j moeten downloaden?

Sommige programmeurs doen

Of het daadwerkelijk gebruikt wordt kun je alleen zien als je de applicatie de-compiled.

Het lijkt mij dat je een specifice versie als dependency kan opgeven, dan blijft het Java project gevoelig totdat die dependency is vervangen door een nieuwere versie.

Dus eigenlijk of crappy programmeerkunsten in java-projecten, of een programeertaal die te "flexibel" blijkt te zijn.
Kies maar.

Inderdaad. De redactie formuleert het niet voor niets zo:
Daar staat niet slordig en onjuist dat Log4j-code inherent kwetsbaar is, daar staat een veel preciezere formulering, namelijk dat de afhankelijkheid is van die Log4j-code die kwetsbaar is. Dat kan alleen maar op de kwetsbare versies van Log4j slaan.

Als je de link naar het verslag van Google volgt wordt dit uitgebreid bevestigd. Ze noemen bijvoorbeeld het aantal pakketten waarin de kwetsbaarheid gerepareerd is door de afhankelijkheid van Log4j helemaal te verwijderen of hem bij te werken naar een afhankelijkheid van de gerepareerde versie van Log4j. Dat maakt volkomen duidelijk dat het gaat om afhankelijkheid van de kwetsbare versies van Log4j.

Ik zie op dit forum heel vaak vragen gesteld worden waarop het antwoord in het artikel staat of anders in de bronnen waar het artikel naar linkt. Lieve mensen, lees goed wat er staat, en volg links naar bronnen als er vragen bij je opkomen. Er bestaat zoiets als precies taalgebruik, en daar kan je jezelf in aanscherpen, zowel bij lezen als bij schrijven. Taal is het middel waarmee je met anderen communiceert, waarmee je kennis overdraagt en ontvangt, dat is geen bijzaak. Goed lezen en informatie opnemen kost natuurlijk tijd en inspanning. Maar domweg door het met aandacht te doen en niet haastig overal overheen te lezen kan je jezelf ontwikkelen, van iemand die veel mist en daardoor van alles moet vragen aan mensen die het niet hebben gemist, naar iemand die zelf die vragen kan beantwoorden. Dat is ontzettend waardevol. Je verrijkt jezelf niet alleen qua kennisniveau, het levert je ook waardering van anderen op en je loopt zelfs kans dat het je uiteindelijk een hoger salaris oplevert.

Kletskoek omdat je het gebruik van de componenten duidelijk niet begrijpt. Je gaat uit van een monolitisch gebeuren, dat is het niet. De aparte onderdelen kunnen geen shared componenten delen zonder in de valkuil van de ddl-hel te vallen.

https://security.googleblog.com/2021/12/understanding-impact-of-apache-log4j.html
Losse onderdelen hebben hun eigen (private) referentie nodig dan krijg je snel hel bomen. Iedereen kan het zien dus wat kan er dan fout gaan? Ja het is veel. Ja het is complex en dan ....
https://github.com/NCSC-NL/log4shell/tree/main/software

Inderdaad en natuurlijk en bijvoorbeeld zo (voor Maven):


Als je een andere versie van log4j zou willen gaan gebruiken dan pas je dat aan in bovenstaand stukje XML en herbouw je je project. Het probleem is wel dat andere bibliotheken waaraan je op deze manier refereert zelf ook log4j kunnen gebruiken en dat je er zeker van moet zijn dat dergelijke bibliotheken zijn bijgewerkt en herbouwd met een gefixte log4j versie, waardoor je er dus niet bent met je eigen log4j referentie bijwerken.

Mark my words... nu is het java met een rotte class, strakjes wordt het iets anders in een snap / flatpack want daar ontstaat dezelfde cultuur van kaarten huizen bouwen en naiviteit vwb maintenance van libraries door anderen!

Retire library dependencies. De Oftedal methode.

Jeetje wat een dom systeem zeg... een normaal systeem zou iets als <version> 2.* </version> gebruiken en dan zou de "current 2.x version" meegenomen worden. Het is dan de verantwoordelijkheid van de maintainers om te zorgen dat de interface voor die 2.x versies hetzelfde blijft.
Dan kunnen updates gewoon (automatisch) geinstalleerd worden en heb je deze ellende niet.

Leerpuntje voor Maven! Linux distributeurs weten dit al jaren...

Zie:https://snyk.io/blog/log4shell-remediation-cheat-sheet/
luntrus

Misschien wordt het tijd dat mensen weer gewoon snappen hoe hun eigen software werkt i.p.v. dat ze klakkeloos duizenden libraries, frameworks en "tooling" overal en nergens vandaan halen om "enterprise solutions te deployen".

Leerpuntje voor jou: dit kan met Maven wel degelijk allemaal opgegeven worden. De notatie is anders dan jij nu bedenkt, maar het kan gewoon, en wel zo:

https://maven.apache.org/pom.html#Dependency_Version_Requirement_Specification

Mij kostte het één gerichte zoekopdracht om deze beschrijving te vinden. Dat lukt jou ook wel als je niet net zo dom bent als je dacht dat Maven is. Pro tip: doe dat voortaan even voor je een commentaar plaatst.

Bij software bibliotheken wil je helemaal geen automatische updates. Als in een update van een bibliotheek de API of het gedrag is veranderd dan moet met beleid worden gekeken of het gebruik van de bibliotheek moet worden aangepast.

Waarbij geheel voorbij gegaan wordt aan het probleem van meegecompileerde modules in commerciele software.

https://www.security.nl/posting/734881/Beruchte+ransomwaregroep+gebruikt+Log4j-kwetsbaarheid+bij+aanvallen

Nee als dit veranderd is moet het versie nummer worden aangepast.
Als bij iedere update iedereen er weer naar moet gaan kijken is het slecht ontworpen en krijg je de problemen zoals die er nu zijn. Is een intrinsiek probleem in Java en de manier waarop Java applicaties gepackaged worden: slecht slecht slecht.
En nu zit de hele wereld daar mee.

Je bedoelt dat je voorgecompileerde softwaremodules gebruikt waarvan je zelf niet de broncode hebt in jouw product waarvan jij de broncode aan het ontwikkelen bent? Tja, daar had ik als open source gebruiker inderdaad niet eens over nagedacht. Wie doet er in 2021 nog zoiets? Dan ben je eigenlijk vendor lock-ins aan het stapelen. Tjeezus... Sterkte man!


Nee je kijkt helemaal niet naar nieuwe versies, mits er geen problemen als dit zijn. Normaliter blijf je gewoon de oudere versie gebruiken onder het "if it ain't broke don't fix it" principe. Natuurlijk wordt het versienummer aangepast bij een wijziging (hoe wil je anders refereren aan de nieuwe versie). Een update van een package voor een besturingssysteem is heel iets anders dan een update van een softwarebibliotheek die je in de broncode van je eigen programma gebruikt. Als er een nieuwe versie van een dergelijke softwarebibliotheek komt dan kan daarin nieuwe functionaliteit zijn ingebouwd, die anders gebruikt moet worden, API's kunnen zijn veranderd, waarbij de oude deprecated wordt verklaard en je verwacht wordt je gebruik naar de nieuwe API om te schrijven. Kortom: ga geen package updates voor een besturingssysteem vergelijken met updates van softwarebibliotheken en ga ook niet de mechanismes daarvoor vergelijken. Die dienen in deze gevallen een totaal verschillend doel. Java applicaties worden prima gepackaged!

Ach welnee man, het is een grote zooi. Wat jij schrijft daar klopt niks van, een gemiddeld Linux systeem heeft
honderden "lib" packages met shared libraries erin die keurig worden geupdate bij vulnerabilities en dan zijn meteen
alle programma's die deze gebruiken geupdate. Tegenwoordig krijg je zelfs meldingen welke draaiende programma's
herstart moeten worden om de nieuwe versie te krijgen.
En dat werkt prima voor security updates. Behalve dan bij die Java ballentent dan. Als je een paar Java applicaties
geinstalleerd hebt staat die log4j er gerust meerdere keren op, zelfs als het dezelfde versie is. PRUTSERS!

Mijn god, die scriptkiddies van tegenwoordig moet je ook alles uitleggen! Bij softwareontwikkeling gebruik je vaak softwarebibliotheken, die met een specifiek versienummer worden aangeduid en de bibliotheken zelf kunnen ook weer gebruik maken van andere bibliotheken. Daardoor is het prima mogelijk en zelfs normaal dat er meerdere versies van een bibliotheek op je systeem staan. Want de ene software gebruikt versie die en die i.v.m. een specifieke API-wijziging die nog niet is doorgevoerd in de aanroepende software, maar de andere software niet. Je hebt er duidelijk totaal geen verstand van maar probeer niet jouw beperkte beeld van softwareontwikkeling met allerlei onzinnige lekenpraat door te drukken. Je verkoopt klinkklare onzin! WAPPIE!

Sorry hoor Toje maar ik weet heel goed waar ik het over heb en dat Java distributie een grote puinzooi is en altijd
al is geweest. Hopelijk zal dit incident daar eens even stevig verandering in brengen want zoals die lui werken
dat kan ECHT niet, zeker niet in deze tijd (maar het was altijd al drama).
Als je denkt dat het anders zit, zoek de denkfout dan bij jezelf.

We praten misschien deels langs elkaar maar je hebt nog steeds niet aangetoond dat 'Java distributie' een 'grote puinzooi' zou zijn in vergelijking met hoe in andere programmeertalen referenties aan gebruikte softwarebibliotheken worden gedaan. Het is van alle tijden en voor alle programmeertalen iets dat op vergelijkbare wijze wordt opgelost (nogmaals: ik heb het niet over packaging van libraries voor besturingssystemen). Zie bv.: https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/versioning.

Over meerdere versies van dezelfde library, als voorbeeld:

1. software A gebruikt library versie 1.x want is ontwikkeld in toen er in die tijd nog geen versie 2.x was van die library;
2. software B gebruikt library versie 2.7 want werd ontwikkeld toen de nieuwe versie v.d. library er wel was;
3. software C gebruikt library versie 2.2 want is nog niet geüpdatet naar de allernieuwste versie en dat heeft ook geen haast.
4. software C gebruikt een experimentele versie van library versie 3.0 want heeft specifieke functionaliteit nodig die door de van API eerdere versies van die libraries nog niet werd aangeboden.

Omdat software gewoon moet blijven werken heb je meerdere en oudere versies van libraries op je systeem en die moeten erop blijven staan totdat de software die deze libraries gebruikt is geüpdatet. Want API's en functionaliteit verschillen meestal tussen libraries en als er semantic versioning is gebruikt dan kan je dat afleiden uit de versienummers.

Wat je met deze log4j vulnerability ziet is dat dit normale proces wordt verstoord doordat de kwetsbaarheid in vele log4j versies aanwezig is. Eigenlijk zouden de aanbieders van de library ook alle oude versies moeten updaten om de kwetsbaarheid te verhelpen (zodat gebruikers van oudere versies van de library niet alles moeten omschrijven naar veranderde functionaliteit en/of een nieuwe API). Nu leggen ze dat neer bij gebruikers van de library. Vergelijk het met een auto die eigenlijk teruggeroepen zou moeten worden omdat er een probleem met de remmen is. Dat probleem zit in alle modellen maar de fabrikant brengt alleen een nieuwe versie van de auto uit en laat eigenaren van de vorige modellen in de kou staan (die moeten maar het nieuwe model gaan gebruiken, wat een hoop moeite en tijd kost want, oh ja, het stuur zit rechts bij het nieuwe model, dat is toch geen probleem?). N.B.: dit heeft niets met Java te maken want geldt net zo goed voor andere programmeertalen en -platformen.