Nieuws
image

Dirty Frag-lek in Linux maakt lokale aanvaller root op meeste distributies

vrijdag 8 mei 2026, 10:53 door Redactie, 38 reacties
Laatst bijgewerkt: 08-05-2026, 11:43

Een nieuwe kwetsbaarheid in Linux met de naam Dirty Frag maakt lokale aanvallers op meeste distributies root. Volgens de ontdekker van het probleem zijn er nog geen updates beschikbaar. Op Hacker News melden lezers dat het erop lijkt dat er inmiddels fixes voor de Linux-kernel zijn verschenen. Dirty Frag combineert twee verschillende kernel-kwetsbaarheden waardoor het mogelijk is om in het geheugen systeembestanden aan te passen. Een lokale aanvaller kan hierdoor zijn rechten naar die van root verhogen. Het probleem raakt vooral multi-tenant Linux omgevingen en shared-kernel containers.

De kwetsbaarheid lijkt op de recent ondekte Copy Fail-kwetsbaarheid. Dit beveiligingslek was ook de reden voor onderzoeker Hyunwoo Kim om zijn onderzoek te doen. Copy Fail bevindt zich in de algif_aead module van de Linux-kernel. Systemen die maatregelen tegen Copy Fail hebben genomen zijn nog steeds kwetsbaar voor Dirty Frag, zo stelt de onderzoeker, omdat zijn aanval niet vereist dat de kwetsbare algif_aead module beschikbaar is. De Dirty Frag-aanval succesvol is getest op Ubuntu 24.04.4, RHEL 10.1, openSUSE Tumbleweed 7.0.2, CentOS Stream 10, AlmaLinux 10, Fedora 44.

Kim merkt op dat het embargo over de bekendmaking van de kwetsbaarheid is geschonden. Daarop heeft hij besloten de details en proof-of-concept exploitcode te publiceren. Patches zijn echter voor nog geen enkele distributie beschikbaar, aldus de onderzoeker. Die adviseert gebruikers om de modules waarin de twee kwetsbaarheden aanwezig zijn te verwijderen en de page cache op te schonen. Op Hacker News melden lezers dat erop lijkt dat voor de verschillende Linux-kernels inmiddels fixes zijn verschenen.

Reacties (38)
Reageer met quote
08-05-2026, 11:06 door Anoniem
Ernstig lek.
En die Linux machines hebben natuurlijk ook vaak geen malware scanner, dus die komen er nooit achter of ze gehacked zijn.
Reageer met quote
08-05-2026, 11:09 door Anoniem
Tijd dat ze zich eens druk gaan maken om Python. Ik breek met Python installed uit elke useraccount. Iedereen met een beetje kennis van zaken weet dit.

Wat gaan ze daar tegen doen? Want dat is al decennia zo....
Reageer met quote
08-05-2026, 11:24 door Anoniem
Geef je persoonlijke priveleven niet
weg aan de TPM2.0,angst is niet de weg,
om toch maar weer windows te gebruiken.

Wereld2026
Reageer met quote
08-05-2026, 11:26 door Anoniem
Net zoals bij de copy fail aanval moet je PC al fysiek gecompromiteerd zijn. (In slechte handen)
Juist om deze reden en meer gebruik ik LUKS full-disk versleuteling.
Reageer met quote
08-05-2026, 11:50 door Anoniem
Het probleem raakt vooral multi-tenant Linux omgevingen en shared-kernel containers.
Ook hier geldt Linux desktop of workstation is niet kwetsbaar omdat je de enige gebruiker bent en je geen externe dienst levert.
Reageer met quote
08-05-2026, 11:51 door Anoniem
Als je het dirty flag linkje in het artikel volgt, zie je oa. een update melding.


2026-05-08 Update:

The xfrm-ESP Page-Cache Write vulnerability has been assigned CVE-2026-43284 and patched in mainline.

