Skip to content

F-5.16: Silly-Rename Files Detected (Open-Unlinked Indicator)

Classification

  • Severity: Info
  • CVSS Vector: Network / Low Complexity / Low Privileges Required
  • Affected Versions: NFSv2, NFSv3, NFSv4
  • RFC Reference: None (implementation-specific behavior; no RFC defines silly rename)
  • Prerequisite: Directory read access on the export root

Summary

NFS "silly rename" is a client-side workaround for the POSIX open-unlink semantic: when a process deletes a file that another process still has open, the NFS client renames it to .nfsXXXXXXXXXXXXXXXX (hex-encoded inode and a uniquifier) instead of removing it immediately. The file is deleted when the last file descriptor is closed. The presence of .nfs* files in a directory listing confirms that the export is actively used, that processes have open file descriptors to deleted files, and that those files still contain their original data on the server.

Technical detail

Silly rename mechanism

On a local filesystem, unlink() on an open file removes the directory entry but keeps the inode alive until all file descriptors are closed. NFS cannot replicate this because the server has no knowledge of client-side file descriptors. The client-side workaround:

1. Client A opens /export/data.csv (fd=3)
2. Client B calls unlink("/export/data.csv")
3. NFS client B issues RENAME("data.csv" -> ".nfs00000002abcdef01")
   instead of REMOVE("data.csv")
4. Client A continues reading from fd=3 -- the file is still accessible
   under its temporary name
5. When Client A closes fd=3, the NFS client issues REMOVE(".nfs00000002abcdef01")

Filename pattern

Linux NFS clients generate silly-rename names as:

.nfs<hex_inode><hex_counter>

For example: .nfs0000000200000003 (inode 2, counter 3). The name is always lowercase hex digits after the .nfs prefix.

What silly renames reveal

Signal Intelligence Value
Export is actively used Processes are running that interact with this export
Open file descriptors exist At least one process holds an open fd to a "deleted" file
File data persists The silly-rename file contains the full original content
Application behavior The pattern of silly renames hints at the application type (databases, log processors, build systems)

Exploitation relevance

Silly-rename files are interesting because:

  1. Data recovery: The files contain data that an application expected to be deleted. This may include temporary credentials, intermediate computation results, or sensitive data being rotated.
  2. ETXTBSY bypass: NFS does not enforce ETXTBSY (text file busy) -- an attacker can overwrite a silly-renamed executable while it is still running, potentially injecting code.
  3. Activity mapping: The number and churn rate of silly-rename files reveals the export's usage pattern and peak activity windows.

Impact

  • Informational -- confirms active use of the export and the presence of open-unlinked files
  • Silly-rename files may contain sensitive data that the deleting application expected to be gone
  • The .nfs* pattern can be used to identify high-value targets for content replacement attacks

Detection (nfswolf)

The analyzer performs READDIRPLUS on the export root and matches filenames against the .nfs* pattern (prefix .nfs followed by one or more hex digits). If matches are found, the finding fires at Info severity with the count and up to 10 example filenames in the evidence.

Remediation

  1. Awareness only -- silly rename is a fundamental NFS client behavior that cannot be disabled without breaking POSIX semantics

  2. Application review -- investigate which processes are creating the silly-rename files and whether the files contain sensitive data that should be securely erased

  3. Restrict write access -- if the attacker cannot write to the export, they cannot overwrite silly-rename files to inject content into running processes

  4. Local processing -- move sensitive file operations (credential rotation, temp files) off NFS exports onto local filesystems where unlink() behaves as expected