Re: tiff

2019-02-12 Thread Brian May
Hugo Lefeuvre writes: >> ++if (0x / tilew < spp) { > > I don't really like this patch... it has not been merged yet (the PR has > been closed, so I guess it will never get merged) and looks more like a > hack to me. > > What if tilew * spp = INT_MAX ? > > Then oskew + iskew will

Re: tiff

2019-02-12 Thread Hugo Lefeuvre
.. follow up of 20190212073152.ga2...@behemoth.owl.eu.com.local otherwise tests went fine. one more comment: > + * Non-maintainer upload by the LTS Team. > + * Fix CVE-2018-19210: NULL pointer dereference > +There is a NULL pointer dereference in the TIFFWriteDirectorySec function > +

Re: tiff

2019-02-11 Thread Hugo Lefeuvre
Hi Brian, I am currently testing the update. I already had a look at the patches. > diff -Nru tiff-4.0.3/debian/patches/CVE-2018-12900.patch > tiff-4.0.3/debian/patches/CVE-2018-12900.patch > --- tiff-4.0.3/debian/patches/CVE-2018-12900.patch1970-01-01 > 10:00:00.0 +1000 > +++

Re: tiff

2019-02-10 Thread Hugo Lefeuvre
Hi, > Attached is my proposed patch for tiff in Jessie. I will be able to test the upload with my usual set of test files tomorrow if necessary. > +From d0a842c5dbad2609aed43c701a12ed12461d3405 Mon Sep 17 00:00:00 2001 > +From: Hugo Lefeuvre > +Date: Wed, 21 Nov 2018 18:50:34 +0100 > +Subject:

Re: tiff

2019-02-10 Thread Ola Lundqvist
Hi Brian I made a brief look and I have nothing to complain about. // Ola On Sun, 10 Feb 2019 at 21:55, Brian May wrote: > Hello, > > Attached is my proposed patch for tiff in Jessie. > > Regards > -- > Brian May > -- --- Inguza Technology AB --- MSc in Information Technology /

Re: tiff / CVE-2018-18661

2018-11-15 Thread Brian May
Ola Lundqvist writes: > Could it be so that the problem is only reproducible on 32-bit systems? It also occurred to me that maybe my computer has too much memory to reproduce an "out of memory" error condition: === cut ===

Re: tiff / CVE-2018-18661

2018-11-14 Thread Brian May
Brian May writes: > I can reproduce CVE-2018-19210. Both on wheezy and stretch. Doesn't Me getting distributions confused. I tested on Jessie, and I was able to reproduce the problem. I did not test wheezy. -- Brian May

Re: tiff / CVE-2018-18661

2018-11-14 Thread Brian May
Brian May writes: > Ola Lundqvist writes: > >> Could it be so that the problem is only reproducible on 32-bit >> systems? > > Good point. Will try. Nope. Can't reproduce i386 build on amd64 kernel. I would be rather surprised if choice of kernel mattered. I can reproduce CVE-2018-19210. Both

Re: tiff / CVE-2018-18661

2018-11-14 Thread Brian May
Ola Lundqvist writes: > Could it be so that the problem is only reproducible on 32-bit > systems? Good point. Will try. -- Brian May

Re: tiff / CVE-2018-18661

2018-11-14 Thread Ola Lundqvist
Hi Could it be so that the problem is only reproducible on 32-bit systems? // Ola On Tue, 13 Nov 2018 at 07:30, Brian May wrote: > Ola Lundqvist writes: > > > Interesting. I wonder what the fix do differently in this case. It is a > > little worrying that it exit with a zero return code, but

Re: tiff / CVE-2018-18661

2018-11-12 Thread Brian May
Ola Lundqvist writes: > Interesting. I wonder what the fix do differently in this case. It is a > little worrying that it exit with a zero return code, but maybe not major. > On the other hand, if we cannot reproduce the problem maybe it is not worth > patching... Hmm. I tried to reproduce this

Re: tiff / CVE-2018-18661

2018-11-12 Thread Ola Lundqvist
Hi Brian Interesting. I wonder what the fix do differently in this case. It is a little worrying that it exit with a zero return code, but maybe not major. On the other hand, if we cannot reproduce the problem maybe it is not worth patching... Hmm. // Ola On Mon, 12 Nov 2018 at 07:24, Brian May

Re: tiff / CVE-2018-18661

2018-11-11 Thread Brian May
Ola Lundqvist writes: > Hi Brian > > To me it looks like you have been able to reproduce the problem. You > clearly get different results with and without the patch indicating > that you have in fact triggered the problem. I do not see that you > have run the program using a debugger, so are you

Re: tiff / CVE-2018-18661

2018-11-10 Thread Ola Lundqvist
Hi Brian To me it looks like you have been able to reproduce the problem. You clearly get different results with and without the patch indicating that you have in fact triggered the problem. I do not see that you have run the program using a debugger, so are you sure that you did not end up in a

Re: tiff / CVE-2018-15209

2018-08-31 Thread Antoine Beaupré
On 2018-08-29 12:24:30, Brian May wrote: > Antoine Beaupré writes: > >> Brian, are you sure you're getting those failures in jessie? Which >> architecture? Here my tests were done in a VirtualBox VM using an up to >> date Debian jessie amd64 box. > > My tests were done in a schroot. Not sure if I

Re: tiff / CVE-2018-15209

2018-08-28 Thread Brian May
Antoine Beaupré writes: > Brian, are you sure you're getting those failures in jessie? Which > architecture? Here my tests were done in a VirtualBox VM using an up to > date Debian jessie amd64 box. My tests were done in a schroot. Not sure if I used i386 or amd64 now. -- Brian May

Re: tiff / CVE-2018-15209

2018-08-27 Thread Antoine Beaupré
On 2018-08-14 17:27:29, Brian May wrote: > I have been trying to reproduce this bug (buffer overflow), but instead > I get increasing memory usage until my computer crashes. With versions > from Jessie, Stretch, and Sid. So maybe another security issue? > > I note that CVE-2017-11613 and

Re: tiff: CVE-2018-8905: heap-based buffer overflow in LZWDecodeCompat

2018-05-02 Thread Hugo Lefeuvre
> So, what is the solution ? > > First, change > > TIFFReadScanline(in, buf, row, s) < 0 > > in tools/tiffcp.c to > > TIFFReadScanline(in, buf, row, s) <= 0 > > It is important to understand that 0 is also an error code here. Otherwise, > change error handling in tif_lzw to return negative

Re: tiff: CVE-2018-8905: heap-based buffer overflow in LZWDecodeCompat

2018-04-30 Thread Hugo Lefeuvre
Hi, > It looks like this buffer overflow is the consequence of an earlier buffer > overflow in the GetNextCodeCompat macro: Hum, that was not completely true. But I think I got it now. The buggy sequence is: 1) Initialy oldcodep points to 0x63201890. We get code 0x010c = 268, add it to

