You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Vulnerability is found in package A (that for example allows code execution or bypass signature verification)
Fix is released to package A in version X+1
Agents are upgraded to use version X+1 in package A
One year latter Server is compromised
Attacker have old files version X of package A with signature and use this data to downgrade agents to vulnerable version
Attacker have code execution on Agents
It will be nice to prevent from such scenario.
Possible solution:
Signature should be generated for pair (SIGNATURE_COUNTER, downloadable executable)
Agent should only accept downloadable executable with SIGNATURE_COUNTER >= CURRENT_SIGNATURE_COUNTER
Agent after accepting downloadable executable sets CURRENT_SIGNATURE_COUNTER=SIGNATURE_COUNTER
Now such scenario is not possible, since attacker is not able to downgrade agents to version X
Server operator after any change (or security patches) to packages sets SIGNATURE_COUNTER=SIGNATURE_COUNTER+1 and recalculates signature for all packages.
Legitimate downgrades (with access to Certificate Authority private key) are still possible - just sign the old binary with new version.
I know that the actual code-signing and verification mechanism is Agent specific and this could be possibly implemented as part of it, but I think it may be worth to add this here since this problem scenario is rather related to problem of code signing for downloadable executables than generic code signing.
The text was updated successfully, but these errors were encountered:
I think it may be worth to extend Code Signing section (https://github.com/open-telemetry/opamp-spec/blob/main/specification.md#code-signing) and add downgrade protection recommendation.
Let's consider following scenario:
It will be nice to prevent from such scenario.
Possible solution:
Now such scenario is not possible, since attacker is not able to downgrade agents to version X
Server operator after any change (or security patches) to packages sets SIGNATURE_COUNTER=SIGNATURE_COUNTER+1 and recalculates signature for all packages.
Legitimate downgrades (with access to Certificate Authority private key) are still possible - just sign the old binary with new version.
I know that the actual code-signing and verification mechanism is Agent specific and this could be possibly implemented as part of it, but I think it may be worth to add this here since this problem scenario is rather related to problem of code signing for downloadable executables than generic code signing.
The text was updated successfully, but these errors were encountered: