Videre til indhold 
Sikkerhedskløften Dirty Frag I Linux-kernen giver en sårbarhed lokale angribere mulighed for næsten sikkert at opnå root-rettigheder på hosting-servere, hvilket rammer både webhosting, cloud-instanser og managed servere i lige høj grad. Jeg viser, hvordan sårbarheden fungerer, hvilke distributioner der er berørt, hvor hurtigt jeg skal installere en patch, og hvilke øjeblikkelige foranstaltninger hosting-administratorer bør iværksætte nu for at Produktionssystemer for at beskytte.
Centrale punkter
- Root-risiko: Lokal udnyttelse medfører fulde rettigheder.
- Bred virkning: Gælder almindelige enterprise-distributioner og Kubernetes-workere.
- Angrebssti: En kombination af ESP/IPsec- og RxRPC-fejl i sidecachen.
- Lapper: Der er opdateringer tilgængelige, men de træder først i kraft efter genstart.
- Afhjælpning: Blokér esp4/esp6/rxrpc, og indskrænk lokal adgang kraftigt.
Hvad der ligger bag »Dirty Frag« i Linux-kernen
Dirty Frag samler to kernefejl i én Privilegieeskalering helt op til root-rettigheder: en usikker in-place-behandling i ESP/IPsec-stakken (esp4, esp6) og fejlbehæftede skrivestier i RxRPC-undersystemet. Begge dele muliggør ændringer i Side-cache af filer, der egentlig burde være beskyttet, såsom SUID-binærfiler eller konfigurationsfiler. Sårbarheden har betegnelserne CVE-2026-43284 og CVE-2026-43500 og blev offentliggjort sammen med et »proof of concept«. Vigtigt: Angriberen skal først have lokal adgang til at udføre kode, hvilket ofte er tilfældet på hosting-servere. Netop derfor kan et lille fodfæste hurtigt føre til en fuldstændig overtagelse af systemet med Rodrettigheder.
Hvorfor hosting-servere er særligt sårbare
Der findes mange på hosting-servere Indgangspunkter: svage adgangskoder, sårbare CMS-systemer, shell-adgang via værktøjer eller forkert konfigurerede tjenester. Så snart en brugerproces kører, kan udnyttelseskæden omgå rettighedsstyringen og få adgang til systemfiler i Side-cache påvirke. I multi-tenant-miljøer er der endda risiko for, at grænserne mellem klienterne brydes, fordi en enkelt kompromitteret konto kan vælte hele værten. Derudover findes der på disse systemer API-nøgler, certifikater og database-adgangsoplysninger, som bliver synlige efter en eskalering. Jeg ser derfor en særlig høj risiko for shared hosting, build-workere, offentlige applikationsservere og Kubernetes-workere Risikoprofil.
Den tekniske fremgangsmåde ved angrebet i enkle trin
En lokal angriber starter med en bruger uden privilegier Bruger på serveren, f.eks. via en webshell eller en konto, der allerede er blevet kompromitteret. Ved hjælp af »Dirty Frag« tvinger han skriveadgang til cachesider, der hører til filer med særlige rettigheder. Derefter manipulerer han f.eks. en SUID-binærfil eller en konfiguration, så der ved næste opkald Kode kører med udvidede rettigheder. Derefter deaktiverer den sikkerhedsindstillinger eller udskifter binære filer for at opnå persistens. Til sidst spreder den sig horisontalt, stjæler loginoplysninger og får adgang til yderligere systemer i datacentret eller cloud-VPC’en, indtil den har inficeret hele Omgivelser kontrolleret.
Berørte distributioner, containere og cloud-instanser
De berørte kernekomponenter har i årevis været en del af store Distributioner: Ubuntu (inklusive LTS), Debian, RHEL, AlmaLinux, Rocky Linux, CentOS Stream, Fedora, openSUSE Tumbleweed og Amazon Linux. Container-workloads er ligeledes udsat for risiko, hvis værtskernelen er sårbar, da containere bruger kernelen dele. Kubernetes-klynger bliver derfor et mål, især worker-noderne, hvor der kører mange forskellige arbejdsbelastninger. Også CI/CD-runners, build-servere og VPN-gateways, der bruger IPsec, øger risikoen. Jeg vurderer systemer, hvor der køres ikke-betroet kode, som Prioritet 1.
Patch-status og realistiske tidsplaner
Mange distributioner leverer allerede opdaterede Kernen-pakker, men beskyttelsen træder først i kraft efter en genstart. Der findes generelle rettelser til CVE-2026-43284, mens der for CVE-2026-43500 i nogle tilfælde opstår forsinkelser, hvilket kræver midlertidige løsninger. Jeg planlægger derfor trinvise vedligeholdelsesvinduer, tjekker afhængigheder som IPsec eller RxRPC og verificerer derefter den kørende Version. En velorganiseret styring af opdateringer og genstarter mindsker risikoen hurtigt og på en overskuelig måde. Hvis man ønsker at strukturere sine arbejdsgange, kan man starte pragmatisk med dette Vejledning i sikkerhedsopdateringer.
Sådan undersøger jeg, om et system er sårbart
Jeg starter pragmatisk med en statusopgørelse: kerneversion, indlæste moduler og eventuelle afhængigheder. I store miljøer automatiserer jeg disse kontroller via Inventory/CM-værktøjer, mens det på enkeltstående servere er nok med få kommandoer.
# Registrer kerneversion og distributionspakke
uname -r
rpm -q kernel || dpkg -l | grep -E 'linux-(image|kernel)'
# Er der indlæste sårbare moduler?
lsmod | egrep '^(esp4|esp6|rxrpc)\b'
# Kontroller brug af IPsec/XFRM (kan være harmløst, men tjener til klassificering)
ip xfrm state 2>/dev/null
ip xfrm policy 2>/dev/null
# Kan RxRPC/kAFS genkendes?
ss -xa | grep -i rxrpc || true
I Kubernetes-miljøer tildeler jeg kernelversioner til worker-rollerne via en node-liste og sikrer, at særligt udsatte noder (build-/job-runners, offentligt tilgængelige workloads) prioriteres først sikret blive.
Midlertidige løsninger uden genstart
Indtil alle systemer er genstartet, blokerer jeg målrettet Moduler esp4, esp6 og rxrpc via Modprobe-blacklisten og aflader dem, hvis de er aktive. Først tjekker jeg med lsmod, om komponenterne er indlæst, og vurderer konsekvenserne for IPsec-forbindelser eller kAFS/RxRPC-tjenester. Samtidig styrker jeg SSH-sikkerheden: kun login med nøgle, intet login med adgangskode, valgfrit 2FA for særligt følsom Administratoradgang. Derudover begrænser jeg lokal shell-adgang for konti uden privilegier og reducerer rettigheder i henhold til princippet om mindst mulig privilegering. Samtidig holder jeg øje med tegn som nye SUID-filer, mistænkelige processer eller usædvanlige binære ændringer i skrivbare stier for at opdage mistænkelige Prøve anerkende tidligt.
Konkrete afbødende foranstaltninger (uden driftsstop, hvor det er muligt)
Jeg sikrer systemet på kort sigt på tre niveauer: kernemoduler, netværksniveau og brugerkonti. I den forbindelse dokumenterer jeg hver eneste ændring, så den senere kan fortrydes, når patchen er installeret uden problemer.
- Sæt moduler på sortlisten og fjern dem (kun hvis afhængighederne er afklaret):
# Opret blacklist-fil
printf "blacklist esp4\nblacklist esp6\nblacklist rxrpc\n" | sudo tee /etc/modprobe.d/dirtyfrag-blacklist.conf
# Afmonter allerede indlæste moduler (kan mislykkes, hvis de er i brug)
sudo rmmod rxrpc 2>/dev/null || true
sudo rmmod esp6 2>/dev/null || true
sudo rmmod esp4 2>/dev/null || true
# Sikre persistens for Initramfs (vær opmærksom på distributionen)
sudo update-initramfs -u || sudo dracut -f
# Kontroller, at modulerne ikke indlæses fremover
modprobe -n esp4; modprobe -n esp6; modprobe -n rxrpc
- Blokering af ESP på netværksniveau (hvis IPsec ikke anvendes i produktionsdrift):
# nftables (foretrukket)
sudo nft add table inet filter
sudo nft add chain inet filter input { type filter hook input priority 0\; }
sudo nft add rule inet filter input meta l4proto 50 drop # ESP = 50
sudo nft add rule inet filter input ip6 nexthdr 50 drop
# Valgfrit også på Output/Forward på samme måde
# iptables (ældre version)
sudo iptables -A INPUT -p 50 -j DROP
sudo ip6tables -A INPUT -p 50 -j DROP
- Sikring af SSH og lokale konti:
# Kun login med nøgle
sudo sed -i 's/^#\?PasswordAuthentication.*/PasswordAuthentication no/' /etc/ssh/sshd_config
sudo systemctl reload sshd
# Deaktiver interaktive shell-miljøer for servicebrugere
sudo usermod -s /usr/sbin/nologin
Jeg vil gerne understrege: Disse foranstaltninger er midlertidigt. Når udrulningen af opdateringerne og genstarterne er fuldført, ophæver jeg spærringerne, i det omfang det er driftsmæssigt nødvendigt.
Overvågning og kriminalteknik: Hvad jeg overvåger
Da Dirty Frag fremmer ændringer af følsomme filer via sidecachen, fokuserer jeg min overvågning på filintegritet, SUID-ændringer og usædvanlig procesaktivitet.
- Registrere ændringer i SUID/SGID:
# Hurtig grundlæggende scanning
sudo find / -xdev -type f -perm -4000 -printf '%p %u:%g %m\n' 2>/dev/null
# Kontroller pakkeintegritet (vær opmærksom på distributionen)
rpm -Va 2>/dev/null | grep '^..5' || true
sudo debsums -s 2>/dev/null || true
- Revisionsregler for binære ændringer (hvis auditd er aktivt):
sudo auditctl -w /usr/bin -p wa -k bin-change
sudo auditctl -w /usr/sbin -p wa -k bin-change
sudo auditctl -a always,exit -F arch=b64 -S chmod,fchmod,fchmodat -k perm-change
I logfilerne søger jeg efter mislykkede modulindlæsninger, XFRM/ESP-hændelser og pludselige ændringer i kapaciteter. I mistænkelige tilfælde sikrer jeg flygtige artefakter (åbne filer, hukommelsesudtræk), inden jeg tager systemet af nettet og følger procedurerne i incident-playbooket analysere.
Hardening af container- og Kubernetes-workloads
I klyngemiljøer bruger jeg seccomp-profiler for at begrænse kritiske systemkald (f.eks. AF_KEY, AF_RXRPC, XFRM-Netlink). Samtidig tvinger jeg AppArmor eller SELinux til at køre i enforcing-tilstand, så brud på sikkerhedspolitikken straks stoppes. Følsomme arbejdsbelastninger indkapsler jeg i højere grad og isolerer Navnerum og adskiller build-workere strengt fra produktions tjenester. Adgangskontrollere håndhæver sikkerhedsprofiler, mens logning og målinger rapporterer om usædvanlig aktivitet på noderne. På worker-noder med ekstern kode planlægger jeg at installere opdateringer helt først, da det er her, den største eksponering.
Eksempler på politikker for pods (i praksis)
Her viser jeg et minimalt SecurityContext-grundlag, der egner sig godt som standard for generiske arbejdsopgaver:
apiVersion: v1
kind: Pod
metadata:
name: hardened-pod
spec:
securityContext:
seccompProfile:
type: RuntimeDefault
containers:
- name: app
image: your-registry/your-image:tag
securityContext:
allowPrivilegeEscalation: false
capabilities:
drop: ["ALL"]
runAsNonRoot: true
readOnlyRootFilesystem: true
Derudover konfigurerer jeg PodSecurityAdmission (eller politikker via Admission-Controller) således, at privilegerede pods kun starter i klart definerede navnerum. Jeg fravælger deling af værts-namespaces (hostPID, hostNetwork), medmindre det er udtrykkeligt nødvendigt. Dermed mindskes risikoen for, at et container-exploit direkte påvirker værtskontekster griber ind.
Vedligeholdelsesvinduer, genstarter og Canary-udrulninger
Beskyttelsen træder først i kraft, når den opdaterede kerne er genstartet. Derfor planlægger jeg en gradvis Vedligeholdelsesvindue med fokus på tilgængelighed:
- Canary-gruppen: Jeg udvælger repræsentative servere for hver platform, installerer opdateringer og genstarter dem først der, og overvåger målinger og logfiler.
- Trinvis udrulning: Derefter følger produktionsklynger i bølger, hver med sundhedstjek og funktionelle smoke-tests.
- Drain & Evict (Kubernetes): Noder tømmes før genstart, og PDB’er samt replikationsantal sikrer tilgængeligheden.
- Backout-plan: Ved regressioner skifter jeg til den forrige kernel (GRUB-valg) eller ruller AMI/snapshots tilbage.
Live-patching kan overbrücke tidsrummet indtil den fuldstændige genstart, men erstatter ikke den endelige genstart, så snart alle rettelser til begge CVE’er er tilgængelige.
Forandringsledelse, kommunikation og dokumentation
Jeg behandler Dirty Frag som enhver kritisk kerneopdatering: et ordentligt ændringsbillet, risikoanalyse, testnoter og godkendelser. Det er vigtigt at holde interessenterne opdateret om Påvirkning, tidsplan og eventuelle serviceafbrydelser. Når arbejdet er afsluttet, dokumenterer jeg kerneversioner, undtagelsesregler (f.eks. IPsec-undtagelser) og fjerner midlertidige løsninger, så der ikke tekniske forpligtelser forbliver.
Typiske faldgruber i praksis
- Mitigation bryder IPsec: Blokering af ESP (Proto 50) eller aflastning af esp4/esp6 forhindrer produktive tunneler. Jeg planlægger alternative ruter eller et særskilt vedligeholdelsesvindue.
- RxRPC-afhængigheder undervurderes: Legacy-tjenester eller brug af kAFS er sjældne, men forekommer. Jeg tjekker det grundigt, før jeg fjerner rxrpc.
- Patch uden genstart: De installerede kernelpakker yder ingen beskyttelse, så længe den gamle kernel kører. Jeg kontrollerer løbende, hvilken version der kører.
- Ufuldstændig dækning: Begge CVE’er skal tages i betragtning – hvis rettelserne udgives gradvist, består den resterende risiko, indtil implementeringen er fuldført.
- Fokus på containeren, glem værten: SecurityContext styrker pods, men værtskernel er det sted, hvor angrebene kan finde sted. Jeg prioriterer altid Host-Fix.
Oversigt for hvert hosting-scenarie
For at give et hurtigt overblik opsummerer jeg risici og umiddelbare fremskridt pr. Scenarie sammen. Tabellen hjælper med at prioritere, når der er mange systemer, der skal administreres. Jeg starter med shared-hosts og worker-noder, derefter følger dedikerede servere og mindre udsatte tjenester. Efter patching tjekker jeg den aktuelle kernelversion og foretager en kort funktionstest. Jeg tager højde for eventuelle IPsec- eller RxRPC-afhængigheder, inden jeg installerer moduler permanent blokere.
| Scenarie | Den største fare | Umiddelbare tiltag | Bemærkning om risikoreduktion |
|---|---|---|---|
| Delt hosting | Adskillelsen af klienter ophæves | Patch + genstart, begrænsning af bruger-shells | esp4/esp6/rxrpc-sortlister, SUID-kontrol |
| Kubernetes-arbejder | Container med værtsrettigheder | Kernel-opdatering, tvangsmæssig aktivering af seccomp/AppArmor | Begræns AF_KEY/AF_RXRPC/XFRM |
| CI/CD-runner | Ikke-betroede build-opgaver | Hurtig patching, princippet om mindst mulig adgang | Midlertidig modulblokering |
| VPN-/IPsec-gateways | ESP/IPsec-angreb | Omhyggelig testning inden implementering | Afveje risiko mod tilgængelighed |
| Dedikerede root-servere | Fuld adgang til data | Installere opdateringer, genstarte, kontrollere audit-logfiler | Sikkerhedsoptimering af SSH og brugerkonti |
Hvorfor valget af hostingudbyder er vigtigt
En udbyder med en klar Plaster-Processer, klar kommunikation og overvågning reducerer tiden indtil afhjælpning drastisk. Jeg lægger vægt på faste vedligeholdelsesvinduer, ændringslogfiler og test af sikkerhedsopdateringer. Lige så vigtigt: fornuftige krav til sikkerhedshærdning, beredskabsplaner og et team, der aktivt håndterer afvigelser. Gennemsigtighed omkring kernelstrategier og upstream-cyklusser skaber tillid i kritiske faser. Hvis man ønsker at forstå baggrunden for opdateringspolitikken, kan man læse en kortfattet oversigt på Gamle kerneversioner i hosting og vurderer derefter sin egen Strategi.
Tjekliste til hurtig implementering
- Oversigt: Kernel-versioner, roller, IPsec-/RxRPC-afhængigheder.
- Prioritering: Værter med upålidelig kode og offentligt tilgængelige knudepunkter først.
- Aktivér afbødende foranstaltninger: Sortlist moduler, deaktiver ESP, styrk SSH-sikkerheden.
- Installation af opdateringer: Prioriter test-/Canary-hosts, derefter gradvis udrulning.
- Planlægning af genstart: Aflastning/failover, sundhedstjek, funktionstest.
- Validering: Kontroller den kørende kerne, udfør integritets- og SUID-scanninger.
- Skærp overvågningen: Auditd-regler, procesafvigelser, log-signaturer.
- Vurdering af tilbagetrækning af midlertidige løsninger efter fuld beskyttelse.
- Dokumentation: Ændringer, undtagelser, erfaringer.
Resumé: Hvad jeg laver lige nu
Jeg prioriterer Systemer med upålidelig kode, tjekker jeg patch-status og planlægger øjeblikkelige genstarter efter opdateringer. Indtil da blokerer jeg esp4, esp6 og rxrpc, flytter om nødvendigt IPsec-tunge systemer over i et separat vindue og skærper SSH-adgangen. I containere implementerer jeg seccomp samt AppArmor/SELinux og overvåger SUID-ændringer, nye binære filer og mistænkelige processer. Efter hver udrulning kontrollerer jeg version, logfiler og funktion for at fortsætte med så få regressioner som muligt. Sådan holder jeg det Risiko kan styres, indtil alle noder kører stabilt, og webapplikationer, databaser samt cloud-workloads fortsætter med at fungere pålideligt.
