Samba waarschuwt voor een zeer ernstige kwetsbaarheid in zijn SMB-software

Samba, de ontwikkelaar van de gelijknamige gratis serverdaemon, waarschuwt voor een ernstige kwetsbaarheid die aanvallers in staat stelt code uit te voeren met rootprivileges. De kwetsbaarheid heeft een CVE-score gekregen van 9,9 van de 10.

De kwetsbaarheid, die de CVE-code 2021-44142 gekregen heeft, zit in elke versie van Samba voor versie 4.13.17. Het gaat om een out-of-bounds heap read write-kwetsbaarheid waardoor aanvallers op afstand arbitraire code kunnen uitvoeren als root op Samba-installaties die gebruikmaken van de vfs-module vfs-fruit. Die module wordt gebruikt voor communicatie tussen Apple SMB-clients en een Netatalk 3 afp-fileserver. De kwetsbaarheid is zeer ernstig en Samba roept dan ook op zo snel mogelijk de software te updaten.

De kwetsbaarheid ontstaat tijdens het parsen van ea-metadata als files geopend worden in smbd. Om de kwetsbaarheid te misbruiken, moet de aanvaller wel aanvullende write-toegang voor de files hebben, maar Samba schrijft dat een aanvaller dat als gastgebruiker of ongeautoriseerde gebruiker kan krijgen.

Dat betekent dat aanvallers die de kwetsbaarheid misbruiken, geen authenticatie nodig hebben om arbitraire code uit te voeren in Samba. De aanvaller kan vervolgens met roottoegang code uitvoeren in de smbd-daemon. Het Zero Day Initiative legt in een blogpost uit hoe de kwetsbaarheid vervolgens misbruikt kan worden via een heap out-of-bounds read write en een bufferoverflow. Volgens het CERT Coordination Center heeft de kwetsbaarheid ook gevolgen voor Red Hat, SUSE Linux en Ubuntu.

Hoewel Samba vooral aanraadt de software te updaten, heeft het ook een workaround online gezet. Samba legt uit dat het mogelijk is om de vfs-module fruit uit de lijst te halen met geconfigureerde vfs-objecten, op alle plekken in de Samba-configuratie waar fruit genoemd wordt. Dit heeft wel ernstige gevolgen voor macOS-systemen die de Samba-server proberen te benaderen. Samba waarschuwt dat als fruit:metadata of fruit:resource aangepast wordt, dit ertoe kan leiden dat opgeslagen informatie niet toegankelijk is, of dat het eruitziet alsof macOS de informatie kwijt is. De Zero Day Initiative raadt de workaround af en roept gebruikers op te focussen op updaten en de patch testen.

De kwetsbaarheid werd door verschillende onderzoekers ontdekt. De Taiwanese onderzoeker Orange Tsai wordt door Samba erkend als de ontdekker. De exploit werd in november getoond door Thach Nguyen Hoang en Billy Jheng Bing-Jhong tijdens Pwn2Own Austin 2021, waar ze 45.000 dollar wonnen voor het gebruiken van de exploit. Het heeft dus even geduurd voordat Samba een update had voor de kwetsbaarheid.

Door Stephan Vegelien

Redacteur

02-02-2022 • 10:52

74

Submitter: Hakker

Reacties (74)

74
74
53
3
0
8
Wijzig sortering
Linux gebruikers kunnen via het volgende commando hun samba versie checken:

smbstatus

De bovenste regel geeft het huidige versie nummer.
Mijn Synology NAS op DSM 7 heeft versie 4.10.18 en is dus kwetsbaar.
Enkel als de fruit-module ook gebruikt wordt, en gegeven dat Synology zelf aangeeft dat 7.x niet vatbaar is lijkt het er op dat die module niet gebruikt wordt.
Hier inderdaad ook v4.10.18 op DSM7. Toch even rondsnuffelen om die te updaten.
De security pagina van Synology zegt dat DSM7 niet vatbaar is.

