Kritische Sicherheitsschwachstellen in Samba veröffentlicht am 12. April 2016

Samba ist eine Open-Source Implementierung des Server Message Block (SMB) oder Common Internet File System (CIFS) Protokolls, welches PC-kompatiblen Rechnern ermöglicht Dateien, Drucker und andere Informationen freizugeben. Es wurden mehrere Fehler entdeckt und in allen aktuell unterstützten Versionen von Samba behoben. Weitere Informationen zum Badlock-Problem (CVE-2016-2118) finden Sie im Knowledgebase-Artikel 2253041.

Betroffene Versionen:

CVE-2015-5370: Mehrere Fehler in DCE/RPC Code

In der Implementierung von Sambas DCE/RPC Protokol wurden mehrere Fehler gefunden. Ein entfernter, authentifizierter Angreifer könnte diese Fehler ausnutzen um eine Dienstverweigerung gegen den Samba Server zu verursachen (hohe CPU-Belastung oder Absturz) oder möglicherweise einen willkürlichen Code auszuführen mit den Berechtigungen des Benutzers, der Samba betreibt (root). Durch diesen Fehler könnte eine sichere DCE/RPC Verbindung herabgestuft werden, indem ein Man-in-the-Middle Angreifer ein Active Directory (AD) Objekt kontrolliert und dadurch die Sicherheit eines Samba Active Directory Domain Controller (DC) gefährdet.

Hinweis: Obwohl in Red Hat Enterprise Linux gelieferte Samba Pakete nicht die Ausführung von Samba als AD DC unterstützen, betrifft dieser Fehler alle Rollen, die Samba implementiert .

CVE-2016-2118 (Badlock): SAMR und LSA Man-in-the-Middle Angriffe möglich

Details zu diesem Fehler finden Sie unter: Badlock Scherheitsschwachstelle in Samba- CVE-2016-2118

CVE-2016-2110: Man-in-the-Middle Angriffe möglich mit NTLMSSP

In Sambas Implementierung von NTLMSSP Authentifizierung wurden mehrere Fehler gefunden. Ein nicht authentifizierter Man-in-the-Middle Angreifer könnte diesen Fehler ausnutzen um die Verschlüsselung und Integrity-Flags einer Verbindung zu löschen und damit bewirken, dass Daten in einfachem Text übermittelt werden. Der Angreifer könnte auch den Client oder den Server zwingen Daten in einfachem Text zu senden, auch wenn für diese Verbindung ausdrücklich Verschlüsselung angefordert wurde.

LDAP (mit NTLMSSP Authentifizierung) wird von verschiedenen administrativen Samba Projekt-Tools als Client verwendet (beispielsweise "net", "samba-tool", "ldbsearch" oder "ldbedit").

Diese Fehler betreffen alle möglichen Rollen, in denen Samba betrieben werden kann, und gehören zu CVE-2016-2112 und CVE-2016-2113.

CVE-2016-2111: NETLOGON Spoofing-Schwachstelle

Es wurde festgestellt, dass Samba, wenn es als Domain-Controller konfiguriert ist, einen sicheren Kommunikationskanal mit einem Rechner mit gefälschtem Computernamen herstellen würde. Ein entfernter Angreifer, der Netzwerk-Datenverkehr überwachen kann, könnte diesen Fehler ausnutzen um sitzungsbezogene Informationen über den gefälschten Rechner zu beziehen.

Dieser Fehler betrifft Samba nur, wenn es als Classic Primary DC, als Backup DC oder als Active Directory DC betrieben wird.

Dieser Fehler wird bezeichnet als CVE-2015-0005 für Microsoft Windows Server.

Das Sicherheits-Advisory Patch für diesen Fehler führt eine neue smb.conf Option ein:

  raw NTLMv2 auth (G)

    Dieser Parameter bestimmt, ob smbd(8) zulässt, dass SMB1 Clients 
    ohne erweiterte Sicherheit (ohne SPNEGO) NTLMv2 Authentifizierung verwenden.

    Wenn sowohl diese Option, als auch lanman auth und ntlm auth deaktiviert ist,
    dann sind nur Clients mit SPNEGO Support zugelassen. Das heißt, dass NTLMv2 nur
    in NTLMSSP unterstützt wird.

    Standard: raw NTLMv2 auth = no

CVE-2016-2112: LDAP Client und Server erzwingen keinen Integritätsschutz