The RxRPC Page-Cache Write vulnerability has been reserved as CVE-2026-43500 for tracking; no patch exists in any tree yet.
Reageer met quote
08-05-2026, 11:52 door Anoniem
Door Anoniem: Net zoals bij de copy fail aanval moet je PC al fysiek gecompromiteerd zijn. (In slechte handen)
Juist om deze reden en meer gebruik ik LUKS full-disk versleuteling.
Of er moet low priviledged malware op draaien?
Reageer met quote
08-05-2026, 11:53 door Anoniem
Als je de esp4, esp6 en rxrpc modules uitschakelt ben je ook veilig. Dit kan door ze uit de kernel te halen of door de modules niet te laten laden.
Reageer met quote
08-05-2026, 11:55 door tuxick
Door Anoniem: Tijd dat ze zich eens druk gaan maken om Python. Ik breek met Python installed uit elke useraccount. Iedereen met een beetje kennis van zaken weet dit.

Wat gaan ze daar tegen doen? Want dat is al decennia zo....
Het is niet de schuld van python.
Reageer met quote
08-05-2026, 11:57 door Anoniem
Wat ik niet helemaal begrijp is dat dit 8 dagen geleden aan de kernel maintainers is gemeld en het nu al op gepubliceerd is.
Wie heeft nu eigenlijk het embargo over de bekendmaking van de kwetsbaarheid geschonden?
Reageer met quote
08-05-2026, 12:09 door Anoniem
Door Anoniem: Ernstig lek.
En die Linux machines hebben natuurlijk ook vaak geen malware scanner, dus die komen er nooit achter of ze gehacked zijn.
Klopt, malware scanners zijn namelijk zelf meestal het probleem ivm admin rechten. Beter is zo iets als https://www.redhat.com/en/lightspeed
Reageer met quote
08-05-2026, 12:17 door Anoniem
Door Anoniem: Wat ik niet helemaal begrijp is dat dit 8 dagen geleden aan de kernel maintainers is gemeld en het nu al op gepubliceerd is.
Wie heeft nu eigenlijk het embargo over de bekendmaking van de kwetsbaarheid geschonden?
Iemand is boos geweest. Dat gebeurd vaker. Zie ook deze waar ik net over verbaasd was: https://www.forbes.com/sites/daveywinder/2026/04/08/1-billion-microsoft-users-warned-as-angry-hacker-drops-0-day-exploit/
Reageer met quote
08-05-2026, 12:35 door Anoniem
Door Anoniem: Ernstig lek.
En die Linux machines hebben natuurlijk ook vaak geen malware scanner, dus die komen er nooit achter of ze gehacked zijn.

Ja, Een ernstig lek als de aanvaller achter m'n computer zit. Inderdaad... Ik schop die aanvaller dan zo lek dat hij nooit meer zonder mijn toestemming m'n huis binnenkomt.

Dus doe niet zo druk met je "ernstig lek". Allemachtig! In de titel van het bericht kon je al lezen dat het een lokale aanvaller moet zijn die dat lek exploiteert. Dus inderdaad, iemand die met zijn gat op mijn bureaustoel zit!

Overigens:
Het zal me niets verbazen als de opmerking 'ernstig' weer uit het altijd door kwetsbaarheden hevig geteisterde Microsoftkamp komt.

Ga je maar ernstig druk maken over 12 mei a.s. (Patch Tuesday) Op https://www.askwoody.com/ staat de waarschuwing vandaag, 8 mei, voor de zoveelste keer op 2.
(1 is het hoogste onbetrouwbaarheidsniveau)
Reageer met quote
08-05-2026, 12:53 door Anoniem
Door Anoniem: Net zoals bij de copy fail aanval moet je PC al fysiek gecompromiteerd zijn. (In slechte handen)
Juist om deze reden en meer gebruik ik LUKS full-disk versleuteling.

LUKS gaat je hier niet helpen. als iemand binnen kan komen kan hij ook root worden en dan kan je versleutelen wat je wil. de machine staat aan en dus ontsleutelt voor een root user toegankelijk.
Wel moet er al user toegang zijn wil je iets kunnen uithalen.
Reageer met quote
08-05-2026, 12:56 door Anoniem
Door Anoniem: Ernstig lek.
En die Linux machines hebben natuurlijk ook vaak geen malware scanner, dus die komen er nooit achter of ze gehacked zijn.

