(Is dit bericht niet goed leesbaar? Bekijk dan de online versie.)

Op 15 mei 2026 zijn er 2 kwetsbaarheden in de linux kernel openbaar gemaakt: Fragnesia en ssh-keysign-pwn In de tussentijd is zijn waar nodig mitigatie maatregelen uitgevoerd en lopen de H&S platformen geen risico meer voor deze kwetsbaarheden.

De door Hosting & Streaming beheerde systemen vallen uiteen in 2 categorieen. Enerzijds de “klassieke” linux systemen. Voor deze systemen geldt dat ze of niet vulnerable waren of sinds diezelfde 15 mei mitigatie actief hebben waardoor de exploits niet werken. Anderzijds de container omgevingen, CHP en Cerberus. Deze zijn als gevolg van eerdere mitigaties niet kwetsbaar voor Fragnesia. Wel zijn ze kwetsbaar voor ssh-keysign-pwn, maar omdat die kwetsbaarheid in een containeromgeving in praktijk niets toevoegt is daar geen actie voor nodig.

Fragnesia is in geen enkele van onze omgevingen een issue, omdat eerdere mitigaties ook afdoende zijn voor Fragnesia.

De andere kwetsbaarheid (ssh-keysign-pwn) is op onze non-container platformen direct gemitigeerd.

In de tussentijd is ook Redhat met een statement gekomen:

In OpenShift Container Platform 4, this flaw is rated Low. The
default restricted-v2 Security Context Constraint (SCC) sets
allowPrivilegeEscalation: false on all pods, which causes the
kernel to ignore setuid file bits and prevents target binaries from
opening privileged files, breaking the exploit chain entirely. Under
non-default SCCs such as anyuid that permit privilege escalation,
the vulnerability is constrained by PID and mount namespace isolation
to the container's own filesystem. An attacker would only be able
to access root-owned files already within the container, not host or
cross-pod resources. In practice, containers rarely contain sensitive
root-owned files that are not already accessible to the pod user
through normal means.

Dat sluit aan bij wat we daar afgelopen week over schreven:

Voor containeromgevingen (CHP, Cerberus) is dit eigenlijk geen issue. In
containers staan i.h.a. geen “geheime” bestanden. De reden daarvoor is
eenvoudig: containers zijn vaak openbaar beschikbaar op containerhosting
websites als docker.io, dus logisch dat daar geen geheimen in staan.
Er kunnen natuurlijk door het platform wel secrets in een container
gemapped worden (denk aan database passwords voor een applicatie oid),
maar die waren toch al leesbaar voor die applicatie. Dus daar is geen
privilege escalation voor nodig. M.a.w.: daar verandert dit probleem
niets aan.

Dit betekent dat alle workloads geen risico lopen. Hoe zit het met de hosts waar die workloads op draaien? Daar schreven we vorige week dit over:

Dan blijven nog over de container hosts, dwz de host systemen waar
de containers van containerplatformen als CHP en Cerberus op draaien.
Deze hosts lopen geen direct risico, omdat willekeurige gebruikers geen
toegang hebben tot het host systeem.
We gaan onderzoeken of de mitigatie op deze systemen ook mogelijk is,
maar voor nu is het risico in onze ogen dus laag.

Uit het onderzoek is gebleken dat mitigatie in principe mogelijk is (door ptrace uit te zetten op die systemen, dwz dezelfde mitigatie als in de klassieke linux omgevingen). Maar dat het risico van het uitvoeren daarvan eigenlijk groter is dat het risico van het niet uitvoeren. Door het uitzetten van ptrace kan het gebeuren dat bepaalde clusterfunctionaliteit niet meer werkt. Dit terwijl er eigenlijk nauwelijks tot geen risico gelopen wordt als er niets gedaan wordt. Ook RedHat staat blijkbaar op dat standpunt; in alle “klassieke” Redhat producten is inmiddels een fix verschenen, met uitzonderin van… Openshift. Daar krijgt dit probleem risicoclkassificatie “Low” en status “Fix deferred”. Hier sluiten we ons bij aan.

Voor Cerberus geldt hetzelfde. Dat is EKS, dus een AWS managed Kubernetes cluster. AWS heeft daar ook nog geen fix voor uitgebracht, om dezelfde reden, nl dat dit als laag risico geclassificeerd wordt.

Team Hosting&Streaming is gedurende al het onderhoud via de normale kanalen bereikbaar. Zie de contact pagina.