OpenSSH 9.8 lost kritieke rce-kwetsbaarheid op

OpenSSH lost een kritieke kwetsbaarheid op die remote code execution mogelijk maakt. De kwetsbaarheid treft versies 8.5p1 tot en met 9.7p1. De beveiligheidsfout werd ontdekt door onderzoekers van de Qualys Threat Research Unit in op glibc gebaseerde Linux-systemen.

De kwetsbaarheid wordt bijgehouden als CVE-2024-6387 en draagt de naam 'regreSSHion' omdat het gaat om een regressie van een eerder gepatchte kwetsbaarheid uit 2006, die werd bijgehouden als CVE-2006-5051. Meer dan 14 miljoen systemen zouden risico lopen door de kwetsbaarheid. De Qualys-onderzoekers raden gebruikers dan ook aan om zo snel mogelijk de nieuwste patches uit te voeren voor OpenSSH.

Onderzoekers van Qualys ontdekten dat het OpenSSH-serverproces wordt beïnvloed door een race condition waardoor kwaadwillenden op afstand niet-geverifieerde code konden uitvoeren met rootrechten. Exploitatie van de kwetsbaarheid is volgens de onderzoekers lastig, maar kan in principe leiden tot volledige systeemovername, waardoor onder meer malware geïnstalleerd kan worden of achterdeuren gecreëerd kunnen worden. Omdat het om een race condition gaat, zijn er wel meerdere pogingen nodig om een succesvolle aanval uit te voeren, aldus de onderzoekers.

De bug zit in versies 8.5p1 tot en met 9.7p1 van OpenSSH's sshd-implementatie, specifiek op Linux-systemen die op de GNU C Library of glibc zijn gebaseerd. OpenSSH heeft de bug gerepareerd in versie 9.8, die inmiddels ook op grote distro's als Ubuntu is doorgevoerd. Gebruikers die de tool niet kunnen bijwerken, kunnen de kwetsbaarheid mitigeren door de waarde 0 toe te kennen aan LoginGraceTime in /etc/ssh/sshd_config. Dit veroorzaakt een tijdelijke denial-of-service die de code-uitvoering voorkomt.

Reacties (61)

[CH4OS]

Wat het Tweakers artikel niet meldt, maar wat het NCSC bijvoorbeeld wel meldt, is dat dit lek ook niet zo eenvoudig te misbruiken is. Op 32 bits systemen duurt het zo'n 6-8 uur voordat een aanvaller daadwerkelijk binnen is en meestal zijn SSH verbindingen ook niet zomaar voor de buitenwereld geopend en vaak enkel via VPN benaderbaar.

Je zult dus al binnen op het netwerk moeten zijn om bij de gemiddelde machine binnen te kunnen komen. Ook zegt het NCSC dat eea een regressie is vanuit de eerder verholpen CVE-2006-5051. Een en ander lijkt dus wel een beetje een storm in een glas water te zijn; ja het is een lek, maar hij is niet zo eenvoudig te ge- of misbruiken. Wat het NCSC zegt over het mogelijke misbruik:

Daadwerkelijk misbruik is bijzonder ingewikkeld. Een kwaadwillende moet voor langere tijd connectiepogingen onderhouden. In een laboratoriumopstelling van de onderzoekers vereiste dat verbindingen van 6-8 uur, op 32-bit systemen. Theoretisch is het mogelijk om de kwetsbaarheid te misbruiken op 64-bit gebaseerde systemen, maar dat is nog niet aangetoond. Actief, grootschalig misbruik is hiermee dus onwaarschijnlijk.

Het lijkt er dus op, dat de impact zich alleen beperkt tot 32 bits systemen.

[Reactie gewijzigd door CH4OS op 22 juli 2024 18:02]

[Jerie]

Je zult dus al binnen op het netwerk moeten zijn om bij de gemiddelde machine binnen te kunnen komen.

Nee hoor, er hangen zat SSH servers op het internet. Kun je zo vinden via Shodan.

NCSC biedt gewoon een nette vertaling aan van wat de OpenSSH devs op hun website hebben gepost.

Het lijkt er dus op, dat de impact zich alleen beperkt tot 32 bits systemen.

Nee, dat ligt genuanceerder. De devs zeggen het volgende:

Exploitation on 64-bit systems is believed to be
possible but has not been demonstrated at this time. It's likely that
these attacks will be improved upon.

