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?
HTH,
Chris.
