[dyslexicsteak]

Affected crate(s)

• Wasmtime (11,905,323 recent downloads)

Links to upstream issue(s) or PR(s)

• Compile-time builtin composition resolves guest imports from host working directory & has path failures bytecodealliance/wasmtime#15024
• Compose compile-time builtins in memory bytecodealliance/wasmtime#15025

Severity

There are various path bugs that allow directory traversal and OS errors, but primarily the bug allows an untrusted guest to make the runtime give full R/W access of host process memory to other untrusted code, at which point all bets are off as to what it could do as the entire host process is compromised.

This only affects embedders who opt into exposing the intrinsics, but their documented contract is violated. This part of the embedding API is also not considered to have tier 1 support (though that is yet undocumented), and as such will not receive a standard security response upstream. I was asked to file an issue publicly by the maintainers.

I've included a CVSS, and I believe this falls under the following CWEs:

• CWE-22: Using the import names verbatim allowing / to end up in paths
• CWE-73: Using the import name verbatim
• CWE-140: The extension logic and colons and slashes
• CWE-426/427: I'm not really sure which or both because the host neither necessarily controls where its working directory is nor does it necessarily control what's in it
• CWE-829: The loading of guest-chosen code with compile-time builtin privilege

I've tentatively included format-injection for the path related issues but I'm not sure if paths are included under it or how directly or inherently it has to lead to a vulnerability. I've also included a lot of the others because code with full R/W access to process memory could do anything, including DoS, code execution, violation of confidentiality, or writing arbitrary data.

Checklist

• Advisory filename(s) starts with RUSTSEC-0000-0000 as the ID
• date field is set to the public disclosure date
• Contains a concise and descriptive title after advisory metadata
• Asked maintainer(s) if publishing an advisory is appropriate

[djc]

[x] Asked maintainer(s) if publishing an advisory is appropriate

Where did this happen? I do not see anything in the upstream issue or PR. Did you just disclose these publicly?

cc @cfallin @alexcrichton @pchickey

[dyslexicsteak]

[x] Asked maintainer(s) if publishing an advisory is appropriate

Where did this happen? I do not see anything in the upstream issue or PR. Did you just disclose these publicly?

cc @cfallin @alexcrichton @pchickey

Over on Zulip and the advisory was closed privately for the feature not being tier 1.

This is the timeline I went through:

1. GHSA, closed for not being T1, told to just make a public issue
2. Double check on Zulip if they're sure this should be public, same response and 2nd opinion
3. I opened the issue and PR for the fix

My understanding is there's no embargo or anything and so I thought considering the severity people who use the affected function should be aware of this. I didn't ask specifically if an entry into the DB was warranted.

[alexcrichton]

As mentioned on Zulip and https://github.com/bytecodealliance/wasmtime/security/advisories/GHSA-hxp4-rv7v-wh5c (private since we closed it) the Wasmtime project does not consider this a vulnerability. In that sense we as maintainers of Wasmtime have explicitly said "no" to if publishing an advisory is appropriate for this.

This is a bug to fix for Wasmtime, yes, and the project is fine discussing this in public, but I would at least personally prefer if RUSTSEC advisories line up with what we consider an advisory, not what anyone might consider an advisory.

[djc]

My understanding is there's no embargo or anything and so I thought considering the severity people who use the affected function should be aware of this. I didn't ask specifically if an entry into the DB was warranted.

The checkmark in the pull request template is for whether the maintainer thinks publishing an advisory is appropriate. Seems like the maintainers clearly indicated they did not think it is?

[dyslexicsteak]

My understanding is there's no embargo or anything and so I thought considering the severity people who use the affected function should be aware of this. I didn't ask specifically if an entry into the DB was warranted.

The checkmark in the pull request template is for whether the maintainer thinks publishing an advisory is appropriate. Seems like the maintainers clearly indicated they did not think it is?

I understand the miscommunication now. I wasn't aware that usptream's maintenance/support policies were also applicable here, and that by advisory it was meant not only on the upstream repository itself as in via GHSA but also elsewhere.

Thank you, Alex, for clarifying.