Es wurde festgestellt, dass Sambas LDAP Implementierung keinen Integritätsschutz für LDAP Verbindungen erzwingt. Ein Man-in-the-Middle Angreifer könnte durch diesen Fehler LDAP Verbindungen herabstufen, sodass sie keinen Integritätsschutz verwenden, und dadurch Kontrolle über solche Verbindungen erlangen.

Dieser Fehler betrifft alle möglichen Rollen, in denen Samba betrieben werden kann.

Das Sicherheits-Advisory Patch für diesen Fehler führt eine neue smb.conf Option ein:

  ldap server require strong auth (G)

    Die Option "ldap server require strong auth" legt fest, ob der
    ldap Server erfordert, dass ldap Datenverkehr signiert oder 
    signiert und verschlüsselt sein muss (versiegelt). Mögliche Werte sind Nein,
    allow_sasl_over_tls und Ja.

    Der Wert Nein erlaubt einfache und sasl Binds für alle Transporte.

    Der Wert allow_sasl_over_tls erlaubft einfache und sasl Binds (ohne signieren oder versiegeln)
    für TLS-verschlüsselte Verbindungen. Unverschlüsselte Verbindungen 
    erlauben sasl Binds nur mit signieren oder versiegeln.

    Der Wert Ja erlaubt nur einfache Binds für TLS-verschlüsselte Verbindungen.
    Unverschlüsselte Verbindungen erlauben nur sasl Binds mit signieren oder versiegeln.

    Standard: ldap server require strong auth = yes

Hinweis: Der LDAP Server enthält noch keine Option starke Authentifizierung zu erzwingen. Die Sicherheits-Patches führen eine neue Option namens ldap server require strong auth ein, deren mögliche Werte no, allow_sasl_over_tls und yessind.

Da das standardmäßige Verhalten vorher auf no gesetzt war, müssen Sie diese Option gegebenenfalls explizit ändern, bis alle Clients eingestellt wurden LDAP_STRONG_AUTH_REQUIRED Fehler zu verarbeiten. Windows Clients und Samba-Mitgliedsserver verwenden bereits Integritätsschutz.

CVE-2016-2113: Fehlende TLS/SSL Zertifikatsvalidierung ermöglicht Man-in-the-Middle Angriffe

Es wurde festgestellt, dass Samba in bestimmten Verbindungen SSL/TLS Zertifikate nicht validierte. Ein Man-in-the-Middle Angreifer könnte diesen Fehler ausnutzen, um unter Verwendung eines speziell hergestellten SSL/TLS Zertifikats einen Samba Server zu fälschen.

Dieser Fehler betrifft alle möglichen Rollen, in denen Samba betrieben werden kann.

Das Sicherheits-Advisory Patch für diesen Fehler führt eine neue smb.conf Option ein:

  tls verify peer (G)

    Dies steuert, ob und wie streng der Client Zertifikat und Namen
    des Peers überprüft. Mögliche Werte sind (in ansteigender Reihenfolge): no_check,
    ca_only, ca_and_name_if_available, ca_and_name und as_strict_as_possible.

    Bei der Einstellung no_check wird das Zertifikat überhaupt nicht überprüft,
    was einfache Man-in-the-Middle Angriffe ermöglicht.

    Bei der Einstellung ca_only wird überprüft, dass das Zertifikat von einer CA signiert ist,
    die in der Option "tls ca file" bestimmt wurde. "tls ca file" muss auf eine gültige
    Datei gestellt werden. Die Lebensdauer des Zertifikats ist auch verifiziert. Ist die Option
    "tls crl file" konfiguriert, so ist das Zertifikat auch auf 
    die CA CRL hin überprüft.

    Bei der Einstellung ca_and_name_if_available werden alle Kontrollen von ca_only durchgeführt.
    Zusätzlich wird der Peer Hostname auf die Zertifikat-Namen hin überprüft,
    sofern dieser von der Anwendungsschicht bereitgestellt und nicht als
    IP-Adresse angegeben ist.

    Bei der Einstellung ca_and_name werden alle Kontrollen von ca_and_name_if_available durchgeführt.
    Zusätzlich muss der Peer Hostname angegeben werden und sogar eine
    IP-Adresse wird auf den Zertifikatnamen hin überprüft.

    Bei der Einstellung as_strict_as_possible werden alle Kontrollen von ca_and_name durchgeführt.
    Zusätzlich muss die "tls crl file" konfiguriert werden. Zukünftige Versionen 
    von Samba werden gegebenenfalls weitere Kontrollen implementieren.

    Standard: tls verify peer = as_strict_as_possible