De PoC werkt in lab omstandigheden tussen de 6 en 8 uur op 32-bit Linux systemen met glibc en ASLR enabled. Het is mij onduidelijk of dat x86-32 betreft of 32-bit systemen in het algemeen. Linux/MIPS bijvoorbeeld, heeft niet eens ASLR...

En de laatste zin van bovenstaande Engelstalige quote is toch het vriendelijke en dringende verzoek om z.s.m. te upgraden voordat derden het aan de praat hebben op een andere machine.

[crazyboy01]

Nee hoor, er hangen zat SSH servers op het internet. Kun je zo vinden via Shodan.

Wou net zeggen, cloud servers worden vaak standaard met een SSH server naar de buitenwereld geleverd en die worden vaak niet vervangen voor iets anders. Of dat onkunde of bewust wordt gedaan laat ik in het midden. Uiteraard zet ik geen poorten in mijn bedrijfsnetwerk open om zonder VPN interne SSH-servers te benaderen, maar in de cloud laat ik ze zelf ook wel eens een tijdje openlijk draaien. Uit gemak en snelheid natuurlijk. En misschien erg kort door de bocht, maar ik snap sowieso niet helemaal dat VPN's altijd als heilig worden gezien tegenover SSH, daarvoor moet ook een poort open en die kunnen toch net zo goed exploits bevatten? Ja, als ze via SSH binnenkomen kunnen ze directer dingen aanrichten, maar je hebt toch ook liever geen onbekenden in je vertrouwde VPN omgeving lijkt me.

Dank voor Shodan trouwens, best grappig - kende ik nog niet.

[Soldaatje]

Maar vpn kan ook over udp, wat weer iets lastiger is te vinden.

[Jerie]

Yep, en ook IPv6 helpt. Want Shodan e.d. kunnen de IPv4 address space snel scannen, maar IPv6 is andere koek.

[dmantione]

Ja, en je kunt je IPv6-adres verborgen houden. Mijn webserver heeft de SSH-server op een ander IP-adres draaien dan de webserver. Bij IPv4 is een IP-adres daar veel te kostbaar voor, bij IPv6 ben je gek als je het niet doet. Bovendien IPv6 privacy-extensions: Voor zijn eigen internetverkeer gebruikt hij weer een ander ip-adres. Dus als ik het ip-adres waar de SSH-server draait niet vertel, zal men het nooit vinden.

En vanzelfsprekend is de SSH-server alleen via IPv6 te bereiken. Waar bij IPv4 een SSH-server openzetten direct allerlei logs van kwaadwillenden oplevert (op zich rustig laten proberen, SSH is ervoor gemaakt), is het bij IPv6 doodse stilte op de SSH-poort.

[3raser]

Security through obscurity. Als Shodan maar lang genoeg scant vinden ze hem op den duur toch wel. De kans is een stuk kleiner maar als de server lang online blijft dan speelt de tijdfactor niet echt een rol toch?

[dmantione]

Als je de aanname doet dat het beheers-ip-adres in dezelfde prefix heeft als het zichtbare ip-adres, dan zijn er 2^80 ip-adressen om te scannen. Met 2^80 ip-adressen om te scannen is de wereld vergaan voordat Shodan hem zal vinden. Ik denk dat dit een beetje een grensgeval is tussen security-through-obscurity en security-through-design: Zeker, als je het ip-adres weet, kun je nog iets elke veiligheidszwakte uitbuiten die er is. Echter, omdat er geen realistische mogelijkheid bestaat om het ip-adres te achterhalen, wordt dat een extra veiligheidstoken dat geraden moet worden, net zoals een wachtwoord dat is.

[3raser]

Je gaat er daarmee vanuit dat jouw veilige IP adres de laatste in de lijst is. Het zou ook 1 van de eerste adressen in de range kunnen zijn waardoor hij vrij snel gescand wordt. Het is dus meer een kwestie van "toeval" dan "security". Het IP adres is niet letterlijk verborgen, het is eerder een naald in een hooiberg. Maar die naald is nog steeds vindbaar als je er maar genoeg tijd en resources aan besteed. En Shodan heeft beide is over het algemeen mijn beleving.

[dmantione]

Dat is nu exact de definitie van security-by-design: Je kunt ook een wachtwoord in één keer goed raden of een cryptografische sleutel in één keer goed hebben. Inderdaad is het gebaseerd op toeval, maar het doel is dat de rekenkracht die benodigd is om de beveiliging te kraken dusdanig hoog is, dat het niet meer te doen is.

