Security release 0.18.1

[tessus]

Summary

Don't Panic. The exploit is limited. See details and impact below.

Details

rustypaste's upload handler accepts an optional custom filename HTTP header that overrides the paste's filename. Unlike the filename taken from the multipart Content-Disposition field (which is stripped down to a bare filename before use), the value of the filename header is used completely unvalidated. It is applied to the destination path with PathBuf::set_file_name() after the path has already passed the application's own directory-escape check, so a value containing ../relative/path/filename or /absolute/path/filename sequences allows an uploader to write the paste's content to an arbitrary path on the filesystem, outside the configured upload_path.

Impact

Any party able to reach the upload endpoint (unauthenticated by default, or any holder of a valid upload token when auth_tokens is configured) can write attacker-controlled content to any path the rustypaste process can write to, limited only by OS file permissions and systemd hardening.

Why is the impact limited?

Admins usually create a service user under which an applications runs. Additionally systemd allows the admin to limit the location a process can write to. These are all standard security practices.
But even if you were to run the rustypaste process as root (which is rather unlikely), an adversary would not be able to overwrite any (system) files on the server, because rustypaste adds an extension (timestamp meta data) to the file that is stored on the server.
The worst that could happen would be that an adversary could fill up a filesystem, if the process were to run as root. However, the chance for this is low, because multiple unlikely conditions must be met for this to happen.