=============================================================================== == Subject: SMB3 connections don't keep encryption across DFS redirects == == CVE ID#: CVE-2017-12151 == == Versions: Samba 4.1.0 to 4.6.7 == == Summary: 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. == ================================================================================ =========== Description =========== Client command line tools like 'smbclient' as well as applications using 'libsmbclient' library have support for requiring 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 connect 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 should also enforce encryption. This is important as these redirects are transparent to the application. 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. That means, a man in the middle could read and/or alter the content of the connection. ================== Patch Availability ================== A patch addressing this defect has been posted to https://www.samba.org/samba/security/ Additionally, Samba 4.6.8, 4.5.14 and 4.4.16 have been issued as security releases to correct the defect. Samba vendors and administrators running affected versions are advised to upgrade or apply the patch as soon as possible. ========== Workaround ========== Keep the default of "client max protocol = NT1".