Een 80-bits token zou op zich zelf niet als heel veilig geacht worden, maar het is rekenkracht die bovenop het daadwerkelijk kraken van de SSH komt en dan is het beslist een extra barriëre.

Shodan heeft niet de resources om ipv6 te scannen. Om je een idee te geven: Laten we 2^80 adressen scannen (dat is mijn netwerk, niet het hele internet). Laten we 1 byte per ip-adres gebruiken voor het resultaat van ieder gescand ip-adres (onrealistisch weinig). Dan heb je 1209 yottabyte aan dataopslag nodig om alleen al het resultaat van je scans te kunnen opslaan. Dat is onrealistisch veel, dit zijn getallen die normaal gebruikt worden bij security-by-design.

Als ik kijk wanneer Shodan het laatst mijn IPv4-adres heeft gescand, op 9 juni... als ze in dat tempo ook v6 zouden scannen, dan scannen ze een beetje heel veel te weinig om een kans te maken het cruciale v6-adres te vinden.

[Reactie gewijzigd door dmantione op 22 juli 2024 18:02]

[3raser]

Dan heb je 1209 yottabyte aan dataopslag nodig om alleen al het resultaat van je scans te kunnen opslaan.

In een /80 subnet zitten 281.474.976.710.656 adressen, dus met 1 byte per ip adres zou dat 281 TB zijn. Nog steeds belachelijk veel maar wel een stuk minder dan wat jij noemt. Hoe dan ook heb je me wel overtuigt van de praktische nadelen om grote netwerken te scannen. In theorie zou het moeten kunnen maar ik had nog slecht voor ogen hoeveel IP adressen er werkelijk in IPv6 schuil gaan. Een beter voorbeeld zou ik dan de scansnelheid vinden. Stel dat je 1.000 IP adressen per seconde zou kunnen scannen dan zou je er bijna 9.000 jaar over doen om een /80 subnet te scannen. En dan is een /80 subnet nog klein. Mijn hostingprovider deelt standaard /64 netwerken uit. Als je die wilt scannen met 1 miljoen adressen per seconde (wat praktisch onmogelijk is) dan zou je daar 584.554 jaar over doen.

[dmantione]

Je krijgt bij ipv6 dan ook niet een /80, maar een /48. Ofwel 2^80 adressen.

2 ^ 80 = 1208925819614629174706176

[RobertMe]

VPN voegt voornamelijk weer een beveiligingslaag toe (VPN moet "gekraakt" worden, of doordat deze daadwerkelijk gehackt wordt, of doordat de gegevens op straat komen te liggen).

Maar er zijn natuurlijk ook andere opties i.p.v. een VPN, denk aan een cloud omgeving die met een firewall vanuit de "hoster" beschermd is waarbij je SSH alleen vanaf vertrouwde IPs toestaat (een service die niet elke provider aanbied). Uiteraard kun je hetzelfde bereiken met een firewall op de VPS zelf, maar daar plakken ook risico's aan. Als je IP veranderd kom je niet meer in de server om de firewall aan te passen (maar vaak wel nog in cloud admin panel). Of iets als Docker dat by-default in de firewall gaat zitten rommelen (als je ports forward naar Docker containers) waardoor onbedoeld poorten open kunnen komen te staan dat niet het geval zal zijn als de firewall extern draait (waardoor je altijd expliciet zelf moet openen).

IMO is een VPN dus ook niet de oplossing. Maar wel een mogelijke oplossing. Maar voor alleen SSH wellicht wat overkill.

[Jerie]

Als je IP veranderd kom je niet meer in de server om de firewall aan te passen

Jawel, maar dan moet je ipv een IPv4/32 een range nemen zoals IPv4/24 of een IPv6 range.

SSH kan overigens ook dienen als VPN.

Persoonlijk gebruik ik graag sinds Wireguard deze graag als VPN (al is Tailscale ook Wireguard).

[RobertMe]

Jawel, maar dan moet je ipv een IPv4/32 een range nemen zoals IPv4/24 of een IPv6 range.

Mijn ISP heeft er geen problemen mee om mij (zeer incidenteel) van 84.<...> naar 217.<...> te verplaatsen. Dus nee, een /24 lost het niet op, en een /8 nog steeds niet

Een beter antwoord was dan dat de cloud provider vast remote toegang geeft (VNC / ...) en via die route alsnog de firewall kunt herstellen

[Jerie]

Het was een voorbeeld. Je kunt gewoon kijken welke ranges ze leveren aan klanten, en die dan toevoegen. Dat kunnen bijvoorbeeld een een /16 en twee /23 zijn of een specifieke /24 en een /16. Maakt allemaal niets uit.

