openSUSE 15 Security Update : samba (openSUSE-SU-2021:3650-1)

high Nessus Plugin ID 155191

Language:

Synopsis

The remote SUSE host is missing one or more security updates.

Description

The remote SUSE Linux SUSE15 host has packages installed that are affected by multiple vulnerabilities as referenced in the openSUSE-SU-2021:3650-1 advisory.

- An attacker can downgrade a negotiated SMB1 client connection and its capabitilities. Kerberos authentication is only possible with the SMB2/3 protocol or SMB1 using the NT1 dialect and the extended security (spnego) capability. Without mandatory SMB signing the protocol can be downgraded to an older insecure dialect like CORE, COREPLUS/CORE+, LANMAN1 or LANMAN2. Even if SMB signing is required it's still possible to downgrade to the NT1 dialect if extended security (spnego) is not negotiated. The attacker is able to get the plaintext password sent over the wire even if Kerberos authentication was required. The problem is only possible if all of the following options are explicitly set together: client NTLMv2 auth = no client lanman auth = yes client plaintext auth = yes client min protocol = NT1 # or lower In currently supported Samba versions all of the above options have different default values, so the problem is very unlikely to happen. Samba 4.5 and older had an additional problem, even in the default configuration, as they send ntlmv2, ntlm or lanman responses. Which means the attacker might be able to do offline attacks in order to recover the plaintext password, lmhash or nthash values. Requiring Kerberos authentication for SMB1/2/3 connections can be controlled by the '-k'/'--kerberos' or '-k yes'/'--kerberos=yes' command line options of various tools like: smbclient, smbcquotas, smbcacls, net, rpcclient, samba-tool and others.
Note that 4.15 deprecated '-k/--kerberos*' and introduced '--use-kerberos=required' command line option as well as the smb.conf option client use kerberos = required. For libsmbclient based applications the usage of Kerberos is controlled by the following function calls: smbc_setOptionUseKerberos(), smbc_setOptionFallbackAfterKerberos() and smbc_setOptionNoAutoAnonymousLogin(). (CVE-2016-2124)

- 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. (CVE-2020-25717)

- Samba implements DCE/RPC, and in most cases it is provided over and protected by the underlying SMB transport, with protections like 'SMB signing'. However there are other cases where large DCE/RPC request payloads are exchanged and fragmented into several pieces. If this happens over untrusted transports (e.g.
directly over TCP/IP or anonymous SMB) clients will typically protect by an explicit authentication at the DCE/RPC layer, e.g. with GSSAPI/Kerberos/NTLMSSP or Netlogon Secure Channel. Because the checks on the fragment protection were not done between the policy controls on the header and the subsequent fragments, an attacker could replace subsequent fragments in requests with their own data, which might be able to alter the server behaviour. DCE/RPC is a core component of all Samba servers, but we are most concerned about Samba as a Domain Controller, given the role as a centrally trusted service. As active directory domain controller this issue affects Samba versions greater or equal to 4.10.0. As NT4 classic domain controller, domain member or standalone server this issue affects Samba versions greater or equal to 4.13.0. (CVE-2021-23192)

Note that Nessus has not tested for this issue but has instead relied only on the application's self-reported version number.

Solution

Update the affected libndr0 and / or libndr0-32bit packages.

Plugin Details

Severity: High

ID: 155191

File Name: openSUSE-2021-3650.nasl

Version: 1.3

Type: local

Agent: unix

Family: SuSE Local Security Checks

Published: 11/11/2021

Updated: 2/28/2022

Supported Sensors: Continuous Assessment, Frictionless Assessment Agent, Frictionless Assessment AWS, Frictionless Assessment Azure, Nessus Agent, Nessus

Risk Information

VPR

Risk Factor: Medium

Score: 6.0

CVSS v2

Risk Factor: High

Base Score: 8.5

Temporal Score: 6.3

Vector: CVSS2#AV:N/AC:L/Au:S/C:C/I:C/A:N

CVSS Score Source: CVE-2020-25717

CVSS v3

Risk Factor: High

Base Score: 8.1

Temporal Score: 7.1

Vector: CVSS:3.0/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

Temporal Vector: CVSS:3.0/E:U/RL:O/RC:C

Vulnerability Information

CPE: cpe:/o:novell:opensuse:15.3, p-cpe:/a:novell:opensuse:libndr0-32bit, p-cpe:/a:novell:opensuse:libndr0

Required KB Items: Host/local_checks_enabled, Host/cpu, Host/SuSE/release, Host/SuSE/rpm-list

Exploit Ease: No known exploits are available

Patch Publication Date: 11/10/2021

Vulnerability Publication Date: 11/9/2021

Reference Information

CVE: CVE-2016-2124, CVE-2020-25717, CVE-2021-23192

Detections

Analytics