Beveiligingslekken in OpenSSH-software maken mitm-aanvallen mogelijk - update

Securityonderzoekers van Qualys hebben twee ernstige kwetsbaarheden aangetroffen in OpenSSH. De ergste hiervan stelt kwaadwillenden in staat om man-in-the-middleaanvallen uit te voeren.

De eerste kwetsbaarheid, CVE-2025-26465, treft gebruikers die werken met de VerifyHostKeyDNS-functionaliteit. Een aanvaller kan hierbij de identiteitscontrole van de server omzeilen, ongeacht of deze optie op 'yes' of 'ask' staat ingesteld. Het lek is al sinds december 2014 aanwezig in de software en treft alle versies vanaf 6.8p1 tot en met 9.9p1.

Daarnaast is CVE-2025-26466 ontdekt, een tweede beveiligingslek dat servers kwetsbaar maakt voor denial-of-serviceaanvallen. Dit probleem, dat sinds augustus 2023 in de code zit, treft de versies 9.5p1 tot en met 9.9p1. Een aanvaller kan hierbij het geheugen en de processor van een systeem overbelasten voordat authenticatie plaatsvindt.

Het beveiligingsteam heeft direct een update uitgebracht om deze problemen te verhelpen. Systeembeheerders wordt aangeraden om zo snel mogelijk te upgraden naar OpenSSH 9.9p2. OpenSSH wordt veelvuldig gebruikt voor het op afstand beheren van systemen en het beveiligd inloggen op servers. De VerifyHostKeyDNS-optie staat standaard uitgeschakeld. Wel wijst Qualys erop dat de optie op FreeBSD-installaties tussen september 2013 en maart 2023 wel standaard aan stond.

Update, 19 februari, 15.59 - In het artikel stond aanvankelijk dat de VerifyHostKeyDNS-optie standaard aan stond, maar dat was alleen het geval op FreeBSD-installaties. Ook is het woord 'kritiek' uit de titel gehaald.

Reacties (71)

[closefuture]

De titel "Kritieke beveiligingslekken in OpenSSH-software maken mitm-aanvallen mogelijk" is wel heel zwaar aangezet voor wat hier aan de hand is.

De optie "VerifyHostKeyDNS" staat standaard uit en is ook nog eens "obscure" te noemen. Bijna niemand gebruikt deze optie. Kennelijk heeft enkel FreeBSD (god knows why) de optie een tijdlang standaard aangezet (maar nu ook al een aantal jaren niet meer).

Omdat DNS ansich vaak ook weer niet encrypted is (tenzij je DOH of DNS met TLS gebruikt) is de optie sowieso al onveilig in veel gevallen. De kans dat iemand dit daadwerkelijk met DNSSEC gebruikt is denk ik ook minimaal.

[Reactie gewijzigd door closefuture op 18 februari 2025 15:48]

[CAPSLOCK2000]

Omdat DNS ansich vaak ook weer niet encrypted is (tenzij je DOH of DNS met TLS gebruikt) is de optie sowieso al onveilig in veel gevallen. De kans dat iemand dit daadwerkelijk met DNSSEC gebruikt is denk ik ook minimaal.

De Linux-versie van OpenSSH laat het gebruik van VerifyHostKeyDNS=yes alleen toe als je ook DNSSEC gebruikt. Dat zou dus vanzelf goed moeten gaan. Zonder DNSSEC vraagt OpenSSH de gebruiker om de fingerprint te accepteren. Ik meen dat het onder Windows anders werkt omdat SSH daar niet kan controleren of DNSSEC is ingeschakeld.

ssh_config(5):

VerifyHostKeyDNS
Specifies whether to verify the remote key using DNS and SSHFP resource records. If this option is set to yes, the client will implicitly trust keys that match a secure fingerprint from DNS. Insecure fingerprints will be handled as if this option was set to ask.
If this option is set to ask, information on fingerprint match will be displayed, but the user will still need to confirm new host keys according to the StrictHostKeyChecking option. The default is no.

"a secure fingerprint from DNS" betekent hier de facto DNSSEC.

[Reactie gewijzigd door CAPSLOCK2000 op 18 februari 2025 16:21]

[closefuture]

"a secure fingerprint from DNS" betekent hier de facto DNSSEC.