[dmantione]

OpenSSH is denk ik de software waar die het meest gehard is tegen de boze buitenwereld. Je kunt een VPN vooral effectief gebruiken om een heel netwerk af te sluiten, dat voorkomt dat je iedere afzonderlijke server als potentiële aanvalsvector moet beschouwen. Maar als je gewoon een webserver of zoiets huurt, dan speelt dat niet, dan is het die ene server die tegen de boze buitenwereld beschermd moet worden. SSH is dan het allerveiligste protocol.

Een extra beveiligingslaag klinkt heel tof, maar het hoeft het niet te zijn. Als remote-execution via de VPN-software mogelijk is, dan is je server al gehackt en boeit het niet meer dat er nog een extra SSH-server achter zit. Terwijl je dan dacht de veiligheid te verhogen, deed je precies het omgekeerde. De kans dat er in VPN-software een lek zit, is veel groter dan in SSH. Voor een individuele server dus gewoon SSH gebruiken, en pas als je hele netwerken met servers hebt, kan het zinnig worden om die met VPN's af te schermen.

[rbr320]

Ik ben een groot fan van (Open)SSH, maar ik denk niet dat je zomaar zonder bronnen kunt claimen dat het veiliger is dan VPN oplossingen. OpenVPN is al jaren in gebruik en heeft (net als OpenSSH) geen enorme lijst met kwetsbaarheden. En de broncode van Wireguard is zo klein dat het zowaar mogelijk is om de code te verifiëren op correctheid en dat is ook al gebeurd.

Daarnaast geeft een VPN je niet meteen shell toegang tot een machine, een SSH sessie doet dat wel. Dus een lek in OpenSSH is potentieel veel erger dan in VPN software.

[dmantione]

Dat laatste is de situatie als je je met succes kunt authenticeren. Als je remote code kunt uitvoeren (zoals bijvoorbeeld bij een bufferoverflow in de code) en ook bij de kwetsbaarheid waar we het hier over hebben, dan hoef je je helemaal niet te authenticeren, je bent immers al binnen.

Omdat SSH zo ongelooflijk veel getoetst is, evenals de reputatie van het OpenBSD-team, heb ik veel meer vertrouwen in SSH dan in allerlei VPN-implementaties. Dat betekent zeker niet dat ze onveilig zijn, om redenen die je noemt, wel is mijn vertrouwen erin veel kleiner dan in OpenSSH.

[ejabberd]

Of je hebt een bedrijfsnetwerk in een VPN en een server in de cloud en je staat enkel verkeer op poort 22 toe vanaf het IP-adres van dat bedrijfsnetwerk.

[3raser]

...maar in de cloud laat ik ze zelf ook wel eens een tijdje openlijk draaien.

Ik zorg er dan gewoon voor dat er een IP filter zit op de firewall. Maar achter een VPN doe ik vrijwel nooit. Wat een gedoe om voor elke cloudserver een VPN op te zetten. Tenzij je misschien dan weer een lokaal cloudnetwerk maakt, maar in dat geval is een VPN eerder gevaarlijker dan een open SSH poort. Theoretisch krijg je na een hack van de VPN toegang tot een groot achterliggend netwerk waarbij je met een hack van SSH vaak beperkt blijft tot een enkele server.

[asing]

Dat Linux het niet heeft is niet correct : Wikipedia: Address space layout randomization

Het is geen sterke vorm en de 32-bits versie heeft zo te zien geen ASLR. 32 bit Linux versies zijn er nog wel https://itsfoss.com/32-bit-linux-distributions/ maar de laatste 32 bits Intel processoren kwamen in 2006 op de markt. Alweer bijna 20 jaar geleden. Dus hoewel er 32 bits Linux distros beschikbaar zijn zie ik het echt als een niche.

[Jerie]

Dat Linux het niet heeft is niet correct : Wikipedia: Address space layout randomization

Dat schreef ik dan ook niet:

Linux/MIPS bijvoorbeeld, heeft niet eens ASLR...

Linux/MIPS heeft geen ASLR.

[ari3]

Het is geen sterke vorm en de 32-bits versie heeft zo te zien geen ASLR. 32 bit Linux versies zijn er nog wel https://itsfoss.com/32-bit-linux-distributions/ maar de laatste 32 bits Intel processoren kwamen in 2006 op de markt. Alweer bijna 20 jaar geleden. Dus hoewel er 32 bits Linux distros beschikbaar zijn zie ik het echt als een niche.