Enkel DSM6.2 en hiervoor is een update beschikbaar.
Voluit:

sudo smbstatus
sudo apt update
sudo apt install samba
sudo smbstatus
Waarom samba installeren? Als je het niet installed en niet nodig hebt heb je geen lek lijkt me?
Natuurlijk maar daarmee krijg je met smbstatus ook al niks terug. @savale Een install is een update. Als je geen samba wilt moet je het natuurlijk niet installeren.
Install kan beter upgrade zijn
Install kan beter 'remove' zijn ;)
Maken veel NAS-systemen onderwater niet ook gebruik van Samba? Hoe kan ik er in dat geval achter komen of deze ook gebruik maken van de module?
Voor Synology systemen moet je bij versie 6.X van DSM upgraden. Versie 7 is niet vatbaar: https://www.synology.com/...dvisory/Synology_SA_22_02
Uit je link begrijp ik dat niet alles van 6.X vatbaar is, maar er moet wel geupgrade worden naar "6.2.4-25556-4 or above." (Of versie 7 natuurlijk)

Wel stom.. die van mij zit nog op 6.2.4-25556-3 en er is via de GUI nog geen update beschikbaar naar 4.

Hier is versie 4 handmatig te downloaden zodat die toch geinstalleerd kan worden
https://archive.synology.com/download/Os/DSM/6.2.4-25556-4
Dat klopt, hier net zo.
Update 4 is minder dan een week oud en Synology rolt altijd geleidelijk uit. Dus afhankelijk van het model kan het wel tot twee weken duren na het uitkomen van een update/release. Misschien gaan ze wat meer haast maken, nu dit in het nieuws is.
Misschien gaan ze wat meer haast maken, nu dit in het nieuws is.
Synology's eigen threat report geeft aan dat om deze exploit uit te buiten, de aanvaller sowieso al geauthenticeerd moet zijn. Dus als je de guest account uit hebt staan - wat de in DSM ingebouwde Security Advisor tooling ook aanraadt - moet men sowieso eerst al de username en het password van een gebruiker weten; of moet er van een keten-aanval sprake zijn waar er malware op een ander device gezet wordt, wat wacht totdat er een geauthenticeerde verbinding met SMB tot stand is gebracht vanaf dat apparaat.

Beetje een storm in een glas water.

[Reactie gewijzigd door R4gnax op 23 juli 2024 14:07]

Wel knullig ja dat je die dan handmatig moet installeren.
En het is niet alsof die net uit is ;

Version: 6.2.4-25556 Update 4
(2022-01-27)

