Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.9.2 2019-07-08T13:51:17Z 2019-07-08T13:51:17Z David Kalnischkies david@kalnischkies.de 2019-07-08T13:48:59Z urn:sha1:2b734a7ec429825c7007c1093883229e069d36c7 Reported-By: cppcheck 2019-02-26T15:31:20Z Julian Andres Klode julian.klode@canonical.com 2019-02-26T12:51:15Z urn:sha1:0dfacb3d014db4c9f337ce2be1a6997dbdc5bde1 2019-02-01T16:52:03Z Julian Andres Klode julian.klode@canonical.com 2019-02-01T13:43:52Z urn:sha1:c2b9b0489538fed4770515bd8853a960b13a2618 This new field allows a repository to declare that access to packages requires authorization. The current implementation will set the pin to -32768 if no authorization has been provided in the auth.conf(.d) files. This implementation is suboptimal in two aspects: (1) A repository should behave more like NotSource repositories (2) We only have the host name for the repository, we cannot use paths yet. - We can fix those after an ABI break. The code also adds a check to acquire-item.cc to not use the specified repository as a download source, mimicking NotSource. 2019-01-22T11:24:22Z David Kalnischkies david@kalnischkies.de 2018-09-11T23:44:18Z urn:sha1:7bf533967fb385b9625a1ee4dd7c6542a84b489c Telling the acquire system which keys caused the gpgv method to succeed allows us for now just a casual check if the gpgv method really executed catching bugs like CVE-2018-0501, but we will make use of the information for better features in the following commits. 2018-08-20T16:29:16Z David Kalnischkies david@kalnischkies.de 2018-08-18T15:32:04Z urn:sha1:29658a3a74af49e2a24e17bdebb20e1612aac3ec 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 2018-07-06T08:40:28Z Julian Andres Klode julian.klode@canonical.com 2018-07-05T15:45:40Z urn:sha1:420009e46ce7c0d97a2dc5e216ffce48dd7c0846 The random_device fails if not enough entropy is available. We do not need high-quality entropy here, though, so let's switch to a seed based on the current time in nanoseconds, XORed with the PID. 2018-05-28T15:57:25Z David Kalnischkies david@kalnischkies.de 2018-05-28T15:02:17Z urn:sha1:484babb7d00f7550cbaa592b7cb0022d38217fad Commit d7c92411dc1f4c6be098d1425f9c1c075e0c2154 introduced a warning for non-existent files from components not mentioned in Components to hint users at a mispelling or the disappearance of a component. The debian-installer subcomponent isn't actively advertised in the Release file through, so if apt ends up in acquiring a file which doesn't exist for this component (like Translation files) apt would produce a warning: W: Skipping acquire of configured file 'main/debian-installer/i18n/Translation-en' as repository 'http://deb.debian.org/debian buster InRelease' doesn't have the component 'main/debian-installer' (component misspelt in sources.list?) We prevent this in the future by checking if any file exists from this component which results in the warning to be produced still for the intended cases and silence it on the d-i case. This could potentially cause the warning not to be produced in cases it should be if some marginal file remains, but as this message is just a hint and the setup a bit pathological lets ignore it for now. There is also the possibility of having no file present as they would all be 0-length files and being a "hidden" component, but that would be easy to workaround from the repository side and isn't really actively used at the moment in the wild. Closes: #879591 2018-05-11T16:28:34Z David Kalnischkies david@kalnischkies.de 2018-01-25T19:52:31Z urn:sha1:97f0bb4a60f2a3eda093e015767211d5c3c21c32 Downloading from the same mirror we got a Release file from makes sense for non-unique URIs as their content changes between mirror states, but if we ask for an index via by-hash we can be sure that we either get the file we wanted or a 404 for which we can perform a fallback for which allows us to pull indexes from different mirror in parallel. 2018-05-11T16:28:29Z David Kalnischkies david@kalnischkies.de 2018-01-15T11:04:45Z urn:sha1:ed0e9eadeb3003f4f150da3c463b28cfa5e54b6f Individual items shouldn't concern themselves with these alternative locations, we can deal with this more efficiently within the infrastructure created for other alternative URIs now avoiding the need to implement this in each item. 2018-05-11T16:28:19Z David Kalnischkies david@kalnischkies.de 2018-01-13T23:07:20Z urn:sha1:2d6c6c8809c7b4c1a009df48387ba15066fda7e2 If we got a file but it produced a hash error, mismatched size or similar we shouldn't fallback to alternative URIs as they likely result in the same error. If we can we should instead use another mirror. We used to be a lot stricter by stopping all trys for this file if we got a non-404 (or a hash-based) failure, but that is too hard as we really want to try other mirrors (if we have them) in the hope that they have the expected and correct files.