Your message dated Sat, 7 Aug 2010 23:30:12 +0200
with message-id <20100807213012.ga4...@rivendell>
and subject line Re: Bug#592115: apt seems to somehow use ~/.gnupg dir when
checking package integrity which might be used for security attacks
has caused the Debian Bug report #592115,
regarding apt seems to somehow use ~/.gnupg dir when checking package integrity
which might be used for security attacks
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact ow...@bugs.debian.org
immediately.)
--
592115: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=592115
Debian Bug Tracking System
Contact ow...@bugs.debian.org with problems
--- Begin Message ---
Package: apt
Version: 0.7.20.2+lenny2
Severity: grave
Tags: security
Justification: user security hole
Hi.
I found out some strange issue, which IMO might be used for security attacks on
secure-apt:
I've only tested it with "apt-get source", but maybe other actions or aptitude
are also affected
(I guess all that uses the same code).
But even if it's just "source", then the severity is suggested IMO, as any user
expects also the source
package to be "secure" and valid.
1) Running e.g. apt-get source packagename as any user (including root), seems
to create ~/.gnupg
if it does not yet exist.
Why? Shouldn't it only use the keyrings in /etc/apt/ ? And not only the
keyrings, but also all other
stuff, like gpg.conf.
A normal user could have set less secure options in gpg.conf or similar things,
which are not
desired for checking package integrity.
This _might_ be fixed in the current sid version (0.7.25.3) at least the
~/.gnupg seems to be not
created there.
2) When apt checks the package integrity, and if gpg fails for some reason, it
merely gives a warning,
but seems to not fail:
$ apt-get source base-files
Reading package lists... Done
Building dependency tree
Reading state information... Done
Need to get 65,6kB of source archives.
Get:1 http://ftp.de.debian.org lenny/main base-files 5lenny6 (dsc) [978B]
Get:2 http://ftp.de.debian.org lenny/main base-files 5lenny6 (tar) [64,6kB]
Fetched 65,6kB in 0s (585kB/s)
gpg: new configuration file `/home/foo/.gnupg/gpg.conf' created
gpg: WARNING: options in `/home/foo/.gnupg/gpg.conf' are not yet active during
this run
gpg: Signature made 2010-06-18 17:13:42 CEST using RSA key ID 9F1B8B32
gpg: Can't check signature: public key not found
dpkg-source: extracting base-files in base-files-5lenny6
dpkg-source: info: unpacking base-files_5lenny6.tar.gz
$ echo $?
0
It seems as if it simply uses ~/.gnupg.
I guess this is really critical, especially that the exit status is 0.
"Nobody" will notice this, especially in scripted environments.
Therefore the high severity.
Also this _might_ be fixed in the current sid version.
3) Code should be added to make absolutely sure, that whenever gnupg fails for
whatever reason
(even segfaults etc.) package verification fails.
If only /etc/apt is used for secure apt, there should be no big problems, as
only "good" keys should be
ever added there.
But for normal ~/.gnupg dirs, any key could go there, of course even unsigned
ones.
Such unsigned ones can be easily "bad" keys, for example keys that are so large
(bit size), that
gpg simply fails.
Also applies to current sid version, I guess.
Cheers,
Chris.
** Please type your report below this line ***
-- Package-specific info:
-- apt-config dump --
APT "";
APT::Architecture "amd64";
APT::Build-Essential "";
APT::Build-Essential:: "build-essential";
APT::Install-Recommends "1";
APT::Install-Suggests "0";
APT::Acquire "";
APT::Acquire::Translation "environment";
APT::NeverAutoRemove "";
APT::NeverAutoRemove:: "^linux-image.*";
APT::NeverAutoRemove:: "^linux-restricted-modules.*";
Dir "/";
Dir::State "var/lib/apt/";
Dir::State::lists "lists/";
Dir::State::cdroms "cdroms.list";
Dir::State::userstatus "status.user";
Dir::State::status "/var/lib/dpkg/status";
Dir::Cache "var/cache/apt/";
Dir::Cache::archives "archives/";
Dir::Cache::srcpkgcache "srcpkgcache.bin";
Dir::Cache::pkgcache "pkgcache.bin";
Dir::Etc "etc/apt/";
Dir::Etc::sourcelist "sources.list";
Dir::Etc::sourceparts "sources.list.d";
Dir::Etc::vendorlist "vendors.list";
Dir::Etc::vendorparts "vendors.list.d";
Dir::Etc::main "apt.conf";
Dir::Etc::parts "apt.conf.d";
Dir::Etc::preferences "preferences";
Dir::Bin "";
Dir::Bin::methods "/usr/lib/apt/methods";
Dir::Bin::dpkg "/usr/bin/dpkg";
Dir::Log "var/log/apt";
Dir::Log::Terminal "term.log";
DPkg "";
DPkg::Pre-Install-Pkgs "";
DPkg::Pre-Install-Pkgs:: "/usr/sbin/apt-listbugs apt || exit 10";
DPkg::Pre-Install-Pkgs:: "/usr/bin/apt-listchanges --apt || test $? -ne 10";
DPkg::Pre-Install-Pkgs:: "/usr/sbin/dpkg-preconfigure --apt || true";
DPkg::Tools "";
DPkg::Tools::Options "";
DPkg::Tools::Options::/usr/sbin/apt-listbugs "";
DPkg::Tools::Options::/usr/sbin/apt-listbugs::Version "2";
DPkg::Tools::Options::/usr/bin/apt-listchanges "";
DPkg::Tools::Options::/usr/bin/apt-listchanges::Version "2";
DPkg::Post-Invoke "";
DPkg::Post-Invoke:: "if [ -x /usr/bin/debsums ]; then /usr/bin/debsums
--generate=nocheck -sp /var/cache/apt/archives; fi";
DPkg::Post-Invoke:: "if [ -x /usr/bin/rkhunter ] && ( ! grep -q -E
'^DISABLE_TESTS=.*(hashes.*attributes|attributes.*hashes|properties)'
/etc/rkhunter.
-- (no /etc/apt/preferences present) --
-- (/etc/apt/sources.list present, but not submitted) --
-- System Information:
Debian Release: 5.0.5
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 2.6.26-2-amd64 (SMP w/1 CPU core)
Locale: LANG=en_DE.UTF-8, LC_CTYPE=en_DE.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Versions of packages apt depends on:
ii debian-archive-keyring 2009.01.31 GnuPG archive keys of the Debian a
ii libc6 2.7-18lenny4 GNU C Library: Shared libraries
ii libgcc1 1:4.3.2-1.1 GCC support library
ii libstdc++6 4.3.2-1.1 The GNU Standard C++ Library v3
apt recommends no packages.
Versions of packages apt suggests:
pn apt-doc <none> (no description available)
ii aptitude 0.4.11.11-1~lenny1 terminal-based package manager
ii bzip2 1.0.5-1 high-quality block-sorting file co
ii dpkg-dev 1.14.29 Debian package development tools
ii lzma 4.43-14 Compression method of 7z format in
ii python-apt 0.7.7.1+nmu1 Python interface to libapt-pkg
-- no debconf information
--- End Message ---
--- Begin Message ---
Version: 1.15.1
Hello,
On Sat, 07 Aug 2010, Christoph Anton Mitterer wrote:
> On Sat, 2010-08-07 at 21:27 +0200, Julian Andres Klode wrote:
> > As everyone should know, dpkg unpacks the source packages and verifies
> > them using gpg. APT knows that the package is secure, because the source
> > is secure.
> Ah I've missed that this is from the debsig, and not from checking the
> integrity via the Release file etc.
debsig is something else... dpkg-source is verifying the GPG signature in the
.dsc with gpgv.
> Nevertheless,... I still don't understand, why I get that error....
> especially, as I e.g. don't get it for the package gnupg (in contrast to
> base-files).... and I don't get it at all in sid.
Different debian-keyring versions and in one case the key is there and not
in the other case? The signature of an updated source package might use a
key that was not yet created at the time of the former stable release (and
thus is not in the debian-keyring package of that release).
Anyway, there's nothing for dpkg to fix right now. The sid/squeeze version
is using gpgv and not gpg directly so it's no longer creating the .gnupg
directory (and it only uses the trustedkeys.gpg keyring there if the
directory already exists).
The choice to fail or not on unpack when a the signature can't be verified
is controlled by the --require-valid-signature option. That said I don't
think that apt-get source should use that option... there are far too many
cases where it would fail without a good reason (debian-keyring not installed,
old source packages using a key no longer in the current keyring, newer
source packages using a key not in the stable debian-keyring, etc.) and
APT is already trusting the source package implicitly via the signature of
the Release file.
Thus closing the bug with the version that fixed the bug.
Cheers,
--
Raphaël Hertzog ◈ Debian Developer ◈ [Flattr=20693]
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
--- End Message ---
