Kritieke OpenSSH-kwetsbaarheid maakt inloggen zonder wachtwoord mogelijk: beheerders moeten Linux-systemen onmiddellijk controleren

Een ernstige kwetsbaarheid in OpenSSH kan aanvallers in bepaalde Linux-omgevingen ongeautoriseerde toegang geven zonder dat zij het juiste wachtwoord kennen. Het beveiligingsprobleem, dat de naam sshole heeft gekregen, ontstaat door een onverwachte wisselwerking tussen OpenSSH en musl, een lichtgewicht C-bibliotheek die onder meer door Alpine Linux wordt gebruikt.

De kwetsbaarheid is extra zorgwekkend omdat het probleem al jarenlang in de betrokken software aanwezig is en niet beperkt blijft tot traditionele Linux-servers. Ook containers, cloudomgevingen, routers, industriële besturingssystemen en andere embedded apparaten kunnen onder bepaalde omstandigheden risico lopen.

Een aanvaller hoeft bovendien niet eerst een groot aantal wachtwoorden uit te proberen. Onder de juiste omstandigheden kan één enkele SSH-verbindingspoging voldoende zijn om de beveiliging te omzeilen. Daarmee vormt het lek een serieus risico voor systemen waarop SSH vanaf een netwerk bereikbaar is.

De kwetsbaarheid treft niet automatisch iedere Linux-installatie met OpenSSH. De daadwerkelijke risico's zijn afhankelijk van de gebruikte C-bibliotheek, de OpenSSH-configuratie en de manier waarop gebruikersaccounts en wachtwoordauthenticatie zijn ingericht.

Hoe werkt de sshole-kwetsbaarheid?

De oorzaak ligt in de manier waarop OpenSSH wachtwoorden verwerkt in combinatie met de musl-bibliotheek. Musl is een relatief compacte implementatie van de standaard C-bibliotheek en wordt onder andere gebruikt door Alpine Linux. Deze distributie is populair vanwege haar geringe omvang en efficiënte gebruik van systeembronnen.

Bij een normale SSH-aanmelding controleert OpenSSH of het ingevoerde wachtwoord overeenkomt met de wachtwoordhash die voor het betreffende gebruikersaccount is opgeslagen. Een wachtwoordhash is een cryptografische representatie van een wachtwoord. Het oorspronkelijke wachtwoord wordt daarbij niet rechtstreeks in het systeem opgeslagen.

Bij sshole gaat het mis wanneer een wachtwoord uitzonderlijk lang is. Als een aanvaller een wachtwoord invoert dat langer is dan 256 tekens, kan musl tijdens de verwerking van het wachtwoord een foutconditie bereiken.

In die situatie kan musl een asterisk (*) teruggeven als resultaat van een mislukte wachtwoordverificatie. Die asterisk heeft een bijzondere betekenis: zij kan ook voorkomen in het wachtwoordveld van een account dat niet bedoeld is om met wachtwoordauthenticatie te kunnen inloggen.

Door een onjuiste afhandeling van dit resultaat kan OpenSSH de foutieve uitkomst interpreteren alsof het ingevoerde wachtwoord overeenkomt met de opgeslagen waarde. Hierdoor kan de authenticatiecontrole worden omzeild.

Het gevolg is dat een aanvaller toegang kan krijgen tot een account waarvoor geen geldig wachtwoord bekend is.

Het gaat dus niet om het kraken van een wachtwoord, het achterhalen van een wachtwoordhash of het rechtstreeks uitlezen van opgeslagen inloggegevens. De kwetsbaarheid maakt misbruik van een fout in de verwerking en interpretatie van het resultaat van de wachtwoordcontrole.

Welke voorwaarden zijn nodig om de kwetsbaarheid te misbruiken?

Niet ieder systeem met OpenSSH en musl is automatisch kwetsbaar. Voor succesvolle exploitatie moet aan een specifieke combinatie van voorwaarden worden voldaan.

De belangrijkste voorwaarden zijn:

1. OpenSSH moet zonder PAM draaien. Pluggable Authentication Modules (PAM) is een framework waarmee Linux-systemen verschillende authenticatiemethoden en toegangsregels kunnen toepassen. De beschreven aanval is gericht op configuraties waarin OpenSSH geen gebruikmaakt van PAM.

2. Wachtwoordauthenticatie moet zijn ingeschakeld. Wanneer SSH uitsluitend gebruikmaakt van bijvoorbeeld publieke-sleutelauthenticatie en wachtwoordaanmeldingen daadwerkelijk zijn uitgeschakeld, kan deze specifieke aanvalsmethode niet worden gebruikt.

