Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lack of integrity verification of downloaded external dependencies #2

Open
mensfeld opened this issue May 13, 2022 · 3 comments
Open
Assignees
Labels
bug Something isn't working

Comments

@mensfeld
Copy link

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 willemneal added the bug Something isn't working label May 14, 2022
@willemneal willemneal self-assigned this May 14, 2022
@willemneal
Copy link
Member

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
Copy link
Author

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
Copy link
Member

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants