Sensitive data is not promptly cleared from memory #5

Open
opened 2 years ago by jahway603 · 1 comments
Collaborator

Ported from issue #4 on GitHub

Just says "See MyHush/SilentDragon#144" which brings us to further explanation of this issue.

Ported from [issue #4 on GitHub](https://github.com/MyHush/SilentDragonWormhole/issues/4) Just says "See [MyHush/SilentDragon#144](https://github.com/MyHush/SilentDragon/issues/144)" which brings us to further explanation of this issue.
Owner

In case Github goes away, here is the full details of the issue:

TOB-ZEC-022 from https://github.com/trailofbits/publications/blob/master/reviews/zecwallet.pdf

This is hard issue, that likely requires many changes. But it's important and worthwhile to reduce our attack surface. In general, whenever we are done with any type of sensitive information (public keys, private keys, hex codes for websocket encryption, etc), we should set the memory to zero.

This defensive programming will help in a situation where some type of memory corruption or Virtual Machine exploit is being used, and potentially one user on a physical server is trying to read the memory from another user on the same physical server (but maybe different VM).

Since our full node would also need to do this to be really effective, this is a nice-to-have but is not critical for SD. This task is more valuable for SilentDragonLite + SilentDragonAndroid, since no full node is running on the same computer there, and these security practices actually have a large improvement in safety. /cc @DenioD

In case Github goes away, here is the full details of the issue: TOB-ZEC-022 from https://github.com/trailofbits/publications/blob/master/reviews/zecwallet.pdf This is hard issue, that likely requires many changes. But it's important and worthwhile to reduce our attack surface. In general, whenever we are done with any type of sensitive information (public keys, private keys, hex codes for websocket encryption, etc), we should set the memory to zero. This defensive programming will help in a situation where some type of memory corruption or Virtual Machine exploit is being used, and potentially one user on a physical server is trying to read the memory from another user on the same physical server (but maybe different VM). Since our full node would also need to do this to be really effective, this is a nice-to-have but is not critical for SD. This task is more valuable for SilentDragonLite + SilentDragonAndroid, since no full node is running on the same computer there, and these security practices actually have a large improvement in safety. /cc @DenioD
Sign in to join this conversation.
No Label
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.