https://lists.debian.org/debian-security-announce/2019/msg00010.html
@Patrick can you please tell me how to force builds to use onion only?
https://www.whonix.org/wiki/Operating_System_Software_and_Updates#apt_security_update_-_DSA_4371-1
Using onion sources may or may not protect from this vulnerability.
Debian’s security announcement does not mention Debian onion sources. Redirects might also be used by onion mirrors. Debian has to the knowledge of Whonix not released information where Debian onion sources are hosted. Onion sources are also just a mirror. And mirrors may also be in a position to attempt a man-in-the-middle attack.
Building Whonix is currently not safe. Will elaborate soon.
Whonix build NOT safe at the moment.
Build happens in chroot but these aren’t safe against breakout. So building now could compromise a build machine.
Applies to Non-Qubes-Whonix only.
Qubes(-Whonix) build attempts to fix this.
Technical background:
Misery of Debian package repositories:
- Debian package repository: contains vulnerable apt version.
- security.debian.org Debian security fixes package repository: contains fixed apt version.
debootstrap is a popular Debian tool.
- Also used by Whonix since Whonix uses grml-debootstrap which internally uses debootstrap to create base Debian images.
- Also used by Whonix since Whonix uses cowbuilder to create packages which internally uses debootstrap.
debootstrap limitations:
- It can only use the Debian package repository.
- It can not use security.debian.org Debian security fixes package repository because that only contains packages that have security fixes but not all packages. So that repository cannot be used
- debootstrap cannot use multiple repositories at once like apt-get can. It can only use one
--mirror.
Build process usually:
Build Debian base image from Debian package repository and then upgrade from Debian package repository and Debian security repository.
Problem:
Exactly this upgrade is insecure.
Solution:
- a) securely update apt after debootstrap inside base image and inside cowbuilder image, OR
- b) multistrap
- make grml-debootstrap use multistrap with multiple repositories and,
- create cowbuilder image with multistrap with multiple repositories
Not exactly easy. So don’t hold your breath.
FWIW I updated the build machine with apt redirects disabled as per their workaround and checked the final image to contain the pacthed 1.4.9
Is this enough?
Debian made a new point release of Stretch which contains the Apt package fix already included. Might help your problem here (e.g build off of the new 9.7 images when they are released).
I wish I read this more carefully before wasting hours building. So pbuilder apt does not depend on the version installed on the base environment, but pulls and uses the vulnerable one from the outdated distro snapshot…
This is one nasty bug.
Let me know when it’s safe to build as mig5’s advice seems good.
No. Otherwise I wouldn’t create above post and make a big deal of it.
This is how it works:
Whonix build script runs commands to run cowbuilder to create cowbuilder image (used for clean package builds) -> cowbuilder runs debootstrap -> deboostrap installs from packages.debian.org only due to limitations explained above -> packages.debian.org contains vulnerable APT -> Whonix build script runs the vulnerable apt-get from inside cowbuilder image -> at this point the image and build machine could get compromises.
Whonix build script runs commands to run grml-debootstrap to create Debian base image (to be updated and Whonix packages installed afterwards) -> grml-debootstrap runs debootstrap -> deboostrap installs from packages.debian.org only due to limitations explained above -> packages.debian.org contains vulnerable APT -> Whonix build script runs the vulnerable apt-get from inside Debian base image -> at this point the image and build machine could get compromises.
Can’t create cowbuilder / debian base image from Debian iso.
- installation method: not sane, not clean […]
- conversion: difficult
But above might help make the package migrate from Debian security repository to non-security packages.debian.org.
Might have been in vain. mmdebstrap might be able to bootstrap from multiple repositories but may not figuring out using newer packages from security.debian.org. Still investigating.
Either way. mmdebstrap has some advantages.
- faster
- Quote man page
-
Reproducible output by default if $SOURCE_DATE_EPOCH is set
-
- written in perl rather than bash (debootstrap)
https://manpages.debian.org/testing/mmdebstrap/mmdebstrap.1.en.html
https://bugs.debian.org/cgi-bin/pkgreport.cgi?pkg=multistrap;dist=unstable
1 Like
I might fortunately be wrong about this. The cowbuilder / pbuilder / mmdebstrap interaction is hard to grasp and enforce always using Debian security repository. Fixed.
But since security fixed apt is now also available in “packages.debian.org” (not just only Debian security repository), it’s hard to really test.
1 Like
Try and mimic the situation using two versions of Whonix repos?
1 Like
Install mmdebstrap from Debian buster now required on build machine. https://www.whonix.org/wiki/Dev/Build_Documentation/14_full updated.
Certainly still unfit for release.
Build config /etc/apt/apt.conf.d/99mmdebstrap breaks apt-get connectivity. Need to be deleted in final build. Easy to fix, will fix soon.
/etc/network/interfaces is empty. Therefore no network interfaces configured. Will fix soon.
Made a minor whonixcheck bug apparent, and fixed:
sudo: pam_open_session: Module is unknown
sudo: policy plugin failed session initialization
That should be partially fixed. Was an apparmor issue.
The full fix may depend on below.
Most critical bug that I hope upstream will react to soon.
coreutils such as /bin/mkdir are duplicated in /usr/bin/mkdir
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=921163
Can anyone make head or tail from the mmdebstrap source code why this is happening?
https://gitlab.mister-muffin.de/josch/mmdebstrap/blob/master/mmdebstrap
1 Like
Yay! you found it.
Maybe:
## setup merged usr
#my @amd64_dirs = ('lib32', 'lib64', 'libx32'); # only amd64 for now
#foreach my $dir ("bin", "sbin", "lib", @amd64_dirs) {
# symlink "usr/$dir", "$options->{root}/$dir" or die "cannot create symlink: $!";
# make_path("$options->{root}/usr/$dir") or die "cannot create /usr/$dir: $!";
#}
1 Like
git tag:
14.0.1.3.8-testers-only