XZ-ontwikkelaar start komende dagen met onderzoek naar backdoor
De ontwikkelaar van datacompressietool XZ, waar vorige week een backdoor in werd aangetroffen, begint de komende dagen met een onderzoek naar de aanval. Hij is op vakantie en had de situatie niet meekregen, totdat hij toevallig zijn e-mail bekeek, zo laat ontwikkelaar Lasse Collin in een bericht op de Linux Kernel Mailing List (LKML) weten. Daarnaast hebben allerlei overheidsdiensten over de backdoor alarm geslagen.
XZ is een tool voor het comprimeren en decomprimeren van data en in veel Linux-distributies aanwezig. Vorige week werd ontdekt dat bepaalde versies een backdoor bevatten waardoor een aanvaller code op systemen kan uitvoeren. De backdoor was toegevoegd door iemand die ook aan het XZ-project werkte. Rob Mensching, ceo van FireGiant en eerder software-engineer bij Microsoft en verantwoordelijk voor het maken van Windows Installer XML, maakte een analyse over de aanval.
Daarin bespreekt Mensching hoe de aanvaller contact met Collin zocht, die te maken had met een burn-out. De aanvaller biedt de XZ-ontwikkelaar aan om te helpen bij de ontwikkeling van de tool en voegt uiteindelijk de code toe waarin de backdoor aanwezig is. "Alleen ik had toegang tot de tukaani.org website, git.tukaani.org repositories en gerelateerde bestanden", zegt collins. De aanvaller had alleen toegang tot zaken die op GitHub werden gehost, zo laat de XZ-ontwikkelaar verder weten. Hij voegt toe deze week met het onderzoek naar de backdoor te starten.
Inmiddels hebben ook allerlei overheidsinstanties waarschuwingen gegeven. Na het Nationaal Cyber Security Centrum (NCSC) en het Amerikaanse cyberagentschap CISA, gaat het ook om het Bundesamt für Sicherheit in der Informationstechnik (BSI), onderdeel van het Duitse ministerie van Binnenlandse Zaken, en het Digital Trust Center van het ministerie van Economische Zaken. Ze adviseren gebruikers en organisaties om de betreffende Linux-distributies niet te gebruiken en naar een niet-gecompromitteerde versie te downgraden.
Reacties (22)
02-04-2024, 12:23 door
Anoniem
Ze adviseren gebruikers en organisaties om de betreffende Linux-distributies niet te gebruiken en naar een niet-gecompromitteerde versie te downgraden.
Sterk overdreven allemaal . Er zijn geen organisaties die testsoftware in productie draaien! Deze backdoor software wordt/werd alleen door ontwikkelaars/testers gebruikt. Het is bij lange na niet vergelijkbaar met log4j Aandacht zou verplaatst moeten worden naar hoe ga je om met trust en security van supply chain software: https://www.linuxfoundation.org/resources/publications/open-source-software-supply-chain-security
02-04-2024, 12:29 door
Anoniem
Er waren blijkbaar ook in de testperiode toch genoeg eye balls om deze geavanceerde backdoor mbv social engineering voor te zijn.
Zo zie je maar dat je per definitie iedereen moet beschouwen als oplichters, zelfs als ze het tegendeel hebben bewezen?
Ik ben benieuwd wanneer Rusland, China, Noord Korea of Iran op de proppen komt als initiator.
Zo zie je maar dat je per definitie iedereen moet beschouwen als oplichters, zelfs als ze het tegendeel hebben bewezen?
Ik ben benieuwd wanneer Rusland, China, Noord Korea of Iran op de proppen komt als initiator.
02-04-2024, 13:16 door
MathFox
Door Anoniem:
We hebben geluk dat deze achterdeur ontdekt is voordat hij met een stabiele release van een (Linux) distributie verspreid is. Ze adviseren gebruikers en organisaties om de betreffende Linux-distributies niet te gebruiken en naar een niet-gecompromitteerde versie te downgraden.
Sterk overdreven allemaal . Er zijn geen organisaties die testsoftware in productie draaien!Het is nog niet 100% duidelijk wat de mogelijkheden van de backdoor zijn, maar ik zou niet verbaasd zijn als het installatie van willekeurige ongewenste software mogelijk maakt. Daarom is het een goed idee om de machine te wissen en herinstalleren, zeker als je SSH naar de machine toestaat.
02-04-2024, 13:44 door
Anoniem
Door MathFox:
Het is nog niet 100% duidelijk wat de mogelijkheden van de backdoor zijn, maar ik zou niet verbaasd zijn als het installatie van willekeurige ongewenste software mogelijk maakt. Daarom is het een goed idee om de machine te wissen en herinstalleren, zeker als je SSH naar de machine toestaat.
Door Anoniem:
We hebben geluk dat deze achterdeur ontdekt is voordat hij met een stabiele release van een (Linux) distributie verspreid is. Ze adviseren gebruikers en organisaties om de betreffende Linux-distributies niet te gebruiken en naar een niet-gecompromitteerde versie te downgraden.
Sterk overdreven allemaal . Er zijn geen organisaties die testsoftware in productie draaien!Het is nog niet 100% duidelijk wat de mogelijkheden van de backdoor zijn, maar ik zou niet verbaasd zijn als het installatie van willekeurige ongewenste software mogelijk maakt. Daarom is het een goed idee om de machine te wissen en herinstalleren, zeker als je SSH naar de machine toestaat.
Dit is grotendeels wel duidelijk. Met de juiste key kan d.m.v een ssh request een payload met de rechten waarop ssh draait uitgevoerd worden op de getargette machine. Dit veranderd elke ssh server in een bot.
Zodra de juiste key meegestuurd word wordt de payload direct naar system() gestuurd. Zo niet wordt de originele flow doorlopen. Tevens is deze malware bijna niet te detecteren in debug en test omgevingen omdat deze zichzelf dan uitschakeld.
Grote vermoedens dat dit door een geheime dienst gebouwd is. Niet voor niets heeft het 2 jaar geduurd vcoordat zo zover waren om dit in XZ te krijgen.
https://arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world
02-04-2024, 15:16 door
Anoniem
Door Anoniem:
Aandacht zou verplaatst moeten worden naar hoe ga je om met trust en security van supply chain software: https://www.linuxfoundation.org/resources/publications/open-source-software-supply-chain-security
Ze adviseren gebruikers en organisaties om de betreffende Linux-distributies niet te gebruiken en naar een niet-gecompromitteerde versie te downgraden.
Sterk overdreven allemaal . Er zijn geen organisaties die testsoftware in productie draaien! Deze backdoor software wordt/werd alleen door ontwikkelaars/testers gebruikt. Het is bij lange na niet vergelijkbaar met log4j Aandacht zou verplaatst moeten worden naar hoe ga je om met trust en security van supply chain software: https://www.linuxfoundation.org/resources/publications/open-source-software-supply-chain-security
In verschillende distors kwam die al voor...
Arch, gentoo, fedora, suse.
Xz is geen test tool, buiten de backdoor voor ssh draaiend als normale login daemon functioneert de software normaal.
De backdoor is gevoelig voor context waarin die gebruikt wordt.
02-04-2024, 15:40 door
Anoniem
Microsoft FAQ and guidance for XZ Utils backdoor
by Brjann Brekkan, Apr 01 2024 06:32 PM
https://techcommunity.microsoft.com/t5/microsoft-defender-vulnerability/microsoft-faq-and-guidance-for-xz-utils-backdoor/ba-p/4101961
As the investigation of this event continues, this blog will be updated with additional insights from Microsoft Security.
by Brjann Brekkan, Apr 01 2024 06:32 PM
You can use the Security Explorer feature within Defender for Cloud to perform queries related to your posture management across Azure, AWS & GCP, and investigate this specific CVE-2024-3094 to find the affected machines and understand the risk associated with them.
https://techcommunity.microsoft.com/t5/microsoft-defender-vulnerability/microsoft-faq-and-guidance-for-xz-utils-backdoor/ba-p/4101961
As the investigation of this event continues, this blog will be updated with additional insights from Microsoft Security.
02-04-2024, 15:47 door
Anoniem
Door Anoniem:
Dit is grotendeels wel duidelijk. Met de juiste key kan d.m.v een ssh request een payload met de rechten waarop ssh draait uitgevoerd worden op de getargette machine. Dit veranderd elke ssh server in een bot.
Zodra de juiste key meegestuurd word wordt de payload direct naar system() gestuurd. Zo niet wordt de originele flow doorlopen. Tevens is deze malware bijna niet te detecteren in debug en test omgevingen omdat deze zichzelf dan uitschakeld.
Grote vermoedens dat dit door een geheime dienst gebouwd is. Niet voor niets heeft het 2 jaar geduurd vcoordat zo zover waren om dit in XZ te krijgen.
https://arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world
Deze ontdekking laat zien hoe cruciaal het is om een waakzaam en ervaren beveiligingsteam te hebben dat de kanalen van de supply chain goed monitort. Door MathFox:
Het is nog niet 100% duidelijk wat de mogelijkheden van de backdoor zijn, maar ik zou niet verbaasd zijn als het installatie van willekeurige ongewenste software mogelijk maakt. Daarom is het een goed idee om de machine te wissen en herinstalleren, zeker als je SSH naar de machine toestaat.
Door Anoniem:
We hebben geluk dat deze achterdeur ontdekt is voordat hij met een stabiele release van een (Linux) distributie verspreid is. Ze adviseren gebruikers en organisaties om de betreffende Linux-distributies niet te gebruiken en naar een niet-gecompromitteerde versie te downgraden.
Sterk overdreven allemaal . Er zijn geen organisaties die testsoftware in productie draaien!Het is nog niet 100% duidelijk wat de mogelijkheden van de backdoor zijn, maar ik zou niet verbaasd zijn als het installatie van willekeurige ongewenste software mogelijk maakt. Daarom is het een goed idee om de machine te wissen en herinstalleren, zeker als je SSH naar de machine toestaat.
Dit is grotendeels wel duidelijk. Met de juiste key kan d.m.v een ssh request een payload met de rechten waarop ssh draait uitgevoerd worden op de getargette machine. Dit veranderd elke ssh server in een bot.
Zodra de juiste key meegestuurd word wordt de payload direct naar system() gestuurd. Zo niet wordt de originele flow doorlopen. Tevens is deze malware bijna niet te detecteren in debug en test omgevingen omdat deze zichzelf dan uitschakeld.
Grote vermoedens dat dit door een geheime dienst gebouwd is. Niet voor niets heeft het 2 jaar geduurd vcoordat zo zover waren om dit in XZ te krijgen.
https://arstechnica.com/security/2024/04/what-we-know-about-the-xz-utils-backdoor-that-almost-infected-the-world
Uit een analyse van de codecommittijden blijkt dat het individu of de groep die verantwoordelijk is, opereert vanuit Oost-Europa en niet vanuit Azië (wat de gebruikersnaam doet suggereren). Ik pleit er voor dat een maintainer zich eerst in levende ljve voorstelt en legitimeert voordat hij of zij code mag submitten.
02-04-2024, 16:39 door
Anoniem
Door Anoniem:
In verschillende distors kwam die al voor...
Arch, gentoo, fedora, suse.
.
Geen enkele productie dus....Door Anoniem:
Aandacht zou verplaatst moeten worden naar hoe ga je om met trust en security van supply chain software: https://www.linuxfoundation.org/resources/publications/open-source-software-supply-chain-security
Ze adviseren gebruikers en organisaties om de betreffende Linux-distributies niet te gebruiken en naar een niet-gecompromitteerde versie te downgraden.
Sterk overdreven allemaal . Er zijn geen organisaties die testsoftware in productie draaien! Deze backdoor software wordt/werd alleen door ontwikkelaars/testers gebruikt. Het is bij lange na niet vergelijkbaar met log4j Aandacht zou verplaatst moeten worden naar hoe ga je om met trust en security van supply chain software: https://www.linuxfoundation.org/resources/publications/open-source-software-supply-chain-security
In verschillende distors kwam die al voor...
Arch, gentoo, fedora, suse.
.
In fedora alleen ontwikkel en beta versies.
Gento maakt geen gebruik van deze patches (https://security.gentoo.org/glsa/202403-04)
Arch maakt geen gebruik van deze bieb.
suse niet in productie (https://www.suse.com/c/suse-addresses-supply-chain-attack-against-xz-compression-library/)
Zelfs niet in CentOS Stream (upstream voor rhel)
Het laat voor mij wel weer de toegevoegde waarde zien voor RHEL en SLES
02-04-2024, 16:50 door
Anoniem
Uit een analyse van de codecommittijden blijkt dat het individu of de groep die verantwoordelijk is, opereert vanuit Oost-Europa en niet vanuit Azië
Of het is aan Aziatisch team dat avond dienst heeft een Amerikaans team dat vroege dienst heeft.
02-04-2024, 17:30 door
Anoniem
Door Anoniem:
In fedora alleen ontwikkel en beta versies.
Gento maakt geen gebruik van deze patches (https://security.gentoo.org/glsa/202403-04)
Arch maakt geen gebruik van deze bieb.
suse niet in productie (https://www.suse.com/c/suse-addresses-supply-chain-attack-against-xz-compression-library/)
Zelfs niet in CentOS Stream (upstream voor rhel)
Het laat voor mij wel weer de toegevoegde waarde zien voor RHEL en SLES
Door Anoniem:
In verschillende distors kwam die al voor...
Arch, gentoo, fedora, suse.
.
Geen enkele productie dus....Door Anoniem:
Aandacht zou verplaatst moeten worden naar hoe ga je om met trust en security van supply chain software: https://www.linuxfoundation.org/resources/publications/open-source-software-supply-chain-security
Ze adviseren gebruikers en organisaties om de betreffende Linux-distributies niet te gebruiken en naar een niet-gecompromitteerde versie te downgraden.
Sterk overdreven allemaal . Er zijn geen organisaties die testsoftware in productie draaien! Deze backdoor software wordt/werd alleen door ontwikkelaars/testers gebruikt. Het is bij lange na niet vergelijkbaar met log4j Aandacht zou verplaatst moeten worden naar hoe ga je om met trust en security van supply chain software: https://www.linuxfoundation.org/resources/publications/open-source-software-supply-chain-security
In verschillende distors kwam die al voor...
Arch, gentoo, fedora, suse.
.
In fedora alleen ontwikkel en beta versies.
Gento maakt geen gebruik van deze patches (https://security.gentoo.org/glsa/202403-04)
Arch maakt geen gebruik van deze bieb.
suse niet in productie (https://www.suse.com/c/suse-addresses-supply-chain-attack-against-xz-compression-library/)
Zelfs niet in CentOS Stream (upstream voor rhel)
Het laat voor mij wel weer de toegevoegde waarde zien voor RHEL en SLES
Nee maar dit had zomaar het geval kunnen zijn als dit niet per toeval ontdekt was. Deze backdoor was zeer goed verborgen maar doordat tijdens een benchmark test van Postgres 0.5 seconden vertraging op trad is de betreffende ontwikkelaar verder gaan zoeken.
Dat het nog niet in productie zat en het wegwuiven als een overdreven bevinding is toch echt je kop in het zand steken want de gevolgen hadden enorm kunnen zijn.
En uiteindelijk ook in RHEL terechtgekomen...
02-04-2024, 17:33 door
Anoniem
Door Anoniem:
In fedora alleen ontwikkel en beta versies.
Gento maakt geen gebruik van deze patches (https://security.gentoo.org/glsa/202403-04)
Arch maakt geen gebruik van deze bieb.
suse niet in productie (https://www.suse.com/c/suse-addresses-supply-chain-attack-against-xz-compression-library/)
Zelfs niet in CentOS Stream (upstream voor rhel)
Het laat voor mij wel weer de toegevoegde waarde zien voor RHEL en SLES
Door Anoniem:
In verschillende distors kwam die al voor...
Arch, gentoo, fedora, suse.
.
Geen enkele productie dus....Door Anoniem:
Aandacht zou verplaatst moeten worden naar hoe ga je om met trust en security van supply chain software: https://www.linuxfoundation.org/resources/publications/open-source-software-supply-chain-security
Ze adviseren gebruikers en organisaties om de betreffende Linux-distributies niet te gebruiken en naar een niet-gecompromitteerde versie te downgraden.
Sterk overdreven allemaal . Er zijn geen organisaties die testsoftware in productie draaien! Deze backdoor software wordt/werd alleen door ontwikkelaars/testers gebruikt. Het is bij lange na niet vergelijkbaar met log4j Aandacht zou verplaatst moeten worden naar hoe ga je om met trust en security van supply chain software: https://www.linuxfoundation.org/resources/publications/open-source-software-supply-chain-security
In verschillende distors kwam die al voor...
Arch, gentoo, fedora, suse.
.
In fedora alleen ontwikkel en beta versies.
Gento maakt geen gebruik van deze patches (https://security.gentoo.org/glsa/202403-04)
Arch maakt geen gebruik van deze bieb.
suse niet in productie (https://www.suse.com/c/suse-addresses-supply-chain-attack-against-xz-compression-library/)
Zelfs niet in CentOS Stream (upstream voor rhel)
Het laat voor mij wel weer de toegevoegde waarde zien voor RHEL en SLES
Systemd trekt deze binnen dus uiteindelijk zou dit in de meeste distros terecht zijn gekomen. Ook in RHEL.
Dit is per toeval ontdekt dus de gevolgen hadden groot kunnen zijn.
02-04-2024, 17:49 door
Anoniem
Door Anoniem: Sterk overdreven allemaal . Er zijn geen organisaties die testsoftware in productie draaien!
Denk alsjeblieft iets verder door dan alleen de allereerste stap. Een testversie die in een ontwikkelomgeving gebruikt wordt kan ook gecompromitteerd raken en een springplank zijn om andere systemen in het netwerk van een organisatie aan te vallen. Daar kunnen weer andere zwakheden aanwezig zijn die misbruikt kunnen worden om verder te komen.Het is heel simpel: als je waar dan ook de gecompromitteerde versies hebt gebruikt dan heb je actie te ondernemen. En dat is niet overdreven.
02-04-2024, 19:19 door
Anoniem
Ook voor de backdoor was xz al broken by design:
https://www.nongnu.org/lzip/xz_inadequate.html
Hopelijk is de backdoor het laatste zetje wat nodig is om er helemaal mee te stoppen.
https://www.nongnu.org/lzip/xz_inadequate.html
Hopelijk is de backdoor het laatste zetje wat nodig is om er helemaal mee te stoppen.
02-04-2024, 20:36 door
Anoniem
Alle vingers wijzen naar Kwatta, zei men vroeger.
Wie is Kwatta in dit geval: cloak and dagger?
Kolowrotek? Uki of Orki?
Knappe jongen, die het weet, toch?
Wie is Kwatta in dit geval: cloak and dagger?
Kolowrotek? Uki of Orki?
Knappe jongen, die het weet, toch?
02-04-2024, 20:59 door
Anoniem
Door Anoniem: Er waren blijkbaar ook in de testperiode toch genoeg eye balls om deze geavanceerde backdoor mbv social engineering voor te zijn.
Zo zie je maar dat je per definitie iedereen moet beschouwen als oplichters, zelfs als ze het tegendeel hebben bewezen?
Ik ben benieuwd wanneer Rusland, China, Noord Korea of Iran op de proppen komt als initiator.
Zo zie je maar dat je per definitie iedereen moet beschouwen als oplichters, zelfs als ze het tegendeel hebben bewezen?
Ik ben benieuwd wanneer Rusland, China, Noord Korea of Iran op de proppen komt als initiator.
Waarom niet de CIA ? Edward Snowden vergeten ?
02-04-2024, 21:58 door
Anoniem
Door Anoniem:
Of het is aan Aziatisch team dat avond dienst heeft een Amerikaans team dat vroege dienst heeft.
Uit een analyse van de codecommittijden blijkt dat het individu of de groep die verantwoordelijk is, opereert vanuit Oost-Europa en niet vanuit Azië
Of het is aan Aziatisch team dat avond dienst heeft een Amerikaans team dat vroege dienst heeft.
Mijn productieve tijden zijn US-daytime . Ik ben daar niet.
02-04-2024, 23:34 door
Anoniem
Door Anoniem:
Nee maar dit had zomaar het geval kunnen zijn als dit niet per toeval ontdekt was. Deze backdoor was zeer goed verborgen maar doordat tijdens een benchmark test van Postgres 0.5 seconden vertraging op trad is de betreffende ontwikkelaar verder gaan zoeken.
Dat het nog niet in productie zat en het wegwuiven als een overdreven bevinding is toch echt je kop in het zand steken want de gevolgen hadden enorm kunnen zijn.
En uiteindelijk ook in RHEL terechtgekomen...
Door Anoniem:
In fedora alleen ontwikkel en beta versies.
Gento maakt geen gebruik van deze patches (https://security.gentoo.org/glsa/202403-04)
Arch maakt geen gebruik van deze bieb.
suse niet in productie (https://www.suse.com/c/suse-addresses-supply-chain-attack-against-xz-compression-library/)
Zelfs niet in CentOS Stream (upstream voor rhel)
Het laat voor mij wel weer de toegevoegde waarde zien voor RHEL en SLES
Door Anoniem:
In verschillende distors kwam die al voor...
Arch, gentoo, fedora, suse.
.
Geen enkele productie dus....Door Anoniem:
Aandacht zou verplaatst moeten worden naar hoe ga je om met trust en security van supply chain software: https://www.linuxfoundation.org/resources/publications/open-source-software-supply-chain-security
Ze adviseren gebruikers en organisaties om de betreffende Linux-distributies niet te gebruiken en naar een niet-gecompromitteerde versie te downgraden.
Sterk overdreven allemaal . Er zijn geen organisaties die testsoftware in productie draaien! Deze backdoor software wordt/werd alleen door ontwikkelaars/testers gebruikt. Het is bij lange na niet vergelijkbaar met log4j Aandacht zou verplaatst moeten worden naar hoe ga je om met trust en security van supply chain software: https://www.linuxfoundation.org/resources/publications/open-source-software-supply-chain-security
In verschillende distors kwam die al voor...
Arch, gentoo, fedora, suse.
.
In fedora alleen ontwikkel en beta versies.
Gento maakt geen gebruik van deze patches (https://security.gentoo.org/glsa/202403-04)
Arch maakt geen gebruik van deze bieb.
suse niet in productie (https://www.suse.com/c/suse-addresses-supply-chain-attack-against-xz-compression-library/)
Zelfs niet in CentOS Stream (upstream voor rhel)
Het laat voor mij wel weer de toegevoegde waarde zien voor RHEL en SLES
Nee maar dit had zomaar het geval kunnen zijn als dit niet per toeval ontdekt was. Deze backdoor was zeer goed verborgen maar doordat tijdens een benchmark test van Postgres 0.5 seconden vertraging op trad is de betreffende ontwikkelaar verder gaan zoeken.
Dat het nog niet in productie zat en het wegwuiven als een overdreven bevinding is toch echt je kop in het zand steken want de gevolgen hadden enorm kunnen zijn.
En uiteindelijk ook in RHEL terechtgekomen...
Door Anoniem:
Of het is aan Aziatisch team dat avond dienst heeft een Amerikaans team dat vroege dienst heeft.
Uit een analyse van de codecommittijden blijkt dat het individu of de groep die verantwoordelijk is, opereert vanuit Oost-Europa en niet vanuit Azië
Of het is aan Aziatisch team dat avond dienst heeft een Amerikaans team dat vroege dienst heeft.
Time zones zijn gewijzigd om ons te laten geloven dat het uit China komt. Helaas is onze "Jia Tan" dot bij 3 commits vergeten waaruit Oost Europa blijkt.
Clever maar wat niet gemeld wordt is dat Israel dezelfde time zone heeft...
Unit8200 iemand?
02-04-2024, 23:42 door
Anoniem
Door Anoniem:
Systemd trekt deze binnen dus uiteindelijk zou dit in de meeste distros terecht zijn gekomen. Ook in RHEL.
Dit is per toeval ontdekt dus de gevolgen hadden groot kunnen zijn.
Was geen toeval want er waren ook veel errors tijdens het bouwen (o.a door die punt). Dat komt echt niet door de rhel bouw procedure. Daarnaast moet het eerst nog door centos stream (rhel upstream) voordat het in rhel wordt gebouwd (nog vele eye balls te gaan) CI/CD pipeline is daar veel strenger.Door Anoniem:
In fedora alleen ontwikkel en beta versies.
Gento maakt geen gebruik van deze patches (https://security.gentoo.org/glsa/202403-04)
Arch maakt geen gebruik van deze bieb.
suse niet in productie (https://www.suse.com/c/suse-addresses-supply-chain-attack-against-xz-compression-library/)
Zelfs niet in CentOS Stream (upstream voor rhel)
Het laat voor mij wel weer de toegevoegde waarde zien voor RHEL en SLES
Door Anoniem:
In verschillende distors kwam die al voor...
Arch, gentoo, fedora, suse.
.
Geen enkele productie dus....Door Anoniem:
Aandacht zou verplaatst moeten worden naar hoe ga je om met trust en security van supply chain software: https://www.linuxfoundation.org/resources/publications/open-source-software-supply-chain-security
Ze adviseren gebruikers en organisaties om de betreffende Linux-distributies niet te gebruiken en naar een niet-gecompromitteerde versie te downgraden.
Sterk overdreven allemaal . Er zijn geen organisaties die testsoftware in productie draaien! Deze backdoor software wordt/werd alleen door ontwikkelaars/testers gebruikt. Het is bij lange na niet vergelijkbaar met log4j Aandacht zou verplaatst moeten worden naar hoe ga je om met trust en security van supply chain software: https://www.linuxfoundation.org/resources/publications/open-source-software-supply-chain-security
In verschillende distors kwam die al voor...
Arch, gentoo, fedora, suse.
.
In fedora alleen ontwikkel en beta versies.
Gento maakt geen gebruik van deze patches (https://security.gentoo.org/glsa/202403-04)
Arch maakt geen gebruik van deze bieb.
suse niet in productie (https://www.suse.com/c/suse-addresses-supply-chain-attack-against-xz-compression-library/)
Zelfs niet in CentOS Stream (upstream voor rhel)
Het laat voor mij wel weer de toegevoegde waarde zien voor RHEL en SLES
Systemd trekt deze binnen dus uiteindelijk zou dit in de meeste distros terecht zijn gekomen. Ook in RHEL.
Dit is per toeval ontdekt dus de gevolgen hadden groot kunnen zijn.
02-04-2024, 23:44 door
Anoniem
Door Anoniem:
Het is heel simpel: als je waar dan ook de gecompromitteerde versies hebt gebruikt dan heb je actie te ondernemen. En dat is niet overdreven.
Natuurlijk heb je actie te ondernemen maar er is niet voor niets een OTAP straat.Door Anoniem: Sterk overdreven allemaal . Er zijn geen organisaties die testsoftware in productie draaien!
Denk alsjeblieft iets verder door dan alleen de allereerste stap. Een testversie die in een ontwikkelomgeving gebruikt wordt kan ook gecompromitteerd raken en een springplank zijn om andere systemen in het netwerk van een organisatie aan te vallen. Daar kunnen weer andere zwakheden aanwezig zijn die misbruikt kunnen worden om verder te komen.Het is heel simpel: als je waar dan ook de gecompromitteerde versies hebt gebruikt dan heb je actie te ondernemen. En dat is niet overdreven.
02-04-2024, 23:47 door
Anoniem
Door Anoniem:
Waarom niet de CIA ? Edward Snowden vergeten ?
CIA NSA Zou ook nog kunnen. Ze hebben het tenslotte via Linus eerder geprobeerd.Door Anoniem: Er waren blijkbaar ook in de testperiode toch genoeg eye balls om deze geavanceerde backdoor mbv social engineering voor te zijn.
Zo zie je maar dat je per definitie iedereen moet beschouwen als oplichters, zelfs als ze het tegendeel hebben bewezen?
Ik ben benieuwd wanneer Rusland, China, Noord Korea of Iran op de proppen komt als initiator.
Zo zie je maar dat je per definitie iedereen moet beschouwen als oplichters, zelfs als ze het tegendeel hebben bewezen?
Ik ben benieuwd wanneer Rusland, China, Noord Korea of Iran op de proppen komt als initiator.
Waarom niet de CIA ? Edward Snowden vergeten ?
03-04-2024, 13:25 door
Anoniem
Door Anoniem:
Door Anoniem:
Systemd trekt deze binnen dus uiteindelijk zou dit in de meeste distros terecht zijn gekomen. Ook in RHEL.
Dit is per toeval ontdekt dus de gevolgen hadden groot kunnen zijn.
Was geen toeval want er waren ook veel errors tijdens het bouwen (o.a door die punt). Dat komt echt niet door de rhel bouw procedure. Daarnaast moet het eerst nog door centos stream (rhel upstream) voordat het in rhel wordt gebouwd (nog vele eye balls te gaan) CI/CD pipeline is daar veel strenger.Door Anoniem:
In fedora alleen ontwikkel en beta versies.
Gento maakt geen gebruik van deze patches (https://security.gentoo.org/glsa/202403-04)
Arch maakt geen gebruik van deze bieb.
suse niet in productie (https://www.suse.com/c/suse-addresses-supply-chain-attack-against-xz-compression-library/)
Zelfs niet in CentOS Stream (upstream voor rhel)
Het laat voor mij wel weer de toegevoegde waarde zien voor RHEL en SLES
Door Anoniem:
In verschillende distors kwam die al voor...
Arch, gentoo, fedora, suse.
.
Geen enkele productie dus....Door Anoniem:
Aandacht zou verplaatst moeten worden naar hoe ga je om met trust en security van supply chain software: https://www.linuxfoundation.org/resources/publications/open-source-software-supply-chain-security
Ze adviseren gebruikers en organisaties om de betreffende Linux-distributies niet te gebruiken en naar een niet-gecompromitteerde versie te downgraden.
Sterk overdreven allemaal . Er zijn geen organisaties die testsoftware in productie draaien! Deze backdoor software wordt/werd alleen door ontwikkelaars/testers gebruikt. Het is bij lange na niet vergelijkbaar met log4j Aandacht zou verplaatst moeten worden naar hoe ga je om met trust en security van supply chain software: https://www.linuxfoundation.org/resources/publications/open-source-software-supply-chain-security
In verschillende distors kwam die al voor...
Arch, gentoo, fedora, suse.
.
In fedora alleen ontwikkel en beta versies.
Gento maakt geen gebruik van deze patches (https://security.gentoo.org/glsa/202403-04)
Arch maakt geen gebruik van deze bieb.
suse niet in productie (https://www.suse.com/c/suse-addresses-supply-chain-attack-against-xz-compression-library/)
Zelfs niet in CentOS Stream (upstream voor rhel)
Het laat voor mij wel weer de toegevoegde waarde zien voor RHEL en SLES
Systemd trekt deze binnen dus uiteindelijk zou dit in de meeste distros terecht zijn gekomen. Ook in RHEL.
Dit is per toeval ontdekt dus de gevolgen hadden groot kunnen zijn.
Denk dat ze een beetje haast hebben gekregen en daardoor fouten, afkortingen hebben gemaakt. Tenminste lijkt erop alsof systemd de lib eruit wilde hebben: https://github.com/systemd/systemd/pull/31550
Lijkt me stug om 2+ jaar tijd en effort zo makkelijk zouden willen laten detecteren.
04-04-2024, 10:34 door
Anoniem
WSL werd aan XZ gelinkt in oktober 2020 https://github.com/microsoft/WSL/issues/6056
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
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.