https://www.synology.com/...M?model=DS416#ver_25556-4
Bedankt, ik heb de patch handmatig toegepast. Niet eens een reboot nodig (wat ik normaal wel altijd heb bij een update).
Dank je voor de link! Zojuist mijn DS213 handmatig geüpdatet naar versie 6.2.4-25556-4.
Enig idee waarom DSM7 niet vatbaar is? Als ik het dsmstatus commando run op een Syno met DSM 7 krijg ik Samba versie 4.10.18 terug, wat zou impliceren dat het wel vatbaar is.
Anoniem: 1322 @Volk2 februari 2022 14:05
De kwetsbare module wordt blijkbaar niet in DSM7 gebruikt.
Merk op dat het hierbij nodig kan zijn om de update handmatig van de synology-site te downloaden. Mijn NAS-interface zelf gaf aan dat de laatste versie geïnstalleerd was, maar dat bleek dus niet het geval...
De laatst beschikbare update voor mijn Synology is DSM 6.2.4-25556 Update 3, terwijl het volgens de link update 4 zou moeten zijn : (

[Reactie gewijzigd door bramgozer op 23 juli 2024 14:07]

Iemand een idee of QNAP hier ook kwetsbaar voor zijn?
Zie nog geen berichten erover vanuit QNAP, maar dat hoeft natuurlijk niks te betekennen.
Ja, QNAP lijkt helaas vulnerable, nog geen workaround.
Via SSH geeft smb2status versie 4.13.14
En in /etc/smb.conf is "fruit" een van de vfs objects
Ik ga proberen de fruit module uit te zetten totdat QNAP een update pusht.
Op mijn QNAP systeem (dat nog wel draait op het oudere QTS 4.3.4) heb ik in /etc/smb.conf fruit uit de vfs objects gehaald, maar na het herstarten van Microsoft Networking staat het er gewoon weer bij.
Anoniem: 1322 @Boydh2 februari 2022 14:07
De meeste NASsen (en daarnaast SANs) maken gebruik van Samba om SMB shares aan te bieden. Het is dus verstandig om die services voor nu te blokkeren tot de leverancier duidelijkheid geeft.
Weinig betrouwbare manier om natuurlijk al je Samba servers te vinden, maar volgens mij draait Samba standard op poort 445.

Een andere methode is om onderstaande in Linux in terminal te proberen.
nmblookup __SAMBA__
Conform de laatste beveiligings tips voor de diverse nas apparaten: zorg er voor dat ze niet vanaf internet benaderbaar zijn. Als je dan op je eigen netwerk weet wat er op is aangesloten, is de kans op problemen via deze route erg klein.

Wil je dat je nas wel via internet beschikbaar is, gebruik dan vanaf je eigen buiten-apparatuur een vpn verbinding naar huis. En doe de verbinding vooral niet via smb/samba (windows-)shares of wat daar dan op lijkt, hoe makkelijk het ook is. Deze verbinding is nooit bedoeld om via het grote boze internet ontsloten te worden. Deze verbinding kan natuurlijk wel via de vpn lopen.
Ik lees dit keer op keer weer.
Vooraf gesteld, dit is zeer zeker goed advies en vooral onesize fits all en goed beginners advies.
Echter vind ik het wel een beetje bangmakerij en niet conform de werkelijkheid.
Ik draai ondertussen al bijna 10 jaar een eigen server (zelfbouw, geen NAS, op Ubuntu gebaseerd) die al die tijd bereikbaar is geweest op het internet. Draai er een aantal eigen sites op en een hele zooi aan services.
Het is een kwestie van de beveiliging goed op orde hebben, waarbij je heel ver kan gaan en de web services/sites 1 van de belangrijkste schakels zijn (want dat is over het algemeen de eerste horde). Die beveiliging loopt over meerdere lagen (van netwerk en firewalls tot filesystem, en web services etc) en alle moet je begrijpen en wat mee.
Maar! Ik ben ook geen super interessant target (1 alledaags persoon) en zolang ik veel laag hangend fruit af kan slaan qua aanvallen (al het gescript en niet super targeted attacks) gaat het prima.
Ook scheelt het een beetje om voor een wat uniekere opzet te gaan dan een NAS. Het exploiten van een product dat vaak verkocht wordt is veel interessanter om geautomatiseerd op te zetten (scripten) dan 1 specifiek target met al zijn eigen eigenaardigheden (en mogelijke kwetsbaarheden). Dat is enigzins security through obscurity maar helpt wel mee in het geheel (niet het enige waar je op moet vertrouwen alleen).

En ja, SMB open en bloot op het internet knallen valt wel onder dat laag hangend fruit en is ongelofelijk dom.

Al met al dus zeker advies in een vorm van "better safe than sorry". Maar het gevaar wordt vaak zwaar overdreven in een thuis (servertje) context.

[Reactie gewijzigd door jozuf op 23 juli 2024 14:07]

Je hebt groot gelijk, zeker als je zelf een server hebt opgebouwd en je bewust bent van wat je doet en wat de gevolgen kunnen zijn.

Uit eigen ervaring weet ik dat zelfs jij en ik interessant zijn. Bijvoorbeeld als onderdeel van een ddos systeem. Onze systemen hoeven maar een beperkt aantal acties uit te voeren en dat hoeft ons helemaal niet te raken, een ping sturen we allemaal wel eens naar internet. Maar onze systemen zijn wel onderdeel van de hele ddos aanval.
Aan de andere kant: waar de grote bedrijven worden versleuteld en grote bedragen worden gevraagd, wordt ook de kleine man op een vergelijkbare manier aangevallen. Hierbij zijn de bedragen die ze durven te vragen in de regel zo hoog dat ze proberen jou te overtuigen te betalen.
Als je FreeNAS/TrueNAS gebruikt kan je updaten naar versie 12.0U8: https://www.truenas.com/docs/releasenotes/core/12.0u8/
Kans is groot: het is zo ongeveer de enige fatsoenlijke oplossing om Linux bestanden te laten delen in een Windows netwerk..
Wel de meest gebruikte, denk ik, maar is filesharing via NFS ook geen mogelijkheid?
Technisch gezien kan Windows NFS shares mounten inderdaad. In de praktijk zou ik me hier niet aan willen wagen. Toegang tot bestanden op de NFS share werkt namelijk op basis van het user ID op de server en Unix user ID's zijn totaal anders dan Windows user ID's. Als je alleen leestoegang wilt tot de share is het niet zo'n probleem, maar als je ook wilt schrijven moet je een mapping maken van de UID's en dat wordt al snel complex. Een work-around is de Windows client anoniem schrijftoegang geven tot de share, maar dat wil je eigenlijk niet vanuit een beveiligingsperspectief. En dit is nog maar 1 van de issues waar je tegenaan gaat lopen.

Kort gezegd, voor de meeste gebruikers zal het gebruik van NFS op Windows te complex zijn en de moeite niet waard. Samba is veel eenvoudiger om op te zetten en werkt op Windows minstens net zo goed (lees: snel), waarschijnlijk zelfs beter (lees: sneller, want SMB in Windows is beter geoptimaliseerd dan NFS).
Linux plus LDAP plus NFS en Windows Active Directory kun je prima werkende oplossingen creëren. Maar als je veel Windows en weinig Linux systemen hebt is SMB inderdaad eenvoudiger op te zetten en te beheren.
Linux plus LDAP plus NFS en Windows Active Directory kun je prima werkende oplossingen creëren.
Je hebt helemaal gelijk, maar zelfs voor veel Tweakers die wel een thuisservertje of NAS draaien gaat het inrichten van directory services toch net even een stapje te ver.
ksmbd begint ook langzaam een optie te worden maar is helaas nog niet echt stabiel is mijn ervaring. Leuk voor thuisnetwerk (en voor diegene die RDMA willen gebruiken) maar verder nog niet echt af voor serieus gebruik.

Oficieel word windows-to-linux rdma overigens niet ondersteunt maar het werkt wel.
Voor FreeBSD wel. Die van Linux was vziw (10 jaar geleden toen ik het laatst geprobeerd had) nogal eenkenning.
Om NFS op windows te gebruiken moet je een pro licentie hebben.
Maar in een Windows netwerk hoef je geen Macs te gebruiken.
Die module wordt gebruikt voor communicatie tussen Apple SMB-clients en een Netatalk 3 afp-fileserver.

(...)

Hoewel Samba vooral aanraadt de software te updaten, heeft het ook een workaround online gezet. Samba legt uit dat het mogelijk is om de vfs-module fruit uit de lijst te halen met geconfigureerde vfs-objecten, op alle plekken in de Samba-configuratie waar fruit genoemd wordt.
Volgens mij wordt in standaard Samba configuraties in bijvoorbeeld Debian en Arch Linux deze module niet gebruikt, en is het systeem dus niet kwetsbaar. In documentatie wordt gerefereerd naar deze voorbeeldconfiguratie, en daar staat fruit niet in.

[Reactie gewijzigd door The Zep Man op 23 juli 2024 14:07]

En dat is niet Linux zijn schuld... even voor de duidelijkheid ;)
Niet de eerste problemen met SMB.. Ik zie nog zoveel Windows servers met SMB1 actief....
"Gelukkig" lijkt het alleen systemen te treffen die "fruit" VFS gebruiken. Op mijn Ubuntu 21.10 met Samba 4.13.14 staat dit mooie stuk in de man page:
Default: vfs objects =
Default lijkt het dus niet enabled te zijn
Dubbelcheck even met testparm of de default ook nog actief is.
Als volgt?
testparm --parameter-name="vfs objects"
Heb testparm nog nooit hoeven te gebruiken.

