Bug#1068825: apt: possible super minor security issue in apt-get source
On Thu, Apr 11, 2024 at 05:52:47PM +0200, Christoph Anton Mitterer wrote:
> Package: apt
> Version: 2.7.14
> Severity: normal
> Tags: security
>
>
> Hey.
>
> I noted the following behaviour - which may or may not be regarded as
> security relevant.
> So this is rather a heads up, and in case you think it's fine as it is,
> just close it.
>
> I always remembered that apt-get source was ought to verify hashes of
> the downloaded files (i.e. secure APT as signed by the repo).
>
> Likewise, I thought to remember that at least at one point in time,
> downloads of binary packages (via e.g. apt-get download or aptitude
> download) were NOT verified.
> Because of that I never trusted these which was quite unhandy.
>
> So I though I'd simply test that (using a local package repo and simply
> changing one byte of the files to download), and turns out that apt-get
> download DOES also verify the binary packages and exit with non-zero
> status of the don't match.
> Nice.
>
>
> So just to be sure I did the same with the source package files.
> And here I noted some things:
> - It does check freshly downloaded files and exit with non-zero in case
> their hashes mismatch.
> - But it does so as well, with *already* downloaded files, and if they
> don't match it silently downloads (also verified) fresh files.
> => First, I'm not sure whether this is the right behaviour, as the
> "original/modified" file seems to get removed, but it - being a
> local file - may actually be something of value to the user.
> So maybe it should just move the file to foo.FAILED and error
> with non-zero exit status?
>
>
> Then I made some particular tries:
> a) On a previously (valid) downloaded source package I modified a byte
> in the local .dsc and modified a byte in the remote .orig.tar.xz.
> apt again notcies the valid local .orig.tar.xz and does nothing and
> notices the invalid local .dsc and re-downloads it (which succeeds
> as I haven't mangled the remote .dsc).
>
> In principle I'd say this is fine, and there's no direct security
> issue ... and probably not even an indirect one.
> What does however happen - due to the skipped download of the already
> present+valid files - is that the remote corruption of he .orig.tar.xz
> isn't notice.
>
> I'd say, not an issue, but nevertheless wanted to give a heads up.
>
>
> b) What may now be the “super minor security issue” is the following:
> apt *does* check already downloaded files for validity and exits
> with zero if they match, right?
>
> So conceptuall one could have gone two ways:
> - anything local is already trusted because it was verified before
> or the user somehow manually brought it to the system and should
> know what he's doing
> - `apt-get source` acts also like a checker and if the exit status is
> one can assume that the files present are valid
>
> It seems to be the 2nd, given that it verifies the local files.
>
> It does however NOT again verify any already unpacked tree.
>
> So in some super obscure scenarios, a user could come to assume that
> exit status zero means that all the stuff is verified, while in fact
> only the non unpacked files are.
>
> Again of course, for an attack, there would need to be some way to
> introduce a modified unpacked tree, where one could say that if an
> attacker can do that, it's anyway already too late.
>
> But simply from that conceptual PoV, it seems to me as if that
> behaviour is unfortunate.
>
> I do however have no idea for a better behaviour.
> Checking would anyway mean that we need to unpack it - therefore
> wasting further resources.
> And the tree may differ simply because of user modifications, what
> then? Move the dir to xx.NON-PRISTINE?
I think I'm fine just exiting 1 if the directory already exists,
after doing the download dance.
--
debian developer - deb.li/jak | jak-linux.org - free software dev
ubuntu core developer i speak de, en
Reply to: