mirror of
https://github.com/Cisco-Talos/clamav.git
synced 2026-10-12 02:01:44 +00:00
Valerie Snyder
3826779c74
Quarantine actions previously validated a source path or destination directory, scanned through that path, and then reopened pathnames later to copy, move, or remove infected files. A local attacker who could replace a source path, symlink, or quarantine directory between those steps could cause ClamAV to copy, move, or delete an object different from the one that produced the detection, or redirect the quarantined output. This change makes quarantine actions operate on objects that were opened and validated before the scan. The shared action_source_t records the user-facing display path, the action path, the scan descriptor, stable file metadata, and Windows handle state. clamscan, clamdscan, clamonacc, clamd, and scanmem pass that source object from scan setup through the quarantine callback so action code does not have to trust mutable pathnames after a detection. On POSIX, destination setup opens and retains the validated quarantine directory, then creates the per-run lock file and destination files relative to that directory. Source opens use no-follow traversal for resolved action paths. Copy reads from the opened scan descriptor. Move is copy plus a verified unlink, and remove captures the final path component into a private directory before deleting it. Device and inode metadata from the scanned file are checked before unlinking. Copy and move revalidate that the configured quarantine path still names the retained destination directory before reporting success. Mismatched private captures are restored only when the platform supports no-replace rename. That conservative behavior avoids hiding a replacement object when a writable directory races the action path. On Windows, destination setup retains an opened directory handle and actions operate through normalized long-path names or retained handles. Move and remove try to keep DELETE access on the scanned source handle; if that access is not available, scanning still proceeds and the action reopens the path at action time, validating the reopened object against the scanned file before deleting. Windows copy preserves alternate data streams, basic file times and attributes, and security metadata where available. File metadata preservation now follows the platform capabilities. Linux copies mode, ownership when permitted, timestamps, and extended attributes from the scanned source. macOS uses fcopyfile() with COPYFILE_ALL. Windows copies named streams, basic metadata, and security descriptors. Metadata failures that are not required for a safe detection do not suppress the detection. The client paths now keep reporting stable for users while separating display paths from action paths. clamd and clamdscan still print the submitted path, but clamd resolves callback paths before opening them so a symlinked parent component cannot change the object scanned after cli_ftw() checks. VirusEvent and quarantine actions receive the resolved scan target. clamdscan and clamonacc use client-opened FILDES or INSTREAM scans when quarantine actions are enabled so clamd does not need to reopen mutable source names. For local quarantine-action directory walks, clamdscan applies clamd CrossFilesystems=no policy to avoid crossing mount points that daemon-side scans would skip. clamdscan --memory applies clamd ExcludePath to each module before direct or packed-module scans. When quarantine actions are enabled, scanmem resolves memory module action sources with the same sharing policy used by action source opens, filters both the submitted module path and resolved path, and uses the resolved path for direct module scanning and quarantine action setup. scanmem avoids caching infected module results while actions are enabled so move or remove can be retried after unload or action failure. The regression coverage exercises destination replacement, source symlink and replacement races, relative source paths, clamdscan scan modes, quarantine lock creation through the validated directory, Windows move and delete behavior, and metadata preservation paths. Reported-by: Hiroki Imai from Ricerca Security, Inc. CLAM-2959