Re: Wheezy update of ikiwiki?

[Emilio Pozuelo Monfort]

Hi Simon,

On 12/01/17 01:09, Simon McVittie wrote:
> On Wed, 11 Jan 2017 at 01:46:32 +, Simon McVittie wrote:
>> Subsequent manual testing of the fixes for all those revealed some tricky
>> issues in error recovery code paths which I fixed in 3.20170110. We'll
>> see whether that's the final version...
> 
> While preparing the backport of this whole mess for jessie, I found
> another security issue which *is* serious (CVE-2017-0356, an authentication
> bypass).
> 
>> I suspect the diff resulting from all this is going to be larger than the
>> rest of the differences between git.pm in wheezy and git.pm in sid, which
>> makes me very tempted to recommend backporting the entire git.pm from sid
> 
> That is my recommendation, and is what went into jessie-security
> (a DSA should follow soon).
> 
> Here is a rather large patch stack which pulls in all the fixes from
> jessie-security (including autopkgtest support and enough build-dependencies
> to run most of the tests at build-time), plus a couple of unrelated backports
> from jessie to get the tests to pass:
> 
> git clone git://git.ikiwiki.info/ -b debian-wheezy
> http://source.ikiwiki.branchable.com/?p=source.git;a=shortlog;h=refs/heads/debian-wheezy
> 
> It builds for wheezy in sbuild, and passes autopkgtests on a wheezy VM
> if you parachute in pkg-perl-autopkgtest_0.19_all.deb from jessie (sorry,
> making it work without that jessie package is a yak-shave too far). I
> have not installed it on an actual web server because I don't run
> oldstable anywhere, but there is a test for CVE-2017-0356, which passes.
> 
> Alternatively, if you want to abandon the backport approach for this package,
> I expect that the jessie-security version (the debian-jessie branch in the
> same git repository) would work fine in wheezy.
> 
> If you release an updated package for wheezy using git, please let me know
> where I can fetch the git commits (or I'll use git-import-dsc if necessary).

Thanks for preparing the update. I have given it some smoke testing and uploaded
it. My only change is attached as a git-format-patch patch.

Cheers,
Emilio
>From 84e9cf77f0d38ec4e380e696012e2a0e71559b2f Mon Sep 17 00:00:00 2001
From: Emilio Pozuelo Monfort 
Date: Tue, 31 Jan 2017 21:30:01 +0100
Subject: [PATCH] Release to wheezy-security

---
 debian/changelog | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/debian/changelog b/debian/changelog
index 2d0134c49..1f4471a4d 100644
--- a/debian/changelog
+++ b/debian/changelog
@@ -1,5 +1,6 @@
-ikiwiki (3.20120629.2+deb7u2) UNRELEASED; urgency=medium
+ikiwiki (3.20120629.2+deb7u2) wheezy-security; urgency=medium
 
+  [ Simon McVittie ]
   * Security: force CGI::FormBuilder->field to scalar context where
 necessary, avoiding unintended function argument injection
 analogous to CVE-2014-1572.
@@ -54,7 +55,10 @@ ikiwiki (3.20120629.2+deb7u2) UNRELEASED; urgency=medium
 (patch from Lafayette Chamber Singers Webmaster, backported from
 3.20140916)
 
- -- Simon McVittie   Wed, 11 Jan 2017 15:22:38 +
+  [ Emilio Pozuelo Monfort ]
+  * Upload to wheezy-security.
+
+ -- Emilio Pozuelo Monfort   Tue, 31 Jan 2017 19:00:50 +0100
 
 ikiwiki (3.20120629.2+deb7u1) wheezy-security; urgency=medium
 
-- 
2.11.0

Re: Wheezy update of ikiwiki?

[Simon McVittie]

On Wed, 11 Jan 2017 at 01:46:32 +, Simon McVittie wrote:
> Subsequent manual testing of the fixes for all those revealed some tricky
> issues in error recovery code paths which I fixed in 3.20170110. We'll
> see whether that's the final version...

While preparing the backport of this whole mess for jessie, I found
another security issue which *is* serious (CVE-2017-0356, an authentication
bypass).

> I suspect the diff resulting from all this is going to be larger than the
> rest of the differences between git.pm in wheezy and git.pm in sid, which
> makes me very tempted to recommend backporting the entire git.pm from sid

That is my recommendation, and is what went into jessie-security
(a DSA should follow soon).

Here is a rather large patch stack which pulls in all the fixes from
jessie-security (including autopkgtest support and enough build-dependencies
to run most of the tests at build-time), plus a couple of unrelated backports
from jessie to get the tests to pass:

git clone git://git.ikiwiki.info/ -b debian-wheezy
http://source.ikiwiki.branchable.com/?p=source.git;a=shortlog;h=refs/heads/debian-wheezy

It builds for wheezy in sbuild, and passes autopkgtests on a wheezy VM
if you parachute in pkg-perl-autopkgtest_0.19_all.deb from jessie (sorry,
making it work without that jessie package is a yak-shave too far). I
have not installed it on an actual web server because I don't run
oldstable anywhere, but there is a test for CVE-2017-0356, which passes.

Alternatively, if you want to abandon the backport approach for this package,
I expect that the jessie-security version (the debian-jessie branch in the
same git repository) would work fine in wheezy.

If you release an updated package for wheezy using git, please let me know
where I can fetch the git commits (or I'll use git-import-dsc if necessary).

S

Re: Wheezy update of ikiwiki?

[Simon McVittie]

On Fri, 23 Dec 2016 at 23:39:09 +, Simon McVittie wrote:
> On Thu, 22 Dec 2016 at 23:09:38 +0100, Ola Lundqvist wrote:
> > the Debian LTS team would like to fix the security issues which are
> > currently open in the Wheezy version of ikiwiki:
> > https://security-tracker.debian.org/tracker/CVE-2016-10026
> 
> I requested a CVE ID because this is technically a security vulnerability,
> but I don't think it's a particularly urgent one - the circumstances for
> it to be a problem are really quite specific, and if those circumstances
> apply then the unwanted change is necessarily easy to revert.

While testing the first attempt at a fix for CVE-2016-10026 I discovered
that it didn't actually fix jessie (CVE-2016-9645 was allocated for this
incomplete fix), and also discovered an unrelated minor vulnerability
that the automated test happened to expose (CVE-2016-9646). So I'm glad
we didn't rush into preparing something for wheezy that later turned out
to be broken.

Subsequent manual testing of the fixes for all those revealed some tricky
issues in error recovery code paths which I fixed in 3.20170110. We'll
see whether that's the final version...

I suspect the diff resulting from all this is going to be larger than the
rest of the differences between git.pm in wheezy and git.pm in sid, which
makes me very tempted to recommend backporting the entire git.pm from sid
(I think the only thing in there that's incompatible with older ikiwiki
is one call to IkiWiki::cloak(), which didn't exist in wheezy/jessie).
But please don't do so until I've had an opinion from the SRMs
on what they'd accept in jessie - it would be perverse for the version
of ikiwiki in oldstable LTS to have more backporting than the version
in stable.

> Please de-prioritize it while I talk to the security team about
> whether they want to bother releasing a DSA.

As expected, the security team are not interested in releasing a DSA
for this.

> There were some trivial git conflicts when cherry-picking the change
> from master to debian-jessie, so you'll probably want to use my
> cherry-pick to debian-jessie as the basis for backporting:
> 
> http://source.ikiwiki.branchable.com/?p=source.git;a=commit;h=bb5cf4a0940b8fd2750c6175adb15382b84c71e2

This is not sufficient. Please do not use it alone.

S

Re: Wheezy update of ikiwiki?

[Ola Lundqvist]

Hi Simon

Thank you a lot for this information. I have now added a note that you
think we should de-prioritize this one for now.
If you get information from the security team, please let me know.

Generally we do not do LTS uploads unless there is an intention to fix
it in stable.

Best regards

// Ola

On 24 December 2016 at 00:39, Simon McVittie  wrote:
> On Thu, 22 Dec 2016 at 23:09:38 +0100, Ola Lundqvist wrote:
>> the Debian LTS team would like to fix the security issues which are
>> currently open in the Wheezy version of ikiwiki:
>> https://security-tracker.debian.org/tracker/CVE-2016-10026
>
> I requested a CVE ID because this is technically a security vulnerability,
> but I don't think it's a particularly urgent one - the circumstances for
> it to be a problem are really quite specific, and if those circumstances
> apply then the unwanted change is necessarily easy to revert.
>
> Please de-prioritize it while I talk to the security team about
> whether they want to bother releasing a DSA.
>
>> If that workflow is a burden to you, feel free to just prepare an
>> updated source package and send it to debian-lts@lists.debian.org
>> (via a debdiff, or with an URL pointing to the source package,
>> or even with a pointer to your packaging repository), and the members
>> of the LTS team will take care of the rest. Indicate clearly whether you
>> have tested the updated package or not.
>
> I'm going to leave this one to the LTS team.
>
> There were some trivial git conflicts when cherry-picking the change
> from master to debian-jessie, so you'll probably want to use my
> cherry-pick to debian-jessie as the basis for backporting:
>
> http://source.ikiwiki.branchable.com/?p=source.git;a=commit;h=bb5cf4a0940b8fd2750c6175adb15382b84c71e2
>
> There's a manual test for this bug (it's most convenient to test
> using w3m and its support for faking the CGI interface without a
> web server), but I accidentally deleted one of the required files
> due to an overzealous .gitignore, so I'll have to bring that back first.
>
> S
>



-- 
 --- Inguza Technology AB --- MSc in Information Technology 
/  o...@inguza.comFolkebogatan 26\
|  o...@debian.org   654 68 KARLSTAD|
|  http://inguza.com/Mobile: +46 (0)70-332 1551 |
\  gpg/f.p.: 7090 A92B 18FE 7994 0C36 4FE4 18A1 B1CF 0FE5 3DD9  /
 ---

Re: Wheezy update of ikiwiki?

[Simon McVittie]

On Thu, 22 Dec 2016 at 23:09:38 +0100, Ola Lundqvist wrote:
> the Debian LTS team would like to fix the security issues which are
> currently open in the Wheezy version of ikiwiki:
> https://security-tracker.debian.org/tracker/CVE-2016-10026

I requested a CVE ID because this is technically a security vulnerability,
but I don't think it's a particularly urgent one - the circumstances for
it to be a problem are really quite specific, and if those circumstances
apply then the unwanted change is necessarily easy to revert.

Please de-prioritize it while I talk to the security team about
whether they want to bother releasing a DSA.

> If that workflow is a burden to you, feel free to just prepare an
> updated source package and send it to debian-lts@lists.debian.org
> (via a debdiff, or with an URL pointing to the source package,
> or even with a pointer to your packaging repository), and the members
> of the LTS team will take care of the rest. Indicate clearly whether you
> have tested the updated package or not.

I'm going to leave this one to the LTS team.

There were some trivial git conflicts when cherry-picking the change
from master to debian-jessie, so you'll probably want to use my
cherry-pick to debian-jessie as the basis for backporting:

http://source.ikiwiki.branchable.com/?p=source.git;a=commit;h=bb5cf4a0940b8fd2750c6175adb15382b84c71e2

There's a manual test for this bug (it's most convenient to test
using w3m and its support for faking the CGI interface without a
web server), but I accidentally deleted one of the required files
due to an overzealous .gitignore, so I'll have to bring that back first.

