5 vragen over de malware in compressietool xz: was dit een achterdeur?

Onderzoekers hebben een opvallende bug gevonden in compressietool xz. Daarmee kon potentieel veel schade worden aangericht in veel Linux-distro's. Het nieuws kwam vlak voor het weekend naar buiten en veel is nog onbekend, maar er begint een beeld te ontstaan van een bewuste achterdeur. Wat weten we nu over de bug in xz?

Wat is xz?

Xz is een compressietool. De software maakt het mogelijk om lossless compressie te doen en komt voornamelijk voor op Linux. De tool is populair: xz, en specifiek het programma xz-utils, wordt standaard meegeleverd in onder andere Ubuntu, Debian, Fedora, Kali Linux en openSUSE, maar praktisch in de meeste Linux-distro's.

De broncode van xz was tot voor kort open source beschikbaar, maar op zondag haalde GitHub de repo offline. Daardoor is het nu lastiger om informatie over de tool online te vinden, al zijn er inmiddels genoeg forks te vinden. Ook hebben de ontwikkelaars zelf nog een mirror online staan.

Gebruikers op een Linux-systeem kunnen via het commando xz --version kijken welke versie zij draaien.

Wat gebeurde er?

Op vrijdagmiddag ging het nieuws rond dat er een bug in xz leek te zitten. Tweakers schreef daar vrijdagavond dit artikel over. Het nieuws kwam naar buiten doordat Andres Freund een bericht stuurde naar de oss-security-mailinglijst. Freund is een PostgreSQL-ontwikkelaar bij Microsoft en was scherp genoeg de bug op te merken. Hij beschrijft hoe hij een opvallende latency van zo'n 500 milliseconden zag toen hij verbinding maakte via sshd. "Ik deed wat microbenchmarks om het systeem te optimaliseren en zag dat sshd-processen een verrassend hoog cpu-verbruik veroorzaakten", schrijft hij.

Kort daarna begonnen de makers van meerdere Linux-distro's met het versturen van waarschuwingen naar gebruikers. Onder andere Debian, openSUSE en Fedora-maker Red Hat waarschuwden voor de bug.

De kwetsbare versie van xz-utils bleek uiteindelijk in slechts een handvol distro's te zitten, omdat de meeste distro's nog geen update voor xz hadden doorgevoerd. De waarschuwingen bleken dus wat prematuur, maar desondanks hebben de distro's maatregelen genomen om xz-utils terug te draaien naar een eerdere versie.

Wie of wat is er allemaal kwetsbaar?

Doordat Freund de kwetsbaarheid al vroeg spotte, is de schade relatief beperkt gebleven. Versies 5.6.0 en 5.6.1 van xz-utils blijken kwetsbaar te zijn, maar die waren nog niet in de upstream van de package gekomen. Daarom waren er nog geen grote Linux-distro's waarbij de kwetsbare versies zijn doorgevoerd in een stabiele release.

Wel zijn enkele vroege releases, zoals publieke bèta's, kwetsbaar. Dat zijn met name Fedora Rawhide en Debian-testing. Ook packagemanager Homebrew voor macOS bevatte de kwetsbare versie 5.6.1 van xz-utils. Inmiddels hebben al die distro's, en Homebrew, xz-utils teruggerold naar versie 5.4.6.

De kwetsbaarheid zit hoe dan ook alleen in de installatiepackage van xz-utils. De Git-repo is niet getroffen.

Xz maakt ook de library liblzma aan. Ook software waar die library in zit, kan dus kwetsbaar zijn.

Wat is de kwetsbaarheid precies en wat kon een eventuele aanvaller daarmee?

Om te beginnen: de volledige omvang van de bug is nog niet helemaal bekend. Onderzoekers zijn momenteel nog te druk om de tool te reverse engineeren, dus waarschijnlijk volgen daar de komende dagen of weken nog meer ontwikkelingen uit.

Wat in ieder geval al wel duidelijk is, is dat de update een installatiescript genaamd build-to-host.m4 draaide. Dat wist zichzelf te plaatsen in functies die door sshd werden gebruikt, een bestand dat op Linux-systemen gebruikt wordt om SSH-verbindingen te leggen. Dat gebeurt via glibc - systemen zijn dus alleen kwetsbaar als ze die library geïnstalleerd hebben, maar dat is vrijwel altijd het geval. De malware gebruikt vervolgens glibc-mechanisme Ifunc om het authenticatieprotocol in OpenSSH te omzeilen.

Sommige onderzoekers zien de bug als een remote code execution-kwetsbaarheid
Er zijn verschillende technische write-ups van de malware die meer de diepte in gaan dan wij hier kunnen doen. Voor een uitgebreide beschrijving kun je de analyse van Filippo Valsorda lezen, die uitlegt waarom hij vindt dat de bug niet alleen een authenticatieomzeiling is maar een remote code execution. Verder heeft Sam James een goede uitleg geschreven waarin ook staat onder welke voorwaarden de malware werkt. Ook heeft securityonderzoeker Gynvael Coldwind een uitgebreide analyse geschreven over hoe een infectie met xz-utils werkt.

Wie zit er achter de malware? En is dit een achterdeur, of gewoon een fout?

In de afgelopen dagen zijn onderzoekers dieper gedoken in misschien niet de belangrijkste, maar wel interessantste vraag rondom de bug: hoe kon dit gebeuren? Inmiddels is duidelijk dat xz-utils dan wel door miljoenen computers mag worden gebruikt, maar slechts door twee personen wordt onderhouden. Het doet daarmee wat denken aan de kwetsbaarheid in Java-library log4j, dat in praktisch alle software zat, maar door slechts een persoon werd onderhouden.

Bron: XKCD

Bij xz-utils lijkt ook weer het door XKCD omschreven probleem om de hoek te kijken, al lijkt de situatie ook wat anders te liggen. In deze uitgebreide analyse van Evan Boehs is de geschiedenis van xz-utils terug te lezen, en dan specifiek van een van de twee maintainers. Xz-utils werd onderhouden door Jia Tan, die zich JiaT75 noemt, en door Lasse Colin, die als Larhzu bekendstaat. Larhzu heeft beheer over de website van xz en schrijft daar kort over de situatie, waarin hij afstand lijkt te nemen van Jia Tan. "Xz-utils 5.6.0 en 5.6.1 bevatte een backdoor. Deze tarballs zijn gemaakt en ondertekend door Jia Tan", schrijft hij. Evan Boehs schrijft dat Jia Tan zijn GitHub-account in 2021 aanmaakte en als eerste commit al een push request deed naar de tool libarchive, wat terug te vinden is in zijn profiel.

Jia Tan werd in juni 2022 een maintainer van xz-utils, samen met Lasse Colin. Zij waren in de afgelopen twee jaar de enige personen die de tool bijhielden. Sindsdien heeft Jia Tan meerdere keren een aanpassing doorgevoerd aan xz-utils waarvan nu blijkt dat ze het systeem mogelijk onveilig hebben gemaakt. Op 23 februari en 9 maart voerde Jia Tan nog twee aanpassingen door die uiteindelijk zouden leiden tot de achterdeur.

Alhoewel, achterdeur? Kunnen we dat wel zo stellig zeggen? Een achterdeur impliceert namelijk een bewuste actie. Het zou in theorie mogelijk kunnen zijn dat iemand commits deed naar xz-utils onder Jia Tans naam. Maar recente acties van de ontwikkelaar maken dat onwaarschijnlijk. Zo zegt een ontwikkelaar van Fedora dat Jia Tan wekenlang in gesprek was met hem en andere Fedora-ontwikkelaars om de tool in het OS te krijgen 'vanwege de prachtige nieuwe features'. Bovendien lijkt het onwaarschijnlijk dat Jia Tan oprecht dacht dat de aanpassingen verbeteringen waren; daarvoor is de malware veel te gedetailleerd. Bovendien deed de malware aan stevige obfuscatie, waardoor iemand, waarschijnlijk Jia Tan, uiteindelijk probeerde de malware stil te houden.

Met welk doel dat gebeurde en of Jia Tan bijvoorbeeld als staatshacker werkte, is nog verre van bekend. Daar wordt veel over gespeculeerd, maar het is nu nog te vroeg er iets over te zeggen. Onderzoekers bestuderen de malware nog; verwacht daar in de komende weken meer informatie over.

Reacties (192)

[deadinspace]

Uit het artikel:

Alhoewel, achterdeur? Kunnen we dat wel zo stellig zeggen?

Ehh, ja.

• De backdoor bevindt zich niet in de xz source code zelf, maar in geobfusceerde vorm in een gecomprimeerd test-bestand in de tests/ directory.
• Deze geobfusceerde code wordt tijdens het compileren van xz geïnjecteerd in de source code waardoor het in de executable terecht komt.
• De stappen voor het injecteren tijdens het build-proces zijn niet aanwezig in de repo zelf, maar alleen in de "release tarballs", zodat de kans kleiner is dat mensen het zien. En deze stappen zijn ook weer geobfusceerd.
• De backdoor zit in een compression library, maar activeert specifiek wanneer deze gebruikt wordt door /usr/bin/sshd. Dan vervangt hij een authenticatie-functie van SSH (RSA_public_decrypt) door zijn eigen versie.
• De backdoor authenticatie-functie controleert of er ingelogd geprobeerd te worden met een ingebakken private key. Zo ja, dan pakt hij een specifiek deel van het authenticatie-bericht, ontsleutelt dit met een ingebakken sleutel, en voert het resultaat uit als commando.
• Om deze SSH functie te vinden gebruikt de backdoor gedeeltelijk handmatige code. Een ander gedeelte plaatst een hook in de dynamic linker library om dit te bereiken. De backdoor verwijdert deze hook weer nadat de SSH functie gekaapt is.
• De backdoor in de xz library checkt door welke executable hij ingeladen wordt. Alleen als dit /usr/bin/sshd is dan activeert de backdoor.

Er bestaat echt geen enkele twijfel over dat dit een backdoor is.

De hele backdoor heeft heel wat moving parts. Hij heeft expliciete code voor SSH (dat gebeurt niet per ongeluk in een compression library), welke expliciet de authenticatie hijackt, en expliciet een payload uitvoert als een specifieke sleutel gebruikt wordt. En er zijn meerdere manieren waarop de code en het proces expres gescrambled zijn om alles te verbergen.

Dit is een hele geraffineerde aanval, en niks anders.

[Reactie gewijzigd door deadinspace op 22 juli 2024 19:24]

[ernstoud]

In de journalistiek geldt algemeen dat als er een vraagteken staat in de kop, het antwoord “ja” is.

Volgens DPG gaat de effectiviteit van het artikel zelfs met 17% omhoog:

https://campus.dpgmedia.n...e-een-kop-die-viral-gaat/

Is dus gewoon een truc. Wel een irritante truc.

[Muncher]

Volgens mij is het juist andersom. Een vraagteken betekent meestal dat het antwoord “nee” is.


https://en.m.wikipedia.or...idge%27s_law_of_headlines

Betteridge's law of headlines is an adage that states: "Any headline that ends in a question mark can be answered by the word no." It is named after Ian Betteridge, a British technology journalist who wrote about it in 2009, although the principle is much older.[1][2] It is based on the assumption that if the publishers were confident that the answer was yes, they would have presented it as an assertion; by presenting it as a question, they are not accountable for whether it is correct or not.

[Devalno]

Uit de quote die je geeft: "CAN be answered by the word no", dat betekent dus niet het antwoord ook echt "nee" is, en uit de toelichting erachter blijkt ook dat het "correct or not" kan zijn.

[Hans1990]

Die law wordt op Wikipedia verwant gesteld aan clickbait. Met 2009 als tijdperk werd het internet ook steeds schreeuwender om aandacht. Iedereen kan iets geks in een nieuwskop zetten.. maar dan als vraagstelling zodat vaak uiteindelijk toch gewoon nee kan worden beantwoord maar er dus ook geen "onzin" is verkocht.

Voor dit artikel vond ik dat deze vraagstelling al eerder duidelijk beschreven/bewezen was (nieuwsartikel van vandaag), dus ik snapte deze kop al niet zo. Het was sensationeler geweest als dit artikel vragen ging stellen over open-source software, of we dat kunnen vertrouwen, of dat ontwikkelmodel nu niet publielijk keihard gefaald heeft o.i.d.
(Zou ik nog oprecht interessant vinden om te weten hoeveel meer van dit soort heterdaadjes meer gevonden zijn, eventueel in relatie met closed-source software, en ook hoelang dat gemiddeld geduurd heeft)

[Reactie gewijzigd door Hans1990 op 22 juli 2024 19:24]

[ernstoud]

Ah. Dank voor de correctie!

En dan klopt hij hier dus niet. Want het is dus echt een backdoor.

(Nou ja, de research loopt nog, maar vrijwel zeker.)

[Reactie gewijzigd door ernstoud op 22 juli 2024 19:24]

[EwickeD]

Sterker nog, je gelinkte artikel van DPG zegt zelfs.
Gebruik geen vraag als kop, dat levert alleen twijfel over wat je gaat lezen.
Doe liever juist een belofte over het antwoord dat de lezer gaat krijgen, effectiviteit +17% als je de vraag weg laat!

Dus reken hier gerust 100% clicks voor dit artikel, in plaats van die 117%

[De Vliegmieren]

Dat verandert niets aan het feit dat het antwoord op deze vraag zoals opgeschreven in het artikel klinklare onzin is.

Een kul argument opvoeren alleen om maar een bepaalde vraag te kunnen stellen doet geen goed aan de kwaliteit van het artikel.

[Reactie gewijzigd door De Vliegmieren op 22 juli 2024 19:24]

[TechSupreme]

https://www.youtube.com/watch?v=S2xHZPH5Sng

Ze doen het omdat het werkt.

[ernstoud]

Ik lees net dit: “With no previous activity under this handle, JiaT75 signed up for GitHub in 2021 and went to work immediately on the projects on the xz utilities. The account has no identifying information beyond a gmail address.”