Echter zijn er wel veel (consumenten) routers die een variant van Linux draaien op 32-bit hardware met mogelijk een SSH-service, o.a. Mikrotik spul. Dat maakt het toch echt geen niche.

[Reactie gewijzigd door ari3 op 22 juli 2024 18:02]

[freshy98]

Niet alleen Linux system, zo te zien: https://www.freebsd.org/s...eBSD-SA-24:04.openssh.asc

[pennywiser]

De initiële ontwikkeling vind toch ook plaats bij Open- of FreeBSD?

[Jerie]

Van OpenSSH op OpenBSD. De p in de OpenSSH release staat voor portable.

[pennywiser]

Geport vanaf waar dan?

[freshy98]

afaik OpenBSD, iig in den beginne: https://www.openssh.com/history.html

[pennywiser]

Dat bedoel ik, of eigenlijk meer dat de ontwikkeling op 1 plek plaatsvind, Linux of BSD, of tegenwoordig ook, Windows,

Gek dat in het artikel dan alleen Linux wordt genoemd

[Reactie gewijzigd door pennywiser op 22 juli 2024 18:02]

[Jerie]

OpenSSH 9.8/9.8p1 (2024-07-01)

@freshy98 Dus nog steeds. Zoals je kunt lezen is de versie OpenSSH 9.8 ofwel OpenSSH 9.8p1. Binnen het OpenSSH team is OpenSSH geprogrammeerd voor OpenBSD. Al het andere zijn portable versies.

Je ziet dat ook op de website terug:

For OpenBSD

Releases
[...]

For other systems

Releases
[...]

Dat het artikel Linux noemt is omdat de PoC werkt op 32-bit Linux (wellicht x86-32) met ASLR.

