doc(security,aot): added security guidance around AoT binaries#4867
Open
srberard wants to merge 1 commit intobytecodealliance:mainfrom
Open
doc(security,aot): added security guidance around AoT binaries#4867srberard wants to merge 1 commit intobytecodealliance:mainfrom
srberard wants to merge 1 commit intobytecodealliance:mainfrom
Conversation
Adds explicit guidance distinguishing trusted AoT binaries from untrusted Wasm binaries, clarifies that malformed/manipulated AoT files are bugs not security issues, and cleans up wording in the security checklist section. Signed-off-by: Stephen Berard <stephen.berard@outlook.com>
There was a problem hiding this comment.
Pull request overview
Updates the security guidance doc to clarify how to classify security issues vs bugs when dealing with untrusted Wasm inputs versus trusted AoT outputs, and to refine the reporting checklist language.
Changes:
- Adds explicit guidance distinguishing untrusted WebAssembly binaries from trusted, toolchain-produced AoT binaries.
- Clarifies when AoT-related crashes/sandbox breaches should be treated as security issues (toolchain emission) vs non-security bugs (malformed/manipulated AoT artifacts).
- Edits the “crash or hang” checklist section and removes a formatting artifact.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Comment on lines
+17
to
+19
| WebAssembly binaries are considered untrusted. A Wasm binary that causes a breach of the Wasm sandbox or a crash of the runtime is considered to be a potential security issue. On the other hand, Ahead-of-Time (AoT) binaries are assumed to be generated by a trusted source and using the supported toolchain. Therefore, AoT binaries are considered trusted. As such, malformed or manipulated AoT binaries that breach the sandbox or cash crashes may be considered as bugs but are not classified as security issues. | ||
|
|
||
| If the AoT compiler and/or related tools emit an AoT binary that causes a breach of the Wasm sandbox or a crash is considered a potential security issue. It is assumed that the correct configuration and options are used when generating AoT binaries. Misconfiguration or misuse of the tooling options, therefore, are not considered to be security issues. |
There was a problem hiding this comment.
This sentence is grammatically incorrect/ambiguous ("emit ... that causes ... or a crash is considered"). Please rephrase so it's clear that an AoT toolchain producing a sandbox breach/crash is treated as a potential security issue (and keep subject/verb agreement consistent throughout).
Suggested change
| WebAssembly binaries are considered untrusted. A Wasm binary that causes a breach of the Wasm sandbox or a crash of the runtime is considered to be a potential security issue. On the other hand, Ahead-of-Time (AoT) binaries are assumed to be generated by a trusted source and using the supported toolchain. Therefore, AoT binaries are considered trusted. As such, malformed or manipulated AoT binaries that breach the sandbox or cash crashes may be considered as bugs but are not classified as security issues. | |
| If the AoT compiler and/or related tools emit an AoT binary that causes a breach of the Wasm sandbox or a crash is considered a potential security issue. It is assumed that the correct configuration and options are used when generating AoT binaries. Misconfiguration or misuse of the tooling options, therefore, are not considered to be security issues. | |
| WebAssembly binaries are considered untrusted. A Wasm binary that causes a breach of the Wasm sandbox or a crash of the runtime is considered to be a potential security issue. On the other hand, Ahead-of-Time (AoT) binaries are assumed to be generated by a trusted source and using the supported toolchain. Therefore, AoT binaries are considered trusted. As such, malformed or manipulated AoT binaries that breach the sandbox or cause crashes of the runtime may be considered as bugs but are not classified as security issues. | |
| If the AoT compiler and/or related tools emit an AoT binary that breaches the Wasm sandbox or causes the runtime to crash, this indicates a potential security issue in the AoT toolchain. It is assumed that the correct configuration and options are used when generating AoT binaries. Misconfiguration or misuse of the tooling options, therefore, is not considered to be a security issue. |
Comment on lines
+29
to
+35
| Does the | ||
| - Exposes sensitive information to unauthorized parties. | ||
| - Allows unauthorized modification of data or system state. | ||
| - Affects the availability of the system or its services. | ||
| - Permits unauthorized access to the system. | ||
| - Enables users to perform actions they should not be able to. | ||
| - Allows users to deny actions they have performed. |
There was a problem hiding this comment.
The checklist prompt is incomplete ("Does the"), and the bullets read like standalone statements ("Exposes", "Allows", etc.). Please rewrite this as a complete question (e.g., "Does the issue:" / "Does the bug:") and make the bullets grammatically consistent so readers can answer "Yes/No" unambiguously.
Suggested change
| Does the | |
| - Exposes sensitive information to unauthorized parties. | |
| - Allows unauthorized modification of data or system state. | |
| - Affects the availability of the system or its services. | |
| - Permits unauthorized access to the system. | |
| - Enables users to perform actions they should not be able to. | |
| - Allows users to deny actions they have performed. | |
| Does the issue: | |
| - expose sensitive information to unauthorized parties? | |
| - allow unauthorized modification of data or system state? | |
| - affect the availability of the system or its services? | |
| - permit unauthorized access to the system? | |
| - enable users to perform actions they should not be able to? | |
| - allow users to deny actions they have performed? |
| By default, native APIs and CLIs are following the principle of **caller guarantee**. If the caller provides incorrect parameters or users input malformed options, it is not a security issue. For example, if a user passes an invalid file descriptor to `fd_read`, it is not a security issue. | ||
|
|
||
| .wasm are not trusted. Malformed .wasm files should be handled gracefully. If a .wasm file causes a runtime crash or hang, it is a security issue. On the other hand, it's expected that aot runtime alone doesn't provide the same guarantee. So user-crafted .aot can cause anything, including crashes or hangs. They are not considered security issues. | ||
| WebAssembly binaries are not trusted. Malformed .wasm files should be handled gracefully. If a .wasm file causes a runtime crash or hang, it is a security issue. On the other hand, it's expected that aot runtime alone doesn't provide the same guarantee. So user-crafted .aot can cause anything, including crashes or hangs. They are not considered security issues. |
There was a problem hiding this comment.
This paragraph now conflicts with the earlier guidance that AoT binaries are considered trusted when produced by a trusted source/toolchain. It currently says "user-crafted .aot can cause anything"; please align terminology and threat model across both sections (trusted AoT vs untrusted/hand-crafted AoT) to avoid contradictory guidance.
|
|
||
| Given that WASI is a set of Capability-based APIs, all unauthorized actions are not supposed to happen. Most of the above security concerns can be alleviated. What remains for us is to ensure that the execution of Wasm modules is secure. In other words, do not compromise the sandbox. Unless it is explicitly disabled beforehand. | ||
|
|
||
| WebAssembly binaries are considered untrusted. A Wasm binary that causes a breach of the Wasm sandbox or a crash of the runtime is considered to be a potential security issue. On the other hand, Ahead-of-Time (AoT) binaries are assumed to be generated by a trusted source and using the supported toolchain. Therefore, AoT binaries are considered trusted. As such, malformed or manipulated AoT binaries that breach the sandbox or cash crashes may be considered as bugs but are not classified as security issues. |
There was a problem hiding this comment.
Typo/wording issue: "cash crashes" reads like a typo and changes the meaning. Please correct (e.g., "cause crashes"/"crash") and consider removing the extra double-spaces/trailing spaces in this paragraph for readability.
Suggested change
| WebAssembly binaries are considered untrusted. A Wasm binary that causes a breach of the Wasm sandbox or a crash of the runtime is considered to be a potential security issue. On the other hand, Ahead-of-Time (AoT) binaries are assumed to be generated by a trusted source and using the supported toolchain. Therefore, AoT binaries are considered trusted. As such, malformed or manipulated AoT binaries that breach the sandbox or cash crashes may be considered as bugs but are not classified as security issues. | |
| WebAssembly binaries are considered untrusted. A Wasm binary that causes a breach of the Wasm sandbox or a crash of the runtime is considered to be a potential security issue. On the other hand, Ahead-of-Time (AoT) binaries are assumed to be generated by a trusted source and using the supported toolchain. Therefore, AoT binaries are considered trusted. As such, malformed or manipulated AoT binaries that breach the sandbox or cause crashes may be considered as bugs but are not classified as security issues. |
lum1n0us
reviewed
Mar 9, 2026
| if a bug **results in crash or hang**, please treat it as a security problem and report it to a security advisor. The maintainer will look into it and change its category if needed. It is better safe than sorry. | ||
|
|
||
| If the author of an issue(results in crash or hang) can go through the following checklist and answer all questions with "No", it is fine to mark it as a regular bug. If not, please report it as a security issue. | ||
| If the author of an issue(results in crash or hang) can go through the checklist below and answer all questions with "No", it is fine to mark it as a regular bug. If not, please report it as a security issue. |
Contributor
There was a problem hiding this comment.
The original idea here is to use an easily recognizable characteristic to let the author finish a quick initial triage. Maybe a better description would be:
- If an issue is a hang or crash, report it as a security issue.
- If an issue doesn't end up with a hang or crash, but allows any of the following questions to be answered as YES, report it as a security issue.
But is this too strict?
| If the author of an issue(results in crash or hang) can go through the following checklist and answer all questions with "No", it is fine to mark it as a regular bug. If not, please report it as a security issue. | ||
| If the author of an issue(results in crash or hang) can go through the checklist below and answer all questions with "No", it is fine to mark it as a regular bug. If not, please report it as a security issue. | ||
|
|
||
| Does the |
Contributor
There was a problem hiding this comment.
maybe we can provide a list with WASM/WAMR-specific questions, such as escaping the sandbox, exposing unauthorized WASI APIs, and so on.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Adds explicit guidance distinguishing trusted AoT binaries from untrusted Wasm binaries, clarifies that malformed/manipulated AoT files are bugs not security issues, and cleans up wording in the security checklist section.