Write Once, Shell Everywhere Turning Arbitrary File Writes into RCE

Arbitrary file write bugs are often rated medium because proving real impact is hard when a tester cannot drop a web shell or overwrite an obvious configuration file. The talk targets that gap for black-box testing. It treats the write primitive as fully controlled and asks two questions: where to write, and what to write to reach code execution.

The method starts with the write result itself. Failed writes reveal whether a path exists, whether it is a directory, and whether the writer has permission. Differences in status codes or error handling can expose this even when no error message is returned. Probing paths that are specific to each Linux distribution or language version builds a profile of the target. The speakers recommend benign probes only, since production traffic may be logged or blocked by a WAF. They then covered several concrete routes. A Bash entry point in a containerized job can be overwritten through a file descriptor that points at the running script, padded with no-op bytes so the shell reaches the injected command. In Ruby on Rails, a schema cache file that is loaded with unsafe YAML deserialization leads to a gadget chain that ends in code execution. In Node.js, worker modules in libraries such as Piscina read their worker file from disk each time a worker spawns, so overwriting that predictable path runs attacker code.

The practical takeaway is to identify the execution context before rating a file write, since the runtime often determines which targets exist. Testers should check framework-known and deterministic paths, watch for files that are loaded as code or cache, and use quiet probes on live systems.