Samba bevat ernstig beveiligingsprobleem

Kwaadwillenden kunnen via Samba, de software die in Linux wordt gebruikt voor filesharing via het smb-protocol van Windows, op afstand root-code uitvoeren. Alle versies sinds 2003 zijn kwetsbaar. Er zijn inmiddels patches uitgegeven.

Door een remote procedure call te manipuleren kan een Samba-server ertoe worden verleid om code uit te voeren als root-gebruiker, zo heeft het softwareproject zelf bekendgemaakt. Het probleem wordt veroorzaakt door een bug in de generator die code produceert voor de rpc-implementatie van Samba.

Door de bug in de generator ontstond een fout bij de afhandeling van rpc-calls. De lengte van variabelen die daarbij naar het geheugen werden geschreven werd wel gecontroleerd, maar niet goed genoeg. Twee variabelen die een client naar een Samba-server stuurt, de variabele met de lengte van een array en de variabele met de waarde van de array zelf, werden los van elkaar gecontroleerd. Dat maakte een buffer overflow mogelijk, waarbij meer data naar het geheugen wordt geschreven dan waarvoor ruimte is gereserveerd.

Samba noemt de kwetsbaarheid zelf 'het ernstigste beveiligingsprobleem dat kan optreden in software', omdat het mogelijk is om de kwetsbaarheid te misbruiken zonder dat authenticatie vereist is. Wel moet een Samba-host uiteraard bereikbaar zijn voor de aanvaller, bijvoorbeeld doordat deze zich op hetzelfde netwerk bevindt of doordat de Samba-host direct aan het internet hangt. Dat laatste werd echter al afgeraden.

Een groot deel van de Samba-gebruikers wordt getroffen door het probleem; het is sinds 2003 in alle Samba-versies aanwezig. Onder meer in Ubuntu, Debian en Red Hat wordt Samba gebruikt om bestanden te delen via het smb-protocol van Microsoft, waardoor bestanden met Windows-pc's kunnen worden gedeeld. Het probleem treedt enkel op als een gebruiker het delen van bestanden heeft ingeschakeld. Ook veel nas-systemen gebruiken Samba om bestanden te delen.

Samba roept op om zo snel mogelijk te updaten. Red Hat heeft inmiddels patches uitgegeven voor het probleem; Ubuntu is daar nog mee bezig. Mac OS X bevat sinds Lion geen Samba meer, maar een eigen implementatie van het smb-protocol. Apple was niet blij met de nieuwe gplv3-licentie die aan Samba werd gehangen.

Gebruikers kunnen handmatig een patch installeren als er voor hun besturingssysteem nog geen update is. Als workaround kunnen gebruikers ervoor kiezen alleen inkomende verbindingen vanaf bepaalde ip-adressen te accepteren. Omdat ip-adressen kunnen worden gemanipuleerd, is dat echter geen waterdichte oplossing.

Reacties (63)

Het is ook goed om te kijken naar je NAS als je een dergelijk apparaat gebruikt. Aangezien de meeste apparaten een of andere Linux distro gebruiken + SAMBA zijn ook deze apparaten kwetsbaar. Natuurlijk zullen deze niet direct aan het internet hangen, maar zeker in grotere bedrijven is dat geen garantie dat er nooit een poging gewaagd zal worden door een geïnfecteerde PC/laptop.

Er zijn ook mensen die de NAS achter een router hebben hangen. Indien je gebruik maakt van port forwarden heb je indirect een rechtstreekse verbinding met de NAS. Dit doe je om je bestanden ook online beschikbaar te maken.

Ik neem even voor het gemak aan dat niemand zo dom is om een poort-forward te maken t.b.v. een SAMBA koppeling Je kan dan beter via NFS een koppeling tot stand brengen, of beter nog een VPN tunnel opbouwen waarover je een SAMA share aanroept.

Sommige internet providers blokkeren deze poort standaard. Zelfs als je dit gedaan hebt kun je er dus nog niet bij.

Klopt. Want Windows zet je PC standaard al open via een share. Vergeet niet dat Samba een opensource implementatie is van Windows filesharing (of hoe MS het tegenwoordig noemt).