Re: tiff: CVE-2018-8905: heap-based buffer overflow in LZWDecodeCompat

2018-04-22 Thread Hugo Lefeuvre
It looks like this buffer overflow is the consequence of an earlier buffer overflow in the GetNextCodeCompat macro: > #define GetNextCodeCompat(sp, bp, code) { \ > nextdata |= (unsigned long) *(bp)++ << nextbits;\ > nextbits += 8;

Re: tiff: CVE-2018-8905: heap-based buffer overflow in LZWDecodeCompat

2018-04-19 Thread Hugo Lefeuvre
Hi, My current understanding of the problem (based on investigations on latest master, but also valid for older versions): The code_t string type is defined as a kind of chained list. Each entry contains: . a pointer to the next string entry . a length field indicating the remaining length of

Re: tiff: CVE-2018-8905: heap-based buffer overflow in LZWDecodeCompat

2018-04-15 Thread Hugo Lefeuvre
Hi, I have successfully reproduced this issue in latest upstream master branch and Buster but couldn't reproduce it neither in Wheezy nor in Jessie or Stretch. I am going to take a closer look, try to prepare a patch and declare Wheezy, Jessie and Stretch unaffected if appropriate. Regards,

Re: tiff updates

2018-04-11 Thread Antoine Beaupré
On 2018-03-22 09:19:31, Hugo Lefeuvre wrote: > * Start working on tiff and tiff3: > > - Investigate, debug/prepare and test patch for CVE-2018-7456 (git master > version). This issue was very long to debug because it required me > to have a good understanding of the TIFF standard which I

