illumos gate

Abstract:
A user who can create an NT Named Stream on an object can use
that handle to change permissions on that underlying object.

Author: Matthew Barden <matt.barden@nexenta.com>

Details:
[MS-FSA] describes three distinct cases for an open request:

1. A new object is being created, where no access checks are done to the created object.
2. A new stream is being created on an existing object, and access checks are performed on the underlying object.
3. An existing stream is being opened on an existing object, and access checks are performed on the underlying object.

The SMB Server treats case 2 as if it were case 1. As such, the SMB Server performs no access checks when creating named streams on existing objects. However, as NT Named Streams are implemented as ZFS Extended Attributes, ZFS requires a user have READ_XATTR and WRITE_XATTR permissions (included in GENERIC_READ and GENERIC_WRITE) to the underlying object in order to create named streams on it.

Additionally, the SMB protocol requires NTFS-like open handle semantics, where permissions granted at the time of handle creation remain effective for the lifetime of the handle, and additional
filesystem access checks are not performed. This means a user who can create a Named Stream on an object can grant themselves any access they desire, such as the WRITE_DAC permission, and make use of that permission for the lifetime of the handle.

Furthermore, the SMB Server 'redirects' get/set attributes/security requests to the underlying object, rather than the named stream itself, as NT named streams do not have their own logical filesystem properties beyond size.

When these are combined, a vulnerability emerges: A user who has READ_XATTR and WRITE_XATTR permissions to an object can create a named stream on the object, request WRITE_DAC on that handle, then use that handle with a "set security information" request to change permissions on the underlying object, such as to grant themselves full_control.

What is affected:
All versions of Illumos-based operating systems that contain an SMB Server are affected. This flaw has been verified as far back as OpenIndiana 147, released in September 2010. The flaw appears in source code dating back to the introduction of the SMB server in 2008.

Mitigating factors:
Servers that do not enable the SMB server are not affected, as local filesystem access and NFS access are not affected. Files and Directories that do not grant READ_XATTR and WRITE_XATTR to users who do not also have WRITE_ATTRIBUTES and WRITE_DAC are not
affected, as it would grant no additional capabilities.
The SMB Server does not support SMB Extended Attributes, and so grants of READ_XATTR and WRITE_XATTR are only necessary for clients that make use of named streams; As such, few users have reason to grant these.
Note that using the Window's 'basic permissions' screen to grant a user generic READ (or READ+EXECUTE) and WRITE permissions will grant that user READ_XATTR and WRITE_XATTR.
Anonymous and Guest accounts aren't treated differently - If they're not granted these accesses, they can't gain additional access.

What can be done with this?
A user with READ_XATTR and WRITE_XATTR permissions to a file or directory can change permissions on that object, or attributes other than AT_SIZE.
A user who can create named streams on a directory can grant themselves DELETE_CHILD, and then delete objects in that directory, including to rename or move objects.
A user who can create named streams on a directory can add inheritable entries, and propogate those entries to newly created objects.
A user who can create named streams on a directory can propogate the default access mask (often 744) to existing objects in that directory by granting themselves DELETE_CHILD, and then moving them into a user-controlled directory.

What can't be done?
Users without READ_XATTR or WRITE_XATTR to an object (including those with no permissions) cannot use this.
Users cannot abuse inheritance to propogate user-controlled entries to pre-existing objects.
Users cannot modify permissions on READ-ONLY files, as WRITE_XATTR access will not be granted.

Workaround:
Remove WRITE_XATTR from any user who does not have WRITE_DAC; only users who need to access Named Streams require READ_XATTR/WRITE_XATTR.

Solution:
Patches and updates are available, making the following changes:

[MS-FSA] prohibits the use of Named Streams handles to set or get security information; the SMB server should obey this limitation. Additionally, the server should perform access checks against the underlying object when creating named streams on it.