Ik heb een jaar of 10 geleden eens geprobeerd om te kijken hoeveel computers je via internet met Windows filesharing kon benaderen en of er ook bestanden benaderbaar waren. Bij sommige systemen kon je zelfs zonder wachtwoord bij alle bestanden komen. Reden genoeg voor providers om dat te blokkeren.

Las het artikel en moest verwijl direct aan mijn NAS denken.

Ondanks dat mijn NAS niet direct verbonden is met het internet (en er geen toegang tot heeft) acht ik de kans zeer klein dat ik getroffen word door deze bug/security risk.

Voor als nog loop ik liever geen onnodig risico en heb het probleem liever zo snel mogelijk verholpen.

Vraagje,
Voor wie in het bezit is van een NAS (Synology, QNAP, Netgear, Iomega ... etc etc)
Heeft men te wachten tot de fabrikant een update uitbrengt of zijn er andere gebruikers vriendelijk opties om deze update toe te passen?

Voor de QNAP gebruikers:

# /usr/local/samba/sbin/smbd -V

Ik heb versie 3.5.2, dus vatbaar. Maar mijn NAS is niet van buitenaf bereikbaar

Ditto, maar ik vertrouw mijn gebruikers niet.

Mac OS X bevat sinds Lion geen Samba meer, maar een eigen implementatie van het smb-protocol.

Dat is te kort door de bocht en niet helemaal waar. Samba zit gewoon nog in OS X maar niet de originele versie van het Samba project zelf maar een door Apple aangepaste versie. Dat is heel wat anders als een eigen implementatie want die is er vooralsnog niet. Er staat in /etc/ en in /private/var/db nog een smb.conf maar volgens mij is dit allemaal overgenomen door de plist variant. In die plist kun je nog altijd een oude commandline option meegeven: --no-symlinks. Zie ook: https://discussions.apple.../3229386?start=0&tstart=0

Ik zou zeggen dat ze op dit moment in een overgangsfase verkeren waarbij Samba nog wordt aangehouden maar ze allerlei dingen op z'n plaats aan het zetten zijn om het te vervangen. Die plist is daar een goed voorbeeld van. Het is dan ook de vraag wat Apple allemaal heeft aangepast en in hoeverre dit lek op hun aangepaste Samba versie van toepassing is.

Apple was niet blij met de nieuwe gplv3-licentie die aan Samba werd gehangen.

Apple heeft hierover met geen enkel woord gerept. Er gingen geruchten dat dit de reden was waarom Apple voor een eigen implementatie ging. Dat bleek niet geheel waar te zijn omdat er nog altijd Samba in zit alleen door Apple aangepast en wat dieper in het systeem gestopt. Apple doet over dit soort dingen nooit en te nimmer uitspraken dus we houden dom giswerk over.

Mijn AC Ryan gebruikt ook Samba..betekent het nu dat iemand mijn films kan downloaden? Ze doen maar

Edit: oke, het is nu een stuk duidelijker! Blijkbaar eindelijk een goed commentaar van mij
Mijn AC Ryan is inderdaad (nog niet) van buiten af te benaderen, al wil ik er nog wel eens mee spelen, kijken of ik hem draadloos bij mijn buurman op z'n router kan krijgen en bedraad in mijn netwerk. Zodat hij films kan streamen vanaf mijn Ac Ryan. Soort buurtfilmservice-achtig iets

[Reactie gewijzigd door dotternetta op 11 april 2012 11:44]

Het betekent dat ze code kunnen uitvoeren. Ze kunnen dus bestanden aanpassen, en zo bijvoorbeeld infecteren met virussen of trojans.

Daarnaast zouden ze het ethernet device in promiscuous mode kunnen zetten, waarmee ze bijvoorbeeld je volledige internetverkeer kunnen monitoren. Denk hierbij aan inloggegevens op diverse sites die geen SSL gebruiken.

Ze kunnen dan zelfs SSL verkeer onderscheppen. Als tools als Fiddler2 zich tussen het SSL verkeer kan nestelen (zonder foutmelding/waarschuwing van de browsers), dan kan natuurlijk elk stukje software dat doen.