3. Het systeem moet musl gebruiken. De kwetsbaarheid heeft betrekking op de interactie tussen OpenSSH en musl. Alpine Linux is hiervan het bekendste voorbeeld, maar ook andere distributies en aangepaste Linux-omgevingen kunnen musl gebruiken.

4. Er moet een account aanwezig zijn dat wachtwoordaanmeldingen afwijst. Het betreffende account moet zo zijn ingericht dat het normaal gesproken niet met een wachtwoord toegankelijk is.

5. Daarnaast moet een ander actief gebruikersaccount beschikken over een geldige SHA-256- of SHA-512-wachtwoordhash. Deze combinatie speelt een rol bij de manier waarop de wachtwoordverificatie en de foutafhandeling verlopen.

Wanneer aan deze voorwaarden wordt voldaan, kan een aanvaller proberen de kwetsbaarheid te activeren door bij een SSH-aanmelding een uitzonderlijk lang wachtwoord in te voeren.

Een belangrijk detail is dat het niet noodzakelijk is dat het aangevallen account zelf een normaal, bruikbaar wachtwoord heeft. Juist de bijzondere accountconfiguratie en de manier waarop OpenSSH de foutuitkomst verwerkt, maken de aanval mogelijk.

Waarom is één enkele SSH-poging voldoende?

Een bijzonder gevaarlijk aspect van sshole is dat de aanval niet afhankelijk is van een langdurig proces waarbij een aanvaller duizenden wachtwoorden moet proberen.

Bij reguliere brute-forceaanvallen probeert een aanvaller systematisch verschillende wachtwoorden totdat er mogelijk een overeenkomst wordt gevonden. Bij sshole wordt juist misbruik gemaakt van de foutieve interpretatie van een mislukte wachtwoordberekening.

De aanvaller heeft in beginsel het volgende nodig:

Het gaat om wachtwoorden van ongeveer 257 tot en met 1.024 tekens. De aanvaller hoeft niet te beschikken over het oorspronkelijke wachtwoord van het doelaccount.

Een bijkomende voorwaarde is dat er op het systeem een ander account aanwezig is met een geschikte SHA-256- of SHA-512-wachtwoordhash. Deze hash is relevant omdat OpenSSH bij de verwerking van de authenticatie gebruikmaakt van gegevens uit de bestaande wachtwoordhash.

Hierdoor kan een account dat normaal gesproken uitsluitend via SSH-sleutels toegankelijk zou moeten zijn, onder bepaalde omstandigheden toch met een willekeurig lang wachtwoord worden benaderd.

Dit maakt de kwetsbaarheid bijzonder gevaarlijk voor servers waarop accounts bewust geen wachtwoordauthenticatie toestaan. De beveiligingsmaatregel die dergelijke accounts normaal gesproken beschermt, kan door de fout juist worden ondermijnd.

Welke Linux-systemen lopen risico?

Alpine Linux is het belangrijkste voorbeeld van een distributie die door de kwetsbaarheid wordt getroffen. De distributie maakt standaard gebruik van musl en biedt OpenSSH-pakketten aan die zonder PAM kunnen functioneren.

Dat betekent echter niet dat uitsluitend Alpine Linux-beheerders actie moeten ondernemen.

Ook andere Linux-omgevingen kunnen kwetsbaar zijn wanneer ze dezelfde combinatie van software en configuratie gebruiken.

Denk onder meer aan:

De kwetsbaarheid is nadrukkelijk afhankelijk van de daadwerkelijke softwareconfiguratie. Alleen het gebruik van musl is niet voldoende om een systeem kwetsbaar te maken.

Welke systemen zijn niet kwetsbaar?

Linux-systemen die gebruikmaken van glibc in plaats van musl vallen niet onder deze specifieke kwetsbaarheid. Dit geldt onder meer voor standaardinstallaties van:

Ook OpenSSH-installaties die PAM gebruiken voor de betreffende wachtwoordauthenticatie zijn niet kwetsbaar voor deze aanvalsmethode.

Daarnaast is deze specifieke kwetsbaarheid niet van toepassing op niet-Linux-systemen en op systemen die Dropbear gebruiken in plaats van OpenSSH.

Het is daarbij belangrijk om onderscheid te maken tussen een standaardinstallatie en een aangepaste omgeving. Een Linux-server kan bijvoorbeeld een distributie gebruiken die normaal gesproken glibc toepast, maar binnen een container of een afzonderlijke omgeving toch een andere C-bibliotheek gebruiken.

