[Task]: Force update in case of critical vulnerability

[Tuditi]

Task description

On the event of a security vulnerability in Firefly, we need to alert users to update. The user shouldn't be able to log in until he updates the patched version.

This was done in Trinity with a blacklist (S3 Bucket). Some more info can be found here:

Version listing: https://github.com/iotaledger/trinity-wallet/blob/develop/src/shared/libs/versions.json Trinity force update: https://github.com/iotaledger/trinity-wallet/blob/639c9f81eb7a1287cfbdf85af6cd7feeb7408e0f/src/desktop/src/ui/Index.js#L253

Requirements

TBD

Acceptance criteria

TBD

Creation checklist

• [x] I have assigned this task to the correct people
• [X] I have added the most appropriate labels
• [X] I have linked the correct milestone and/or project

[Tuditi]

Threat Model

A critical vulnerability is exposed. A user has to update his wallet, otherwise he risks losing his funds. A malicious actor has no access to the S3 server and cannot execute a DOS attack on the S3 server.

[Tuditi]

Security Requirements

• Only IF can post to S3 Server
• Observed trafic doesn't give information about user's version
• Non-blacklisted version cannot be tricked into thinking it's blacklisted (no false positives)
• Blacklisted version cannot be tricked into thinking it's not blacklisted (no false negatives)

[Tuditi]

Implementation

The implementation consists of the following tasks: get version list, make a decision whether or not to block FF, show an alert if update is needed and provide a mechanism to update it to the latest version.

1. Get version list

Upon start-up Firefly has to make a decision based upon a version blacklist stored remotely to show an alert and disable login. The remote blacklist (JSON example) can be maintained on an Amazon S3 Storage server.

Dev Tasks:

• [ ] Store version list on S3 (est. 0.5 day)
• [ ] Fetch remote blacklist (est. 0.2 day)
• [ ] Get current version (est. 0.1 day)

Q: Should the version list be signed by IF? If yes, we have to check signature.

2. Block

Login functionality has to be blocked, otherwise the user could be exposed to vulnerabilities.

Dev Tasks:

• [ ] Compare if blacklisted (est. 0.1 day)
• [ ] Disable login (est. 0.5 day)

3. Show alert

If login is blocked an alert has to be created with a cancel button and an update to latest version button. Potentially, we might need to add an option to reopen the model if the user clicks on cancel.

UI Task:

• [ ] Create an alert modal (est. 1 day)
• [ ] Create a user flow/requirements for case user clicks cancel (est. 1 day)

Dev Task:

• [ ] Create an alert modal (est. 0.5 day)
• [ ] Create a user flow/requirements for case user clicks cancel (est. 0.3 day)

4. Update Firefly

This step does not require anything new in particular, since we already have the function in place to update FF. Potentially, we might need to adapt something UI-wise.

Dev Tasks:

• [ ] Check if UI needs updating (est. 0.2 day)
• [ ] Test everything (est. 1 day)

[Tuditi]

Possibly only blacklist sensitive actions, such as unlocking stronghold/sending transactions/... .