Dat is volgens mij niet wat er staat in de manual. Wat hier bedoelt word is als er een "SSHFP" record voor de host entry in de DNS staat (zoals bijvoorbeeld "ssh.tweakers.net") en "VerifyHostKeyDNS" staat aan dan word de client vertrouwd (net zoals als deze in "~/.ssh/authorized_keys" zou staan). Als er geen DNS entry is dan word de client als untrusted gezien en word er gevraagd of de fingerprint vertrouwd moet worden.

Ik weet dit vrij zeker omdat ik VerifyHostKeyDNS vroeger gebruikte samen met DNS SSHFP entries. Dat gebruikte geen DNSSSEC. Daarnaast kan de SSH client (in zijn huidige vorm) denk ik helemaal niet zien of DNSSEC gebruikt is omdat die waarschijnlijk gewoon de libc resolver gebruikt om die SSHFP record op te vragen. En libc koppelt niet terug naar de caller of DNSSEC gebruikt is.

[Reactie gewijzigd door closefuture op 18 februari 2025 16:57]

[CAPSLOCK2000]

Dat is volgens mij niet wat er staat in de manual. Wat hier bedoelt word is als er een "SSHFP" record voor de host entry in de DNS staat (zoals bijvoorbeeld "ssh.tweakers.net") en "VerifyHostKeyDNS" staat aan dan word de client vertrouwd (net zoals als deze in "~/.ssh/authorized_keys" zou staan). Als er geen DNS entry is dan word de client als untrusted gezien en word er gevraagd of de fingerprint vertrouwd moet worden.

Ik zal het vanavond nog eens testen, maar de handleiding heeft het over "secure fingerprints" en "insecure fingerprints". Volgens mij is de enige zinnige uitleg dat dit op DNSSEC slaat. Met DNSSEC wordt de SSFP-key gewoon geaccepteerd. Zonder DNSSEC moet de gebruiker bevestiging geven maar krijg je wel de informatie te zien dát er een SSHFP is gevonden. Je zal wel de resolver moeten vertrouwen maar dat moest je toch al.

Daarnaast kan de SSH client (in zijn huidige vorm) denk ik helemaal niet zien of DNSSEC gebruikt is omdat die waarschijnlijk gewoon de libc resolver gebruikt om die SSHFP record op te vragen. En libc koppelt niet terug naar de caller of DNSSEC gebruikt is.

Jawel, daar is de AD (Authenticate Data) bit voor. SSH vraagt via die bit aan de resolver om DNSSEC in te schakelen en kan ook controleren of het antwoord inderdaad veilig is.

Als je SSH debug logging aanzet en SSHFP probeert te gebruiken zonder DNSSEC (of met ongeldige sleutels) dan krijg je de volgende melding te zien:

debug1: found 2 insecure fingerprints in DNS

Als er nog een derde fingerprint is die wel secure is dan wordt die gewoon gebruikt.
Volgens mij wordt de verbinding ook geaccepteerd als je de hostkey al eerder hebt geaccepteerd. Dat zou kunnen verklaren waarom het lijkt te werken zonder DNSSEC.

[Reactie gewijzigd door CAPSLOCK2000 op 18 februari 2025 17:19]

[closefuture]

OpenSSH kan kennelijk wel wat met DNSSEC doen inderdaad (ik dacht aanvankelijk dat het helemaal niks er mee deed).

Jawel, daar is de AD (Authenticate Data) bit voor. SSH vraagt via die bit aan de resolver om DNSSEC in te schakelen en kan ook controleren of het antwoord inderdaad veilig is.

Ik heb even wat in de source rondgeplozen en DNSSEC support loopt volgens mij niet via libc. Hiervoor moet je kennelijk OpenSSH builden met de "-ldns" flag. Hiermee word OpenSSH gebuild met ldns support. Beetje verwarrende naam in deze context aangezien de "-l" flag meestal staat voor dat je een library wilt toevoegen aan de linker path.

Volgens mij word standaard op bijvoorbeeld Fedora deze flag (-ldns) niet meegegeven. Ik heb niet in de RPM spec file gekeken, maar even snel met "ldd /usr/bin/ssh" en ik zie geen ldns. ldns bestaat wel als RPM maar is ook niet geinstalleerd op mijn systeem.

Volgens mij werkt het inderdaad voor de rest zoals jij stelt.

[Llopigat]

