samba announce - Jan 2022 - [Announce] Samba meta-data symlink vulnerability CVE-2021-20316

Security Advisory
-----------------

All versions of the Samba file server prior to 4.15.0 are affected by 
CVE-2021-20316. There will be no patches available for older Samba 
versions before 4.15 and 4.15 itself is already secure.

 ?* CVE-2021-20316: Symlink race error can allow metadata read
 ?? and modify outside of the exported share.

https://www.samba.org/samba/security/CVE-2021-20316.html

Please update affected systems as soon as possible.

======Details
======
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.

#######################################
Reporting bugs & Development Discussion
#######################################

Please discuss this release on the samba-technical mailing list or by
joining the #samba-technical IRC channel on irc.libera.chat or the
#samba-technical:matrix.org matrix channel.

If you do report problems then please try to send high quality
feedback. If you don't provide vital information to help us track down
the problem then you will probably be ignored.? All bug reports should
be filed under the Samba 4.1 and newer product in the project's Bugzilla
database (https://bugzilla.samba.org/).


Our Code, Our Bugs, Our Responsibility.
(https://bugzilla.samba.org/)

 ??????????????????????? --Enjoy
 ??????????????????????? The Samba Team
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.samba.org/pipermail/samba-announce/attachments/20220110/45a57b19/attachment.htm>

On 10.01.22 15:52, Jule Anger via samba wrote:
> ======> Details
> ======> 
> 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.
Just for clarification: If client min protocol is set to SMB2 or higher, 
*or* unix entensions are disabled, and NFS is not used, this is not 
exploitable? Or do Unix extensions always allow this race, even with 
recent protocol versions?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: OpenPGP_signature
Type: application/pgp-signature
Size: 665 bytes
Desc: OpenPGP digital signature
URL:
<http://lists.samba.org/pipermail/samba/attachments/20220110/bc3eb769/OpenPGP_signature.sig>