Een controle op basis van uitsluitend de distributienaam is daarom onvoldoende. Beheerders moeten ook nagaan welke SSH-server daadwerkelijk actief is, tegen welke C-bibliotheek deze is gebouwd en welke authenticatiemethode wordt gebruikt.

Extra risico voor containers, routers en embedded systemen

De kwetsbaarheid heeft mogelijk verstrekkende gevolgen doordat Alpine Linux en andere minimale Linux-omgevingen op grote schaal worden toegepast buiten traditionele serverinfrastructuren.

Alpine Linux is bijzonder populair bij containerplatformen, waaronder Docker-omgevingen. De kleine installatieomvang maakt de distributie aantrekkelijk voor ontwikkelaars die applicaties zo efficiënt mogelijk willen verpakken en uitvoeren.

Ook in routers, industriële controllers, netwerkapparatuur, IoT-apparaten en andere embedded systemen worden lichte Linux-omgevingen gebruikt.

Juist deze apparaten vormen een extra beveiligingsrisico. In tegenstelling tot reguliere servers krijgen embedded systemen niet altijd tijdig beveiligingsupdates. Sommige apparaten draaien jarenlang op dezelfde firmware, terwijl de fabrikant geen nieuwe versie meer beschikbaar stelt.

Daarnaast worden containers regelmatig opgebouwd vanuit bestaande basisimages. Wanneer een ontwikkelaar een oude image blijft gebruiken, kan een inmiddels gepatchte kwetsbaarheid toch opnieuw in een productieomgeving terechtkomen.

Het installeren van een update op de onderliggende host betekent bovendien niet automatisch dat alle afzonderlijke containers en apparaten eveneens zijn bijgewerkt.

Organisaties moeten daarom niet alleen hun fysieke servers controleren, maar ook hun containerimages, cloudtemplates, virtuele machines en embedded apparatuur.

Gevaar voor roottoegang en overname van systemen

De gevolgen van een succesvolle aanval zijn afhankelijk van de rechten van het account waartoe de aanvaller toegang krijgt.

Wanneer het getroffen account uitsluitend beperkte gebruikersrechten heeft, kan de directe impact relatief beperkt blijven. De aanvaller heeft dan echter wel een toegangspunt binnen het systeem en kan proberen aanvullende kwetsbaarheden of verkeerd ingestelde rechten te misbruiken.

De situatie wordt aanzienlijk ernstiger wanneer het account beschikt over beheerdersrechten of toegang heeft tot mechanismen waarmee hogere rechten kunnen worden verkregen.

Dat geldt bijvoorbeeld voor accounts die gebruik mogen maken van sudo of doas. Met deze voorzieningen kunnen gebruikers bepaalde opdrachten met verhoogde rechten uitvoeren.

Alpine Linux is in dit verband extra interessant vanuit het perspectief van aanvallers. Bepaalde cloudimages bevatten standaardaccounts die bedoeld zijn voor toegang via SSH-sleutels en die daarnaast over specifieke beheermogelijkheden beschikken.

Wanneer een aanvaller via sshole toegang krijgt tot een dergelijk account, kan dat in bepaalde configuraties de weg vrijmaken naar roottoegang.

Root is het hoogste gebruikersniveau binnen Linux. Een aanvaller die deze rechten verkrijgt, kan in beginsel vrijwel alle onderdelen van het systeem beheren.

Mogelijke gevolgen zijn onder andere:

Wanneer het systeem onderdeel is van een bedrijfsnetwerk of cloudomgeving, kan een succesvolle inbraak daardoor gevolgen hebben die veel verder reiken dan één afzonderlijke Linux-installatie.

Alpine Linux-cloudimages verdienen bijzondere aandacht

Extra aandacht is nodig voor bepaalde Alpine Linux-cloudimages die worden gebruikt bij aanbieders zoals Amazon Web Services (AWS) en Microsoft Azure.

In specifieke cloudimages zijn accounts aanwezig die bedoeld zijn voor sleutelgebaseerde authenticatie. Het wachtwoordveld van dergelijke accounts kan een asterisk bevatten, waardoor deze accounts onder de juiste omstandigheden binnen het bereik van sshole vallen.

Het risico neemt toe wanneer op hetzelfde systeem ook een ander account met een geschikte SHA-256- of SHA-512-wachtwoordhash aanwezig is.

Wanneer het getroffen account daarnaast toegang heeft tot doas of een andere methode om beheerdersrechten te verkrijgen, kan de impact zeer groot zijn.

Beheerders moeten daarom niet uitsluitend controleren of hun cloudservers de nieuwste OpenSSH-versie gebruiken. Ook de oorspronkelijke image, de aanwezige gebruikersaccounts, de authenticatie-instellingen en de toegewezen rechten moeten worden gecontroleerd.

