check Qubes build script for apt-get update network / gpg failure security issues

phabricator-migrator · February 19, 2024, 5:51pm

Information

ID: 170
PHID: PHID-TASK-iw63l5dh22mjdg7tlia5
Author: Patrick
Status at Migration Time: invalid
Priority at Migration Time: Normal

Description

There are various security issues when using apt-get update in scripts:

TODO:

Check if Qubes’ build script for building Debian and/or Whonix templates catch those issues and fix them if necessary.

Comments

nrgaway

2015-02-16 06:01:48 UTC

Patrick

2015-02-16 09:40:10 UTC

nrgaway

2015-02-16 12:35:49 UTC

Patrick

2015-06-02 23:51:31 UTC

nrgaway

2015-06-06 16:32:57 UTC

Patrick

2015-06-29 23:51:14 UTC

! In T170#5334, @nrgaway wrote:
the --force option has also been removed

Good.

The Qubes build script will fail the install of the template if any apt-get errors are returned.

I don’t think this can be worked around at the moment without parsing the output of apt-get.

There are no meaningful exit codes for failure but if verbose mode is turned on you can see what the error was by reviewing the output.

(Just so we don’t talk past each other: Nevermind meaningful exit codes for the build script. Not my point here.)

The issue is, that apt-get does not provide meaningful exit codes for gpg and network failures. “Not meaningful” here means, that apt-get update exits 0, even if it failed. This makes it hard to figure out in scripts if apt-get update actually succeeded loading repository metadata or failed.

The threat model here is using multiple repositories. Such as Debian’s main repository as well as Debian’s security repository. For consistent and secure builds, both have to be enabled. Now, an adversary could make fetching the Debian main repository succeed, but simulate a gpg or network failure for the Debian security repository. Then the build would go on only with the Debian main repository, without the Debian security repository.

In other words… Here is a practical example…

Consider the following sources.list which is fine.
deb http://security.debian.org wheezy/updates main contrib non-free
deb http://ftp.us.debian.org/debian wheezy main contrib non-free
Consider the following sources.list which is fine which contains an intentional typo for demonstration purposes.
deb http://not-security.debian.org wheezy/updates main contrib non-free
deb http://ftp.us.debian.org/debian wheezy main contrib non-free
Now, when you run…
sudo apt-get update ; echo $?
The output shows.
Err http://not-security.debian.org wheezy/updates Release.gpg                                                                                                                      
  Could not resolve 'not-security.debian.org'
Hit http://ftp.us.debian.org wheezy Release.gpg                                                                                                                                    
...
W: Failed to fetch http://not-security.debian.org/dists/wheezy/updates/Release.gpg  Could not resolve 'not-security.debian.org'

W: Some index files failed to download. They have been ignored, or old ones used instead.
0
Security repository was excluded. That’s an attack an adversary can mount or it can happen for other reasons also. The bad thing here is, apt-get exited 0. Therefore hard to detect these situations in scripts. (Bugs are reported upstream - see ticket description - could take a very long time until fixed upstream.)

The way this was solved in Whonix 10 is by using a wrapper. /usr/lib/apt-get-wrapper, that parses apt-get update’s output. Awful hack, but the real fix would require fixing apt-get upstream at Debian. I think the only way to make qubes-builder-debian equally secure would be using that or a similar script/way.

nrgaway

2015-06-30 01:01:37 UTC

I see your point.

I don’t like really like the idea of using a wrapper if we don’t need to since it would need to be installed before qubes packages are installed.

How about using something like this?
apt-get update 2>&1 | gawk 'BEGIN{} /^W:/{ret_code=125;}/^/ ; END{exit ret_code}' ; echo $?

Patrick

2015-10-16 09:52:52 UTC

If we don’t have duplicate sources[1][2][3] while building… And that should be doable… Then this could work.

Few points:

should match for both, W: and E:

match W: and E: case-insensitive, i.e. also for w: and e: (You’ll never know if apt-get changes the output at some point.)

there is no need to always exit 125 just because a W: or E: was found in the output, for many cases apt-get properly exits non-zero in case of W: or E:

applies to ‘apt-get update’ only

ideally, that new apt-get command should be a variable or function, so it does not have to be copied verbatim multiple times (but looks like you have this anyhow)

support for builders to inject options must not be broken (APT_GET_OPTIONS)

enable pipefail, set -o pipefail, otherwise apt-get’s exit code that comes first in the pipe will not be forwarded to gawk

this stuff is fragile, some unit testing for these parsers would be good, but this can be left for future work

Footnotes:

[1] Because then the matching command gets too complex.
[2] Ignoring the duplicate sources issue, because it’s not serious.
[3] https://github.com/Whonix/whonixcheck/blob/12b77823d3df94075f447212bd279e1c578ca65d/usr/lib/apt-get-wrapper#L55-57

Trivia:

Whonix copies the wrapper at build time before installing any packages so the wrapper can be used.
** I don’t like this solution too much.

Patrick

2015-08-06 14:06:08 UTC