Subscribe to our Threatpost Today newsletter

Join thousands of people who receive the latest breaking cybersecurity news every day.

The administrator of your personal data will be Threatpost, Inc., 500 Unicorn Park, Woburn, MA 01801. Detailed information on the processing of personal data can be found in the privacy policy. In addition, you will find them in the message confirming the subscription to the newsletter.

*

*

I agree to my personal data being stored and used to receive the newsletter

*

I agree to accept information and occasional commercial offers from Threatpost partners

The administrator of your personal data will be Threatpost, Inc., 500 Unicorn Park, Woburn, MA 01801. Detailed information on the processing of personal data can be found in the privacy policy. In addition, you will find them in the message confirming the subscription to the newsletter.

Samba Update Patches Two SMB-Related MiTM Bugs

Samba 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.

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.

Authors

Threatpost

InfoSec Insider Post

InfoSec Insider content is written by a trusted community of Threatpost cybersecurity subject matter experts. Each contribution has a goal of bringing a unique voice to important cybersecurity topics. Content strives to be of the highest quality, objective and non-commercial.

Sponsored

Sponsored Post

Sponsored Content is paid for by an advertiser. Sponsored content is written and edited by members of our sponsor community. This content creates an opportunity for a sponsor to provide insight and commentary from their point-of-view directly to the Threatpost audience. The Threatpost editorial team does not participate in the writing or editing of Sponsored Content.