apt: CVE-2014-0478: no authentication checks for source packages

Debian Bug report logs - #749795
apt: CVE-2014-0478: no authentication checks for source packages

Toggle useless messages

---

Message #3 received at submit@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

Package: apt
Version: 1.0.3
Severity: grave
Tags: security

I've been investigating how apt behaves when the repository doesn't 
contain any Release signatures (possibly because they were stripped off 
by a man-in-the-middle attacker).

This is what I found out:

| # cat /etc/apt/sources.list
| deb http://ftp.debian.org/debian/ unstable main
| deb-src http://ftp.debian.org/debian/ unstable main
|
| # apt-get update
| Ign http://ftp.debian.org unstable InRelease
| Ign http://ftp.debian.org unstable Release.gpg
| Get:1 http://ftp.debian.org unstable Release [205 kB]
| Get:2 http://ftp.debian.org unstable/main Sources [7249 kB]
| Get:3 http://ftp.debian.org unstable/main amd64 Packages [6758 kB]
| Fetched 14.2 MB in 29s (479 kB/s)
| Reading package lists... Done
|
| # echo $?
| 0

Hmm. There is no warning suggesting that anything fishy is going on, and 
the exit code indicates success. (Perhaps the "Ign"s could raise 
suspicion of an observant sysadmin. But who knows what "Ign" exactly 
means? At least the apt-get(1) manpage doesn't know.)

Fortunately, apt-get won't let you install anything:

| # apt-get install -qq nyancat
| WARNING: The following packages cannot be authenticated!
|   nyancat
| E: There are problems and -y was used without --force-yes

And it won't let you even download binary packages:

| $ apt-get download nyancat
| WARNING: The following packages cannot be authenticated!
|   nyancat
| E: Some packages could not be authenticated

So far, so good. However, apt-get happily downloads unauthenticated 
source packages, with no warning:

| $ apt-get source -d nyancat
| Reading package lists... Done
| Building dependency tree
| Reading state information... Done
| Selected version '1.2.2-1' (unstable) for nyancat
| Need to get 20.6 kB of source archives.
| Get:1 http://ftp.debian.org/debian/ unstable/main nyancat 1.2.2-1 (dsc) [1782 B]
| Get:2 http://ftp.debian.org/debian/ unstable/main nyancat 1.2.2-1 (tar) [14.1 kB]
| Get:3 http://ftp.debian.org/debian/ unstable/main nyancat 1.2.2-1 (diff) [4748 B]
| Fetched 20.6 kB in 0s (1838 kB/s)
| Download complete and in download only mode
|
| $ echo $?
| 0

It is equally happy to unpack them:

| $ apt-get source nyancat
| Reading package lists... Done
| Building dependency tree
| Reading state information... Done
| Selected version '1.2.2-1' (unstable) for nyancat
| Need to get 20.6 kB of source archives.
| Get:1 http://ftp.debian.org/debian/ unstable/main nyancat 1.2.2-1 (dsc) [1782 B]
| Get:2 http://ftp.debian.org/debian/ unstable/main nyancat 1.2.2-1 (tar) [14.1 kB]
| Get:3 http://ftp.debian.org/debian/ unstable/main nyancat 1.2.2-1 (diff) [4748 B]
| Fetched 20.6 kB in 0s (1637 kB/s)
| gpgv: keyblock resource `/home/jwilk/.gnupg/trustedkeys.gpg': file open error
| gpgv: Signature made Fri Dec 13 23:42:11 2013 CET using RSA key ID 37AD3296
| gpgv: Can't check signature: public key not found
| dpkg-source: warning: failed to verify signature on ./nyancat_1.2.2-1.dsc
| dpkg-source: info: extracting nyancat in nyancat-1.2.2
| dpkg-source: info: unpacking nyancat_1.2.2.orig.tar.gz
| dpkg-source: info: unpacking nyancat_1.2.2-1.debian.tar.gz
| dpkg-source: info: applying 01-nyancat-debhelper.patch
|
| $ echo $?
| 0

And it will even let you build them:

| $ apt-get source -b nyancat
| Reading package lists... Done
| Building dependency tree
| Reading state information... Done
| Selected version '1.2.2-1' (unstable) for nyancat
| Need to get 20.6 kB of source archives.
| Get:1 http://ftp.debian.org/debian/ unstable/main nyancat 1.2.2-1 (dsc) [1782 B]
| Get:2 http://ftp.debian.org/debian/ unstable/main nyancat 1.2.2-1 (tar) [14.1 kB]
| Get:3 http://ftp.debian.org/debian/ unstable/main nyancat 1.2.2-1 (diff) [4748 B]
| Fetched 20.6 kB in 0s (1757 kB/s)
| gpgv: keyblock resource `/home/jwilk/.gnupg/trustedkeys.gpg': file open error
| gpgv: Signature made Fri Dec 13 23:42:11 2013 CET using RSA key ID 37AD3296
| gpgv: Can't check signature: public key not found
| dpkg-source: warning: failed to verify signature on ./nyancat_1.2.2-1.dsc
| dpkg-source: info: extracting nyancat in nyancat-1.2.2
| dpkg-source: info: unpacking nyancat_1.2.2.orig.tar.gz
| dpkg-source: info: unpacking nyancat_1.2.2-1.debian.tar.gz
| dpkg-source: info: applying 01-nyancat-debhelper.patch
| dpkg-buildpackage: source package nyancat
| dpkg-buildpackage: source version 1.2.2-1
| dpkg-buildpackage: source distribution unstable
| dpkg-buildpackage: source changed by Jonathan McCrohan <jmccrohan@gmail.com>
| dpkg-buildpackage: host architecture amd64
|  dpkg-source --before-build nyancat-1.2.2
|  fakeroot debian/rules clean
[...]

The mitmproxy script I used for testing is attached.

-- System Information:
Debian Release: jessie/sid
 APT prefers unstable
 APT policy: (990, 'unstable')
Architecture: amd64 (x86_64)

Kernel: Linux 3.14-1-amd64 (SMP w/1 CPU core)
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)
Shell: /bin/sh linked to /bin/dash

Versions of packages apt depends on:
ii  debian-archive-keyring  2012.4
ii  gnupg                   1.4.16-1.1
ii  libapt-pkg4.12          1.0.3
ii  libc6                   2.18-7
ii  libgcc1                 1:4.9.0-5
ii  libstdc++6              4.9.0-5

-- 
Jakub Wilk

[nosigs.py (text/x-python, attachment)]

---

Message #8 received at 749795@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Thu, May 29, 2014 at 11:04:35PM +0200, Jakub Wilk wrote:
> Package: apt
> Version: 1.0.3
> Severity: grave
> Tags: security

(personally, this feels a bit high. Mostly as deb-src isn't even part of
 many default configurations in which apt is found. And in those where
 you find it, you probably find also vcs checkouts and "wget | sh" …
 Anyway tl;dr: I wouldn't like to release jessie with it, so I leave it at
 that and we should ask the relevant security teams what they want, but
 I am too dreamy now to figure out a patch/all the mail addresses…)


> I've been investigating how apt behaves when the repository doesn't contain
> any Release signatures (possibly because they were stripped off by a
> man-in-the-middle attacker).

Thanks! Not many do, so such things usually never get reported…
The pain of being even less sexy than OpenSSL…

