[Announce] Samba 4.0.4 Security Release Available for Download

[steve]

On 21/03/13 00:17, Andrew Bartlett wrote:
> As our announcement of 4.0.4 has confused some of our administrators as
> to who is affected, and because there are IMPORTANT STEPS included that
> affected administrators need to follow, I'm posting the whole advisory
> text below:
>
> On Tue, 2013-03-19 at 11:04 +0100, Karolin Seeger wrote:
>> Release Announcements
>> ---------------------
>>
>> This is a security release in order to address CVE-2013-1863
>> (World-writeable files may be created in additional shares on a
>> Samba 4.0 AD DC).
>>
>> o  CVE-2013-1863:
>>     Administrators of the Samba 4.0 Active Directory Domain
>>     Controller might unexpectedly find files created world-writeable
>>     if additional CIFS file shares are created on the AD DC.
>>     Samba versions 4.0.0rc6 - 4.0.3 (inclusive) are affected by this
>>     defect.
>>
>>
>> Changes since 4.0.3:
>> --------------------
>>
>> o   Andrew Bartlett <abartlet at samba.org>
>>      * BUG 9709: CVE-2013-1863: Remove forced set of 'create mask' to 0777.
>
> ===========================================================
> == Subject:     World-writeable files may be created in additional shares on a
> ==		Samba 4.0 AD DC
> ==
> == CVE ID#:     CVE-2013-1863
> ==
> == Versions:    Samba 4.0.0rc6 - 4.0.3 (inclusive)
> ==
> == Summary:	Administrators of the Samba 4.0 Active Directory Domain
> ==		Controller might unexpectedly find files created world-writeable
> ==		if additional CIFS file shares are created on the AD DC.
> ==
> ===========================================================
>
> ===========
> Description
> ===========
>
> Administrators of the Samba 4.0 Active Directory Domain Controller might
> unexpectedly find files created world-writeable if additional CIFS file shares
> are created on the AD DC.
>
> By default the AD DC is not vulnerable to this issue, as a specific inheritable
> ACL is set on the files in the [sysvol] and [netlogon] shares.
>
> However, on other shares, when only configured with simple unix
> user/group/other permissions, the forced setting of 'create mask' and
> 'directory mask' on AD DC installations would apply, resulting in
> world-writable file permissions being set.
>
> These permissions are visible with the standard tools, and only the initial
> file creation is affected.  As Samba honours the unix permissions, the security
> of files where explicit permissions have been set are not affected.
>
> Administrators will need to manually correct the permissions of any
> world-writable files and directories.  After upgrading, either recursively set
> correct permissions using the Windows ACL editor, or run something like e.g.:
>
> sudo setfacl -b -R /path/to/share && sudo chmod o-w,g-w -R /path/to/share
> (Please note that this command might need to be adapted to your needs).
>
> This will remove all the ACLs (a reasonable step as this only impacts on shares
> without an ACL set), including a problematic default posix ACL on
> subdirectories.
>
> ==================
> Mitigating factors
> ==================
>
> By default the AD DC is not vulnerable to this issue, as a specific inheritable
> ACL is set on the files in the default [sysvol] and [netlogon] shares.
>
> Users of our file server when configured in any other mode, such as a
> standalone server, domain member (including of a Samba 4.0 AD Domain), file
> server or classic (NT4-like) domain controller are not impacted.  Many Samba
> 4.0 AD DC installations have followed the Team's advise to split their
> installation in this way, and so are not affected.
>
> Similarly, samba 4.0 AD DC installations based on the 'ntvfs' file server are
> not impacted.  This is not the default in upstream Samba, but importantly it is
> the only available configuration in samba4 packages of Samba 4.0 in Debian
> (including experimental) and Ubuntu supplied packages.
>
> Likewise, packages and installations built --without-ad-dc are not impacted, as
> only AD DC installations will set this configuration.  We understand Red Hat
> and Fedora installations are built in this mode.
>
> Unless guest access has been explicitly allowed (guest ok = yes), only
> authenticated users would be able to read/write any of accidentally
> world-writable files.  Similarly, the 'read only = no' default in the smb.conf
> still applies.
>
> ==========
> Workaround
> ==========
>
> Set a recursive and inherited ACL on the root of the share (for example, using
> the ACL editor on a Windows client)
>
> ==================
> Patch Availability
> ==================
>
> Patches addressing this defect have been posted to
>
>    http://www.samba.org/samba/security/
>
> Additionally, Samba 4.0.4, has been issued as security
> releases to correct the defect.  Samba administrators running affected versions
> are advised to upgrade to 4.0.4 or apply the patch as soon as
> possible.
>
> =======
> Credits
> =======
>
> The vulnerability was noticed by a number of observant administrators,
> including Ricky Nance <ricky.nance at weaubleau.k12.mo.us>.
>
> ==========================================================
> == Our Code, Our Bugs, Our Responsibility.
> == The Samba Team
> ==========================================================
Hi everyone

Is this bug 9730? https://bugzilla.samba.org/show_bug.cgi?id=9730

If I mount a share using cifs on a linux machine, all files are created 
universally rw'able. It makes no difference what ACL is set on the 
mounted share, files created are ALWAYS universally rw. Recursice ACL or 
not.

I am using the 4.0-test git branch and pulled and rebuilt this morning. 
No joy. Files are still created 0777. Applying the ACL as above makes no 
difference either.

Notes: this only effects cifs mounted shares. Writing to the unmounted 
share works exactly as expected, as does writing to the same share 
mounted via NFS. Also, mounting shares via cifs from a 3.6.6 server 
works as expected.

Conclusion: this issue only concerns the AD file server when running the 
samba binary.

We have had to stop access from Linux machines in our domain. Our 
workaround is to mount the shares using NFS for the Linux clients, but 
this is a pain. Is there any workaround for cifs?

Thanks,
Steve.