Serguey Asael Shinder: A reference to a place you can write is a bug, with or without a file there
The interesting security bug this week, in Project Zero's writeup, had nothing behind it. A Windows COM object was registered system-wide, trusted by every service on the machine, and its server DLL did not exist — the registration pointed at a path inside a directory any user can write to. The exploit was to create the file the system had already promised was there.
I keep this one because the shape is not about COM, or Windows, and it turns up in ordinary application code, Java included. The pattern is: a trusted component resolves a name to a location, and the location is writable by someone less trusted than the component. Whether anything is at the location yet is irrelevant — the attacker supplies it.
In a JVM service the same shape hides in mundane places:
- a classpath or module path entry pointing at a directory a deploy step populates, that something else can also write to;
ServiceLoaderdiscovering providers fromMETA-INF/serviceson a path that includes a writable directory — you get whatever implementation is found first;- a plugin or extension directory read at startup, where "drop a jar in here" is a feature for the operator and a foothold for anyone else who can drop a jar in there;
System.load/System.loadLibraryagainst a path resolved from configuration or an environment variable that a lower-privileged process controls;- a config file, keystore or credentials path taken from an env var, where the reference is trusted even though the place it points is not.
None of these need a malicious file present today to be a defect. The registration — the classpath entry, the services file, the plugin dir — is the vulnerability. The file is just the ammunition, and it can be supplied later by anyone who reaches the location.
Two habits fall out of this, and both are cheap:
Audit the resolvers, not the files. You cannot enumerate every malicious file that might someday appear. You can enumerate the places your privileged code will load from: every search path, every plugin directory, every config-driven file reference. For each, ask one question — can a less-privileged principal write here? Every "yes" is a bug whether or not anyone has written the payload.
Trust the reference no more than the most writable place it can resolve to. The COM object was trusted by the whole machine; the directory it resolved to was trusted by no one, and the gap between those two was the whole vulnerability. A path is only as trustworthy as its most writable resolution. If your code trusts a name, it is implicitly trusting every location that name can point at — so the location, not the name, is what you have to lock down.