Bug#746306: dpkg: CVE-2014-0471 fix introduces the vulnerability into squeeze
Here it is the missing file. However, this is not over. exploto_0.1.debian.tar.gz Description: application/compressed-tar smime.p7s Description: S/MIME cryptographic signature
Bug#746306: dpkg: CVE-2014-0471 fix introduces the vulnerability into squeeze
Hi Guillem, On 30 April 2014 01:36, Guillem Jover guil...@debian.org wrote: [...] Attached a non-tested quick patch implementing this. I'll start testing it and preparing packages for all suites. In case you were waiting for an ACK, please go ahead. I'll handle the update soon after they've hit the sec archive. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746306: dpkg: CVE-2014-0471 fix introduces the vulnerability into squeeze
On Wed, 2014-04-30 at 14:45:36 +0200, Raphael Geissert wrote: On 30 April 2014 01:36, Guillem Jover guil...@debian.org wrote: [...] Attached a non-tested quick patch implementing this. I'll start testing it and preparing packages for all suites. In case you were waiting for an ACK, please go ahead. I'll handle the update soon after they've hit the sec archive. Ok thanks, I'm preparing the uploads for squeeze and wheezy right away. The wheezy one contains some translation updates, hope that's fine. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746306: dpkg: CVE-2014-0471 fix introduces the vulnerability into squeeze
Hi, On Mon, 2014-04-28 at 22:35:57 +0200, Javier Serrano Polo wrote: Package: dpkg Version: 1.15.9 Tags: security squeeze As far as I see, escaping file names was added to diffutils in 2012. The feature is not present in a squeeze environment. CVE-2014-0471 does not apply. Directory traversal during unpack is possible now. I will wait one day before releasing an exploit package. Oh, woah, right now I'm either guessing I mixed up my chroots when initially checking the submitted test package, or had the files in /tmp from a previous extraction, otherwise I cannot explain this blunder. :/ I've reproduced this now locally on a squeeze chroot with a test package. In any case, squeeze could be affected by a partial upgrade of patch, so the options I see are: 1. Simply revert the patch, and ignore issues w/ partial upgrades (at least for now?). 2. Revert the patch and add versioned depdendencies against the working patch package. This might require some dist-upgrade tests, though. 3. Fix the patch to take into account the old behaviour, by checking if either of the filenames (escaped and unescaped) are unsafe. I guess the last one is the “safest option”. In any case I'd like input from the security team (CCed just to make sure you get this), and I'm very sorry guys about this. :( I think I could have either option 1 or 3 ready for later today, option 2 would require more consideration and testing. Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746306: dpkg: CVE-2014-0471 fix introduces the vulnerability into squeeze
El dt 29 de 04 de 2014 a les 08:11 +0200, Guillem Jover va escriure: In any case, squeeze could be affected by a partial upgrade of patch, That is true. Since patch is the one doing the job, how about performing a --dry-run first and checking the output? smime.p7s Description: S/MIME cryptographic signature
Bug#746306: dpkg: CVE-2014-0471 fix introduces the vulnerability into squeeze
Hi, On 29 April 2014 08:11, Guillem Jover guil...@debian.org wrote: [...] 2. Revert the patch and add versioned depdendencies against the working patch package. This might require some dist-upgrade tests, though. 3. Fix the patch to take into account the old behaviour, by checking if either of the filenames (escaped and unescaped) are unsafe. I guess the last one is the “safest option”. In any case I'd like input from the security team (CCed just to make sure you get this), and I'm very sorry guys about this. :( This goes both ways: * if using dependencies, they would need to be added to all versions so that e.g. wheezy's dpkg can't be used with squeeze's patch * if handling both behaviors, it should also apply to both releases. Unless I missed something, of course. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746306: dpkg: CVE-2014-0471 fix introduces the vulnerability into squeeze
On 2014-04-29 12:27 +0200, Raphael Geissert wrote: On 29 April 2014 08:11, Guillem Jover guil...@debian.org wrote: [...] 2. Revert the patch and add versioned depdendencies against the working patch package. This might require some dist-upgrade tests, though. 3. Fix the patch to take into account the old behaviour, by checking if either of the filenames (escaped and unescaped) are unsafe. I guess the last one is the “safest option”. In any case I'd like input from the security team (CCed just to make sure you get this), and I'm very sorry guys about this. :( This goes both ways: * if using dependencies, they would need to be added to all versions so that e.g. wheezy's dpkg can't be used with squeeze's patch * if handling both behaviors, it should also apply to both releases. Unless I missed something, of course. Something nobody has mentioned yet: isn't the critical path between wheezy and jessie/sid rather than between squeeze and wheezy? Support for double-quoted filenames was added in patch 2.7, which entered unstable only in June 2013. Cheers, Sven -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746306: dpkg: CVE-2014-0471 fix introduces the vulnerability into squeeze
* Guillem Jover guil...@debian.org, 2014-04-29, 08:11: 1. Simply revert the patch, and ignore issues w/ partial upgrades (at least for now?). 2. Revert the patch and add versioned depdendencies against the working patch package. This might require some dist-upgrade tests, though. 3. Fix the patch to take into account the old behaviour, by checking if either of the filenames (escaped and unescaped) are unsafe. I guess the last one is the “safest option”. For a quick fix, 3 is probably the best. But I think this bug shows that validating diffs is not viable in the long run. We need to either fix patch(1) not to traverse directory symlinks, or implement a completely different strategy: 1) Unpack .orig.tar. 2) Delete all symlinks (and maybe also other non-regular files). 3) Apply patches. 4) Restore all the files deleted in step 2. In another mail Javier suggested to check --dry-run output. I don't think this is feasible. Parsing --dry-run output is probably even harder than parsing patches, and after reading https://savannah.gnu.org/bugs/index.php?37642 I wouldn't trust it to be very dry anyway... -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746306: dpkg: CVE-2014-0471 fix introduces the vulnerability into squeeze
I am giving some hours to the security team, that has asked for a proof of concept. Format: 3.0 (quilt) Source: exploto Version: 0.1 Maintainer: Javier Serrano Polo jav...@jasp.net Standards-Version: 3.9.1 Checksums-Sha1: 6f6e8000c35ad31251693ed8edc4cea71428df7c 121 exploto_0.1.orig.tar.gz d12c6a70a048c42c2bacc062f80b91072447b76f 637 exploto_0.1.debian.tar.gz Checksums-Sha256: 92a4fce2a3bc1f6085cf99d65889776bb703594bebbd3ce5c0e6d26c433c3087 121 exploto_0.1.orig.tar.gz 1147c671aac3a3c14140af8280ad45995b81978ce79ca862f782c751af2de8fd 637 exploto_0.1.debian.tar.gz Files: dae83c0a0865622804b972589e903383 121 exploto_0.1.orig.tar.gz 15ca1f6eefa8fab9c3fdd5160602706a 637 exploto_0.1.debian.tar.gz exploto_0.1.orig.tar.gz Description: application/compressed-tar smime.p7s Description: S/MIME cryptographic signature
Bug#746306: dpkg: CVE-2014-0471 fix introduces the vulnerability into squeeze
On Tue, 2014-04-29 at 18:55:35 +0200, Jakub Wilk wrote: * Guillem Jover guil...@debian.org, 2014-04-29, 08:11: 1. Simply revert the patch, and ignore issues w/ partial upgrades (at least for now?). 2. Revert the patch and add versioned depdendencies against the working patch package. This might require some dist-upgrade tests, though. 3. Fix the patch to take into account the old behaviour, by checking if either of the filenames (escaped and unescaped) are unsafe. I guess the last one is the “safest option”. For a quick fix, 3 is probably the best. Did you mean 1? After having checked to implement 3, there's many parts of the code that need to be changed and moved around, I'll try to cook an actual patch to see how bad it is though. There's also the newly supported git formatted patches now recognized by patch, “fortunately” Dpkg::Source::Patch does not understand them and because it creates any necessary directories (or what looks like one), I don't see a way it can be exploited. But I might be short on imagination at this moment. Also another issue is that independently of partial upgrades, dpkg-dev might be used on other systems where we don't know what patch version is available, so it could be vulnerable or not depending on that. :/ But I think this bug shows that validating diffs is not viable in the long run. We need to either fix patch(1) not to traverse directory symlinks, Yeah, I've to agree with that, the only really safe option here is for patch to not follow any symlinks at all. And that seems to have been partly the intention behind the new default and the option to revert it with --follow-symlinks, but it seems to only apply to the last component. A patch program that follows symlinks also means that extracting a Debian source package manually is unsafe… or implement a completely different strategy: 1) Unpack .orig.tar. 2) Delete all symlinks (and maybe also other non-regular files). 3) Apply patches. 4) Restore all the files deleted in step 2. In another mail Javier suggested to check --dry-run output. I don't think this is feasible. Parsing --dry-run output is probably even harder than parsing patches, Yeah, I don't think parsing --dry-run output is a good idea either, it's not future-proof and prone to break if the output changes. Your proposed solution might be the safer and more future-proof way to deal with the current patch changing behaviour, but it might not cover all future new features (think similar extensions like the git formatted patches). Thanks, Guillem -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746306: dpkg: CVE-2014-0471 fix introduces the vulnerability into squeeze
* Guillem Jover guil...@debian.org, 2014-04-29, 23:40: 1. Simply revert the patch, and ignore issues w/ partial upgrades (at least for now?). 2. Revert the patch and add versioned depdendencies against the working patch package. This might require some dist-upgrade tests, though. 3. Fix the patch to take into account the old behaviour, by checking if either of the filenames (escaped and unescaped) are unsafe. I guess the last one is the “safest option”. For a quick fix, 3 is probably the best. Did you mean 1? After having checked to implement 3, there's many parts of the code that need to be changed and moved around, I'll try to cook an actual patch to see how bad it is though. I had assumed that the patch for 3 would we straightforward. If this is not the case, then I'd go for 1 for now, and maybe we'll figure out something better later. Of course, Security Team's option may vary. There's also the newly supported git formatted patches now recognized by patch, “fortunately” Dpkg::Source::Patch does not understand them and because it creates any necessary directories (or what looks like one), I don't see a way it can be exploited. But I might be short on imagination at this moment. Oh, I completely forgot about git patches. I have a hunch that there's a clever way to exploit them. :\ -- Jakub Wilk -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#746306: dpkg: CVE-2014-0471 fix introduces the vulnerability into squeeze
Hi!
On Wed, 2014-04-30 at 00:12:56 +0200, Jakub Wilk wrote:
* Guillem Jover guil...@debian.org, 2014-04-29, 23:40:
1. Simply revert the patch, and ignore issues w/ partial upgrades (at
least for now?).
2. Revert the patch and add versioned depdendencies against the
working patch package. This might require some dist-upgrade tests,
though.
3. Fix the patch to take into account the old behaviour, by checking
if either of the filenames (escaped and unescaped) are unsafe.
I guess the last one is the “safest option”.
For a quick fix, 3 is probably the best.
Did you mean 1? After having checked to implement 3, there's many parts of
the code that need to be changed and moved around, I'll try to cook an
actual patch to see how bad it is though.
I had assumed that the patch for 3 would we straightforward. If this is not
the case, then I'd go for 1 for now, and maybe we'll figure out something
better later. Of course, Security Team's option may vary.
Well it looks a bit gross, because it might end up generating strange
directories, as those are recorded by the same code analyzing and
deciding if a pathname is safe or not. So if we have to check both
we don't know which one will end up being used by patch and would
need to create them all. :/
And actually, after having pondered about this for a bit, it just
occurred to me that the most strightforward and safe solution of all is
to simply and completely ban C-style strings, which would be option 4.
Because we avoid any discrepancy in behaviour from dpkg-dev and patch,
avoid any strange directory creation side-effects, and works everywhere,
even on systems with old/new or non-GNU patch programs. Also any such
new patches would not extract correctly on old suites anyway. And why
should we support those encoded characters at all, when we've lived
w/o them all this time.
Attached a non-tested quick patch implementing this. I'll start
testing it and preparing packages for all suites.
There's also the newly supported git formatted patches now recognized by
patch, “fortunately” Dpkg::Source::Patch does not understand them and
because it creates any necessary directories (or what looks like one), I
don't see a way it can be exploited. But I might be short on imagination
at this moment.
Oh, I completely forgot about git patches. I have a hunch that there's a
clever way to exploit them. :\
That's what I fear too, but I've been trying to concoct some PoC and
failed.
Thanks,
Guillem
diff --git a/scripts/Dpkg/Source/Patch.pm b/scripts/Dpkg/Source/Patch.pm
index 712e743..2d8fb81 100644
--- a/scripts/Dpkg/Source/Patch.pm
+++ b/scripts/Dpkg/Source/Patch.pm
@@ -332,31 +332,6 @@ sub _getline {
return $line;
}
-my %ESCAPE = ((
-'a' = \a,
-'b' = \b,
-'f' = \f,
-'n' = \n,
-'r' = \r,
-'t' = \t,
-'v' = \cK,
-'\\' = '\\',
-'' = '',
-), (
-map { sprintf('%03o', $_) = chr($_) } (0..255)
-));
-
-sub _unescape {
-my ($diff, $str) = @_;
-
-if (exists $ESCAPE{$str}) {
-return $ESCAPE{$str};
-} else {
-error(_g('diff %s patches file with unknown escape sequence \\%s'),
- $diff, $str);
-}
-}
-
# Fetch the header filename ignoring the optional timestamp
sub _fetch_filename {
my ($diff, $header) = @_;
@@ -366,12 +341,7 @@ sub _fetch_filename {
# Is it a C-style string?
if ($header =~ m/^/) {
-$header =~ m/^((?:[^\\]|\\.)*)/;
-error(_g('diff %s patches file with unbalanced quote'), $diff)
-unless defined $1;
-
-$header = $1;
-$header =~ s/\\([0-3][0-7]{2}|.)/_unescape($diff, $1)/eg;
+error(_g('diff %s patches file using unsupported C-style string'), $diff);
} else {
# Tab is the official separator, it's always used when
# filename contain spaces. Try it first, otherwise strip on space
Bug#746306: dpkg: CVE-2014-0471 fix introduces the vulnerability into squeeze
Package: dpkg Version: 1.15.9 Tags: security squeeze As far as I see, escaping file names was added to diffutils in 2012. The feature is not present in a squeeze environment. CVE-2014-0471 does not apply. Directory traversal during unpack is possible now. I will wait one day before releasing an exploit package. smime.p7s Description: S/MIME cryptographic signature
