Pre-1.2.5 archives spoofing vulnerability (CVE-2023-36811)

Bug #2037511 reported by Julian Andres Klode
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
borgbackup (Ubuntu)
New
Undecided
Unassigned

Bug Description

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

    insert files (with no additional headers) into backups
    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.5, we mean a borg version >= 1.2.5 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:

    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.

    Run BORG_WORKAROUNDS=ignore_invalid_archive_tam borg info --debug <repo> 2>&1 | grep TAM | grep -i manifest.
        If you get “TAM-verified manifest”, continue with 3.
        If you get “Manifest TAM not found and not required”, run borg upgrade --tam --force <repository> on every client.

    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.

    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>

    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)

CVE References

Revision history for this message
Julian Andres Klode (juliank) wrote :

Aside from security issue, this means that if you run borg recreate/rename in lunar or older, the archives are rejected as invalid by the one in mantic.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.