S

Wheezy update of ikiwiki?

[Ola Lundqvist]

Hello dear maintainer(s),

the Debian LTS team would like to fix the security issues which are
currently open in the Wheezy version of ikiwiki:
https://security-tracker.debian.org/tracker/CVE-2016-10026

Would you like to take care of this yourself?

If yes, please follow the workflow we have defined here:
https://wiki.debian.org/LTS/Development

If that workflow is a burden to you, feel free to just prepare an
updated source package and send it to debian-lts@lists.debian.org
(via a debdiff, or with an URL pointing to the source package,
or even with a pointer to your packaging repository), and the members
of the LTS team will take care of the rest. Indicate clearly whether you
have tested the updated package or not.

If you don't want to take care of this update, it's not a problem, we
will do our best with your package. Just let us know whether you would
like to review and/or test the updated package before it gets released.

You can also opt-out from receiving future similar emails in your
answer and then the LTS Team will take care of ikiwiki updates
for the LTS releases.

Thank you very much.

Ola Lundqvist,
  on behalf of the Debian LTS team.

PS: A member of the LTS team might start working on this update at
any point in time. You can verify whether someone is registered
on this update in this file:
https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup
-- 
 -- Ola Lundqvist 
/  o...@debian.org   GPG fingerprint  \
|  o...@inguza.com22F2 32C6 B1E0 F4BF 2B26 |
|  http://inguza.com/0A6A 5E90 DCFA 9426 876F /
 -

