comments about bugs 2581 and 2587

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

comments about bugs 2581 and 2587

Henri Salo
New security related issue reported in:

http://bugzilla.maptools.org/show_bug.cgi?id=2581

with CVE request in:

http://www.openwall.com/lists/oss-security/2016/11/09/13

Can't reproduce this issue anymore with the latest codebase so maybe this case
can just be closed:

http://bugzilla.maptools.org/show_bug.cgi?id=2587

--
Henri Salo
_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: comments about bugs 2581 and 2587

Even Rouault-2
Le mercredi 09 novembre 2016 18:22:56, Henri Salo a écrit :
> New security related issue reported in:
>
> http://bugzilla.maptools.org/show_bug.cgi?id=2581
>
> with CVE request in:
>
> http://www.openwall.com/lists/oss-security/2016/11/09/13

It looks to me it is an issue with address sanitizer itself that cannot handle
allocation attempts of 17 GB, but when running in normal conditions (and under
Valgrind too), the realloc() fails properly (or might succeed if you have a
huge amout of RAM) properly.
One could discuss if libtiff should do such huge allocations but that's a
tricky subject...

>
> Can't reproduce this issue anymore with the latest codebase so maybe this
> case can just be closed:
>
> http://bugzilla.maptools.org/show_bug.cgi?id=2587

No crash, but Valgrind isn't happy:

==15186== Invalid read of size 8
==15186==    at 0x401E87: cpStrips (tiffsplit.c:246)
==15186==    by 0x401DC2: tiffcp (tiffsplit.c:227)
==15186==    by 0x401066: main (tiffsplit.c:89)
==15186==  Address 0x5f381f8 is 0 bytes after a block of size 8 alloc'd
==15186==    at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==15186==    by 0x4C27522: realloc (vg_replace_malloc.c:525)
==15186==    by 0x4E8DD38: _TIFFrealloc (tif_unix.c:328)
==15186==    by 0x4E35A98: _TIFFCheckRealloc (tif_aux.c:73)
==15186==    by 0x4E35B25: _TIFFCheckMalloc (tif_aux.c:88)
==15186==    by 0x4E4C97E: ChopUpSingleUncompressedStrip (tif_dirread.c:5533)
==15186==    by 0x4E485E9: TIFFReadDirectory (tif_dirread.c:4046)
==15186==    by 0x4E7AF7C: TIFFClientOpen (tif_open.c:466)
==15186==    by 0x4E8DBA2: TIFFFdOpen (tif_unix.c:211)
==15186==    by 0x4E8DCB8: TIFFOpen (tif_unix.c:250)
==15186==    by 0x400F7C: main (tiffsplit.c:71)
==15186==
==15186== Invalid read of size 8
==15186==    at 0x401EEE: cpStrips (tiffsplit.c:252)
==15186==    by 0x401DC2: tiffcp (tiffsplit.c:227)
==15186==    by 0x401066: main (tiffsplit.c:89)
==15186==  Address 0x5f381f8 is 0 bytes after a block of size 8 alloc'd
==15186==    at 0x4C274A8: malloc (vg_replace_malloc.c:236)
==15186==    by 0x4C27522: realloc (vg_replace_malloc.c:525)
==15186==    by 0x4E8DD38: _TIFFrealloc (tif_unix.c:328)
==15186==    by 0x4E35A98: _TIFFCheckRealloc (tif_aux.c:73)
==15186==    by 0x4E35B25: _TIFFCheckMalloc (tif_aux.c:88)
==15186==    by 0x4E4C97E: ChopUpSingleUncompressedStrip (tif_dirread.c:5533)
==15186==    by 0x4E485E9: TIFFReadDirectory (tif_dirread.c:4046)
==15186==    by 0x4E7AF7C: TIFFClientOpen (tif_open.c:466)
==15186==    by 0x4E8DBA2: TIFFFdOpen (tif_unix.c:211)
==15186==    by 0x4E8DCB8: TIFFOpen (tif_unix.c:250)
==15186==    by 0x400F7C: main (tiffsplit.c:71)
==15186==
TIFFReadRawStrip: 1: Strip out of range, max 1.

I've pushed a fix for that.

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: comments about bugs 2581 and 2587

Bob Friesenhahn
On Thu, 10 Nov 2016, Even Rouault wrote:

> Le mercredi 09 novembre 2016 18:22:56, Henri Salo a écrit :
>> New security related issue reported in:
>>
>> http://bugzilla.maptools.org/show_bug.cgi?id=2581
>>
>> with CVE request in:
>>
>> http://www.openwall.com/lists/oss-security/2016/11/09/13
>
> It looks to me it is an issue with address sanitizer itself that cannot handle
> allocation attempts of 17 GB, but when running in normal conditions (and under
> Valgrind too), the realloc() fails properly (or might succeed if you have a
> huge amout of RAM) properly.
> One could discuss if libtiff should do such huge allocations but that's a
> tricky subject...
A common OS (Linux) thinks nothing of allowing huge allocations since
the allocations don't consume actual memory (only virtual memory)
until they are written to.  Other OSs work differently.  Some OSs will
allocate backing store ("swap") for the memory allocations to assure
that the process can page out if it has to.

Bob
--
Bob Friesenhahn
[hidden email], http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: comments about bugs 2581 and 2587

Henri Salo
In reply to this post by Even Rouault-2
On Thu, Nov 10, 2016 at 12:03:54AM +0100, Even Rouault wrote:
> > http://bugzilla.maptools.org/show_bug.cgi?id=2581
>
> It looks to me it is an issue with address sanitizer itself that cannot handle
> allocation attempts of 17 GB, but when running in normal conditions (and under
> Valgrind too), the realloc() fails properly (or might succeed if you have a
> huge amout of RAM) properly.
> One could discuss if libtiff should do such huge allocations but that's a
> tricky subject...

Yeah and my test machine has 24G so no problems allocating 17G :)

--
Henri Salo
_______________________________________________
Tiff mailing list: [hidden email]
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
Loading...