Add advisory for unsound problem in wasmtime_jit_debug

[safe4u]

A soundness bug in wasmtime_jit_debug that wrongly marks the function dump_code_load_record as 'safe'.
The issue report: bytecodealliance/wasmtime#8905

[kornelski]

It looks like it's been patched in v27

bytecodealliance/wasmtime@b5e31a5

can you mark it as patched in the advisory?

[kornelski]

Needs to be updated with the patched version

[safe4u]

Needs to be updated with the patched version

Done. Thanks for your correction.

[solomoncyj]

pr is stil not merged. can a maintainer pleser merger it?

[djc]

@alexcrichton any feedback on this one?

[alexcrichton]

Personally, if acceptable, I'd prefer not to merge this. I think this was good to flag on our issue tracker and fix, but it's an internal crate to the project which we've documented users should not use. We have a number of wasmtime-* crates which are internal implementation details not intended for external consumption, and this is likely not the only issue with them. The advisories at least we on Wasmtime worry about are those reachable from public APIs we recommend users use (e.g. the wasmtime crate itself) and we would not accept security advisories for internal crates unless Wasmtime, through the public API, can trigger undefined behavior or such. Effectively while this was a good fix I don't believe this actually poses any risk to users. Anyone using the wasmtime crate itself would not have been exposed to this issue and no one should be using the wasmtime_jit_debug crate directly.

Now how exactly that falls under the advisory db here I'm not sure. We would ideally lint/etc that users shouldn't directly depend on these internal crates (and we could probably do a better job of messaging in Wasmtime as well), but doing so through advisories feels like something we should figure out in Wasmtime better rather than here.

Is it reasonable to ask this not be merged? If it's still desired to be merged I'd ask that we on Wasmtime have a moment to sort out how exactly to best discourage users from using internal crates before this is merged.

Also, as a side note, this advisory says <= 24.0.0 is affected while >= 24.0.0 is patched, meaning that 24.0.0 is simultaneously affected and patched. I believe the affected versions should be < 24.0.0 instead.

[djc]

Is it reasonable to ask this not be merged? If it's still desired to be merged I'd ask that we on Wasmtime have a moment to sort out how exactly to best discourage users from using internal crates before this is merged.

Given the purpose of internal-only usage, we can definitely delay merging this so you can figure out messaging/mitigation.

In my mind, if the crate is published to crates.io as a library that someone could potentially use, then issues with public, safe API should be fair game for advisories... Maybe it could make sense to guard the contents of the crate with an __internals feature and/or doc(hidden) flags?

@Shnatsel, @tarcieri, @alex any thoughts?

[alex]

I think I agree with that.

[alexcrichton]

Sounds reasonable! I've got an agenda item for our upcoming meeting next Thursday. I'll post here with a response after that