A critical vulnerability in sshd( was present in Portable OpenSSH
versions between 8.5p1 and 9.7p1 (inclusive) that may allow arbitrary
code execution with root privileges.

Successful exploitation has been demonstrated on 32-bit Linux/glibc
systems with ASLR. Under lab conditions, the attack requires on
average 6-8 hours of continuous connections up to the maximum the
server will accept. Exploitation on 64-bit systems is believed to be
possible but has not been demonstrated at this time. It's likely that
these attacks will be improved upon.

Exploitation on non-glibc systems is conceivable but has not been
examined. Systems that lack ASLR or users of downstream Linux
distributions that have modified OpenSSH to disable per-connection
ASLR re-randomisation (yes - this is a thing, no - we don't
understand why) may potentially have an easier path to exploitation.
OpenBSD is not vulnerable.

Hier zit geen woord Spaans bij. Iedere zin die ik quote is relevant.

Bron: https://www.openssh.com/ en https://www.openssh.com/releasenotes.html#9.8p1

[rbr320]

Dat klopt maar omdat in het artikel staat dat deze kwetsbaarheid specifiek Linux systemen treft die gebruik maken van glibc zou je kunnen denken dat *bsd systemen niet kwetsbaar zijn. De g in glibc staat namelijk voor GNU, waarvan de software veel gebruikt wordt op Linux maar niet op BSD-gebaseerde besturingssystemen.

[pennywiser]

Thanks, gek dat dan alleen Linux zo specifiek genoemd wordt.

[sabineschults]

Qualys heeft het specifiek over op glibc gebaseerde Linux-systemen.
https://blog.qualys.com/v...ability-in-openssh-server

[Jerie]

Klopt, Linux met glibc (GNU libc).

BSDs gebruiken geen glibc maar BSD libc.

Maar hier zet ik mijn vraagtekens bij:

Based on searches using Censys and Shodan, we have identified over 14 million potentially vulnerable OpenSSH server instances exposed to the Internet. Anonymized data from Qualys CSAM 3.0 with External Attack Surface Management data reveals that approximately 700,000 external internet-facing instances are vulnerable. This accounts for 31% of all internet-facing instances with OpenSSH in our global customer base. Interestingly, over 0.14% of vulnerable internet-facing instances with OpenSSH service have an End-Of-Life/End-Of-Support version of OpenSSH running.

potentially vulnerable zegt niets. Zijn dat dan 32-bit systemen? Betreft het x86-32 of 32-bit in algemeen? Ik geloof er geen drol van dat 31% van de systemen die aan het internet hangen 32-bit architectuur Linux draait. Linux wel, maar 32-bit arch dat geloof ik niet. Dat wil ik dan wel onderbouwd zien met data.

Hier staat ook wat waarom OpenBSD niet kwetsbaar is, en dat OpenSSH versies tot 4.4p1 (dus in volksmond 4.4) kwetsbaar zijn.

Affected OpenSSH versions:

OpenSSH versions earlier than 4.4p1 are vulnerable to this signal handler race condition unless they are patched for CVE-2006-5051 and CVE-2008-4109.

Versions from 4.4p1 up to, but not including, 8.5p1 are not vulnerable due to a transformative patch for CVE-2006-5051, which made a previously unsafe function secure.

The vulnerability resurfaces in versions from 8.5p1 up to, but not including, 9.8p1 due to the accidental removal of a critical component in a function.

OpenBSD systems are unaffected by this bug, as OpenBSD developed a secure mechanism in 2001 that prevents this vulnerability.

[laurxp]

Based on searches using Censys and Shodan, we have identified over 14 million potentially vulnerable OpenSSH server instances exposed to the Internet. Anonymized data from Qualys CSAM 3.0 with External Attack Surface Management data reveals that approximately 700,000 external internet-facing instances are vulnerable. This accounts for 31% of all internet-facing instances with OpenSSH in our global customer base. Interestingly, over 0.14% of vulnerable internet-facing instances with OpenSSH service have an End-Of-Life/End-Of-Support version of OpenSSH running.

Dat is 100% marketing-tekst. Qualys verkoopt "vulnerability scanners", dus ze willen dat iedereen hun producten gaat kopen om te checken of hun servers daadwerkelijk vatbaar zijn. Je server kán tenslotte vatbaar zijn - je weet het maar nooit!

[dmantione]

Belangrijk is te weten dat alleen naar het versienummer gekeken wordt. De meeste Linuxdistributies hebben evenwel niet het beleid om met nieuwe versies van software te komen als een beveiligingslek gevonden wordt, nieuwe versies veroorzaken namelijk vaak incompatibiliteiten, of vereisen dat andere componenten in de distributie geactualiseerd worden om met de nieuwe versie te kunnen werken.

Daarom wordt meestal het lek in de oude versie gepatcht. Dan is een server volgens Shodan kwetsbaar, maar in werkelijkheid niet. Omdat servers zelden de allernieuwste distributie draaien, zal een grote meerderheid van de servers als kwetsbaar aangemerkt worden, maar in werkelijkheid gewoon veilig zijn, omdat de veiligheidsupdates geïnstalleerd zijn.

[fdh]

Probleem is niet beperkt tot 32bit systemen, maar zit ook in x86_64

[dasiro]

WSL gebruikt optioneel ook openssh-server, dus afhankelijk van de geïnstalleerde versie is die ook kwetsbaar

[MainframeX]

De kans dat een kwaadwillende een openssh server op je WSL installatie misbruikt is wel echt heel beperkt. Ik neem aan dat je geen Windows servers met WSL direct aan het internet hebt hangen?

[dasiro]

de tijd dat toestellen zomaar aan het internet werden gehangen is toch al wel een tijdje voorbij mag ik hopen, maar dat wil niet zeggen dat er nergens in je netwerk een device kan zijn dat al dan niet legitiem toegang mag hebben tot die bewuste server. Malware gaat gewoon op zoek naar vulnerabilities in een netwerk en of dat nu een WSL of een of andere native *nix distro is maakt meestal niet uit, tenzij een bepaalde attack-chain is uitgestippeld. In zo'n geval zou het zelfs net kunnen zijn dat ze een WSL-installatie zoeken om dan weer windows exploits te kunnen installeren en dan kan een WSL even nuttig zijn als een SMB 1.0

[P1nGu1n]

OpenBSD is in ieder geval niet getroffen:

quote: https://www.qualys.com/20...2024-6387/regresshion.txt

OpenBSD is notably not vulnerable, because its SIGALRM handler calls syslog_r(), an async-signal-safer version of syslog() that was invented by OpenBSD in 2001.

[freshy98]

Verbaast me niet :-)

[sIRwa3]

dus een fail2ban zou ook al tot vermindered succes van de exploit zorgen?

[CH4OS]

In theorie wel, maar fail2ban is ook weer niet de heilige graal of zo, daarnaast is het lek redelijk specifiek en vaak (zeker in zakelijke omgevingen) heb je een VPN verbinding nodig. Dus voordat het lek misbruikt kan worden heb je ook een groter probleem.

