Qubes OS could be honeypot?

adrelanos · July 5, 2024, 1:07pm

Qubes OS could be honeypot?

Could be. But why only ask about Qubes OS?

Debian, Fedora, Qubes, you name it could be honeypot?

Could be. Could either be a honeypot (which assumes that developers are malicious?) or could be compromised by a backdoor.

Is it possible to prove that there is no backdoor in you-name-it? No.

But Open Source helps? Yes, but at the moment that is insufficient.

Threat Model

The primary concern is the potential for widespread compromise through the distribution of malicious binaries. This threat model assumes:

Sophisticated attackers with significant resources (nation-states, well-funded criminal organizations).
The ability to compromise one or more core developers or their systems.
The goal of inserting malicious code into widely-distributed binaries.
The inability of most users to detect such compromises due to reliance on pre-built binaries.

Key Threats

Supply Chain Attacks: Compromising the build and distribution infrastructure to insert malicious code.
Developer Compromise: Exploiting or coercing core developers to introduce backdoors.
Hidden Malicious Code: Inserting malicious code that doesn’t appear in the public source but exists in distributed binaries.
Long-term Persistence: Maintaining access across multiple releases and updates.

Impact

The potential impact of such a compromise could be severe, including:

Mass surveillance of users
Theft of sensitive data
Creation of large-scale botnets
Targeted attacks on high-value users

Generic Issue Applicable to Many Projects

This forum post discusses Qubes, but the issue is not specific to Qubes. It applies to all Linux distributions, all operating systems, and even most complex applications.

80/20 Principle Application

I am describing this situation using the 80/20 principle. The description should be correct for at least 80% of users. It might differ for a small minority of highly technical people.

Questions and Answers

Why Is This About Core Developers?

Because these are the ones creating binaries that thousands of users will use as-is. In theory, if the core developers were malicious or compromised, they could spread backdoored binaries.

Let’s Suppose the Core Developers Are Not Malicious…

Sure, let’s assume the core developers have good morals and do not intend to backdoor the software. However, core developers could be compromised. Being compromised is different from being malicious by bad character.

How Could the Core Developers Get Compromised?

Some examples:

Physical Attacks: An attacker might gain physical access to their computer while they are away (shopping, on holiday, sleeping).
Threat or Blackmail-Based Compromise.
Software Attacks: An advanced adversary might find or purchase zero-day exploits and use them against the core developers.
Hardware Backdoors.

How Likely Is It for Core Developers to Get Compromised?

Unknown, and not important for the sake of this argument.

Why Would an Attacker Want to Compromise Core Developers?

There is significant monetary value in compromising an entire operating system. This is more valuable than compromising individuals, which happens frequently (primarily on the Windows operating system).

Is There Any Specific Reason to Distrust the Core Developers?

No. In the context of this argument, trusting the core developers versus not trusting them does not make a difference.

But Qubes Is Open Source, So It Doesn’t Matter If Core Developers Get Compromised?

Unfortunately, this is wrong for a few reasons:

There hasn’t been a complete source code audit yet. Also, “audit” can mean many things. It is not a one-time, definitive check. Every audit has a scope, is performed by fallible humans, and is very difficult, making it easy to overlook things.
Even if an audit has been completed, there is a constant stream of source code changes. These would need to be continuously audited as well.
Most people use binaries rather than source code. In theory, reproducible builds and rebuilders would ensure that binaries match the source code used to create them. However, this has been a development goal for many years and could take multiple more years or even decades to fully implement due to the technical complexity and the small number of contributors. Until then, this argument remains applicable.

No progress in Make the whole qubes-builder deterministic · Issue #816 · QubesOS/qubes-issues · GitHub since 2020.

Reproducible Builds?

Reproducible builds are a set of software development practices that create an independently-verifiable path from source code to binary code, ensuring that a given source always results in the same binary. This approach addresses many of the trust issues raised earlier by allowing independent verification of binaries without requiring users to build from source themselves. The full implementation across all open source projects remains an ongoing challenge.

Hidden Source Code

There is no easy way to verify that a specific source code was really used to create a provided binary until reproducible builds are implemented and people actually check (rebuilders). Until then, core developers could upload one version of source code to the repository but use different, backdoored source code to create the actual binaries.

But I trust core developers won’t do that? Ok, it’s easy to grant that core developers are not malicious. However, as mentioned above, core developers might be compromised. Compromised core developers might not even notice that hidden, backdoored source code is being injected without their knowledge during the build process of binaries.

How to Be Safe from Hidden Source Code-Based Backdoors?

Build images from source code and install upgrades from source code only as well.

What “building from source code” means in the context of building Linux distributions from source code is not well defined.

Who Always Builds from Source Code?

I am unaware of anyone who has publicly confirmed to always build images and upgraded packages from source code.

How Difficult Is It to Always Build from Source Code?

Extremely difficult. Building images requires Qubes builder. Users are failing to create images. The reported issues remain open and unfixed for months. Unfortunately, fixing such issues seems not a priority for the Qubes core developers.

As currently implemented, building Qubes images using Qubes builder does not help much either.

How Much Is Accomplished by Building Qubes Images Using Qubes Builder?

It’s nice to do that, but not much is accomplished. Even if using Qubes builder, you’ll most likely still be using binaries that you have not built yourself. Evidence?

Just search Qubes source code for deb.qubes-os.org. For example, see: QubesOS/qubes-builder-debian/blob/main/template_debian/distribution.sh

deb [arch=amd64] https://deb.qubes-os.org/r${USE_QUBES_REPO_VERSION}/vm ${DIST_CODENAME} main

What does that mean? That Qubes binary repository is being used during the Qubes image build process. Therefore, not touching any binaries created by Qubes is already extremely difficult.

Why Not Use Any Binaries from Qubes?

Good question. To avoid backdoors until reproducible builds protect from compromised core developers. It would be nice if that was possible, but…

How to Avoid Using Any Binaries from Debian and Fedora?

This would be even harder to accomplish. And why trust Debian, Fedora but not Qubes? For attack surface reduction, it would be nice to avoid any binaries created by Qubes, but it would still be very incomplete.

How Likely Is It to See a “Source Code Only, Strictly No Binaries” Build Process?

Highly unlikely, but I would be more than happy to be proven wrong.

How to Upgrade Packages from Source Code?

I don’t think this is really being discussed, documented, or supported.

Why Isn’t Always Using the Source Code for Images and Upgrades and Avoiding Binaries Better Supported?

Possible reasons:

Longer build times.
Low demand. Users want stuff to work out of the box, without issues, and with simplicity.
Not a project priority.
Highly difficult to develop Linux build scripts with numerous different use cases.
Developers might think efforts are better spent towards reproducible builds than on a minority of technical users building everything from source code.

But Open Source?

If >=80% of users lack the technical capabilities to make actual use of the source code and avoid all binaries, then this argument is somewhat moot.

Are highly complex, expensive, years long backdoor attacks against Open Source happening?

Yes, see the recent xz backdoor.

Should I Use Something Else?

No. This is not my argument. Maybe a source-based distribution, but the ones I looked at have other issues. (Security-Focused Operating System Comparison as Base for Whonix)

Open Source is certainly better to avoid backdoors. It is still much harder to spot backdoors in closed source software than in Open Source software. No need for fatalism, no need to go back to Windows.

The Right Questions?

How to build and use Qubes from source code while never using Qubes repository / any Qubes binaries?
How to build and use Debian from source code while never using Debian repository / any Debian binaries?

How to improve this situation?

Contribute to reproducible builds.
Contribute to build from source code without touching binaries / binary repository.