Translated message

A translation of this page exists in English.

Fallos de seguridad críticos en el lanzamiento de Samba el día 12 de abril, 2016

Samba es una implementación de código abierto de Server Message Block (SMB) o del protocolo del Sistema de archivos comunes de Internet (CIFS), que permite a las máquinas PC-compatibles compartir impresoras y otra información. Se han descubierto varios fallos y corregido a través de todas las versiones de Samba que reciben soporte actualmente. Para obtener más información sobre la vulnerabilidad Badlock (CVE-2016-2118), consulte el artículo de la base de conocimiento 2253041.

Versiones afectadas:

CVE RHEL 5 samba RHEL 5 samba3x RHEL 6 samba RHEL 6 samba4 RHEL 7 Gluster Storage Roles de Samba afectados
CVE-2015-5370 N Y Y Y Y Y Todos los roles posibles en los que Samba puede operar
CVE-2016-2110 Y Y Y Y Y Y Todos los roles posibles en los que Samba puede operar
CVE-2016-2111 Y Y Y Y Y Y Classic primary DC, backup DC, o Active Directory DC
CVE-2016-2112 Y Y Y Y Y Y Todos los roles posibles en los que Samba puede operar
CVE-2016-2113 N N N Y Y Y Todos los roles posibles en los que Samba puede operar
CVE-2016-2114 N N N Y Y Y Todos los roles posibles en los que Samba puede operar
CVE-2016-2115 Y Y Y Y Y Y Todos los roles posibles en los que Samba puede operar
CVE-2016-2118 Y Y Y Y Y Y Todos los roles posibles en los cuales Samba puede operar, a excepción de los roles críticos para Active Directory DC

CVE-2015-5370: Múltiples fallos en código DCE/RPC

Se encontraron múltiples fallos en la implementación de protocolo DCE/RPC. Un atacante autenticado remoto podría usar estos fallos para causar una negación de servicio contra el servidor de Zanata (carga alta de CPU o caída) o, posiblemente, ejecutar código arbitrario con los permisos del usuario que ejecuta Samba (root). Este fallo podría ser utilizado para rebajar una conexión segura DCH/RPC por un atacante Hombre-en-el- medio tomando control sobre un objeto de Active Directory (AD) y comprometiendo la seguridad de un Samba Active Directory Domain Controller (DC).

Nota: A pesar de que los paquetes de Samba se distribuyen en Red Hat Enterprise Linux, no soportan Samba en un AD DC, este fallo se presenta en todos los roles de implementados por Samba.

CVE-2016-2118 (Badlock): Posibles ataques de Hombre-en-el-medio a SAMR y LSA

Más información acerca de este error está disponible en: Badlock Security Flaw in Samba - CVE-2016-2118

CVE-2016-2110: Posibles ataques de Hombre-en-el-medio con NTLMSSP

Se descubrieron varios fallos en la implementación Samba de autenticación NTLMSSP. Un atacante no identificado, Hombre-en-el-medio, podría utilizar este fallo para borrar el cifrado y los indicadores de integridad de la conexión, haciendo que los datos sean transmitidos en texto plano. El atacante también podría obligar al cliente o servidor a enviar datos en texto plano, incluso si el cifrado se hubiera solicitado para dicha conexión.

LDAP (con autenticación NTLMSSP) es utilizado como un cliente por varias herramientas administrativas de Samba (por ejemplo: "net", "samba-tool", "ldbsearch", o "ldbedit").

Estos fallos afectan todos los roles en los cuales puede operar Samba y están relacionados con CVE-2016-2112 y CVE-2016-2113.

CVE-2016-2111: NETLOGON Spoofing Vulnerability

Se descubrió que Samba configurado como un Domain Controller establecería un canal de comunicación seguro con la máquina que utiliza un nombre de computador falso. Un atacante podría observar tráfico de red que podría usar este fallo para obtener información relacionada con la sesión sobre la máquina falsa.

