{"id":184154,"date":"2026-11-05T23:41:11","date_gmt":"2026-11-05T21:41:11","guid":{"rendered":"https:\/\/prohoster.info\/blog\/news\/sshole-uyazvimost-pozvolyayushhaya-podklyuchitsya-po-ssh-bez-parolya-v-sistemah-s-musl"},"modified":"2026-11-05T23:41:15","modified_gmt":"2026-11-05T21:41:15","slug":"sshole-vulnerability-allows-passwordless-ssh-access-on-musl-based-systems","status":"publish","type":"post","link":"https:\/\/prohoster.info\/no\/blog\/news\/sshole-vulnerability-allows-passwordless-ssh-access-on-musl-based-systems","title":{"rendered":"SSHole \u2014 en s\u00e5rbarhet som tillater SSH-tilkobling uten passord i systemer med Musl","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Utviklerne av OpenSSH har publisert en n\u00f8doppdatering for OpenSSH 10.6p2, som inkluderer beskyttelse mot en kritisk s\u00e5rbarhet (CVE ikke tildelt) som har f\u00e5tt kodenavnet \u00abSSHole\u00bb og som gj\u00f8r det mulig \u00e5 omg\u00e5 autentiseringen. I systemer med Musl-biblioteket lar s\u00e5rbarheten deg koble til en bruker som ikke har et passord, ved \u00e5 angi et hvilket som helst passord som er mer enn 256 tegn langt. Problemet ber\u00f8rer Linux-distribusjoner som bruker det standard musl-biblioteket, men ikke bruker PAM (Pluggable Authentication Modules), som OpenWRT, Alpine, Buildroot og Yocto. En spesiell fare er at tilgang via passord ofte er blokkert for root-brukeren, noe som gir hvem som helst muligheten til \u00e5 koble seg til med administratorrettigheter.<\/p>\n
Feilen som f\u00f8rer til s\u00e5rbarheten ligger ikke i OpenSSH-koden, men utnyttes gjennom sshd. Gitt alvorlighetsgraden av problemet, har versjon 10.6p2 av OpenSSH tilbudt en midlertidig l\u00f8sning for \u00e5 blokkere s\u00e5rbarheten. Eierne av s\u00e5rbare systemer anbefales \u00e5 ikke vente p\u00e5 oppdateringer, men umiddelbart deaktivere passordautentisering ved \u00e5 bruke parameteren \u00abPasswordAuthentication no\u00bb i \/etc\/ssh\/sshd_config eller fullt ut deaktivere SSH. <\/p>\n
Problemet oppst\u00e5r ikke i systemer som ikke er basert p\u00e5 Linux, og i Linux-milj\u00f8er basert p\u00e5 glibc, samt i systemer som bruker PAM ved passordautentisering. En l\u00f8sning er allerede tilgjengelig i Alpine og OpenWRT.<\/p>\n
S\u00e5rbarheten er relatert til feil interaksjon mellom OpenSSH og crypt()-funksjonen fra musl. For \u00e5 beskytte mot \u00e5 finne eksisterende brukere ved \u00e5 analysere forskjeller i behandlingstidene for foresp\u00f8rslene, har OpenSSH siden 2016 brukt den vanlige prosedyren for \u00e5 sjekke passord n\u00e5r det sjekkes mot brukerkontoer uten passord: den kaller funksjonen \u00abcrypt(gitt passord, salt)\u00bb med saltet til en annen bruker som har en gyldig passordhash, og sammenligner deretter hashen returnert av crypt-funksjonen med verdien fra feltet med passordhasher.<\/p>\n
Imidlertid returnerer crypt()-funksjonen i musl for SHA-512-hasher symbolet \u00ab*\u00bb hvis lengden p\u00e5 det gitte passordet overstiger 256 byte (denne begrensningen ble innf\u00f8rt i 2012 for \u00e5 beskytte mot DoS-angrep, ettersom store verdier medf\u00f8rer stor belastning p\u00e5 CPU). Det samme symbolet brukes i feltet med passordhasher i \u00ab\/etc\/shadow\u00bb for \u00e5 indikere brukerkontoer der passordautentiseringen er blokkert. <\/p>\n
Som f\u00f8lge av angrep kan en angriper som har mulighet til \u00e5 koble seg til en SSH-server, koble seg til hvilken som helst konto der det i '\/etc\/shadow' feltet for passordet er angitt symbolet '*', ved \u00e5 sende en streng p\u00e5 mellom 257 og 1024 byte. Problemet dekker mange eksisterende Docker-bilder bygget med Alpine Linux, samt standard Alpine-bilder for skyplattformer som AWS og Azure, der brukeren root har f\u00e5tt satt symbolet '*' i stedet for passordhash. <\/p>\n