(may I ask to push security bugs through the security teams first
 though, so that they can coordinate properly as 'apt' and 'security'
 tends to make people super nervous as recovery tends to be painful)


> This is what I found out:
> 
> | # cat /etc/apt/sources.list
> | deb http://ftp.debian.org/debian/ unstable main
> | deb-src http://ftp.debian.org/debian/ unstable main
> |
> | # apt-get update
> | Ign http://ftp.debian.org unstable InRelease
> | Ign http://ftp.debian.org unstable Release.gpg
> | Get:1 http://ftp.debian.org unstable Release [205 kB]
> | Get:2 http://ftp.debian.org unstable/main Sources [7249 kB]
> | Get:3 http://ftp.debian.org unstable/main amd64 Packages [6758 kB]
> | Fetched 14.2 MB in 29s (479 kB/s)
> | Reading package lists... Done
> |
> | # echo $?
> | 0
> 
> Hmm. There is no warning suggesting that anything fishy is going on, and the
> exit code indicates success. (Perhaps the "Ign"s could raise suspicion of an
> observant sysadmin. But who knows what "Ign" exactly means? At least the
> apt-get(1) manpage doesn't know.)

Well, "Ign" isn't "Get" - and it stands for "Ignore", but that is surely
not your point here.

The "problem" is that apt supports unsigned repositories as too many
people would bitch too much if it would require a signature – it used
to work before apt 0.6, it has to work forever, man – FOR EVER!

So not getting a signature isn't an error and not even fishy.
It's absolutely fine…


Maybe we could be "evil" and enforce the usage of the flag on update, too?


> Fortunately, apt-get won't let you install anything:
> 
> | # apt-get install -qq nyancat
> | WARNING: The following packages cannot be authenticated!
> |   nyancat
> | E: There are problems and -y was used without --force-yes
> 
> And it won't let you even download binary packages:
> 
> | $ apt-get download nyancat
> | WARNING: The following packages cannot be authenticated!
> |   nyancat
> | E: Some packages could not be authenticated

JFTR: --allow-unauthenticated is the flag littered all over the place to
let this error disappear. Similar to wget --no-check-certificate | sh.


> So far, so good. However, apt-get happily downloads unauthenticated source
> packages, with no warning:
> 
> | $ apt-get source -d nyancat
> | Reading package lists... Done
> | Building dependency tree
> | Reading state information... Done
> | Selected version '1.2.2-1' (unstable) for nyancat
> | Need to get 20.6 kB of source archives.
> | Get:1 http://ftp.debian.org/debian/ unstable/main nyancat 1.2.2-1 (dsc) [1782 B]
> | Get:2 http://ftp.debian.org/debian/ unstable/main nyancat 1.2.2-1 (tar) [14.1 kB]
> | Get:3 http://ftp.debian.org/debian/ unstable/main nyancat 1.2.2-1 (diff) [4748 B]
> | Fetched 20.6 kB in 0s (1838 kB/s)
> | Download complete and in download only mode
> |
> | $ echo $?
> | 0

Snipping the rest as if it downloads, everything else is just a follow
up. You see btw that dpkg-source (which does the unpack/build) would
check signatures on the dsc if it had them available. I think installing
debian-keyring would help (at least for packages from debian).

You will also notice that the check for the hashsum in the Sources, as
well as the check for the hashsum of Sources in Release is done, you
"just" don't get this lovely warning & error message for missing
signatures (aka: the MITM has to be a bit more active in modifying these
files as well to get away with sneaking bad files on your system).


The source (is this a pun now?) has no indication of ever wanting to
check this. Easy to add, for sure (CheckAuth method exists in various
versions in various places). Hardest part will be deciding if
a) sources should be interactive (needs a new string) OR
b) not just like e.g. 'download'.


I guess the later makes more sense (similar to download) and is more
backward compatible (not suddenly interactive), would therefore not
require a new string and should be simple(r) to backport if needed.
As this will surely find at least a few complainers for stable I will
repeat it though: This breaks (obviously) compatibility with unsigned
archives. Workaround for those buggers would be the flag from above.


Haven't written patch/testcase yet though, as I should be in dreamland
for a while now, so I could be horribly wrong about all this of course.

