Lack of integrity verification of downloaded external dependencies

[mensfeld]

Hey,

My name is Maciej Mensfeld and I run a research security project called WhiteSource Diffend.io.

I've noticed, that this library downloads some external resources and uses them. While it's a totally common pattern, what is lacking here is integrity verification.

You could verify the integrity of the downloaded file before using it by comparing the file hash to a hardcoded, expected file hash.

This is essentially what package managers do to verify the integrity of downloaded packages.

Doing this would prevent attack scenarios in which raen is manipulated.

Have a great day :)

ref https://my.diffend.io/npm/naen-cli/0.0.1#d2h-954720-533

[willemneal]

Hey thanks!

Yeah we had placed too much trust in Github here. So while the file is produced from a tagged signed commit, we don't check that github sent the same file.

He have tried using IPFS in the past since the file is content addressed and has that built in, however, we found that a public gateway can still send corrupted bytes (though very rarely).

We copied this library originally from here: https://github.com/rustwasm/wasm-pack/blob/master/npm/binary.js

And it seems they are doing it too.

[mensfeld]

Why would you want to run a corrupted version? The way I've seen it in other places is to either fail loud with a checksum fail or restart download 1-3 times with a backoff and then fail if sha ain't good. This would allow you (retry) to satisfy the consistency and would provide security improvement.

[willemneal]

I never said I wanted to run a corrupted version. IPFS gateways occasionally returned an incorrect file, but it would fail.

I agree we should add this, but for now we will advise people to use cargo to build from source to avoid this security bug, while adding the checksum checks.