Ja de DNS optie heeft alleen zin als het zelf ook weer gesigned is (encrypted maakt niet zo heel veel uit want het is geen geheime informatie). Maar over het algemeen gebruikt men met SSH nog steeds TOFU (Trust On First Use). Dus inderdaad is er effectief niet echt een probleem voor de meeste mensen.

[kdekker]

Omdat openssh (voor Linux) doorgaans een module is, duurt het meestal wel even alle distributies de fix hebben. Voor die tijd kunnen systeembeheerders weinig. Developers die zelf openssh gebruiken kunnen wel wat, maar voor software boeren is het toch (uit mijn ervaring) wachten tot de volgende release trein. En dat kan zo enkele maanden (of langer) duren.

Overigens was de lijst CVE's bij openSSH lange eigenlijk altijd laag. Ca 2 jaar past op een A4-tje, zie: https://www.openssh.com/security.html.

[_JGC_]

Debian had de fix vanmorgen al voor Bookworm, vanmiddag kwam Buster daar achteraan.

OpenSSH zal voor dit soort lekken een mailinglist hebben waar distributie maintainers op ingeschreven staan. Dan is de patch al bekend bij de distributies en kan de fix tegelijk met de aankondiging beschikbaar worden gesteld.

[Olaf van der Spek]

En dat kan zo enkele maanden (of langer) duren.

Dan gebruik je de verkeerde distro..

[kdekker]

Als vanuit persoonlijk gebruik denkt, ja. Vanuit zakelijk gebruik wordt een enterprise versie steviger getest en heeft minder vaak releases. Dus daar is het zondermeer: nee. Denk aan Suse SLES, RedHat ES. En zo zijn er meer. Niet iedereen draait een 'pret' versie (ik waardee Ununtu, maar dat is doorgaans in de server wereld geen versie die voor 24/7 gebruikt wordt, domweg omdat er geen service contracten op af te sluiten zijn). Het is voor grote bedrijven/grote groepen gebruikers altijd de afweging security v.s. stabiliteit. Een top-secure systeem wat niet draait, wordt ook niemand blij van (het gebeurt niet vaak, maar updates uitrollen is een risico en kost tijd).

Overigens is het niet mijn bedoeling om een 'maar Ubuntu kun je prima gebruiken voor server-grade toepassingen' discussie laten ontstaan. Ik noteer slechts dat oplossen bij openSSH 1-ding is en het even (afhankelijk van de distro) korter of langer extra, voordat ze de openSSH fix in hun eigen versie van openSSH gebruiken).

Nog los daarvan: iedere Linux distro maakt zijn eigen overwegingen over welke versie van openSSH meegeleverd wordt c.q. onderhouden wordt (bij Enterprise Linux versies is dat veel defensiever dan voor een 'pret' Linux versie, waar de eisen lager liggen).

[Reactie gewijzigd door kdekker op 18 februari 2025 17:05]

[Elminster]

Kerel, weet je eigenlijk wel waar je over spreekt?

Enterprise versies maintainen hun eigen branches, en voor bugs als deze worden de patches gewoon gebackport. No f-ing way dat SLES / RES hier maanden gaan voor nodig hebben.

Gewoon efkes kijken op suse customer center, packages zijn al beschikbaar.
https://scc.suse.com/patches#!/356649

Trouwens, 'pret' linux.

[pennywiser]

RHEL 8 lijkt geen fix meer te krijgen, maar heeft nog tot in 2029 support: https://access.redhat.com/security/cve/CVE-2025-26465

[DataGhost]

Dat ligt dan meer aan de procedures van die vorige werkgever van je. Als het allemaal zo belangrijk is dat het blijft werken én secure is, heb je iemand of een team in-house of onder contract staan die de voorgestelde patches kunnen analyseren, kunnen fast-tracken op een testomgeving en dan zo snel mogelijk op live krijgen, met alle bijbehorende procedures natuurlijk. Ik kan me slecht voorstellen dat men liever een kritiek lek (niet deze, deze is niet kritiek) op internet-facing machines aanhoudt omdat alles volgens het langzame boekje moet. Anders ligt de prioriteit simpelweg niet op de plek die je nu impliceert. Dat mag alsnog, prima, maar dat ligt dan niet aan de distro-makers terwijl dat wel is waar je het over had in je eerste reactie.

[kdekker]

