nocompressio is vulnerable to swapped chunks in state files

[zhaozhongn]

Description

To prevent attack from swapping chunks in state files, the original compressio made each chunk's hash to be based on (data, size, previous_chunk_hash). The nocompressio is instead calculating chunk hash only based on (data, size). This means it will be vulnerable to swapped chunks in state files.

Steps to reproduce

No response

runsc version

No response

docker version (if using docker)

No response

uname

No response

kubectl (if using Kubernetes)

No response

repo state (if built from source)

No response

runsc debug logs (if available)

No response

[EtiennePerot]

I'm not sure what type of threat this would protect against. If an attacker has the ability to modify the checkpoint file, it can also just corrupt it or replace any chunk with whatever it wants. The hash is only good for verifying integrity against random transcription errors; it does not protect against malicious rewriting.

That being said, I see no harm in making it robust against this regardless, so long as it can be done in a high-performance-friendly way (which was the intent of adding nocompressio mode in the first place). Adding in previous_chunk_hash to the computation forces the integrity verification to be serialized, because each expected hash requires checking the previous one. I suggest making the hash be over (data, size, index of chunk within checkpoint) instead.