Debians commandline package manager https://git.kalnischkies.de/apt/atom?h=1.9.9 2019-11-27T21:00:43Z 2019-11-27T21:00:43Z David Kalnischkies david@kalnischkies.de 2019-11-27T11:10:31Z urn:sha1:1690c3f87ae45a41e8d3e09bf0b1021c008460b9 While passing the combi Release and Release.gpg to the gpgv method for verification the filename of Release is placed where usually Release.gpg is assumed in the rest of the code. The "usual" cases like passing verification and failing verification ending in an error are taking care of this, but the code path dealing with a failed verification, but ignoring said failure (e.g. due to trusted=yes) was not which results in the wrong file being removed later on (in case the index happens to be unmodified since the last update call) leading us into the abyss of strange failures (fixed in the previous commit) were nothing should have changed. This is not a security issue in this form as the repository needs to fail verification & the user forcing apt to ignore the failure and carry on anyhow. It does show however how complicated the code and its various interconnected paths can become. Reported-By: Val "pinkieval" Lorentz on IRC 2019-11-27T20:56:33Z David Kalnischkies david@kalnischkies.de 2019-11-27T18:57:08Z urn:sha1:62bfe5b6ca3ccfba6313d3f9ab4cb75a24a5557a If we have no old Release file, but old indices we can't compare hashsums with the new Release file and hence must request the indices again and have to react to IMS hits if they didn't change. We used to symlink the old index file to the partial directory, but that usually meant that we linked an uncompressed file to a compressed file, which not all uncompressors can deal with transparently resulting in strange failures. We could do without the symlink, but that would require changes in the codepaths dealing with failure as they would rename the file to FAILED. 2019-11-26T11:36:46Z David Kalnischkies david@kalnischkies.de 2019-09-13T10:01:47Z urn:sha1:35012abf30ec1cfc9b5ee29647d4b1e25d98e99f Unused variable, std::algorithms instead of raw for-loops. There should be no observeable difference in behaviour. Reported-By: cppcheck Gbp-Dch: Ignore 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