Re: Wheezy update of ikiwiki?

[Markus Koschany]

Am 10.05.2016 um 00:25 schrieb Simon McVittie:
> On Tue, 10 May 2016 at 00:06:01 +0200, Markus Koschany wrote:
>> Am 09.05.2016 um 23:51 schrieb Simon McVittie:
>>> I've uploaded a second test version, fixing a regression
>>
>> Looks manageable to me. Please go ahead.
> 
> Uploaded. I would appreciate it if someone from the LTS team prepares
> the DLA; it should probably look remarkably similar to DSA-3571.

I'll take care of that.

Cheers,

Markus




signature.asc
Description: OpenPGP digital signature

Re: Wheezy update of ikiwiki?

[Simon McVittie]

On Tue, 10 May 2016 at 00:06:01 +0200, Markus Koschany wrote:
> Am 09.05.2016 um 23:51 schrieb Simon McVittie:
> > I've uploaded a second test version, fixing a regression
> 
> Looks manageable to me. Please go ahead.

Uploaded. I would appreciate it if someone from the LTS team prepares
the DLA; it should probably look remarkably similar to DSA-3571.

S

Re: Wheezy update of ikiwiki?

[Markus Koschany]

Am 09.05.2016 um 23:51 schrieb Simon McVittie:
> On Mon, 09 May 2016 at 20:05:17 +0200, Markus Koschany wrote:
>> Please proceed with the upload to wheezy-security at your leisure.
> 
> I've uploaded a second test version, fixing a regression which I've
> also just fixed in unstable: images with upper-case extensions, such as
> the IMG1234.JPG frequently seen on cameras' FAT filesystems, were not
> accepted. Interdiff attached. Still good to go?
> 
> S