De beste manier om dit probleem te mitigeren als er geen update beschikbaar is, is om

LoginGraceTime

op 0 te zetten in de SSHD configuratie file en SSHD te herstarten, zoals de laatste paragraaf ook al beschrijft. Fail2Ban is dan immers niet meer nodig.

[Reactie gewijzigd door CH4OS op 22 juli 2024 18:02]

[Mijzelf]

De beste manier om dit probleem te mitigeren als er geen update beschikbaar is, is om LoginGraceTime op 0 te zetten in de SSHD configuratie file en SSHD te herstarten

Ik vraag me af of je dan niet net zo goed de hele ssh server kunt uitzetten. Als je 0 seconden hebt om in te loggen, kun je toch gewoon niet inloggen?

[CH4OS]

In principe log je in met een SSH key of certificaat via een managing app, dus op zich heb je ook geen username en/of password nodig om in te loggen.

[RobertMe]

LoginGraceTime
The server disconnects after this time if the user has
not successfully logged in. If the value is 0, there is
no time limit. The default is 120 seconds.

Nu heeft 0 sowieso een andere betekenis. Maar het lijkt mij dat LoginGraceTime betrekking heeft op logins onafhankelijk van de authenticatie methode. Dus ook als public/private key auth te langzaam is lijkt mij dat dit gewoon de verbinding dicht gooit. Kan vast voorkomen als je bv een SSH agent hebt draaien die nog een passphrase voor de key vraagt, of als je een key gebruikt op basis van een security key waarbij een roaming key (zoals een YubiKey) uberhaupt al aangesloten moet zijn, maar er ook altijd nog eens een bevestiging gegeven moet worden om de security key te mogen gebruiken, dat dus lang(er) kan duren.
Als je deze instelling op 1 (seconde) zet (/kort zet) lijkt het mij dus wel degelijk mogelijk dat je tegen dit "probleem" aanloopt. Omdat je simpelweg niet binnen die 1e seconde nadat de TCP verbinding is opgezet volledig ingelogd bent.

[Dennisb1]

[...]

Ik vraag me af of je dan niet net zo goed de hele ssh server kunt uitzetten. Als je 0 seconden hebt om in te loggen, kun je toch gewoon niet inloggen?

Volgens mij betekend 0 gewoon onbeperkt tijd.

[mrmrmr]

LoginGraceTime 0 vermijdt dat code wordt aangeroepen met het probleem. Bron.

[Reactie gewijzigd door mrmrmr op 22 juli 2024 18:02]

[kodak]

Daar kun je maar beter niet vanuit gaan. Fail2ban is gewoonlijk reactief, dus als er al een poging is gedaan. Het probleem is juist dat de ssh-client van de crimineel niet binnen de gestelde tijd een poging tot authenticatie doet en dit al mogelijkheid geeft. Je stopt dus niet de eerste poging, wat al genoeg kan zijn om root-rechten te krijgen.
Natuurlijk kun je dat risico aanvaarden als het maar bij één poging blijft. Maar je kunt duizenden verschillende criminelen verwachten die het komende jaren gaan proberen. Terwijl 1 succesvolle crimineel die het lukt root-rechten te krijgen waarschijnlijk al onacceptabel is.
Als je niet kan updaten zal het voorkomen eerder effectiever zijn als je de configuraties van de ssh-service zoals omschreven aanpast en daarnaast alleen van vertrouwde clients pogingen gaat accepteren.

[Reactie gewijzigd door kodak op 22 juli 2024 18:02]

[thomas_n]

Ik kreeg de update al binnen, inderdaad. Aan de ene kant mooi om te zien dat er binnen een paar dagen na eerste melding van de kwetsbaarheid een oplossing klaar staat, maar aan de andere kant jammer om te lezen dat de kwetsbaarheid al in 2020 ontstaan is. Hopelijk is die niet in de tussentijd door kwaadwillenden ontdekt.

[Cybermage]

Op welke linux distro kreeg je de update binnen? Draai zelf fedora maar die heeft nog vrolijk een oudere versie die wel vulnerbility bevat.

[thomas_n]

Op welke linux distro kreeg je de update binnen? Draai zelf fedora maar die heeft nog vrolijk een oudere versie die wel vulnerbility bevat.

Ubuntu. Ik neem aan dat Fedora ook wel snel zal volgen. Red Hat heeft hem ook inderdaad nog niet gepatcht, zo te zien.

[dmantione]

