Prior security vulnerability: initial package pinning against insecure source #7

New Issue

Closed

opened 2024-09-25 12:33:10 +00:00 by invd · 1 comment

invd commented

2024-09-25 12:33:10 +00:00

While working for Turnkey, I've discovered a suspected vulnerability in previous versions of toolchain.

The issue was present in revisions before 5bbf26be78. I therefore consider it already patched and resolved, but wanted to document it here to flag potential persisting risks.

In the toolchain logic, the packages-update script is responsible for fetching the initial apt .deb artifacts that the user wants to trust and hash-lock.

The expected behavior here is that a currently fresh set of package files for the desired packages are downloaded with common apt security levels, meaning checks that the packages have valid signatures by trusted apt source maintainers. This implies valid signatures by said maintainers on problematic packages are needed to perform a supply chain attack.

However, the actual code behavior was to fetch packages from [trusted=yes] sources over http://:
3f14cf21ba/scripts/packages-update (L6-L12)

This allows a Machine-in-the-Middle (MitM) attacker to impersonate the download server and deliver arbitrarily modified, unsigned variants of the requested packages. While the toolchain logic would not install or run them during this step, this results in tainted hash-locks.
On secondary systems that use the hash references generated by such an attack, the same MitM attacker could then leverage a repeated attack with the same malicious files to compromise the victim machines.
The attack would be discovered as a hash mismatch when running the tainted hash list against an apt source that serves the genuine files.

@lrvick approved public documentation of this issue.

While working for [Turnkey](https://www.turnkey.com/), I've discovered a suspected vulnerability in previous versions of `toolchain`. The issue was present in revisions before 5bbf26be78a05fe504c5aeb989d16bfa44383253. I therefore consider it already patched and resolved, but wanted to document it here to flag potential persisting risks. In the `toolchain` logic, the `packages-update` script is responsible for fetching the initial apt `.deb` artifacts that the user wants to trust and hash-lock. The expected behavior here is that a currently fresh set of package files for the desired packages are downloaded with common apt security levels, meaning checks that the packages have valid signatures by trusted apt source maintainers. This implies valid signatures by said maintainers on problematic packages are needed to perform a supply chain attack. However, the actual code behavior was to fetch packages from `[trusted=yes]` sources over `http://`: https://git.distrust.co/public/toolchain/src/commit/3f14cf21ba43f955d90b988d9845b772c978c2f4/scripts/packages-update#L6-L12 This allows a Machine-in-the-Middle (MitM) attacker to impersonate the download server and deliver arbitrarily modified, unsigned variants of the requested packages. While the `toolchain` logic would not install or run them during this step, this results in tainted hash-locks. On secondary systems that use the hash references generated by such an attack, the same MitM attacker could then leverage a repeated attack with the same malicious files to compromise the victim machines. The attack would be discovered as a hash mismatch when running the tainted hash list against an apt source that serves the genuine files. @lrvick approved public documentation of this issue.

invd commented

2024-09-25 12:34:40 +00:00

Author

Marking as resolved since the issue is patched.

Newer versions of package-update still use http:// downloads, but no longer mark them as [trusted=yes], which leaves common apt security mechanisms active:

a2315fdbc8/scripts/packages-update (L6-L10)

As an additional hardening step, moving to https:// downloads could be worthwhile.

Marking as resolved since the issue is patched. Newer versions of `package-update` still use `http://` downloads, but no longer mark them as `[trusted=yes]`, which leaves common apt security mechanisms active: https://git.distrust.co/public/toolchain/src/commit/a2315fdbc8cd0e4a654d1aa4623a53d5292b3574/scripts/packages-update#L6-L10 As an additional hardening step, moving to `https://` downloads could be worthwhile.

invd closed this issue

2024-09-25 12:34:40 +00:00

No Label

No Milestone

No project

No Assignees

1 Participants

Notifications

Due Date

The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: public/toolchain#7

No description provided.