Looks manageable to me. Please go ahead.






signature.asc
Description: OpenPGP digital signature

Re: Wheezy update of ikiwiki?

[Simon McVittie]

On Mon, 09 May 2016 at 20:05:17 +0200, Markus Koschany wrote:
> Please proceed with the upload to wheezy-security at your leisure.

I've uploaded a second test version, fixing a regression which I've
also just fixed in unstable: images with upper-case extensions, such as
the IMG1234.JPG frequently seen on cameras' FAT filesystems, were not
accepted. Interdiff attached. Still good to go?

S
diffstat for ikiwiki-3.20120629.2+deb7u1 ikiwiki-3.20120629.2+deb7u1

 CHANGELOG |7 ---
 IkiWiki/Plugin/img.pm |2 +-
 NEWS  |2 +-
 debian/NEWS   |2 +-
 debian/changelog  |7 ---
 t/img.t   |   12 +---
 6 files changed, 20 insertions(+), 12 deletions(-)

diff -Nru ikiwiki-3.20120629.2+deb7u1/CHANGELOG ikiwiki-3.20120629.2+deb7u1/CHANGELOG
--- ikiwiki-3.20120629.2+deb7u1/CHANGELOG	2016-05-08 16:31:08.0 +0100
+++ ikiwiki-3.20120629.2+deb7u1/CHANGELOG	2016-05-09 22:39:24.0 +0100
@@ -2,14 +2,15 @@
 
   * HTML-escape error messages, in one case avoiding potential cross-site
 scripting (CVE-2016-4561, OVE-20160505-0012)
-  * Update img plugin to version 3.20160506 to mitigate ImageMagick
+  * Update img plugin to version 3.20160509 to mitigate ImageMagick
 vulnerabilities, including remote code execution (CVE-2016-3714):
 - Never convert SVG images to PNG; simply pass them through to the
   browser. This prevents exploitation of any ImageMagick SVG coder
   vulnerabilities. (joeyh)
 - Do not resize image formats other than JPEG, PNG, GIF unless
   specifically configured to do so. This prevents exploitation
-  of any vulnerabilities in less common coders, such as MVG. (smcv)
+  of any vulnerabilities in less common coders, such as MVG.
+  (schmonz, smcv)
 - Do not resize JPEG, PNG, GIF, PDF images if their extensions do
   not match their "magic numbers", because wiki admins might try to
   restrict attachments by extension, but ImageMagick can base its
