path/filepath: Walk/WalkDir susceptible to symlink race

[neild]

The filepath.Walk and filepath.WalkDir functions are documented as not following symbolic links.

Both these functions are susceptible to a TOCTOU (time of check/time of use) race condition where a portion of the path being walked is replaced with a symbolic link while the walk is in progress.

The impact of this race condition is either mitigated or exacerbated (depending on your perspective) by the fact that the Walk/WalkDir API is fundamentally subject to TOCTOU races: Walk/WalkDir provides the names of files to a WalkFunc/WalkDirFunc, but the file may be replaced in between the WalkFunc/WalkDIrFunc being invoked and making use of the file name. This fundamental raciness means that a WalkFunc/WalkDirFunc that needs to defend against symlink traversal must use a traversal-resistant API to access files, such as github.com/google/safeopen or the proposed os.Root (#67002). Using a traversal-resistant file API will also defend against races in Walk/WalkDir itself.

Because of the inherent raciness of the Walk/WalkDir API, and the fact that fixing the TOCTOU vulnerability requires non-trivial implementation changes, we are classifying this as a PUBLIC track vulnerability.

This has been assigned CVE-2024-8244.

[adonovan]

The GNU find command (last I looked) used chdir and cwd-relative operations for traversal, I assume because of some combination of (a) it being faster because it avoids repeatedly parsing the name of the enclosing directory in the kernel's dcache layer, and (b) it avoids the TOCTTOU problem you describe. Now that we have fd-relative operations (openat, etc) one could write a variant of WalkDir that resolves every directory name at most once. I wonder how fast it would be.

Not that the world was clamoring for yet another version of WalkDir...

[os-sanitizer-dev]

Be advised that CVE-2024-8244 is still marked reserved, so potentially people have not been notified yet.