Libssh-bibliotheek bevat lek dat omzeilen van authenticatie toelaat

Een beveiligingsonderzoeker heeft een lek in de softwarebibliotheek libssh gevonden, die het ssh-protocol implementeert. Het lek maakt het mogelijk authenticatie te omzeilen op een kwetsbare server. Het aantal kwetsbare servers wordt op zesduizend geschat. Patches zijn beschikbaar.

Op libssh.org is een advisory gepubliceerd die meer details over de kwetsbaarheid met kenmerk CVE-2018-10933 bevat. Zo is het lek aanwezig in versies 0.6 en hoger van de software, waarbij de eerste kwetsbare versie uitkwam in januari van 2014. Volgens de beschrijving bevat de servercode een fout waardoor een aanvaller het bericht 'SSH2_MSG_USERAUTH_SUCCESS' naar de server kan sturen en zo authenticatie kan voltooien zonder gebruik te maken van inloggegevens. De ontdekker van het lek, Peter Winter-Smith van de NCC Group, zegt tegen Ars Technica dat libssh alleen kwetsbaar is in 'server mode' en niet in 'client mode'.

De site publiceert een Shodan-zoekopdracht, waarmee ongeveer zesduizend kwetsbare servers te vinden zijn. Een zoekopdracht van beveiligingsonderzoeker Amit Serper, gespecificeerd op poort 22, levert ongeveer drieduizend kwetsbare servers op. Daardoor lijken de gevolgen beperkt, ook omdat de populariteit van OpenSSH groter is. Een van de grootste sites die gebruikmaken van libssh in server mode, is GitHub, maar deze liet al weten niet kwetsbaar te zijn door het gebruik van een aangepaste versie van de bibliotheek.

Er zijn inmiddels patches beschikbaar in de vorm van versies 0.8.4 en 0.7.6. Libssh is een softwarebibliotheek die voornamelijk in C is geschreven en die het ssh-protocol implementeert. Met ssh is het mogelijk een beveiligde verbinding naar bijvoorbeeld een server op te zetten om deze van afstand te beheren. Een aanvaller die gebruikmaakt van de huidige kwetsbaarheid is daarom in staat om toegang te krijgen tot een server en deze over te nemen.

Reacties (23)

Dus voor de duidelijkheid. het gaat om libssh en niet om openssh.

libssh wordt door andere programma's gebruikt, om ssh mogelijkheden te krijgen.

Daarbij moet het ook nog een server zijn. Bij mij (FreeBSD + libssh2 1.8.0) gebruiken alleen Midnight commander en Rust het client-side. Er zitten geen binary executables in de package, alleen dynamic libs en include bestanden, dus de server-functionaliteit moet je eerst zelf nog construeren.
Het source bestand userauth.c (78K) gebruikt hier als enige de vlag SSH_MSG_USERAUTH_SUCCES, dus zonder de 2. Daarbij staat bij alle voorkomende gevallen expliciet in comments erbij dat de authenticatie succesvol was, op 1 na. Zou dit hem zijn? (regel 136)

if (session->userauth_list_data[0] == SSH_MSG_USERAUTH_SUCCESS) {
/* Wow, who'dve thought... */
_libssh2_error(session, LIBSSH2_ERROR_NONE, "No error");
LIBSSH2_FREE(session, session->userauth_list_data);
session->userauth_list_data = NULL;
session->state |= LIBSSH2_STATE_AUTHENTICATED;
session->userauth_list_state = libssh2_NB_state_idle;
return NULL;
}

Wat ik nou niet begrijp is hoe je dit bericht naar een server "stuurt". Dit is toch uiteindelijk slechts een adres dat refereert naar iets binnen de process-space van een lokale tegen libssh gelinkte executable? Gaat het om de mogelijkheid als normale user lokaal dat bericht naar een draaiend libssh2 component te sturen met je beschikbare user commando's met lokale privilege escalation tot root als mogelijk gevolg?

[Reactie gewijzigd door blorf op 17 oktober 2018 14:12]

.

[Reactie gewijzigd door Bonobo op 17 oktober 2018 22:05]

Het zou wel prettig zijn als ergens een lijstje is met welke daemons/servers/appliances deze library gebruiken.

Voor een goede indicatie kan je gewoon de lijst van afhankelijke pakketten opvragen bij je favoriete Linux distributie. Hier is die voor Arch Linux. Enkele die opvallen: FFmpeg, Kodi, MySQL Workbench, Remmina en Wireshark.

[edit]
Uitgebreidere lijst in de Arch User Repository. Niet veel nieuws. Apache Guacamole en yafc (terminal FTP client) gebruiken het ook.

[Reactie gewijzigd door The Zep Man op 17 oktober 2018 10:47]

Op apt-ondersteunende distros kan je het checken met het commando `sudo apt-cache rdepends libssh-4`. Let wel, dit noemt alle packages die libssh-4 als dependency hebben, niet per se dat je de packages geinstalleerd hebt.

Op geupdate Ubuntu op Windows 10 met WSL krijg ik de volgende lijst:
$ sudo apt-cache rdepends libssh-4
libssh-4
Reverse Depends:
hydra
cockpit-bridge
kodi-bin
yafc
x2goplugin
x2goclient
tmate
remmina-plugin-nx
libguac-client-ssh0
libcsync-plugin-sftp
kodi-bin
kio-extras
remmina
gnugk
|libssh-dbg
libssh-dev