Hetzelfde geldt voor automatisch uitgerolde servers. Een kwetsbare basisimage kan ertoe leiden dat nieuwe systemen opnieuw met dezelfde beveiligingsfout worden geïntroduceerd.

Eerste aanwijzingen voor misbruik

De kwetsbaarheid is extra zorgwekkend omdat een aanvaller in principe met één SSH-verbindingspoging kan slagen. Er hoeft dus geen lange reeks mislukte aanmeldingen zichtbaar te zijn voordat een inbraak plaatsvindt.

Securityteams kunnen daardoor niet uitsluitend vertrouwen op detectiesystemen die grote aantallen mislukte wachtwoordpogingen signaleren.

Er zijn inmiddels meldingen verschenen van daadwerkelijk misbruik van sshole. Daarbij is ook succesvolle toegang tot rootniveau op een kwetsbare testomgeving vastgesteld. Dat maakt het noodzakelijk om de kwetsbaarheid niet langer uitsluitend als een theoretisch risico te behandelen.

Beheerders wordt geadviseerd om onder meer de volgende gegevens te onderzoeken:

Een succesvolle aanmelding bij een account dat volgens de beveiligingsconfiguratie geen wachtwoordaanmeldingen mag accepteren, moet als een serieus beveiligingsincident worden onderzocht.

Wanneer een inbraak niet met voldoende zekerheid kan worden uitgesloten, is het verstandig het betreffende systeem als mogelijk gecompromitteerd te behandelen. Alleen het installeren van een beveiligingsupdate is dan niet voldoende: ook de mogelijke gevolgen van de eerdere toegang moeten worden onderzocht.

OpenSSH 10.6p2 dicht het beveiligingslek

Het OpenSSH-ontwikkelteam heeft op 5 november 2026 een noodupdate uitgebracht om de kwetsbaarheid te verhelpen. De oplossing is opgenomen in OpenSSH-versie 10.6p2.

Hoewel de oorzaak samenhangt met de manier waarop musl wachtwoordverificatie afhandelt, is ervoor gekozen om in OpenSSH een aanvullende controle in te bouwen. Daarmee wordt voorkomen dat een foutmelding van de onderliggende C-bibliotheek als een geldige wachtwoordovereenkomst wordt geïnterpreteerd.

Alpine Linux heeft daarnaast eigen beveiligingsupdates uitgebracht voor verschillende ondersteunde en oudere releasebranches. Daarbij zijn ook oudere OpenSSH-versies voorzien van de benodigde beveiligingsaanpassing. Beheerders moeten daarom niet uitsluitend kijken naar het versienummer van OpenSSH, maar ook naar de volledige pakketversie van hun Linux-distributie.

De volgende pakketversies bevatten de beveiligingsoplossing:

Ook voor oudere Alpine-installaties zijn updates beschikbaar gesteld, maar beheerders moeten rekening houden met de ondersteuningsstatus van hun distributie.

Organisaties die Alpine Linux of andere musl-gebaseerde Linux-systemen gebruiken, wordt dringend geadviseerd hun SSH-installaties te controleren en waar nodig onmiddellijk te beveiligen.

De volgende maatregelen zijn belangrijk:

1. Controleer welke C-bibliotheek wordt gebruikt

Stel vast of het systeem musl of glibc gebruikt. Controleer daarnaast of de SSH-server daadwerkelijk OpenSSH is en niet bijvoorbeeld Dropbear.

2. Controleer de SSH-authenticatieconfiguratie

Onderzoek of PAM wordt gebruikt en of wachtwoordauthenticatie is ingeschakeld. Kijk daarbij niet alleen naar de hoofdconfiguratie, maar ook naar eventuele aanvullende configuratiebestanden.

3. Installeer de beschikbare beveiliginsgsupdate

Voor Alpine Linux kan het systeem worden bijgewerkt met:

apk update
apk upgrade

Controleer vervolgens of de geïnstalleerde OpenSSH-pakketversie overeenkomt met de gepatchte versie voor de gebruikte Alpine-release.

4. Herstart de SSH-service

Een belangrijke stap die niet mag worden overgeslagen, is het opnieuw starten van de SSH-service. Het installeren van een beveiligingsupdate vervangt namelijk niet automatisch het reeds draaiende SSH-serverproces.

Op Alpine Linux kan dit met:

rc-service sshd restart

Controleer vooraf of je via een alternatieve SSH-sessie of console toegang houdt tot het systeem. Zo voorkom je dat een fout in de configuratie of herstart je buitensluit.

