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 s
.. 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
> +i
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
> +++ tiff-
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:
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
/ o...
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 ===
(stretch-i386-default)root@silverfish:/tmp/brian/tmpcvxwwflu/build/i386#
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
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 o
Ola Lundqvist writes:
> Could it be so that the problem is only reproducible on 32-bit
> systems?
Good point. Will try.
--
Brian May
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
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
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
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
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
c
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
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
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 CVE-2018-5
> 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 num
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 t
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;
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 th
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,
Hug
Hi Antoine,
> I see you have the `tiff` package claimed in dla-needed.txt, but not
> `tiff3`. I suspect both are fairly similar issues and that you intended
> to work on both, so I figured it might be better to claim both next
> time.
Right, I will prepare an upload for both packages at the same
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
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 co
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?
Hum,
> 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 - td
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 and 3rd paragraph
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; i++)
i.e. it star
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 set the 4th row?
--
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
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 i
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 td->td_samplesperpi
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 thi
Hi Brian,
I've had a look at your patch, here are some comments.
> 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 f
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
> executed,
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
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
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 tif
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
> > cha
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
> suffici
Raphael Hertzog writes:
>> What does the TIFFReadDirectoryFindFieldInfo function do? What
>> situations is TIFFReadDirectoryFindFieldInfo unsuccessful?
>
> I don't know.
It searches for the field in the tiff file. As I guessed.
Which confused me (and still does), if the field is not there, how
On Thu, 15 Sep 2016, Brian May wrote:
> What does the TIFFReadDirectoryFindFieldInfo function do? What
> situations is TIFFReadDirectoryFindFieldInfo unsuccessful?
I don't know.
> You could perhaps mitigate by requiring an extra parameter that declares
> the number of options you are parsing, how
On Thu, 15 Sep 2016, Brian May wrote:
> 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 the
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 comprehensive list of suc
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...
--
Brian May
Hi Brian,
On Wed, Sep 14, 2016 at 08:26:06AM +1000, 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
Minor comment: if you are sure that those are duplicates you might try
to
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 w
48 matches
Mail list logo