Re: tiff / CVE-2018-7456

2018-03-20 Thread Hugo Lefeuvre
Hi, > Thanks for the feedback ! I'll write the remaining part and submit it to > upstream. You can find a first draft in attachment. While it's already a working solution (at least, I think), there's still place for improvements. * I'm not sure that the check it well positioned in the source

Re: tiff / CVE-2018-7456

2018-03-18 Thread Hugo Lefeuvre
Hi Brian, > > So, in fact it may very well be that the size of the TransferFunction table > > is always at most 3 rows and this definition is right. > > Is the code that loads the transfer function safe? Is there any > possibility of tricking the loading function to try and set the 4th row?

Re: tiff / CVE-2018-7456

2018-03-18 Thread Hugo Lefeuvre
> Seems good to me. I would suggest sending a patch upstream, see what > they think. Thanks for the feedback ! I'll write the remaining part and submit it to upstream. > Also I tend to think some some of assertion might be a good idea, > something that aborts if > > (td->td_samplesperpixel -

Re: tiff / CVE-2018-7456

2018-03-17 Thread Brian May
Hugo Lefeuvre writes: > So, after some debugging on CVE-2018-7456, I start to get the feeling to > understand the issue. > > Here are my conclusions for the moment: > > * In any case, the transfer function should not care about other > channels defined by ExtraSamples (see 2nd

Re: tiff / CVE-2018-7456

2018-03-17 Thread Brian May
Hugo Lefeuvre writes: > Sure ? To me it looked like three entries are provided, but the fourth > (td->td_transferfunction[3]) isn't. I was about to write justification for how I was absolutely sure of this. Then I realized the loop is: for (i = 1; i < td->td_samplesperpixel;

Re: tiff / CVE-2018-7456

2018-03-17 Thread Brian May
Hugo Lefeuvre writes: > So, in fact it may very well be that the size of the TransferFunction table > is always at most 3 rows and this definition is right. Is the code that loads the transfer function safe? Is there any possibility of tricking the loading function to try and

Re: tiff / CVE-2018-7456

2018-03-17 Thread Hugo Lefeuvre
So, after some debugging on CVE-2018-7456, I start to get the feeling to understand the issue. Here are my conclusions for the moment: * In any case, the transfer function should not care about other channels defined by ExtraSamples (see 2nd and 3rd paragraphs of TransferFunction entry, page

Re: tiff / CVE-2018-7456

2018-03-16 Thread Hugo Lefeuvre
Hi Brian, > > Under certain conditions, the td->td_transferfunction table might not > > have the excepted size, that is it may not have the excepted number of > > samples per pixel (td->td_samplesperpixel). In this case for example, > > the table is only 3 rows large while td->td_samplesperpixel

Re: tiff / CVE-2018-7456

2018-03-16 Thread Brian May
Hugo Lefeuvre writes: > Under certain conditions, the td->td_transferfunction table might not > have the excepted size, that is it may not have the excepted number of > samples per pixel (td->td_samplesperpixel). In this case for example, > the table is only 3 rows large while

Re: tiff / CVE-2018-7456

2018-03-15 Thread Ben Hutchings
On Thu, 2018-03-15 at 16:55 +0100, Hugo Lefeuvre wrote: [...] > * My understanding of the problem: > > Under certain conditions, the td->td_transferfunction table might not > have the excepted size, that is it may not have the excepted number of > samples per pixel (td->td_samplesperpixel). In

Re: tiff / CVE-2018-7456

2018-03-15 Thread Hugo Lefeuvre
Hi Brian, > I attempted to fix CVE-2018-7456 issue in tiff, for the version in > stretch. My patch is below. But curiously my patch only works if I > enable the commented out call to fprintf or use -O0 instead of the > default -O2 (-O1 also fails). Otherwise the if condition never gets >

Re: tiff and CVE-2016-10095

2017-06-06 Thread Guido Günther
Hi Raphael, On Tue, Jun 06, 2017 at 12:05:14PM +0200, Raphael Hertzog wrote: > Hi, > > On Fri, 02 Jun 2017, Guido Günther wrote: > > > but it's not worth arguing and providing that in jessie might be useful > > > for > > > building building custom tools still. > > > > But then again the fix for

Re: tiff and CVE-2016-10095

2017-06-06 Thread Raphael Hertzog
Hi, On Fri, 02 Jun 2017, Guido Günther wrote: > > but it's not worth arguing and providing that in jessie might be useful for > > building building custom tools still. > > But then again the fix for this should be in Wheezy already as far as I > can tell. Raphael (since you provided the upstream

Re: tiff and CVE-2016-10095

2017-06-02 Thread Salvatore Bonaccorso
Hi Guido, On Fri, Jun 02, 2017 at 12:29:29PM +0200, Guido Günther wrote: > On Fri, Jun 02, 2017 at 11:02:06AM +0200, Moritz Muehlenhoff wrote: > > On Fri, Jun 02, 2017 at 10:25:29AM +0200, Guido Günther wrote: > > > Hi Moritz, > > > I'm trying to figure out the reasoning for @51764. This marks

Re: tiff and CVE-2016-10095

2017-06-02 Thread Guido Günther
On Fri, Jun 02, 2017 at 11:02:06AM +0200, Moritz Muehlenhoff wrote: > On Fri, Jun 02, 2017 at 10:25:29AM +0200, Guido Günther wrote: > > Hi Moritz, > > I'm trying to figure out the reasoning for @51764. This marks tiff as > > affected by CVE-2016-10095. However from the upstream bug and the > >

Re: tiff and CVE-2016-10095

2017-06-02 Thread Moritz Muehlenhoff
On Fri, Jun 02, 2017 at 10:25:29AM +0200, Guido Günther wrote: > Hi Moritz, > I'm trying to figure out the reasoning for @51764. This marks tiff as > affected by CVE-2016-10095. However from the upstream bug and the > changes we made in wheezy it looks like the changes we made already are >

Re: tiff / tiff3 / CVE-2015-7554 / CVE-2016-5318

2016-09-15 Thread Brian May
Raphael Hertzog writes: > I agree on all this but somehow I have the feeling that we can still > do better for example by blacklisting tags that are known to use a single > extension and refusing to handle them as custom > > My problem is that I'm not sure that we have a

Re: tiff / tiff3 / CVE-2015-7554 / CVE-2016-5318

2016-09-15 Thread Brian May
Salvatore Bonaccorso writes: > Minor comment: if you are sure that those are duplicates you might try > to contact MITRE to made them aware. I was just going based on what others have said, e.g. in the linked reports. Would hope that one of them has already contacted MITRE...

Re: tiff / tiff3 / CVE-2015-7554 / CVE-2016-5318

2016-09-14 Thread Raphael Hertzog
Hi, On Wed, 14 Sep 2016, Brian May wrote: > CVE-2015-7554 / http://bugzilla.maptools.org/show_bug.cgi?id=2564 > > Duplicate: > > CVE-2016-5318 / http://bugzilla.maptools.org/show_bug.cgi?id=2561 > > What would be considered an acceptable fix here? It looks like a proper > fix is not available