Waarom niet ?
Door Anoniem: Tijd dat ze zich eens druk gaan maken om Python. Ik breek met Python installed uit elke useraccount. Iedereen met een beetje kennis van zaken weet dit.

Wat gaan ze daar tegen doen? Want dat is al decennia zo....

Blijkbaar geen idee waar je het overhebt.
Dan moet je ook bash en andere shells en script talen er uit slopen. Python is niet de oorzaak van het probleem. dit kan met elke script taal gedaan worden.
Reageer met quote
08-05-2026, 12:56 door Anoniem
Door Anoniem: Net zoals bij de copy fail aanval moet je PC al fysiek gecompromiteerd zijn. (In slechte handen)
Juist om deze reden en meer gebruik ik LUKS full-disk versleuteling.
Leuk voor een desktop. Maar voor webservers heeft dit weinig nut.

Je onderschat overduidelijk copy fail
Reageer met quote
08-05-2026, 13:04 door meidoorn - Bijgewerkt: 08-05-2026, 13:04
Ja, Een ernstig lek als de aanvaller achter m'n computer zit.
Achter een computer zitten vind ik minder erg, dan er vóór zitten.. :-))
Reageer met quote
08-05-2026, 13:11 door Anoniem
Waarom heeft iedereen het over dat je fysieke toegang moet hebben of achter je desktop, laptop moet zitten...

Eveneens haalt LUKS full disk encryption niks uit als je systeem aan staan en ontgrendeld is dus alleen als uit staat heb je iets aan fde. Maar als je systeem uit staat kun je deze exploit ook niet draaien...

Linux wordt wereldwijd toch gebruikt als server? Hier maken meestal meerdere of een veelvoud aan gebruikers gebruik van en hebben dus een "lokaal" account. Dus om te zeggen dat dit niet zo kritisch is lijkt me een beetje een simplistische redenering of zie ik dit nu verkeerd?
Reageer met quote
08-05-2026, 13:21 door Anoniem
Ik gebruik Linux Ubuntu 26.4 LTS, maar daar is het lek niet aanwezig.
Reageer met quote
08-05-2026, 13:47 door Anoniem
man man man.

We hebben hier weer een stel "experts" bij elkaar.

Stroming : "het is voor mij veilig want ik doe helemaal niks ermee" .
Lekker hoor. Mijn backup CD met Windows 95 in de kast betekent dan zeker dat "Windows 95 veilig is"

En dan de misvatting dat "lokale access" betekent "moet op het fysieke toetsenbord zitten ".
Dat is toch echt om te huilen , juist voor "Unix liefhebbers" , want back in the day was het leuke sellingpoint dat je met Unix helemaal niet verplicht was om naast de computer te zitten waarop je dingen draaiden , omdat je gewoon remote kunt inloggen, volledig grafisch (X terminal/X display) .

En wat zit hier - stelletje Linux fanboys die denken dat "lokaal" betekent "persoon staat naast mijn computer".

Nee kiddo's - lokaal betekent alleen maar "user proces dat op de kwetsbare computer draait kan root-rechten verkrijgen" .

Maakt niet uit waar of hoe vaar de aanvaller zit , als die maar een user proces iets kan laten doen .
Meestal is dat een "ingelogde gebruiker" , mag gewoon via SSH zijn.

En soms is het aanvaller die de gebruiker een stukje code laat cut-pasten , zoals (zelfs) developers nog recent overkwam.
Reageer met quote
08-05-2026, 13:59 door Anoniem
Door Anoniem: Tijd dat ze zich eens druk gaan maken om Python. Ik breek met Python installed uit elke useraccount. Iedereen met een beetje kennis van zaken weet dit.
Kennelijk heb ik niet genoeg kennis van zaken, want ik weet dat niet. Heb je een link naar iemand met dat beetje kennis van zaken die het probleem beschrijft?