@@ -29,7 +30,7 @@
 (chrysn, joeyh, schmonz, smcv)
   * debian/tests: add metadata to run the img test as an autopkgtest
 
- -- Simon McVittie   Sun, 08 May 2016 16:30:55 +0100
+ -- Simon McVittie   Mon, 09 May 2016 22:38:35 +0100
 
 ikiwiki (3.20120629.2) wheezy; urgency=medium
 
diff -Nru ikiwiki-3.20120629.2+deb7u1/debian/changelog ikiwiki-3.20120629.2+deb7u1/debian/changelog
--- ikiwiki-3.20120629.2+deb7u1/debian/changelog	2016-05-08 16:31:08.0 +0100
+++ ikiwiki-3.20120629.2+deb7u1/debian/changelog	2016-05-09 22:39:24.0 +0100
@@ -2,14 +2,15 @@
 
   * HTML-escape error messages, in one case avoiding potential cross-site
 scripting (CVE-2016-4561, OVE-20160505-0012)
-  * Update img plugin to version 3.20160506 to mitigate ImageMagick
+  * Update img plugin to version 3.20160509 to mitigate ImageMagick
 vulnerabilities, including remote code execution (CVE-2016-3714):
 - Never convert SVG images to PNG; simply pass them through to the
   browser. This prevents exploitation of any ImageMagick SVG coder
   vulnerabilities. (joeyh)
 - Do not resize image formats other than JPEG, PNG, GIF unless
   specifically configured to do so. This prevents exploitation
-  of any vulnerabilities in less common coders, such as MVG. (smcv)
+  of any vulnerabilities in less common coders, such as MVG.
+  (schmonz, smcv)
 - Do not resize JPEG, PNG, GIF, PDF images if their extensions do
   not match their "magic numbers", because wiki admins might try to
   restrict attachments by extension, but ImageMagick can base its
@@ -29,7 +30,7 @@
 (chrysn, joeyh, schmonz, smcv)
   * debian/tests: add metadata to run the img test as an autopkgtest
 
- -- Simon McVittie   Sun, 08 May 2016 16:30:55 +0100
+ -- Simon McVittie   Mon, 09 May 2016 22:38:35 +0100
 
 ikiwiki (3.20120629.2) wheezy; urgency=medium
 
diff -Nru ikiwiki-3.20120629.2+deb7u1/debian/NEWS ikiwiki-3.20120629.2+deb7u1/debian/NEWS
--- ikiwiki-3.20120629.2+deb7u1/debian/NEWS	2016-05-08 16:31:08.0 +0100
+++ ikiwiki-3.20120629.2+deb7u1/debian/NEWS	2016-05-09 22:39:24.0 +0100
@@ -18,7 +18,7 @@
   can be removed with the new img_allowed_formats setup option.
   See  for more details.
 
- -- Simon McVittie   Sun, 08 May 2016 16:30:55 +0100
+ -- Simon McVittie   Mon, 09 May 2016 22:38:35 +0100
 
 ikiwiki (3.20110122) unstable; urgency=low
 
diff -Nru ikiwiki-3.20120629.2+deb7u1/IkiWiki/Plugin/img.pm ikiwiki-3.20120629.2+deb7u1/IkiWiki/Plugin/img.pm
--- ikiwiki-3.20120629.2+deb7u1/IkiWiki/Plugin/img.pm	2016-05-08 16:31:08.0 +0100
+++ ikiwiki-3.20120629.2+deb7u1/IkiWiki/Plugin/img.pm	2016-05-09 22:39:24.0 +0100
@@ -89,7 +89,7 @@
 	my $extension;
 	my $format;
 
-	if ($base =~ m/\.([a-z0-9]+)$/) {
+	if ($base =~ m/\.([a-z0-9]+)$/is) {
 		$extension = $1;
 	}
 	else {
diff -Nru ikiwiki-3.20120629.2+deb7u1/NEWS ikiwiki-3.20120629.2+deb7u1/NEWS
--- iki

Re: Wheezy update of ikiwiki?

[Markus Koschany]

Am 09.05.2016 um 19:50 schrieb Simon McVittie:
[...]
>> This used to work with the current version in Wheezy. Is this
>> intentional or a regression?
> 
> There was no option of that name in the current version in Wheezy. All
> versions prior to last Friday effectively had the same behaviour as if you
> used
> 
> img_allowed_formats: [everything]
> 
> in the updated version.
> 
> When you tried it, it "worked" in the sense that it was accepted and
> ignored like any other unimplemented setting, exactly as though you
> had written
> 
> permissive format is permissive: 'yes, this'
> 
> in your setup file :-)
> 

OK. True I installed the old version first, then the new version but
then I also used ikiwiki --setup /etc/ikiwiki/auto.setup with the new
one. Makes sense now. :)

