Summary

Wasmtime's WASI filesystem implementation lets a guest with a read-only source file capability overwrite that file by hard-linking it into another preopen that allows file writes. An attacker who can run a WASI guest can bypass WasiCtxBuilder per-preopen FilePerms and modify host files that were exposed as FilePerms::READ.

This attack is possible through the wasip1, wasip2, and wasip3 interfaces to the WASI filesystem.

This attack is also possible through an indirection of renaming a hardlink into another preopen.

Details

WasiCtxBuilder::preopened_dir documents file_perms as the maximum permissions usable for files in that preopen. However, hard-link creation and renaming only checked directory mutation for permission, and not whether the file permissions matched.

This makes an attack possible where:

• a read-only file target exists in a preopen with only FilePerms::READ
• a hardlink named alias, with destination to the target, is created in a preopen with FilePerms::READ | FilePerms::WRITE
• the attacker opens the file alias for writing, in which they can overwrite target

The same attack is possible by way of renaming:

• a read-only file target exists in a preopen with only FilePerms::READ
• a hardlink named alias, with destination to the target, is created in that same preopen
• the alias file is renamed into a preopen with FilePerms::READ | FilePerms::WRITE
• the attacker opens the file alias for writing, in which they can overwrite target

Symbolic links are not a vector for this attack because the wasi-filesystem interfaces already enforces that the destination for a symlink is under the same preopen. We do not believe there are any other vectors to this attack because there are no other wasi filesystem interfaces that take multiple borrows of a descriptor resource for e.g. the source and destination in different descriptors.

Remediation

The definition of Dir::link_at and Dir::rename_at in wasmtime-wasi's src/filesystem.rs now have an additional permissions check that ensures the source and destination values for the directory permissions perms and the file permissions file_perms are identical.

        if self.perms != new_dir.perms || self.file_perms != new_dir.file_perms {
            return Err(ErrorCode::NotPermitted);
        }

Impact

Only wasmtime-wasi embeddings that use a combination of DirPerms::MUTATE with FilePerms::READ, as well as using a second preopen with higher permissions (FilePerms::WRITE as well), are affected by this bug, e.g. those that use in the WasiCtxBuilder:

builder.preopened_dir("readwrite", "readwrite", DirPerms::READ | DirPerms::MUTATE, FilePerms::READ | FilePerms::WRITE);
builder.preopened_dir("readonly", "readonly", DirPerms::READ | DirPerms::MUTATE, FilePerms::READ);

In particular, the Wasmtime project's wasmtime-cli's use of wasmtime-wasi is not affected, because it always sets FilePerms::all() for all preopens.