RustFS: The 'Anything Goes' S3 POST Policy

In the world of object storage, S3 Presigned POSTs are the gold standard for performance. Instead of piping gigabytes of user uploads through your fragile application servers, you sign a permission slip (a Policy) and tell the user, "Here, go talk to the storage server directly."

This Policy is a JSON document containing specific rules: the user can only upload to /avatars/user123, the file must be an image, and it can't be larger than 5MB. The backend signs this policy with a secret key, and the storage server (RustFS) is supposed to verify two things: 1) The signature is valid, and 2) The upload actually follows the rules in the policy.

RustFS got part 1 right. It checked the ID at the door. But it failed part 2 spectacularly. It let the user walk in with a dump truck full of garbage because, hey, their ID badge was legitimate.

The vulnerability lies in the implementation of the S3 PostObject API within RustFS versions 1.0.0-alpha.56 through 1.0.0-alpha.82. When a client performs a multipart form POST, they send the file data along with the base64-encoded policy and the signature.

Technically, RustFS was performing the cryptographic heavy lifting. It verified that the signature matched the policy provided. However, the code logic stopped there. It treated the policy conditions—content-length-range, starts-with, and eq checks—as decorative suggestions rather than mandatory constraints.

This is a classic breakdown between Authentication (Who are you?) and Authorization (What are you allowed to do?). The server authenticated the request successfully but completely skipped the authorization logic defined inside the signed payload.

While the exact snippet of the vulnerable code isn't public, the behavior suggests a control flow gap in the request handler. In a correct S3 implementation, the flow looks like this:

// Pseudocode of a SECURE implementation
let policy = parse_policy(&req);
if !verify_signature(&policy, &req.signature) {
    return Error("Invalid Signature");
}
 
// The step RustFS skipped:
for condition in policy.conditions {
    if !condition.is_satisfied_by(&req) {
        return Error("Policy Violation");
    }
}
 
process_upload(&req);

In the vulnerable versions of RustFS, the loop iterating over policy.conditions was effectively missing or non-functional. The server validated the crypto and immediately jumped to process_upload. This meant that even if your policy explicitly stated ["content-length-range", 0, 1024] (max 1KB), the server would happily accept a 10TB stream, filling the disk until the service crashed.

Let's assume you are an attacker targeting a web app using RustFS. The app allows you to upload a small avatar. You request an upload URL, and the backend gives you a signed policy restricting you to user/123/avatar.jpg and a max size of 1MB.

You take that valid signature and construct a new multipart/form-data request. Instead of the avatar, you target the system configuration.

Attack Scenario:

1. Bypass Prefix: The policy says ["starts-with", "$key", "user/123/"]. You change the form field key to admin/config.json. RustFS ignores the mismatch and overwrites the admin config.
2. Bypass Quota: The policy says max 1MB. You pipe /dev/urandom into the upload. RustFS keeps writing until the physical disk is full, causing a Denial of Service (DoS) for the entire cluster.
3. Bypass Type: The policy requires Content-Type: image/jpeg. You upload an SVG containing malicious JavaScript (<script>alert(1)</script>) and set the type to image/svg+xml. If the domain is serving content inline, you've just achieved Stored XSS.

The impact here is severe because it breaks the fundamental trust model of S3 offloading. Developers rely on these policies to sanitize inputs before they reach the storage layer.

• Integrity (High): Attackers can overwrite files they shouldn't have access to. If the bucket structure isn't strictly isolated by tenant (e.g., all users share one bucket), one user can wipe out another's data.
• Availability (High): Storage exhaustion is trivial. A single authenticated user can fill the storage backend, crashing the service for everyone.
• Confidentiality (None): Interestingly, this is a write-only vulnerability. Unless the attacker can overwrite a file that controls access logic (like an .htaccess or policy file), they cannot read data they shouldn't see. They can only destroy or replace it.

The fix is straightforward: the validation logic was added in version 1.0.0-alpha.83. If you are running RustFS, you must upgrade immediately.

If upgrading is not possible, you have few good options because the vulnerability is in the core API handling of the storage server. You would have to stop using Presigned POSTs entirely and proxy all uploads through your application server, where you can enforce size and type checks manually before streaming the data to RustFS. This defeats the performance purpose of RustFS, but it stops the bleeding.