Please proceed with the upload to wheezy-security at your leisure.

Markus



signature.asc
Description: OpenPGP digital signature

Re: Wheezy update of ikiwiki?

[Simon McVittie]

On Mon, 09 May 2016 at 19:34:37 +0200, Markus Koschany wrote:
> However when I edit test.setup and edit
> 
> img_allowed_formats: 'png, jpeg'
> 
> because I want to be even more restrictive I get the following error
> message:
> 
> Error: Can't use string ("png, jpeg") as an ARRAY ref while "strict
> refs" in use at /usr/share/perl5/IkiWiki/Plugin/img.pm line 39

It's meant to be a YAML list, you've set it to a string. The correct
syntax is, for example, any of

img_allowed_formats: [png, jpeg]

img_allowed_formats: ["PNG", "JPEG"]

img_allowed_formats:
- png
- jpeg

 describes one form of correct
syntax. I didn't include documentation updates in the wheezy update to keep it
minimal.

> This used to work with the current version in Wheezy. Is this
> intentional or a regression?

There was no option of that name in the current version in Wheezy. All
versions prior to last Friday effectively had the same behaviour as if you
used

img_allowed_formats: [everything]

in the updated version.

When you tried it, it "worked" in the sense that it was accepted and
ignored like any other unimplemented setting, exactly as though you
had written

permissive format is permissive: 'yes, this'

in your setup file :-)

S

Re: Wheezy update of ikiwiki?

[Markus Koschany]

Am 08.05.2016 um 23:58 schrieb Simon McVittie:
[...]
> Note that I haven't done any real-world testing on this version, because
> I haven't run wheezy since around the time jessie was released, and my
> production ikiwiki instances use the latest upstream release from
> jessie-backports. t/img.t passes in autopkgtest and an SVG [[!img]]
> in the documentation still works, though.
[...]

Hi,

thanks for preparing this update. I installed the new version on my
wheezy box, set up a wiki and did some smoke testing.

When I use the default settings the following works as expected and the
image is shown

[[!img test.png]]

However when I edit test.setup and edit

img_allowed_formats: 'png, jpeg'

because I want to be even more restrictive I get the following error
message:

Error: Can't use string ("png, jpeg") as an ARRAY ref while "strict
refs" in use at /usr/share/perl5/IkiWiki/Plugin/img.pm line 39

This used to work with the current version in Wheezy. Is this
intentional or a regression?

The rest looks good to me and I think we can proceed with an upload to
wheezy-security if the error message above is a feature and not a bug.

Regards,

Markus




signature.asc
Description: OpenPGP digital signature

Re: Wheezy update of ikiwiki?

[Simon McVittie]

On Sat, 07 May 2016 at 23:34:12 +0100, Simon McVittie wrote:
> On Sat, 07 May 2016 at 23:36:36 +0200, Markus Koschany wrote:
> > CVE-2016-4561 would be rather easy to fix in Wheezy but if you think the
> > ImageMagick mitigation is even more important, it is certainly possible
> > to fix that too.
> 
> Yes, I do think that. The security team have given me permission to
> upload both changes to jessie-security, so that's in the pipeline now.
> 
> I'll look into preparing a matching wheezy update tomorrow.

Please review and/or test:


(unsigned temporary package for testing, will be signed when ready)

Note that I haven't done any real-world testing on this version, because
I haven't run wheezy since around the time jessie was released, and my
production ikiwiki instances use the latest upstream release from
jessie-backports. t/img.t passes in autopkgtest and an SVG [[!img]]
in the documentation still works, though.

The ImageMagick mitigation involved some re-indentation, so the easiest
version to review is probably ignore-space-change.patch, which is the
result of git diff --ignore-space-change.

