Software-update: OpenSSH 9.8

OpenSSH logo (Über pix) Versie 9.8 van OpenSSH uitgekomen. OpenSSH versleutelt het netwerkverkeer om afluisteren, het overnemen van de verbinding en andere netwerkaanvallen tegen te gaan. Daarnaast bevat het de mogelijkheid om zogenaamde veilige tunnels op te zetten en ondersteunt het verschillende authenticatiemethodes. OpenSSH is primair ontwikkeld voor OpenBSD; gebruikers van andere besturingssystemen kunnen hier terecht. In deze uitgave zijn twee beveiligingsproblemen verholpen. Meer hierover is op onze voorpagina te lezen.

Security

This release contains fixes for two security problems, one critical and one minor.

  • Race condition in sshd
    A critical vulnerability in sshd was present in Portable OpenSSH versions 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.
    We thank the Qualys Security Advisory Team for discovering, reporting and demonstrating exploitability of this problem, and for providing detailed feedback on additional mitigation measures.

  • Logic error in ssh ObscureKeystrokeTiming
    In OpenSSH version 9.5 through 9.7 (inclusive), when connected to an OpenSSH server version 9.5 or later, a logic error in the ssh ObscureKeystrokeTiming feature (on by default) rendered this feature ineffective - a passive observer could still detect which network packets contained real keystrokes when the countermeasure was active because both fake and real keystroke packets were being sent unconditionally.
    This bug was found by Philippos Giavridis and also independently by Jacky Wei En Kung, Daniel Hugenroth and Alastair Beresford of the University of Cambridge Computer Lab.
    Worse, the unconditional sending of both fake and real keystroke packets broke another long-standing timing attack mitigation. Since OpenSSH 2.9.9 sshd(8) has sent fake keystoke echo packets for traffic received on TTYs in echo-off mode, such as when entering a password into su(8) or sudo(8). This bug rendered these fake keystroke echoes ineffective and could allow a passive observer of a SSH session to once again detect when echo was off and obtain fairly limited timing information about keystrokes in this situation (20ms granularity by default).
    This additional implication of the bug was identified by Jacky Wei En Kung, Daniel Hugenroth and Alastair Beresford and we thank them for their detailed analysis. This bug does not affect connections when ObscureKeystrokeTiming was disabled or sessions where no TTY was requested.

OpenSSH dinges (481 pix)

Versienummer 9.8
Releasestatus Final
Besturingssystemen Windows 7, Linux, BSD, macOS, Solaris, Windows Server 2012, Windows 8, Windows 10, Windows Server 2016, Windows Server 2019, Windows 11
Website OpenSSH
Download https://ftp.openbsd.org/pub/OpenBSD/OpenSSH/
Licentietype GPL

Door Bart van Klaveren

Downloads en Best Buy Guide

02-07-2024 • 09:34

40

Bron: OpenSSH

Update-historie

07-'24 OpenSSH 9.8 40
10-'23 OpenSSH 9.5 4
05-'22 OpenSSH 9.0 1
10-'21 OpenSSH 8.8 0
04-'19 OpenSSH 8.0 4
03-'15 OpenSSH 6.8 1
03-'10 OpenSSH 5.4 12
10-'09 OpenSSH 5.3 9
02-'09 OpenSSH 5.2 7
07-'08 Openssh 5.1 3
Meer historie

Reacties (40)

40
40
33
1
0
7
Wijzig sortering
Deze patch maakt het werk van security engineers weer goed spannend vandaag |:(
Hoezo? Wie hangt er nou port 22 openbaar aan het internet zonder verdere maatregelen?
Je zult toch *iets* aan Internet moeten hangen om beheer te doen.
Is het niet SSH dan is volgende keer weer een of andere VPN service lek.
Of je gebruikt Tailscale, ik heb geen poorten open, al het verkeer restricted tot het Tailnet (tenminste, voor beheer, wel 443 open voor wat dingetjes).

`sudo ufw allow in on tailscale0`
`sudo ufw default deny incoming`

Wel altijd heel erg uitkijken met docker (compose), met de "ports" optie zet Docker zo heel behulpzaam alles weer open op je standaard interface, het overschrijft wat je met UFW instelt.

[Reactie gewijzigd door teek2 op 22 juli 2024 14:16]

En dan draai je vervolgens Docker die heel ufw bypassed en regels in iptables / nftables gooit :+
Daarvoor kun je dan weer heel mooi de Docker config aanpassen om dat niet te doen:
/etc/docker/daemon.json
{
"iptables": false,
"ip6tables": false
}
(Note: ip6tables staat pas default aan sinds Docker 27, en die is pas een paar dagen/weken uit. De setting bestaat denk ik wel al langer)

Overigena heeft Docker ook helemaal geen nft / nftables support. Maar de kernel en iptables tools zijn AFAIK wel compatible met nftables. Of in ieder geval is er een implementatie van de iptables tools (iptables, ip6tables, ipset naar ik aanneem) die in werkelijkheid de nftables kernel interfaces aanspreken. Of de oude iptables kernel interface nog bestaat (en mapt naar nftables) weet ik niet met 100% zekerheid. Daardoor dat Docker wel kinda half werkt met nftables. Maar of dat wenselijk is is een ander verhaal. Docker is echter wel compatible met de hoger gelegen firewalld daemon / toolset (die op zijn beurt AFAIK ook nftables compatible is).

Edit:
Verzin de juiste JSON syntax voor het config voorbeeld zelf maar. Want blijkbaar mag een code tag niet op de frontpage 8)7