Dit is wat ik wel denk te weten:

Als een gebruiker een programma start dan draait dat met de rechten van die gebruiker. Een programma kan niet opeens meer dan de gebruiker kan. Als de gebruiker geen schrijfrechten heeft in systeem-directory's dan heeft een programma door die gebruiker gestart die net zo min. Als de gebruiker de bestanden in de home-directory van een andere gebruiker niet mag lezen dan mag een programma door die gebruiker gestart dat ook niet. Dat soort dingen kunnen alleen toch als er expliciet geregeld is dat het in dat geval wel kan, maar dan heb je het over bewust toegestane zaken en niet over een fout in Python.

Als je met Python uit een user-account kan breken, een rechten-escalatie dus, dan heb je het over iets dat dan in beginsel ook met een andere programmeertaal dan Python moet kunnen. Het is namelijk niet zo dat de Python-interpreter bijzondere rechten op het systeem heeft die andere programmeertalen of runtimes niet hebben.

Wat gaan ze daar tegen doen? Want dat is al decennia zo....
Als je terecht een probleem herkent en ze er al die tijd al niets aan gedaan hebben dan lijkt het wel alsof al die decennia niemand het probleem heeft gemeld en dat ze domweg niet op de hoogte zijn. Heb je er ooit een bugmelding voor gedaan?
Reageer met quote
08-05-2026, 14:03 door Anoniem
Door meidoorn:
Ja, Een ernstig lek als de aanvaller achter m'n computer zit.
Achter een computer zitten vind ik minder erg, dan er vóór zitten.. :-))

Hier de anoniem van de post waarvan je een citaat uitlicht;

Je hebt taalkundig gelijk. Letterlijk: Ik zit ook liever in een taxi waar de bestuurder voor het stuur zit dan er achter; in het dashboard of nog gekker onder de motorkap. :-)

(Taal is en blijft een wispelturig ding waar o.a strafpleiters beducht voor moeten zijn)
Reageer met quote
08-05-2026, 14:04 door _R0N_
Door Anoniem: Net zoals bij de copy fail aanval moet je PC al fysiek gecompromiteerd zijn. (In slechte handen)
Juist om deze reden en meer gebruik ik LUKS full-disk versleuteling.

Niet echt, een foute website waar je een scriptje kunt uploaden en uitvoeren is voldoende. Je moest eens weten hoeveel websites zo'n mooie upload module gebruiken.
Reageer met quote
08-05-2026, 14:06 door _R0N_
Door Anoniem: Wat ik niet helemaal begrijp is dat dit 8 dagen geleden aan de kernel maintainers is gemeld en het nu al op gepubliceerd is.
Wie heeft nu eigenlijk het embargo over de bekendmaking van de kwetsbaarheid geschonden?

Iemand heeft het embargo geschonden, dat is ook naar buiten gebracht..
Reageer met quote
08-05-2026, 15:17 door Anoniem
GrapheneOS is er bestendig tegen;
Bron:
https://discuss.grapheneos.org/d/35353-grapheneos-isnt-vulnerable-to-the-3-recent-linux-memory-logic-vulnerabilities
Reageer met quote
08-05-2026, 17:04 door Anoniem
Door Anoniem:
Door Anoniem: Ernstig lek.
En die Linux machines hebben natuurlijk ook vaak geen malware scanner, dus die komen er nooit achter of ze gehacked zijn.

Ja, Een ernstig lek als de aanvaller achter m'n computer zit. Inderdaad... Ik schop die aanvaller dan zo lek dat hij nooit meer zonder mijn toestemming m'n huis binnenkomt.

