TrueNAS 12.0-U6.1 Released

MrT_134

Super Moderator
Moderator
iXsystems
Joined
Aug 25, 2016
Messages
14
Last edited:

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,554
If your TrueNAS server is joined to an Active Directory domain, you should upgrade to this version as soon as possible:
Subject: A user in an AD Domain could become root on domain members

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N (8.1)

For convenience, I have copied the upstream security announcement in its entirety here:
CVE-2020-25717.html:


===========================================================
== Subject: A user in an AD Domain could become root on
== domain members
==
== CVE ID#: CVE-2020-25717
==
== Versions: All Samba versions since Samba 3.0
==
== Summary: Samba may map domain users to local users
== in an undesired way.
===========================================================

===========
Description
===========

Windows Active Directory (AD) domains have by default a feature to
allow users to create computer accounts, controlled by
ms-DS-MachineAccountQuota.

In addition some (presumably trusted) users have the right to create
new users or computers in both Samba and Windows Active Directory
Domains.

These features can be quite dangerous in the wrong hands, as the user
who creates such accounts has broad privileges to not just create them
and set their passwords, but to rename them at a later time with the
only contraint being they may not match an existing samAccountName in
AD.

When Samba as an AD Domain member accepts a Kerberos ticket, it must
map the information found therein to a local UNIX user-id (uid). This
is currently done via the account name in the Active Directory
generated Kerberos Privileged Attribute Certificate (PAC), or the
account name in the ticket (if there is no PAC).

For example, Samba will attempt to find a user "DOMAIN\user" before
falling back to trying to find the user "user".

If the DOMAIN\user lookup can be made to fail, then a privilege
escalation is possible.

The easiest example to illustrate this is if an attacker creates an
account named root (by renaming a MachineAccountQuota based machine
account), and asks for a login without a Kerberos PAC. Between
obtaining the ticket and presenting it to a server, the attacker
renames the user account to a different name. Samba attempts to look
up "DOMAIN\root", which fails (as this no longer exists) and then
falls back to looking up user "root", which will map to the privileged
UNIX uid of 0.

This patch changes Samba to require a PAC (in all scenarios related to
active directory domains) and use the SID and account name
values of the PAC, which means the combination represents the same point
in time. The processing is now similar to as with NTLM based logins.
The SID is unique and non-repeating and so can't be confused with another user.

Additionally, a new parameter has been added "min domain uid" (default
1000), and no matter how we obtain the UNIX uid to use in the process
token (we may eventually read /etc/passwd or similar), by default no
UNIX uid below this value will be accepted.

The patch also removes the fallback from 'DOMAIN\user' to just 'user',
as it dangerous and not needed when nss_winbind is used (even when
'winbind use default domain = yes' is set).

However there are setups which are joined to an active directory
domain just for authentication, but the authorization is handled
without nss_winbind by mapping the domain account to a local user
provided by nss_file, nss_ldap or something similar. NOTE: These
setups won't work anymore without explicitly mapping the users!

For these setups administrators need to use the 'username map' or
'username map script' option in order to map domain users explicitly
to local users, e.g.

user = DOMAIN\user

Please consult 'man 5 smb.conf' for further details on 'username
map' or 'username map script'. Also note that in the above example '\'
refers to the default value of the 'winbind separator' option.

[Added 2021-11-11]
There's sadly a regression that "allow trusted domains = no"
prevents winbindd from starting, fixes are available at
https://bugzilla.samba.org/show_bug.cgi?id=14899

Please also notice the additional fix and advanced example
for the 'username map [script]' based fallback from
'DOMAIN\user' to 'user'. See
https://bugzilla.samba.org/show_bug.cgi?id=14901 and
https://gitlab.com/samba-team/samba/-/merge_requests/2251

============
Beyond Samba
============

Samba is almost unique in the Linux/Unix landscape in that it can read
the PAC and make authorisation choices based on the SIDs in the PAC.

Administrators and those responsible for the deployment of other
applications that use Kerberos, and which can only rely on the "cname"
(client name) in the Kerberos ticket should take care not to map these
into the same namespace as system users.

