Samba this week released three security updates, including two related to SMB connections that could be abused by an attacker already on the network t
Samba this week released three security updates, including two related to SMB connections that could be abused by an attacker already on the network to hijack connections and manipulate traffic or data sent from a client.
The most serious of the bugs is CVE-2017-12150 where with certain configurations, Samba fails to enforce SMB signing in versions 1, 2 and 3. SMB signing digitally signs communication through the protocol at the packet level.
“A man in the middle attack may hijack client connections,” Samba said in its advisory.
Versions 3.0.25 to 4.6.7 are affected, and the issue is addressed in versions 4.6.8, 4.5.14 and 4.4.16, Samba said.
Samba identified four code paths where SMB signing is not enforced. From the advisory:
- The fixes for CVE-2015-5296 didn’t apply the implied signing protection when enforcing encryption for commands like ‘smb2mount -e’, ‘smbcacls -e’ and ‘smbcquotas -e’.
- The python binding exported as ‘samba.samba3.libsmb_samba_internal’ doesn’t make use of the “client signing” smb.conf option.
- libgpo as well as ‘net ads gpo’ doesn’t require SMB signing when fetching group policies.
- Commandline tools like ‘smbclient’, ‘smbcacls’ and ‘smbcquotas’ allow a fallback to an anonymous connection when using the ‘–use-ccache’ option and this happens even if SMB signing is required.
A similar bug, CVE-2017-12151, affects SMB3 connections in that they don’t maintain encryption across distributed file system services in Samba 4.1.0 to 4.6.7. The flaw can be remotely exploited by an attacker already on the network.
“A man in the middle attack can read and may alter confidential documents transferred via a client connection, which are reached via DFS redirect when the original connection used SMB3,” Samba said in its advisory.
The Samba Team explains that encrypted client connections should continue throughout subsequent DFS redirects to other servers.
“In the case where “SMB3”, “SMB3_00”, “SMB3_02”, “SMB3_10” or “SMB3_11″ was used as max protocol and a connection actually made use of the SMB3 encryption, any redirected connection would lose the requirement for encryption and also the requirement for signing,” Samba said. “That means, a man in the middle could read and/or alter the content of the connection.”
The flaw was addressed in Samba 4.6.8, 4.5.14 and 4.4.16.
Samba also patched a server memory leak over SMB1 affecting all versions of the software, in particular clients with write access to shares.
“Some SMB1 write requests were not correctly range checked to ensure the client had sent enough data to fulfill the write, allowing server memory contents to be written into the file (or printer) instead of client supplied data,” Samba said in an advisory. “The client cannot control the area of the server memory that is written to the file (or printer).”
Admins can set servers to use only SMB2 as a workaround, otherwise, update to 4.6.8, 4.5.14 or 4.4.16.