The RPC code generator in Samba 3.x before 3.4.16, 3.5.x before 3.5.14, and 3.6.x before 3.6.4 does not implement validation of an array length in a manner consistent with validation of array memory allocation, which allows remote attackers to execute arbitrary code via a crafted RPC call.

Heap-based buffer overflow in the dcerpcreadncacnpacketdone function in librpc/rpc/dcerpcutil.c in winbindd in Samba 3.x before 3.6.22, 4.0.x before 4.0.13, and 4.1.x before 4.1.3 allows remote AD domain controllers to execute arbitrary code via an invalid fragment length in a DCE-RPC packet.

As per upstream:

Samba client code always requests a forwardable ticket when using Kerberos authentication. This means the target server, which must be in the current or trusted domain/realm, is given a valid general purpose Kerberos "Ticket Granting Ticket" (TGT), which can be used to fully impersonate the authenticated user or service.

The risks of impersonation of the client are similar to the well known risks from forwarding of NTLM credentials, with two important differences: - NTLM forwarding can and should be mitigated with packet signing - Kerberos forwarding can only be attempted after the trusted destination server decrypts the ticket.

Finally, it should be noted that typically the connections involved are either explicitly requested, or are between or to Domain Controllers already of ultimate privilege.

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.

Samba 3.4 before 3.4.2, 3.3 before 3.3.8, 3.2 before 3.2.15, and 3.0.12 through 3.0.36, as used in the SMB subsystem in Apple Mac OS X 10.5.8 when Windows File Sharing is enabled, Fedora 11, and other operating systems, does not properly handle errors in resolving pathnames, which allows remote authenticated users to bypass intended sharing restrictions, and read, create, or modify files, in certain circumstances involving user accounts that lack home directories.

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.

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.

Cross-site request forgery (CSRF) vulnerability in the Samba Web Administration Tool (SWAT) in Samba 3.x before 3.5.21, 3.6.x before 3.6.12, and 4.x before 4.0.2 allows remote attackers to hijack the authentication of arbitrary users by leveraging knowledge of a password and composing requests that perform SWAT actions.

The Samba Web Administration Tool (SWAT) in Samba 3.x before 3.5.21, 3.6.x before 3.6.12, and 4.x before 4.0.2 allows remote attackers to conduct clickjacking attacks via a (1) FRAME or (2) IFRAME element.

A flaw was found in the way Samba handles the file descriptor sets (fdset) datastructure.

The Samba codebase uses file descriptor sets in various places. The fdset structure is a fixed size defined by the FDSETSIZE variable. If a file descriptor with a value greater than or equal to FDSETSIZE is added to a set, it can set a single bit on the stack to a '1'.

In Red Hat Enterprise Linux, all samba processes except for smbd have a limit set which prevents a process from allocating more than 1024 file descriptors by default. 1024 is the value of FDSETSIZE on Red Hat Enterprise Linux.

smbd does not cap the maximum allowed file descriptors below 1024. This means that if a remote attacker has the ability to open files on a Samba server, they may be able to flip arbitrary stack bits to a '1'. It is not currently believed that this flaw can be used for arbitrary code execution, but the possibility should not be ruled out.

Acknowledgements:

Red Hat would like to thank the Samba team for reporting this issue. Upstream acknowledges Volker Lendecke of SerNet as the original reporter.

The replysesssetupandXspnego function in sesssetup.c in smbd in Samba before 3.4.8 and 3.5.x before 3.5.2 allows remote attackers to trigger an out-of-bounds read, and cause a denial of service (process crash), via a \xff\xff security blob length in a Session Setup AndX request.

It was reported [1] that two vulnerabilities were found in Samba's smbd that would allow an attacker to trigger a null pointer dereference or an unitialized variable read by sending a specific 'Sessions Setup AndX' query. Successful exploitation of these issues would result in a denial of service. The upstream bug report [2] has a patch.

[1] http://www.stratsec.net/Research/Advisories/Samba-Multiple-DoS-Vulnerabilities-(SS-2010-005) [2] https://bugzilla.samba.org/showbug.cgi?id=7254

Originally the CVE-2010-0547 identifier has been assigned by Common Vulnerabilities and Exposures to the following security issue:

client/mount.cifs.c in mount.cifs in smbfs in Samba 3.4.5 and earlier does not verify that the (1) device name and (2) mountpoint strings are composed of valid characters, which allows local users to cause a denial of service (mtab corruption) via a crafted string.

Later a bug was found in the upstream patch for this issue. More specifically:

checkmtab() calls checknewline() to check device and directory name. checknewline() returns EXUSAGE (1) when error is detected, while checkmtab() expects -1 to indicate an error.

This bug in original CVE-2010-0547 fix (not to propagate the error properly) caused mount.cifs command on specially-crafted mount point (containing newline character) still to succeed and potentially, to corrupt mtab table on the systems, where CVE-2010-0296 glibc fix was not applied yet.

Proposed upstream patch by Jeff Layton: [1] http://thread.gmane.org/gmane.linux.kernel.cifs/3827