* apt-pkg/acquire-item.cc:

  - remove 'old' InRelease file if we can't get a new one before
    proceeding with Release.gpg to avoid the false impression of a still
    trusted repository by a (still present) old InRelease file.
    Thanks to Simon Ruderich for reporting this issue! (CVE-2012-0214)

Effected are all versions >= 0.8.11

Possible attack summary:
- Attacker needs to find a user which has run at least one successful
 'apt-get update' against an archive providing InRelease files.
- Create a Packages file with his preferred content.
- Attacker then prevents the download of InRelease, Release and
  Release.gpg (alternatively he creates a valid Release file and sends
  this, the other two files need to be missing either way).
- User updates against this, getting the modified Packages file without
  any indication of being unsigned (beside the "Ign InRelease" and
  "Ign Release.gpg" in the output of 'apt-get update').
=> deb files from this source are considered 'trusted' (and therefore the
   user isn't asked for an additional confirmation before install)

1 files changed, 7 insertions, 0 deletions

diff --git a/apt-pkg/acquire-item.cc b/apt-pkg/acquire-item.cc
index 4e6fb7ff9..545a57d37 100644
--- a/apt-pkg/acquire-item.cc
+++ b/apt-pkg/acquire-item.cc
@@ -1598,6 +1598,13 @@ void pkgAcqMetaClearSig::Failed(string Message,pkgAcquire::MethodConfig *Cnf) /*
 {
    if (AuthPass == false)
    {
+      // Remove the 'old' InRelease file if we try Release.gpg now as otherwise
+      // the file will stay around and gives a false-auth impression (CVE-2012-0214)
+      string FinalFile = _config->FindDir("Dir::State::lists");
+      FinalFile.append(URItoFileName(RealURI));
+      if (FileExists(FinalFile))
+	 unlink(FinalFile.c_str());
+
       new pkgAcqMetaSig(Owner,
 			MetaSigURI, MetaSigURIDesc, MetaSigShortDesc,
 			MetaIndexURI, MetaIndexURIDesc, MetaIndexShortDesc,