Ik ben mijn systemen aan het updaten. Raspberry Pi OS heeft het via Debian al de juiste versies. Mijn OpenSuSE-systemen hebben nog geen updates en dat kan wel eens zijn omdat SuSE stelt dat alleen SLES15 SP6 kwetsbaar is:

https://www.suse.com/security/cve/CVE-2024-6387.html

OpenSuSE 15.6 is op SP6 gebaseerd, dus wellicht komt er wel helemaal geen update voor mijn 15.5-systemen, welke op SP5 gebaseerd zijn.

Maar dan komt wel de vraag op: Waarom zo weinig distributies kwetsbaar?

[Reactie gewijzigd door dmantione op 22 juli 2024 18:02]

[CH4OS]

Het lek lijkt momenteel alleen mogelijk te zijn op 32 bits systemen, dus als je al een 64 bits systeem hebt (en daarop een 64 bits OS draait), lijkt het erop dat je er geen last van hebt, zie ook CH4OS in 'OpenSSH 9.8 lost kritieke rce-kwetsbaarheid op'.

[RobertMe]

Dat misbruik nog niet is aangetoond betekend natuurlijk niet dat het niet mogelijk is. Het kan ook simpelweg zijn dat de researchers het alleen op een 32 bit systeem getest hebben omdat dat het enige was dat ze voorhanden hadden (alhoewel dat onwaarschijnlijk is ). Hetzelfde als dat het lek alleen bewezen is met glibc, maar er ook geen uitsluitsel is over andere C library implementaties. Beste is en blijft het IMO dan ook om te updaten.
Hetzelfde als dat bij de xz backdoor distros snel terugrolde naar oudere versies omdat de implicaties onbekend waren. Terwijl vanaf de bekendmaking meteen duidelijk was dat de originele source files op GitHub op zichzelf niet kwetsbaar waren (en alleen de handmatig geupdate sourcecode zip / tar de "trigger" bevatte) en volgens mij ook geen andere lekken aan het licht zijn gekomen. Dus daar waren de distros wel uiterst voorzichtig en deden alle distros wel iets er mee, ook al waren op basis van de code alleen Debian based & RPM based distros getroffen etc. Die "voorzichtigheid" mag hier dus ook wel, en ook voor 64 bits (/64 bit only) distributies gewoon een versie uitgeven met batch. Het kan geen kwaad om de patch toe te passen en de mogelijkheid op het lek is dan meteen weg. Terwijl er nu onzekerheid is. Ja, het is wellicht onwaarschijnlijk dat het op 64 bit of met een andere C library implementatie toepasbaar is. Maar het is niet bewezen dat deze niet getroffen zijn, dus beter aan de veilige kant gaan zitten. Daarnaast is de exploit nu ook bekend, en geven de researchers zelf al aan dat er mogelijk een betere reproducer voor gemaakt wordt (die het sneller vind, en wellicht dus ook beter toepasbaar maakt op 64 bit of andere C libraries).

[RobertMe]

Debian Bookworm is die ook al voor uit gekomen: https://lists.debian.org/...nounce/2024/msg00135.html Als je nu update krijg je versie 1:9.2p1-2+deb12u3 die dus gepatcht is (mijn systeem stond u2 op, ter vergelijking).

En Arch heeft ook al de 9.8 versie sinds vanmorgen: https://archlinux.org/packages/core/x86_64/openssh/

Normaliter gaan dit soort zaken ook heel snel. Aangezien er hier en daar wat security mailing lists zijn voor de distros die al geïnformeerd worden voordat de nieuwe versie uit is en wellicht zelfs al de release vooraf ontvangen. Op het moment dat het lek dan gepubliceerd wordt kunnen de distros ook meteen aan de slag. I.p.v. dat het eerst bekend wordt en de distros dan "overvallen" worden en nog eens alles bij elkaar moeten zoeken.

[Reactie gewijzigd door RobertMe op 22 juli 2024 18:02]

[_JGC_]

Vanmiddag op Debian 12 ook al binnen. Had net de pointrelease van afgelopen weekend overal uitgerold en kreeg kort daarna weer meldingen over ontbrekende updates op een aantal systemen.
Debian 11 heeft nog 8.4p1 en heeft de bug niet.

[kuurtjes]

Technische info: https://www.qualys.com/20...2024-6387/regresshion.txt

[telenut]

Hoe kan je uw netwerk eigenlijk scannen op toestellen die mogelijks die kwetsbaarheid hebben?
Niet iedereen is altijd zo open en eerlijk over wat ze op het netwerk zetten...