5. Schakel wachtwoordauthenticatie tijdelijk uit wanneer direct patchen niet mogelijk is

Wanneer een beveiligingsupdate niet onmiddellijk kan worden geïnstalleerd, kan wachtwoordauthenticatie als tijdelijke maatregel worden uitgeschakeld.

In de configuratie van OpenSSH (/etc/ssh/sshd_config) kan hiervoor de volgende instelling worden gebruikt:

PasswordAuthentication no

Daarna moet de SSH-service opnieuw worden gestart.

Deze maatregel betekent dat gebruikers via wachtwoorden niet meer kunnen inloggen. Controleer daarom eerst of sleutelgebaseerde authenticatie correct werkt. Schakel SSH desnoods volledig uit wanneer geen veilige tijdelijke configuratie mogelijk is.

6. Onderzoek bestaande en mogelijke inbraken

Controleer de authenticatielogs op verdachte succesvolle aanmeldingen. Besteed extra aandacht aan accounts die normaal gesproken geen wachtwoordaanmeldingen mogen accepteren.

Wanneer verdachte toegang wordt vastgesteld, moeten ook de gebruikersrechten, SSH-sleutels, systeemprocessen en mogelijke wijzigingen aan bestanden worden onderzocht.

Niet alleen servers, maar ook containerimages controleren

Een veelgemaakte fout bij beveiligingsupdates is dat uitsluitend de fysieke of virtuele server wordt bijgewerkt, terwijl containers en applicatieomgevingen ongemoeid blijven.

Dat is bij sshole een belangrijk aandachtspunt.

Een container kan een eigen Alpine Linux-basisimage bevatten, inclusief een eigen OpenSSH-installatie. Wanneer die image verouderd is, kan de kwetsbare software aanwezig blijven, zelfs als de host waarop de container draait volledig is bijgewerkt.

Hetzelfde probleem kan zich voordoen bij automatisch uitgerolde cloudservers en infrastructuur die via vooraf samengestelde images wordt geïnstalleerd.

Organisaties moeten daarom ook hun Dockerfiles, containerregisters, basisimages, Kubernetes-omgevingen en CI/CD-processen controleren. Verouderde images moeten opnieuw worden opgebouwd met bijgewerkte pakketten en vervolgens opnieuw worden uitgerold.

Een update op één server is dus geen garantie dat de volledige infrastructuur is beveiligd. 

Een kwetsbaarheid met gevolgen voor de gehele Linux-infrastructuur

De sshole-kwetsbaarheid laat zien hoe een relatief kleine fout in de samenwerking tussen softwarecomponenten grote gevolgen kan hebben voor de beveiliging van een compleet systeem.

OpenSSH is een van de meest gebruikte voorzieningen voor het op afstand beheren van Linux-systemen. Het wordt ingezet voor serverbeheer, geautomatiseerde processen, cloudinfrastructuren, netwerkapparatuur en industriële toepassingen. Juist omdat SSH vaak vanaf externe netwerken bereikbaar is, kan een fout in de authenticatieafhandeling een aantrekkelijk doelwit vormen voor aanvallers.

De bijzondere situatie bij sshole is dat een account dat bewust tegen wachtwoordaanmeldingen is beschermd, door een fout in de verwerking van een uitzonderlijk lang wachtwoord alsnog toegankelijk kan worden. Wanneer dat account vervolgens over beheerdersrechten beschikt, kan de impact oplopen tot volledige systeemovername.

Ook het feit dat één enkele verbindingspoging voldoende kan zijn, maakt detectie en preventie extra belangrijk. Traditionele beveiligingsmaatregelen die vooral gericht zijn op het herkennen van herhaaldelijke mislukte inlogpogingen bieden hier onvoldoende bescherming.

De belangrijkste conclusie is dat beheerders niet moeten wachten totdat er aanwijzingen voor misbruik verschijnen. Alle Linux-systemen die OpenSSH in combinatie met musl gebruiken, moeten zo snel mogelijk worden gecontroleerd. Waar de kwetsbare configuratie aanwezig is, moet de beveiligingsupdate onmiddellijk worden geïnstalleerd en moet de SSH-service opnieuw worden gestart.

Voor organisaties met Alpine Linux, embedded systemen, routers, cloudimages en containeromgevingen is het bovendien noodzakelijk om ook minder zichtbare systemen en verouderde software-installaties in de inventarisatie mee te nemen. Een kwetsbaar apparaat dat buiten het reguliere updateproces valt, kan immers een toegangspunt vormen tot een veel groter netwerk.

Door: Drifter