Este error solo afecta Samba ejecutándose como DC, backup DC, o Active Directory DC.

Este error se conoce como CVE-2015-0005 para Microsoft Windows Server.

El parche de recomendación de seguridad para este fallo introduce una nueva opción `smb.conf:

  raw NTLMv2 auth (G)

     Este parámetro determina si smbd(8) autoriza clientes SMB1 
    sin seguridad extendida (sin SPNEGO) para usar autenticación NTLMv2.

    Si la opción, lanman auth y ntlm auth están inhabilitadas únicamente
  los clientes con soporte SPNEGO están permitidos. Esto significa que NTLMv2 no lo es únicamente
    con soporte dentro de NTLMSSP.

    Predeterminado: raw NTLMv2 auth = no

CVE-2016-2112: El cliente LDAP y el servidor no aplican protección de integridad

Se descubrió que la implementación de Samba no aplicó protección de integridad para conexiones LDAP. Un atacante Hombre-en-el-medio pudo haber usado este fallo para reducir las conexiones LDAP para no usar protección de integridad, permitiéndole secuestrar dichas conexiones.

Este fallo afecta todos los roles posibles en los que Samba pueda operar.

El parche de recomendación de seguridad para este fallo introduce una nueva opción `smb.conf:

 El servidor ldap requiere auth (G) fuerte

    La opción "ldap server require strong auth" define si el 
  el servidor ldap requiere que tráfico ldap sea firmado o
    firmado y cifrado (sellado). Los posibles valores son no,
    allow_sasl_over_tls and yes.

    Un valor de no permite vínculos sencillos y sasl sobre todos los transportes.

    Un valor de allow_sasl_over_tls permite vínculos sencillos y sasl (sin firma o sello)
    en conexiones TLS cifradas. Conexiones sin cifrar únicamente
    permite vínculos sasl con firma o sello.

Un valor de yes permite vínculos sencillos en conexiones cifradas TLS.
Las conexiones sin cifrar únicamente permiten vínculos con firma o sello.

    Predeterminado: el servidor ldap requiere fuerte auth = yes

Nota: El servidor LDAP no tiene aún una opción para aplicar autenticación fuerte. Los parches de seguridad presentarán una nueva opción llamada ldap server require strong auth, los posibles valores son no, allow_sasl_over_tls y yes.

Como la conducta predeterminada fue establecida a no anteriormente, puede haber cambiado explícitamente esta opción hasta que todos los clientes hayan sido ajustados para manejar errores LDAP_STRONG_AUTH_REQUIRED. Los clientes de Windows y los servidores miembros de Samba ya usan protección de integridad.

CVE-2016-2113: La falta la validación de certificado TLS/SSL permite ataques de Hombre-en-el-medio

Se encontró que Samba no validó certificados SSL/TLS en algunas conexiones. Un atacante Hombre-en-el-medio podría usar este fallo para falsificar un servidor Samba mediante un certificado SSL/TLS bien elaborado.

Este fallo afecta todos los roles posibles en los que Samba pueda operar.