Not a lot of time tomorrow^Wtoday (and I can't upload anyway), so,
Michael, could you please have a look and talk to the security teams?


Best regards

David Kalnischkies

[signature.asc (application/pgp-signature, inline)]

---

Message #13 received at submit@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Thu, May 29, 2014 at 11:04:35PM +0200, Jakub Wilk wrote:
> Package: apt
> Version: 1.0.3
> Severity: grave
> Tags: security

Thanks for your bugreport. You raise a important issue, but I agree
with David that its best if this goes through the security team for
coordination.
 
> I've been investigating how apt behaves when the repository doesn't
> contain any Release signatures (possibly because they were stripped
> off by a man-in-the-middle attacker).
> 
> This is what I found out:
> 
> | # cat /etc/apt/sources.list
> | deb http://ftp.debian.org/debian/ unstable main
> | deb-src http://ftp.debian.org/debian/ unstable main
> |
> | # apt-get update
> | Ign http://ftp.debian.org unstable InRelease
> | Ign http://ftp.debian.org unstable Release.gpg
> | Get:1 http://ftp.debian.org unstable Release [205 kB]
> | Get:2 http://ftp.debian.org unstable/main Sources [7249 kB]
> | Get:3 http://ftp.debian.org unstable/main amd64 Packages [6758 kB]
> | Fetched 14.2 MB in 29s (479 kB/s)
> | Reading package lists... Done
> |
> | # echo $?
> | 0
> 
> Hmm. There is no warning suggesting that anything fishy is going on,
> and the exit code indicates success. (Perhaps the "Ign"s could raise
> suspicion of an observant sysadmin. But who knows what "Ign" exactly
> means? At least the apt-get(1) manpage doesn't know.)

Right, I think apt should show a more prominent warning here. I will
look into this next.
 
[..]
> So far, so good. However, apt-get happily downloads unauthenticated
> source packages, with no warning:
> 
> | $ apt-get source -d nyancat
> | Reading package lists... Done
> | Building dependency tree
> | Reading state information... Done
> | Selected version '1.2.2-1' (unstable) for nyancat
> | Need to get 20.6 kB of source archives.
> | Get:1 http://ftp.debian.org/debian/ unstable/main nyancat 1.2.2-1 (dsc) [1782 B]
> | Get:2 http://ftp.debian.org/debian/ unstable/main nyancat 1.2.2-1 (tar) [14.1 kB]
> | Get:3 http://ftp.debian.org/debian/ unstable/main nyancat 1.2.2-1 (diff) [4748 B]
> | Fetched 20.6 kB in 0s (1838 kB/s)
> | Download complete and in download only mode
[..]

Indeed, this is a problem that needs fixing. Attached is a patch that
addresses the issue.

Cheers,
 Michael

[0001-Show-unauthenticated-warning-for-source-packages-as-.patch (text/x-diff, attachment)]

---

Message #23 received at 749795@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Fri, May 30, 2014 at 03:21:20PM +0200, Michael Vogt wrote:
> >From b7f501b5cc8583f61467f0c7a0282acbb88e4b29 Mon Sep 17 00:00:00 2001
> From: Michael Vogt <mvo@debian.org>
> Date: Fri, 30 May 2014 14:47:56 +0200
> Subject: [PATCH] Show unauthenticated warning for source packages as well
> 
> This will show the same unauthenticated warning for source packages
> as for binary packages and will not download a source package if
> it is unauthenticated. This can be overriden with

typo: overridden

> +   // check authentication status of the source as well
> +   if (UntrustedList != "" && !AuthPrompt(UntrustedList, true))
> +      return false;

As said, I don't think 'apt-get source' should be interactive, so this
true should be a false, right?

Reasons (as a repeat):
- it was not interactive before
- the error message on 'no' talks about install, so we would need a new
  string
- 'apt-get download' isn't interactive either
(- it is more in line with your own commit summary)

Counter arguments?


Best regards

David Kalnischkies

[signature.asc (application/pgp-signature, inline)]

---

Message #28 received at 749795@bugs.debian.org (full text, mbox, reply):

On Sat, May 31, 2014 at 12:07:48AM +0200, David Kalnischkies wrote:
> On Fri, May 30, 2014 at 03:21:20PM +0200, Michael Vogt wrote:
> > >From b7f501b5cc8583f61467f0c7a0282acbb88e4b29 Mon Sep 17 00:00:00 2001
> > From: Michael Vogt <mvo@debian.org>
> > Date: Fri, 30 May 2014 14:47:56 +0200
> > Subject: [PATCH] Show unauthenticated warning for source packages as well
> > 
> > This will show the same unauthenticated warning for source packages
> > as for binary packages and will not download a source package if
> > it is unauthenticated. This can be overriden with
> 
> typo: overridden

Thanks, fixed.
 
> > +   // check authentication status of the source as well
> > +   if (UntrustedList != "" && !AuthPrompt(UntrustedList, true))
> > +      return false;
> 
> As said, I don't think 'apt-get source' should be interactive, so this
> true should be a false, right?
> 
> Reasons (as a repeat):
> - it was not interactive before
> - the error message on 'no' talks about install, so we would need a new
>   string
> - 'apt-get download' isn't interactive either
> (- it is more in line with your own commit summary)
> 
> Counter arguments?
[..]

Good point! No counter arguments, the risk of breaking script by
prompting is indeed a good reason not to show the prompt (and we do
the same for download).

I changed it to non-interactive now.

Cheers,
 Michael

---

Message #33 received at 749795-close@bugs.debian.org (full text, mbox, reply):

Source: apt
Source-Version: 1.0.4

We believe that the bug you reported is fixed in the latest version of
apt, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 749795@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Vogt <mvo@debian.org> (supplier of updated apt package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Tue, 10 Jun 2014 14:55:05 +0200
Source: apt
Binary: apt libapt-pkg4.12 libapt-inst1.5 apt-doc libapt-pkg-dev libapt-pkg-doc apt-utils apt-transport-https
Architecture: source all amd64
Version: 1.0.4
Distribution: unstable
Urgency: low
Maintainer: APT Development Team <deity@lists.debian.org>
Changed-By: Michael Vogt <mvo@debian.org>
Description:
 apt        - commandline package manager
 apt-doc    - documentation for APT
 apt-transport-https - https download transport for APT
 apt-utils  - package management related utility programs
 libapt-inst1.5 - deb package format runtime library
 libapt-pkg-dev - development files for APT's libapt-pkg and libapt-inst
 libapt-pkg-doc - documentation for APT development
 libapt-pkg4.12 - package management runtime library
Closes: 742835 745046 747942 748389 748430 749795 750009
Changes:
 apt (1.0.4) unstable; urgency=low
 .
   [ Michael Vogt ]
   * Implement CacheDB for source packages in apt-ftparchive
   * apt-private/acqprogress.cc: reset color in apt update
   * Show progress in run-tests
   * Never parse Version/Architecture tags in a Translation-$lang file
   * Show upgradable packages after apt update (Closes: 748389)
   * Fix various errors found by clang -fsanitize=address
   * Fix various errors foudn by clang scan-build
   * Show unauthenticated warning for source packages as well (Closes: #749795)
   * Add compat mode for old (32bit FileSize) CacheDB (LP: #1274466)
   * cmdline/apt-helper.cc: use less generic description/short-description
     in apt-helper download
   * add pkgSrcRecords::Step() to step through all the pkgSrcRecords
     (thanks to Helmut Grohne)
 .
   [ David Kalnischkies ]
   * initialize Verify in second pkgAcqIndex constructor
   * consistently fail if Smart* packagemanager actions fail
   * fix tight loop detection and temporary removes
   * if Resolver fails, do not continue even if not broken
   * check exit status of external solvers
   * do not revert candidate for protected packages (Closes: 745046)
   * support Acquire::GzipIndexes in dumpavail (Closes: 742835)
 .
   [ Stefano Zacchiroli ]
   * EDSP doc: fix typo in Request stanza description
   * EDSP: bump protocol version to 0.5
   * EDSP: add Architecture(s) multi-arch fields to the Request stanza
   * EDSP: add Source field to Package stanzas
   * EDSP: add APT-Release field to Package stanzas
 .
   [ Sebastian Schmidt ]
   * fix screen width detection for apt/apt-get lists (Closes: 748430, 747942)
 .
   [ Milo Casagrande ]
   * Italian program translation update (Closes: 750009)
Checksums-Sha1:
 5012b3eedb72a72ca69ffabbdbeb1085fafa5579 1716 apt_1.0.4.dsc
 e0c1cb8cb6f6a861285ea0bf2c676a3e418f6b2d 1776932 apt_1.0.4.tar.xz
 ab36a1e23185e32843c256dc6041a389c116b658 271722 apt-doc_1.0.4_all.deb
 bb5d2f932b02b6931df0faae8c514e25643ff103 770516 libapt-pkg-doc_1.0.4_all.deb
 1fc3f3a79460a1340c74c6cb3a24a99b27a28470 749480 libapt-pkg4.12_1.0.4_amd64.deb
 dfab4ae6117a23fe31aadb1250af3fa845078529 164442 libapt-inst1.5_1.0.4_amd64.deb
 ae398139586d0c54a859062c469bea4878cfa276 1062828 apt_1.0.4_amd64.deb
 d0c1e3112ae6a1722697725ff7831ce1eeeacf0b 189120 libapt-pkg-dev_1.0.4_amd64.deb
 eba44caba84d5925aaa1aaac28f0b5d61dbbd526 355048 apt-utils_1.0.4_amd64.deb
 2cd4430d01c7a6540319518786ad72b8f4989009 131300 apt-transport-https_1.0.4_amd64.deb
Checksums-Sha256:
 fcf12c38d105e0c4bde1761ba4ccaeec687f99e52ef2ef57898502aba78f9bf9 1716 apt_1.0.4.dsc
 bc1ae079f4608f5d60963bf0646a899329ba2fd54b2a34a5a57bcd1a29f95c7e 1776932 apt_1.0.4.tar.xz
 c39908954314bc4d2255e797dd5c1277e238b899175f979b305511a522cde2b3 271722 apt-doc_1.0.4_all.deb
 071510242264073073900600e3d49e53ca7bc70e4b6cd8856b7e5004ab5ce8f2 770516 libapt-pkg-doc_1.0.4_all.deb
 d044473e47d7c43cce4e5fe411fd9e0a8136f12de793d67333f27bfe49592940 749480 libapt-pkg4.12_1.0.4_amd64.deb
 dd501debd8f3cf26487b31acf122d4707a91dce8c5fe4394622fc66ceffd3ff2 164442 libapt-inst1.5_1.0.4_amd64.deb
 9133b9e1c43a6dd36c485875fe01b56aadc1d896da1396f7b848b8935f89eae3 1062828 apt_1.0.4_amd64.deb
 1c8d0c6b09f54f7ffd38da0b7d6ffbfbaf0b201b07f10e28dd3a7e41dd29cf76 189120 libapt-pkg-dev_1.0.4_amd64.deb
 32b8e05637e666960329b8088120a0b3e101c0b6446a4d81c2fa4eed7f0a3f97 355048 apt-utils_1.0.4_amd64.deb
 8ae733c28411984a63b4c53a93b0842d06fc925ac913a3fc78129070b7c8ea4b 131300 apt-transport-https_1.0.4_amd64.deb
Files:
 0788362911f30214667b49eca5bbdc4a 271722 doc optional apt-doc_1.0.4_all.deb
 080b8e6bb21fc37ba55358c852a92a11 770516 doc optional libapt-pkg-doc_1.0.4_all.deb
 0d7c7739ad82da0b3307691ec6547ee0 749480 libs important libapt-pkg4.12_1.0.4_amd64.deb
 db9a0fb1408646e59f12d66e0e968952 164442 libs important libapt-inst1.5_1.0.4_amd64.deb
 838d4d1f9276022b2cf607ce1144f69f 1062828 admin important apt_1.0.4_amd64.deb
 aa1c9f8f2f1014bc881eb005e7b80473 189120 libdevel optional libapt-pkg-dev_1.0.4_amd64.deb
 dc0d7ffeefb9c2d4e258dca8bebfec8f 355048 admin important apt-utils_1.0.4_amd64.deb
 447f3686b24ec1277ab99b972dc20eef 131300 admin optional apt-transport-https_1.0.4_amd64.deb
 39b9a5cdda52d708f827a85a0a0f353a 1716 admin important apt_1.0.4.dsc
 164852d9b08178b8212fa78daa08e6f2 1776932 admin important apt_1.0.4.tar.xz

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlOXEQ8ACgkQliSD4VZixzSVNACfeq5v8DBcV0aBoY/mJLIbli38
fO8Ani++44JL+oC7GYGh5iZh48nzu8i5
=ke43
-----END PGP SIGNATURE-----

---

Message #38 received at 749795@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

reopen 749795
stop

Hi.

I'm reopening this for now, even if the issue is solved from a technical
point of view (see below why).


In my opinion this is really some horrible bug... probably it could have
been very easily found by others, and we have no idea whether it was
exploited already or not.

Anyone who believed in getting trusted sources might have been attacked
with forged packages, and even the plain build of such package might
have undermined users' security integrity.

The same is the case with all debian build systems which probably rely
on secure APT.


So IMHO this bug definitely deserves a CVE and a DSA,... so that people
are informed that there systems might have been compromised (i.e. if an
attacker tricked them into using forged sources)... which is also why I
reopen it.

And do we need an investigation whether Debian an the Debian archives
themselves might have been intruded that way?


It's really saddening to see that such an issue could slip through,
especially when I've personally started already a few threads on
debian-devel about the security of secure APT.
The most recent one was IIRC:
https://lists.debian.org/debian-devel/2012/03/msg00549.html
but I've had one before, I think.


I think such bug shows that we can't just move on as we did till now...

From the APT perspective:

- Do we have unit checks now in APT, which basically test all commands
with unsigned repos, repos with invalid signature, packages where the
sums don't match the valid repo signatures, etc.?
We really should have this,.. and also check for things like expiry
dates.

- I also think that there should be one place of code that handles all
downloads of packages, so that we have some rock solid functions, which
do all the checks and verifications.

- I think per default APT should refuse to work with unsigned
repos/packages. One should really need some configuration switch or
option that allows this.
I don't think it's a big issue, since all the major repos are signed and
even the "end-user" tools to make own repos (like debarchiver) support
signing.
People should simply be taught to not use unsigned repos...

- That being said,... APT should always delete all cached files (repo
lists, signature files, Package and Source lists as well as downloaded
packages) as soon as a single verification error occurred at some place.
And since 3rd party programs or users may manually take stuff from
places like /var/lib/apt/lists or /var/cache/apt/archives... these
directories should contain a subdir like "unsecured/" where APT
downloads stuff to and only moves it out from there once all checks have
been passed.

- In case any even just remotely possible security issue occurs... apt
should exit with a non-zero status and not just a warning wich shell
scripts from users usually won't check for.


What about 3rd party programs and Debian in general:
There are still probably many programs which download stuff without any
verification,... or just warn which may be easily overseen:
- [c]debootstrap
I think they both default now to verify signatures (which is a good
thing)... but IIRC, debootstrap also defaults to not verify anything...
if the keyrings aren't installed - admittedly this is unlikely... but
possible... I've already had a discussion at the respective bug with
upstream, but nothing happened... I think such choices make it easily
happen for security critical situations to occur... completely
unnecessary.

- not really secure APT related: apt-listbugs
Not sure whether it uses https for getting bug infos... but since Debian
nowadays uses certs from GANDI, which we generally cannot trust,... this
is probably moot anyway.
Securely showing bugs, may be important for users, since they want to
now about bugs like "big security hole in package XYZ - don't install"

- apt-listchanges
Guess that uses local files an is therefore secure.

- apt-file
Last time I checked, the bug about not verifying the sums of the
Contents-* files was still open


- what about our build daemons and building tools like piuparts,
pbuilder, pbuilder-uml, debian-builder or qemubuilder
Do they use secure APT in ALL places? Is this constantly checked by some
unit tests?
Or are they easily tricked into using possibly insecure files, by
depending on exit statuses which are perhaps not != 0 in case of
security problems ... or by using files which were downloaded but not
removed when it was found out that they're insecure.

I think a package like e.g. pbuilder might easily operate insecurely...
it depends on [c]debootstrap for building... if debootstrap is used, but
debian-archive-keyring is not installed, then (IIRC) no signature
checking is done... in that case forged stuff may be downloaded,
chrooted into... and *bam* - already lost the game... and you don't even
need a hole like APT not checking files it gets with apt-get source.



Cheers,
Chris.

[smime.p7s (application/x-pkcs7-signature, attachment)]

---

Message #47 received at 749795@bugs.debian.org (full text, mbox, reply):

Christoph Anton Mitterer wrote:
> reopen 749795
> I'm reopening this for now, even if the issue is solved from a technical
> point of view (see below why).

AAICS, #749795 talked about bringing this to the security team's
attention, but they never seem to have been CCed.

So the security team may not be aware that a security hole in apt was
recently fixed, that caused apt-get source to not give any indication
when the Release file was lacking a signature.

Whether it's closed in unstable or not, this bug is open still in
stable, and needs to get a CVE assigned, and a DSA issued.

-- 
see shy jo

---

Message #54 received at 749795@bugs.debian.org (full text, mbox, reply):

On Thu, 12 Jun 2014, Christoph Anton Mitterer wrote:

> Anyone who believed in getting trusted sources might have been attacked
> with forged packages, and even the plain build of such package might
> have undermined users' security integrity.

Then I believe Debian itself may be undermined.

> The same is the case with all debian build systems which probably rely
> on secure APT.

A buildd (sbuild) or cowbuilder is set up using the normal debootstrap
process with --variant=buildd using the Debian archive keyring of the
host system to validate. (This works.) Then, /etc/apt/sources.list is
written, and APT defaults to secure. The debian-archive-keyring package
is Essential, so this is always installed during the bootstrap. Porters
add debian-ports-archive-keyring (debootstrap can do that).

The buildd-related software (and most people when doing manual builds
with cowbuilder) uses “apt-get source foo” to download the file, fully
assuming that apt-get ensures validation, so no “dscverify” is run on
the sources downloaded by apt. (If someone uses dget, either dget is
new enough to call dscverify, or they had better be doing that by hand.)

The build process inside the chroot of cowbuilder also calls dscverify,
but as debian-keyring (distinct from debian-archive-keyring) is never
installed, it errors out always, which is just ignored. (That being
said, when I was doing porter builds/uploads with cowbuilder and used
dget+dscverify to retrieve the source, even the debian-keyring package
in sid was sometimes not up-to-date enough to have the new keys the
maintainers used to sign their packages in it. Since the proper buildd
infrastructure does not use this but relies on SecureAPT to validate
the files it downloads, this is understandable.)

This means that, if there was ever a chance that 'apt-get source foo'
would not check the integrity of the files it downloaded against
Sources.gz + Release{,.gpg} we’re in pretty deep shit. (Well, there
was, before SecureAPT was enacted, but that’s outside of the scope
of this.)

bye,
//mirabilos
-- 
“ah that reminds me, thanks for the stellar entertainment that you and certain
other people provide on the Debian mailing lists │ sole reason I subscribed to
them (I'm not using Debian anywhere) is the entertainment factor │ Debian does
not strike me as a place for good humour, much less German admin-style humour”

---

Message #61 received at 749795@bugs.debian.org (full text, mbox, reply):

Hi,

> apt: no authentication checks for source packages

The Debian security team has assigned CVE-2014-0478 to this issue.

APT developers: we should fix this in wheezy. Are you able to provide an
update for wheezy for this issue?

As for squeeze, if it's not too much extra work it would be great if an
update for squeeze was also possible. Perhaps it could also even include
the fix for https://security-tracker.debian.org/tracker/CVE-2011-3634?

Let us know.

Thanks,
Thijs

---

Message #66 received at 749795@bugs.debian.org (full text, mbox, reply):

On Thu, Jun 12, 2014 at 11:44:20AM +0200, Thijs Kinkhorst wrote:
> Hi,
> 
> > apt: no authentication checks for source packages
> 
> The Debian security team has assigned CVE-2014-0478 to this issue.
> 
> APT developers: we should fix this in wheezy. Are you able to provide an
> update for wheezy for this issue?

Yes, I will work on a backport for this today.

> As for squeeze, if it's not too much extra work it would be great if an
> update for squeeze was also possible. Perhaps it could also even include
> the fix for https://security-tracker.debian.org/tracker/CVE-2011-3634?

I look into this too, I don't know yet how much extra work it is.

Cheers,
 Michael

---

Message #73 received at 749795@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Thu, Jun 12, 2014 at 11:44:20AM +0200, Thijs Kinkhorst wrote:
> > apt: no authentication checks for source packages
> 
> The Debian security team has assigned CVE-2014-0478 to this issue.
> 
> APT developers: we should fix this in wheezy. Are you able to provide an
> update for wheezy for this issue?
[..]

Attached is the fix for wheezy with a regression test, a additional
test run is very welcome (works in my wheezy container both the
testcase and a manual test when removing /var/lib/apt/lists/*Release*).

Cheers,
 Michael

[apt_0.9.7.9+deb7u2.debdiff (text/plain, attachment)]

---

Message #78 received at 749795@bugs.debian.org (full text, mbox, reply):

Hi Michael,

On Thu, June 12, 2014 13:52, Michael Vogt wrote:
> On Thu, Jun 12, 2014 at 11:44:20AM +0200, Thijs Kinkhorst wrote:
>> > apt: no authentication checks for source packages
>>
>> The Debian security team has assigned CVE-2014-0478 to this issue.
>>
>> APT developers: we should fix this in wheezy. Are you able to provide an
>> update for wheezy for this issue?
> [..]
>
> Attached is the fix for wheezy with a regression test, a additional
> test run is very welcome (works in my wheezy container both the
> testcase and a manual test when removing /var/lib/apt/lists/*Release*).

Thanks! I've built it and verified that it works for me aswell (and solves
the issue). For the changelog: you need to target "wheezy-security", and
may want to add "closes: #749795" and urgency=high. With these changes you
can upload to security-master.debian.org. Make sure to build with full
source ("-sa") as wheezy-security doesn't yet have the orig tarball.

The patch seems to apply rather cleanly to squeeze, so an update for that
would be nice if possible. Fixing CVE-2011-3634 aswell would be nice if
simple to do but not essential.


Cheers,
Thijs

---

Message #83 received at 749795@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Thu, Jun 12, 2014 at 11:44:20AM +0200, Thijs Kinkhorst wrote:
[..]
> > apt: no authentication checks for source packages
> 
> The Debian security team has assigned CVE-2014-0478 to this issue.
[..]
> As for squeeze, if it's not too much extra work it would be great if an
> update for squeeze was also possible. Perhaps it could also even include
> the fix for https://security-tracker.debian.org/tracker/CVE-2011-3634?

Attached is the debdiff for squeeze. Additional testing welcome (work
in my debian-squeeze environment).

Cheers,
 Michael

[apt_0.8.10.3+squeeze2.debdiff (text/plain, attachment)]

---

Message #88 received at 749795@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Thu, Jun 12, 2014 at 01:06:28AM +0200, Christoph Anton Mitterer wrote:
> In my opinion this is really some horrible bug... probably it could have
> been very easily found by others, and we have no idea whether it was
> exploited already or not.

Probably yes. Someone in the last ~11 years could have, but that nobody
did tells you a lot about how many people actively work on what so many
people seem to assume just has to work and complain loudly if it
doesn't in the way it always was (assumed to be)… so, to get anything
useful out of this: Should we do a kickstarter now or wait for
a libreapt fork?


> Anyone who believed in getting trusted sources might have been attacked
> with forged packages, and even the plain build of such package might
> have undermined users' security integrity.

Worst case. In practice you will have installed build-dependencies
before which has resulted in a error for those, which should have been
enough for you to recognise that something fishy goes on. It is at least
what all automatic builders will run into. Assuming of course you don't
ignore such errors which many users/scripts happily do…


Also, keep in mind that the chain is broken at the Release -> Sources
level, not at the Sources -> tarball level, so if you ship modified
tarballs to your target you have to also ship a modified Sources file.

For your attack to be (always) successful, you need a full-sources
mirror on which you modify all tarballs, so that you can build a valid
Sources file. You can't just build your attack tarball on demand as the
hash (and filesize) isn't going to match with what Sources declares.
(assuming you aren't good at pre-imaging, but then, why do you bother
with this one here?) Combine that with the problems of being a good MITM
in general and you might understand why my heart isn't bleeding that
much about this particular bug. We had worse and nobody really cared…


> It's really saddening to see that such an issue could slip through,
> especially when I've personally started already a few threads on
> debian-devel about the security of secure APT.
> The most recent one was IIRC:
> https://lists.debian.org/debian-devel/2012/03/msg00549.html
> but I've had one before, I think.

What is really sad is that many people keep talking about how much more
secure everything should be but don't do the smallest bit of work
to make it happen or even do a basic level of research themselves.

So instead of answering all your questions, I will instead leave them
unanswered and say: Go on and check for yourself! You shouldn't trust
a random guy like me anyway and if that leads to even one person
contributing to apt (or the security team or anything else really) in
this area, we have a phenomenal massive increase in manpower …
(for apt in the 50% ballpark!)


> - I think per default APT should refuse to work with unsigned
> repos/packages. One should really need some configuration switch or
> option that allows this.

I will comment this one though: Michael wanted to look into this for
a while now. The plan I was suggesting was something like jessie:
support-unauth=true by default, jessie+1: support-unauth=false by
default, jessie+2: gone. We will see if this can be implemented at all.
Contributions welcome as always.


> I don't think it's a big issue, since all the major repos are signed and
> even the "end-user" tools to make own repos (like debarchiver) support
> signing.

Think again. People do it all the time. It is the default mode of
operation for plugging in repos into builders for example. If you are
bored, just search for the usage of --allow-unauthenticated.


I half-jokingly mentioned with the plan last time that a bunker is
nearby, so I would be safe; half-jokingly as at least I got murder
threats for far less. I doubt it will be any different with this "not
big issue". So be careful with what you assume to be simple and
uncontroversial. See also xkcd#1172.


Some usecases can be transitioned to [trusted=yes] probably, but I am
not sure we really gain that much this way (as it makes things actually
worse from a security standpoint) so we really shouldn't press the
"security: don't care" crowd in this direction. Hence the slow ride-plan.


> People should simply be taught to not use unsigned repos...

Yeah. I will try my luck with world peace first though. Might be easier…
But I am a naive kid. 5 years ago I wondered why a small bug – which
even I could provide a patch for – wasn't fixed. Now I wonder how the
"team" manages to keep up with reading bugs at all; but its the same for
many other "Debian: native" packages. aka: It took me a while to
understand what "no upstream" really means …


Best regards

David Kalnischkies

P.S.: Dropping security@, bug@ and everyone else in Reply-To as this
chit-chat thread is just noise for them. Please don't pick up cc's at
random … If you want to /work/ on anything you could move to deity@ as
already suggested. Otherwise lets just talk here… (and no, you don't
have to cc me either)

[signature.asc (application/pgp-signature, inline)]

---

Message #93 received at 749795-close@bugs.debian.org (full text, mbox, reply):

Source: apt
Source-Version: 0.8.10.3+squeeze2

We believe that the bug you reported is fixed in the latest version of
apt, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 749795@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Vogt <mvo@debian.org> (supplier of updated apt package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Thu, 12 Jun 2014 14:30:59 +0200
Source: apt
Binary: apt apt-doc libapt-pkg-dev libapt-pkg-doc apt-utils apt-transport-https
Architecture: source all amd64
Version: 0.8.10.3+squeeze2
Distribution: squeeze-lts
Urgency: high
Maintainer: APT Development Team <deity@lists.debian.org>
Changed-By: Michael Vogt <mvo@debian.org>
Description: 
 apt        - Advanced front-end for dpkg
 apt-doc    - Documentation for APT
 apt-transport-https - APT https transport
 apt-utils  - APT utility programs
 libapt-pkg-dev - Development files for APT's libapt-pkg and libapt-inst
 libapt-pkg-doc - Documentation for APT development
Closes: 749795
Changes: 
 apt (0.8.10.3+squeeze2) squeeze-lts; urgency=high
 .
   * SECURITY UPDATE: apt-get source validation (closes: #749795)
     - CVE-2014-0478
   * SECURITY UPDATE: sensitive information disclosure via incorrect
     hostname validation (LP: #868353)
     - methods/https.cc: properly set CURLOPT_SSL_VERIFYHOST.
     - CVE-2011-3634
Checksums-Sha1: 
 eac6d7afdc9913e918c226c484f32450b8bf1125 1643 apt_0.8.10.3+squeeze2.dsc
 b08a7fde701111f12c4c93065ae1ea83627e24c2 3148430 apt_0.8.10.3+squeeze2.tar.gz
 5d1a4c81d0b2c54227952e73ae9248e052a26e16 235592 apt-doc_0.8.10.3+squeeze2_all.deb
 fb86248e760cf453658988237b454a9d8b745ba2 694130 libapt-pkg-doc_0.8.10.3+squeeze2_all.deb
 8f875323dd04ae2dca2db521490b24a60d7cdc5d 2183396 apt_0.8.10.3+squeeze2_amd64.deb
 8162afbed8d101c9538aff8d6892d6e9b6d92882 151120 libapt-pkg-dev_0.8.10.3+squeeze2_amd64.deb
 8c1218aadb87860d36507d5b305229e5a9adeb36 274288 apt-utils_0.8.10.3+squeeze2_amd64.deb
 ca73c4732c0a75ae41509357b6c55e708cf507b8 84058 apt-transport-https_0.8.10.3+squeeze2_amd64.deb
Checksums-Sha256: 
 3ec6e2f8b406bb87c766f758f5526c6d97d229d85fa980799ebca03e823fb355 1643 apt_0.8.10.3+squeeze2.dsc
 5049e40a7b9ddd8caab7860a99d4eb0688f8629bd19896c5a8e453961d14c375 3148430 apt_0.8.10.3+squeeze2.tar.gz
 685188746b24906f09a78ec6fdcef7c5770fc0255260682101815f1bdad0d742 235592 apt-doc_0.8.10.3+squeeze2_all.deb
 408539d9d8362da9d9acd8ab14411ee6d5328b0becc49cd57d642c83c925f442 694130 libapt-pkg-doc_0.8.10.3+squeeze2_all.deb
 9d97c6af65cb587509b34caf7e3cfa21fb32de107b829751be4c9a043ef7448f 2183396 apt_0.8.10.3+squeeze2_amd64.deb
 0151206e844f0a6d41d6ae99fca91b533d20852c888a4252f366f919275c7a34 151120 libapt-pkg-dev_0.8.10.3+squeeze2_amd64.deb
 6d3449b1bd787dc58a9145f07fa2787d64eb31122996e92b6844034063e9f8bf 274288 apt-utils_0.8.10.3+squeeze2_amd64.deb
 b7952017066021c5900ee2cb928f10844de54fe9b092cad68d7cbfcc12f2a3d8 84058 apt-transport-https_0.8.10.3+squeeze2_amd64.deb
Files: 
 8950d696fac7fba2d6ec5d2e4ee6ab3c 1643 admin important apt_0.8.10.3+squeeze2.dsc
 9035eeeb42a5ad4a7d0ca191b62c0b15 3148430 admin important apt_0.8.10.3+squeeze2.tar.gz
 a078195dfc1a586f869ad610c991040f 235592 doc optional apt-doc_0.8.10.3+squeeze2_all.deb
 0d7be19fe7a5a2489c53f2681c8be837 694130 doc optional libapt-pkg-doc_0.8.10.3+squeeze2_all.deb
 1390d6e23202117a5af409851a457e41 2183396 admin important apt_0.8.10.3+squeeze2_amd64.deb
 1495f46f4be1db85d89b36ae39f55400 151120 libdevel optional libapt-pkg-dev_0.8.10.3+squeeze2_amd64.deb
 83dc1cf2c8550a91445a4a9cba81dced 274288 admin important apt-utils_0.8.10.3+squeeze2_amd64.deb
 5fb8ce76ac8426e3bd41fe02246061f8 84058 admin optional apt-transport-https_0.8.10.3+squeeze2_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQEcBAEBAgAGBQJTmed2AAoJEFb2GnlAHawEELkH/AnEU0JlKTJGAouq3ZcE2o9o
BCrHt4iw85YxKWiiRGcZDJv585TdWxVQCafZo9F4jn555xr6ZQq+MaUYHXmE1m+e
LHxpsa3UbbMg6GddGv9g3ZJL4YEHJ4+4Ipw0BU5y/KwlCq1RB74SftbFHWmRe+Sy
pprl9IiS1n9clccpoCSxRji8IpndDPyP/+kaF0bCl6L6NAqGVYtNrMawctOfLebg
4mm2rZc2/4BPpDPOnN8UqOYqobXOL5NOhtjxop/VFC+ZdSDAnTBIWB6lB+wuXLu9
T43x+5iYTxiNyzLHOrGVMVF93/5Cg9zGqNqN3ERbEKwO6tJHyTajwsTxMT2kreA=
=dBKb
-----END PGP SIGNATURE-----

---

Message #98 received at 749795-close@bugs.debian.org (full text, mbox, reply):

Source: apt
Source-Version: 0.9.7.9+deb7u2

We believe that the bug you reported is fixed in the latest version of
apt, which is due to be installed in the Debian FTP archive.

A summary of the changes between this version and the previous one is
attached.

Thank you for reporting the bug, which will now be closed.  If you
have further comments please address them to 749795@bugs.debian.org,
and the maintainer will reopen the bug report if appropriate.

Debian distribution maintenance software
pp.
Michael Vogt <mvo@debian.org> (supplier of updated apt package)

(This message was generated automatically at their request; if you
believe that there is a problem with it please contact the archive
administrators by mailing ftpmaster@ftp-master.debian.org)


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Format: 1.8
Date: Thu, 12 Jun 2014 12:47:25 +0200
Source: apt
Binary: apt libapt-pkg4.12 libapt-inst1.5 apt-doc libapt-pkg-dev libapt-pkg-doc apt-utils apt-transport-https
Architecture: source all amd64
Version: 0.9.7.9+deb7u2
Distribution: wheezy-security
Urgency: high
Maintainer: APT Development Team <deity@lists.debian.org>
Changed-By: Michael Vogt <mvo@debian.org>
Description: 
 apt        - commandline package manager
 apt-doc    - documentation for APT
 apt-transport-https - https download transport for APT
 apt-utils  - package managment related utility programs
 libapt-inst1.5 - deb package format runtime library
 libapt-pkg-dev - development files for APT's libapt-pkg and libapt-inst
 libapt-pkg-doc - documentation for APT development
 libapt-pkg4.12 - package managment runtime library
Closes: 749795
Changes: 
 apt (0.9.7.9+deb7u2) wheezy-security; urgency=high
 .
   * SECURITY UPDATE: apt-get source validation (closes: #749795)
     - CVE-2014-0478
Checksums-Sha1: 
 cb8ceff4ac6843de5712f13597ce33eb3360ce3e 1707 apt_0.9.7.9+deb7u2.dsc
 bb1d29fa2b799868a909c822e250c14be055f763 3399785 apt_0.9.7.9+deb7u2.tar.gz
 56c78ce70c079a9d55996bcf40ddb94074e38b00 261440 apt-doc_0.9.7.9+deb7u2_all.deb
 b8ad0e3aab1f19b41bae9f402f75d5c8369ff89c 959170 libapt-pkg-doc_0.9.7.9+deb7u2_all.deb
 6606ac96a7bd3c15fe3138f3ef76bfdfcf7a107d 889796 libapt-pkg4.12_0.9.7.9+deb7u2_amd64.deb
 4d4fa4aba36e2a229e90c179e21c8039d0d4ef40 166658 libapt-inst1.5_0.9.7.9+deb7u2_amd64.deb
 f4129fda11b109122ebe300213d88c92cf2b45a7 1261084 apt_0.9.7.9+deb7u2_amd64.deb
 9ec988fcc8761c2de1b92343b87266e79ed97963 187028 libapt-pkg-dev_0.9.7.9+deb7u2_amd64.deb
 44f8ece956dbfe3f2218dead396b8890bc00cd09 377536 apt-utils_0.9.7.9+deb7u2_amd64.deb
 9a7a37335f0e9a9b010016b346a21875833f0af4 108850 apt-transport-https_0.9.7.9+deb7u2_amd64.deb
Checksums-Sha256: 
 3175904abac4645d07662035cfa97718321f6a3cf78dfa2849b34977bb24c565 1707 apt_0.9.7.9+deb7u2.dsc
 3f665cb0e1304681212a292a25fe27f8555ee344c110b7ed6dbdd636c19e8686 3399785 apt_0.9.7.9+deb7u2.tar.gz
 8b089afe469223c7b6672f266590006ff6d79ffc4f83af1f8c15b596a9aa3125 261440 apt-doc_0.9.7.9+deb7u2_all.deb
 03117d4102bc510a4f1a6efac8dead97d3827588107ba6c1e979e998f4214c44 959170 libapt-pkg-doc_0.9.7.9+deb7u2_all.deb
 89b7e28d8fef6551646760fc85e586fa3f0d5b802fd44b1168da7448acc84e8e 889796 libapt-pkg4.12_0.9.7.9+deb7u2_amd64.deb
 a57680fc959c7e25097bb70398860506e4c8c8d1fbc5b8bb5c637855cb7d8978 166658 libapt-inst1.5_0.9.7.9+deb7u2_amd64.deb
 36997b52ad31ae481ba9be17d592b6737d29cb11b1357e2061ce5fd57b2635fe 1261084 apt_0.9.7.9+deb7u2_amd64.deb
 23af5f2a03a08350538660586c97f29b986ff629b298d7ecfe7a42c2a01d9902 187028 libapt-pkg-dev_0.9.7.9+deb7u2_amd64.deb
 6c33e95f587e9a28d61fb7bf1375ec9a427636702b0cce3f7f3f030ff1193da9 377536 apt-utils_0.9.7.9+deb7u2_amd64.deb
 e7bcd8c319e71b06cdfe3ab2b6e67378b935194d2d3556dce383aa163a5dcd59 108850 apt-transport-https_0.9.7.9+deb7u2_amd64.deb
Files: 
 794d53bb8bc41c625fe3837a11fd5d17 1707 admin important apt_0.9.7.9+deb7u2.dsc
 11742f10404fca4c56669f2804af3764 3399785 admin important apt_0.9.7.9+deb7u2.tar.gz
 0cbe517179118a12386f256575a8356b 261440 doc optional apt-doc_0.9.7.9+deb7u2_all.deb
 d0b8099d4f9c5e19528d7fc655724b82 959170 doc optional libapt-pkg-doc_0.9.7.9+deb7u2_all.deb
 9437e9e1d864ece245263eca3e1cd9fd 889796 libs important libapt-pkg4.12_0.9.7.9+deb7u2_amd64.deb
 782fcd67201a92589be12b474d12c086 166658 libs important libapt-inst1.5_0.9.7.9+deb7u2_amd64.deb
 7603385c4f7f8e2bd098bd9a79878403 1261084 admin important apt_0.9.7.9+deb7u2_amd64.deb
 94278e43c53af971d570c9544792237d 187028 libdevel optional libapt-pkg-dev_0.9.7.9+deb7u2_amd64.deb
 dd8bc29f4b17c55a878b824568449a3e 377536 admin important apt-utils_0.9.7.9+deb7u2_amd64.deb
 3075898eaff96911425df6afd11c8631 108850 admin optional apt-transport-https_0.9.7.9+deb7u2_amd64.deb

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iEYEARECAAYFAlOZybMACgkQliSD4VZixzQrOgCfe5CYzF8guEbiq/b2WhGpN7ZH
l14An3upZfD/1SZKFEjZELI9OSL4j1U8
=3WbZ
-----END PGP SIGNATURE-----

---

Message #103 received at submit@bugs.debian.org (full text, mbox, reply):

On Fri, May 30, 2014 at 03:21:20PM +0200, Michael Vogt wrote:
[..]
> > Hmm. There is no warning suggesting that anything fishy is going on,
> > and the exit code indicates success. (Perhaps the "Ign"s could raise
> > suspicion of an observant sysadmin. But who knows what "Ign" exactly
> > means? At least the apt-get(1) manpage doesn't know.)
> 
> Right, I think apt should show a more prominent warning here. I will
> look into this next.
[..]

I create a git branch that shows a warning if it comes accross a
unauthenticated repository:
"""
+   _error->Warning(_("The data from '%s' is not signed. All packages from "
+                     "that repository can not be authenticated."),
+                   MetaIndexURIDesc.c_str());
"""

I think for the future we actually should not allow a apt-get update
of untrusted repos without --allow-unauthenticated  or
[trusted=no]. But this will probably break some setups so we need to
be careful and not rush it.



Cheers,
 Michael

---

Message #111 received at 749795@bugs.debian.org (full text, mbox, reply):

* Michael Vogt <mvo@debian.org>, 2014-06-16, 09:35:
>+   _error->Warning(_("The data from '%s' is not signed. All packages from "
>+                     "that repository can not be authenticated."),

s/can not/cannot/

Also, "All" with a negated verb sounds awkward to me (but that may be 
due to my non-native-englishness). How about:

"No packages from that repository can be authenticated."

or simply

"Packages from that repository cannot be authenticated."

?

-- 
Jakub Wilk

---

Message #116 received at 749795@bugs.debian.org (full text, mbox, reply):

On Thu, 12 Jun 2014, David Kalnischkies wrote:

> For your attack to be (always) successful, you need a full-sources
> mirror on which you modify all tarballs, so that you can build a valid
> Sources file. You can't just build your attack tarball on demand as the

Erm, no? You can just cache a working Sources file and exchange
the paragraph you are interested in. That’s something that would
be easy in a CGI written in shell, *and* perform well. Trivial.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

---

Message #121 received at 749795@bugs.debian.org (full text, mbox, reply):

On Mon, 2014-06-16 at 09:35 +0200, Michael Vogt wrote: 
> I think for the future we actually should not allow a apt-get update
> of untrusted repos without --allow-unauthenticated  or
> [trusted=no]. But this will probably break some setups so we need to
> be careful and not rush it.

And what about the setups, which assume secure data to be retrieved (as
far as I can see the whole build stack of Debian), which is already
broken now?

Security is much more critical here then things continuing to work... if
someone's setup really depend on not verifying integrity... he will
immediately notice (and can add the flag),... but no one notices if his
security is compromised by MitMs... :-(


So I see not much of a reason to not implement that right away.


Cheers,
Chris.

---

Message #126 received at 749795@bugs.debian.org (full text, mbox, reply):

On Mon, Jun 16, 2014 at 02:58:28PM +0200, Christoph Anton Mitterer wrote:
> On Mon, 2014-06-16 at 09:35 +0200, Michael Vogt wrote: 
> > I think for the future we actually should not allow a apt-get update
> > of untrusted repos without --allow-unauthenticated  or
> > [trusted=no]. But this will probably break some setups so we need to
> > be careful and not rush it.
> 
> And what about the setups, which assume secure data to be retrieved (as
> far as I can see the whole build stack of Debian), which is already
> broken now?
> 
> Security is much more critical here then things continuing to work... if
> someone's setup really depend on not verifying integrity... he will
> immediately notice (and can add the flag),... but no one notices if his
> security is compromised by MitMs... :-(
>
> So I see not much of a reason to not implement that right away.

Absolutely, security is (much!) more important.

However with the fix that recently went into -security "apt-get source
foo" will fail if foo comes from a not-authenticated source. What I
wrote above is about not allowing "apt-get update" at all for unsigned
repositories (unless --allow-unauthenticated is used). But maybe you
are right and the warning that I added to git should be a error that
tells the user to use --allow-unauthenticated if he/she really wants
to use a repository that we can not authenticate.

Cheers,
 Michael
 

---

Message #131 received at 749795@bugs.debian.org (full text, mbox, reply):

[Message part 1 (text/plain, inline)]

On Mon, Jun 16, 2014 at 12:04:51PM +0200, Thorsten Glaser wrote:
> On Thu, 12 Jun 2014, David Kalnischkies wrote:
> > For your attack to be (always) successful, you need a full-sources
> > mirror on which you modify all tarballs, so that you can build a valid
> > Sources file. You can't just build your attack tarball on demand as the
> 
> Erm, no? You can just cache a working Sources file and exchange
> the paragraph you are interested in. That’s something that would
> be easy in a CGI written in shell, *and* perform well. Trivial.

The "always" refers to the small problem that a MITM isn't in control of
what source package is acquired by the user later on. Modifying the
Source file is of course trivial, the hard part is making the
modification count given that at the time the request for the Sources
file is made you have no idea what (if any) source package the user will
request in 10 seconds/days following this 'apt-get update' (or
equivalent) – if the user isn't on to you given that you have thrown
away the signatures for binary packages, too, so that he can't even get
his build-dependencies without saying yes to a (default: no) warning.

From a theoretical standpoint, this is of course all negligible, but in
practice it's so annoying/fragile that way better alternatives exist.
(Me messing up InRelease parsing [twice] for example with ironically far
less coverage - its all about catchy titles I guess)


Best regards

David Kalnischkies

[signature.asc (application/pgp-signature, inline)]

---

Message #136 received at 749795@bugs.debian.org (full text, mbox, reply):

On Mon, Jun 16, 2014 at 11:18:27AM +0200, Jakub Wilk wrote:
> * Michael Vogt <mvo@debian.org>, 2014-06-16, 09:35:
> >+   _error->Warning(_("The data from '%s' is not signed. All packages from "
> >+                     "that repository can not be authenticated."),
> 
> s/can not/cannot/
> 
> Also, "All" with a negated verb sounds awkward to me (but that may
> be due to my non-native-englishness). How about:
> 
> "No packages from that repository can be authenticated."
> 
> or simply
> 
> "Packages from that repository cannot be authenticated."
> 
> ?

I like the second string, I updated my branch. Thanks!

Cheers,
 Michael

---

Send a report that this bug log contains spam.

---

Debian bug tracking system administrator <owner@bugs.debian.org>. Last modified: Wed Jun 19 15:05:44 2019; Machine Name: buxtehude

Debian Bug tracking system

Debbugs is free software and licensed under the terms of the GNU Public License version 2. The current version can be obtained from https://bugs.debian.org/debbugs-source/.

Copyright © 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson, 2005-2017 Don Armstrong, and many other contributors.