Défaut de sécurité de Samba publié le 12 avril 2016

Samba est une implémentation open source du protocole SMB (Server Message Block) ou CIFS (Common Internet File System) permettant l'accès au partage d'imprimantes, de fichiers et autres informations entre des PC compatibles. Un certain nombre de défaillances ont été découvertes et corrigées dans toutes les versions de Samba actuellement prises en charge. Pour davantage d'informations sur Badlock (CVE-2016-2118), consulter l'article de base de connaissance 2253041.

Versions concernées :

CVE-2015-5370: Multiple flaws in DCE/RPC code

On a trouvé plusieurs défaillances dans l'implémentation du protocole DCE/RPC de Samba. Un attaquant distant authentifié peut utiliser ces défaillances pour causer un déni de service au serveur Samba (charge CPU élevée ou un crash) ou, il peut exécuter un code arbitraire avec les permissions de l'utilisateur qui exécute Samba (root). L'attaquant malveillant qui prendrait le contrôle de l'Active Directory (AD) peut également exploiter cette défaillance pour affaiblir une connexion sécurisée de DCE/RPC et compromettre la sécurité d'un contrôleur de domaine d'Active Directory (DC) de Samba.

Remarque : malgré que les packages Samba qui sont fournis dans Red Hat Enterprise Linux ne prennent pas en charge Samba comme AD DC, cette défaillance s'applique à tous les rôles implémentés par Samba.

CVE-2016-2118 (Badlock) : attaques possibles d'intercepteur dans SAMR et LSA

Pour des informations plus détaillées : Badlock Security Flaw in Samba - CVE-2016-2118

CVE-2016-2110 : attaques possibles d'intercepteur dans NTLMSSP

On a trouvé un certain nombre de défaillances dans l'implémentation de l'authentification NTLMSSP de Samba. Un attaquant non authentifié pourrait utiliser cette faille pour supprimer les indicateurs d'intégrité et l'encodage d'une connexion, entraînant la transmission des données en format de texte brut. L'attaquant peut également forcer le client ou le serveur à envoyer des données en texte brut, même si l'encodage a été expressément demandé pour cette connexion.

LDAP (avec authentification NTLMSSP) est utilisé comme client par plusieurs outils adminstratifs de projets Samba (par exemple, "net", "samba-tool", "ldbsearch", ou "ldbedit").

Ces défaillances affectent tous les rôles possibles dans lesquels Samba peut opérer : voir CVE-2016-2112 and CVE-2016-2113.

CVE-2016-2111: NETLOGON Spoofing Vulnerability

On a découvert que quand Samba était configuré en tant que contrôleur de domaine (DC), il pouvait établir un canal de communication sécurisé avec une machine en utilisant un nom d'ordinateur falsifié. Un attaquant distant pouvant observer le trafic réseau pouvait exploiter cette défaillance pour obtenir des informations liées à la session sur la machine falsifiée.

Cette défaillance n'affecte que Samba exécutant en tant que Classic primary DC, Backup DC, ou Active Directory DC.

Cette défaillance est connue sous le nom CVE-2015-0005 pour Microsoft Windows Server.

Le correctif de cette alerte de sécurité propose une nouvelle optionsmb.conf:

  raw NTLMv2 auth (G)

    Ce paramètre détermine si smbd(8) autorise ou non les client SMB1
    sans sécurité étendue (sans SPNEGO) pour utiliser l'authentification NTLMv2.

    Si dans cette option, lanman auth, et ntlm auth sont désactivés, seuls les
    clients ayant un support SPNEGO sont autorisés. Cela signifie que NTLMv2 est uniquement
    pris en charge dans NTLMSSP.

    Par défaut : raw NTLMv2 auth = no

CVE-2016-2112: le client LDAP et le serveur n'appliquent pas la protection d'intégrité

On a trouvé que l'implémentation LDAP de Samba n'appliquait pas la protection d'intégrité des connexions LDAP. Un attaquant pouvait donc exploiter cette défaillance afin d'affaiblir les connexions LDAP en les empêchant d'utiliser la protection d'intégrité, ce qui lui permettait de détourner ces connexions.

Cette défaillance affecte tous les rôles possibles dans lesquels Samba peut opérer.

Le correctif de cette alerte de sécurité propose une nouvelle optionsmb.conf:

Idap nécessite une auth (G) puissante

    L'option "ldap server require strong auth" détermine si le
    serveur ldap a besoin que le trafic ldap soit signé ou 
    s'il doit être signé et crypté (scellé). Les valeurs possibles sont no, 
    allow_sasl_over_tls et yes.

    La valeur no permet des liaisons simples et sasl pour tous les transports.

    La valeur allow_sasl_over_tls permet des liaisons simples et sasl (sans signature, ni sceau)
    Les connexions over TLS cryptées. Connexions non cryptées uniquement
    autorise les liaisons sasl avec signature ou sceau.

    La valeur yes n'autorise que les liaisons simples sur les connexions TLS cryptées.
    Les connexions non cryptées n'autorisent que les liaisons sasl avec signature ou sceau.

    Par défaut : ldap server require strong auth = yes

Remarque : le serveur LDAP ne possède pas d'option pour pouvoir faire appliquer une authentification puissante pour l'instant. Les correctifs de sécurité vont présenter une nouvelle option intitulée ldap server require strong authdont les valeurs possibles sontno, allow_sasl_over_tls et yes.

Comme le comportement par défaut avait été défini à no, vous devrez modifier cette option explicitement jusqu'à ce que tous les clients aient pu être ajustés pour gérer les erreurs de LDAP_STRONG_AUTH_REQUIRED. Les clients Windows et les serveurs membres de Samba utilisent déjà la protection d'intégrité.

