|
|
@@ -5,6 +5,83 @@ Important notes
|
|
|
|
|
|
This section provides information about security and corruption issues.
|
|
|
|
|
|
+.. _archives_tam_vuln:
|
|
|
+
|
|
|
+Pre-1.2.5 archives spoofing vulnerability (CVE-2023-36811)
|
|
|
+----------------------------------------------------------
|
|
|
+Note: the security fix released with borg 1.2.5/1.2.6 was backported to
|
|
|
+1.1-maint branch. Below is a copy of the related upgrade notes from 1.2.6,
|
|
|
+they also apply here:
|
|
|
+
|
|
|
+A flaw in the cryptographic authentication scheme in Borg allowed an attacker to
|
|
|
+fake archives and potentially indirectly cause backup data loss in the repository.
|
|
|
+
|
|
|
+The attack requires an attacker to be able to
|
|
|
+
|
|
|
+1. insert files (with no additional headers) into backups
|
|
|
+2. gain write access to the repository
|
|
|
+
|
|
|
+This vulnerability does not disclose plaintext to the attacker, nor does it
|
|
|
+affect the authenticity of existing archives.
|
|
|
+
|
|
|
+Creating plausible fake archives may be feasible for empty or small archives,
|
|
|
+but is unlikely for large archives.
|
|
|
+
|
|
|
+The fix enforces checking the TAM authentication tag of archives at critical
|
|
|
+places. Borg now considers archives without TAM as garbage or an attack.
|
|
|
+
|
|
|
+We are not aware of others having discovered, disclosed or exploited this vulnerability.
|
|
|
+
|
|
|
+Below, if we speak of borg 1.2.6, we mean a borg version >= 1.2.6 **or** a
|
|
|
+borg version that has the relevant security patches for this vulnerability applied
|
|
|
+(could be also an older version in that case).
|
|
|
+
|
|
|
+Steps you must take to upgrade a repository:
|
|
|
+
|
|
|
+1. Upgrade all clients using this repository to borg 1.2.6.
|
|
|
+ Note: it is not required to upgrade a server, except if the server-side borg
|
|
|
+ is also used as a client (and not just for "borg serve").
|
|
|
+
|
|
|
+ Do **not** run ``borg check`` with borg > 1.2.4 before completing the upgrade steps.
|
|
|
+
|
|
|
+2. Run ``BORG_WORKAROUNDS=ignore_invalid_archive_tam borg info --debug <repo> 2>&1 | grep TAM | grep -i manifest``.
|
|
|
+
|
|
|
+ a) If you get "TAM-verified manifest", continue with 3.
|
|
|
+ b) If you get "Manifest TAM not found and not required", run
|
|
|
+ ``borg upgrade --tam --force <repository>`` *on every client*.
|
|
|
+
|
|
|
+3. Run ``BORG_WORKAROUNDS=ignore_invalid_archive_tam borg list --format='{name} {time} tam:{tam}{NL}' <repo>``.
|
|
|
+ "tam:verified" means that the archive has a valid TAM authentication.
|
|
|
+ "tam:none" is expected as output for archives created by borg <1.0.9.
|
|
|
+ "tam:none" is also expected for archives resulting from a borg rename
|
|
|
+ or borg recreate operation (see #7791).
|
|
|
+ "tam:none" could also come from archives created by an attacker.
|
|
|
+ You should verify that "tam:none" archives are authentic and not malicious
|
|
|
+ (== have good content, have correct timestamp, can be extracted successfully).
|
|
|
+ In case you find crappy/malicious archives, you must delete them before proceeding.
|
|
|
+ In low-risk, trusted environments, you may decide on your own risk to skip step 3
|
|
|
+ and just trust in everything being OK.
|
|
|
+
|
|
|
+4. If there are no tam:none archives left at this point, you can skip this step.
|
|
|
+ Run ``BORG_WORKAROUNDS=ignore_invalid_archive_tam borg upgrade --archives-tam <repo>``.
|
|
|
+ This will unconditionally add a correct archive TAM to all archives not having one.
|
|
|
+ ``borg check`` would consider TAM-less or invalid-TAM archives as garbage or a potential attack.
|
|
|
+ To see that all archives now are "tam:verified" run: ``borg list --format='{name} {time} tam:{tam}{NL}' <repo>``
|
|
|
+
|
|
|
+5. Please note that you should never use BORG_WORKAROUNDS=ignore_invalid_archive_tam
|
|
|
+ for normal production operations - it is only needed once to get the archives in a
|
|
|
+ repository into a good state. All archives have a valid TAM now.
|
|
|
+
|
|
|
+Vulnerability time line:
|
|
|
+
|
|
|
+* 2023-06-13: Vulnerability discovered during code review by Thomas Waldmann
|
|
|
+* 2023-06-13...: Work on fixing the issue, upgrade procedure, docs.
|
|
|
+* 2023-06-30: CVE was assigned via Github CNA
|
|
|
+* 2023-06-30 .. 2023-08-29: Fixed issue, code review, docs, testing.
|
|
|
+* 2023-08-30: Released fixed version 1.2.5 (broken upgrade procedure for some repos)
|
|
|
+* 2023-08-31: Released fixed version 1.2.6 (fixes upgrade procedure)
|
|
|
+* 2023-09-08: Backported fixes / docs to 1.1-maint branch.
|
|
|
+
|
|
|
.. _hashindex_set_bug:
|
|
|
|
|
|
Pre-1.1.11 potential index corruption / data loss issue
|
Thomas Waldmann