From bd10f513e5f0dc18622b59cb10b4d1d45e19e06f Mon Sep 17 00:00:00 2001 From: Emanuele Aina <emanuele.aina@collabora.com> Date: Fri, 26 Feb 2021 11:04:18 +0100 Subject: [PATCH] system-updates-and-rollback: Clarify concerns about downgrade attacks Signed-off-by: Emanuele Aina <emanuele.aina@collabora.com> --- .../designs/system-updates-and-rollback.md | 23 +++++++++++++------ 1 file changed, 16 insertions(+), 7 deletions(-) diff --git a/content/designs/system-updates-and-rollback.md b/content/designs/system-updates-and-rollback.md index 18228d244..5d1e2c03d 100644 --- a/content/designs/system-updates-and-rollback.md +++ b/content/designs/system-updates-and-rollback.md @@ -148,13 +148,22 @@ be customizable. For instance, some products may chose to only roll back the base OS and keep applications untouched, some other products may choose to roll applications back as well. -Apertis recommends rollbacks to be allowed only after a system upgrade and before -confirming that the new version works as expected. Enabling rollbacks in general -could be a potential security issue, since a rollback could be used to install -a previous release with vulnerabilities. By taking this approach it also -simplifies how applications have to deal with base OS rollbacks, since -applications should only upgrade their configuration accordingly when the new -version is confirmed and there is no possible rollback. +Rollbacks can be misused to perform +[downgrade attacks](https://en.wikipedia.org/wiki/Downgrade_attack) where the +attacker purposefully initiates a rollback to an older version to leverage +vulnerabilities fixed in the currently deployed version. + +For this reason care need to be taken about the conditions on which a rollback +is to be initiated. For instance, if the system is not explicitly in the +process of performing an upgrade, rollback should never be initiated even in +case of boot failure as those are likely due to external reasons and rolling +back to a previous version would not produce any benefit. Relatedly, once +a specific version has been booted successfully, the system should never +roll back to earlier versions. This also simplifies how applications have to +deal with base OS updates: since the version of the successfully booted +deployment can only monotonically increase, user applications that get launched +after the successful system boot has been confirmed will never have to deal +with downgrades. ### Reset to clean state -- GitLab