~~META:
title = C2026D11: Afmelding Fragnesia en ssh-keysign-pwn root exploit acties
~~
{{htmlmetatags>
metatag-keywords=(fragnesia ssh-keysign-pwn root exploit)
metatag-og:title=(Afmelding Fragnesia en ssh-keysign-pwn root exploit acties)
metatag-og:description=(
	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.
	)
}}

====== C2026D11: Afmelding Afmelding Fragnesia en ssh-keysign-pwn root exploit acties ======
(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:
[[https://github.com/v12-security/pocs/tree/main/fragnesia|Fragnesia]]
en
[[https://github.com/0xdeadbeefnetwork/ssh-keysign-pwn|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.

====== Achtergrond ======
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
[[https://access.redhat.com/security/cve/cve-2026-46333|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.

====== Overzicht betrokken omgevingen ======
^Naam		^Wat draait erin					^Fragnesia?	|ssh-keysign-pwn^Risico ^Status	^
|CHP5		|webhosting omgeving voor omroepen en NPO teams		|Nee		|Ja		|laag	|mitigatie niet nodig	|
|Cerberus	|CHP/AWS SSO, monitoring, beheer			|Nee		|Ja		|laag	|mitigatie niet nodig	|
|PowerDNS	|PowerDNS + 2 bind slaves				|Nee		|Ja		|geen((na mitigatie))	|mitigatie is op 15 mei uitgerold	|
|netboot	|DNS, Mail, Icecast, ARLA, Monitoring, redir, backend	|Nee		|Nee		|geen	|hier hoeft (wederom) niets te gebeuren. Later dit voorjaar komt er een rondje reboots om netboot //nog// veiliger te maken op dit vlak.	|
|Proxmox	|alle on-prem VM's					|Nee		|Ja		|geen((na mitigatie))	 |mitigatie is op 15 mei uitgerold	|
|be1		|RCRS							|Nee		|Ja		|geen((na mitigatie))	 |mitigatie is op 15 mei uitgerold	|

===== Bereikbaarheid =====
Team Hosting&Streaming is gedurende al het onderhoud via de normale
kanalen bereikbaar. Zie de [[:contact|contact pagina]].