LPE via tails-upgrade-frontend

See https://git.radicallyopensecurity.com/otf/pen-tails/-/issues/1

User impact

An adversary who can already execute arbitrary code as the amnesia user can leverage this vulnerability to install a malicious IUK, with which they can persistently modify how Tails works from the next boot on, e.g. run arbitrary code as root next time the user starts this Tails, and retain this capability until the malicious IUK is removed (which would happen next time the user does an automatic upgrade, except the adversary can disable that; so in practice this really means: until the user re-installs or does a manual upgrade).

Practical exploitation paths

We believe this vulnerability cannot be leveraged solely from the context of an exploited Tor Browser that gives the adversary the capability to run arbitrary code as the amnesia user in a restricted environment. We believe it's the same for the other most sensitive apps, thanks to their restrictive AppArmor confinement rules.

However, we believe this vulnerability can probably be leveraged via an exploited Thunderbird. Thankfully most Thunderbird vulnerabilities that might lead to successful exploitation don't affect Tails in its default configuration. But the user can become at least partly vulnerable if they enable display of HTML email.

From ROS

mkdir -p Sub/HandlesVia/
cp /usr/share/perl5/Sub/HandlesVia/Toolkit.pm Sub/HandlesVia/ 

Edit the Toolkit.pm and add 
nano Sub/HandlesVia/Toolkit.pm
 -> system("/bin/sh");

# Trigger LPE
sudo -u tails-upgrade-frontend /usr/local/bin/tails-upgrade-frontend

To Do

• Fix tails-iuk's test suite to have a healthy baseline to test against !1862 (merged)
• Verify that this can't be exploited from Tor Browser
• Fix the problem in tails-upgrade-frontend
• Look for other impacted code in Tails; if any is found, add action items to fix them
• Report the problem privately to the maintainer of the code that introduces the vuln (https://metacpan.org/dist/Sub-HandlesVia)
• Ensure we don't ship copies of the vulnerable code in the future (tails/tails-private!4)
• Locate impacted code in Debian and report to Debian security team

Affected code

The problem exists only for programs that use Sub-HandlesVia and are run with privileges higher than the user who is allowed to run them.

As of Tais 6.10, Sub-HandlesVia is only used via MooX::late, which itself is used only by:

• GnuPG::Interface, used by:
  • Tails::IUK::Utils loads this package which makes any code that loads Tails::IUK::Utils affected in turn. We load it all over the place. So either we move verify_signature to a different package that only protected code loads (cheap, but we risk loading it from unprotected code in the future), or we add the chdir '/' mitigation in many places and never forget to use it in newly written code (not cheap, risky), or we solve the root cause of the problem or we get rid of GnuPG::Interface (#17825 (closed), very tempting because then we can ensure we don't even ship MooX::late and the vuln cannot possibly be re-introduced anymore)
  • our verify_signature method (until #17825 (closed)), used by:
    • RMs and developers in trusted environments
    • tails-iuk-get-upgrade-description-file run by the frontend so does not need its own protection if we chdir '/' in the frontend
• Tails::IUK::Role::FormatByte → removed useless usage of MooX::late
• Tails::Constants → ported away from MooX::late
• Tails::Role::DisplayError::Gtk3 → removed useless usage of MooX::late
• Tails::Role::HasDBus::System → ported away from MooX::late
• Tails::Role::HasEncoding→ ported away from MooX::late
• Tails::RunningSystem → ported away from MooX::late
• Tails::UDisks → ported away from MooX::late

Upstream

• CVE-2025-30672 - for Mite (root cause), fixed in https://metacpan.org/release/TOBYINK/Mite-0.013000/changes
• CVE-2025-30673 - for Sub-HandlesVia, fixed in https://metacpan.org/release/TOBYINK/Sub-HandlesVia-0.050002/changes