Ralph Boehme
2022-Jan-10 15:31 UTC
[Samba] [Announce] Samba meta-data symlink vulnerability CVE-2021-20316
On 1/10/22 16:06, Sven Schwedas via samba wrote:> 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?correct. Unless you allow access by ssh.> Or do Unix extensions always allow this race, even with > recent protocol versions?SMB2 and newer don't (yet) support UNIX extensions. -slow -- Ralph Boehme, Samba Team https://samba.org/ SerNet Samba Team Lead https://sernet.de/en/team-samba -------------- next part -------------- A non-text attachment was scrubbed... Name: OpenPGP_signature Type: application/pgp-signature Size: 840 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/samba/attachments/20220110/93481a10/OpenPGP_signature.sig>
Jeremy Allison
2022-Jan-10 16:51 UTC
[Samba] [Announce] Samba meta-data symlink vulnerability CVE-2021-20316
On Mon, Jan 10, 2022 at 04:31:02PM +0100, Ralph Boehme via samba wrote:>On 1/10/22 16:06, Sven Schwedas via samba wrote: >>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? > >correct. Unless you allow access by ssh.If you allow access via ssh, you have local access to all readable files anyway :-).
Jeremy Allison
2022-Jan-10 17:00 UTC
[Samba] [Announce] Samba meta-data symlink vulnerability CVE-2021-20316
On Mon, Jan 10, 2022 at 04:31:02PM +0100, Ralph Boehme via samba wrote:>On 1/10/22 16:06, Sven Schwedas via samba wrote: >>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? > >correct. Unless you allow access by ssh. > >>Or do Unix extensions always allow this race, even with recent >>protocol versions? > >SMB2 and newer don't (yet) support UNIX extensions.One more thing :-). The design for SMB2 UNIX extensions allows creation / removal / renaming of UNIX symlinks over SMB2 but how the server stores these is implementation dependent. The new (current now, I guess) VFS design makes smbd safe against real filesystem symlink escapes, but the current plan for smbd is *NOT* to store SMB2+UNIX extension symlinks are "real" filesystem symlinks, but to store them in an EA attached to a zero-length file. This will prevent any future problems with symlinks created by SMB (especially once the SMB1 code is removed from smbd) but at a cost of making the SMB2 UNIX symlinks not visible from NFS. That's a cost I think is worth it for the security safety benefits. User modifiable symlinks really are "The Worlds Worst Idea (tm)." I blame Berkeley :-).