After Step 2, our security release process will be the following:
We make a patch
We sparsely test it
We send it to the trusted validator group, and publish a reproducible binary for other validators, who can check that the trusted validator group confirmed the rebuild hash
Once enough of the validators have deployed it, we publish the patch, and non-trusted validators can verify our commitment
This proposal focuses on the “distributing the patch” part (steps 3-4) of this process. The “testing” part (step 2) is orthogonal to this proposal, as whatever we choose to do, we need to test with the patch still being secret.
Why should NEAR One work on this
Between steps 3 and 4 of our security release process, an attacker could reverse the binary we published, guess the vulnerability, and exploit it
What needs to be accomplished
We can randomize the binary, but with a seed that we publish along with the patch so that it stays reproducible.
Example work items would be:
Randomize struct fields order, similar to random_struct_layout, but allowing for a seed being set at compile-time, and making sure non-security-builds disable randomization, so that rustc is free to optimize as much as it wants
Randomize functions order and loading address? I’m not sure that would actually bring much in isolation, but along with the struct fields order randomization it could shake an attacker off even better
Main use case
With this change, binary-only releases would be safe against an attacker guessing. Honestly, the threat model is very restricted, and so it may. not be worth doing this for a long time. However, timeboxing this to 1-2 weeks would probably make sense, allow us to at least randomize struct fields order, and give us 80% of the benefit here.
The estimated time is 1-2 week-person. @Ekleog-NEAR can work on it
Assumptions
None
Pre-requisites
Security Release Process Step 2 needs to be performed first, because without it making binaries harder to reverse makes no sense
Out of scope
None
Task list
### Tasks
- [ ] randomize struct fields order (for security releases only)
- [ ] consider randomizing function order
- [ ] optionally, think of other things that could be randomized easily to make the binary harder to reverse
Goals
Background
After Step 2, our security release process will be the following:
This proposal focuses on the “distributing the patch” part (steps 3-4) of this process. The “testing” part (step 2) is orthogonal to this proposal, as whatever we choose to do, we need to test with the patch still being secret.
Why should NEAR One work on this
Between steps 3 and 4 of our security release process, an attacker could reverse the binary we published, guess the vulnerability, and exploit it
What needs to be accomplished
We can randomize the binary, but with a seed that we publish along with the patch so that it stays reproducible.
Example work items would be:
Main use case
With this change, binary-only releases would be safe against an attacker guessing. Honestly, the threat model is very restricted, and so it may. not be worth doing this for a long time. However, timeboxing this to 1-2 weeks would probably make sense, allow us to at least randomize struct fields order, and give us 80% of the benefit here.
Links to external documentations and discussions
Discussion has already started on the full design document.
Estimated effort
The estimated time is 1-2 week-person. @Ekleog-NEAR can work on it
Assumptions
None
Pre-requisites
Security Release Process Step 2 needs to be performed first, because without it making binaries harder to reverse makes no sense
Out of scope
None
Task list