The branch, master has been updated
via 5038e2f add CVE-2021-20316.html
from 23d3a17 use html format for the CVE advisory (Samba 4.13.16
Security Release)
https://git.samba.org/?p=samba-web.git;a=shortlog;h=master
- Log -----------------------------------------------------------------
commit 5038e2f88f51ce6e49774b1c4db0d81f3ba65a7c
Author: Jule Anger <jan...@samba.org>
Date: Mon Jan 10 15:40:26 2022 +0100
add CVE-2021-20316.html
patches not possible -> without security release
Signed-off-by: Jule Anger <jan...@samba.org>
-----------------------------------------------------------------------
Summary of changes:
security/CVE-2021-20316.html | 128 +++++++++++++++++++++++++++++++++++++++++++
1 file changed, 128 insertions(+)
create mode 100644 security/CVE-2021-20316.html
Changeset truncated at 500 lines:
diff --git a/security/CVE-2021-20316.html b/security/CVE-2021-20316.html
new file mode 100644
index 0000000..71076da
--- /dev/null
+++ b/security/CVE-2021-20316.html
@@ -0,0 +1,128 @@
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
+ "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";>
+<html xmlns="http://www.w3.org/1999/xhtml";>
+
+<head>
+<title>Samba - Security Announcement Archive</title>
+</head>
+
+<body>
+
+ <H2>CVE-2021-20316.html:</H2>
+
+<p>
+<pre>
+===========================================================
+== Subject: Symlink race error can allow metadata read
+== and modify outside of the exported share.
+==
+== CVE ID#: CVE-2021-20316
+==
+==
+== Versions: All versions of the Samba file server prior to
+== 4.15.0
+==
+== Summary: A malicious client can use a symlink race to
+== access or modify file or directory metadata
+== information outside of the exported share.
+== The user must have permissions to read or write
+== the metadata on the accessed file or directory.
+===========================================================
+
+===========
+Description
+===========
+
+All versions of Samba prior to 4.15.0 are vulnerable to a malicious
+client using an SMB1 or NFS symlink race to allow filesystem metadata
+to be accessed in an area of the server file system not exported under
+the share definition. Note that SMB1 has to be enabled, or the share
+also available via NFS in order for this attack to succeed.
+
+Clients that have write access to the exported part of the file system
+under a share via SMB1 unix extensions or NFS can create symlinks that
+can race the server by renaming an existing path and then replacing it
+with a symlink. If the client wins the race it can cause the server to
+read or modify file or directory metadata on the symlink target.
+
+The authenticated user must have permissions to read or modify the
+metadata of the target of the symlink in order to perform the
+operation outside of the share.
+
+Filesystem metadata includes such attributes as timestamps, extended
+attributes, permissions, and ownership.
+
+This is a difficult race to win, but theoretically possible. Note that
+the proof of concept code supplied wins the race only when the server
+is slowed down and put under heavy load. Exploitation of this bug has
+not been seen in the wild.
+
+==================
+Patch Availability
+==================
+
+Prior to Samba 4.15.0 patches for this are not possible, due to the
+prior design of the Samba VFS layer which used pathname-based calls
+for most meta-data operations.
+
+A two and a half year effort was undertaken to completely re-write the
+Samba VFS layer to stop use of pathname-based calls in all cases
+involving reading and writing of metadata returned to the client.
+This work has finally been completed in Samba 4.15.0.
+
+Pathname-based VFS calls are still used as an initial optimization to
+determine if a client requested path exists, but when data is returned
+to the client or written onto the underlying filesystem then the
+target component is first opened as a file handle, going through
+rigourous checking to ensure it is contained within the share
+path. All meta-data is then refreshed from or written to the open
+handle, not via pathname-based VFS calls.
+
+As all operations are now done on an open handle we believe that any
+further symlink race conditions have been completely eliminated in
+Samba 4.15.0 and all future versions of Samba.
+
+==================
+CVSSv3.1 calculation
+==================
+
+CVSS:7.4/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:H/A:N/E:P/RL:O/RC:C/CR:M/IR:M/AR:X/MAV:N/MAC:H/MPR:L/MUI:N/MS:C/MC:H/MI:H/MA:N
+
+base score of 5.9.
+
+=================================
+Workaround and mitigating factors
+=================================
+
+Do not enable SMB1 (please note SMB1 is disabled by default in Samba
+from version 4.11.0 and onwards). This prevents the creation of
+symbolic links via SMB1. If SMB1 must be enabled for backwards
+compatibility then add the parameter:
+
+unix extensions = no
+
+to the [global] section of your smb.conf and restart smbd. This
+prevents SMB1 clients from creating symlinks on the exported file
+system.
+
+However, if the same region of the file system is also exported using
+NFS, NFS clients can create symlinks that potentially can also hit the
+race condition. For non-patched versions of Samba we recommend only
+exporting areas of the file system by either SMB2 or NFS, not both.
+
+=======
+Credits
+=======
+
+Reported by Michael Hanselmann of Google.
+
+The fix was a multi-year effort by Ralph Boehme of Sernet,
+Jeremy Allison of Google and Noel Power of SuSE.
+
+==========================================================
+== Our Code, Our Bugs, Our Responsibility.
+== The Samba Team
+==========================================================
+</pre>
+</body>
+</html>
--
Samba Website Repository