Dat is mogelijk omdat Fiddler zich in de WinInet stack plaatst en een kopie van de datastream kan krijgen. Hierdoor is fiddler ook 'getuige' van de SSL/TLS handshake en weet daarmee dus welke keys er worden gebruikt voor de transmissie en kan net als de browser de data decrypten.

Het is niet heel erg lastig om een redirect iptables statement te geven welke uitgaand verkeer naar poort 80 en 443 doorzet naar een proxy. De proxy kan vervolgens transparant de request en response streams doorzetten, maar zelf werken met een kopie daarvan.

SSL is alleen 'maar' encryptie en een checksum. Het voorkomt geen man-in-the-middle aanvallen. Elke hop in de keten kan theoretisch het verkeer monitoren en dat geldt dus ook voor jouw internet provider. Het is alleen niet mogelijk om de data van en naar de server te wijzigen omdat de private keys niet bekend zijn.

Ze zouden ook 'corrupte' sleutels aan je GPG-key collectie kunnen toevoegen en bijvoorbeeld de repository sources (eventueel via een wijziging in het hosts bestand) kunnen wijzigen.

Nog betere malware wijzigd de syslog filter regels zodat succesvolle logins niet meer worden gelogd, maakt daarna een (SSH) user account aan en stuurt de login gegevens (met key) naar de hacker.

Er zijn weinig systeembeheerders welke elke dag alle logs doorlezen. De meeste systeembeheerder gebruiken tools zoals 'logcheck' en die filteren de logregels waarvan de beheerder weet dat deze geen bedreiging vormen. Regelmatig zit hier ook een succesvolle login bij want meestal zijn 'we' meer geinteresseerd in een mislukte inlog pogingen.

Een hacker kan daarna inloggen en alle wijzigingen maken welke hij wil. Hij kan zelfs besluiten om daarna het account weer te verwijderen om ontdekking te minimaliseren.

Iemand met root of administrator rechten kan alles met jouw machine. Daarom is het ook zaak om zo weinig mogelijk te doen als root/administrator en alleen de services te installeren/draaien welke je ook daadwerkelijk nodig hebt..

Persoonlijk denk ik niet dat deze exploit al veel in het wild gebruikt wordt, anders was deze vast wel in de afgelopen jaren op een security mailinglist terecht gekomen. Echter nu is de exploit wel bekend en wordt Samba op erg veel machines geinstalleerd. In theorie kan Windows malware nu het netwerk scannen op Samba clients en vervolgens ook binnen dringen (lees: opdrachten versturen welke een buffer overflow veroorzaken en daarna code uitvoeren) op Linux machines..

Elke exploit welke root execution rights oplevert is levens gevaarlijk, ongeacht welk besturings systeem je gebruikt..

Tenzij de computer waar je browser op draait zelf geinfecteerd wordt zal je bij SSL minstens foutmeldingen zien. SSL zorgt er immers wel voor dat 2 endpoints met elkaar kunnen communiceren zonder dat iemand tussenin het verkeer kan lezen of wijzigen, ook je ISP niet. Het is daarbij wel belangrijk om bij het opzetten van de communicatie te verifiëren wie het andere endpoint is.

Indien je zomaar elk self-signed certificate accepteert (zonder externe verificatie van fingerprints), dan is er natuurlijk geen enkele vorm van controle of je wel met de juiste server verbonden bent. Dan kan tussenin door middel van een man-in-the-middle attack een ander self-signed certificate gegenereerd worden waardoor de communicatie onderschept kan worden. Dit is ook wat Fiddler2 doet: on-the-fly man-in-the-middle certificates genereren.

Zonder extra actie zie je dan ook foutmeldingen. Indien je deze wil vermijden zal je eerst Fiddler2 moeten toevoegen aan je Trusted Root CA lijst in je browser.

Voor meer info: http://www.fiddler2.com/Fiddler/help/httpsdecryption.asp

Uitstekende uitleg! Vooral je uitleg over de man-in-the-middle aanval zal voor een hoop mensen die niet veel kennis hebben van netwerken en security, goed te lezen zijn.