[Reactie gewijzigd door RobertMe op 22 juli 2024 14:16]

Zeker! Ik weet heel goed hoe het op te lossen is. Maar het probleem is vooral dat lang niet iedere Docker gebruiker op de hoogte is van dit probleem.

Dát zou opgelost moeten worden. Standaard aanpassen of een extra prompt voorschotelen breekt veel te veel. Maar dat duidelijk op het scherm "printen" met een link naar uitgebreidere documentatie is wellicht de beste manier.
Ja, goed uitkijken altijd. Bij Linode heb je gelukkig nog een cloud-firewall (waar Docker niet aan kan zitten natuurlijk), maar in onze huidige decentrale org hebben we wel al eens porten aan 1 of ander lokaal lan blootgesteld terwijl we echt alles proberen op het Tailnet te houden.

Ik ben wel aan het spelen met podman, ik denk dat je dat daar niet hebt? Je bent iig niet standaard Root...

[Reactie gewijzigd door teek2 op 22 juli 2024 14:16]

Ik ben zelf niet echt bekend met Linode. Staat die firewall standaard aan? Dat is wel een goede ontwikkeling uiteraard, maar dit is wel iets wat door Docker opgelost moet worden. En niet door IaaS providers of door projecten dke Docker gebruiken.
Ik ben wel aan het spelen met podman, ik denk dat je dat daar niet hebt? Je bent iig niet standaard Root...
Podman werkt - desondanks het een behoorlijk close drop-in replacement is - volgens een wat andere attitude. Ik geloof dat die UFW bypass op Podman niet speelt omdat je forwarding zelf moet fixen - maar ben daar niet helemaal zeker van.

Met Docker, Podman en LXC ben ik niet heel bekend - desondanks decennia aan Unix en netwerk ervaring (gebruik nauwelijks Linux).
Of, mocht je tegen Tailscale limieten aanlopen: zrok / OpenZiti. :)
Integreert ook erg mooi in je cluster als een container bijvoorbeeld, kan je het cluster ook dichtzetten en alleen bereikbaar maken over het OpenZiti / zrok overlay netwerk.
Ik ken best veel van dit soort partijen, maar ook dat komt met gevaren (niet om vervelend te doen, maar dit is hardop denken). Heb ze zelf ook wel eens gebruikt (Tailscale toevallig niet, maar ik ken het principe dus. Heb ze wel even opgezocht).

Ondanks dat je in je eigen firewall geen poort open hebt, zet je theoretisch wel alles open naar zo'n Tailscale 'netwerk', want het is gewoon een soort VPN-in-the-middle. En op dat moment ben je dus afhankelijk van je vertrouwen in zo'n partij én vooral dat zij nooit een lek hebben dat kan worden misbruikt door een derde persoon. Of als je Tailscale account compromised raakt. Selfhosten met Headscale gaat het doel van dit verhaal ook een beetje voorbij want daarvoor moeten weer poorten open. En Tailnet Lock geeft in het geval van Tailscale meer zekerheid aan de voorkant maar nog steeds niet als het achterliggende systeem misbruikt wordt, lijkt me. En je bent echt verder van huis op het moment dat er op je Tailscale netwerk ingebroken is, dan dat je een poort open hebt staan op het moment dat er op de service die erachter draait geen actief misbruikte exploits zitten, lijkt me. Een vreemde die erin komt kan namelijk ook bij die poort plus nog een heleboel meer.

Dit is best leuk om af en toe te verbinden naar iets wat thuis draait, maar of je dit in alle situaties moet willen inzetten over een open poort weet ik niet. Een open poort is min of meer zo veilig als de service die erachter draait. Als er al iets achter draait. Het is geen open voordeur ofzo, zoals het vaak wel wordt geschetst. Het is meer een soort openbare plek die alleen open is tijdens draaiuren, en de veiligheid is afhankelijk van de getroffen maatregelen.
Jawel maar dan whitelist je de benodigde IPv4 en IPv6 ranges van je admins.
Ga je dan van iedere werknemer het IP adres van de internetverbinding thuis in je firewall configuratie opnemen, die bovendien ook nog wel eens willen wijzigen? Dat lijkt me geen schaalbare oplossing.
Je maakt een lijstje van de IPv4 adressen van degenen die toegang moeten hebben. Evt. ranges. Evt. hou je zoiets bij in git. Die lijst zet je dan in je jumphost in de allow list van de firewall en de users en pub keys in de allow list van SSH. Geen hogere wiskunde.