Ik heb te maken gehad met tokos waar 2x per jaar een 24h maintenance time frame is. Dus ja: doordraaien is (soms/meestal/altijd doorstrepen wat niet van toepassing is) belangrijker dan secure zijn. En gezien wat je regelmatig in het nieuws gebeurt dat vaak genoeg. Van de zijlijn is makkelijk te zeggen: foei insecure. Maar niet doordraaien kan een stuk duurder zijn dan eventuele boetes.

[DataGhost]

Prima, dat is een keuze, maar rijmt totaal niet met

...duurt het meestal wel even alle distributies de fix hebben. Voor die tijd kunnen systeembeheerders weinig.

[kdekker]

Dat is waar. Ik sprak uit ervaring van langer geleden en wist niet dat Linux distro's zo snel waren met security fixes.

[Elminster]

U leek te willen spreken met autoriteit, en leek te insinueren dat SLES & RHES geen updates zouden uitbrengen tot hun volgende release (of het zou maanden duren). Dat is simpelweg niet correct.

Daar komt nog bij dat de term " 'pret' linux " gewoon zeer beledigend is tegenover andere gebruikers.
(en aangezien ik geen SLES/RHES gebruikt hoor ik daar ook bij)

Heel veel / de meeste software wordt geschreven & maintained door niet-SLES/RHES gebruikers.
Inclusief software dat door SLES/RHES geincludeerd wordt.
Ik neem aan dat u dat weet (of zou moeten weten, als u systemen beheert), en een beetje meer respect voor ons kan dan geen kwaad. Wie de bal kaatst, mag hem terug verwachten.

Maar toch mijn excuses. Het was gisteren een stevige ochtend, en dat is geen goeie reden om heftig te reageren. Bij deze.

[kdekker]

Leg me geen woorden in de mond die ik niet zei:

Ik zei:

Vanuit zakelijk gebruik wordt een enterprise versie steviger getest en heeft minder vaak releases

Jij zei:

No f-ing way dat SLES / RES hier maanden gaan voor nodig hebben

(de smileys laat ik maar weg)

Het enige wat ik zei dat bij enterprise versies het iets langer duurt (of duurde, toen ik er mee werkte, wat ook al meer dan 5 jaar geleden is), omdat ze meer testen. Dat is namelijk hun bestaansrecht: enterprise = stabiliteit.

Dat je mijn reactie over pret-linux als een sneer opvatte is aan jou, maar nogmaals, die versies hebben een heel ander gebruiksdoel en enterprise business draait daar niet op (effe benadrukken: vanuit mijn context schrijf ik dat en vanuit ervaring). Net zo goed dat server-grade spul niet op Windows 11, maar op Windows Server xyz draait. Dat jouw wereld daar niet bij aansluit, prima. Op de plekken waar ik tegen Linux aanliep, als softwareontwikkelaar, was het altijd een enterprise versie, domweg omdat de software die we maakten alleen gevalideerd werd op een enterprise Linux versie. Valideren van complexe software wil je niet op tig Linux distro's. Het is qua tijd niet uit te voeren. Overigens, als er ex-UNIX (AIX, Solaris, HPUX) klanten waren, stapten ze vaker over naar Windows, dan naar Linux (wat ik dan weer niet begreep, omdat Linux doorgaans en stabieler en sneller draaide op dezelfde hardware). Waarschijnlijk omdat de meeste systeembeheerafdelingen binnen een bedrijf toch al meer van Windows weten dan van Linux.

Samenvattend c.q. correctie/aanvulling op mijn eerdere post: de tijd zit veel meer bij de (Enterprise) software boer dan bij de Linux leverancier. Overigens valdieerden we alleen major versies. Minor versies en security updates is aan de klant. Wel gebruikten we zelf ook 3rd party spul (statically linked, om conflicteb met OS varianten te voorkomen), en adoptie van security fixes daar kost wel weken/maanden, om voornoemde redenen.

Je reageerde op een vervelende manier. Laat een ander s.v.p. ook in zijn waarde. Ook deze reactie getuigd wel vooringenomendheid. De bal werd door jou op een vervelende manier gekaatst, alsof een ander geen andere ervaringen kan hebben of geen kennis heeft. En dat is jammer. Ik stond kennelijk onbedoeld op je best wel lange tenen... Besef dat mijn perspectief heel anders kan zijn dan de jouwe

