Remote Exploit in Samba ab 3.5

-Nuke-

Well-Known Member
Heyho,

passend zur Lücke in der SMB-Implementierung von Windows, hat jetzt Samba ein ähnliches Problem. Ich habe es mir mal verkniffen einen "Boycott Samba" Thread zu eröffnen ;), aber:

https://www.samba.org/samba/security/CVE-2017-7494.html

All versions of Samba from 3.5.0 onwards are vulnerable to a remote
code execution vulnerability, allowing a malicious client to upload a
shared library to a writable share, and then cause the server to load
and execute it.

Happy Patching!
 
Spannend ... ob die denn den alten 3.x patchen oder auf 4.x verweisen, was für meine Zwecke unter FreeBSD irgendwie unbenutzbar war. Danke für die info!
 
Welche Plastikrouter mit Samba sind betroffen? Wobei Samba auf einem Router so entbehrlich ist wie Fusspilz.

FreeNAS (zähle ich nicht zu den "Fertig-NAS") hat übrigens reagiert.
 
Soweit ich gesehen habe, braucht es writeable Zugriff auf zumindest ein Share. Bei Heimroutern also nicht so tragisch, wer einen öffentlichen Share nach draußen anbietet, dem ist sowieso nicht mehr zu helfen. Und in Firmen sollte man ja doch meinen, dass sie richtige Server verwenden, die auch gepatcht werden können.
 
Falls noch jemand aus diversen, ekligen Gründen auf net/samba36 für FreeBSD hängt, habe ich hier einen Patch für die letzte Revision des Ports (SVN r429528). Wird als files/patch-source3__rpc_server__srv_pipe.c abgelegt:

Code:
--- ./source3/rpc_server/srv_pipe.c.orig   2017-05-27 08:59:13.000000000 +0200
+++ ./source3/rpc_server/srv_pipe.c   2017-05-27 09:00:28.000000000 +0200
@@ -384,6 +384,11 @@
     pipename += 1;
   }
+   if (strchr(pipename, '/')) {
+     DEBUG(1,("Refusing open on pipe %s\n", pipename));
+     return false;
+   }
+
   if (lp_disable_spoolss() && strequal(pipename, "spoolss")) {
     DEBUG(10, ("refusing spoolss access\n"));
     return false;
Der Patch selbst kommt von Debian, genauer gesagt aus Debian Wheezy. Ich übernehme keine Garantie, dass er korrekt ist. Also weder, dass er die Lücke komplett schließt, noch das er irgendwelche Nebenwirkungen hat.
 
Alternativ kann man auch in der Datei smb.conf im Abschnitt [Global] folgende Zeile eintragen:
Code:
nt pipe support = no
 
hi


mal eine "bloede" frage

wenn ich den bug richtig verstehe , kann ich über diesen remote code ausführen.

wenn nun eine jail baue , welches speziell gehaertet ist so das nur der samba proccess darin läuft , und sämmtliche möglichkeiten abgeschaltet sind einen connect
von innen nach aussen zu machen ........ könnnte diese jail den bug abmildern ?

holger
 
Naja, der Bug wäre eine super Möglichkeit für eine etwaige Ransomware sich a) im Netz zu verbreiten und b) alle deine Dokumente zu verschlüsseln.

Darum wird die Lücke auch gerne "SambaCry" genannt in Anspielung auf WannaCry, welches sich durch eine Lücke im SMB-Protokoll von Windows so verbreitet hat. Eine Verbindung von innen nach außen ist ja möglich, ansonsten würde Samba ja nicht funktionieren.
 
wenn nun eine jail baue , welches speziell gehaertet ist so das nur der samba proccess darin läuft , und sämmtliche möglichkeiten abgeschaltet sind einen connect
von innen nach aussen zu machen ........ könnnte diese jail den bug abmildern ?
Soviel wie der genutzte User von Samba in der Jail ausrichten kann aka. Privilege Escalation, infizieren von Sambainhalten, dos'en von der Jail aus zum Hostsystem, dos'en des Kernels, Ressourcen auslasten. Die Jail schützt genau das, was ich früher von einer Chroot erwartet hätte, simpel und einfach eingesperrter Inhalt.
 
Naja, der Bug wäre eine super Möglichkeit für eine etwaige Ransomware sich a) im Netz zu verbreiten und b) alle deine Dokumente zu verschlüsseln.

Darum wird die Lücke auch gerne "SambaCry" genannt in Anspielung auf WannaCry, welches sich durch eine Lücke im SMB-Protokoll von Windows so verbreitet hat. Eine Verbindung von innen nach außen ist ja möglich, ansonsten würde Samba ja nicht funktionieren.

hm wieso

ein samba connect ( client 2 server ) ist fuer mich von aussen nach innen ...
wenn nun aussschliessen kann das kein proccess der im inneren laeuft eine verbindung nach aussen initieren kann , sollte an der stelle eine etwalige verbreitung nicht möglich sein
das gleiche gilt eingentlich auch fuer write zugriffe ...
wenn der user ,unter dem samba laeuft ,nur read only zugriffe hat , auf fs und inner halb des jail , sollte das reichen das er keinen unfug mit dateien anstellen kann.

und root in jail sollte != root auf dem host sein.

holger
 
Naja, du hast aber einen offenen Port. Jemand verbindet sich mit Schreibzugriff (wenn alle deine Shares Read Only sind, geht das Ganze so oder so nicht) auf deinen Server, packt dort die schädliche Datei rein und los geht's. Samba hat ja Schreibzugriff auf deine Daten die du damit teilst. An dem Punkt ist die Weiterverbreitung ja erst mal egal, denn das macht ja ggf. auch direkt der PC der sich die Ransomware eingefangen hat. Deine Daten kann man aber prinzipiell erst mal verschlüsseln.

Der Einfalls-Vektor ist ja nicht der Samba-Server, sondern der PC, der mit ihm verbunden ist.
 
Tja, ich sags ja nicht gerne, aber nach einem update der restlichen Pakete, startet nun samba3.6 nicht mehr und es gibt scheinbar auch gar kein Samba3 mehr in den Ports oder in den Paketen ...

Das wäre ja nicht so schlimm, wenn sich denn die ACLs mit ZFS nun vertragen würden:
https://www.bsdforen.de/threads/samba-4-x-auf-zfs.33353/

Ein Blick in die unendlichen Weiten des Netzes läßt bei mir das Grauen wachsen ... es scheint sich seit meinem letzten Versuch da auch nichts getan zu haben.

Interessanterweise kann man laut "make config" samba4.2-4.4 ohne ACL support bauen und danach verschwindet der ACL-Knopf aus der config, aber dafür steht ntvfs als deprecated. Mal schauen, ob ich damit was hinbekomme, was ich brauche.

Wie man als fileserversoftware ausgerechnet ZFS so boykottieren kann, will sich mir nicht ganz erschließen.
 
Zurück
Oben