[Reactie gewijzigd door Mitsuko op 23 juli 2024 14:07]

Dat werkt inderdaad, geeft bij mij (na op enter drukken) "shadow_copy2 widelinks catia fruit qnap_macea streams_depot"
Klopt, ik moest fruit handmatig aanzetten. Samba op macOS werkt een stuk beter met fruit.
Das logisch. Een appel is een fruit ;)
Sowieso handig om je installs te hardenen en alle functies die je niet hard nodig hebt gewoon uit te zetten en software wat je niet nodig hebt te prunen. Ik ken geen omgevingen waar CIFS en AFS samen worden gebruikt. Snap ik goed dat dit een aannemelijke scenario zou zijn om een kwetsbare configuratie aan te treffen?
Heeft dit alleen te maken met Apple producten, of allerlei Linux systemen die in een Windows netwerk zitten?
De kwetsbaarheid zit in Samba, in de module die toegang biedt aan Applesystemen. Dus in de server, niet in de cliënt.
Besef dat dat de definitie van "server" is, degene die de files deelt. Ook je goedkope mediaspeler kan files delen met een "server"
Het heeft te maken met Linux systemen die ook aan Apple clients file shares aan willen bieden. Als die mogelijkheid open staat bestaat de kwetsbaarheid, of er nou Apple clients in het netwerk voorkomen of niet.
Rare vraag maar in "Raspbian GNU/Linux 10 (buster)" geeft die "Samba version 4.9.5-Debian" hoe kan ik die naar een hogere versie forceren. (alhoewel er maar 2 mensen in huis zijn ben ik gewoon nieuwsgierig)
Het lijkt erop dat er nog geen fix is voor Debian/Raspbian:
https://security-tracker.debian.org/tracker/CVE-2021-44142
Ik klik hier ook even op aan. Zoals @bartvb al aangeeft is er nog geen update beschikbaar. Zat dit nieuws te lezen bij de tandarts, gelijk even een herinnering in mn telefoon gezet om te updaten maar zie dat er geen update is :+

Ik gebruik het voor Time Machine, en twijfel of het zin heeft om het uit te zetten (hier op mijn thuis netwerk).
Ook hier dezelfde vraag, apt update geeft geen update.
Het heeft even geduurd maar er zijn nieuwe packages voor Buster en Bullseye:
https://security-tracker.debian.org/tracker/CVE-2021-44142
Is dit ook lek op TrueNAS (FreeBSD)?
Gauw even mijn NAS DS215J handmatig geupdate.

Die zag de update 4 nog niet.

Geef weer een veilig(er) gevoel.
Op TrueNAS SCALE-22.02-RC.2 staat het default aan op elke Samba share die je hebt aangemaakt. Config vind je in /etc/smb4_share.conf, maar volgens mij zijn handmatige wijzigingen "vluchtig", met andere woorden, na een reboot staat het er vrolijk weer in.

Ik heb er nog niet specifiek naar gezocht maar ik denk dat we afhankelijk zijn van een TrueNAS update.
Vergeet niet je printers te checken! Die draaien vaak ook Samba (al dan niet in de fruitige variant om alle Apple gebruikers te kunnen bedienen).
Hoe check je een printer?

Op dit item kan niet meer gereageerd worden.