[Reactie gewijzigd door kdekker op 19 februari 2025 16:31]

[Elminster]

Leg me geen woorden in de mond die ik niet zei:

Kijk eens naar uw eerste post. Ik zie daar staan:

Omdat openssh (voor Linux) doorgaans een module is, duurt het meestal wel even alle distributies de fix hebben. Voor die tijd kunnen systeembeheerders weinig. Developers die zelf openssh gebruiken kunnen wel wat, maar voor software boeren is het toch (uit mijn ervaring) wachten tot de volgende release trein. En dat kan zo enkele maanden (of langer) duren.

Daarop zei olaf:

Dan gebruik je de verkeerde distro..

En waarop uw 2de post.

Vanuit zakelijk gebruik wordt een enterprise versie steviger getest en heeft minder vaak releases. Dus daar is het zondermeer: nee. Denk aan Suse SLES, RedHat ES.

Hieruit versta ik toch duidelijk de woorden die ik u blijkbaar in de mond gelegd heb.

Ik stond kennelijk onbedoeld op je best wel lange tenen.

Kijk, ik heb mijn excuses aangeboden. U trapt na.

[kdekker]

Je slaat noch steeds een essentieel onderdeel over, nl ik heb het over ontwikkelaars. Daar zit de vertraging. Voor de distros heb je gelijk. Dat is, als de patch er is, systeembeheer. Maar software opnieuw bouwen met de nieuwere versie van openssh is developers werk. Dat onderscheid heb ik in de eerste post wellicht onvoldoende belicht. En release cycli van bijv ERP software is domweg maanden (iig voor externe klanten. Voor de interne cloud wel men wel snelle werken, maar dan heb je alle kn eigen beheer). Ik kan het niet mooier maken dan het is.

Die excuses had ik overheen gelezen. Mea culpa. Ik zat ook even in een kort moment te typen. Excuses aanvaard. Zo is de toon ook een stuk prettiger, bedankt.

[pennywiser]

Ok, maar RHEL 8 lijkt dus geen fix te krijgen: https://access.redhat.com/security/cve/CVE-2025-26465

[desalniettemin]

Denk het ook, want ik heb het net geupdate op MX Linux: sudo apt update && sudo apt upgrade openssh-client

[jeroenvj]

Moet je niet openssh-server oid (ik ken MX Linux niet) updaten, het is een fout in de server niet in de client?
Laat maar, ik zie dat de belangrijkste een client bug is.

[Reactie gewijzigd door jeroenvj op 18 februari 2025 18:11]

[latka]

Gelukkig is de belangrijkste CVE voor VerifyHostKeyDNS en die staat standaard uit. De andere is een DOS en dat is op zijn minst vervelend maar lekt minder data.

[YopY]

Als het goed opgezet is zal veel SSH ook niet op het open internet beschikbaar zijn, of op z'n minst indirect; als je achter een CDN zoals Cloudflare zit is het al moeilijk voor aanvallers om het 'echte' IP adres van je SSH server te achterhalen. Ik doe zelf ook mijn SSH altijd op een andere poort draaien, tenzij je een aantrekkelijk doelwit bent zullen er weinig zijn die een volledige port scan doen.

Werkt deze DDOS ook als je aan IP whitelisting doet?

[MulMonkey]

Als het goed opgezet is zal veel SSH ook niet op het open internet beschikbaar zijn, of op z'n minst indirect

Heel veel webservers zijn júist (alleen) benaderbaar via SSH. Ze staan in een datacenter ergens waar je niet ff een schermpje op kunt zetten.

Er zullen natuurlijk vele uitzonderingen bestaan: proxy's en vpns. Maar ik denk dat er juist een gigantisch scala aan SSH poorten "op het open internet" beschikbaar zijn.

[eborn]

Dat wil niet zeggen dat ze open moeten staan. SSH zonder specifieke IP-filter is bij ons een no-go.

[SVMartin]

Precies dit, check je config en kijk of je wakker ligt van mogelijke DDoS en neem daarop additionele maatregelen voor jouw situatie.

[markjanssen]

En is dit een client bug, niet een server-bug.

Dus als je alleen naar je eigen servers connect, gaat 't wel heel erg opvallen als er wat raars aan de hand is:
client$ /usr/bin/ssh -o VerifyHostKeyDNS=yes john@real-server
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

