Client command line tools like 'smbclient' as well as applications using 'libsmbclient' library have support for required encryption. This is activated by the '-e|--encrypt' command line option or the smbc_setOptionSmbEncryptionLevel() library call. By default, only SMB1 is used in order to do connections to a server, as the effective default for "client max protocol" smb.conf option as well for the "-m|--max-protocol=" command line option is "NT1". If the original client connection used encryption, following DFS redirects to another server also enforce encryption. This is important as these redirects are transparent to the application. In case "SMB3", "SMB3_00", "SMB3_02", "SMB3_10" or "SMB3_11" is used as max protocol and a connection actually made use of the SMB3 encryption, any redirected connection looses the requirement for encryption and maybe also the requirement for signing. That means, a man in the middle can read and/or alter the content of the connection.
Acknowledgments: Name: the Samba project Upstream: Stefan Metzmacher (SerNet)
Mitigation: Keep the default of "client max protocol = NT1".
Statement: The samba4 package in Red Hat Enterprise Linux 6, is a tech preview and by default uses the SMB1 protocol, therefore though affected by this flaw, will not be addressed in a security update.
External References: https://www.samba.org/samba/security/CVE-2017-12151.html
Created samba tracking bugs for this issue: Affects: fedora-all [bug 1493441]
This issue has been addressed in the following products: Red Hat Enterprise Linux 7 Via RHSA-2017:2790 https://access.redhat.com/errata/RHSA-2017:2790
This issue has been addressed in the following products: Red Hat Gluster Storage 3.3 for RHEL 6 Red Hat Gluster Storage 3.3 for RHEL 7 Via RHSA-2017:2858 https://access.redhat.com/errata/RHSA-2017:2858