[Reactie gewijzigd door anargeek op 17 oktober 2018 11:19]

Onder ubuntu en andere debian varianten kun je eenvoudig :
sudo apt-cache rdepends libssh-4 --installed
doen.

Dan maken we er een oneliner van.

apt-cache rdepends libssh-4|sed 1,2d| xargs -n1 apt-cache policy |grep -B1 Installed

Nice! Ik moest wel nog `sed 's/^\s*|//'` toevoegen voor `xargs -n1 apt-cache policy` omdat sommige packages een pipe ("|") voor de naam hebben staan, en dan gaat ie alle mogelijke packages in de distro aflopen

het staat op mijn RPi3 met OSMC (Kodi), welke van Raspbian (Debian) afstroomt dacht ik.

versie is 0.7.3-2, dus kwestbaar.

Stel dat ik het wil weggooien (apt remove libssh-4), heb ik toch en hoop packages dat ermee weg zouden zijn. De vraag is welke daarbij als Server draaien [en dan op welke poorten], maar ik vermoed toch meerdere.

Nu de ssh-poort 22, is wel opgevangen door sshd, welke gebruik maakt van openssh (dus niet libssh).

Nu de ssh-poort 22, is wel opgevangen door sshd, welke gebruik maakt van openssh (dus niet libssh).

Aangenomen dat er geen SSH server die gebruik maakt van libssh op een andere poort draait is er niets aan de hand en ben je niet kwetsbaar.

Die voorbeelden zullen voornamelijk in client mode werken. Dus hierbij is er geen risico. Heel misschien Kodi als die zelf een SSH server integreert? In de uitgebreide lijst is Guacamole (remote access framework) wel alarmerend.

Om te weten welke producten als firewalls, accesspoints of andere iot apparaten onveilig zijn is het helaas wat lastiger. Hopelijk geven die fabrikanten snel inzicht aan hun klanten.

Volgens de site van LibSSH:
Github (klik)
X2GO
SFTP van KDE
XMBC
csync
Remmina
GNU Gatekeeper

Verder o.a.:
Wireshark
FFMpeg
Bird
MySQL-Workbench
Cockpit
Yafc
Guacamole

En volgensmij doet Synology ook iets met libssh. Echter 't is alleen kwetsbaar in server-mode dus ik vermoed dat er enkele weggestreept kunnen worden (MySQL Workbench, Yafc bijvoorbeeld; bijna alle?)

[Reactie gewijzigd door RobinF op 17 oktober 2018 10:53]

Synology draait (bij mij iig) een SSH server op de NAS voor management (kan een hoop meer mee dan met de web interface). Als dit op libssh draait, dan heb ik enigszins een probleem. Gelukkig enkel via VPN toegankelijk in mijn geval dus valt alleszins mee, maar toch.

Het is bijzonder weinig, libssh wordt nauwelijks gebruikt. Op mijn Debian Testing systeem zijn de volgende pakketten afhankelijk van libssh (minus wat libjes en headers):

• cockpit-bridge
• gnugk
• gsql-plugins
• hydra
• kde-runtime
• kio-extras
• libguac-client-ssh0
• libopenvas8
• libopenvas9
• libpam-x2go
• libssh-4
• mpv
• mpv-git
• mpv-wsl
• openvas-nasl
• remmina
• remmina-plugin-nx
• tmate
• x2goclient
• x2goplugin
• xbmc-bin
• yafc

Dit zijn vooral client applicaties, geen servers die 24/7 aan het netwerk staan te wachten op een verbinding. Wat dat betreft lijkt de impact mee te vallen.

[Reactie gewijzigd door CAPSLOCK2000 op 17 oktober 2018 16:40]

Er zijn niet veel servers die libssh gebruiken. De voorbeelden die mensen hier noemen zijn in het algemeen clients, en daar maakt het niet uit.

Qua servers heb je github (maar daar is het al gepatched). En verder zijn er blijkbaar nog een aantal andere appliances die het gebruiken. Linux en mac zullen in het algemeen openssh gebruiken.

Je kan ook je eigen netwerk scannen, bijvoorbeeld met `nmap -sV $netwerk -p 22`

Voor zover ik het begrijp zijn servers die weliswaar gebruik maken van LibSSH, maar User/Password authentication uit hebben staan en enkel PKI-authenticatie toestaan, niet kwetsbaar.

Software is inmiddels gewoon toegestaan in de Nederlandse taal:
https://www.vandale.nl/gr...nis/software#.W8b0zVR1rs8

Zoals anderen al aangaven, software is een geaccepteerd leenwoord. Jouw voorstel is sowieso erger dan het probleem dat je ermee dacht op te lossen; je kunt idioom niet zomaar letterlijk vertalen zonder dat de betekenis verdwijnt of verandert. Denk bijvoorbeeld aan een woord als acteren, dat toneelspelen betekent maar soms letterlijk uit het Engels wordt overgenomen, waar het handelen, handelend optreden of actie ondernemen betekent.

En als je software dan toch perse wilt vertalen, gebruik dan (computer) programma

In dit geval 'programmabibliotheek'.