CVE-2016-2114: "server signing = mandatory" nicht erzwungen

Es wurde festgestellt, dass Samba das Signieren von Server Message Block (SMB) für Clients, die das SMB1 Protokoll verwenden, nicht erzwungen hat. Ein Man-in-the-Middle Angreifer könnte diesen Fehler ausnutzen, um den Datenverkehr zwischen einem Client und einem Server zu modifizieren.

Dieser Fehler betrifft folgende Samba Rollen: Standalone Server, Mitgliedsserver, Classic Primary DC, Backup DC und Active Directory DC.

Vorbeugung:

Eine explizite Konfigurationsoption server signing = mandatory im [global] Abschnitt der smb.conf Datei zusammen mit server min protocol = SMB2soll Verbindungen ohne Signierschutz verhindern. Dies kann allerdings zur Folge haben, dass ältere Clients, die SMB2 (oder höher) nicht unterstützen, nicht verbinden können.

CVE-2016-2115: SMB Client-Verbindungen für IPC Datenverkehr haben keinen Integritätsschutz

Es wurde festgestellt, dass Samba Integritätsschutz für IPC Datenverkehr nicht standardmäßig aktiviert. Ein Man-in-the-Middle Angreifer könnte diesen Fahler ausnutzen um zwischen dem Samba Server und Client gesendete Daten zu sehen und zu modifizieren.

Das Sicherheits-Advisory Patch für diesen Fehler führt mehrere neue smb.conf Optionen ein:

  client ipc signing (G)

    Dies steuert, ob der Client SMB Signierung für ICP$ Verbindungen 
    als DCE/RPC Transport verwenden darf oder muss. Mögliche Werte 
    sind auto, obligatorisch und deaktiviert.

    Bei der Einstellung obligatorisch oder Standard ist das Signieren von SMB erforderlich.

    Bei der Einstellung auto wird das Signieren von SMB angeboten, aber nicht erzwungen. 
    Und bei der Einstellung deaktiviert wird das Signieren von SMB nicht angeboten.

    Verbindungen von winbindd zu Active Directory Domain-Controllern
    erzwingen immer Signieren.

    Standard: client ipc signing = default

  client ipc max protocol (G)

    Der Wert des Parameters (ein String) ist die höchste Protokollebene, die
    für IPC$ Verbindungen als DCE/RPC Transport unterstützt wird.

    Normalerweise sollte diese Option nicht als automatische Verhandlungsphase eingestellt sein, 
    wenn das SMB Protokoll für die Wahl des entsprechendem Protokolls zuständig ist.

    Der standardmäßige Wert verweist auf das zuletzt unterstützte Protokoll, derzeit SMB3_11.

    Eine vollständige Liste verfügbarer Protokolle finden Sie im Client Max Protokoll.
    Upgrade der Werte CORE, COREPLUS, LANMAN1, LANMAN2 zu NT1 geschieht  automatisch.
   Standard: client ipc max protocol = default

    Beispiel: client ipc max protocol = SMB2_10

  client ipc min protocol (G)

    Diese Einstellung steuert die Minimum Protokollversion, die 
    für IPC$ Verbindungen als DCE/RPC Transport verwendet werden soll.

    Normalerweise muss diese Option nicht als automatische Verhandlungsphase eingestellt sein
    wenn das SMB Protokoll für die Wahl des entsprechendem Protokolls zuständig ist.

    Der Standardwert verweist auf den höheren Wert von NT1 und den
    effektiven Wert von "client min protocol".

    Eine vollständige Liste verfügbarer Protokolle finden Sie im Client Max Protokoll.
    Upgrade der Werte CORE, COREPLUS, LANMAN1, LANMAN2 zu NT1 geschieht  automatisch.

    Standard: client ipc min protocol = default

    Beispiel: client ipc min protocol = SMB3_11

Vorbeugung:

Eine explizite Konfigurationsoption client signing = mandatory im[global] Abschnitt der smb.conf Datei.

Dieser Fehler betrifft alle möglichen Rollen, in denen Samba betrieben werden kann.