Hier een eind hout (knuppel) voor elke inbreker/indringer.
Fysieke beveiliging is ook belangrijk.
Reageer met quote
08-05-2026, 17:06 door Anoniem
Het probleem overal is dat er nog maar heel weinig Security-Untouchables zijn,
die elk bonnetje overleggen en zelf mogen beslissen.
Reageer met quote
08-05-2026, 17:07 door Anoniem
Door Anoniem: Linux wordt wereldwijd toch gebruikt als server? Hier maken meestal meerdere of een veelvoud aan gebruikers gebruik van en hebben dus een "lokaal" account. Dus om te zeggen dat dit niet zo kritisch is lijkt me een beetje een simplistische redenering of zie ik dit nu verkeerd?

Het wordt ook hier en daar als desktop gebruikt.
Reageer met quote
08-05-2026, 17:51 door Anoniem
Door Anoniem: Waarom heeft iedereen het over dat je fysieke toegang moet hebben of achter je desktop, laptop moet zitten...

Eveneens haalt LUKS full disk encryption niks uit als je systeem aan staan en ontgrendeld is dus alleen als uit staat heb je iets aan fde. Maar als je systeem uit staat kun je deze exploit ook niet draaien...

Linux wordt wereldwijd toch gebruikt als server? Hier maken meestal meerdere of een veelvoud aan gebruikers gebruik van en hebben dus een "lokaal" account. Dus om te zeggen dat dit niet zo kritisch is lijkt me een beetje een simplistische redenering of zie ik dit nu verkeerd?
Meeste LInux servers hebben vaak helemaal geen externe lokale users. Wel voor de diensten die worden gebruikt (mail, web etc). Zelfs voor de samba shares kan je niks aanroepen als lokale gebruiker. Verder lokale users voor specifieke agents zoals monitoring of backup etc. Linux terminal servers komen bijna niet voor. Het probleem raakt vooral shared-kernel containers, waar Microsoft ook druk mee is.
Reageer met quote
08-05-2026, 17:58 door Anoniem
Door Anoniem: man man man.

We hebben hier weer een stel "experts" bij elkaar.

Stroming : "het is voor mij veilig want ik doe helemaal niks ermee" .
Lekker hoor. Mijn backup CD met Windows 95 in de kast betekent dan zeker dat "Windows 95 veilig is"

En dan de misvatting dat "lokale access" betekent "moet op het fysieke toetsenbord zitten ".
Dat is toch echt om te huilen , juist voor "Unix liefhebbers" , want back in the day was het leuke sellingpoint dat je met Unix helemaal niet verplicht was om naast de computer te zitten waarop je dingen draaiden , omdat je gewoon remote kunt inloggen, volledig grafisch (X terminal/X display) .

En wat zit hier - stelletje Linux fanboys die denken dat "lokaal" betekent "persoon staat naast mijn computer".

Nee kiddo's - lokaal betekent alleen maar "user proces dat op de kwetsbare computer draait kan root-rechten verkrijgen" .

Maakt niet uit waar of hoe vaar de aanvaller zit , als die maar een user proces iets kan laten doen .
Meestal is dat een "ingelogde gebruiker" , mag gewoon via SSH zijn.

En soms is het aanvaller die de gebruiker een stukje code laat cut-pasten , zoals (zelfs) developers nog recent overkwam.
Je hebt er niet veel van begrepen. Een Linux gebruiker met een laptop staat geen gebruikers van buiten toe (ook niet default via ssh want dat staat verstandig alleen aan als je het nodig hebt) De aanvaller zal dus dan echt naast mij op de stoel moeten gaan zitten zoals een ander al zei. Hoe graag jij het ook anders wilt zien LInux != windows. Waarschijnlijk lopen windows 11 gebruikers wel risico omdat daar WSL vaak is geïnstalleerd en er van alles aan staat :)
Reageer met quote
08-05-2026, 18:03 door Anoniem
Door _R0N_:
Door Anoniem: Net zoals bij de copy fail aanval moet je PC al fysiek gecompromiteerd zijn. (In slechte handen)
Juist om deze reden en meer gebruik ik LUKS full-disk versleuteling.