NFS-Ganesha has a mode to map AD domain users via Samba's winbindd.
Use of this mode is encouraged, and (for all NFS servers in AD
domains) the default idmapd.conf "Method = nsswitch" is discouraged.

Likewise special care should be taken in the general configuration of
"auth_to_local" in a krb5.conf as might be used by other services.

==================
Patch Availability
==================

Patches addressing both these issues have been posted to:

https://www.samba.org/samba/security/

Additionally, Samba 4.15.2, 4.14.10 and 4.13.14 have been issued
as security releases to correct the defect. Samba administrators are
advised to upgrade to these releases or apply the patch as soon
as possible.

==================
CVSSv3 calculation
==================

CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N (8.1)

==========
Workaround
==========

Setting "gensec:require_pac=true" in the smb.conf makes the
DOMAIN\user lookup succeed, due to a cache prime in winbind, provided
nss_winbind is in use and no error paths are hit.

It would be prudent to pre-create disabled users in Active Directory
matching on all privileged names not held in Active Directory, eg

samba-tool user add root -H ldap://$SERVER -U$USERNAME%$PASSWORD --random-password
samba-tool user add ubuntu -H ldap://$SERVER -U$USERNAME%$PASSWORD --random-password
...

(repeat for eg all system users under 1000 in /etc/passwd or special
to any other AD-connected services, eg perhaps "admin" for a web-app)

Setting ms-DS-MachineAccountQuota to 0, in the Active Directory domain
is also advised, if possible.

The following settings might be additional mitigations (but they have
not been explicitly verified yet):

1. The use of the 'invalid users' option, note this needs to be
specified in the [global] section, as well as every share with an
existing 'invalid users' option, e.g.:

invalid users = root, ubuntu

2. The usage of the "obey pam restrictions = yes" together with
something like 'account required pam_succeed_if.so quiet uid >=
1000' in the pam configuration for "samba", please consult 'man 8
pam_succeed_if'.

=======
Credits
=======

Originally reported by Andrew Bartlett of Catalyst and the Samba Team.

Patches provided by:
* Stefan Metzmacher of SerNet and the Samba Team
* Samuel Cabrero of SuSE and the Samba Team
* Joseph Sutton of Catalyst and the Samba Team
* Alexander Bokovoy of Red Hat and the Samba Team
* Ralph Boehme of SerNet and the Samba Team

Andrew wishes to give much thanks to NetSPI for the blog
"MachineAccountQuota is USEFUL Sometimes: Exploiting One of Active
Directory's Oddest Settings" by Kevin Robertson[1], on which the full
horror of MachineAccountQuota became clear.

[1] https://www.netspi.com/blog/technic...ting/machineaccountquota-is-useful-sometimes/

==========================================================
== Our Code, Our Bugs, Our Responsibility.
== The Samba Team
==========================================================

If you need to wait for a maintenance window to upgrade, a few potential workarounds are mentioned in the security announcement. They may be applied as auxiliary parameters under Services->SMB, but said workarounds are untested on TrueNAS and so your best course of action is to upgrade as soon as it is practical.
 

anodos

Sambassador
iXsystems
Joined
Mar 6, 2014
Messages
9,554
Additional errata about the Samba security fix in 12.0-U6.1.

Since Samba 4.12 is technically end-of-life, and the scope and potential impact of the security fix is rather large, we opted for this release to rebase on the latest release of the Samba 4.13 branch (4.13.14). I believe this gives us the best opportunity to provide you with a smooth transition / update while guaranteeing that the most number of eyes have been put on ensuring the fixes are properly implemented.

Please feel free to PM me or file a jira ticket if you encounter an SMB related issue that is caused by this update.
 

John45622

Contributor
Joined
Dec 2, 2020
Messages
105
I installed this yesterday and this gave my setup a significant performance boost. I'm on an all OSX clients network and transfers are about 20% faster now. Also browsing folders over SMB is much snappier than before. So is bulk deleting large amounts of files inside folders which often took very long on U6 and older is now MUCH faster. I have changed nothing else. Just a straight update and that was it.

Well done and thank you!
 
Last edited:
Top