NCSC: hoge kans op misbruik en schade door backdoor in XZ-tool
De kans op misbruik van de backdoor die in datacompressietool XZ is aangetroffen en de schade die dit kan aanrichten is 'hoog', zo waarschuwt het Nationaal Cyber Security Centrum (NCSC) in een advisory. Gisteren werd bekend dat in versie 5.6.0 en 5.6.1 van XZ Utils malafide code is aangetroffen. "Een kwaadwillende kan de kwetsbaarheid misbruiken om authenticatie te omzeilen en lijkt gebruikt te worden om SSH te compromitteren", aldus het NCSC.
XZ is software voor het comprimeren en decomprimeren van bestanden en is in de meeste Linux-distributies aanwezig. Via de gevonden backdoor zou een aanvaller toegang tot besmette systemen kunnen krijgen. "De kans en schade van deze kwetsbaarheid beoordelen wij als High/High. Wij adviseren u ons beveiligingsadvies op te volgen", zo laat het NCSC op X weten. Als oplossing wordt gewezen naar het advies dat verschillende Linux-distributies als gaven, namelijk het downgraden naar een oudere versie van XZ die niet gecomprimeerd is.
Red Hat stelt dat de backdoor aanwezig is in Fedora 41 en Fedora Rawhide. Het gebruik van deze distributies wordt afgeraden. Debian meldde dat de stable distributies niet zijn aangetast, wel de testing, unstable en experimentele versies. De backdoor heeft ook een CVE-nummer gekregen, namelijk CVE-2024-3094. De impact is op een schaal van 1 tot en met 10 beoordeeld met een 10.0.
Reacties (37)
30-03-2024, 10:06 door
Anoniem
OpenSUSE adviseert meer dan alleen downgraden:
For our openSUSE Tumbleweed users where SSH is exposed to the internet we recommend installing fresh, as it’s unknown if the backdoor has been exploited. Due to the sophisticated nature of the backdoor an on-system detection of a breach is likely not possible.
https://news.opensuse.org/2024/03/29/xz-backdoor/[/quote]
30-03-2024, 10:55 door
Anoniem
Wie onder Debian de package unattended-upgrades heeft ingeschakeld kan rustig blijven slapen, op die systemen is de versie meteen teruggedraaid naar 5.4.1
30-03-2024, 10:57 door
Anoniem
Oeps! Klikbare link bij de eerste reactie:
https://news.opensuse.org/2024/03/29/xz-backdoor/
https://news.opensuse.org/2024/03/29/xz-backdoor/
30-03-2024, 11:21 door
Anoniem
Ik verwacht ook problemen met flatpak en snap, omdat die hun eigen versies van xz bij zich kunnen dragen. Welke versie van xz zit er bijvoorbeeld in Firefox onder linux? Misschien gebruikt Firefox geen compressie om bestanden lokaal op te slaan? Misschien ook wel.
30-03-2024, 12:57 door
Anoniem
kali linux heeft ook gelijk xz gedowngrade, kon ook gelijk updaten
30-03-2024, 13:42 door
Anoniem
Als ik mij niet vergis, dan is in Linux Ubuntu 22.04.4 LTS wel XZ geïnstalleerd (volgens Synaptic Pakketbeheer), maar zo te zien is deze XZ-versie niet voorzien van de gevonden backdoor.
Als mijn conclusie klopt, dan hoeft deze distro niet te worden bijgewerkt. Hoe het met de andere Ubuntu versies zit, weet ik op dit moment niet. Daar zou dus ook afzonderlijk naar gekeken moeten worden.
Als mijn conclusie klopt, dan hoeft deze distro niet te worden bijgewerkt. Hoe het met de andere Ubuntu versies zit, weet ik op dit moment niet. Daar zou dus ook afzonderlijk naar gekeken moeten worden.
30-03-2024, 14:18 door
Anoniem
Door Anoniem: Wie onder Debian de package unattended-upgrades heeft ingeschakeld kan rustig blijven slapen, op die systemen is de versie meteen teruggedraaid naar 5.4.1
5.4.5
30-03-2024, 14:21 door
Anoniem
Een kwaadwillende kan de kwetsbaarheid misbruiken om authenticatie te omzeilen en lijkt gebruikt te worden om SSH te compromitteren", aldus het NCSC.
Lijkt mij een voorbarige conclusie van NCSC. Mijn gevoel zegt dat alleen die maintainer toegang heeft met zijn private key omdat er waarschijnlijk een public key in die testbinary zit. Volgens mij gebruikt niemand Fedora 41 want zelfs Fedora 40 is nog in beta.
Als Redhat rhel gebruiker haal ik opgelucht adem. Geen enkel product affected. Wel een bewijs dat open source MOET want van die testbinary was geen source beschikbaar.
Ik zie dat Lasse Collin het heeft gefixed. https://git.tukaani.org/?p=xz.git
Op 2024-03-09 heeft de saboteur Jia Tan (of iemand anders via zijn gehackt account) die testfiles ge-commit.
30-03-2024, 14:24 door
Anoniem
Blijkbaar is er ook een windows versie: https://git.tukaani.org/?p=xz.git;a=tree;f=windows;h=e3048e2a3c82664b26b8bd7688d5c292fe878212;hb=HEAD
30-03-2024, 15:04 door
Anoniem
Door Anoniem: Als ik mij niet vergis, dan is in Linux Ubuntu 22.04.4 LTS wel XZ geïnstalleerd (volgens Synaptic Pakketbeheer), maar zo te zien is deze XZ-versie niet voorzien van de gevonden backdoor.
Als mijn conclusie klopt, dan hoeft deze distro niet te worden bijgewerkt. Hoe het met de andere Ubuntu versies zit, weet ik op dit moment niet. Daar zou dus ook afzonderlijk naar gekeken moeten worden.
Als mijn conclusie klopt, dan hoeft deze distro niet te worden bijgewerkt. Hoe het met de andere Ubuntu versies zit, weet ik op dit moment niet. Daar zou dus ook afzonderlijk naar gekeken moeten worden.
Hoe het met de reguliere releases zit weet ik niet, voor 24.04 LTS stond de 'foute' release op de planning maar is daar inmiddels uitgehaald. Eea op basis van de nu bekende gegevens, in de aanname dat de oudere releases wel goed zijn...
https://discourse.ubuntu.com/t/xz-liblzma-security-update/43714
30-03-2024, 16:28 door
Anoniem
Door Anoniem:
Volgens mij gebruikt niemand Fedora 41 want zelfs Fedora 40 is nog in beta.
Als Redhat rhel gebruiker haal ik opgelucht adem. Geen enkel product affected. Wel een bewijs dat open source MOET want van die testbinary was geen source beschikbaar.
Een kwaadwillende kan de kwetsbaarheid misbruiken om authenticatie te omzeilen en lijkt gebruikt te worden om SSH te compromitteren", aldus het NCSC.
Lijkt mij een voorbarige conclusie van NCSC. Mijn gevoel zegt dat alleen die maintainer toegang heeft met zijn private key omdat er waarschijnlijk een public key in die testbinary zit. Volgens mij gebruikt niemand Fedora 41 want zelfs Fedora 40 is nog in beta.
Als Redhat rhel gebruiker haal ik opgelucht adem. Geen enkel product affected. Wel een bewijs dat open source MOET want van die testbinary was geen source beschikbaar.
Je moet 'open source' niet ZO heilig verklaren.
Het hele inbouwen van de 'testcode' in een build WAS open source. Alleen obfuscated in het auto-conf script.
En dat is allemaal niet gezien totdat die ene ontdekker een probleem ging analyseren en erop stuitte.
Er zijn veel denkbare mechanismen om 'eigenlijk binary' inderdaad als test objecten mee te leveren
Of het nu crypto libraries zijn, of image processing, een paar known testvectors om precies te testen of de gecompileerde versie het doet.
Het is dan vrij makkelijk om daar je malicious code (eventueel geobfuscate, of gecrypt) tussen te plakken en op vergelijkbare manier te laten importeren. En dat kunnen nog 'valide' test files zijn ook , dwz iets dat 'herkend' wordt als .png file, dat ook is, maar waarvan een stukje data vanaf offset 0xdeadbeef eruit geknipt wordt met een script en dan opeens een .o file is.
30-03-2024, 17:10 door
Anoniem
Door Anoniem:
Een kwaadwillende kan de kwetsbaarheid misbruiken om authenticatie te omzeilen en lijkt gebruikt te worden om SSH te compromitteren", aldus het NCSC.
Lijkt mij een voorbarige conclusie van NCSC. Mijn gevoel zegt dat alleen die maintainer toegang heeft met zijn private key omdat er waarschijnlijk een public key in die testbinary zit. Het heeft alle schijn van een state-sponsored attack, en niet (slechts) een persoonlijke actie van 'die maintainer' .
Inderdaad ligt een magische extra key voor de hand , het is vast niet alleen de NSA die graag 'NOBUS' (nobody but us) backdoors wil , en geen backdoors die "iedereen" kan gebruiken die de code analyseert.
Maar de pool van 'kwaadwillenden' die deze toegang kan gebruiken zal m.i. wel meer zijn dan "die (ene) maintainer" .
Of, na alle analyse en reverse engineering de backdoor _ook nog _ door anderen te gebruiken is, is een open vraag.
30-03-2024, 17:13 door
Anoniem
Door Anoniem: Wie onder Debian de package unattended-upgrades heeft ingeschakeld kan rustig blijven slapen, op die systemen is de versie meteen teruggedraaid naar 5.4.1
Wie Debian stable gebruikt heeft om te beginnen al geen gecompromitteerde versie gehad. En wie de gecompromitteerde versie wel aan boord heeft gehad, of dat nou op Debian unstable of testing, op een van de genoemde Fedora-versies, openSUSE of wat anders was, doet er goed aan te onderzoeken of er geen ongewenste wijzigingen +zijn aangebracht. En dat kan lastig zijn als bijvoorbeeld mocht blijken dat je een nog onbekende rootkit hebt opgelopen. Zie het advies van openSUSE waar hierboven al naar is gelinkt.
30-03-2024, 18:56 door
Anoniem
We mogen malwareontdekker Andres Freund wel zeer dankbaar zijn. Hij heeft groter leed voorkomen. Is er een manier om hem te belonen?
30-03-2024, 22:02 door
Anoniem
Door Anoniem:
Hoe het met de reguliere releases zit weet ik niet, voor 24.04 LTS stond de 'foute' release op de planning maar is daar inmiddels uitgehaald. Eea op basis van de nu bekende gegevens, in de aanname dat de oudere releases wel goed zijn...
https://discourse.ubuntu.com/t/xz-liblzma-security-update/43714
Bedankt voor de info!Door Anoniem: Als ik mij niet vergis, dan is in Linux Ubuntu 22.04.4 LTS wel XZ geïnstalleerd (volgens Synaptic Pakketbeheer), maar zo te zien is deze XZ-versie niet voorzien van de gevonden backdoor.
Als mijn conclusie klopt, dan hoeft deze distro niet te worden bijgewerkt. Hoe het met de andere Ubuntu versies zit, weet ik op dit moment niet. Daar zou dus ook afzonderlijk naar gekeken moeten worden.
Als mijn conclusie klopt, dan hoeft deze distro niet te worden bijgewerkt. Hoe het met de andere Ubuntu versies zit, weet ik op dit moment niet. Daar zou dus ook afzonderlijk naar gekeken moeten worden.
Hoe het met de reguliere releases zit weet ik niet, voor 24.04 LTS stond de 'foute' release op de planning maar is daar inmiddels uitgehaald. Eea op basis van de nu bekende gegevens, in de aanname dat de oudere releases wel goed zijn...
https://discourse.ubuntu.com/t/xz-liblzma-security-update/43714
Er wordt al van 'state sponsored attack' gesproken. Probleem is dat er eerst een volledig onderzoek moet komen hoe eventueel deze Backdoor precies erin is gekomen, en of later de vraag kan worden beantwoord of er een APT van een of ander land achter zou kunnen zitten. Maar afgezien daarvan, is het goed dat er mensen zijn die de code natrekken. Zonder hen zouden we nu een behoorlijke kwetsbaarheid in onze Linux distro's hebben!
31-03-2024, 00:32 door
Anoniem
Door Anoniem: Wie onder Debian de package unattended-upgrades heeft ingeschakeld kan rustig blijven slapen, op die systemen is de versie meteen teruggedraaid naar 5.4.1
Dat is mogelijk onvoldoende. In die xz versie zijn wel vele veranderingen door de aanvaller opgenomen. Om verlost te zijn van betrokkenheid van die persoon moet een distributie teruggaan tot 2022 of eerder.
31-03-2024, 09:57 door
Anoniem
Door Anoniem: We mogen malwareontdekker Andres Freund wel zeer dankbaar zijn. Hij heeft groter leed voorkomen. Is er een manier om hem te belonen?
Overweeg om een deel van uw geld, hardware, bandbreedte of tijd belastingvrij te doneren aan het Debian-project! :-)
https://www.debian.org/donations.nl.html
31-03-2024, 10:31 door
Anoniem
Door Anoniem:
Je moet 'open source' niet ZO heilig verklaren.
Het hele inbouwen van de 'testcode' in een build WAS open source. Alleen obfuscated in het auto-conf script.
En dat is allemaal niet gezien totdat die ene ontdekker een probleem ging analyseren en erop stuitte.
Er zijn veel denkbare mechanismen om 'eigenlijk binary' inderdaad als test objecten mee te leveren
Of het nu crypto libraries zijn, of image processing, een paar known testvectors om precies te testen of de gecompileerde versie het doet.
Het is dan vrij makkelijk om daar je malicious code (eventueel geobfuscate, of gecrypt) tussen te plakken en op vergelijkbare manier te laten importeren. En dat kunnen nog 'valide' test files zijn ook , dwz iets dat 'herkend' wordt als .png file, dat ook is, maar waarvan een stukje data vanaf offset 0xdeadbeef eruit geknipt wordt met een script en dan opeens een .o file is.
De source van die testfase was niet bekend. Daarom zeg ik geen blogs in git. Dan compileer je het maar on the fly. Er zijn trouwens ook symbolisch verwijderd. Dan had er ook een lampje moeten branden.Door Anoniem:
Volgens mij gebruikt niemand Fedora 41 want zelfs Fedora 40 is nog in beta.
Als Redhat rhel gebruiker haal ik opgelucht adem. Geen enkel product affected. Wel een bewijs dat open source MOET want van die testbinary was geen source beschikbaar.
Een kwaadwillende kan de kwetsbaarheid misbruiken om authenticatie te omzeilen en lijkt gebruikt te worden om SSH te compromitteren", aldus het NCSC.
Lijkt mij een voorbarige conclusie van NCSC. Mijn gevoel zegt dat alleen die maintainer toegang heeft met zijn private key omdat er waarschijnlijk een public key in die testbinary zit. Volgens mij gebruikt niemand Fedora 41 want zelfs Fedora 40 is nog in beta.
Als Redhat rhel gebruiker haal ik opgelucht adem. Geen enkel product affected. Wel een bewijs dat open source MOET want van die testbinary was geen source beschikbaar.
Je moet 'open source' niet ZO heilig verklaren.
Het hele inbouwen van de 'testcode' in een build WAS open source. Alleen obfuscated in het auto-conf script.
En dat is allemaal niet gezien totdat die ene ontdekker een probleem ging analyseren en erop stuitte.
Er zijn veel denkbare mechanismen om 'eigenlijk binary' inderdaad als test objecten mee te leveren
Of het nu crypto libraries zijn, of image processing, een paar known testvectors om precies te testen of de gecompileerde versie het doet.
Het is dan vrij makkelijk om daar je malicious code (eventueel geobfuscate, of gecrypt) tussen te plakken en op vergelijkbare manier te laten importeren. En dat kunnen nog 'valide' test files zijn ook , dwz iets dat 'herkend' wordt als .png file, dat ook is, maar waarvan een stukje data vanaf offset 0xdeadbeef eruit geknipt wordt met een script en dan opeens een .o file is.
31-03-2024, 10:35 door
Anoniem
Door Anoniem:
Dat is mogelijk onvoldoende. In die xz versie zijn wel vele veranderingen door de aanvaller opgenomen. Om verlost te zijn van betrokkenheid van die persoon moet een distributie teruggaan tot 2022 of eerder.
Nee backdoor zit in de Testfile. Zie git historischeDoor Anoniem: Wie onder Debian de package unattended-upgrades heeft ingeschakeld kan rustig blijven slapen, op die systemen is de versie meteen teruggedraaid naar 5.4.1
Dat is mogelijk onvoldoende. In die xz versie zijn wel vele veranderingen door de aanvaller opgenomen. Om verlost te zijn van betrokkenheid van die persoon moet een distributie teruggaan tot 2022 of eerder.
31-03-2024, 10:41 door
Anoniem
Door Anoniem:
Het heeft alle schijn van een state-sponsored attack, en niet (slechts) een persoonlijke actie van 'die maintainer' .
Inderdaad ligt een magische extra key voor de hand , het is vast niet alleen de NSA die graag 'NOBUS' (nobody but us) backdoors wil , en geen backdoors die "iedereen" kan gebruiken die de code analyseert.
Maar de pool van 'kwaadwillenden' die deze toegang kan gebruiken zal m.i. wel meer zijn dan "die (ene) maintainer" .
Of, na alle analyse en reverse engineering de backdoor _ook nog _ door anderen te gebruiken is, is een open vraag.
Ik denk het ook. Daarnaast zijn er rond dezelfde tijd meerdere accounts aangemaakt bij andere distros lees ik. We gaan het horen of er naast de public key van de hackers nog meer aan de hand is. Weer een leuke honing pot erbij.Door Anoniem:
Een kwaadwillende kan de kwetsbaarheid misbruiken om authenticatie te omzeilen en lijkt gebruikt te worden om SSH te compromitteren", aldus het NCSC.
Lijkt mij een voorbarige conclusie van NCSC. Mijn gevoel zegt dat alleen die maintainer toegang heeft met zijn private key omdat er waarschijnlijk een public key in die testbinary zit. Het heeft alle schijn van een state-sponsored attack, en niet (slechts) een persoonlijke actie van 'die maintainer' .
Inderdaad ligt een magische extra key voor de hand , het is vast niet alleen de NSA die graag 'NOBUS' (nobody but us) backdoors wil , en geen backdoors die "iedereen" kan gebruiken die de code analyseert.
Maar de pool van 'kwaadwillenden' die deze toegang kan gebruiken zal m.i. wel meer zijn dan "die (ene) maintainer" .
Of, na alle analyse en reverse engineering de backdoor _ook nog _ door anderen te gebruiken is, is een open vraag.
31-03-2024, 13:52 door
Anoniem
Door Anoniem:
Door Anoniem:
Je moet 'open source' niet ZO heilig verklaren.
Het hele inbouwen van de 'testcode' in een build WAS open source. Alleen obfuscated in het auto-conf script.
En dat is allemaal niet gezien totdat die ene ontdekker een probleem ging analyseren en erop stuitte.
Er zijn veel denkbare mechanismen om 'eigenlijk binary' inderdaad als test objecten mee te leveren
Of het nu crypto libraries zijn, of image processing, een paar known testvectors om precies te testen of de gecompileerde versie het doet.
Het is dan vrij makkelijk om daar je malicious code (eventueel geobfuscate, of gecrypt) tussen te plakken en op vergelijkbare manier te laten importeren. En dat kunnen nog 'valide' test files zijn ook , dwz iets dat 'herkend' wordt als .png file, dat ook is, maar waarvan een stukje data vanaf offset 0xdeadbeef eruit geknipt wordt met een script en dan opeens een .o file is.
De source van die testfase was niet bekend. Daarom zeg ik geen blogs in git. Dan compileer je het maar on the fly. Er zijn trouwens ook symbolisch verwijderd. Dan had er ook een lampje moeten branden.Door Anoniem:
Volgens mij gebruikt niemand Fedora 41 want zelfs Fedora 40 is nog in beta.
Als Redhat rhel gebruiker haal ik opgelucht adem. Geen enkel product affected. Wel een bewijs dat open source MOET want van die testbinary was geen source beschikbaar.
Een kwaadwillende kan de kwetsbaarheid misbruiken om authenticatie te omzeilen en lijkt gebruikt te worden om SSH te compromitteren", aldus het NCSC.
Lijkt mij een voorbarige conclusie van NCSC. Mijn gevoel zegt dat alleen die maintainer toegang heeft met zijn private key omdat er waarschijnlijk een public key in die testbinary zit. Volgens mij gebruikt niemand Fedora 41 want zelfs Fedora 40 is nog in beta.
Als Redhat rhel gebruiker haal ik opgelucht adem. Geen enkel product affected. Wel een bewijs dat open source MOET want van die testbinary was geen source beschikbaar.
Je moet 'open source' niet ZO heilig verklaren.
Het hele inbouwen van de 'testcode' in een build WAS open source. Alleen obfuscated in het auto-conf script.
En dat is allemaal niet gezien totdat die ene ontdekker een probleem ging analyseren en erop stuitte.
Er zijn veel denkbare mechanismen om 'eigenlijk binary' inderdaad als test objecten mee te leveren
Of het nu crypto libraries zijn, of image processing, een paar known testvectors om precies te testen of de gecompileerde versie het doet.
Het is dan vrij makkelijk om daar je malicious code (eventueel geobfuscate, of gecrypt) tussen te plakken en op vergelijkbare manier te laten importeren. En dat kunnen nog 'valide' test files zijn ook , dwz iets dat 'herkend' wordt als .png file, dat ook is, maar waarvan een stukje data vanaf offset 0xdeadbeef eruit geknipt wordt met een script en dan opeens een .o file is.
Je snapt het nog steeds niet.
test "data" is bij veel software noodzakelijk. Dat is wat je bij een build wilt controleren - _werkt_ het ook. Geen foutje omdat het gecompileerd is op big endian cpu. of op 16 bit .
Dus is het meeleveren van test 'data' - die gebruikt kan worden door het zojuist ge-builde project met bekende uitkomst - zo nodig.
Dat er uit een encryptie of compressie programma 'abracadabra' komt is niet genoeg. Of dat er "iets" gedaan wordt door een audio converter, of een image processor .
- het moet wel abracadraba zijn die klopt met de spec, en die door ANDERE software die dit protocol implementeert ook weer gelezen kan worden.
Als je amper of nooit zelf iets gecodeerd (of maar gebuild) hebt snap je niet wat 'normaal' of 'nodig' is - en waarom dat soort leunstoel wijsheden "gewoon alleen maar source" zo'n nutteloos advies is als 'magische oplossing' .
Lees hier ook eens https://www.ioccc.org/
Nogmaals, dat hele build proces WAS AL FOUT . En open source. En werd niet gezien .
Pas nadat het serieus bekeken werd was meteen duidelijk ' heel wordt iets heel erg fishy gedaan .
31-03-2024, 19:58 door
Joep Lunaar
Mogelijk helpt het dat veel toepassingen tegenwoordig in een container of sandbox draaien waarmee het risico op manifeste problemen kleiner zijn. Wat mogelijk niet helpt is als closed-source programma's van de gecompromitteerde lib gebruik hebben gemaakt zonder dat dit voor de gebruikers zichtbaar is - los van de vraag of daarbij de bepalingen van de GPL wel worden gevolgd. En over hoe goed die programmatuur van updates wordt voorzien ...
Door Anoniem:
Je snapt het nog steeds niet.
[knip /] ...
Als je amper of nooit zelf iets gecodeerd (of maar gebuild) hebt snap je niet wat 'normaal' of 'nodig' is - en waarom dat soort leunstoel wijsheden "gewoon alleen maar source" zo'n nutteloos advies is als 'magische oplossing' .
Lees hier ook eens https://www.ioccc.org/
Nogmaals, dat hele build proces WAS AL FOUT . En open source. En werd niet gezien .
Pas nadat het serieus bekeken werd was meteen duidelijk ' heel wordt iets heel erg fishy gedaan .
U doet bijzonder aanmatigend en onaardig.... vriendelijke en welgemeende discussie ...
Je snapt het nog steeds niet.
[knip /] ...
Als je amper of nooit zelf iets gecodeerd (of maar gebuild) hebt snap je niet wat 'normaal' of 'nodig' is - en waarom dat soort leunstoel wijsheden "gewoon alleen maar source" zo'n nutteloos advies is als 'magische oplossing' .
Lees hier ook eens https://www.ioccc.org/
Nogmaals, dat hele build proces WAS AL FOUT . En open source. En werd niet gezien .
Pas nadat het serieus bekeken werd was meteen duidelijk ' heel wordt iets heel erg fishy gedaan .
31-03-2024, 20:28 door
Anoniem
Door Anoniem:
Door Anoniem:
Dat is mogelijk onvoldoende. In die xz versie zijn wel vele veranderingen door de aanvaller opgenomen. Om verlost te zijn van betrokkenheid van die persoon moet een distributie teruggaan tot 2022 of eerder.
Nee backdoor zit in de Testfile. Zie git historischeDoor Anoniem: Wie onder Debian de package unattended-upgrades heeft ingeschakeld kan rustig blijven slapen, op die systemen is de versie meteen teruggedraaid naar 5.4.1
Dat is mogelijk onvoldoende. In die xz versie zijn wel vele veranderingen door de aanvaller opgenomen. Om verlost te zijn van betrokkenheid van die persoon moet een distributie teruggaan tot 2022 of eerder.
Heb je moeite met begrijpend lezen?
31-03-2024, 20:35 door
Anoniem
Door Joep Lunaar:
Door Anoniem:
Je snapt het nog steeds niet.
[knip /] ...
Als je amper of nooit zelf iets gecodeerd (of maar gebuild) hebt snap je niet wat 'normaal' of 'nodig' is - en waarom dat soort leunstoel wijsheden "gewoon alleen maar source" zo'n nutteloos advies is als 'magische oplossing' .
Lees hier ook eens https://www.ioccc.org/
Nogmaals, dat hele build proces WAS AL FOUT . En open source. En werd niet gezien .
Pas nadat het serieus bekeken werd was meteen duidelijk ' heel wordt iets heel erg fishy gedaan .
U doet bijzonder aanmatigend en onaardig.... vriendelijke en welgemeende discussie ...
Je snapt het nog steeds niet.
[knip /] ...
Als je amper of nooit zelf iets gecodeerd (of maar gebuild) hebt snap je niet wat 'normaal' of 'nodig' is - en waarom dat soort leunstoel wijsheden "gewoon alleen maar source" zo'n nutteloos advies is als 'magische oplossing' .
Lees hier ook eens https://www.ioccc.org/
Nogmaals, dat hele build proces WAS AL FOUT . En open source. En werd niet gezien .
Pas nadat het serieus bekeken werd was meteen duidelijk ' heel wordt iets heel erg fishy gedaan .
tsja, je legt het probleem één keer netjes uit, en dan komt ie erover heen weer hetzelfde , zonder het commentaar gelezen cq begrepen te hebben.
Dan moet het maar wat harder en duidelijker gezegd worden.
Misschien zakt het dan - ook bij meelezers - in hoe moeilijk het probleem is , dan wel hoeveel manieren een malicious insider heeft om normale en noodzakelijke aspecten van een software (build) proces te misbruiken.
. En dat "óók de source is te zien" (zoals het backdoor insert tijdens build-proces) niet vanzelf een oplossing is.
31-03-2024, 22:28 door
Anoniem
Door Anoniem:
Er wordt al van 'state sponsored attack' gesproken. Probleem is dat er eerst een volledig onderzoek moet komen hoe eventueel deze Backdoor precies erin is gekomen, en of later de vraag kan worden beantwoord of er een APT van een of ander land achter zou kunnen zitten. Maar afgezien daarvan, is het goed dat er mensen zijn die de code natrekken. Zonder hen zouden we nu een behoorlijke kwetsbaarheid in onze Linux distro's hebben!
Nadat iemand iets vreemds signaleerde, is er iemand gaan zoeken. Nu niet het doen of er continu nagezocht wordt.Door Anoniem:
Hoe het met de reguliere releases zit weet ik niet, voor 24.04 LTS stond de 'foute' release op de planning maar is daar inmiddels uitgehaald. Eea op basis van de nu bekende gegevens, in de aanname dat de oudere releases wel goed zijn...
https://discourse.ubuntu.com/t/xz-liblzma-security-update/43714
Bedankt voor de info!Door Anoniem: Als ik mij niet vergis, dan is in Linux Ubuntu 22.04.4 LTS wel XZ geïnstalleerd (volgens Synaptic Pakketbeheer), maar zo te zien is deze XZ-versie niet voorzien van de gevonden backdoor.
Als mijn conclusie klopt, dan hoeft deze distro niet te worden bijgewerkt. Hoe het met de andere Ubuntu versies zit, weet ik op dit moment niet. Daar zou dus ook afzonderlijk naar gekeken moeten worden.
Als mijn conclusie klopt, dan hoeft deze distro niet te worden bijgewerkt. Hoe het met de andere Ubuntu versies zit, weet ik op dit moment niet. Daar zou dus ook afzonderlijk naar gekeken moeten worden.
Hoe het met de reguliere releases zit weet ik niet, voor 24.04 LTS stond de 'foute' release op de planning maar is daar inmiddels uitgehaald. Eea op basis van de nu bekende gegevens, in de aanname dat de oudere releases wel goed zijn...
https://discourse.ubuntu.com/t/xz-liblzma-security-update/43714
Er wordt al van 'state sponsored attack' gesproken. Probleem is dat er eerst een volledig onderzoek moet komen hoe eventueel deze Backdoor precies erin is gekomen, en of later de vraag kan worden beantwoord of er een APT van een of ander land achter zou kunnen zitten. Maar afgezien daarvan, is het goed dat er mensen zijn die de code natrekken. Zonder hen zouden we nu een behoorlijke kwetsbaarheid in onze Linux distro's hebben!
31-03-2024, 22:59 door
Anoniem
Lijkt mij een voorbarige conclusie van NCSC. Mijn gevoel zegt dat alleen die maintainer toegang heeft met zijn private key omdat er waarschijnlijk een public key in die testbinary zit.
'Gevoel' lijkt me een gevaarlijke raadgever in security zaken ;-)
Ik meen ergens gelezen te hebben dat:
- de vulnerability is niet een authenticatie omzeiling maar een 'remote code execution'.
- een van de backdoor voorziene sshd saved het public key deel van een speciaal aangemaakt openssl certificaat/rsa key als een executable en runt dat met root privileged. Waarvoor het inloggen niet eens hoeft te lukken.
- een kwetsbare sshd kan dus door iedereen die weet hoe de backdoor werkt gebruikt worden om willekeurig wat met root privileges te runnen.
- daarna is het systeem dus niet meer te vertrouwen.
01-04-2024, 12:09 door
Anoniem
Door Anoniem: Het heeft alle schijn van een state-sponsored attack, en niet (slechts) een persoonlijke actie
Dit lijkt een vooropgezet plan te zijn geweest waarbij deze user alleen al maanden bezig is geweest met deze exploit in te bakken (bv in december al een wijziging aan de website dat de door GitHub gegenereerde source downloads niet gebruikt moeten worden, maar mogelijk nog eerder al waarbij er wordt verwezen naar juni/juli 2023). Nog los van het feit dat deze persoon al 2 jaar "mede eigenaar" is van het project en waarschijnlijk daarvoor ook al bijdragen deed leveren (om niet als total stranger te vragen om "mede eigenaar" te worden).
https://tweakers.net/nieuws/220340/compressietool-xz-lijkt-malware-te-bevatten-linux-distros-waarschuwen.html
01-04-2024, 15:42 door
Anoniem
Door Anoniem:
Lijkt mij een voorbarige conclusie van NCSC. Mijn gevoel zegt dat alleen die maintainer toegang heeft met zijn private key omdat er waarschijnlijk een public key in die testbinary zit.
'Gevoel' lijkt me een gevaarlijke raadgever in security zaken ;-)
Ik meen ergens gelezen te hebben dat:
Lijkt mij een voorbarige conclusie van NCSC. Mijn gevoel zegt dat alleen die maintainer toegang heeft met zijn private key omdat er waarschijnlijk een public key in die testbinary zit.
'Gevoel' lijkt me een gevaarlijke raadgever in security zaken ;-)
Ik meen ergens gelezen te hebben dat:
Gevoel was hier , zo te lezen, meer 'aannamelijke speculatie'.
Maar het is maar net een klein trapje slechter dan "ik meen ergens gelezen te hebben" als raadgever.
Kom op - om serieus conclusies te trekken moet je wat exacter paraat hebben waar je informatie vandaan komt, en of het op z'n minst aannemelijk is dat die plek een solide bron is.
"I read it on the Internet ..."
- de vulnerability is niet een authenticatie omzeiling maar een 'remote code execution'.
- een van de backdoor voorziene sshd saved het public key deel van een speciaal aangemaakt openssl certificaat/rsa key als een executable en runt dat met root privileged. Waarvoor het inloggen niet eens hoeft te lukken.
- een kwetsbare sshd kan dus door iedereen die weet hoe de backdoor werkt gebruikt worden om willekeurig wat met root privileges te runnen.
- daarna is het systeem dus niet meer te vertrouwen.
In dit geval heb ik dit ook gelezen. Waarschijnlijk deze https://bsky.app/profile/filippo.abyssdomain.expert/post/3kowjkx2njy2b , waar de redactie naar linkte.
Note dat dit een verhaal 'uit de tweede hand' is - Valsorda zegt dat hij repost van 'mensen die aan het reverse engineeren zijn' .
nitpicktje : niet 'iedereen die weet hoe de backdoor werkt' , m.i. ,maar iedereen die de magische secret key heeft .
Waarschijnlijk een geheime dienst. Misschien niet eens 'Jia Tan' , om de backdoor te plaatsen hoeft die niet de sleutel te hebben, alleen de pubkey ervan.
Hier is iemand behoorlijk goed bezig met reverse analyseren.
https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9f504
analyse van de backdoor-insertion tijdens het builden.
https://gynvael.coldwind.pl/?lang=en&id=782
(take note - dit deel was open source ! )
cartoon versie van timelines
https://twitter.com/fr0gger_/status/1774342248437813525
01-04-2024, 22:36 door
Anoniem
Door Anoniem:
Je snapt het nog steeds niet.
test "data" is bij veel software noodzakelijk. Dat is wat je bij een build wilt controleren - _werkt_ het ook. Geen foutje omdat het gecompileerd is op big endian cpu. of op 16 bit .
Dus is het meeleveren van test 'data' - die gebruikt kan worden door het zojuist ge-builde project met bekende uitkomst - zo nodig.
Dat er uit een encryptie of compressie programma 'abracadabra' komt is niet genoeg. Of dat er "iets" gedaan wordt door een audio converter, of een image processor .
- het moet wel abracadraba zijn die klopt met de spec, en die door ANDERE software die dit protocol implementeert ook weer gelezen kan worden.
Als je amper of nooit zelf iets gecodeerd (of maar gebuild) hebt snap je niet wat 'normaal' of 'nodig' is - en waarom dat soort leunstoel wijsheden "gewoon alleen maar source" zo'n nutteloos advies is als 'magische oplossing' .
Lees hier ook eens https://www.ioccc.org/
Nogmaals, dat hele build proces WAS AL FOUT . En open source. En werd niet gezien .
Pas nadat het serieus bekeken werd was meteen duidelijk ' heel wordt iets heel erg fishy gedaan .
Dan waren er dus niet genoeg eye balls. Natuurlijk moeten er testfiles beschikbaar zijn maar dan ook hoe ze zijn gegenereerd (of compiled van sources) Je gaat niet zo maar in een bouwfase onbekende test objectfiles injecteren.Door Anoniem:
Door Anoniem:
Je moet 'open source' niet ZO heilig verklaren.
Het hele inbouwen van de 'testcode' in een build WAS open source. Alleen obfuscated in het auto-conf script.
En dat is allemaal niet gezien totdat die ene ontdekker een probleem ging analyseren en erop stuitte.
Er zijn veel denkbare mechanismen om 'eigenlijk binary' inderdaad als test objecten mee te leveren
Of het nu crypto libraries zijn, of image processing, een paar known testvectors om precies te testen of de gecompileerde versie het doet.
Het is dan vrij makkelijk om daar je malicious code (eventueel geobfuscate, of gecrypt) tussen te plakken en op vergelijkbare manier te laten importeren. En dat kunnen nog 'valide' test files zijn ook , dwz iets dat 'herkend' wordt als .png file, dat ook is, maar waarvan een stukje data vanaf offset 0xdeadbeef eruit geknipt wordt met een script en dan opeens een .o file is.
De source van die testfase was niet bekend. Daarom zeg ik geen blogs in git. Dan compileer je het maar on the fly. Er zijn trouwens ook symbolisch verwijderd. Dan had er ook een lampje moeten branden.Door Anoniem:
Volgens mij gebruikt niemand Fedora 41 want zelfs Fedora 40 is nog in beta.
Als Redhat rhel gebruiker haal ik opgelucht adem. Geen enkel product affected. Wel een bewijs dat open source MOET want van die testbinary was geen source beschikbaar.
Een kwaadwillende kan de kwetsbaarheid misbruiken om authenticatie te omzeilen en lijkt gebruikt te worden om SSH te compromitteren", aldus het NCSC.
Lijkt mij een voorbarige conclusie van NCSC. Mijn gevoel zegt dat alleen die maintainer toegang heeft met zijn private key omdat er waarschijnlijk een public key in die testbinary zit. Volgens mij gebruikt niemand Fedora 41 want zelfs Fedora 40 is nog in beta.
Als Redhat rhel gebruiker haal ik opgelucht adem. Geen enkel product affected. Wel een bewijs dat open source MOET want van die testbinary was geen source beschikbaar.
Je moet 'open source' niet ZO heilig verklaren.
Het hele inbouwen van de 'testcode' in een build WAS open source. Alleen obfuscated in het auto-conf script.
En dat is allemaal niet gezien totdat die ene ontdekker een probleem ging analyseren en erop stuitte.
Er zijn veel denkbare mechanismen om 'eigenlijk binary' inderdaad als test objecten mee te leveren
Of het nu crypto libraries zijn, of image processing, een paar known testvectors om precies te testen of de gecompileerde versie het doet.
Het is dan vrij makkelijk om daar je malicious code (eventueel geobfuscate, of gecrypt) tussen te plakken en op vergelijkbare manier te laten importeren. En dat kunnen nog 'valide' test files zijn ook , dwz iets dat 'herkend' wordt als .png file, dat ook is, maar waarvan een stukje data vanaf offset 0xdeadbeef eruit geknipt wordt met een script en dan opeens een .o file is.
Je snapt het nog steeds niet.
test "data" is bij veel software noodzakelijk. Dat is wat je bij een build wilt controleren - _werkt_ het ook. Geen foutje omdat het gecompileerd is op big endian cpu. of op 16 bit .
Dus is het meeleveren van test 'data' - die gebruikt kan worden door het zojuist ge-builde project met bekende uitkomst - zo nodig.
Dat er uit een encryptie of compressie programma 'abracadabra' komt is niet genoeg. Of dat er "iets" gedaan wordt door een audio converter, of een image processor .
- het moet wel abracadraba zijn die klopt met de spec, en die door ANDERE software die dit protocol implementeert ook weer gelezen kan worden.
Als je amper of nooit zelf iets gecodeerd (of maar gebuild) hebt snap je niet wat 'normaal' of 'nodig' is - en waarom dat soort leunstoel wijsheden "gewoon alleen maar source" zo'n nutteloos advies is als 'magische oplossing' .
Lees hier ook eens https://www.ioccc.org/
Nogmaals, dat hele build proces WAS AL FOUT . En open source. En werd niet gezien .
Pas nadat het serieus bekeken werd was meteen duidelijk ' heel wordt iets heel erg fishy gedaan .
01-04-2024, 22:38 door
Anoniem
Door Joep Lunaar: Mogelijk helpt het dat veel toepassingen tegenwoordig in een container of sandbox draaien waarmee het risico op manifeste problemen kleiner zijn. Wat mogelijk niet helpt is als closed-source programma's van de gecompromitteerde lib gebruik hebben gemaakt zonder dat dit voor de gebruikers zichtbaar is - los van de vraag of daarbij de bepalingen van de GPL wel worden gevolgd. En over hoe goed die programmatuur van updates wordt voorzien ...
Windows 11 maakt ook gebruik van XZ (zie ondersteunde archives sinds oktober vorig jaar)
01-04-2024, 22:45 door
Anoniem
Door Anoniem:
Bij RedHat rhel zeker wel!Door Anoniem:
Er wordt al van 'state sponsored attack' gesproken. Probleem is dat er eerst een volledig onderzoek moet komen hoe eventueel deze Backdoor precies erin is gekomen, en of later de vraag kan worden beantwoord of er een APT van een of ander land achter zou kunnen zitten. Maar afgezien daarvan, is het goed dat er mensen zijn die de code natrekken. Zonder hen zouden we nu een behoorlijke kwetsbaarheid in onze Linux distro's hebben!
Nadat iemand iets vreemds signaleerde, is er iemand gaan zoeken. Nu niet het doen of er continu nagezocht wordt.Door Anoniem:
Hoe het met de reguliere releases zit weet ik niet, voor 24.04 LTS stond de 'foute' release op de planning maar is daar inmiddels uitgehaald. Eea op basis van de nu bekende gegevens, in de aanname dat de oudere releases wel goed zijn...
https://discourse.ubuntu.com/t/xz-liblzma-security-update/43714
Bedankt voor de info!Door Anoniem: Als ik mij niet vergis, dan is in Linux Ubuntu 22.04.4 LTS wel XZ geïnstalleerd (volgens Synaptic Pakketbeheer), maar zo te zien is deze XZ-versie niet voorzien van de gevonden backdoor.
Als mijn conclusie klopt, dan hoeft deze distro niet te worden bijgewerkt. Hoe het met de andere Ubuntu versies zit, weet ik op dit moment niet. Daar zou dus ook afzonderlijk naar gekeken moeten worden.
Als mijn conclusie klopt, dan hoeft deze distro niet te worden bijgewerkt. Hoe het met de andere Ubuntu versies zit, weet ik op dit moment niet. Daar zou dus ook afzonderlijk naar gekeken moeten worden.
Hoe het met de reguliere releases zit weet ik niet, voor 24.04 LTS stond de 'foute' release op de planning maar is daar inmiddels uitgehaald. Eea op basis van de nu bekende gegevens, in de aanname dat de oudere releases wel goed zijn...
https://discourse.ubuntu.com/t/xz-liblzma-security-update/43714
Er wordt al van 'state sponsored attack' gesproken. Probleem is dat er eerst een volledig onderzoek moet komen hoe eventueel deze Backdoor precies erin is gekomen, en of later de vraag kan worden beantwoord of er een APT van een of ander land achter zou kunnen zitten. Maar afgezien daarvan, is het goed dat er mensen zijn die de code natrekken. Zonder hen zouden we nu een behoorlijke kwetsbaarheid in onze Linux distro's hebben!
01-04-2024, 22:55 door
Anoniem
Door Anoniem:
Gevoel was hier , zo te lezen, meer 'aannamelijke speculatie'.
Maar het is maar net een klein trapje slechter dan "ik meen ergens gelezen te hebben" als raadgever.
Kom op - om serieus conclusies te trekken moet je wat exacter paraat hebben waar je informatie vandaan komt, en of het op z'n minst aannemelijk is dat die plek een solide bron is. Als iemand iets uit gevoel zegt vertaal jij dat direkt naar serieuse conclusies. Jij moet vaker vastlopen.
"I read it on the Internet ..."
- de vulnerability is niet een authenticatie omzeiling maar een 'remote code execution'.
- een van de backdoor voorziene sshd saved het public key deel van een speciaal aangemaakt openssl certificaat/rsa key als een executable en runt dat met root privileged. Waarvoor het inloggen niet eens hoeft te lukken.
- een kwetsbare sshd kan dus door iedereen die weet hoe de backdoor werkt gebruikt worden om willekeurig wat met root privileges te runnen.
- daarna is het systeem dus niet meer te vertrouwen.
In dit geval heb ik dit ook gelezen. Waarschijnlijk deze https://bsky.app/profile/filippo.abyssdomain.expert/post/3kowjkx2njy2b , waar de redactie naar linkte.
Note dat dit een verhaal 'uit de tweede hand' is - Valsorda zegt dat hij repost van 'mensen die aan het reverse engineeren zijn' .
nitpicktje : niet 'iedereen die weet hoe de backdoor werkt' , m.i. ,maar iedereen die de magische secret key heeft .
Waarschijnlijk een geheime dienst. Misschien niet eens 'Jia Tan' , om de backdoor te plaatsen hoeft die niet de sleutel te hebben, alleen de pubkey ervan.
Hier is iemand behoorlijk goed bezig met reverse analyseren.
https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9f504
analyse van de backdoor-insertion tijdens het builden.
https://gynvael.coldwind.pl/?lang=en&id=782
(take note - dit deel was open source ! )
cartoon versie van timelines
https://twitter.com/fr0gger_/status/1774342248437813525
Gevoel is ook een hele goeie raadgever in security zaken heb ik ervaren. Met autisten alleen kom je er niet.Door Anoniem:
Lijkt mij een voorbarige conclusie van NCSC. Mijn gevoel zegt dat alleen die maintainer toegang heeft met zijn private key omdat er waarschijnlijk een public key in die testbinary zit.
'Gevoel' lijkt me een gevaarlijke raadgever in security zaken ;-)
Ik meen ergens gelezen te hebben dat:
Lijkt mij een voorbarige conclusie van NCSC. Mijn gevoel zegt dat alleen die maintainer toegang heeft met zijn private key omdat er waarschijnlijk een public key in die testbinary zit.
'Gevoel' lijkt me een gevaarlijke raadgever in security zaken ;-)
Ik meen ergens gelezen te hebben dat:
Gevoel was hier , zo te lezen, meer 'aannamelijke speculatie'.
Maar het is maar net een klein trapje slechter dan "ik meen ergens gelezen te hebben" als raadgever.
Kom op - om serieus conclusies te trekken moet je wat exacter paraat hebben waar je informatie vandaan komt, en of het op z'n minst aannemelijk is dat die plek een solide bron is. Als iemand iets uit gevoel zegt vertaal jij dat direkt naar serieuse conclusies. Jij moet vaker vastlopen.
"I read it on the Internet ..."
- de vulnerability is niet een authenticatie omzeiling maar een 'remote code execution'.
- een van de backdoor voorziene sshd saved het public key deel van een speciaal aangemaakt openssl certificaat/rsa key als een executable en runt dat met root privileged. Waarvoor het inloggen niet eens hoeft te lukken.
- een kwetsbare sshd kan dus door iedereen die weet hoe de backdoor werkt gebruikt worden om willekeurig wat met root privileges te runnen.
- daarna is het systeem dus niet meer te vertrouwen.
In dit geval heb ik dit ook gelezen. Waarschijnlijk deze https://bsky.app/profile/filippo.abyssdomain.expert/post/3kowjkx2njy2b , waar de redactie naar linkte.
Note dat dit een verhaal 'uit de tweede hand' is - Valsorda zegt dat hij repost van 'mensen die aan het reverse engineeren zijn' .
nitpicktje : niet 'iedereen die weet hoe de backdoor werkt' , m.i. ,maar iedereen die de magische secret key heeft .
Waarschijnlijk een geheime dienst. Misschien niet eens 'Jia Tan' , om de backdoor te plaatsen hoeft die niet de sleutel te hebben, alleen de pubkey ervan.
Hier is iemand behoorlijk goed bezig met reverse analyseren.
https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9f504
analyse van de backdoor-insertion tijdens het builden.
https://gynvael.coldwind.pl/?lang=en&id=782
(take note - dit deel was open source ! )
cartoon versie van timelines
https://twitter.com/fr0gger_/status/1774342248437813525
02-04-2024, 11:40 door
Anoniem
Door Joep Lunaar: Mogelijk helpt het dat veel toepassingen tegenwoordig in een container of sandbox draaien
Dit debacle met XZ Utils toont opnieuw aan dat de beveiliging van de Linux desktop en server omgeving verouderd is:
Linux still follows [the traditional application security model], and as such, there is no resemblance of a strong sandboxing architecture or permission model in the standard Linux desktop — current sandboxing solutions are either nonexistent or insufficient. All applications have access to each other’s data [...].
https://madaidans-insecurities.github.io/linux.html#sandboxing
Volgens de auteur(s) van bovenstaande kritiek doen we er beter aan om GrapheneOS en QubesOS te omarmen.
02-04-2024, 11:58 door
Anoniem
Door Anoniem:
Dit debacle met XZ Utils toont opnieuw aan dat de beveiliging van de Linux desktop en server omgeving verouderd is:
https://madaidans-insecurities.github.io/linux.html#sandboxing
Volgens de auteur(s) van bovenstaande kritiek doen we er beter aan om GrapheneOS en QubesOS te omarmen.
Dit XZ probleem is niet technisch op te lossen maar gaat over vertrouwen en omkoping.Door Joep Lunaar: Mogelijk helpt het dat veel toepassingen tegenwoordig in een container of sandbox draaien
Dit debacle met XZ Utils toont opnieuw aan dat de beveiliging van de Linux desktop en server omgeving verouderd is:
Linux still follows [the traditional application security model], and as such, there is no resemblance of a strong sandboxing architecture or permission model in the standard Linux desktop — current sandboxing solutions are either nonexistent or insufficient. All applications have access to each other’s data [...].
https://madaidans-insecurities.github.io/linux.html#sandboxing
Volgens de auteur(s) van bovenstaande kritiek doen we er beter aan om GrapheneOS en QubesOS te omarmen.
02-04-2024, 16:59 door
Anoniem
Door Anoniem:
Gevoel is ook een hele goeie raadgever in security zaken heb ik ervaren. Met autisten alleen kom je er niet.
Gevoel is ook een hele goeie raadgever in security zaken heb ik ervaren. Met autisten alleen kom je er niet.
Je hoeft geen autist te zijn, gewoon een beetje professioneel in het bijhouden van informatie bronnen en de kwaliteit ervan scheelt een hoop .
Het geldt eigenlijk voor elk vak, als je daarin wat verder wilt komen.
05-04-2024, 10:06 door
Anoniem
Door Anoniem:
Door Anoniem: Volgens de auteur(s) van bovenstaande kritiek doen we er beter aan om GrapheneOS en QubesOS te omarmen.
Dit XZ probleem is niet technisch op te lossen maar gaat over vertrouwen en omkoping.Wat niet wegneemt dat de Security by Isolation benadering de lat voor criminelen en statelijke actoren veel hoger legt.
Reageren
Ondersteunde bbcodes
Bold: [b]bold text[/b]
Italic: [i]italic text[/i]
Underline: [u]underlined text[/u]
Quote: [quote]quoted text[/quote]
URL: [url]https://www.security.nl[/url]
Config: [config]config text[/config]
Code: [code]code text[/code]
Je bent niet ingelogd en reageert "Anoniem". Dit betekent dat Security.NL geen accountgegevens (e-mailadres en alias) opslaat voor deze reactie. Je reactie wordt niet direct geplaatst maar eerst gemodereerd. Als je nog geen account hebt kun je hier direct een account aanmaken. Wanneer je Anoniem reageert moet je altijd een captchacode opgeven.
IT Security Officer
Utrecht heeft jou nodig! Als Information Security Officer vertaal je beleid naar technische uitvoering. Dit is cruciaal voor het waarborgen van de informatiebeveiliging van onze inwoners. Je krijgt de kans om betrokken te zijn bij complexe projecten met de nieuwste technologieën en kunt jouw stempel drukken op innovatie. Solliciteer nu!
Ketenregisseur Gedigitaliseerde Criminaliteit en Cybercrime
Ben jij er klaar voor om de leiding te nemen in het bevorderen van de regionale samen-werking in de strijd tegen gedigitaliseerde criminaliteit en cybercrime? Samen met collega's, politie en regionale en landelijke partners? Dan is de dynamische rol van Ketenregisseur Gedigitaliseerde Criminaliteit en Cybercrime bij het Regionaal Samenwerkingsverband Integrale Veiligheid (RSIV) jouw op het lijf geschreven!
Digital Designer
Ben jij een Grafisch vormgever, UI-designer, Game-artist of gewoon een ‘self-proclaimed creative genius’, die op zoek is naar een leuke en uitdagende baan waarin je al je creativiteit kwijt kan?Je werkt samen met onze developers en UI/UX-designer aan onze Gamified Cybersecurity Challenges welke jij voorziet van de mooiste designs.
Senior Full Stack Developer
Als full stack developer bij Certified Secure maak je de mooiste cybersecurity challenges die onze deelnemers wereldwijd uitdagen en inspireren. Alle challenges zijn gebaseerd op actuele kwetsbaarheden, je komt dus telkens nieuwe technieken tegen, van machine learning tot web assembly, van Swift UI tot GCP.