Some notes about the debdiff to pre-empt questions that people will
probably have:

* Some diffs appear twice. This is because debdiff dereferences
  symbolic links and compares the content: NEWS and ChangeLog are symlinks
  to equivalents in debian/.

* .gitignore and .gitattributes are in the debdiff because
  old git-buildpackage excluded them, and new git-buildpackage
  doesn't. They should have no practical effect either way, and I don't
  intend to waste time redoing the package to exclude them.

* I backported the entire img plugin because the mitigation
  doesn't merge cleanly onto a 4 year old version, and in my opinion,
  either resolving the conflicts or arbitrarily reverting individual bug
  fixes would have a higher risk of regressions than taking the whole
  thing.  It is now identical to what's in jessie-security, and almost
  identical to what's in sid (an extra commit making img_allowed_formats
  case-insensitive was accidentally left out of 3.20160506 and will be
  in the next release to sid).

* The autopkgtest suite only includes img.t and not the complete
  test suite from sid, because turning the build-time tests into
  as-installed tests post-jessie involved a significant diffstat.

Regards,
S

Re: Wheezy update of ikiwiki?

[Simon McVittie]

On Sat, 07 May 2016 at 23:36:36 +0200, Markus Koschany wrote:
> You are probably referring to CVE-2016-3714.

Yes, that's the remote code execution flaw. There are also various less
serious flaws discovered around the same time.

> I'm not sure but wouldn't a
> fix for ImageMagick also resolve this for ikiwiki?

It would if we had one, but at the moment we don't.

Based on the nature of the flaw leading to CVE-2016-3714 and the upstream
response to it, I'm also quite confident that this won't be the last
exploitable flaw in ImageMagick. ikiwiki is (at least partially) a wiki,
designed to survive use by untrusted editors, so it's a larger attack
surface than most webapps; the changes I made to mitigate CVE-2016-3714
should hopefully mean we avoid most future ImageMagick vulnerabilities
without further changes.

> CVE-2016-4561 would be rather easy to fix in Wheezy but if you think the
> ImageMagick mitigation is even more important, it is certainly possible
> to fix that too.

Yes, I do think that. The security team have given me permission to
upload both changes to jessie-security, so that's in the pipeline now.

I'll look into preparing a matching wheezy update tomorrow.

S

Re: Wheezy update of ikiwiki?

[Markus Koschany]

Am 07.05.2016 um 22:38 schrieb Simon McVittie:
> On Sat, 07 May 2016 at 20:52:16 +0200, Markus Koschany wrote:
>> the Debian LTS team would like to fix the security issues which are
>> currently open in the Wheezy version of ikiwiki:
>> https://security-tracker.debian.org/tracker/CVE-2016-4561
> 
> I'm well aware of that vulnerability, having discovered it myself.
> 
> I'm currently waiting for feedback from the security team on how they
> want me to deal with the security-related 3.20160506 changes in jessie.
> I found CVE-2016-4561 accidentally while mitigating the recent ImageMagick
> flaws, which I consider to be much more important - CVE-2016-4561 is
> only cross-site scripting (I don't actually know of a specific exploit,
> although it can probably be exploited somehow) whereas the ImageMagick
> flaws are remote arbitrary code execution in some wiki configurations.

You are probably referring to CVE-2016-3714. I'm not sure but wouldn't a
fix for ImageMagick also resolve this for ikiwiki? Or is this another
CVE-worthy issue in ikiwiki?

>> Would you like to take care of this yourself?
> 
> That would probably be best if we're doing the ImageMagick mitigation;
> I had to backport a lot of fixes to the img plugin to get that to
> apply to jessie. It might make most sense to just drop in the entire
> img plugin from jessie, or for that matter a backport of all of
> ikiwiki from jessie.
> 
> I'm not sure how much sense it makes to maintain webapps in LTS by
> backporting individual changes, to be honest.

CVE-2016-4561 would be rather easy to fix in Wheezy but if you think the
ImageMagick mitigation is even more important, it is certainly possible
to fix that too. We usually prefer the same minimal changes as for all
security fixes but depending on the package / webapp in question it does
make sense to consider a backport. Since you are most certainly the one
who knows ikiwiki best, we would leave it to you to make that
assessment. Feel free to send in the debdiff for review or just follow
our procedure that we have outlined at

