So was trying to poke around with a few things to find vulnerabilities with deploying signed artifacts to devices - in particular, one that fills up the device and bricks it.
So realistically, if I have access to a genuine signed artifact and I create another that’s incorrectly signed but contains a seriously compressed file (e.g. full of zeros) - I can manipulate that artifact (as it’s just a tar) to place the manifest and signature of the genuine artifact inside it, so a device will accept it.
The scenario here is an attacker with access to our infrastructure and server, but doesn’t have access to our signing system.
I know the Mender server will check the manifests when trying to upload to the server (good!), but it may be possible then to directly interact with S3 to get a bad artifact on the server - I haven’t verified that yet, but even if it isn’t possible but some other checks, not everyone might be using a Mender server as means to push down artifacts!
So in this case, the device would be accepting what they thought to be a genuine update, as the signature of the manifest is correct, but it will have to extract everything before it can verify that the manifest itself is correct.
Could this possibly fill up the device and brick it, or are there measures in place in the Mender client to stop extracting and revert?
We were thinking maybe that the manifest could include the extracted size (so that would be signed), for which could be matched against the uncompressed size reported by the .gz of the 0000.tar, if possible.
Bit of an edge case, but still!