CWE-66 is about software that mishandles a file name that identifies a virtual resource, one that is not listed directly in the directory tied to that name. The software ends up performing file operations on something that is not a file.
Web servers, file servers and any app that maps request paths to files are the usual homes for this bug.
How it happens
Virtual file names look like normal names, but they are effectively aliases for other resources that do not behave like normal files. They are not necessarily listed in directories. Depending on what they do, they can act as alternate entities.
Because they look ordinary, filters and handlers written for normal files let them through. The server then applies file logic to a resource that follows different rules.
The observed examples make it concrete. CVE-1999-0278 describes IIS where remote attackers obtain source code for ASP files by appending "::$DATA" to the URL. CVE-2004-1084 is a server that lets remote attackers read files and resource fork content via HTTP requests to special file names related to multiple data streams in HFS+. CVE-2002-0106 is a server that can be pushed into a denial of service via a series of requests to .JSP files that contain an MS-DOS device name. See CVE-1999-0278, CVE-2004-1084 and CVE-2002-0106.
What an attacker gains
The MITRE record lists the consequence only as "Other". The examples suggest source code disclosure and denial of service, but those come from the individual CVEs, not a fixed rule for the weakness.
How to find it
MITRE cites a source that lists techniques with partial coverage at reasonable cost:
- Bytecode weakness analysis and binary or bytecode disassemblers, followed by manual review.
- Web application scanners.
- Fuzz testing with framework-based fuzzers.
A simple manual check is to request resources with known special suffixes or device-style names and see whether the server returns something other than a clean not-found response.
How to fix it
The record lists no formal mitigations. The sensible direction follows from the description: decide which names your software accepts, resolve them to a canonical form, and refuse anything that is not a plain file you expect to serve. Keep source files outside any directory that is served as content.
Quick check
What did the IIS example in CVE-1999-0278 show?
Appending "::$DATA" to the URL made the server return the source of an ASP file instead of running it.