(Bron: https://thenewstack.io/li...d-be-greater-than-feared/)

Dus als ik het goed begrijp kun je in open source projecten committen met alleen een Gmail (sic!) adres. Zonder enige andere verdere identificatie.

Lekker.

[RobertMe]

Tuurlijk kan dat. Waarom zou dat niet kunnen? Normaliter doorloop je een "proces" waarbij je via pull request wijzigingen indient die gecontroleerd worden etc etc. En op basis van dat iemand vaker kwalitatieve PRs aanmaakt etc kan het dan voorkomen dat iemand meer rechten krijgt. Of er nu "shortcuts" zijn genomen durf ik echter niet te zeggen. Maar gezien de (persoonlijke) situatie van de hoofd ontwikkelaar en dat er toentertijd wat "druk" op is gezet zou het zomaar kunnen dat er inderdaad shortcuts zijn genomen. En in die communicatie toen heeft de hoofd ontwikkelaar ook aangegeven dat hij contact had met deze bad actor, buiten de mailing list om. In hoeverre dat wel of niet was voordat hij uberhaupt een PR had gemaakt durf ik echter niet te zeggen.

En wat is er inherent mis met een gmail adres? Niet dat ik er zelf fan van ben. Maar als ik contributions doe aan projecten gebruik ik daarvoor een uniek emailadres onder mijn eigen domein (<project>@<mijn-domein>), zou je dat dan wel betrouwbaar vinden? Of contributions van een account van een ISP die je niet kent? Als je meewerkt aan bv een "Amerikaans" open source project zegt een @kpn.nl / @ziggo.nl / @delta.nl emailadres net zo goed helemaal niks.

En zo heb ik vorig jaar ergens ook "totaal uit het niets" een pull request gedaan bij systemd om een probleem op te lossen. Werd zonder veel gedoe gewoon goedgekeurd. Sure, er zijn wat iteraties van code review en "fixes" overheen gegaan. Maar het is niet dat ik eerst een sollicitatiegesprek of zo moest doen voordat ze mijn PR "in behandeling" zouden nemen.

[ernstoud]

Dus ik moet het normaal vinden dat je zonder enige verdere identificatie zo ver kunt komen zoals nu gebeurd is met XZ? Alleen op basis van “vertrouwen”?

Nou, jammer dan. Ik vind dat dit niet normaal is. Als een developer/maintainer op basis van het vertrouwen van iemand die hij nooit gezien heeft commits doorzet naar productie dan valt foss wat mij betreft van het voetstuk.

Ik heb vele software development teams mogen auditen tegen 9001 en 27001 en zag dan vaak in de agile werkwijze in sprints dat er vele kwaliteitswaarborgen ingebouwd waren. Niemand in die teams zou het in zijn hoofd halen commits te accepteren van iemand waarvan je alleen een e-mail adres hebt. Dat is bij closed source in ieder geval wat beter, hiërarchie, vertrouwen op basis van CV, peer review bij inhuur e.d.

Maar goed, het schijnt dus normaal te zijn. Mijn nekharen staan in ieder geval overeind.

En dan ook nog zover kunnen komen dat oss-fuzz geen alarm sloeg omdat de kwaadwillende ook daar kon handelen. Oi.

En ja [e-mail] vertrouw ik nog minder dan [e-mail] of zo iets.

Interessante video over dit vertrouwen en de schade die het veroorzaakt: https://x.com/feross/stat...&t=A9TlanwkjtYIUreAgKfKQA

[Reactie gewijzigd door ernstoud op 22 juli 2024 19:24]

[RobertMe]

Dus ik moet het normaal vinden dat je zonder enige verdere identificatie zo ver kunt komen zoals nu nu gebeurt is met XZ? Alleen op basis van “vertrouwen”?

Wat jij normaal moet vinden ga ik me niet mee bemoeien Maar dit is wel een voorbeeld van de gang van zaken. Die in het geval van xz natuurlijk gigantisch fout is gelopen, en dat is "niet normaal" nee. Maar wel te verwachten. Aangezien soms (/vaak?) van die kleine 1 mans projecten ineens aan de grondslag van heel veel systemen komt te liggen.

Nou, jammer dan. Ik vind dat dit niet normaal is. Als een developer/maintainer op basis van het vertrouwen van iemand die hij nooit gezien heeft commits doorzet naar productie dan valt foss wat mij betreft van het voetstuk.

Tsja, dat is ook een beetje inherent aan open source he. Iedereen kan er aan bijdragen. Maar dat betekend natuurlijk niet dat de maintainer elke bijdrage ook moet accepteren. Daarom is het totale proces ook belangrijk. Code reviews, duidelijke coding styles, geen vage code accepteren, etc etc. En bij grotere projecten werkt dat an zich prima. Ook vele projecten waarbij PRs niet gemerged worden voordat 2 maintainers / "vertrouwde personen" deze PR goedkeuren.

Ik heb vele software development teams mogen auditen tegen 9001 en 27001 en zag dan vaak in de agile werkwijze in sprints dat er vele kwaliteitswaarborgen ingebouwd waren. Niemand in die teams zou het in zijn hoofd halen commits te accepteren van iemand waarvan je alleen een e-mail adres hebt.

Geen enkele van die bedrijven maakte gebruikt van software bibliotheken die open source zijn? Want als ze dat wel doen is er 99,99% kans dat ze dus gebruik maken van code die een "anoniemeling" heeft geschreven. En vergeet daarbij ook niet dat vele programmeertalen "van zichzelf" open source zijn. De huidige .NET is open source (uiteraard wel primair ontwikkeld door Microsoft, maar eenieder kan er anoniem aan bijdragen), Java is open source, PHP is open source, Chromium & Firefox zijn open source (met daaraan gelieerd dus Chrome, Edge, Vivaldi, Brave, Opera, ... die allemaal die open source code met anonieme bijdragen bevatten), NodeJS is open source (waarschijnlijk ook nog steeds gebaseerd op de JS engine van Chromium), Python is open source, etc etc.

En for what it's worth: ik ben werkzaam als programmeur in een bedrijf met ISO 9001 en NEN 27001 certificering. En ja: wij gebruiken gewoon open source software bibliotheken, waarbij wij niet handmatig elke regel code controleren. Heeft bij mijn weten nog nooit een auditor naar gekraaid. Uiteraard zijn er wel waarborgingen over welke software bibliotheken we wel of niet "mogen" gebruiken of in hoeverre we daadwerkelijk zelf de code "auditten" voordat we die toevoegen.

Dat is bij closed source in ieder geval wat beter, hiërarchie, vertrouwen op basis van CV, peer review bij inhuur e.d.

Hoezo is dat beter? Al helemaal als het daadwerkelijk "peer review bij inhuur" is. Iemand die het bedrijf gewoon vers aanneemt wordt geen code van gereviewed en die kan op dag 1 malafide code toevoegen? Terwijl deze bad actor bij xz 700+ commits heeft gedaan, waarvan er enkele (tientallen?) wellicht gelieerd zijn aan deze exploit. Die andere 700+ lijken dus daadwerkelijke bijdragen te zijn waar niks mee aan de hand is. En ja, op een gegeven moment ga je zo iemand dan wellicht vertrouwen. Zeker ook met de staat van xz: 1 developer die alleen de kar trekt. Die ook onbetaald is om er aan te werken etc. Dus dan kun je niet verwachten dat 1 iemand "voor de hobby" zijn "vrije" tijd investeert in het reviewen van (alle) code van deze bad actor. Op een gegeven moment heeft diegene zich "bewezen" om goede code af te leveren.

En dan ook nog zover kunnen komen dat oss-fuzz geen alarm sloeg omdat de kwaadwillende ook daar kon handelen. Oi.

Niet vergeten dat oss-fuzz geen security "systeem" is. Het is een project om "fuzzing" te doen op open source projecten om crashes te vinden. Bullshit in ("fuzzen") => mag geen crash opleveren. Dat is het doel van het "oss-fuzz" project. Daar zit geen security idee achter.

En ja [e-mail] vertrouw ik nog minder dan [e-mail] of zo iets.

Dat was natuurlijk niet het voorbeeld wat ik stelde Waarbij @redhat.com dus ook nog eens gelieerd is aan een bedrijf (/multinational, naar ik aanneem). Vervang [e-mail] eens met [e-mail] of een willekeurige ISP. Of [e-mail] / [e-mail] / ....

Edit (op de toevoeging van de edit):

Interessante video over dit vertrouwen en de schade die het veroorzaakt: https://x.com/feross/stat...&t=A9TlanwkjtYIUreAgKfKQA

Video niet gekeken, maar:

There's a CONSTANT low-level stream of malware and spyware being uploaded to npm, PyPI, and Go registries.

I want to share a few examples from the 20,000+ malicious packages we detected so far:

Dat is een totaal andere situatie. 20k+ malicious packages die malware en spyware bevatten zullen in zeer veel (de overgrote meerderheid) packages zijn die alleen bestaan om malicious te zijn. Bv een "typo" variant op een "goed" package. Dus populaire library X heeft 1 miljoen (en meer) downloads, maak vervolgens een package met naam X' met dezelfde code en malware / spyware toegevoegd en zet dat op npm / PyPI / Go registry / .... Gegarandeerd dat er (kleine groepen) mensen zijn die dan per ongeluk jouw malafide package gebruiken.
Maar dat is niet de situatie die bij xz aan de hand is. Daar is het daadwerkelijke officiele package malafide geworden door een bad actor. Terwijl van die 20.000+ malafide packages waar die X post over gaat niet zal gaan over "xz" maar over package "yz", dat heel veel lijkt op "xz", en ook hetzelfde doet, maar malware / spyware bevat. En dat is een heel ander probleem in de software development wereld.
Waarbij bv ook GitHub kampt met dit probleem: nieuws: GitHub overspoeld met malafide repository's

[Reactie gewijzigd door RobertMe op 22 juli 2024 19:24]

[cariolive23]

En for what it's worth: ik ben werkzaam als programmeur in een bedrijf met ISO 9001 en NEN 27001 certificering.

Kortom, jullie hebben een sticker gekregen bij een zakje chips...

Hiermee wil ik niet zeggen dat jullie slecht werk leveren of niks kunnen, verre van dat. En ik weet dat je die certificaten nodig hebt omdat klanten dit eisen, dat is ook de reden waarom wij deze ook hebben. Maar het is imho niet meer dan een grote wassen neus. Het zegt iets over jullie processen, maar niks over de kwaliteit of functionaliteit die jullie leveren. Een goed proces kan wel structureel tot hogere kwaliteit leiden, maar dat hoeft niet. Met zwemdiploma kun je ook verdrinken.

In het geval van opzet vrees ik echter dat geen enkel certificaat je gaat helpen.

[ernstoud]

Je laatste zin klopt. Uit de rest van je betoog haal ik dat je geen waarde hecht aan kwaliteitseisen. Dat hoor ik vaak. Toch is het fijn dat de mensen die naast je rijden op de snelweg een rijbewijs hebben.

27001 garandeert niet dat je security perfect is, maar de tienduizenden bedrijven wereldwijd die kwaliteit - ook van security processen - serieus nemen zijn gemiddeld gesproken beter bezig dan degenen die dat niet doen.

Een wassen neus is het beslist niet. Ik denk dat jij ook graag in een vliegtuig stapt waar de onderhoudsprocessen met kwaliteitsprocessen geborgd zijn.

Dat je zo spreekt over dit proces bij je werkgever vind ik merkwaardig, eigenlijk zeg je dat het niet belangrijk is. Bijzonder. Ik zou juist trots zijn op mijn werkgever als ze dit soort borging belangrijk vinden.

[cariolive23]

Ik ben zelf werkgever en wij hebben deze certificaten met bijbehorende processen in place. En juist daarom prik ik er zo makkelijk door heen. Het certificaat zegt weinig, de mensen die de processen uitvoeren echter wél. Het draait om hen, om hun kennis en kunde.

Het papiertje zelf, dat is een moment opname, een lijstje met wat vinkjes

[ernstoud]

Sorry, maar dan begrijp je niet hoe een ISMS kan bijdragen de kwaliteit te verbeteren. Het certificaat zelf is een papiertje (pdf tegenwoordig) maar als je het ziet als een vinkjes lijst heb je nog een weg naar volwassen kwaliteitsmanagement te gaan.

[Firefox]

Enig cynisme kan hem niet ontzegd worden, dat is waar, maar er zit een kern van waarheid in. Het hebben van een ISO9001 of 27001 kán een bepaalde mate van kwaliteit aantonen, maar in de praktijk heb ik toch te vaak meegemaakt dat de audits teveel gericht waren op het halen van het papiertje, inclusief training vooraf over wat wel/niet te zeggen bij vragen van de auditor. Sample verzameling van de picture perfect tickets vss de kwalitatief uitermate teleurstellende gevallen, auditors die duidelijk bezig waren om de audit taak van volgend jaar alvast veilig te stellen. Altijd een paar minors vinden om te laten zien dat ze echt wel gekeken hadden, maar niet verder dan strikt noodzakelijk.

En dan moet je ook nog rete scherp zijn op wat er in scope van de audit is. Je kan je wc bij wijzen certificeren, maar de rest een zwijnenstal maken.

Intenties van de goeden daargelaten, er lopen veel te veel beunhazen rond om echt blind op het papier te vvertouwen

[ernstoud]

Helemaal correct. En jammer genoeg gaan bedrijven die niet gaan voor kwaliteitsborging maar voor het papiertje daar in mee. Natuurlijk moet je als organisatie een auditor die jou niet helpt beter te worden, de deur wijzen. Je moet dat niet accepteren.

Ik heb nooit begrepen dat bedrijven tienduizenden euro’s uitgeven om een papiertje te halen zonder echt beter te willen worden.

Een collega van in me in dat werk heeft een keer een dergelijk bedrijf een kindertekening gegeven. Hier heb je je papiertje,… zullen we nu kijken of het beter kan bij jou?

[FreezeXJ]

Sommige (en ik vrees teveel) bedrijven hebben de certificering alleen omdat een afnemer/jurist het vereist, en niet omdat ze zelf goed bezig willen zijn.
Dat verklaart ook waarom ze voor een dubbeltje op de eerste rang willen zitten: het is een kosten-baten-analyse van het verkeerde type.

[ernstoud]

Klopt helemaal. Ik heb de manager van zo’n bedrijf na een paar jaar bij een audit wel horen zeggen dat hij langzamerhand er zelf ook wel wat aan had.

Dat is de “weeffout” bij ISO normen, je moet een certificaat verstrekken als een organisatie aan de eisen voldoet, ook al is het zeg maar een 6- i.p.v. een volwassen mangementsysteem. Maar goed, we komen elk jaar of vaker als het moet. En dan zie je vaak toch wel groei.

Maar goed, we dwalen af.

[aikebah]

Een wassen neus is het beslist niet. Ik denk dat jij ook graag in een vliegtuig stapt waar de onderhoudsprocessen met kwaliteitsprocessen geborgd zijn.

Volgens mij had boeing ook gewoon alle stempeltjes behaald en hebben ze toch ontdekt dat bij nader inzien ze niet genoeg kwaliteit(scontrole) leverden. Niks in het nieuws gezien over auditors die daar vooraf over hadden gerapporteerd dat de processen niet op orde waren.

[ernstoud]

Dus als jij iets niet in het nieuws ziet dan was het er niet? In de aviation wordt meer geaudit dan waar dan ook. Maar het management moet er wel wat mee doen. Dat ging fout daar omdat Airbus ze op de hielen zat (zit).

[aikebah]

Met de aandacht die de pers voor Boeing heeft gehad vertrouw ik er wel op dat inderdaad een stevige waarschuwing uit zo'n certificeringstraject wel boven tafel was gekomen ja.

Niets ten nadele van jou, zo te lezen ben jij uit het goede hout gesneden, maar bij veel audits wordt naar mijn gevoelen te weinig doorgevraagd, waarna een goedkeuringsstikkertje in het boekje geplakt mag worden (met als gevolg meer een papieren dan een werkelijke veiligheid).

[ernstoud]

Ja, er zijn mindere goden ook in het audit werkveld. Punt is dat het vaak proces auditoren zijn. Maar ISO 27001 beschrijft dan wel een proces, de security wordt pas beter door implementatie van (de juiste) maatregelen. Dat betekent dat een auditor van al die 94 maatregelen in de annex A. diepgaande kennis moet hebben.

En dat hebben veel auditoren niet. Als ik vraag aan een systeembeheerder welk provisioning tool ze gebruiken, Ansible of zo, dan zie ik soms verwarring. Ik zie ze dan denken “oh shit, een auditor met kennis”.

En dan ook met de facility manager fysieke security, met HR hoe screening gaat, met legal hoe de compliance ingericht is, je ziet het probleem. A mile wide and a mile deep. Meeste auditors gaan een mile wide and an inch deep.

En het management weet vaak geen ander antwoord te bedenken op de vraag wat hun doelstelling is voor de security processen dan dat ze zich aan de wet moeten houden. Welke wetten dat dan zijn wordt al wazig voor ze, en wat klanteisen zijn al helemaal.

[Tozz]

ISO27001 is dan ook geen 'kwaliteitsnorm'.

[cariolive23]

ISO/IEC 27001 is an international standard to manage information security.

Indirect gaat het altijd over kwaliteit: Hou je jezelf aan de standaard Ja of Nee.

En 9001 is zeker wel een kwaliteitsstandaard, maar ook die gaat over het proces en niet over het product.

[ernstoud]

Niet? Zeker wel! Security is een deel van de kwaliteit van je product of dienst.

[MeMoRy]

Dit.
Het zo'n mijn inziens vooral mensen die verdienen aan standaarden en certificaten die roepen hoe belangrijk die normen zijn. Ik heb meerdere audits die verschillende personen meegemaakt. Werd alleen een beetje gekeken naar of protocollen gevolgd werden en of dingen tracable waren.
En bad actor kan net zo goed leren dat systeem te bespelen.
Ik vind het maar een wassen neus. Het is totaal niet alsof het bug free software garandeert. Maar goed, bij gebrek aan beter gebruikt iedereen in bepaalde sectoren dit maar.

[Reactie gewijzigd door MeMoRy op 22 juli 2024 19:24]

[ernstoud]

“En for what it's worth: ik ben werkzaam als programmeur in een bedrijf met ISO 9001 en NEN 27001 certificering. En ja: wij gebruiken gewoon open source software bibliotheken, waarbij wij niet handmatig elke regel code controleren. Heeft bij mijn weten nog nooit een auditor naar gekraaid.”

Slechte auditor, of niet al te kritische systemen? 27001 vereist secure system development. En dus hebben ontwikkel teams mij mogen uitleggen hoe en wat. Welke tools zoals oss-fuzz, brakeman e.v.a. ze gebruikten. En in kritische omgevingen kom je dan echt niet weg met “we vertrouwen deze library”. Maar goed, niet elke auditor vraagt door.

En zeker, bijna iedereen gebruikt ergens foss, ook bij closed source teams. Maar ik hoop echt dat dat er meer controle en minder vertrouwen is, of laten we zeggen gezonde achterdocht, als het gaat over vliegtuigbouw, kerncentrales en distributie van hoogspanning (allemaal processen die ik heb mogen zien van dichtbij).

In de open source wereld hoop ik dat van dit gebeuren geleerd wordt. Maar ik twijfel daar aan. Heartbleed is 10 jaar geleden. Is daar wat van geleerd? Log4j?

In de post op X die ik hierboven linkte laat Socket zien wat zij zien in bijvoorbeeld npm of in de Python repositories. Schrikken.

[Tozz]

> Slechte auditor, of niet al te kritische systemen?

Een auditor toetst vooral de werking van je ISMS. Die zal niet snel zich bekommeren om de specificieke risico's die de organisatie heeft bedacht. Het is aan de organisatie zelf om risico's te herkennen en deze te beoordelen.

De juiste stap in jullie organisatie zou nu zijn dat er nu wordt opgemerkt 'Hmm, die open source libs zijn een risico. We gaan dit risico classificeren'. Dan komt daar een classificatie uit op basis van kans en impact.

Als het totaal van kans * impact boven een bepaalde grenswaarde komt dan moet het risico behandeld worden. Maar je kunt ook stellen 'met alle miljoenen open source projecten komt dit 1x per zoveel jaar voor, de kans is zeer klein'. Grote kans dat je de grenswaarde niet haalt, en dan kun je het risico accepteren zonder verdere behandeling. Dan ben je klaar en heb je conform ISO27001 gehandeld en ben je in control over je risico's.

Ik moet de 1e auditor nog tegenkomen die met mij in discussie gaat over hoe wij risico's hebben beoordeeld.

[ernstoud]

Eh, die laatste zin… je had dan aan mij een andere auditor dan die je nu had… want je moet aan mij wel degelijk laten zien hoe je de risico’s beoordeeld hebt. En dan is “goed” geen antwoord.

Een SW development club in een kritische omgeving, zeg een kerncentrale mag mij dus meer uitleggen dan wat jij hier schetst. Want de certification body neemt wel risico. Hun naam staat op het certificaat.

Dus ook al toetsen we “alleen een ISMS”, je moet me laten zien dat je de juiste risico’s afdoende beheerst. En wat is afdoende? Dat blijkt uit je context. Dus wat de in jou geïnteresseerde partijen van jou verwachten. Niet wat jijzelf bedenkt.

In de context van dit XZ… de gebruikers verwachten geen back door. Wat heb je er dan aan gedaan om dat te voorkomen? Laat maar zien. Je development proces, je competentie management, je test systemen, etc. Alles wat relevant is uit Annex A.

Maar goed, er zijn helaas auditors met te weinig verstand van security. Die dus alleen het proces maar niet de inhoud toetsen.

[Tozz]

> Eh, die laatste zin… je had dan aan mij een andere auditor dan die je nu had… want je moet aan mij wel
> degelijk laten zien hoe je de risico’s beoordeeld hebt. En dan is “goed” geen antwoord.

Wat ik bedoel is dat er een procedure moet zijn hoe je risico's behandeld en beoordeeld. Een auditor behoort zich niet te bemoeien met hoe dat proces er dan precies uitziet en of dat al dan niet de risico's goed inschat. Concreet kan ik dus een risico als zeer laag classificeren terwijl dat achteraf verkeerd blijkt te zijn, of andersom. Het is niet aan een auditor om met mij ruzie te gaan maken hoe hoog een bepaald risico zou moeten scoren. Als het is geclassificeerd volgens mijn risicoclassificatie procedure is het oke.

Terug naar dit voorbeeld.. Als een auditor het oneens is dat ik dit probleem met xz als laag risico inschat dat geen mitigerende behandeling vereist (als normale IT club), als ik dat gewoon conform mijn risicobeoordeling heb behandeld, hebben we een gezellige middag

[ernstoud]

Ja, ik bemoei me wel met hoe dat RA proces er uit ziet want 27001 beschrijft in clausule 6 dat proces. Alle eisen daarin moet ik toetsen. En dat de RA gebaseerd is op de contextanalyse, en dat het management betrokken is en besluiten neemt en je de juiste risicoreducerende maatregelen getroffen hebt.

En belangrijk; dat je ook de maatregelen met juridische basis (ook civielrechtelijk in contracten genoemd) geïmplementeerd hebt, ondanks dat ze voor jou geen risico reduceren.

Etc. Etc.

De risicoanalyse en het proces is een wezenlijk onderdeel van de audit!

En voorbeeld: ik mag zeker challengen waarom je een camera bij de leveranciersingang niet belangrijk vindt als die deur de hele dag open staat en je wel poortjes bij de ingang hebt. Leg maar uit..

Leg maar uit waarom je weinig aan bewustwording doet omdat “je capabele mensen inhuurt” maar wel veel incidenten hebt.

Een auditor die niet challenged is de sop niet waard. Niet zijn/haar wil oplegt (gebeurt veel - die auditor moet je wegsturen) maar luistert, begrijpt en prikkelt, aan het denken zet, verbeteringen signaleert t.o.v. compliance met de eisen etc.

Ja, je mag zelf met veel vrijheid dat RA proces inrichten. Maar je moet je keuzes wel onderbouwen. En dat gaat vaak mis. Dan heb je aan mij een slechte.

Als je een auditor hebt die je RA proces en je keuzes niet toetst en challenged moet je een andere vragen.

[bart.koppers]

Ik moet de 1e auditor nog tegenkomen die met mij in discussie gaat over hoe wij risico's hebben beoordeeld.

Dat zegt voornamelijk wat over de kwaliteiten van de auditors die je inzet. Risicobeoordeling is zo ongeveer het belangrijkste in audits.

[ernstoud]

Jij begrijpt het. In de opleiding IT auditor wordt het er in gehamerd. Audit vereist een risico gebaseerde aanpak. De diepte in waar het nodig is dus.

[FreezeXJ]

Moet je die diepgang wel hebben... De auditors die ik heb langs zien komen (en vaak ook niet meer dan dat) zitten 2 dagen in een hokje met de chef-security en that's it. Meer dan 'hebben jullie een versioning systeem' komt er vaak niet uit. Laat staan dat ze vragen wat er _niet_ in dat versioning systeem zit

[ernstoud]

Ja, het is een vak. En de kwaliteitsbewaking door de Raad voor Accreditatie zou wat mij betreft veel strakker moeten.

[ernstoud]

Nee, het is geen andere situatie die Socket hier toont. Zoals hij ook in het begin van de video zegt; “De foss wereld is gebouwd op vertrouwen.”, en vervolgens laat hij zien waar dat toe leidt… honderden tools, snippets etc. met dubieuze code. Die gewoon vertrouwd worden. Zoals log4j ook vertrouwd werd.

Dat is wat ik wilde zeggen… dat “vertrouwen” moet anders ingericht worden. Wat is er mis mee dat je je identiteit moet bewijzen als je commits plaatst? Net zoals dat je bij een bedrijf je je ID een keer hebt moeten laten zien? En je CV?

Natuurlijk niet waterdicht. Maar de duimschroeven iets dichter zetten is zinvol.

Ook fijn: van 3,3% van de changes in de Linux kernel is niet bekend waar de committer werkt. En meer dan 13% van de changes werkt bij het bedrijf “None”.

https://x.com/securityfreax/status/1774406278875423050?s=20

Maar goed, Linus Torvalds zit er bovenop … vol vertrouwen.

[Reactie gewijzigd door ernstoud op 22 juli 2024 19:24]

[dasiro]

gezien deze situatie en je achtergrond: zou dit voor jou professioneel gezien een reden zijn om alle geïmpacteerde distro's als onbekend (en dus waarschijnlijk hoog) risico in te schalen? Zo ja, dan zou dit een klein bommetje leggen onder het volledige gebruik ervan in (kritische) infrastructuur.

[ernstoud]

Ja. Maar dat is nu al zo. In zeer kritische omgevingen is het standpunt dat niets vertrouwd wordt. Maar dan nog is infiltratie een groot risico. Zit in de risicoanalyses, dus AIVD screening, background checks e.d., veel interne checks in de teams, monitoring van het team etc.

Ook niet 100% maar close.

[Tozz]

En nu terug naar de werkelijkheid. Wat had in dit geval met xz of jouw log4j voorbeeld het geholpen als de identititeit van de comitter bekend was? Log4J was geen backdoor, eerder een knullige bug. Daar zijn er wel meer van. De backdoor in XZ was behoorlijk obfuscated en is ook niet direct opgemerkt. Dus ook hier, als we de identiteit van de persoon die 't heeft gecommit wisten was er niets voorkomen. Je had alleen iemand makkelijker aan de schandpaal kunnen nagelen.

Het enige dat je gaat bereiken is dat men minder snel geneigd is om mee te ontwikkelen bij FOSS en de echte kwaadwillenden gaan gewoon door op een minder opzichtige manier. Dus commits die bewust fouten bevatten maar die ook als reguliere security bug kunnen worden beoordeeld. In andere woorden, 'plausible deniability'.

Datzelfde gaat ook op voor werknemers binnen een organisatie. Iemand die werkzaam is bij Microsoft kan ook backdoors in de code toevoegen die niet direct als zodanig te herkennen zijn. Maar dan vertrouw je Microsoft wel op haar blauwe ogen? Da's toch raar?

Om een vergelijking te trekken met de echte wereld.. De legitimatieplicht op straat heeft ook nog nooit 1 strafbare handeling voorkomen.

Tegelijkertijd kun je dit naar mijn idee prima technisch afvangen door een zero trust model toe te passen in je infrastructuur.

[ernstoud]

Bijzonder dat als het om software ontwikkeling gaat, de identiteit en het vertrouwen opeens niet meer belangrijk is. Dus als een volslagen onbekende bij je aan de deur komt en je een kauwgombal aanbiedt heb je geen twijfel?

Bij een maintainer met alleen een Gmail adres ook niet?

Ik zeg nergens dat vertrouwen, elkaar in de ogen zien, teambuilding, training, identiteit, motivatie, screening, vakmanschap, CV etc. etc. alle garanties geeft, maar helpen doet het zeker.

Maar goed, ik heb in omgevingen gewerkt waar dit alles zo belangrijk is dat ik niet anders weet. Wellicht zie ik het verkeerd. In een kerncentrale iemand toelaten die zegt even mooie nieuwe functionaliteit in de software van de procescomputer te willen installeren? Zonder de genoemde aspecten die vertrouwen geven? No way.

En dat is normaal in de Foss wereld. En ik moet dat ook normaal vinden?

En het is erg flauw om dan die programmeur bij Apple (zullen we eens een ander voorbeeld nemen?) er bij te halen. Want daar worden dus juist al die genoemde zaken wel gedaan! Absoluut zeker dat dat de kans op bugs en malafide acties verlaagt.

En dan toch stonden er geen curly brackets om een if statement en werd de hele certificaat controle in iOS 12 overgeslagen. Oepsie. Shit happens.

Maar je moet dus wel de kans zo klein mogelijk maken.

Gelukkig zie ik posts overal en video’s op YT over dat in de (f)oss wereld dit een eye-opener is en dat het echt anders moet. Ik hoop het.

[AardbeiMeloen]

Bedenk je even dat deze vuln veel lastiger gevonden was geweest als het een closed source project was. Ik denk dat er oss projecten alsmede closed source bedrijven zijn die er heel losjes mee omgaan, maar ook (en hopelijk een meerderheid aan) plekken waar het extreem streng is.

Maar bij OSS blijft controle door het publiek makkelijker. Bij closed source moet ik de auteurs gewoon op hun woord geloven.

[ernstoud]

Dat moest je nu bij XZ toch ook? Gewoon vertrouwen? Ik begreep je betoog niet.

[FreezeXJ]

De controle wordt makkelijker gemaakt, maar wordt ie ook daadwerkelijk gedaan? Zeker als je ziet hoeveel energie er in deze exploit gestopt is dan is het best netjes dat ie gevonden is, en dat was niet door de code reviewer(s).
Daarna gaat er heel veel gewoon als bulk package mee met de rest, en wordt er alleen naar gekeken als er iets mafs gebeurt, zoals hier dus die vertraging die een onderzoeker opmerkte. Daar heb je geen source voor nodig.
Was dit bij closed-source gebeurd dan had de betreffende Jia nu een keurige rechtszaak aan z'n broek gehad wegens bad faith, en nu ... moeten we maar gokken wie het is/was.

[StCreed]

Ik heb ook PRs gepushed naar libraries van mensen die ik niet ken. In tegenstelling tot wat je denkt is dat juist veiliger dan wijzigingen van bekenden zomaar accepteren omdat je ze kent. Mijn commits worden juist streng onderzocht. En dat is beter dan "oh, ik ken hem, neem maar over".

Zero trust policies zijn al sinds zeker het jaar 2000 de norm in security land, dus ik vraag me af of je echt professioneel met security bezig bent geweest als je denkt dat iemand kennen garanties bied op veiligheid. Die misvatting heeft al veel schade veroorzaakt.

[ernstoud]

40 jaar IT, waarvan hoe helft in het Security werkveld. Auditor, consultancy etc.

Ja, ik denk dat iemand kennen vertrouwen geeft en leidt tot betere security. Dat is nl. overal zo, dus waarom zou dat bij security niet zo zijn?

En ik zeg “betere”, ik zeg niet “volledige”. Ook huwelijken stranden. Iemand goed kennen en vertrouwen kan alsnog tot problemen leiden.

Zero trust policies de norm? Ik zie ze weinig. Als ik als auditor aan developers vraag wat hun policies zijn, welke secure engineering principes ze hanteren e.d. zitten ze me soms aan te staren alsof ik vraag wat the meaning of life, the universe and everything is.

Maar goed, zolang ik functieprofielen bij een bank zie waarin gevraagd wordt of de kandidaat AMBI modules gehaald heeft, is er nog een hoop te doen. En dat is geen 1 april grap. Werkelijk vorig jaar gezien.

[Chris_147]

Als 58% van security incidenten door insiders worden veroorzaakt, dan denk ik niet dat iemand kennen tot betere security leidt.
https://www.raconteur.net/technology/insider-threats-risk

[ernstoud]

Ik ken dat soort onderzoeken, ze kloppen niet. Want wie is er schuldig aan ransomware. Het onderzoek zegt; degene die op een phishing e-mail reageerde. Dat is onzin. Schuldig is de kwaadwillende achter die phishing e-mail!

[StCreed]

Okee, het is m.i. de norm, maar helaas halen veel partijen die norm niet. Dat klopt wel.

Dat zie ik ook op andere gebieden. De incompetentie van een deel van de oudere COBOL-ontwikkelaars is stuitend. De informatie analisten die ik meemaak vallen bij het eerste testje door de mand, en architecten kennen TOGAF wel maar snappen niet waarom die handig zou kunnen zijn. En vallen terug op plaatjes in PowerPoint.

Het IT vakgebied is door en door rot. Maar dat betekent niet dat de lat lager moet. Mensen die niet voldoen moeten er domweg uit. Met minder mensen kun je vaak sneller en beter opleveren.

[Thijzer]

Het punt hier is dat closed source vaak geld verdient op kap van open source. En dat van dat geld amper tot niets terugvloeit naar open source. XZ heeft nooit de kans noch de financiële ruimte gekregen om zijn project ten gronde te onderhouden.

Misschien is de enige oplossing hier een licentie bijdrage voor onderhoud en ontwikkeling. Betalen pannekoek!

[ernstoud]

Maar hoe? Een soort Buma/Stemra zou een idee zijn. Auteurs die geld ontvangen naar gelang het aantal gebruikers of het belang. En elke gebruiker van open source stort in de pot.

Maar dan dus internationaal. Moeilijk te organiseren.

[likewise]

Het zou in mijn ogen juist slecht zijn als je de persoon wel blind vertrouwd maar de code niet.

Uiteindelijk gaat het om de code die wordt uitgevoerd.

Op die code zou een veel betere audit op moeten zitten, niet eenmalig op de (vermeende) persoon erachter.

[Hatseflats]

Nou ja, je kan het ook anders zien. In open source komt men er over het algemeen redelijk snel achter als het niet klopt en kan men het eenvoudig traceren. Closed source, da's weer andere koek.

Zelf in OpenBSD werd men er op een gegeven moment op attent gemaakt, dat er een ontwikkelaar rondliep die op de loonlijst stond van 1 van de 3 letterige Amerikaanse agentschappen. En zelfs daarvan kan je zeggen dat het in principe niet automagisch betekent dat er dan niet te goeder trouw wordt gehandeld. SElinux is er bijvoorbeeld ook uit voortgekomen. Het roept uiteraard wel vraagtekens op, helemaal in het geval als er Sinezen bij zijn betrokken. En in dit geval is het overduidelijk.

Dit is het model van open source. Niks aan veranderen.

Als er een auto ongeluk plaatsvindt, gaat men toch ook niet plotsklaps een bijna onmogelijk te halen ballotage commissie instellen? Alhoewel .

Het moet ook een werkbare situatie blijven.

[Reactie gewijzigd door Hatseflats op 22 juli 2024 19:24]

[ernstoud]

Je eerste zin gaat op als er inderdaad veel ogen naar de broncode kijken. En dan ook ogen van mensen die de complexiteit van de broncode begrijpen. En dat blijkt keer op keer een issue. Bij Heartbleed (OpenSSL) bleek ook dat er maar drie mensen min of meer actief aan werkten.

Een fout in bash zat er decennia in. En in al die jaren zullen er heel veel ogen naar "gekeken" hebben.

Dit geldt voor alle software, ook voor closed source. Ook bij closed source is er geen enkele garantie dat de testomgeving en de testers daarin alles bekijken. Is ook vaak alleen browsen en dan de build aftrappen.

Het simpelweg stellen dat er naar foss broncode meer ogen kijken is een zwak argument omdat je dat gewoon niet weet. Het aantal commits e.d. zal een indicatie geven maar ook niet meer dan dat.

En die "ogen" kunnen ook kwade bedoelingen hebben. Zo blijkt maar weer.

[Hatseflats]

Nee, dat stel ik ook niet. Het komt erop neer, dat als er een afwijking wordt gevonden, dit in open source sneller kan worden getraceerd dan in closed source.

En dat een fout er al lange tijd in zit heeft inderdaad mede te maken met de complexiteit van het stuk waarnaar je kijkt. Zelfs de knapste koppen hebben hier moeite mee.

Maar dat houdt niet automagisch in dat de onderliggende structuur om dingen te implementeren dan maar moet worden aangepast of fout is. Zulke ingrepen in het verleden hebben al geleid tot wet- en regelgeving op andere vlakken, dat je wel kunt spreken van een machtsgreep door belanghebbenden of in ieder geval een zodanig hoge drempel, dat alleen mensen met veel geld aan zo'n proces kunnen deelnemen.

En ja, mensen met kwade bedoelingen kun je met geen enkel systeem stoppen. Daar bestaat het gezegde "waar een wil is, is een weg" ook voor.

[ernstoud]

Ah, dan begreep ik je verkeerd. Bij closed source moet je maar hopen dat een bug opgelost wordt, bij open source kun je zelf zoeken en mogelijk oplossen. Absoluut een voordeel.

Wat complexiteit betreft… in mijn beginjaren (ergens in de steentijd) heb ik college gehad van Edsger Dijkstra (https://nl.wikipedia.org/wiki/Edsger_Dijkstra). Onder andere over logisch (dus met de basisbeginselen van mathematica) kunnen bewijzen dat software foutloos is. En dat was teleurstellend… hij gaf voorbeelden van 5 regels broncode waarvan het bewijs al niet meer te leveren is.

Dus fijn dat de overheid de broncode van Windows en Office mag inzien. Wat doe je dan daarmee?

Of de broncode van XZ?

[Hatseflats]

Edsger is de beste. Zo worden ze niet meer gebouwd. Ik ken hem van internet (youtube, SPF en zijn EWD's). Zo oud ben ik niet, om college van hem gehad te kunnen hebben.

Dus fijn dat de overheid de broncode van Windows en Office mag inzien. Wat doe je dan daarmee?

Of de broncode van XZ?

Ik begrijp wat je bedoelt, maar het is nog altijd beter dan het alternatief, closed source. Uiteindelijk zijn er wel mensen op overheidsniveau, die er naar kijken en het snappen, mocht er wat mis gaan. Bovendien is het ook handig om te hebben, mocht het bedrijf ineens failliet gaan of dat er zich andere omstandigheden voordoen. Kijk naar ARM en Huawei.

[Reactie gewijzigd door Hatseflats op 22 juli 2024 19:24]

[ernstoud]

Ja, escrow. Maar vergis je niet. Dat is bij foss vaak perfect, zelf builden. Maar closed source in escrow? Notarissen verdienen er wat geld mee. Maar is de set broncode compleet? Welke compiler? Build scripts? Libraries?

Edsger was te gek. Vooral zijn statements over goto, competenties van programmeurs e.d. zijn geweldig. Terechte eer heeft hij gelukkig wel gekregen.

De Nederlandse Alan Turing.

[Hatseflats]

Ha, breek mij de bek niet open over notarissen, in veel gevallen veredelde stempelmachines.

Daar heb ik ooit al eens iets over geschreven i.v.m. estate planning en ETH, nu je het over escrow en vertrouwen hebt.

[ejabberd]

Dus als ik het goed begrijp kun je in open source projecten committen met alleen een Gmail (sic!) adres. Zonder enige andere verdere identificatie.

Lekker.

Het leuke aan opensourceprojecten is dat dit nu allemaal open en bloot wordt geanalyseerd. Wees er maar zeker van dat ook bedrijven die geen lijn opensourcecode gebruiken of schrijven, blij zijn dat ze die analyse nu in detail kunnen meelezen om daar uit te leren.

Het zal niet de eerste keer zijn, maar ook niet de laatste, dat iemand van bij de start van een samenwerking al gecorrumpeerd blijkt te zijn of dat achteraf wordt door bijvoorbeeld omkoping of een al dan niet gestuurde verslaving.

[miitjohn]

Maar is dat niet hoe het altijd gegaan is? OSS wil basically zeggen: je gooit iets op github en that´s it, vanaf dan your miles may vary. Er is geen verdere controle meer anders dan dat van jezelf, de community en tegenwoordig meer en meer van tools en scanning die github aanbiedt (maar dat is iets van de laatste jaren zeg maar).

De OS community werkt voor een deel op vertrouwen. Je gebruikt een library, hoe ben je zeker dat deze clean is? Zelfs al zou de backdoor in de source code zitten. Je hebt enkel de hoop dat de community dat vroeg of laat opmerkt en het zo aan het licht komt. Voor een deel dan ook de tradeoff met closed source. Daar heb je wel volledige controle, maar dan weer als nadeel dat er maar 1 partij is die de code kritisch kan bekijken en aanpassen.

Bij het grootste deel van de OS projecten zal het wel goed gaan. De personen die een project zover krijgen dat het standaard in de gangbare linux distro´s zit en de tand des tijds heeft doorstaan van iedereen die al jaren meekijkt, is daardoor impliciet te vertrouwen.

Maar! Je ziet hier dan weer een ander nadeel van OSS: het systeem en de structuur is maar zo goed als de founders ervan hebben bedacht. Zoals hier, kan mij voorstellen dat men zelf niet gedacht had dat dit zo lang zou blijven verder lopen. Op een bepaald moment gaat het leven verder, mensen hun interesse veranderen, geen tijd meer enz. Vanaf dan gaat ofwel een fork het overnemen ofwel ga je het project overlaten. Bij dat overlaten zou je dan de personen moeten screenen. Maar dit is geen bedrijf, het zijn vrijwilligers. Dus voor hetzelfde geldt komt daar een knowledgeable hacker die zich goed kan verkopen in het team te zitten en de zaak is vertrokkken. Een mogelijkheid daarbij is dat dan een bedrijf de repo overneemt zoals bv. RedHat. Maar vroeg of laat krijg je dan ook weer organizational drag waardoor de community zich gaat roeren en waarschijnlijk toch weer een fork start.

[Reactie gewijzigd door miitjohn op 22 juli 2024 19:24]

[Patriot]

een Gmail (sic!) adres.

Als je sic gebruikt dan hoor je dat wat fout is juist over te nemen en niet te verbeteren.

[Reactie gewijzigd door Patriot op 22 juli 2024 19:24]

[ernstoud]

“ Sic wordt gebruikt om de lezer te attenderen op een bijzonderheid of fout in een citaat of …” en “… vestigt dus de nadruk op iets wat de auteur verbaast.”

En dat bedoelde ik… een maintainer die Gmail gebruikt. Dat verbaast mij.

Heb je ook nog inhoudelijk iets toe te voegen?

[Patriot]

Oh excuus, het ging om de meestgebruikte e-maildienst ter wereld dus verbazing leek me in dit geval zo onwaarschijnlijk dat ik je dat niet in de schoenen wilde schuiven. Mea culpa.

[Reactie gewijzigd door Patriot op 22 juli 2024 19:24]

[ernstoud]

Thx. Natuurlijk, Gmail is zo normaal als wat, maar mijn verwachting (verbazing) is dat een maintainer van een dergelijk belangrijk stuk software de commits doet vanaf een Gmail account.

Ik verwacht dat je dan toch - je moet immers de code goed testen - een enigszins professionele set-up hebt. Een server, cloud, mailserver etc.

Maar goed, ben een ouwe peer… wellicht is het normaal. Maar zakelijk zie ik ook liever geen Gmail…

[MneoreJ]

Tja, als het geen staatshacker was of andere persoon achter wie een organisatie schuil ging dan was het een persoon met heel veel geduld, vrije tijd en commitment om nepaccounts te maken, social engineering toe te passen op diverse mensen om een heel project over te kunnen nemen, en subtiele code te schrijven die uiteindelijk, via via, op onverwachte wijze in sshd actief komt, over een periode van minstens twee jaar.

Zulke mensen bestaan vast wel, maar laten we zeggen dat het een stuk waarschijnlijker is dat hier meer dan persoonlijke motivatie aan ten grondslag lag.

[Cergorach]

Ik weet niet of er heel veel tijd/social engineering achter zit. Het is niet voor niets dat dergelijke projecten slechts 1 of 2 maintainers hebben. Als die ene maintainer er opeens hulp bij krijgt van een ander die goed code schrijft, dan wordt diens workload gehalveerd. Zeker als je dit voor je nop doet, dan zal je maar al te snel en al te graag "Yes please!" roepen.

Ik zou me zo kunnen voorstellen dat een proof of concept al jaren is geschreven voor zo een belangrijke dependancy in relatief korte tijd, maar vervolgens over jaren is geïmplementeerd. Planned step #1, planned step #2, etc. Dus hoeveel tijd is er over al die jaren daadwerkelijk ingestoken.

Natuurlijk kan hier een organisatie achter zitten, maar het kan ook een individu zijn met een lange termijn plan, die vervolgens data/toegang zou kunnen verkopen aan derden. Deze mentaliteit is niet heel anders dan ergens jaren voor sparen voordat je het kan kopen...

[CAPSLOCK2000]

Natuurlijk kan hier een organisatie achter zitten, maar het kan ook een individu zijn met een lange termijn plan, die vervolgens data/toegang zou kunnen verkopen aan derden. Deze mentaliteit is niet heel anders dan ergens jaren voor sparen voordat je het kan kopen...

Dat kan, maar waarom zou je?

Als je deze skills hebt dan kun je een prima baan als programmeur krijgen die per direct een mooi salaris oplevert. Een backdoor als deze is miljoenen waard, maar als je moet er wel jaren onbetaald voor werken met een kleine kans op slagen. Dat voelt meer als een riskante investeringen dan als veilig sparen.

Daarom vind ik het waarschijnlijker dat er een organisatie achter zit en de boosdoener gewoon een salaris krijgt om zich jarenlang bezig te houden met infiltratie. Zorgelijk is dat het waarschijnlijk niet de enige is, als ik een geheime dienst had zou ik niet op één infiltratie gokken maar meerder pogingen tegelijk doen.

Deze exploit werkt niet stand-alone maar is een indirecte aanval via systemd op sshd onder bijzondere omstandigheden. Dat is een beetje een vreemde volgorde, het zou me niet verbazen als ze zijn begonnen met een kwetsbaarheid in ssh zoeken en uiteindelijk bij liblzma terecht zijn gekomen. Dat suggereert dat het niet gaat om een toevallige ontdekking maar iemand systematisch op zoek is naar exploits en de resources heeft om dat over meerdere projecten/codebasissen heen te exploiten.

ssh en xz zijn niet bepaalde eenvoudige pakketten, als programmeur zal je aardig wat in huis moeten hebben om zinnige bijdrages te doen op laag niveau. Dat soort mensen vind je niet op straat, die moet je opleiden en betalen, je hebt meer nodig dan een gesjeesde informatica student.

Overigens denk ik dat we er rekening mee moeten houden dat Jia Tan helemaal niet bestaat en dat er een of ander collectief achter zit. Een paar programmeurs met technische skills om te hacken en een paar mensen sociale skills om het project te infiltreren en de code op te laten nemen door de Linux-distro's.

[Reactie gewijzigd door CAPSLOCK2000 op 22 juli 2024 19:24]

[RobertMe]

als ze zijn begonnen met een kwetsbaarheid in ssh zoeken en uiteindelijk bij liblzma terecht zijn gekome

Waarschijnlijker is dat ze gezocht hebben naar een zwakke "sociale" plek.

xz is door 1 persoon ontwikkeld, het project was relatief stil / "dood" (/uitontwikkeld, een compressie algoritme blijf je niet verder ontwikkelen, daar komt eerder een compleet nieuwe van. Je gaat niet snel "features" toevoegen aan de bestaande compressie). En vervolgens is er wat druk uitgeoefend dat er een maintainer bij zou komen. Ik meen 2 onbekende personen/emailadressen die ineens wat aan het pushen waren voor een tweede maintainer aan het project. En dat rond de tijd dat deze bad actor zijn eerste contribution deed. En die emailadressen zijn online verder nergens te vinden en hebben zich ook nooit meer laten zien bij xz.
Dit lijkt dus bij uitstek een gerichte "sociale" aanval te zijn geweest om deze ene persoon / account co-maintainer van het project te maken. Wetende dat het project ook niet echt ontwikkeld wordt. Waarbij in de discussie omtrent het toevoegen van een maintainer ook nog langs kwam dat de ontwikkelaar mentale problemen heeft (zou van tevoren al bekend kunnen zijn geweest bij de aanvaller?) en ogenschijnlijk ook nog eens vaker op vakantie (/"niet bereikbaar") is.

Dit project is/was dus bij uitstek geschikt om totaal onder de radar te kunnen doen en laten wat ze willen. Terwijl er bij SSH waarschijnlijk en systemd zeker veel meer contributors zijn en er veel uitgebreidere review/test processen zijn. Als "individu" (/single account) is het bij zo'n project dus vele malen lastiger om de controle in handen te krijgen en ongezien deze backdoor te introduceren.

Waarbij het technisch vermoed ik mogelijk is/was om in elke library die door sshd gelinkt wordt deze backdoor te introduceren. Waarbij het uiteraard logischer zou zijn om dat dan te doen bij een library die altijd gebruikt wordt. Daar waar sshd dus niet naar systemd linkt (en daardoor niet naar liblzma), maar het een aantal distributies zijn die sshd patchen om een bepaalde systemd feature te gebruiken. Dus een backdoor in liblzma is vanuit de mogelijke omvang niet eens de logischte plek (maar met Debian, Ubuntu, Fedora, Red Hat heb je natuurlijk wel het overgrote deel van de Linux markt). Wat het dus ook alleen maar waarschijnlijker maakt dat xz gekozen is omdat het onder de radar kon (hoogstens 1 iemand die het werk controleert maar zelfs dan vaker "afwezig" is).

[CAPSLOCK2000]

Waarschijnlijker is dat ze gezocht hebben naar een zwakke "sociale" plek.
<knip>
Waarbij het technisch vermoed ik mogelijk is/was om in elke library die door sshd gelinkt wordt deze backdoor te introduceren.
<knip>
Wat het dus ook alleen maar waarschijnlijker maakt dat xz gekozen is omdat het onder de radar kon (hoogstens 1 iemand die het werk controleert maar zelfs dan vaker "afwezig" is).

Dat denk ik ook. Daarom maak ik me ook zorgen dat dit pas het topje van de ijsberg is en er ook nog andere projecten zijn geinfiltreerd.

Of ze begonnen zijn met een technische of sociale exploit vind ik niet zo belangrijk. Als het inderdaad professioneel is georganiseerd kunnen ze ook vele wegen tegelijk hebben bewandeld. Uiteindelijk is het gelukt om een project te vinden waarin beide (sociaal & technisch) kwetsbaar waren.

[Cergorach]

Als je deze skills hebt dan kun je een prima baan als programmeur krijgen die per direct een mooi salaris oplevert. Een backdoor als deze is miljoenen waard, maar als je moet er wel jaren onbetaald voor werken met een kleine kans op slagen. Dat voelt meer als een riskante investeringen dan als veilig sparen.

Wie zegt dat deze persoon niet al een prima baan heeft als programmeur en flink wordt betaald en dit niet meer is dan een nevenactiviteit? Deze persoon, zelfs zonder kwade bedoelingen, zal toch moeten eten en huur moeten betalen... Er zijn zat projecten waar men niet fulltime aan werkt, maar gewoon doet naast een baan.

Niet elke crimineel (in spe) is een onopgeleide schoolverlater...

[CAPSLOCK2000]

Wie zegt dat deze persoon niet al een prima baan heeft als programmeur en flink wordt betaald en dit niet meer is dan een nevenactiviteit?

Het kan, maar ik vind het niet waarschijnlijk.
Het is een grote en riskante investering die niet direct geld oplevert.
Als het allemaal al goed gaat zal je daarna nog een manier moeten vinden om geld te verdienen aan je exploit. Daarna zul je ofwel zelf bedrijven moeten gaan hacken en chanteren of je exploit verkopen aan andere criminelen.
Dat is best wel een grote gok om jaren in te investeren.

Het kan allemaal, maar ik vind het niet waarschijnlijk.

Niet elke crimineel (in spe) is een onopgeleide schoolverlater...

Dat is min of meer mijn punt, als intelligente professionele crimineel begin je hier niet aan. De risico's verhouden zich niet tot de verwachte opbrengst.

[downtime]

Dat is min of meer mijn punt, als intelligente professionele crimineel begin je hier niet aan. De risico's verhouden zich niet tot de verwachte opbrengst.

Hoewel ik zelf ook geloof dat hier een organisatie achter zit, en niet een individu, is het wel uitvoerbaar voor een individu. Er zijn natuurlijk risico's maar daar loop je pas tegenaan als je die exploit na enkele jaren wil verkopen. Tot die tijd kun je je gewoon achter een VPN en een fictieve naam verschuilen.

[RobertMe]

De benoemde risicos zitten in deze discussie in de investering. Er is veel tijd (= geld) ingestoken. One way or another moet dat dus geld opleveren, door of zelf misbruik er van te maken of door de exploit te verkopen.

Als vervolgens zoals nu de exploit gevonden en gepatcht wordt voor de (grootschalige) uitlrol is al die tijd weggegooid.
Je kunt dus niet zeggen "ik heb 50k op de bank en ga de komende jaren stoppen met werken om een Linux exploit te bouwen die ik voor 1M verkoop". Want na die jaren heb je je geld uitgegeven aan levensonderhoud en zoals nu is de return of investment $0. Dan heb je dus een lege rekening en geen inkomstenbron.

[downtime]

Maar niet iedereen hoeft betaalt te worden. Als ik een goede ontwikkelaar ben die 8 uur per dag bonafide code schrijft voor een baas en dan de avonduren in mijn "hobby" steek dan kost me dat niets.
Linus Torvalds heeft de eerste versies van Linux in zijn vrije tijd ontwikkeld. Hij had blijkbaar tijd over naast de universitaire studie die hij deed. Als hij daar tijd voor had, terwijl hij nooit had kunnen voorzien dat het ooit een cent op zou leveren, dan heeft ook wel iemand tijd om in de avonduren wat functies voor xz te ontwikkelen.

Alleen die 700 commits op andere projecten zijn wel knap. Ben benieuwd of dat ook echt goede commits waren, waar serieus tijd in is gestoken, of dat het allemaal laaghangend fruit was.

[GrooV]

Mwah daar kunnen gewoon meerdere mensen aan werken. Niet heel spannend allemaal

[ejabberd]

Het kan, maar ik vind het niet waarschijnlijk.

Dat weet ik niet. Het is best mogelijk dat iemand eerst betaald wordt om als hobby legaal te werken aan een opensourceproject waarna men die persoon steeds meer onder druk gaat zetten om veel verder te gaan. M.a.w. dezelfde werkwijze als hoe havenarbeiders vaak in de drugdwereld rollen.

[CAPSLOCK2000]

Volgens mij zijn we de draad een beetje kwijt. Ik betwist niet dat er mensen zijn die vanuit hun hobby de criminaliteit in rollen. Ik denk alleen niet dat dit specifieke geval één persoon alleen is die zit te hobbyen.
De persoon heeft geen geschiedenis van legitieme bijdrages aan open source. Hij(?) komt uit het niets en lijkt (achteraf gezien) vanaf het begin aan een plan te werken, nog voor de eerste code is opgestuurd.

Dit voelt niet als iets waar je als kleine hobbycrimineel aan begint. Te riskant en te weinig kans van slagen.
Als je de skills hebt kun je een prima legitieme baan krijgen (bv als hacker voor de overheid). Er is een reden waarom drugs door havenarbeiders wordt gesmokkeld en niet door de directeuren. Hun gewone salaris is hoog genoeg dat ze niet aan smokkel beginnen. Natuurlijk zijn er uitzonderingen, maar die zijn (per definitie) niet waarschijnlijk.

Als een slimme programmeur besluit het slechte pad op te gaan dan zijn er een hoop betere mogelijkheden om geld te verdienen, bv met ransomware & chantage of het ontwikkelen van malware voor de verkoop. Dan heb je direct geld in de hand.
Zo'n backdoor gepubliceerd krijgen is indrukwekkend werk maar het levert niet direct geld op, het zet alleen een deurtje open. Iemand zal alsnog naar binnen moeten gaan om data te stelen of zo iets. En als je alleen maar ergens wil inbreken zijn er zat doelen die je kan kraken zonder dit soort zware gereedschap.

Daarom lijkt me dit deel te zijn van een groter plan van een organisatie die niet uit is op makkelijk geld verdienen.

[ejabberd]

Je zegt eigenlijk net hetzelfde als ik hoor.

Het zou zo kunnen lopen:

Stap 1: een random iemand wordt verleid om legaal tegen betaling een centje bij te verdienen.

Stap 2: de organisatie drijft het slachtoffer geleidelijk aan in de illegaliteit.

Stap 3: de organisatie eist onder dwang dat het slachtoffer bepaalde aanpassingen doet waarbij het team van die organisatie het slachtoffer aanstuurt.

[svennd]

kleine kans op slagen

Daar ben ik zo zeker nog niet van, dat dit ondekt is, is puur geluk, en niet 1x maar meerdere keren. Ik vraag me eerder af hoeveel pakketten ook "hooks" hebben.
https://boehs.org/node/ev...now-about-the-xz-backdoor
Leest dan ook als betere triller.

Een staatshacker is perfect mogelijk, maar ook een klein team die dit ergens op de backburner heeft lopen. Kans dat het slaagt lijkt mijn inziens relatief groot, en zelfs al w/ het ontdekt deze bug zou nog jaren op legacy systemen draaien. (uiteraard niet gezien het nog niet echt released was maar bon.)

[Armada651]

Als je deze skills hebt dan kun je een prima baan als programmeur krijgen die per direct een mooi salaris oplevert.

Dat hangt er maar vanaf waar je woont, niet overal zijn dezelfde kansen tot je beschikking. En goede kans dat deze programmeur al een mooi salaris krijgt en dat dit zijn baan is.

[R4gnax]

Overigens denk ik dat we er rekening mee moeten houden dat Jia Tan helemaal niet bestaat en dat er een of ander collectief achter zit. Een paar programmeurs met technische skills om te hacken en een paar mensen sociale skills om het project te infiltreren en de code op te laten nemen door de Linux-distro's.

Dit lijkt me nou eindelijk eens een uitgelezen moment om een deep learning model toe te passen. Om over de volledige commit en comment history van deze 'persoon' heen te gaan en deze te beoordelen op stylistisch coherent taalgebruik.

De patroonherkenning in zo'n model kan, in het geval bovenstaande klopt, waarschijnlijk redelijk accuraat alles opsplitsen in verschillende cohorten aan werkelijke verschillende menselijke bijdragers. En vandaar uit kun je logisch gaan doorspeuren op wie met welke infiltratie-vectoren bezig was.

[Hans1990]

Wie er ook achter zit, ik denk dat de keuze voor xz om meerdere redenen kan worden gedaan:

- Compressie libraries zijn niet 'hot'. Het zijn libraries die op de achtergrond hun werk doen. 1 of 2 maintainers terwijl het halve internet op dit spul draait, getuige de XKCD.
- 1 of 2 maintainers maakt het ook makkelijk om prooi te vallen aan social engineering.
- Compressie is voor niet ingeleerden een soort zwarte magie. De prorgammatuur is slechts een implementatie van een algoritme die waarschijnlijk door een computer wetenschapper op papier is gezet. De kans dat jan met de pet iets nuttigs toevoegt is klein. Ik vermoed dat daardoor zo'n project nog minder aandacht krijgt..
- Compressie libraries moeten met binary streams werken. De test repository bevat daardoor een reeks aan handmatig bewerkte streams die bijvoorbeeld gecorrupt zijn. Dit is een ideale plek om malware payloads te verstoppen: met die blobs kunnen code reviews weinig mee..
IMO een andere kandidaat library voor een blob zou iets als OpenSSL kunnen zijn.. maar dat project is weer zo groot dat zoiets snel opvalt.

Misschien is deze injectiewijze een kleine geruststelling: de hoeveelheid open-source projecten waarbij te verantwoorden valt om met binary (data)blobs te werken is relatief klein. Dat iemand dus plek weet te vinden om z'n malicious code blob tussen te verstoppen is daardoor nog minder groot. Een backdoor in C schrijven zal waarschijnlijk ook wel gebeuren, maar is een stuk lastiger. Vage code zal geflagged worden of kan op elk moment herschreven worden. Bovendien kan een backdoor niet expliciet state informatie opslaan van z'n eigen mechaniek, want dat valt ook direct op.

Ik denk zelf dat het waarschijnlijker is dat er een groep professionele mensen achter zit. Wat je leest over veel scriptkids o.i.d. is dat ze bijzonder ongeduldig zijn en graag erkenning willen voor hun werk. Dit lijkt een zeer strak uitgestippeld plan.

[Reactie gewijzigd door Hans1990 op 22 juli 2024 19:24]

[MneoreJ]

Natuurlijk kan hier een organisatie achter zitten, maar het kan ook een individu zijn met een lange termijn plan, die vervolgens data/toegang zou kunnen verkopen aan derden.

Ik zou het op zich bijna mooi vinden als er een solo "entrepreneur" van deze vorm achter zat (met veel geduld en vrije tijd naast de day job, dan?), maar zelfs al was het zo (en ik heb er mijn twijfels over) dan laat dit onverlet dat het nog veel enger is om te denken dat als een individu dit kan, het een peulenschilletje is voor inlichtingendiensten en criminele groepen om veel meer van dit soort "investeringen" uit te zetten en dat hoogstwaarschijnlijk ook al gedaan wordt, en gedaan is.

[Cergorach]

Inlichtingendiensten en criminele groepen kunnen nog veel verder gaan, die kunnen hun mensen bij bedrijven naar binnen krijgen waar ze dergelijke dingen uithalen zonder dat daar de hele wereld naar de code kan of hoeft te kijken...

Stel er wordt een manager van een afdeling binnen gehengeld of omgekocht, die vervolgens personeel kan vervanger wat deze wil. Naast het salaris wat ze krijgen zouden ze prima nog een aardige smak geld van een derde partij kunnen krijgen...

Als je bij een bank gaat werken krijg je behoorlijk wat background checks, maar die krijg je weer niet als je bij software house X gaat werken...

[MneoreJ]

Allemaal waar, maar een aanval op een publieke repo als dit heeft dan wel weer het voordeel dat je helemaal niets hoeft te doen waar geldstromen vloeien of getuigen bij ontstaan, en juist omdat het gaat om code waar de hele wereld naar kan kijken (en die de hele wereld dus gebruikt) komt je op veel meer plekken dan je zou komen als je proprietary pakket X overneemt. Een private backdoor in sshd is natuurlijk iets waar niemand nee tegen zegt.

[ejabberd]

Allemaal waar, maar een aanval op een publieke repo als dit heeft dan wel weer het voordeel dat je helemaal niets hoeft te doen waar geldstromen vloeien of getuigen bij ontstaan,

Als die geldstromen en getuigen echt een probleem zijn, dan kwam er geen gram drugs het land in.

[MneoreJ]

Voor een voldoende gemotiveerde crimineel (en/of overheidsinstantie...) is weinig een onoverkomelijk probleem, maar dat wil natuurlijk niet zeggen dat onder de radar vliegen niet z'n eigen voordelen heeft.

[rob12424]

Er zit wel degelijk social engineering achter. Wat ik las uit een andere bron was er een onbekende programmeur die kwam helpen en de orginele maintainair zo onder druk zette dat deze een burn out kreeg.

Ook verschillende andere mensen die toegevoegd waren. Zijn zo opeens ontstaan. Zo lijkt het of er meerdere mensen dingen toevoegde maar blijkt het nu mogelijk maar 1 iemand te zijn.

Houd er maar rekening mee dat met AI je wel een videoconferentie kan houden om te "zien" of iemand "echt" is maar ook niet werkt.

Beste is maar ook niet waterdicht:

Kijken hou oud profielen zijn en wat er is bijgedragen en ook of dit klopt. En verder kijken dan 1 connectie.

[downtime]

Kijken hou oud profielen zijn en wat er is bijgedragen en ook of dit klopt. En verder kijken dan 1 connectie.

Ik las dat dezelfde alias over enkele jaren 700 bijdragen aan andere projecten heeft gedaan die (voor zover nu bekend) niet verdacht zijn. Het lijkt erop dat er twee teams waren, die onder dezelfde alias werkten, waarbij het ene team bonafide code voor projecten schreef om een dekmantel te verschaffen voor het tweede team waar de malware werd geschreven.

[RobertMe]

Nee, dit account heeft maar aan één project gewerkt: xz. Er is een minimaal wantal contributies geweest aan andere projecten, maar die waren puur om de exploit "under covers" te houden of te "enablen". (Bij Googles oss-fuzz bv de maintainer updaten naar zichzelf en het uitschakelen van de detectie van het gebruik van ifunc).

Die 700+ commits klopt wel. Maar dat is alleen aan xz. Dat dat mogelijk door twee teams gedaan is, o.a. door "tijdsverschil" tussen legitieme commits en kwaadaardige commits heb ik ook gelezen (dus dat alle legitieme commits bij wijze van tussen 8u en 17u zijn gedaan en alle kwaadwillende commits tussen 20u - 24u).

[Reactie gewijzigd door RobertMe op 22 juli 2024 19:24]

[ejabberd]

De ouderdom van profielen kan een indicatie zijn maar je mag je daar niet enkel op baseren. Ik ben er zeker van dat staatshackers nu al brave profielen warm houden of in staat zijn om brave profielen via omkoping of onder druk kunnen gebruiken als dat hen kan helpen om hun doelen te bereiken.

[dipje2]

Er is best wat gelinkt naar mensen die al 2 jaar geleden aantonen hoe deze persoon als maintainer kwam.
Door veel te pushen op een oude maintainer die aangaf er te weinig tijd voor te hebben.
Kan best dus een stukje social engineering zijn wat meer dan 2 jaar geleden begon.

[mrmrmr]

maar het kan ook een individu zijn met een lange termijn plan, die vervolgens data/toegang zou kunnen verkopen aan derden.

Dat is onwaarschijnlijk omdat de kans op ontdekking eenmaal wijdverbreid in het wild zeer groot is. Dit zal een korte termijn effect hebben gehad en je zult toegang tot interessante targets niet tijdig hebben kunnen verkopen. Dat rechtvaardigd niet een investering van 3 jaar.

Ik vermoed dat dit een intimiderende demonstratie is van een bepaalde 'club': "jullie systemen zijn niet veilig voor ons". Als dat zo is, heeft die club er belang bij dat het niet al te moeilijk te achterhalen is wie er achter zit. De usual suspects zijn schurkenstaten.

[sdziscool]

Mwah de persoon had verscheidene sock puppet accounts ingezet om bvb de originele bijhouden de stok te doen doorgeven, en ook accounts gemaakt om distros te vragen of ze aub zsm naar de laatste release van XZ konden upgraden etc. etc.

Dat is een fulltime baan, kan natuurlijk een werkeloze hacker zijn (en zo ja dan zou het zeker de moeite waard zijn na een jaar of 2, man/vrouw had waarschijnlijk in no time zichzelf multimiljonair kunnen maken als het in ook maar een distro was gekomen, waar het niet ver van af zat) maar zeker niet iemand die dit voor de lol in zijn vrije tijd aan het doen is naar mijn idee.

[Armada651]

Zulke mensen bestaan vast wel, maar laten we zeggen dat het een stuk waarschijnlijker is dat hier meer dan persoonlijke motivatie aan ten grondslag lag.

Als het Jia Tan gelukt was om deze backdoor stil te houden, en dat was zo te zien bijna gelukt, dan was de private key om gebruik te maken van deze backdoor miljoenen waard. Het kan best zijn dat Jia Tan op eigen houtje werkte met de intentie om de backdoor te verkopen mocht het hem gelukt zijn.

[MneoreJ]

Ja, de "kwade genius" theorie is niet helemaal uitgesloten, maar naar mijn mening wel minder waarschijnlijk. De mensen die slim genoeg zijn om zoiets van A tot Z te plannen en vervolgens ook uit te voeren (en dan niet alleen de technische kant maar ook de sociale) houden zich doorgaans bezig met legale activiteiten die ook gewoon goed verdienen (zoals de PostgreSQL dev die dit toevallig ontdekte ) Nee, dat is uiteraard geen natuurwet, maar acties als deze zijn wel makkelijker uit te voeren, makkelijker te gelde te maken en minder risicovol wanneer ze door een organisatie ondernomen worden dan wanneer een individu dat doet.

Enfin, het blijft onderaan de streep natuurlijk pure speculatie tenzij "Jia Tan" ooit omwille van de street cred zegt "ik was het, ik werkte in mijn eentje, hier is de private key en al het bewijs dat ik alleen was". Dat zou een fantastische Netflix special opleveren, maar ik ga er niet van uit.

[Reactie gewijzigd door MneoreJ op 22 juli 2024 19:24]

[HollowGamer]

Tevens was de eigenaar van het xz project kwetsbaar. Wat we nu weten, zat hij met mentale problemen, en zag hij Jia Tan als een waardige vervanger/mede-maintainer. Dan ben je zelf al meer kwetsbaar, en daar lijken ze goed gebruik van hebben gemaakt.

Ik weet zelf hoe het is om mentale problemen te hebben (ook genoeg andere), dus hopelijk is hij onschuldig in dit, maar kan hij zichzelf ook sterk houden. Het lijkt me ontzettend moeilijk als dit allemaal op je afkomt en je enkel je best wilde doen. Nu mag je alles opruimen of eigenlijk is je project nu als onveilig verklaard.

Hopelijk checkt dus iemand ook hem, liefst ook fysiek.

[ernstoud]

Ik denk een misvatting. Denk eens aan 9/11… ook daar jaren van voorbereiding.

[MneoreJ]

Je punt ontgaat me. Die aanslag was sowieso aantoonbaar niet een individuele actie, en uiteraard kun je niet even in een opwelling een aanslag van een dergelijke omvang plegen.

Bij deze actie zou je nog kunnen denken dat een enkeling met veel geduld en vage motieven het in z'n eentje gerooid heeft, al lijkt dat niet waarschijnlijk.

[ernstoud]

Ik reageerde op de opmerking “Zulke mensen bestaan vast wel, maar laten we zeggen dat het een stuk waarschijnlijker is dat hier meer dan persoonlijke motivatie aan ten grondslag lag.”

Dat lijkt (?) te suggereren dat je minder verwacht dat er organisaties zijn met een jaren planning van zoiets als deze backdoor. Terwijl de geschiedenis laat zien dat er juist veel actoren zijn met dit geduld. Zoals 9/11, stuxnet, infiltratie in de overheid door kwaadwillenden e.d.

Ik heb voor kritieke processen door de overheid verplichte risico analyses gedaan waarin dergelijke dreigingen gelukkig zeer zeker meegenomen worden. Bij de organisatie waar ik werkte zagen we het realtime… personen die via LinkedIn probeerden te infiltreren en daar gerust en jaar de tijd voor namen.

[MneoreJ]

Nee, dat was precies het tegenovergestelde van wat ik bedoelde. Ik acht het bijna 100% zeker dat hier een organisatie achter zat en geen excentriek individu, dat bedoelde ik met "meer dan persoonlijke motivatie". Wat voor organisatie en wat ze uiteindelijk op het oog hadden komen we waarschijnlijk niet te weten, anders dan door toeval, want met een RCE in sshd kun je natuurlijk alle kanten op.

[Reactie gewijzigd door MneoreJ op 22 juli 2024 19:24]

[ernstoud]

Ah, excuus. Dan was er sprake van crommunicatie (dixit Wim de Bie).

[Rob Coops]

Ja dat soort mensen bestaan, kijk voor de grap eens naar verhalen zo als dat van de Guiding Hand Social club in Eve Online een computer spelletje waar de persoon in kwestie 10 maanden lang vele uren in stak om het vertrouwen te winnen van een groep en met name de leider van die groep om vervolgens de leider in PvP te verslaan en zo'n $16.5k aan in game items van de groep te stelen. En dat alles om dat iemand hem in gehuurd had om de leider van die groep te verslaan.

Als er mensen zijn die zo ver gaan in een computer spelletje dan zijn er zeker mensen die zo ver gaan in een poging de tool die toegang tot vrijwel alle belangrijke systemen op deze planeet geeft te comprimeren.

De kans dat dit een persoon was is relatief klein simpel weg omdat als dit gelukt zou zijn de aanvallen vrij snel uitgevoerd hadden moeten worden op zeer veel doelen omdat de kans dat de backdoor gevonden zou worden door verdachte activiteit op in ieder geval een van de netwerken die men zou aanvallen vrij groot is. Als die alleen bedoeld zou zijn voor een bepaalde organisatie dan had je de code aan kunnen passen om alleen op bepaalde systemen met specifieke IP's actief te zijn bijvoorbeeld waardoor de kans op ontdekking heel erg veel kleiner zou zijn geweest. Om deze reden gok ik op een grootschalige aanval en dus een groep die de mogelijkheid heeft zo'n grote aanval uit te voeren in een zeer korte tijd.

Dit toont al weer aan waarom open source projecten echt niet zo veel veiliger zijn dan closed source projecten. Bij de eerste kijkt vrijwel niemand naar de code tenzij ze tegen een probleem aan lopen en bij de tweede kijkt helemaal niemand buiten het bedrijf naar de code maar is er bij de maintainer en de organisatie waar deze voor werkt een zekere mate van persoonlijk belang om probleem loze code te leveren dan wel gevonden problemen zo goed mogelijk op te lossen binnen een redelijke tijd.
In beide gevallen is er anders dan een theoretische mogelijkheid om de code te controleren eigenlijk geen verschil. Ik zeg met opzet theoretische mogelijkheid omdat zelfs mensen die de moeite nemen de code te bekijken in de meeste gevallen niet voldoende kennis van het probleem domein en de programmeertaal hebben om de code echt volledige te doorgronden. Om die reden is het in theorie mogelijk om de code te bekijken en dit soort problemen te ontdekken maar in werkelijkheid is dat maar voor een zeer beperkt aantal mensen weg gelegd en zelfs als mensen de nodige kennis hebben is de kans dat ze er ook de tijd en de wil voor hebben heel erg klein. Om die reden is closed source echt niet zo veel slechter dan open source.

[Frame164]

Oftewel: als je echt de voordelen van open source wilt hebben ontkom je er niet aan om serieuze, gecoördineerde codereviewteams in het leven te roepen. Het past weliswaar niet helemaal bij de filosofie achter open source naar het vrijheid blijheid is te gevaarlijk.

[CAPSLOCK2000]

Oftewel: als je echt de voordelen van open source wilt hebben ontkom je er niet aan om serieuze, gecoördineerde codereviewteams in het leven te roepen. Het past weliswaar niet helemaal bij de filosofie achter open source naar het vrijheid blijheid is te gevaarlijk.

Hoezo past dat niet?

Ik vind het juist beter bij open source passen omdat je als klant/gebruiker mee kan kijken en zien dat het proces gevolgd wordt. Bij bedrijven moet je maar geloven dat ze achter gesloten deuren doen wat ze aan de buitenkant beloven. De meeste bedrijven zullen toch maar een paar mensen hebben die programmeren en codereviews doen. Als je twee personeelsleden hebt die samenwerken is zo'n code review eenvoudig te omzeilen, de klant zal het nooit kunnen ontdekken.

[downtime]

Ik vind het juist beter bij open source passen omdat je als klant/gebruiker mee kan kijken en zien dat het proces gevolgd wordt. Bij bedrijven moet je maar geloven dat ze achter gesloten deuren doen wat ze aan de buitenkant beloven. De meeste bedrijven zullen toch maar een paar mensen hebben die programmeren en codereviews doen. Als je twee personeelsleden hebt die samenwerken is zo'n code review eenvoudig te omzeilen, de klant zal het nooit kunnen ontdekken.

In dit geval was de werkwijze zo gerafineerd dat een simpele code review het waarschijnlijk ook niet had gevonden. In een code review ga je er meestal niet vanuit dat degene die de code schrijft een kwaadwillende is die een backdoor in jouw product wil implementeren. Ik vermoed dat alleen echte pair programming, waarbij de ontwikkelaars letterlijk naast elkaar zitten en elke punt en komma aan elkaar uitleggen, dit echt kan voorkomen.

[RobertMe]

Nja, er zijn wel een aantal commis geweest die, zeker achteraf gezien, nogal vaag omschreven zijn.

Vooral de tweede versie van die blob. De eerste versie leidt dus incidenteel tot crashes (in 5.6.0), waardoor er een nieuwe versie nodig is. Die wordt vervolgens gecommit als zijnde "het vorige bestand was niet reproduceerbaar. Deze is gegenereerd met een seed en daardoor wel reproduceerbaar". Dan zou het dus logisch zijn als op zijn minst beschreven is wat die seed dan is en hoe die seed gebruikt is om het bestand te genereren. Iets dat bij een review gevraagd zou kunnen/moeten worden.

Of de sneaky change om de landlock sandbox te omzeilen. Hiervoor wordt/werd feature detectie gebruikt. Bestaat de `linux/landlock.h` header file is de feature beschikbaar en wordt deze gebruikt. Vervolgens heeft deze bad actor deze detectie om zeep geholpen onder de noemer "detectie werkt niet, soms is de header aanwezig maar faalt het compileren". Daarbij is vervolgens de detectie aangepast om een aantal regels code te compileren, lukt dat is de feature beschikbaar. Echter zit in dat stukje code een "onschuldig" foutje, een punt. Die leidt tot een syntax error waardoor de featre altijd "afwezig" is. En ook hierbij geldt dat de informatie van de commit zeer summier is. Er wordt totaal niet beschreven onder welke omstandigheden / bij welk OS/distro het compileren mislukt. En ook dat is iets dat bij een review uitgevraagd zou moeten worden. Of nog beter, de toegepaste methode om zelf een volledig stuk C code te schrijven om te testen of een feature aanwezig is is low level. Terwijl er ook high level manieren (schijnen te) zijn om te controleren of bv dus bepaalde methodes aanwezig zijn/gebruikt kunnen worden. Waarbij de build tools dus "de code voor je schijft". En dat had dus de aanbevolen manier moeten zijn om dit probleem op te lossen, als het probleem al bestond. Omdat de build tools dus geen ongeldige code zullen genereren met een onschuldig foutje er in. En ook zoiets had met een review er uit gepikt kunnen/moeten worden.

[Reactie gewijzigd door RobertMe op 22 juli 2024 19:24]

[MneoreJ]

Het past weliswaar niet helemaal bij de filosofie achter open source

Die dingen zijn onafhankelijk van elkaar. Open source betekent gewoon precies dat: de source is vrijelijk voor iedereen beschikbaar om ermee te doen wat je wil (en de copyleft mensen voegen daar nog aan toe: en datzelfde moet gelden voor aanpassingen die je doet).

Het feit dat het open source is betekent niet dat alle wijzigingen klakkeloos doorgevoerd zouden moeten worden, sterker nog dan blijft er van de meeste repositories niet veel meer over. Dat een zekere mate van coördinatie en controle nodig is was al vanaf het allereerste uur duidelijk. Dat dit er nog wel eens bij in wil schieten is een tweede, maar heeft minder te maken met de filosofie van open source dan met de praktische grenzen aan menselijk gedrag.

[Reactie gewijzigd door MneoreJ op 22 juli 2024 19:24]

[cariolive23]

Wat je dus eigenlijk zegt, is dat een software "team" wat bestaat uit één of twee mensen, veel te klein is. Software die door deze mensen wordt gemaakt, kun je niet vertrouwen.

Welke licentie bij deze software hoort, is totaal irrelevant.

Vraag is dan welke eisen je stelt aan een software productie proces? Op basis van deze eisen en de antwoorden daar op, kun je bepalen of jij deze software wel of niet wilt gebruiken.

[Verwijderd]

Het lijkt mij niet verstandig om de xz binary te runnen om de versie te checken, wat als er nog meer malware in schuil gaat? Check de versie gewoon via je package manager.

[MneoreJ]

"Goed" nieuws: xz vanaf de command line draaien verhoogt het risico nauwelijks, want de kwetsbaarheden zitten in ieder geval in liblzma, en daar zijn meer dingen van afhankelijk, onder andere systemd. Ergo, als er nog meer malware in zit die niet alleen sshd target ben je daar hoogstwaarschijnlijk al gewoon het slachtoffer van. Eh, vrolijk Pasen?

[The Zep Man]

En bij gebrek aan een package manager kan je altijd nog de xz-binary door strings halen. Daarmee haal je het versienummer er ook uit.

[svennd]

of je killt je sshd ?

[blorf]

Dat lijkt me gewoon argc/argv CLI parameter afhandeling. Als iemand daar een call in heeft verstopt ziet iedereem die de code inziet en main() opzoekt dat meteen.

[Toine1]

Nu de volgende vragen: wie is Jia Tan, waarschijnlijk is dit een pseudonym en waar komt hij vandaan?

[RobertMe]

Dit is zeer zeker een pseudoniem. Tenzij iemand met zo'n kennis en kunde verder of 0,0 online presence heeft (zou nogal gek zijn, als je online overal anoniem handelt ga je niet een backdoor inbouwen onder eigen naam). Of het is die security researcher (IIRC) in Californië maar die zit dan te committen met een +8 tijdzone terwijl Californië -8 is, en dan ook nog eens "overdag" in +8 (wat dus altijd 's nachts in -8 zou zijn).
En daarnaast zou het nogal raar zijn om als het die security researcher is om dit onder eigen naam te doen.

Blijft alleen de vraag of het een willekeurig gekozen naam is of een vorm van "identiteitsdiefstal" (als de originele developer de naam opgezocht zou hebben zou het zoekresultaat van deze security researcher vertrouwen hebben kunnen geven?)

[JanVQ]

Alles wat er over hem al bekend is staat op de pagina van Evan Boehs (zie de link in het artikel).

[SuperDre]

Doordat men nog steeds niet weet wat er aan de hand is, en of het een echte bewuste backdoor is, blijft het allemaal gissen. Kan ook gewoin een oprechte vergissing zijn.

[RobertMe]

Dit is per definitie geen oprechte vergissing. De enige (kleine?) mogelijkheid is dat het account van deze persoon is overgenomen en iemand anders dit gedaan heeft.
Maar dat er een exploit in 5.6.x zit blijkt onomstotelijk uit de "code". Immers is er geen enkele reden waarom liblzma de public/private key validatie functie van SSH / SSL zou moeten overschrijven. En het feit dat "iemand" onder dezelfde naam actief met de Fedora developers heeft samengewerkt om de incidentele crashes / Valgrind issues op te lossen en er daarna ineens een nieuwe blob van de exploit (vermomd als test bestand) in xz opduikt duidt daar ook wel op.

[sfranken]

Ik link/quote @HollowGamer hier even: HollowGamer in '5 vragen over de malware in compressietool xz: was dit een achterdeur?'

[ernstoud]

Die cartoon van xkcd slaat de spijker op de kop. De laatste jaren is wel duidelijk (bash, heartbleed etc.) hoe afhankelijk de veiligheid rond open source is van kritische utilities onderhouden door een enkeling. Hoe zou dat opgelost kunnen worden? Geen idee. Maar het moet opgepakt worden.

Bij belangrijke zaken in het leven moet je je identificeren. Maar ontwikkel je kritische open software kan dat zonder dat iemand weet wie je bent.

Meest verontrustend vind ik overigens dat XZ ook gebruikt wordt om het Linux image en rootfs te comprimeren. Als deze backdoor niet ontdekt was dan zou met enige tijd daarin op veel embedded devices bijvoorbeeld deze backdoor zitten. Eng.

Het is toch een gotspe dat sshd, ongelofelijk belangrijk voor de veiligheid, gebruikt maakt van een library onderhouden wordt door een developer die in 2022 aangaf mentale problemen te hebben en een andere developer waar niemand nu van weet wie het is.

[RobertMe]

Het is toch een gotspe dat sshd, ongelofelijk belangrijk voor de veiligheid, gebruikt maakt van een library onderhouden wordt door een developer die in 2022 aangaf mentale problemen te hebben en een andere developer waar niemand nu van weet wie het is.

Doet sshd ook niet. Daarvoor moet je wijzen naar bepaalde distributies die zelf zitten te patchen. Het zijn deze distributies die sshd aanpassen om gebruik te maken van een systemd feature. En via die route wandelt de liblzma library naar binnen (systemd heeft een dependency op liblzma).

Edit:

Meest verontrustend vind ik overigens dat XZ ook gebruikt wordt om het Linux image en rootfs te comprimeren. Als deze backdoor niet ontdekt was dan zou met enige tijd daarin op veel embedded devices bijvoorbeeld deze backdoor zitten. Eng.

De Linux kernel gebruikt xz-embedded. Dat wordt wel door dezelfde personen onderhouden, maar is niet hetzelfde project.
En de verdere impact daarvan durf ik niet te beoordelen. Het kan zijn dat de Linux kernel eerder de code overneemt en zelf aan een uitgebreide review onderwerpt, i.p.v. 1 op 1 als dependency binnenhaalt en alleen maar naar een changelog kijkt (bv).

Wat mogelijk verwijtbaarder is is dat XZ gemonitord werd door het Google oss fuzz project, een project om fuzzers (om bugs te vinden) uit te voeren op open source projecten. Deze fuzzer detecteert, o.a., het gebruik van glibcs "ifunc", een mechanisme om function calls te monkey patchen, en deze bad actor heeft doodleuk een PR bij oss fuzz kunnen doen om deze controle uit te schakelen. Waarbij ifunc gebruikt wordt om kritische validatie functies van SSH / SSL te overschrijven en zo de backdoor in te bouwen. Waarbij er echter ook op één plek in de code een "zogenaamd" valide use case voor het gebruik van ifunc is toegevoegd. Googles "oss fuzz" zou in principe dus dwars hebben gelegen om de backdoor in te bouwen, omdat die triggerde op het gebruik van deze "akelige" functie/mogelijkheid. Waarbij als workaround het gebruik van ifunc legitiem in de code is opgenomen en dit gebruikt is om deze controle bij oss-fuzz uit te schakelen.
Waarbij deze wijziging om ifunc te gebruiken is voorgesteld onder de naam "Hans Jansen", maar de wijziging uiteindelijk door de originele XZ ontwikkelaar is aangepast en gecommit ("Bijgedragen door Hans Jansen"). En die hele naam "Hans Jansen" duikt maar op één andere plek online op. Die heeft bij Debian lopen pushen om XZ 5.6 in de repo te krijgen.

[Reactie gewijzigd door RobertMe op 22 juli 2024 19:24]

[ernstoud]

Ja, IFUNC. wellicht was initd toch zo slecht nog niet, systemd is te complex geworden.

Je hebt een punt, blijft dus staan dat er distro’s zijn (lees: developers) die een core component zoal sshd aanpassen waardoor de afhankelijkheid van een externe library zoals liblzma ontstaat. Onderhouden door 1 goedbedoelende (hoop ik) hobbyist en 1 minder goedbedoelende.

Repeat van log4j…

[MneoreJ]

De functionaliteit die hier bedoeld wordt is "stuur een notificatie naar systemd dat de boel draait". Dit is 5 regels C code als je het los implementeert (regeltje plain text over een Unix socket) waar geen compressie bij komt kijken, maar men koos ervoor om een hele lib binnen te hengelen met een afhankelijkheid voor ongerelateerde functionaliteit. Dit kun je systemd moeilijk aanrekenen buiten het feit dat systemd bestaat. Nota bene, libpam heeft ook een afhankelijkheid van liblzma en ook die is in te stellen als (optionele) afhankelijkheid van sshd. Voorbij dat heb je ook nog selinux, binutils, grub... die allemaal liblzma laden.

Ik ben overigens geen partij in de "systemd is evil/systemd is geweldig" kampen, maar in dit geval is het geen argument dat het op de een of andere manier de schuld is van systemd.

[Reactie gewijzigd door MneoreJ op 22 juli 2024 19:24]

[ernstoud]

Goed punt. Juist een backdoor als deze laat zien dat beheersing over de hele keten bij open sources een issue is. Maintainers van XZ, GitHub commit verificatie, een functie van systemd, developers bij distro’s, sshd, etc…. Wie heeft nog inzicht?

Toch wel iets waar closed source mogelijkerwijs een voordeel heeft… daar is toch sprake van centraal geleide planning, project management e.d. (met ook weer alle nadelen van dien).

Maar goed, als ik op YT de video’s van Dave Plummer (dave’s garage), over SW development bij Microsoft een tiental jaren geleden, bekijk dan was dat toen ook behoorlijk amateuristisch en persoonsgebonden lijkt het.

[MneoreJ]

Het grote nadeel van closed source is dan weer dat het... closed is. Bij open source kan het fout gaan, maar bij closed source weet je het gewoon niet. Als daar de NSA over de vloer komt en iemand een paar miljoen biedt om een backdoor erin te gooien, of een paar jaar cachot als ze dreigen dit genereuze aanbod openbaar te maken, dan doet men dat gewoon netjes, en centraal aangestuurd waarschijnlijk ook nog.

Bij open source is de uitdaging vooral praktisch: hoe zorgen we er nu voor dat de keten ook echt goed gereviewed wordt? Bij closed source kom je niet verder dan "laten we dit bedrijf maar vertrouwen dan". Beiden kunnen fout gaan, maar bij open source is het dan in ieder geval openbaar wat er dan mis gaat en hoe het verbeterd wordt. Bij bedrijven is het gewoon opdoeken en op zoek naar de volgende, als het al uitkomt.

[ernstoud]

Zeker. De voor- en nadelen van open versus closed zijn voldoende uitgekauwd. Wel is je argument voor closed source “vertrouwen” wel wat verzwakt. Een groot aantal closed source developers staan code review, audits e.d. gewoon toe.

(Maar wat kun je doen als je de miljoenen regels Windows source voor je hebt liggen .)

[GrooV]

Errr juist bij closed source heb je hier 0,0 transparantie op.

Dit heeft ook niks met open source te maken, hier is het misgegaan dat de tarballs niet het zelfde bevatten als de source. Iets wat bij close sourced software sowieso nooit te controleren is.

Het enige wat hier echt mis gegaan is dat er een contributor te snel en te makkelijk releases kon signeren waar heel wat andere software gebruik van maakt. Dit had echter ook bij een klein bedrijf kunnen gebeuren met een malafide medewerker.

[Reactie gewijzigd door GrooV op 22 juli 2024 19:24]

[dmantione]

Ook gesloten software gebruikt openbronbibliotheken. Compressie is een typisch voorbeeld, libgzip, libbzip2, liblz4 en libzma zijn hele populaire bibliotheken die in veel gesloten software gebruikt worden. Een gesloten ontwikkelaar zal dan ook een tarballetje downloaden en compileren en zijn er in tegenstelling bij open software niet de vele ogen om te toetsen.

Het is niet heel mooi hoe ver deze hack heeft kunnen komen, maar de vele ogen hebben het toch gezien. In een later stadium dan waar ik comfortabel mee ben, maar wel op tijd om grote schade te voorkomen.

[cariolive23]

Juist een backdoor als deze laat zien dat beheersing over de hele keten bij open sources een issue is.

Het zal vast aan mij liggen, maar ik zie niet hoe het vrij beschikbaar zijn van de code, heeft bijgedragen aan het lek.

Toch wel iets waar closed source mogelijkerwijs een voordeel heeft… daar is toch sprake van centraal geleide planning, project management e.d. (met ook weer alle nadelen van dien).

Stel dat xz als bedrijf was geproduceerd en closed source was uitgegeven. Dan had je precies één programmeur gehad die hieraan had gewerkt. Komt er vervolgens iemand aankloppen, die voor een appel en een ei als medewerker zijn bijdrages wil gaan leveren. En die doet dan exact hetzelfde als wat er nu is gebeurd. Met als enige verschil dat de broncode niet vrij beschikbaar is.

Waar zijn dan volgens jou de "centraal geleide planning" of "project management" ? Ik zie ze niet.

Iemand had overigens voor flink wat geld dit bedrijfje kunnen overkopen, om zelf álles te beheersen.

Toch zou het lek dan nog steeds zijn gevonden, want een open source PostgreSQL developer, in dienst van Microsoft, heeft het afwijkende gedrag van de tool weten te vinden. Dankzij open source is het lek vervolgens wel sneller gevonden.

Juist voor kleine projecten zoals xz, of bedrijven van die omvang, zou de source inzichtelijk moeten zijn voor de klanten/gebruikers. Dat maakt het vinden van lekken iets eenvoudiger.

Of je dat doet door de code open source te maken of via escrow, dat is een andere discussie.

[ernstoud]

Fair point. Ik zei ook “mogelijkerwijs”. Ook closed source kan kwetsbaarheden bevatten. Notoir was bijvoorbeeld de bug in iOS waarbij de hele certificate check bypassed werd.

Maar ik blijf er bij dat sturing, hiërarchie, controle, project management kwaliteits bevorderende tools zijn. En dan nog ontploft een Space Shuttle. Maar hoeveel van dat soort issues zijn voorkomen?

[Reactie gewijzigd door ernstoud op 22 juli 2024 19:24]

[cariolive23]

Maar ik blijf er bij dat sturing, hiërarchie, controle, project management kwaliteits bevorderende tools zijn. En dan nog ontploft een Space Shuttle. Maar hoeveel van dat soort issues zijn voorkomen?

Wat je dus eigenlijk signaleert, is dat hele kleine bedrijven/projecten een risico zijn vanwege het ontbreken van controle etc. En dat grote projecten/bedrijven een risico zijn vanwege de enterprise doelen die groter en belangrijker zijn dan jouw bijdrage. In jouw voorbeeld het doel om de Space shuttle te lanceren.

[ernstoud]

Eigenlijk wel ja. De Space Shuttle was maar een voorbeeld, maar te grote teams is ook weer niet goed. Ook een regel in Agile werken… kleine teams.

[RobertMe]

Ja, IFUNC. wellicht was initd toch zo slecht nog niet, systemd is te complex geworden.

ifunc is een glibc mogelijkheid en heeft niks te maken met waarom systemd gebruikt wordt. De systemd dependency is er v.w.b. wat ik gelezen hebben omwille van iets met "notify", dus de reactie van @MneoreJ dat dat is om systemd te laten weten dat de service gestart is klinkt heel aannemelijk (en vast ook dat het zelf te doen is in een paar regels code die je net zo makkelijk zelf schrijft).

[ernstoud]

Eens. Uit de FAQ: “ This is not the fault of systemd, this is more unfortunate.”

Gepatchte sshd die dan systemd-notify kan gebruiken waardoor uiteindelijk liblzma mee komt…

Die jiat75 is niet dom…

[HollowGamer]

https://git.tukaani.org/?...f4f1d324616a0137a5001c14c

Tja, als dit geen actie is voor een backdoor, dan weet ik het ook niet meer.
Hij schakelde de hele sandbox check dus bewust uit. Maar er zijn nog meer vraagstukken en mogelijke lekken. Ben erg benieuwd of andere libs nu ook gaan checken, heb zo'n gevoel dat het niet alleen bij xz is gebleven.

Het vermoeden is dat er een land achter zit, zoals destijds met Stuxnet.
Ik ga geen land aanwijzen, want dan krijg je weer de hele discussie welk land 'beter is'.

[RobertMe]

Tja, als dit geen actie is voor een backdoor, dan weet ik het ook niet meer.

Dan weet je het blijkbaar niet
Een punt kan een oprechte fout zijn. Als er nu een non-breaking space ergens stond of bv andere unicode tekens gebruikt waren (in het cyrillisch schrift is er blijkbaar ook een teken dat exact op een c lijkt bv) dan kon je zeggen dat het doelbewust was, maar een punt valt te verdedigen als een oprechte fout.

Daarnaast zit deze fout alleen in de CMake build config. Terwijl exact dezelfde aanpassing is gedaan in de autotools build config, en daar ontbreekt die punt.

Uiteraard is het op basis van wat we nu weten met 99% een bewuste actie. Maar als dit goed gereviewd was en er op gewezen was dan was een "oepsie, typo" geen enkele reden tot zorgen geweest (als het een non-breaking space of unicode teken was dat exact lijkt op... dan was dat uiteraard wel uiterst verdacht).

[HollowGamer]

De punt betekend dat het bestand niet wordt gecompiled.
Het is echt een bewuste actie, het zorgt ervoor dat het bestand niet kan worden ingeladen.

CMake was volgens mij ook de bedoeling. Naar mijn weten en kennis (vrij karig) was het vooral gericht op RPM en Debian distro's.

[Reactie gewijzigd door HollowGamer op 22 juli 2024 19:24]

[RobertMe]

Wat de gevolgen zijn hoef je me niet uit te leggen. Je kunt alleen niet stellig zijn in dat het bewust is. Een typo is zo gemaakt. En deze fout zie je (er staat een punt...). Als het echt onzichtbaar moest dan was wel een non-breaking space gebruikt, of zo'n op een c gelijkend teken uit het cyrillisch schrift. Dat zie je niet. En zou daadwerkelijk alleen opvallen doordat de cmake output aangeeft dat de feature flag niet enabled is en/of door het bestand te openen in een IDE die "verwarrende" tekens (zoals een nbsp, of unicode teken, of uberhaupt alles dat niet in ASCII valt) highlight. En een IDE zou uiteraard ook al een fout moeten aangeven op die punt.

En los daarvan, is dit de commit waarin die wijziging is gedaan: https://git.tukaani.org/?...1307644efdb58db2c422d9ba7 . Waarbij in de CMakeLists.txt dat stukje C code staat, met die punt. Maar in de configure.ac van autotools staat precies hetzelfde stukje C code, alleen zonder die punt. Dus áls het bewust is dan zou dat alleen zijn als cmake als build tool gebruikt wordt. Terwijl autotools de aanbevolen / defacto standaard manier is om xz te compileren. Én het aftrappen van de exploit tijdens de build ook nog eens in een .m4 file zit, behorende tot make, onderdeel van autotools (maar mogelijk ook in gebruik door cmake?). Dus het kan zijn dat de exploit waar het om draait alleen aanwezig is in een build gemaakt met autotools, en dat daarin landlock sandboxing prima enabled is, terwijl bij de cmake build landlock altijd disabled is (door deze punt) terwijl in die build de hele exploit niet zit.

Edit:
Dit is hoe Debian build: https://salsa.debian.org/...bian/rules?ref_type=heads
Ik zie hier meermaals "auto_configure" (behorende tot de ./autogen => ./configure => make workflow?) en 0x iets m.b.t. cmake of de capitalized flags zoals cmake vaak heeft. Ik denk dus dat Debian in ieder geval niet cmake gebrukktvoor het builden.

[Reactie gewijzigd door RobertMe op 22 juli 2024 19:24]

[downtime]

Unicode tekens gebruiken in de hoop dat het niet opvalt lijkt me niet zo slim. VS Code heeft een Unicode Highlight feature en is 1 van de meest populaire editors. Ik weet niet of die Unicode Highlight in VS Code standaard aanstaat of dat ik die zelf aan heb gezet (want ideaal als je vaak code van het internet plukt) maar bij mij zouden dat soort ongewone tekens er meteen uitspatten op het scherm.

[sfranken]

Toen dit bekend werd was het even spannend, maar inmiddels is bij Fedora 40, 41 en Rawhide een update uitgebracht (of eigelijk downgrade) van xz 5.6.x naar 5.4.x, de laatste schone versie. Het is dus aan te raden je systeemupdates te doen op Fedora.

Zover ik weet zijn andere grote distros ook bezig. Bij mijn Gentoo machines is het in ieder geval ook al zover dat xz van 5.6.x naar 5.4.x ging :-)

[RobertMe]

5.4.x is niet per definitie een schone versie. Deze bad actor heeft al 2 jaar contributions gedaan en of allemaal die code legit is is nog onbekend. Het kan dus best dat in die zogenaamd "schone" 5.4.x versies nog steeds een exploit zit, alleen dus niet deze.
Als je echt veilig wilt zijn moet je terug naar de 5.2 serie, en dan uiteraard een release tarbal die gesigned is door de originele ontwikkelaar.

[sfranken]

Hoe meer ik hier over doorlees, hoe meer ik me afvraag of er nog meer is wat "dirty" is, gezien deze ontwikkelaar zijn/haar handjes in meer spreekwoordelijke taarten had.