Chapeau!

Kan je samba niet in userspace draaien zonder root rechten?
Sommige services kunnen dat na opstarten.
Ik vraag me ook af of deze exploit ook op windows werkt?

@Soldaatje
Samba kan je volgens mij niet als unprivileged gebruiker draaien, samba gebruikt redelijk wat system calls naar mijn weten en is dus niet als non-root te draaien.

Wat je wel kan doen is een chroot/jail maken je te exporteren folders daarin bind-mounten. Linux heeft echter wat problemen (gekend) met de chroot methode, dus dan is een freebsd jail meer aan te raden.

@terror538: het gebruik van system calls heeft op zich helemaal niets te maken met root rechten. Elk programma doet dat. write(), read(), open(), geen enkel probleem. Samba maakt echter noodzakelijkerwijs vrij veel gebruik van bijvoorbeeld setuid(), waarvoor wel root privileges nodig zijn.

Sowieso moet samba zgn. privileged ports openen.

Alleen als de AC direct aan het internet hangt (lijkt me niet toch?)

Op zich lijkt het allemaal niet zo heel gevaarlijk, maar denk eens door.
Films downloaden van jouw AC is kolder, maar door root-code uit te voeren kunnen ze van jouw AC een bot maken voor DDos aanvallen, of een FTP server draaien voor allerlei minder frisse zaken.

Allemaal ver gezocht, ik weet het, maar het kan.

Een andere invalshoek die niet vergeten moet worden is een systeem binnen jouw netwerk dat geinfecteerd is met een virus.

Als dat virus geprogrammeerd is om dit lek te misbruiken, wat zeker een aantal varianten (gaan) doen, dan is jouw NAS nog steeds kwetsbaar.

Vrij ver gegrepen geef ik toe, maar als de gegevens gevoelig zijn dan moet je hier wel rekening mee houden en kijken of er firmware updates beschikbaar zijn.

Dat betekend dat ze je systeem kunnen overnemen. Het zal als een exploit kunnen worden uitgevoerd.

Ze kunnen doen met je machine wat ze willen, er draait onder water nog altijd Unix op.

Ik neem aan dat vanaf de buitenwereld je AC Ryan niet te benaderen is? Dan is er niets aan de hand... Alleen mensen intern kunnen er dan exploits op los laten (wat dus zeeeeer onwaarschijnlijk is dat iemand dat zou doen).

Je AC Ryan is hoogstwaarschijnlijk niet direct vanaf het internet te benaderen waardoor deze kwetsbaarheid niet zomaar geëxploiteerd kan worden.

In het geval een kwetsbare smb-server wel aan het internet open staat kan een willekeurig iemand op het internet zichzelf mogelijk toegang verschaffen tot de server en alle bestanden daarop. En via de server mogelijkerwijs weer tot andere systemen in je lokale netwerk.

Daar dacht ik ook aan. Ik verwacht eerlijk gezegd niet snel een update van AC Ryan.

Ik heb een vergelijkbare mediaspeler. Ik ben niet direct bang dat die wordt gehackt, maar buffer overflows kunnen ook crashes en/of datacorruptie veroorzaken.

kijken of ik hem draadloos bij mijn buurman op z'n router kan krijgen en bedraad in mijn netwerk. Zodat hij films kan streamen vanaf mijn Ac Ryan. Soort buurtfilmservice-achtig iets

Nee kan niet, als je je WiFi erop hebt, is de andere interface uitgezet
Je zal dan niet een 2e IP krijgen

< of je moet in de firmware gaan spitten >

Als je dat wilt, kan je beter een laptop met dat netwerk van de buurman verbinden, en bridgen met jouw netwerk
( makkelijker is om jullie netwerken dan één te laten zijn, en met één router te werken )

wat bedoelen ze met:

werden los van elkaar gecontroleerd. Dat maakte een buffer overflow mogelijk

wat voor fout hebben ze in de code gemaakt en hoe zou zo iets dan wel moeten?

als je ze beide controleert kan het toch niet fout gaan?
ongeacht of je ze los van elkaar controleert.