https://wiki.debian.org/LTS/Development

Thanks for your help

Markus






signature.asc
Description: OpenPGP digital signature

Re: Wheezy update of ikiwiki?

[Simon McVittie]

On Sat, 07 May 2016 at 22:59:49 +0200, Thorsten Alteholz wrote:
> Hi Simon,
> 
> On Sat, 7 May 2016, Simon McVittie wrote:
> > That would probably be best if we're doing the ImageMagick mitigation;
> 
> do you need to change something in ikiwiki to handle the ImageMagick CVEs?

There doesn't seem to be an upstream fix in
ImageMagick that fully addresses the recent CVEs, but
ikiwiki changes can stop them from being exploited that way.

is what I had to backport for my proposed version for jessie (it's less
than it looks like - most of that is the regression test).

> > I'm not sure how much sense it makes to maintain webapps in LTS by
> > backporting individual changes, to be honest.
> 
> The patch for ikiwikis CVE-2016-4561 doesn't look that complicated, so
> wouldn't this single change be better for the users of that version?

If I can prevent ikiwiki from being used to access the ImageMagick flaw
and cause remote arbitrary code execution, it seems desirable to do that.
XSS with no known exploit concerns me a lot less than remote code
execution!

I've asked the security team (again) how they want to handle this.
Whatever they want to do for jessie, I'll look into backporting the same
to wheezy.

S

Re: Wheezy update of ikiwiki?

[Thorsten Alteholz]

Hi Simon,

On Sat, 7 May 2016, Simon McVittie wrote:

That would probably be best if we're doing the ImageMagick mitigation;


do you need to change something in ikiwiki to handle the ImageMagick CVEs?


I'm not sure how much sense it makes to maintain webapps in LTS by
backporting individual changes, to be honest.


The patch for ikiwikis CVE-2016-4561 doesn't look that complicated, so 
wouldn't this single change be better for the users of that version?


  Thorsten

Re: Wheezy update of ikiwiki?

[Simon McVittie]

On Sat, 07 May 2016 at 20:52:16 +0200, Markus Koschany wrote:
> the Debian LTS team would like to fix the security issues which are
> currently open in the Wheezy version of ikiwiki:
> https://security-tracker.debian.org/tracker/CVE-2016-4561

I'm well aware of that vulnerability, having discovered it myself.

I'm currently waiting for feedback from the security team on how they
want me to deal with the security-related 3.20160506 changes in jessie.
I found CVE-2016-4561 accidentally while mitigating the recent ImageMagick
flaws, which I consider to be much more important - CVE-2016-4561 is
only cross-site scripting (I don't actually know of a specific exploit,
although it can probably be exploited somehow) whereas the ImageMagick
flaws are remote arbitrary code execution in some wiki configurations.

> Would you like to take care of this yourself?

That would probably be best if we're doing the ImageMagick mitigation;
I had to backport a lot of fixes to the img plugin to get that to
apply to jessie. It might make most sense to just drop in the entire
img plugin from jessie, or for that matter a backport of all of
ikiwiki from jessie.

I'm not sure how much sense it makes to maintain webapps in LTS by
backporting individual changes, to be honest.

S

Wheezy update of ikiwiki?

[Markus Koschany]

Hello dear maintainer(s),

the Debian LTS team would like to fix the security issues which are
currently open in the Wheezy version of ikiwiki:
https://security-tracker.debian.org/tracker/CVE-2016-4561

Would you like to take care of this yourself?

If yes, please follow the workflow we have defined here:
https://wiki.debian.org/LTS/Development

If that workflow is a burden to you, feel free to just prepare an
updated source package and send it to debian-lts@lists.debian.org
(via a debdiff, or with an URL pointing to the source package,
or even with a pointer to your packaging repository), and the members
of the LTS team will take care of the rest. Indicate clearly whether you
have tested the updated package or not.

If you don't want to take care of this update, it's not a problem, we
will do our best with your package. Just let us know whether you would
like to review and/or test the updated package before it gets released.

Thank you very much.

Markus Koschany,
  on behalf of the Debian LTS team.

PS: A member of the LTS team might start working on this update at
any point in time. You can verify whether someone is registered
on this update in this file:
https://anonscm.debian.org/viewvc/secure-testing/data/dla-needed.txt?view=markup