A flaw was found in Samba. The KDC accepts kpasswd requests encrypted with any key known to it. By encrypting forged kpasswd requests with its own key, a user can change other users' passwords, enabling full domain takeover.
A flaw was found in samba versions 4.0.0 to 4.5.2. The Samba routine ndrpulldnspname contains an integer wrap problem, leading to an attacker-controlled memory overwrite. ndrpulldnspname parses data from the Samba Active Directory ldb database. Any user who can write to the dnsRecord attribute over LDAP can trigger this memory corruption. By default, all authenticated LDAP users can write to the dnsRecord attribute on new DNS objects. This makes the defect a remote privilege escalation.
As per samba upstream advisory:
Samba, operating as an AD DC, is sometimes operated in a domain with a mix of Samba and Windows Active Directory Domain Controllers.
All versions of Samba from 4.0.0 to 4.3.2 inclusive, when deployed as an AD DC in the same domain with Windows DCs, could be used to override the protection against the MS15-096 / CVE-2015-2535 security issue in Windows.
Prior to MS16-096 it was possible to bypass the quota of machine accounts a non-administrative user could create. Pure Samba domains are not impacted, as Samba does not implement the SeMachineAccountPrivilege functionality to allow non-administrator users to create new computer objects.
The following mitigation was suggested by upstream:
Only users with SeMachineAccountPrivilege can exploit this issue in Windows, removing this privilege from "Authenticated Users" can provide a mitigation.
It was reported that when adding an LDB DN to the database, that if a \00 (null byte) is used, remote memory can be read due to a combination of tallocstrdup() and a length assignment.
Upstream bug:
https://bugzilla.samba.org/showbug.cgi?id=11599
The MS-SAMR and MS-LSAD protocol implementations in Samba 3.x and 4.x before 4.2.11, 4.3.x before 4.3.8, and 4.4.x before 4.4.2 mishandle DCERPC connections, which allows man-in-the-middle attackers to perform protocol-downgrade attacks and impersonate users by modifying the client-server data stream, aka "BADLOCK."
libcli/smb/smbXclibase.c in Samba 4.x before 4.2.14, 4.3.x before 4.3.11, and 4.4.x before 4.4.5 allows man-in-the-middle attackers to bypass a client-signing protection mechanism, and consequently spoof SMB2 and SMB3 servers, via the (1) SMB2SESSIONFLAGISGUEST or (2) SMB2SESSIONFLAGISNULL flag.
Samba 4.x before 4.2.11, 4.3.x before 4.3.8, and 4.4.x before 4.4.2 does not verify X.509 certificates from TLS servers, which allows man-in-the-middle attackers to spoof LDAPS and HTTPS servers and obtain sensitive information via a crafted certificate.
As per samba upstream advisory:
All versions of Samba from 3.0.0 to 4.3.2 inclusive are vulnerable to a bug in symlink verification, which under certain circumstances could allow client access to files outside the exported share path.
If a Samba share is configured with a path that shares a common path prefix with another directory on the file system, the smbd daemon may allow the client to follow a symlink pointing to a file or directory in that other directory, even if the share parameter "wide links" is set to "no" (the default).
For example. Given two directories on the file system:
/share/
/share1/
If a Samba share is created as follows:
[sharename] path = /share wide links = no
Then a symlink with the path
/share/symlink -> /share1/file
would be followed by smbd, due to the fact that only the string "/share" is checked to see if it matches the target path. This means a path that starts with "/share", such as "/share1" will also match.
The following mitigation was suggested by upstream:
Ensure all exported share paths do not share base path names with other directories on the file system.
Please note, setting the smb.conf variable "follow symlinks = no" is NOT a workaround for this problem, as this only prohibits smbd from following a symlink at the end of a path.
A symlink could be created that points to the directory which shares a base path name instead, and smbd would still follow that link. For example, with the above share definition, given a symlink of:
/share/symlink -> /share1
a client could send a relative path such as "symlink/file", which would still be followed by smbd as the end component "file" of "symlink/file" is NOT a symlink, and so is not affected by "follow symlinks = no".
The SMB1 implementation in smbd in Samba 3.x and 4.x before 4.1.23, 4.2.x before 4.2.9, 4.3.x before 4.3.6, and 4.4.x before 4.4.0rc4 allows remote authenticated users to modify arbitrary ACLs by using a UNIX SMB1 call to create a symlink, and then using a non-UNIX SMB1 call to write to the ACL content.
Samba from version 4.3.0 and before versions 4.7.12, 4.8.7 and 4.9.3 are vulnerable to a denial of service. When configured to accept smart-card authentication, Samba's KDC will call tallocfree() twice on the same memory if the principal in a validly signed certificate does not match the principal in the AS-REQ. This is only possible after authentication with a trusted certificate. talloc is robust against further corruption from a double-free with tallocfree() and directly calls abort(), terminating the KDC process.
The NETLOGON service in Samba 3.x and 4.x before 4.2.11, 4.3.x before 4.3.8, and 4.4.x before 4.4.2, when a domain controller is configured, allows remote attackers to spoof the computer name of a secure channel's endpoint, and obtain sensitive session information, by running a crafted application and leveraging the ability to sniff network traffic, a related issue to CVE-2015-0005.
The internal DNS server in Samba 4.x before 4.1.23, 4.2.x before 4.2.9, 4.3.x before 4.3.6, and 4.4.x before 4.4.0rc4, when an AD DC is configured, allows remote authenticated users to cause a denial of service (out-of-bounds read) or possibly obtain sensitive information from process memory by uploading a crafted DNS TXT record.
Samba 3.x and 4.x before 4.2.11, 4.3.x before 4.3.8, and 4.4.x before 4.4.2 does not require SMB signing within a DCERPC session over ncacnnp, which allows man-in-the-middle attackers to spoof SMB clients by modifying the client-server data stream.
The NTLMSSP authentication implementation in Samba 3.x and 4.x before 4.2.11, 4.3.x before 4.3.8, and 4.4.x before 4.4.2 allows man-in-the-middle attackers to perform protocol-downgrade attacks by modifying the client-server data stream to remove application-layer flags or encryption settings, as demonstrated by clearing the NTLMSSPNEGOTIATESEAL or NTLMSSPNEGOTIATESIGN option to disrupt LDAP security.
Samba 3.x and 4.x before 4.2.11, 4.3.x before 4.3.8, and 4.4.x before 4.4.2 does not properly implement the DCE-RPC layer, which allows remote attackers to perform protocol-downgrade attacks, cause a denial of service (application crash or CPU consumption), or possibly execute arbitrary code on a client system via unspecified vectors.
The SMB1 protocol implementation in Samba 4.x before 4.2.11, 4.3.x before 4.3.8, and 4.4.x before 4.4.2 does not recognize the "server signing = mandatory" setting, which allows man-in-the-middle attackers to spoof SMB servers by modifying the client-server data stream.
The bundled LDAP client library in Samba 3.x and 4.x before 4.2.11, 4.3.x before 4.3.8, and 4.4.x before 4.4.2 does not recognize the "client ldap sasl wrapping" setting, which allows man-in-the-middle attackers to perform LDAP protocol-downgrade attacks by modifying the client-server data stream.
A flaw was found in the Samba AD LDAP server. The AD DC database audit logging module can access LDAP message values freed by a preceding database module, resulting in a use-after-free issue. This issue is only possible when modifying certain privileged attributes, such as userAccountControl.
As per upstream samba advisory:
Versions of Samba from 3.2.0 to 4.3.2 inclusive do not ensure that signing is negotiated when creating an encrypted client connection to a server.
Without this a man-in-the-middle attack could downgrade the connection and connect using the supplied credentials as an unsigned, unencrypted connection.
The following mitigation was suggested by upstream:
When using the smbclient command, always add the argument "--signing=required" when using the "-e" or "--encrypt" argument.
Alternatively, set the variable "client signing = mandatory" in the [global] section of the smb.conf file on any client using encrypted connections.
To protect a Samba server exporting encrypted shares against a downgrade attack set the variable "smb encrypt = mandatory" in the smb.conf definition of the encrypted shares.
As per samba upstream advisory:
All versions of Samba from 4.0.0 to 4.3.2 inclusive are vulnerable to a denial of service attack in the samba daemon LDAP server.
A malicious client can send packets that cause the LDAP server in the samba daemon process to become unresponsive, preventing the server from servicing any other requests.
This flaw is not exploitable beyond causing the code to loop expending CPU resources.
The Samba Project reports:
All versions of Samba from 3.2.0 to 4.3.1 inclusive are vulnerable to a missing access control check in the vfsshadowcopy2 module. When looking for the shadow copy directory under the share path the current accessing user should have DIRECTORYLIST access rights in order to view the current snapshots.
This was not being checked in the affected versions of Samba.
https://bugzilla.samba.org/showbug.cgi?id=11529