[Reactie gewijzigd door liquid_ice op 11 april 2012 11:01]

Gezamenlijk kunnen de twee bij elkaar opgeteld meer data bevatten dan dat de buffer aan kan. Ze kijken nu echter naar de individuele sets of die boven dat totaal uit komen.

Voorbeeld:
Buffer size = 10

A ) NaamVariableen = 5
B ) Lengte variabelen = 6
Gezamenlijk hebben ze een buffer van 11 nodig.

Wat er gebeurde was dat ze controleerde of A 10 of kleiner was en B of deze 10 of kleiner was. Gezamenlijk kan dit natuurlijk meer zijn.

In dit geval betekend het dus een buffer_overflow

[Reactie gewijzigd door Liqued op 11 april 2012 11:06]

Zo heeft OpenWRT bv. al een patch klaar staan voor dit probleem, en waar je ook kan zien wat er precies veranderd is in de src.

Volgens Samba-Bugzilla is deze security bug 8815 (zie attachment 7400) ontdekt als onderdeel van het HP's Zero Day Initiative program (link).

An Anonymous researcher working with HP's Zero Day Initiative program
has found this and notified us.

[Reactie gewijzigd door Ravefiend op 11 april 2012 11:15]

if ($array != null)
if ($array.length > 0)
foreach ($item in $array)
doeiets($item);

en ze misten dus nog:

if ($array.length > expectedlength)
{
PANIC();
}
//gokje

[Reactie gewijzigd door FireDrunk op 11 april 2012 11:06]

Dan kijk je toch wat er in de patch staat? Daar staan alle veranderingen!

Dat is wel een serieus ernstig lek inderdaad. Ik ben benieuwd hoeveel misbruik hier van is gemaakt in de afgelopen jaren, dat zullen we denk ik nooit weten. Nu maar hopen dat iedereen snel de patches uitrolt.

Vergeet echter even niet dat samba over het algemeen alleen op interne netwerken word gebruikt. Ik ken geen enkele persoon of bedrijf die samba over internet gebruikt. De standaard modems routers bij mensen thuis zullen ook echt geen samba poorten forwarden. Ofterwijl je moet al toegang hebben tot een prive/bedrijfsnetwerk wil je hier iets mee kunnen.

Dat het vanuit het oogpunt van de Samba makers het ergste is wat hun kunnen hebben, wil niet zeggen dat het in de praktijk echt gevaarlijk is. Je moet wel het gebruik en omgeving van Samba in ogenschouw nemen als je een opbjectief oordeel wilt geven!

Maar veel grote hacks worden uitgevoerd door (ex) werknemers die (nog) toegang hebben tot het netwerk. Het komt er op neer dat je mensen met toegang ongeveer net zo goed kan vertrouwen als alle andere mensen buiten je netwerk.

Bedrijfsnetwerken kunnen behoorlijk groot zijn (ik zit op eentje van geloof ik 30.000 clients), en dit betekent dus dat elke willekeurige werknemer op elke Unix/Linux server/client met Samba kan rondbanjeren, met root rechten. Ik ga ook maar eens kijken of ze de salaris administratie op een Linux server hebben draaien, nulletje erbij tralala

[Reactie gewijzigd door Dreamvoid op 11 april 2012 21:53]

Red Hat heeft de patches al gepushed.
Ben ook benieuwd hoe lang dit al bekend is onder kwaadwillende...

Het is van toepassing op alle 3.0.x tot en met 3.6.3 versies.

En aangezien 3.0.0 op 24 september 2003 gereleased is kan dat dus al vrij lang bekend zijn onder kwaadwillenden.

http://ftp.samba.org/pub/samba/old-versions/

Dat is een pijnlijk lange periode. Bedankt voor de info.
Gisterennacht zijn de patches op mijn RHEL systemen geïnstalleerd.
Wel heel vervelend dit soort openbaringen...

[Reactie gewijzigd door Anoniem: 328088 op 11 april 2012 12:00]

Het probleem schijnt zich nog maar 5 jaar voor te doen en niet 9 zoals hier en op veel andere plaatsen wordt beweerd. Nog steeds lang natuurlijk, maar de Samba developers willen toch even laten weten dat het iets minder erg is dan hier wordt beweerd