[Memori]

Gelukkig is de belangrijkste CVE voor VerifyHostKeyDNS en die staat standaard uit

Sterker nog, deze setting zit standaard niet in de config file en default naar uit. Dus geen zorgen voor degene die openssh gewoon installeren en configureren zonder de documentatie te lezen.

[zenlord]

Omdat openssh (voor Linux) doorgaans een module is

Ik heb openssh nog nooit als module gezien en heb nu toch al wat jaren op de teller met een aantal linux distributies - niet op Debian, Archlinux of Alpine.

, duurt het meestal wel even alle distributies de fix hebben.

Dat hangt af van de distributie. Debian heeft een security team die eerder vandaag al een DSA ('Debian Security Advisory') had gepubliceerd en een update naar de repo's had gestuurd. Vanavond zijn al mijn servers en clients gepatcht.

[desalniettemin]

Net geupdate op MX Linux dat op Debian gebaseerd is:

sudo apt update && sudo apt upgrade openssh-client

[desalniettemin]

Meteen even geupdate: sudo apt update && sudo apt upgrade openssh-client

[Opifex]

Ja, dat doet dus helemaal niets. De apt repositories hebben nog lang niet de nieuwe versie opgenomen. Als je nu op een Arch o.i.d. had gezeten, dan had dat misschien al een ander verhaal geweest. Maar dan nog...

Maar goed... als jij je veiliger voelt ben ik blij voor jou

[pennywiser]

Om 12 uur had Debian al een fix https://security-tracker.debian.org/tracker/CVE-2025-26465

[CAPSLOCK2000]

Ja, dat doet dus helemaal niets. De apt repositories hebben nog lang niet de nieuwe versie opgenomen.

Debian heeft al fixes geupload voor alle ondersteunde versies naar de security repo's:
https://security-tracker.debian.org/tracker/CVE-2025-26465

De fix is dus beschikbaar voor Bookworm (stable), Bullseye (oldstable) en Sid (unstable). Trixie (testing) moet even wachten om het normale test-proces te doorlopen, zoals gewoonlijk is bij Testing.

[GorgeousMetal]

Dit klinkt als heel ernstig. Welke software gebruikt allemaal OpenSSH? Ik zie het in elk geval op mijn Debian Server.

[Reactie gewijzigd door GorgeousMetal op 18 februari 2025 15:19]

[jdh009]

OpenSSH wordt in een breed scala aan besturingssystemen en netwerkapparaten gebruikt, waaronder veel Linux- en BSD-varianten, netwerkapparatuur en zelfs Windows. De lijst is behoorlijk lang:

• OpenBSD
• FreeBSD
• BSDi BSD/OS
• NetBSD
• Computone
• Stallion
• Cygwin
• Mac OS X Version 10.1 and later
• HP Procurve Switch 4108GL and 2524/2512
• IBM AIX
• Sun Solaris 9 and later (named SunSSH)
• SmoothWall
• SGI Irix
• ThinLinc
• Nokia IPSO
• Cisco CSS11500 series content services switches
• Cisco SN 5400 series storage routers
• TopLayer IDS balancers
• NTI SSH Serial Port Switch
• Bluecoat (formerly Cacheflow) Proxy SG
• Novell NetWare
• Digi CM Console Servers
• Alcatel OmniSwitch
• Dell PowerConnect L2 and L3 Switches
• HP-UX (known as HP-UX Secure Shell)
• Packeteer PacketShaper 6.0 and above.
• Juniper Networks JUNOS
• All Linux systems, such as Red Hat.
• Microsoft Windows

En meer... Dus voor degenen die iets gebruiken dat in bovenstaande lijst staat en bepaalde SSH functionaliteit in die producten gebruiken (zoals beveiligde toegang (op afstand), versleutelde communicatie of bestandsoverdracht), is het handig om te kijken of een update nodig is.

Bron:
https://www.openssh.com/users.html

[Reactie gewijzigd door jdh009 op 18 februari 2025 15:29]

[Alfa1970]

Blue Coat bestaat niet meer. Het is Symantec, een divisie van Broadcom onder de sterfhuis constructie van Computer Associates. In de tijd van Cacheflow en later Blue Coat was dit geen probleem gezien ze geen Linux gebruikten maar een eigen proprietary OS volledig geschreven in assembly, en dus ook geen OpenSSH.

