Add ruzstd uninit/out-of-bounds memory reads advisory

[paolobarbolini]

Creates the advisory for the vulnerability reported at KillingSpark/zstd-rs#75, fixed by KillingSpark/zstd-rs#76, and released as https://github.com/KillingSpark/zstd-rs/releases/tag/v0.7.3.

[Shnatsel]

Thank you for the report!

We normally use the informational = unsound variant for unsound APIs that can be misused, but I see the function is not exposed via the public API.

AFAIK it's not settled whether it is OK to copy uninitialized u8 values without ever observing them, and the compiler currently does not exploit that for optimization purposes.

However, I am concerned about the risk of exposing contents of uninitialized memory via a crafted input. I would like to hear from the maintainers about the potential impact of this issue.

[KillingSpark]

Hi, maintainer of ruzstd here:

As far as I can tell this could, with specially crafted inputs, result in the decoded output containing up to 15 bytes of heap memory that didn't belong to the allocation of the ringbuffer used during decoding. More specifically up to 15 bytes directly after that allocation.

So this could maybe be used to exfiltrate data from a process, if the process

• Decodes an attacker controlled archive
• Passes the decoded contents back to the attacker

Edit: The 15 bytes are the result of copying data using 128bit registers on SSE platforms. On other platforms a usize is used so on those it would be size_of(usize) - 1 bytes that could be included in the output

Edit 2: That's 15 bytes per case that the UB is hit which can happen multiple times per archive. The Buffer will re-allocate if it gets full, similar to Vec but it won't if the user drains it regularly. So the attacker might read a few different locations multiple times over the course of the decoding process, depending on how ringbuffer is drained.

[KillingSpark]

Can I ask what the recommended/common next steps are here? This is the first handling such a situation as a maintainer.

My guess would be:

• Find the released versions that include the error
• Yank them from crates.io
• Make new releases with a bumped minor that only fix this and change nothing else
• Delete the affected releases on github

Am I missing something?

[paolobarbolini]

I've updated the advisory with some of the feedback.

Find the released versions that include the error

I think the issue was introduced by KillingSpark/zstd-rs@2ee37fd. I've run miri on a checkout of v0.6.0 and it found no issues. Because of this I put < 0.7.0 as unaffected.

Make new releases with a bumped minor that only fix this and change nothing else

I've put >= 0.7.3 into the patched versions of the advisory.

So this could maybe be used to exfiltrate data from a process, if the process

• Decodes an attacker controlled archive

• Passes the decoded contents back to the attacker

I added the memory-exposure category.

[paolobarbolini]

Cross posting here too that the v0.7.3 release fixing the issue is out