CVE-2016-2113: validation de certificat TLS/SSL manquant permettant des attaques malveillantes

On a trouvé que Samba ne validait pas les certificats SSL/TLS pour certaines connexions. Un attaquant pouvait donc utiliser cette défaillance pour falsifier un serveur Samba en utilisant un certificat SSL/TLS fabriqué spécialement.

Cette défaillance affecte tous les rôles possibles dans lesquels Samba peut opérer.

Le correctif de cette alerte de sécurité propose une nouvelle optionsmb.conf:

  tls verify peer (G)

    Contrôle si et avec quel sérieux le client va vérifier le nom et le certificat
    de son homologue. Les valeurs possibles sont (en ordre ascendant) : no_check,
    ca_only, ca_and_name_if_available, ca_and_name et as_strict_as_possible.

    Si défini à no_check, le certificat ne sera pas dutout vérifié,
    ce qui permet des attaques triviales.

    Si défini sur ca_only, on vérifiera que le certificat est bien signé avec un CA
    spécifié dans l'option "tls ca file". Il est exigé de définir "tls ca file" dans un fichier valide. 
    La durée de vie du certificat est également vérifiée. Si l'option "tls crl file"
    est configurée, on vérifie également
    le CA CRL.

    Si défini sur  ca_and_name_if_available, toutes les vérifications ca_only sont effectuées.
    De plus, les noms de certificats des noms d'hôte des homologues sont
    vérifiés, s'ils sont fournis par la couche d'application et non pas par 
    une chaîne d'adresse IP.

    Si défini sur  ca_and_name, toutes les vérifications ca_and_name_if_available sont effectuées.
    De plus, les noms d'hôtes des homologues et même une adresse IP 
    seront vérifiés par rapport au nom du certificat.

    Si défini sur  as_strict_as_possible, toutes les vérifications ca_and_name sont effectuées.
    De plus le fichier "tls crl" doit être configuré. Les versions à venir 
    de Samba comprendront sans doute des vérifications supplémentaires.

    Par défaut : tls verify peer = as_strict_as_possible

CVE-2016-2114: "server signing = mandatory" not enforced

On a découvert que Samba n'appliquait pas SMB (Server Message Block). Un attaquant malveillant pouvait exploiter cette défaillance pour modifier le trafic entre un client et un serveur.

Cette défaillance affecte les rôles de serveurs suivants : serveur autonome, serveur membre, Classic primary DC, Backup DC, et Active Directory DC.

Prévention:

Une option de configuration server signing = mandatory explicite dans la section [global] du fichier smb.conf avec server min protocol = SMB2, doit empêcher les connexions non protégées par des signatures. Malgré tout, cela risque d'entraîner que d'anciens clients sans support SMB2 (ou supérieur) ne puissent pas se connecter.

CVE-2016-2115: les connexions de client SMB de trafic IPC ne sont pas protégés au niveau intégrité

On s'est aperçu que Samba n'activait pas par défaut la protection d'intégrité pour le trafic IPC. Un attaquant pouvait donc exploiter cette faille pour afficher et modifier les données envoyées entre un serveur Samba et un client.

Le correctif de cette alerte de sécurité propose un certain nombre de nouvelles optionssmb.conf:

  client ipc signing (G)

    Contrôle si le client est autorisé ou s'il doit utiliser 
    une signature SMB pour les connexions IPC$ pour le transport DCE/RPC. Les valeurs 
    acceptées sont auto, mandatory et disabled.

    Si défini sur mandatory ou default, la signature SMB est exigée.

    Si défini sur auto, la signature SMB est proposée, mais non exigée et
    Si défini sur disabled, la signature SMB n'est pas proposée. 

    Les connexions de winbindd à Active Directory DC
    exigent toujours une signature.

    Par défaut : client ipc signing = default

  client ipc max protocol (G)

    La valeur du paramètre (une chaîne) correspond au plus haut niveau de protocole qui
    puisse être supporté par les connexions IPC$ pour le transport DCE/RPC.

    Dans la plupart des cas, cette option ne doit pas être définie en phase de négociation automatique
    si le protocole SMB s'occupe de choisir le protocole qui convient.

    La valeur par défaut correspond à la valeur du dernier protocole pris en charge, actuellement SMB3_11.

    Voir client max protocol pour accéder à une liste des protocoles disponibles.
    Les valeurs CORE, COREPLUS, LANMAN1, LANMAN2 sont mises à niveau à NT1.
   Par défaut : client ipc max protocol = default

    Exemple : client ipc max protocol = SMB2_10

  client ipc min protocol (G)

Ce paramètre contrôle la version de protocole minimum tentée 
    pour utiliser les connexions IPC$ pour le transport DCE/RPC.

    Dans la plupart des cas, cette option n'a pas besoin d'être définie en phase de négociation automatique
    si le protocole SMB s'occupe de choisir le protocole qui convient.

    La valeur par défaut correspond à la valeur NT1 la plus élevée et à la 
    valeur de "client min protocol".

    Voir client max protocol pour accéder à une liste des protocoles disponibles.
    Les valeurs CORE, COREPLUS, LANMAN1, LANMAN2 sont mises à niveau à NT1.

    Par défaut : client ipc min protocol = default

    Exemple : client ipc min protocol = SMB3_11

Prévention:

Une option de configurationclient signing = mandatory dans la section [global] du fichier smb.conf.

Cette défaillance affecte tous les rôles possibles dans lesquels Samba peut opérer.