You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

test-cve-2018-0501-mirror-alternatives 1.1 KiB

clear alternative URIs for mirror:// between steps (CVE-2018-0501) APT in 1.6 saw me rewriting the mirror:// transport method, which works comparable to the decommissioned httpredir.d.o "just" that apt requests a mirror list and performs all the redirections internally with all the bells like parallel download and automatic fallback (more details in the apt-transport-mirror manpage included in the 1.6 release). The automatic fallback is the problem here: The intend is that if a file fails to be downloaded (e.g. because the mirror is offline, broken, out-of-sync, …) instead of erroring out the next mirror in the list is contacted for a retry of the download. Internally the acquire process of an InRelease file (works with the Release/Release.gpg pair, too) happens in steps: 1) download file and 2) verify file, both handled as URL requests passed around. Due to an oversight the fallbacks for the first step are still active for the second step, so that the successful download from another mirror stands in for the failed verification… *facepalm* Note that the attacker can not judge by the request arriving for the InRelease file if the user is using the mirror method or not. If entire traffic is observed Eve might be able to observe the request for a mirror list, but that might or might not be telling if following requests for InRelease files will be based on that list or for another sources.list entry not using mirror (Users have also the option to have the mirror list locally (via e.g. mirror+file://) instead of on a remote host). If the user isn't using mirror:// for this InRelease file apt will fail very visibly as intended. (The mirror list needs to include at least two mirrors and to work reliably the attacker needs to be able to MITM all mirrors in the list. For remotely accessed mirror lists this is no limitation as the attacker is in full control of the file in that case) Fixed by clearing the alternatives after a step completes (and moving a pimpl class further to the top to make that valid compilable code). mirror:// is at the moment the only method using this code infrastructure (for all others this set is already empty) and the only method-independent user so far is the download of deb files, but those are downloaded and verified in a single step; so there shouldn't be much opportunity for regression here even through a central code area is changed. Upgrade instructions: Given all apt-based frontends are affected, even additional restrictions like signed-by are bypassed and the attack in progress is hardly visible in the progress reporting of an update operation (the InRelease file is marked "Ign", but no fallback to "Release/Release.gpg" is happening) and leaves no trace (expect files downloaded from the attackers repository of course) the best course of action might be to change the sources.list to not use the mirror family of transports ({tor+,…}mirror{,+{http{,s},file,…}}) until a fixed version of the src:apt packages are installed. Regression-Of: 355e1aceac1dd05c4c7daf3420b09bd860fd169d, 57fa854e4cdb060e87ca265abd5a83364f9fa681 LP: #1787752
2 years ago
  1. #!/bin/sh
  2. set -e
  3. TESTDIR="$(readlink -f "$(dirname "$0")")"
  4. . "$TESTDIR/framework"
  5. setupenvironment
  6. configarchitecture "i386"
  7. buildsimplenativepackage 'foo' 'all' '1' 'stable'
  8. setupaptarchive --no-update
  9. changetohttpswebserver
  10. # User has mirror method configured in apt >= 1.6~alpha6 &
  11. # Eve has enough MITM control over the network to
  12. # a) have the mirror file include at least two mirrors and
  13. # b) can send her bad InRelease files for both mirrors
  14. sed -i -e 's# https:# mirror+https:#' -e 's#/ stable#/mirror.txt stable#' rootdir/etc/apt/sources.list.d/*-stable-*
  15. echo "http://localhost:${APTHTTPPORT}
  16. https://localhost:${APTHTTPSPORT}" > aptarchive/mirror.txt
  17. # real Eve would do something worse…
  18. sed -i "/^Date: / a\
  19. Evil: yes" $(find ./aptarchive -name 'Release' -o -name 'InRelease')
  20. # progress display shows that the InRelease file was bad,
  21. # but it is used anyhow as the bad file causes a fallback to
  22. # a request to the second mirror which completes successful
  23. # causing apt to believe the verify completed successfully…
  24. testfailure apt update
  25. testfailure grep '^Evil:' rootdir/var/lib/apt/lists/*Release
  26. testfailure apt show foo