El parche de recomendación de seguridad para este fallo introduce una nueva opción `smb.conf:

  tls verify peer (G)

    Controla si y qué tan estricto es el cliente que va a verificar el certificado y nombre del 
certificado. Los valores posibles son  (en orden ascendente): no_check,
    ca_only, ca_and_name_if_available, ca_and_name and as_strict_as_possible.

Cuando se establece a -check el certificado no es verificado
lo que cual permite ataques triviales de Hombre-en-el-medio. 

   Cuando se establece a ca_only,  se verifica que el certificado esté firmado desde un CA
    especificado en la opción "tls ca file". Configurando "tls ca file" a un archivo válido
    se requiere. El tiempo de vida del certificado también se verifica. Si la opción "tls crl file"
está configurada, el certificado también se verifica
    the CA CRL.

   Cuando se establece como ca_and_name_if_available, se realizan  todas las revisiones de ca_only.
Además, el nombre de host par es verificado con el nombre de certificado, si 
si la capa de aplicación lo provee y no como 
una cadena de dirección IP.

    Cuando se establece a ca_and_name  se realizan todas las revisiones de ca_and_name_if_available.
    Además el nombre de host debe proporcionarse el nombre de host e incluso una dirección IP
debe ser comparada con el nombre de certificados.

Cuando se establece como as_strict_as_possible  todas las revisiones de ca_and_name
Además el  "tls crl file" debe ser configurado. Las versiones futuras
de Samba pueden implementar revisiones adicionales.

    Predeterminado: tls verify peer = as_strict_as_possible

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

Se descubrió que Samba no impuso la firma de Server Message Block (SMB) para clientes que usan el protocolo SMB1. Un atacante Hombre-en-el-medio podría usar este fallo para modificar el tráfico entre un cliente y un servidor.

Este fallo afecta los siguientes roles de servidor: el servidor autónomo, el servidor miembro, classic primary DC, backup DC y Active Directory DC.

Mitigación:

Una opción de configuración de server signing = mandatory en la sección [global] del archivo smb.conf junto con server min protocol = SMB2, debe evitar conexiones sin protección de firma. Sin embargo, esto puede hacer que los clientes antiguos que no reciben soporte para SMB2 (o superior) no puedan conectarse.

CVE-2016-2115: las conexiones de cliente SMB para tráfico IPC no tienen integridad protegida

Se descubrió que Samba no pudo integrar protección de integridad para tráfico IPC de forma predeterminada. Un atacante Hombre-en-el-medio podría usar este fallo y modificar los datos enviados entre un servidor Samba y un cliente.

El parche de esta recomendación de seguridad propone un cierto número de nuevas opciones smb.conf:

  client ipc signing (G)

Controla si el cliente está autorizado o debe usar 
La firma SMB para conexiones IPC$ como transporte DCE/RPC. Los valores posibles
son 'auto', 'mandatory' y 'disabled'

Cuando se establece a 'mandatory' o 'default', se requiere la firma SMB.

Cuando se establece a 'auto', la firma SMB se ofrece pero no se exige y
si se establece a 'disabled', la firma SMB tampoco se ofrece. 

Las conexiones desde winbindd a Active Directory Domain Controllers
siempre se exige la firma.

    Default: client ipc signing = default

  client ipc max protocol (G)

El valor del parámetro (un cadena) es el protocolo de más alto nivel que 
recibe soporte para conexiones IPC$ como transporte DCE/RPC.

Normalmente esta opción no se debe establecer como la fase de negociación automática
si el protocolo SMB se ocupa de elegir el protocolo apropiado.

El valor 'default' se refiere al último protocolo que recibe soporte, actualmente SMB3_11. 

Vea el protocolo máximo de clientes para obtener una lista completa de los protocolos disponibles.
Los valores  CORE, COREPLUS, LANMAN1, LANMAN2 se actualizan a NT1.
   Default: client ipc max protocol = default

    Example: client ipc max protocol = SMB2_10

  client ipc min protocol (G)

Esta configuración controla la versión de protocolo mínima que se intentará 
usar para conexiones IPC$ como transporte DCE/RPC.

Normalmente esta opción no necesita establecerse como la fase de negociación automática 
si el protocolo SMB se ocupa de elegir el protocolo apropiado.

El valor predeterminado se refiere al valor más alto de NT1 y al
valor efectivo de "client min protocol".

Vea el protocolo máximo de clientes para obtener una lista completa de los protocolos disponibles.
Los valores  CORE, COREPLUS, LANMAN1, LANMAN2 se actualizan a NT1.

    Default: client ipc min protocol = default

    Example: client ipc min protocol = SMB3_11

Mitigación:

Una opción de configuración explícita client signing = mandatory en la sección del archivo 'smb.conf'.

Este fallo afecta todos los roles posibles en los que Samba pueda operar.

Comments