[kdekker]

Veel meer. Als developer kun je ook openssh als bibliotheek gebruiken in je code en ook iets als curl gebruikt het. Curl zit zelfs standaard in Windows (als handige command line tool).

Correctie: curl gebruikt geen openssh. Wel openssl. Wat iets anders is. Met dank aan @Elminster .

[Reactie gewijzigd door kdekker op 18 februari 2025 22:19]

[Elminster]

Waarom kom jij nu af met openssl?

Het probleem zit in openssH, niet openssL.

Als je als developer openssL gebruikt, dan ga je niet veel last hebben van openssH bugs.

[kdekker]

Mijn typefout.

[vanaalten]

Ik gok heel veel Linux machines die als server via internet bereikbaar zijn, op via ssh te benaderen. Ik zie in elk geval op mijn machine (Debian Stable) dat openssh-server geinstalleerd staat.

edit: ... en die nu een update gekregen heeft, van 9.2p1-2+deb12u4 naar 9.2p1-2+deb12u5

[Reactie gewijzigd door vanaalten op 18 februari 2025 15:23]

[bantoo]

Vrijwel alles met remote toegang heeft wel ergens een SSH server draaien.

[zalazar]

Deze vulnerability (CVE-2025-26465) is niet zo ernstig
Als je VerifyHostKeyDNS niet handmatig hebt aangezet, en voor 99,99% van de gebruikers is dat zo, dan is er geen problem. Daarnaast is het een voorwaarde dat je gebruikt maakt van DNSSEC

Op FreeBSD stond de optie van september 2013 t/m maart 2023 standaard aan, maar als je hebt geupdate en je de optie niet handmatig hebt gezet, dan staat het inmiddels daar ook uit.

Verder gaat hier om een man-in-the-middle waarbij je qua connectie uit komt op het systeem van de aanvaller, en waarbij het systeem van de aanvaller zich voordoet als de normale server. Je krijgt dan geen prompt dat de host identification is gewijzigd. En mocht de optie toch aan staan, en je gebruikt DNSSEC, dan is de kans vrij klein dat je in zo'n situatie terecht komt.

[ahbart]

Ik zie VerifyHostKeyDNS niet in mijn sshd_config staan? Hoe zit dat?
Dit betreft een debian server.

[Klauwhamer]

Default is 'no'. Wil je afwijken, dan maak je een config aan in conf.d met "VerifyHostKeyDNS = [Yes/Ask]".

[moonlander]

Dat hangt dus af van welke versie je geinstalleerd hebt.

Hoewel de VerifyHostKeyDNS-optie momenteel standaard is uitgeschakeld, stond deze tussen september 2013 en maart 2023 wel standaard aan.

En nee niet elk hostingbedrijf heeft de laatste SSH versie erop staan, heb net nog een sharedhosting gecheckt van vimexx en daar zitten ze nog op versie OpenSSH_7.4p1 van 2017

[deadinspace]

Dat hangt dus af van welke versie je geinstalleerd hebt.

Nee, dat is onjuiste informatie in het tweakers artikel. De upstream default was altijd 'no'.

Het heeft tussen september 2013 en maart 2023 default aangestaan op FreeBSD. Niet in upstream OpenSSH, en voorzover mij zo snel bekend geen ander OS.

En nee niet elk hostingbedrijf heeft de laatste SSH versie erop staan, heb net nog een sharedhosting gecheckt van vimexx en daar zitten ze nog op versie OpenSSH_7.4p1 van 2017

Als die security fixes gebackport krijgt dan hoeft dat geen probleem te zijn (onwaarschijnlijk op zo'n antieke versie, maar ok).

En als dat niet zo is, tijd voor een andere hosting. Security updates zijn natuurlijk gewoon een must.

[RobIII]

VerifyHostKeyDNS is een SSH client setting. Kijk dus in ~/.ssh/config (of /etc/ssh/ssh_config).

[Reactie gewijzigd door RobIII op 18 februari 2025 15:43]

[Klauwhamer]

"Een aanvaller kan hierbij de identiteitscontrole van de server omzeilen, ongeacht of deze optie op 'yes' of 'ask' staat ingesteld." Dit leest dramatischer dan het is; default is immers 'no' en je moet bewust dit wijzigen vanuit 'no' naar 'ask' of 'yes' (m.u.v. FreeBSD 2013-2023).

[hcQd]

Yes of Ask zou veiliger moeten zijn aangezien het de handtekening van de server via DNS verifieert in plaats van dat je domweg maar accepteert dat je met de juiste server praat de eerste keer dat je verbinding maakt.

[Soldaatje]

Volgens mij niet hoor, 'no' is veiliger, want dat wordt de sleutel helemaal niet via DNS gecheckt, dus kan er ook niets gespoofed worden.

[hcQd]

Als de sleutel niet geverifieerd wordt hoe weet je dan dat het de juiste is. Hier een uitleg hoe een en ander werkt en waarom het in principe veiliger is, tenzij je natuurlijk fingerprints via een ander kanaal verifieert, maar dat zal zelden het geval zijn.

[aikebah]

... edit... alternatief kanaal had je al staan maar had ik gemist

[Reactie gewijzigd door aikebah op 18 februari 2025 18:50]

[DDX]

In mijn beleving stond dit altijd al aan, lees ook dit bij het artikel :

Hoewel de VerifyHostKeyDNS-optie momenteel standaard is uitgeschakeld, stond deze tussen september 2013 en maart 2023 wel standaard aan.

Iemand enig idee waarom het na maart 2023 is uitgezet ?

[deadinspace]

Dat is foute informatie in het tweakers.net artikel.

Uit het Qualis artikel:

Note: although VerifyHostKeyDNS is disabled by default, it was enabled by default on FreeBSD (for example) from September 2013 to March 2023; for more information:

https://cgit.freebsd.org/src/commit/?id=83c6a52
https://cgit.freebsd.org/src/commit/?id=41ff5ea

De tweakers redacteur heeft dat dus fout overgenomen en "in FreeBSD" weggelaten.

De reden dat het in FreeBSD ook is uitgezet is omdat ze (in 2023) bedachten dat het niet de meest verstandige default was. Commit log:

author Ed Maste <[e-mail]> 2023-02-17 01:26:41 +0000
committer Ed Maste <[e-mail]> 2023-03-01 14:19:07 +0000
commit 41ff5ea22cb95deb9e7415510eb2f5f00b91537a (patch)
tree e2281a253f5851de6914aa02ffc7fa4d11fada15
parent 71af885af9c86a900beec09d98fb9d305c303744 (diff)

ssh: default VerifyHostKeyDNS to no, following upstream

Revert to upstream's default. Using VerifyHostKeyDNS may depend on a
trusted nameserver and network path.

This reverts commit 83c6a5242c80160fff76fb85454938761645b0c4.

Reported by: David Leadbeater, G-Research
Reviewed by: gordon
Relnotes: Yes
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D38648

[Opifex]

Uit nieuwsgierigheid: waarom spreekt het artikel van "Kritieke beveiligingslekken", terwijl beide issues geclassificeerd zijn als Medium? Is er een bron die wél spreekt van critical? Of was dit journalistieke vrijheid van de auteur?

[telenut]

Als er Kritiek in de titel staat zijn er meer lezers...

[Cilph]

Toch redelijk kleine kans dat je kwetsbaar bent. VerifyHostKeyDNS staat standaard uit. Verder is het ook gewoon verstandig om SSH achter een VPN te zetten.

[desalniettemin]

sudo apt update && sudo apt upgrade openssh-client

[DigitalExorcist]

Het issue bestond al sinds 2014.......

[desalniettemin]

Het zal wel.

[DataGhost]

Dat kan net zo goed in closed source gebeuren. De kans dat het dan ontdekt wordt door een van de ontwikkelaars is echt veel kleiner. Zeker als management vindt dat het zoeken naar dat soort dingen, laat staan het oplossen ervan, geen direct financieel voordeel voor het bedrijf heeft omdat het geen verkoopbare feature is.

Zie bijvoorbeeld nieuws: Google-onderzoeker vindt lek dat al 18 jaar in Windows zit

[xxs]

Weet je waarom wij nog steeds op papier stemmen en niet met een computer?

Omdat de broncode niet vrijgegeven werd door de leverancier van de stemmachines.

Maar als jij liever closed source gebruikt ga gerust je gang.

[pennywiser]

Dat gaat echt veel georganiseerder dan jij weergeeft.