Er zijn waarschijnlijk ook geen tientallen mensen die SSH toegang nodig moeten hebben. Als dat wel zo is, doe je m.i. toch iets goed fout als organisatie.

[Reactie gewijzigd door Jerie op 22 juli 2024 14:16]

Inderdaad geen hogere wiskunde, behoorlijk triviaal zelfs zou ik willen stellen. Maar zolang mijn ISP nog op elk moment het uitgaande IP adres van mijn verbinding kan wijzigen naar iets in een totaal ander subnet (tijd geleden nog gebeurd bij Odido), is het geen geweldige oplossing want je bent dat van de ene op de andere dag buitengesloten.

Daarnaast schaalt de oplossing niet. Ik werk in een omgeving met zo'n 50 beheerders van verschillende disciplines (Linux, DBA, applicatiebeheer) en die hebben wel allemaal SSH toegang nodig. Nee daar gaat niets mis.
Tegenwoordig werken mensen vanaf hun mobiele telefoon smartphone of tablet, die hebben ook geen vast IP adres. Ik geef gewoon een andere poort door. Dat zorgt al voor een vermindering van ongewenste connecties met meer dan 95%. De configuratie is gehardend zodat men geen 10.000 pogingen kan uitvoeren. Dat is gemiddeld nodig volgens de publicisten van de laatste lek.
Bor Coördinator Frontpage Admins / FP Powermod @mrmrmr7 juli 2024 10:19
De configuratie is gehardend zodat men geen 10.000 pogingen kan uitvoeren.
Dan kijk je over een belangrijk punt heen; die 10.000 pogingen is nameijk on average

Er kunnen veel meer maar ook veel minder pogingen nodig zijn om de race condition te winnen.
@Bor Ik schreef: "Dat is gemiddeld nodig volgens de publicisten van de laatste lek."

[Reactie gewijzigd door mrmrmr op 22 juli 2024 14:16]

Bor Coördinator Frontpage Admins / FP Powermod @mrmrmr7 juli 2024 13:20
Dat schreef je inderdaad. Als je echter hardened op een manier dat er geen 10.000 pogingen uit gevoerd kunnen worden mitigeer je mogelijk de aanval niet gezien het aantal pogingen voor een geslaagde aanval vele malen lager kan liggen. Dat is wat ik bedoel.
Het bericht waar je op reageert bevat een stijlfiguur, er is niemand die 10.000 pogingen gaat toelaten en dat hardenen noemt. Je moet dat dus niet letterlijk nemen, hardening levert een veel lager aantal op. De verantwoording van het aantal ligt bij de publicisten van dat lek, niet bij mij.

Overigens is het in dit geval zo dat de code waarin de race condition zit niet bereikbaar wordt als er helemaal geen LoginGraceTime beperking is. Dat is contra-intuitief voor de meesten onder ons.
Beste optie is dat je werkgever een bastionhost opzet (Win/Linux) met 2FA gekoppeld aan je admin account, vanwaar je je servers kan benaderen om je beheer te doen. Het liefste ook nog eens met een speciaal admin account inloggen op die bastionhost, een account dat dus niet gelijk is aan het account waarmee je op je computer inlogt.

Hoef je ook niet bij te gaan houden wat eenieder zijn/haar IP adres thuis is.
Daarnaast kan je ook nog een specifieke VPN verbinding vereisen indien je niet fysiek op kantoor zit om überhaupt bij de bastionhost te kunnen komen. Ook daar inloggen met 2FA, dat gekoppeld is aan je gewone account.

[Reactie gewijzigd door SebasFM op 22 juli 2024 14:16]

Dat is inderdaad een veel beter oplossing en de meeste organisaties waarin ik gewerkt heb functioneren op die manier, namelijk met een bastionhost ook wel jumphost genoemd, die eventueel nog extra is afgeschermd met een VPN. Maar ik reageerde dan ook op de oplossing van Jerie om alle thuis-IP-adressen van je werknemers te gaan whitelisten. Naast niet praktisch is dat ook nog eens gevoelig voor fouten en bovendien blijft je IP-adres thuis niet eeuwig hetzelfde.