[Reactie gewijzigd door martdj op 11 april 2012 23:20]

Hmm vanavond maar ff updaten dan.
Ik heb mijn samba servertje ook aan het internet hangen zodat ik hem vanaf het werk benaderen kan. Nu heb ik wel alleen het werk ip toegestaan d.m.v. hosts.allow / deny, maar vraag me af of dit wel afdoende is. En updaten kan nooit kwaad lijkt me

but why? samba is bedoeld voor file sharing op een LAN (je weet wel, met de L van local). Als je dan per se samba wilt gebruiken, gebruik dan op zijn minst een beveiligde tunnel om je verkeer overheen te sturen

Zodra ergens certificaten aan te pas komen haken veel mensen af en doen het onveilig.

Zodra ergens certificaten aan te pas komen haken veel mensen af en doen het onveilig.

Als het om een ad-hoc implementatie gaat (1 gebruiker, 1 eigen server, 1 eigen client) kan de gebruiker ook opteren voor een pre-shared key (PSK). Dit kan sowieso met de meest gangbare SSL-gebaseerde VPN's (OpenVPN, bijvoorbeeld) en IPSec.

Dit is niet voor een gemiddelde computergebruiker, maar zeker te doen voor de iets meer technisch ontwikkelde gebruikers die zelf hun NAS modificeren en port forwardings kunnen maken.

[Reactie gewijzigd door The Zep Man op 11 april 2012 13:39]

Samba is bedoeld voor file sharing over TCP/IP, of dat een LAN of WAN is maakt technisch niet uit.

Ik denk niet dat er veel samba over het internet gebruikt wordt dus ja het is een fikse bug maar voornamelijk een probleem als een kwaadwillend persoon al toegang tot je netwerk heeft.

Wellicht niet, maar het is wel een prima manier om vanaf een ander al geinfecteerd systeem op een netwerk (denk aan je windows laptop) ook de op dat netwerk draaiende linux systemen over te nemen. Inclusief je NAS, je AC/Ryan of een ander dergelijk apparaat. Dat lijkt me wel degelijk een serieus risico.

Ikzelf heb een Synology NAS, bestanden zijn alleen in mijn netwerk te benaderen (via Samba weliswaar), maar dit zou toch niet uit moeten maken dan?
Kan sowieso buiten mijn netwerk niet aanloggen op de Nas, en volgens mij gebruiken heel veel mensen hun Nas op deze manier..kan volgens mij op die manier iig niet erg veel kwaad..

@ Hieronder: Dat gaat inderdaad wat ver, in dat geval kunnen ze wel meer onderscheppen!

[Reactie gewijzigd door Only op 11 april 2012 12:52]

Zo lang je geen poorten naar je NAS hebt geforward, kan alleen iemand vanuit je eigen netwerk hier gebruik van maken ja.

Neemt niet weg dat 'ze' bijvoorbeeld je wifi-wachtwoord kunnen achterhalen of op één of andere manier op je router kunnen inbreken. Maar dat is allemaal wel erg vergezocht, geef ik direct toe.

Hoe dan ook, Synology zal het binnenkort vast wel met een firmware-update verhelpen.

Haha yeah.. Gisteren bericht gezien dat mijn ubuntu 10.10 (jaaa i know ik moet updaten) geen updates meer krijgt, komt er zo'n beveiligingslek langs..

/offtopic
Dat is precies de reden waarom ik voor Ubuntu op de LTS releases blijf hangen, ik heb zelf ook geen zin/tijd om elke 6 maanden te upgraden. Wellicht ook een optie voor jou?

Alle versies sinds 2003 zijn kwetsbaar

dus als ik het goed begrijp, loop je daar geen risico voor als je een versie hebt van VOOR 2003... meestal bevelen ze de nieuwste versie van software aan ivm. veiligheid...

voor deze kwetsbaarheid niet.
maar tenzij je alle andere patchen backported hebt kan je wel kwetsbaar zijn voor andere exploits.

maw updaten naar versie 3.6.4 is beter.