[Group.of.nepali.translators] [Bug 1647467] Re: InRelease file splitter treats getline() errors as EOF
This bug was fixed in the package apt - 1.4~beta2 --- apt (1.4~beta2) unstable; urgency=high [ John R. Lenton ] * bash-completion: Only complete understood file paths for install (LP: #1645815) [ Julian Andres Klode ] * SECURITY UPDATE: gpgv: Check for errors when splitting files (CVE-2016-1252) Thanks to Jann Horn, Google Project Zero for reporting the issue (LP: #1647467) * gpgv: Flush the files before checking for errors -- Julian Andres KlodeThu, 08 Dec 2016 15:21:16 +0100 ** Changed in: apt (Ubuntu Zesty) Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1647467 Title: InRelease file splitter treats getline() errors as EOF Status in apt package in Ubuntu: Fix Released Status in apt source package in Trusty: Fix Released Status in apt source package in Xenial: Fix Released Status in apt source package in Yakkety: Fix Released Status in apt source package in Zesty: Fix Released Bug description: We have just been made aware of a security bug upstream that affects the validation of signatures on InRelease file. This bug is to track progress for it. It allows for attacking a repository via MITM attacks, circumventing the signature of the InRelease file. It works by making a call to getline() fail with ENOMEM, which is not documented as an error for that but follows from the fact that getline() can allocate memory. In such a case, apt would treat the first part of the file as a valid release file. = Original bug report = From: Jann Horn To: secur...@debian.org Cc: Date: Mon, 5 Dec 2016 18:33:09 +0100 Subject: apt: repository signing bypass via memory allocation failure == Vulnerability == When apt-get updates a repository that uses an InRelease file (clearsigned Release files), this file is processed as follows: First, the InRelease file is downloaded to disk. In a subprocess running the gpgv helper, "apt-key verify" (with some more arguments) is executed through the following callchain: gpgv.cc:main -> pkgAcqMethod::Run -> GPGVMethod::URIAcquire -> GPGVMethod::VerifyGetSigners -> ExecGPGV ExecGPGV() splits the clearsigned file into payload and signature using SplitClearSignedFile(), calls apt-key on these two files to perform the cryptographic signature verification, then discards the split files and only retains the clearsigned original. SplitClearSignedFile() ignores leading and trailing garbage. Afterwards, in the parent process, the InRelease file has to be loaded again so that its payload can be processed. At this point, the code isn't aware anymore whether the Release file was clearsigned or split-signed, so the file is opened using OpenMaybeClearSignedFile(), which first attempts to parse the file as a clearsigned (InRelease) file and extract the payload, then falls back to treating the file as the file as a split-signed (Release) file if the file format couldn't be recognized. The weakness here is: If an attacker can create an InRelease file that is parsed as a proper split-signed file during signature validation, but then isn't recognized by OpenMaybeClearSignedFile(), the "leading garbage" that was ignored by the signature validation is interpreted as repository metadata, bypassing the signing scheme. It first looks as if it would be impossible to create a file that is recognized as split-signed by ExecGPGV(), but isn't recognized by OpenMaybeClearSignedFile(), because both use the same function, SplitClearSignedFile(), for parsing the file. However, multiple executions of SplitClearSignedFile() on the same data can actually have different non-error results because of a bug. SplitClearSignedFile() uses getline() to parse the input file. A return code of -1, which signals that either EOF or an error occured, is always treated as EOF. The Linux manpage only lists EINVAL (caused by bad arguments) as possible error code, but because the function allocates (nearly) unbounded amounts of memory, it can actually also fail with ENOMEM if it runs out of memory. Therefore, if an attacker can cause the address space in the main apt-get process to be sufficiently constrained to prevent allocation of a large line buffer while the address space of the gpgv helper process is less constrained and permits the allocation of a buffer with the same size, the attacker can use this to fake an end-of-file condition in SplitClearSignedFile() that causes the file to be parsed as a normal Release file. A very crude way to cause such a constraint on a 32-bit machine is based on abusing ASLR. Because ASLR randomizes the address space after each execve(), thereby altering how much contiguous
[Group.of.nepali.translators] [Bug 1647467] Re: InRelease file splitter treats getline() errors as EOF
This bug was fixed in the package apt - 1.0.1ubuntu2.17 --- apt (1.0.1ubuntu2.17) trusty-security; urgency=high * SECURITY UPDATE: gpgv: Check for errors when splitting files (CVE-2016-1252) Thanks to Jann Horn, Google Project Zero for reporting the issue (LP: #1647467) -- Julian Andres KlodeThu, 08 Dec 2016 15:31:29 +0100 ** Changed in: apt (Ubuntu Trusty) Status: New => Fix Released -- You received this bug notification because you are a member of नेपाली भाषा समायोजकहरुको समूह, which is subscribed to Xenial. Matching subscriptions: Ubuntu 16.04 Bugs https://bugs.launchpad.net/bugs/1647467 Title: InRelease file splitter treats getline() errors as EOF Status in apt package in Ubuntu: Fix Committed Status in apt source package in Trusty: Fix Released Status in apt source package in Xenial: Fix Released Status in apt source package in Yakkety: Fix Released Status in apt source package in Zesty: Fix Committed Bug description: We have just been made aware of a security bug upstream that affects the validation of signatures on InRelease file. This bug is to track progress for it. It allows for attacking a repository via MITM attacks, circumventing the signature of the InRelease file. It works by making a call to getline() fail with ENOMEM, which is not documented as an error for that but follows from the fact that getline() can allocate memory. In such a case, apt would treat the first part of the file as a valid release file. = Original bug report = From: Jann Horn To: secur...@debian.org Cc: Date: Mon, 5 Dec 2016 18:33:09 +0100 Subject: apt: repository signing bypass via memory allocation failure == Vulnerability == When apt-get updates a repository that uses an InRelease file (clearsigned Release files), this file is processed as follows: First, the InRelease file is downloaded to disk. In a subprocess running the gpgv helper, "apt-key verify" (with some more arguments) is executed through the following callchain: gpgv.cc:main -> pkgAcqMethod::Run -> GPGVMethod::URIAcquire -> GPGVMethod::VerifyGetSigners -> ExecGPGV ExecGPGV() splits the clearsigned file into payload and signature using SplitClearSignedFile(), calls apt-key on these two files to perform the cryptographic signature verification, then discards the split files and only retains the clearsigned original. SplitClearSignedFile() ignores leading and trailing garbage. Afterwards, in the parent process, the InRelease file has to be loaded again so that its payload can be processed. At this point, the code isn't aware anymore whether the Release file was clearsigned or split-signed, so the file is opened using OpenMaybeClearSignedFile(), which first attempts to parse the file as a clearsigned (InRelease) file and extract the payload, then falls back to treating the file as the file as a split-signed (Release) file if the file format couldn't be recognized. The weakness here is: If an attacker can create an InRelease file that is parsed as a proper split-signed file during signature validation, but then isn't recognized by OpenMaybeClearSignedFile(), the "leading garbage" that was ignored by the signature validation is interpreted as repository metadata, bypassing the signing scheme. It first looks as if it would be impossible to create a file that is recognized as split-signed by ExecGPGV(), but isn't recognized by OpenMaybeClearSignedFile(), because both use the same function, SplitClearSignedFile(), for parsing the file. However, multiple executions of SplitClearSignedFile() on the same data can actually have different non-error results because of a bug. SplitClearSignedFile() uses getline() to parse the input file. A return code of -1, which signals that either EOF or an error occured, is always treated as EOF. The Linux manpage only lists EINVAL (caused by bad arguments) as possible error code, but because the function allocates (nearly) unbounded amounts of memory, it can actually also fail with ENOMEM if it runs out of memory. Therefore, if an attacker can cause the address space in the main apt-get process to be sufficiently constrained to prevent allocation of a large line buffer while the address space of the gpgv helper process is less constrained and permits the allocation of a buffer with the same size, the attacker can use this to fake an end-of-file condition in SplitClearSignedFile() that causes the file to be parsed as a normal Release file. A very crude way to cause such a constraint on a 32-bit machine is based on abusing ASLR. Because ASLR randomizes the address space after each execve(), thereby altering how much contiguous virtual memory is available, an allocation that attempts to use the average available virtual memory should ideally succeed 50% of the time, resulting in an upper limit of