Niet echt, een foute website waar je een scriptje kunt uploaden en uitvoeren is voldoende. Je moest eens weten hoeveel websites zo'n mooie upload module gebruiken.
IK draai geen website en al helemaal geen foute website op mijn laptop. Een website waar je zo maar iets willekeurig kan executeren zijn alleen maar honeypots
Reageer met quote
08-05-2026, 18:07 door Anoniem
Door Anoniem:
Door Anoniem: Linux wordt wereldwijd toch gebruikt als server? Hier maken meestal meerdere of een veelvoud aan gebruikers gebruik van en hebben dus een "lokaal" account. Dus om te zeggen dat dit niet zo kritisch is lijkt me een beetje een simplistische redenering of zie ik dit nu verkeerd?

Het wordt ook hier en daar als desktop gebruikt.
Er zijn vele servers waar veel gebruikers gebruik van maken zonder local account. Nergens voor nodig. IK weet niet hoe het zit met Linux servers die met active directory zijn ge-joind (AD users ) om files te serveren. Ik denk dat die alleen maar toegang tot files hebben en geen terminal kunnen starten (NOSHELL).
Reageer met quote
08-05-2026, 19:40 door Anoniem
Door Anoniem:
Door Anoniem:
Door Anoniem: Linux wordt wereldwijd toch gebruikt als server? Hier maken meestal meerdere of een veelvoud aan gebruikers gebruik van en hebben dus een "lokaal" account. Dus om te zeggen dat dit niet zo kritisch is lijkt me een beetje een simplistische redenering of zie ik dit nu verkeerd?

Het wordt ook hier en daar als desktop gebruikt.
Er zijn vele servers waar veel gebruikers gebruik van maken zonder local account. Nergens voor nodig. IK weet niet hoe het zit met Linux servers die met active directory zijn ge-joind (AD users ) om files te serveren. Ik denk dat die alleen maar toegang tot files hebben en geen terminal kunnen starten (NOSHELL).

Ik bedoelde: als desktop op pc of laptop (thuis)
Niet als gebruiker op een linux server (al dan niet met desktop).

Ik krijg de indruk dat in deze thread er twee belevingswerelden door elkaar lopen.
Een groep die gefocusd is op linux servers voor websites/diensten, en een groep gebruikers (bv thuis) die niets aan het web aanbieden.
Reageer met quote
08-05-2026, 19:49 door Anoniem
Door Anoniem:
Door Anoniem: Tijd dat ze zich eens druk gaan maken om Python. Ik breek met Python installed uit elke useraccount. Iedereen met een beetje kennis van zaken weet dit.
Kennelijk heb ik niet genoeg kennis van zaken, want ik weet dat niet. Heb je een link naar iemand met dat beetje kennis van zaken die het probleem beschrijft?

Dit is wat ik wel denk te weten:

Als een gebruiker een programma start dan draait dat met de rechten van die gebruiker. Een programma kan niet opeens meer dan de gebruiker kan. Als de gebruiker geen schrijfrechten heeft in systeem-directory's dan heeft een programma door die gebruiker gestart die net zo min. Als de gebruiker de bestanden in de home-directory van een andere gebruiker niet mag lezen dan mag een programma door die gebruiker gestart dat ook niet. Dat soort dingen kunnen alleen toch als er expliciet geregeld is dat het in dat geval wel kan, maar dan heb je het over bewust toegestane zaken en niet over een fout in Python.

Als je met Python uit een user-account kan breken, een rechten-escalatie dus, dan heb je het over iets dat dan in beginsel ook met een andere programmeertaal dan Python moet kunnen. Het is namelijk niet zo dat de Python-interpreter bijzondere rechten op het systeem heeft die andere programmeertalen of runtimes niet hebben.

Wat gaan ze daar tegen doen? Want dat is al decennia zo....
Als je terecht een probleem herkent en ze er al die tijd al niets aan gedaan hebben dan lijkt het wel alsof al die decennia niemand het probleem heeft gemeld en dat ze domweg niet op de hoogte zijn. Heb je er ooit een bugmelding voor gedaan?

Ik ben de schrijver van dat bericht.

Zoals door meerderen gemeld, is daar weinig aan te doen. Sommige brengen dat vriendelijk. Anders denken dat je nergens verstand van hebt.

