Re: nagios3 spurious backport?
Hi Antoine, Am 16.12.2016 um 15:15 schrieb Antoine Beaupré: > I am looking at recent nagios3 vulnerabilities and I can't make sense of > this: > > nagios3 (3.4.1-3+deb7u1) wheezy; urgency=low > > [...] > > -- Jonas Meurer Fri, 01 Nov 2013 14:32:18 +0100 > > https://tracker.debian.org/media/packages/n/nagios3/changelog-3.4.1-5~bpo7%2B1 > > nagios3 (3.4.1-5~bpo7+1) wheezy-backports; urgency=low > > * Backport for wheezy. > > -- Jonas Meurer Fri, 01 Nov 2013 11:59:02 +0100 > > https://tracker.debian.org/media/packages/n/nagios3/changelog-3.4.1-3%2Bdeb7u1 > > Why did you upload almost identical versions of nagios3 to > wheezy-backports *and* wheezy at the time? I agree that this doesn't make sense without context. Reason for both uploads was to fix CVE-2013-2214 in wheezy. I remember that back then I was unsure whether an upload to wheezy would have been accepted by the stable release managers after it got rejected by the security team.[1] Thus I first did the backport in order to have a fixed version available for wheezy at all. Shortly after, I got the approval by the stable release managers to go for the 3.4.1-3+deb7u1 upload to wheezy. [1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=714171 > It will make updating this for the security issues much harder than it > should be. > > Could you arrange for the backport to be updated or removed? I see that the current situation with a higher nagios3 version in backports than in wheezy-security is not very nice. I'll ping the backports ftpmasters and ask for removal of nagios3 from wheezy-backports. Cheers, jonas signature.asc Description: OpenPGP digital signature
Re: nagios3 spurious backport?
On 2016-12-18 10:05:48, Jonas Meurer wrote: > I see that the current situation with a higher nagios3 version in > backports than in wheezy-security is not very nice. I'll ping the > backports ftpmasters and ask for removal of nagios3 from wheezy-backports. Actually, after talking with an ftpmaster on IRC, he has made me realize that removing the package from -backports will not actually serve our purpose, because users will not upgrade to the wheezy-security version, as it has a lower version. The proper fix would be to upload a new backport from stretch or, failing that, ship the patches from wheezy-security into the backport. I don't think we can safely update the wheezy-security version to the backport as there are what seems to me to be API-breaking changes between -3 and -5... I haven't reviewed the patch, but those changes seemed problematic: * [8b23685] Remove obsolete webapps configuration (Closes: #714707, #714258) * [6abb302] Cleanup password handling * [e4a9bf7] Fix password handling * [c14f6cf] Deprecate Nagios1 compatible Nagios configuration * [abe9bc9] Update web specific packaging for apache 2.4 A. -- C'est trop facile quand les guerres sont finies D'aller gueuler que c'était la dernière Amis bourgeois vous me faites envie Ne voyez vous pas donc point vos cimetières? - Jaques Brel
Re: unrealize mechanism in 9pfs
Hi Guido, > We don't have virtfs-proxy-helper in wheezy so I think we don't need > support the "proxy" case. > > As for "handle" did you check that it works in Wheezy including unplug? > If so please let me know and we can have a closer look. > > I've only used "local" so far which does not seem to be affected by the > CVEs. Hum, I wasn't excepting that. I did a quick test and it looks like handle is not working either. I get "fsdriver handle not found". Should I throw out my work and mark them unaffected ? Could you test on your machine ? I find it weird that both proxy and handle fsdrivers are present but not working. Cheers, Hugo -- Hugo Lefeuvre (hle)|www.owl.eu.com 4096/ ACB7 B67F 197F 9B32 1533 431C AC90 AC3E C524 065E signature.asc Description: PGP signature
Wheezy update of dcmtk?
Hello dear maintainer(s), the Debian LTS team would like to fix the security issues which are currently open in the Wheezy version of dcmtk: https://security-tracker.debian.org/tracker/CVE-2015-8979 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 dcmtk updates for the LTS releases. 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
Re: unrealize mechanism in 9pfs
On Sun, Dec 18, 2016 at 09:55:55PM +0100, Hugo Lefeuvre wrote: > Hi Guido, > > > We don't have virtfs-proxy-helper in wheezy so I think we don't need > > support the "proxy" case. > > > > As for "handle" did you check that it works in Wheezy including unplug? > > If so please let me know and we can have a closer look. > > > > I've only used "local" so far which does not seem to be affected by the > > CVEs. > > Hum, I wasn't excepting that. I did a quick test and it looks like handle > is not working either. I get "fsdriver handle not found". > > Should I throw out my work and mark them unaffected ? Could you test on > your machine ? Could you paste the commands / libvirt configs you used to test this? -- Guido
Re: Wheezy update of dcmtk?
Hi Markus, thanks for your work on LTS which I consider quite important. On Sun, Dec 18, 2016 at 10:47:05PM +0100, Markus Koschany wrote: > Hello dear maintainer(s), > > the Debian LTS team would like to fix the security issues which are > currently open in the Wheezy version of dcmtk: > https://security-tracker.debian.org/tracker/CVE-2015-8979 > > Would you like to take care of this yourself? I personally feel not capable to do so and Mathieu left the team - so I would be astonished (but definitely happy!) if he would step in for this task. If you do not receive a positive response from Gert I doubt that anybody else from the team would take over. Kind regards and thanks again Andreas. -- http://fam-tille.de
using existing workflows?
In working with the ImageMagick package, I noticed that the maintainer uses gitpkg's debian/source/git-patches system to factor in upstream patches in Debian. We haven't used this so far in the wheezy upload so I kept working that way, especially since i'm not very familiar with that system. I do wonder, however, if we should respect existing systems like this, especially in the case (like here) where the package is under collab-maint. Are we expected to learn the package-specific workflows like those when maintaining packages in LTS? I had a similar situation with the Nagios3 package where I lost precious time re-learning dpatch, to my horror. I wonder if it wouldn't have been simpler to just convert that thing to quilt, especially since the maintainer did exactly that in jessie. Since the previous LTS upload kept using dpatch, I plowed on with a horrible hack (yay: rm in a dpatch script!), but I did wonder if i would have saved time just doing the conversion. We often stumble upon a surprising variety of software out there. While I can grok a lot of programming languages and toolchains, one has to wonder how many of those we can efficiently keep in our heads at once. :) A. -- The university must paint itself black, mulatto, worker anddd peasant. If not, people will break down their doors and paint the university the color they like. - Ernesto "Che" Guevara
imagemagick security update ready for testing
TL;DR: please test and review: https://people.debian.org/~anarcat/debian/wheezy-lts diff -Nru imagemagick-6.7.7.10/debian/changelog imagemagick-6.7.7.10/debian/changelog --- imagemagick-6.7.7.10/debian/changelog 2016-12-11 00:57:24.0 -0500 +++ imagemagick-6.7.7.10/debian/changelog 2016-12-18 17:35:45.0 -0500 @@ -1,3 +1,28 @@ +imagemagick (8:6.7.7.10-5+deb7u10) UNRELEASED; urgency=high + + * Non-maintainer upload by the LTS Security Team. + * mogrify global buffer overflow (CVE-2016-7799) (Closes: #840437) + * mogrify use after free (CVE-2016-7906) (Closes: #840435) + * memory allocate failure in AcquireQuantumPixels (CVE-2016-8677) (Closes: #845206) + * ImageMagick Convert Tiff Adobe Deflate Code Execution +Vulnerability (CVE-2016-8707) (Closes: #848139) + * memory allocation failure in AcquireMagickMemory (CVE-2016-8862, CVE-2016-8866) (Closes: #845634) + * Heap buffer overflow in heap-buffer-overflow in IsPixelGray (CVE-2016-9556) (Closes: #845242) + * null pointer passed as argument 2, which is declared to never be null (CVE-2016-9559) (Closes: #845243) + * TIFF file buffer overflow (Closes: #845195) + * Check return of write function (Closes: #845196) + * Check validity of extend during TIFF file reading (Closes: #845198) + * Better check for bufferoverflow for TIFF handling (Closes: #845202) + * Fix out of bound read in viff file handling (Closes: #845212) + * 0161-Do-not-ignore-SetImageBias-bias-value.patch: DOS fix? +Do not ignore SetImageBias() bias value (undocumented patch from Jessie) + * Suspend exception processing if there are too many exceptions (Closes: #845213) + * Prevent fault in MSL interpreter (Closes: #845241) + * Add check for invalid mat file (Closes: #845244) + * mat file out of bound (Closes: #845246) + + -- Antoine Beaupré Fri, 16 Dec 2016 16:10:35 -0500 + imagemagick (8:6.7.7.10-5+deb7u9) wheezy-security; urgency=high * Non-maintainer upload by the LTS Team diff -Nru imagemagick-6.7.7.10/debian/patches/0125-CVE-2016-7799.patch imagemagick-6.7.7.10/debian/patches/0125-CVE-2016-7799.patch --- imagemagick-6.7.7.10/debian/patches/0125-CVE-2016-7799.patch 1969-12-31 19:00:00.0 -0500 +++ imagemagick-6.7.7.10/debian/patches/0125-CVE-2016-7799.patch 2016-12-18 15:55:49.0 -0500 @@ -0,0 +1,20 @@ +From a7bb158b7bedd1449a34432feb3a67c8f1873bfa Mon Sep 17 00:00:00 2001 +From: Cristy +Date: Fri, 30 Sep 2016 15:19:06 -0400 +Subject: [PATCH] https://github.com/ImageMagick/ImageMagick/issues/280 + +--- + MagickCore/profile.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/magick/profile.c b/magick/profile.c +@@ -1581,7 +1581,7 @@ MagickExport MagickBooleanType SyncImage + (void) AddValueToSplayTree(exif_resources,q,q); + tag_value=(ssize_t) ReadProfileShort(endian,q); + format=(ssize_t) ReadProfileShort(endian,q+2); +- if ((format-1) >= EXIF_NUM_FORMATS) ++ if ((format < 0) || ((format-1) >= EXIF_NUM_FORMATS)) + break; + components=(ssize_t) ReadProfileLong(endian,q+4); + if (components < 0) diff -Nru imagemagick-6.7.7.10/debian/patches/0126-CVE-2016-7906.patch imagemagick-6.7.7.10/debian/patches/0126-CVE-2016-7906.patch --- imagemagick-6.7.7.10/debian/patches/0126-CVE-2016-7906.patch 1969-12-31 19:00:00.0 -0500 +++ imagemagick-6.7.7.10/debian/patches/0126-CVE-2016-7906.patch 2016-12-18 15:55:49.0 -0500 @@ -0,0 +1,19 @@ +From d63a3c5729df59f183e9e110d5d8385d17caaad0 Mon Sep 17 00:00:00 2001 +From: Cristy +Date: Sat, 1 Oct 2016 11:16:55 -0400 +Subject: [PATCH] https://github.com/ImageMagick/ImageMagick/issues/281 + +--- + magick/attribute.c | 2 +- + 1 file changed, 1 insertion(+), 1 deletion(-) + +--- a/magick/attribute.c b/magick/attribute.c +@@ -1175,6 +1175,7 @@ MagickExport MagickBooleanType SetImageT + status=QuantizeImage(quantize_info,image); + quantize_info=DestroyQuantizeInfo(quantize_info); + } ++ status=AcquireImageColormap(image,2); + image->matte=MagickFalse; + break; + } diff -Nru imagemagick-6.7.7.10/debian/patches/0127-CVE-2016-8677.patch imagemagick-6.7.7.10/debian/patches/0127-CVE-2016-8677.patch --- imagemagick-6.7.7.10/debian/patches/0127-CVE-2016-8677.patch 1969-12-31 19:00:00.0 -0500 +++ imagemagick-6.7.7.10/debian/patches/0127-CVE-2016-8677.patch 2016-12-18 15:55:49.0 -0500 @@ -0,0 +1,21 @@ +From 524349d2b3fed7fa0e53de2c908458474eb24418 Mon Sep 17 00:00:00 2001 +From: Cristy +Date: Thu, 15 Sep 2016 20:26:36 -0400 +Subject: [PATCH] https://github.com/ImageMagick/ImageMagick/issues/268 + +--- + coders/tiff.c | 131 +- + 1 file changed, 65 insertions(+), 66 deletions(-) + +--- a/coders/tiff.c b/coders/tiff.c +@@ -1678,7 +1678,8 @@ static Image *ReadTIFFImage(const ImageI + } + SetQuantumImageType(image,quantum_type); + next_tiff_frame: +-quantum_info=DestroyQuantumInfo(quantum_info)
Re: phpmyadmin / CVE-2016-9861 / PMASA-2016-66
Antoine Beaupré writes: >> +--- a/url.php >> b/url.php >> ++// JavaScript redirection is necessary. Because if header() is used >> ++// then web browser sometimes does not change the HTTP_REFERER >> ++// field and so with old URL as Referer, token also goes to >> ++// external site. > > I haven't reviewed the whole code - but this actually works? Doesn't > this assume the token isn't passed to the url.php file? I am still a bit unclear in the CVE-2016-4412 / PMASA-2016-57 vulnerability. Ok, so lets say the vulnerability is in the HTTP_REFERER having the token. In which case, if this JavaScript redirection successfully hides the HTTP_REFERER header, there is no need for a whitelist. I am guessing the JavaScript isn't reliable. Or doesn't work on alll browsers. I will conduct some more tests. -- Brian May
Re: phpmyadmin / CVE-2016-9861 / PMASA-2016-66
Brian May writes: > I am still a bit unclear in the CVE-2016-4412 / PMASA-2016-57 > vulnerability. Ok, so lets say the vulnerability is in the HTTP_REFERER > having the token. Curiously while I can reproduce this in Firefox, I can't under Chrome, as it doesn't seem to provide the Referer header in this situation. -- Brian May
Re: phpmyadmin / CVE-2016-9861 / PMASA-2016-66
Brian May writes: > Curiously while I can reproduce this in Firefox, I can't under Chrome, > as it doesn't seem to provide the Referer header in this situation. It looks like replacing the HTTP header with a block of JavaScript code really does hide the Referer header in Firefox ESR version 45.5.1esr-1. Ok, I wasn't exactly expecting that. So my guess is that the white list only required for certain browsers, or older browsers or something. -- Brian May
Re: Wheezy update of dcmtk?
Hello Markus, Am Sonntag, den 18.12.2016, 23:46 +0100 schrieb Andreas Tille: > Hi Markus, > > thanks for your work on LTS which I consider quite important. > > On Sun, Dec 18, 2016 at 10:47:05PM +0100, Markus Koschany wrote: > > > > Hello dear maintainer(s), > > > > the Debian LTS team would like to fix the security issues which are > > currently open in the Wheezy version of dcmtk: > > https://security-tracker.debian.org/tracker/CVE-2015-8979 > > > > Would you like to take care of this yourself? I would do it, but not before the beginning of next year. best, Gert
