Attack possible by downgrading to earlier exploitable binary version by MITM about go-update

[thomasf]

So.. this is how I solved in my use case.. It could possibly be a pattern of interest to other people...

Adding the version number to the verifier:
alkasir/alkasir@5d57cc6

And a Version number check in the client before even trying to accept a patch:
alkasir/alkasir@ca8a5c1

[inconshreveable]

@thomasf Thanks for reporting this! I really appreciate it.

I will note that even when incorporating the version into the hash/signature calculations, an attacker who compromises the mechanism used to pull the metadata that describes 'the next available update' could still force a downgrade unless the second check for 'target version being higher than the current version' is implemented (which is difficult for a few reasons, timestamps are better). In short: compromising the update check could allow an attacker to return a valid tuple of [old version, old_signature, payload of old version] and circumvent this fix as well.

This kind of problem is avoided by using a more robust publishing/updating framework like TUF.

go-update's docs need to provide a security section explaining the threat model and the tradeoffs and compromises made in the design of the library.

In the meantime, this additional check will improve things, thanks again for sharing it.

[thomasf]

I will implement the valid version check in my client using a semver library so that the client only accepts a semver version newer than itself.

[thomasf]

Btw. I'm getting to this item some time tomorrow in the project I'm working on (which currently is being moved to https://github.com/alkasir/alkasir ).

[thomasf]

Btw. would you like me to contribute https://github.com/alkasir/alkasir/blob/master/pkg/upgradebin/ed25519Verifier.go to go-update?