Overigens ben ik nooit zo'n voorstander van het introduceren van extra accounts, zeker niet als dat extra account ook admin rechten heeft. Je kunt best toe met 1 account waarop je sterke wachtwoorden en 2FA afdwingt, die je vervolgens met HBAC toegang geeft tot specifieke servers en services binnen je netwerk waarop ze vervolgens door middel van RBAC wel of geen admin rechten hebben. En de admin rechten gaan uiteraard altijd via een "elevate privileges" prompt of sudo. Complexer om goed op te zetten maar als het eenmaal werkt heb je er veel plezier van.

Overigens heeft als je goed gebruikt maakt van automatisering met bijvoorbeeld Ansible en een Tower vrijwel niemand admin rechten nodig, alleen de gebruiker waaronder Ansible Tower zijn wijzigingen uitvoert.
Niet van 'alle werknemers' maar degenen die toegang moeten hebben.

Twee werkgevers terug gebruikten we beiden. Dus bastionhost/jumphost en whitelist. Maar dat was een kleine toko. De rest had VPN met 2FA nodig, was blijkbaar conform ISO27001.

Bij vorige werkgever betrof het klein team, ook makkelijk om te whitelisten, maar was geen sprake van een jumphost. Gewoon de paar devs die het nodig hadden, waren gewhitelist.

Vergeet niet dat whitelist best wat ruimer mag zijn. Het is namelijk slechts een layer, de rest van de layer is SSH authenticatie en dat is veilig zat. Alleen in deze specifieke situatie niet.
Shell scriptje dat wacht op een bepaalde string op een poort en daarna pas iets open zet.
Praktisch iedere VPS provider.
Dan kun je zelf je sshd.conf aanpassen toch?
De huurder van een VPS ("je" in jouw vraag) kan dat. Maar doet die dat?

Dat is het probleem wanneer niet secure by default wordt toegepast.
Shared responsibility lijkt mij dat. Als je een VPS huurt maar weinig tot geen verstand van hebt hoe je zo iets moet beveiligen/beheren.
Ja wie zijn schuld is dat dan.
Moet iemand zonder technische beheerkennis uberhaupt een VPS willen huren?
Het perfecte recept om binnen de kortste keren onderdeel uit te maken van een botnet.
De discussie was wie dit doet, niet wie de "schuld" draagt.

Verder ben ik een fan van secure by default/design. Dan moet een (aanwijsbare) partij een actieve actie doen om iets onveilig te maken.
hoeft niet perse via het internet te komen, ik zou als ik kwaad zou willen een laptop van iemand compromitteren en dan als die op het interne netwerk zit dan gaan kijken waar ik bij kan komen via poortje 22

dat zal je verbazen hoeveel organisaties de management interfaces van de spullenboel 'gewoon' open hebben staan vanaf het internet client-netwerk.
Beetje een afgewogen risico. Beheer meerdere VPS'en, die allen bereikbaar zijn op poort 22. Als je services draait die open staan voor de buitenwereld komt dit altijd zo nu en dan voor.
Wel fail2ban er op, en een firewall voor zo'n beetje iedere andere poort, ook om te voorkomen dat iets per ongeluk open staat.
Zelf sta ik meer te kijken van cloudbased wachtwoord-tools ;)
Ook intern wil je toch niet dat alle users zomaar overal in kunnen met full root access? En ja, de meeste users gebruiken hier SSH voor hun dagelijkse werk.

Ook als je netwerk al gecompromitteerd zou zijn, wil je ook niet dat al de rest zo lek is als een zeef.

Dus intern patchen: ja!
Hoezo? Waren gisteren al beschikbaar voor zo ongeveer alle linux distributies (security update, bestaande versie met patch voor de kritieke bug). In 5 minuten uitgerold op alle systemen met ansible.

Het spannende in deze versie zelf is dat ze de sshd binary gesplitst hebben in 2 losse binaries. Eentje voor de listener en eentje voor de daadwerkelijke afhandeling. Als je deze versie zo over de oude heen klapt zonder de service opnieuw te starten kom je niet meer in je systeem, aangezien de oude versie de listener probeert op te starten voor taken die het niet begrijpt.
Ter info: Ubuntu LTS versies tot en met 20.04 waren niet kwetsbaar (en zijn dat nog steeds niet) omdat ze een oudere versie draaien van OpenSSH.
En debian 12?
debian 12 volgens mij wel ik had gisteren een update beschikbaar voor openssh-server
Debian 12 / Bookworm is/was vatbaar. Gisteren is daarvoor een update uitgekomen. Je moet daarvan de versie hebben die in ieder geval eindigd op "u3" (waarbij ikzelf "u2" geïnstalleerd had staan, verder was het versienummer IIRC identiek).
Is RHEL 8 eigenlijk vulnerable? Edit: SSH 8.0p1 zo te lezen niet.

[Reactie gewijzigd door pennywiser op 22 juli 2024 14:16]

Op dit item kan niet meer gereageerd worden.