Anyway, ik heb er zo weinig verstand van dat ik het toch maar even heb gemeld hier. Want programmeertalen installed is een security-krater. En omdat Python vrijwel overal installed is, heb je vrijwel altijd een probleem.

Zolang daar niets op gevonden wordt, ben je muizengaatjes aan het dichtstoppen terwijl de stadspoort open blijft staan met de ophaalbrug naar beneden.

Gegroet,
de Clueloze
Reageer met quote
08-05-2026, 20:06 door Anoniem
Linus Torvalds did not issue a public "meltdown" or fiery retort, but rather focused on the technical inadequacy of the affected subsystem and advocated for removing the problematic code entirely.
Here is the breakdown of his reaction based on discussions:

Blamed the AF_ALG Subsystem: Torvalds indicated that the user-space crypto API (AF_ALG)—where the flaw resides—has never been heavily used, except in exploits, and that it doesn't stand up in a modern world with AI-assisted bug discovery.

Recommends Disabling Subsystem: He advised that those in charge of Linux kernel configurations should disable all CONFIG_CRYPTO_USER_API_* options to make this, and future similar bugs, unexploitable.

Advocates for User-Space Migration: Torvalds suggested that any user-space programs relying on this API should be migrated to user-space cryptography code rather than relying on kernel-mode crypto functions
Reageer met quote
08-05-2026, 20:38 door Anoniem
Quote: "Tijd dat ze zich eens druk gaan maken om Python. Ik breek met Python installed uit elke useraccount. Iedereen met een beetje kennis van zaken weet dit."

Kun je hiervan een voorbeeld geven? Naar mijn weten is dit namelijk onmogelijk, zonder dat er bijvoorbeeld een verkeerd geconfigureerde sudo op het systeem staat. In dat geval is dus ook niet Python het probleem, maar sudo (iets wat ik overigens al sinds het bestaan zie als een kwetsbaarheid!).
Reageer met quote
Gisteren, 14:19 door Anoniem
Door Anoniem: Quote: "Tijd dat ze zich eens druk gaan maken om Python. Ik breek met Python installed uit elke useraccount. Iedereen met een beetje kennis van zaken weet dit."

Kun je hiervan een voorbeeld geven? Naar mijn weten is dit namelijk onmogelijk, zonder dat er bijvoorbeeld een verkeerd geconfigureerde sudo op het systeem staat. In dat geval is dus ook niet Python het probleem, maar sudo (iets wat ik overigens al sinds het bestaan zie als een kwetsbaarheid!).

Ik weet niet wat precies de reden is maar sinds rhel8 wordt de unversioned python command (/usr/bin/python) (for interactief gebruik) per default niet meer geïnstalleerd.
Een restricted shell zou de oplossing kunnen zijn. Zodat de the python binary specifieke versie ge-exclude kan worden.
Reageer met quote
Gisteren, 15:41 door Anoniem
Door Anoniem:
Door Anoniem: Quote: "Tijd dat ze zich eens druk gaan maken om Python. Ik breek met Python installed uit elke useraccount. Iedereen met een beetje kennis van zaken weet dit."

Kun je hiervan een voorbeeld geven? Naar mijn weten is dit namelijk onmogelijk, zonder dat er bijvoorbeeld een verkeerd geconfigureerde sudo op het systeem staat. In dat geval is dus ook niet Python het probleem, maar sudo (iets wat ik overigens al sinds het bestaan zie als een kwetsbaarheid!).

Ik weet niet wat precies de reden is maar sinds rhel8 wordt de unversioned python command (/usr/bin/python) (for interactief gebruik) per default niet meer geïnstalleerd.
Een restricted shell zou de oplossing kunnen zijn. Zodat de the python binary specifieke versie ge-exclude kan worden.
Hier kan je ook over nadenken voor een limited user: https://access.redhat.com/solutions/65822
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 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.

Zoeken
search
Certified Secure Full Stack Training 2026 Salt Road: Compromised Components