Debian and Ubuntu have issued advisories today (April 28):
The issue is fixed upstream in 1.17.8.
Mageia 3 and Mageia 4 are also affected.
Steps to Reproduce:
I have pushed 1.17.8 into cauldron
MGA4TOO, MGA3TOO =>
Note that a regression in 1.17.8 was fixed in 1.17.9:
Also note that we are not affected by the regression, as it only affects you if your version of the patch package is older than 1.7 (we have 1.7.1 in Mageia 3).
BTW, we still need an update for this CVE for Mageia 3 and Mageia 4.
Fedora has issued an advisory for this on May 12:
They updated to 1.16.14, which also fixes this.
We could update Mageia 4 to the latest version, and Mageia 3 to 1.16.14.
More dpkg CVEs:
Debian has issued an advisory for CVE-2014-3864 and CVE-2014-3865 on June 8:
dpkg updated to 1.17.10 in cauldron and mga4 and to 1.16.15 in mga3.
The packages to test are:
BTW, Bruno, you shouldn't have used the subrel on these packages. We can let it go this time, but you'll need to rebuild the Cauldron package to have a newer release tag than the Mageia 4 update.
Updated dpkg packages fix security vulnerabilities:
Jakub Wilk discovered that dpkg did not correctly parse C-style filename
quoting, allowing for paths to be traversed when unpacking a source package,
leading to the creation of files outside the directory of the source being
Multiple vulnerabilities were discovered in dpkg that allow file modification
through path traversal when unpacking source packages with especially-crafted
patch files (CVE-2014-3864, CVE-2014-3865).
Updated packages in core/updates_testing:
I changed mkrel to 2 in the cauldron version to avoid the issue you rightly mentioned.
as far as understand the linked reports correctly, there might be an poc, but not public, yet?
So I installed dpkg packages:
[root@localhost marc]# rpm -qa | grep -i dpkg
and unpack a deb-file without any issue. Trying to use some other dpkg function as well and everything seems to working.
So adding MGA4-32-OK tag. Please let me know in case you are aware of more specific tests...
tested for MGA4 64bit as well.
Just for clarification (same tests I did for 32bit above):
I've extracted a deb-file with
[root@localhost Downloads]# dpkg -x bash_4.2+dfsg-0.1_i386.deb ./tmp
And I did also a test extracted source file (since vulnerability was discovered by extracting a source file?) the with:
[root@localhost Downloads]# dpkg-source -x bash_4.2+dfsg-0.1.dsc
gpgv: keyblock resource `/root/.gnupg/trustedkeys.gpg': No such file or directory
gpgv: Signature made Sun 30 Dec 2012 02:40:46 AM CET using RSA key ID FDFE09F2
gpgv: Can't check signature: No public key
dpkg-source: warning: failed to verify signature on ./bash_4.2+dfsg-0.1.dsc
dpkg-source: info: extracting bash in bash-4.2+dfsg
dpkg-source: info: unpacking bash_4.2+dfsg.orig.tar.gz
dpkg-source: info: applying bash_4.2+dfsg-0.1.diff.gz
MGA3TOO MGA4-32-OK =>
MGA3TOO MGA4-32-OK MGA4-64-OK
same tests performed for MGA3 32 and 64 bit. Everything is fine.
If tests are sufficient, then please upload the advisory and validating the update.
MGA3TOO MGA4-32-OK MGA4-64-OK =>
MGA3TOO MGA4-32-OK MGA4-64-OK MGA3-32-OK MGA3-64-OK
MGA3TOO MGA4-32-OK MGA4-64-OK MGA3-32-OK MGA3-64-OK =>
MGA3TOO MGA4-32-OK MGA4-64-OK MGA3-32-OK MGA3-64-OK advisory
Yes, this can be validated. Thanks Marc.
Validated, please push dpkg to Mageia 3 and 4 core/updates.