Created an attachment (id=740) [details]
a report and a poc of this issue

I tested the CVS of libtiff(https://github.com/vadz/libtiff) and the
Segmentation Fault is still existed.

#########################
gdb-peda$ run
'/home/kirito/Desktop/fuzz/netpbm/fuzz_0/analysis/crashes_use/000017.tif' 
Starting program: /home/kirito/Desktop/fuzz/netpbm/test_libtiffCVS/tifftopnm
'/home/kirito/Desktop/fuzz/netpbm/fuzz_0/analysis/crashes_use/000017.tif'
TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not
sorted in ascending order.
TIFFReadDirectory: Warning, Unknown field with tag 1301 (0x515) encountered.
TIFFFetchNormalTag: Warning, IO error during reading of "XResolution"; tag
ignored.
TIFFFetchNormalTag: Warning, IO error during reading of "YResolution"; tag
ignored.
_TIFFVSetField:
/home/kirito/Desktop/fuzz/netpbm/fuzz_0/analysis/crashes_use/000017.tif: Null
count for "ICC Profile" (type 7, writecount -3, passcount 1).
tifftopnm: writing PGM file
P5
32800 32
255
tifftopnm: WARNING: This TIFF image has an orientation that most TIFF libraries
converts incorrectly.  Use -byrow to circumvent.

Program received signal SIGSEGV, Segmentation fault.










[----------------------------------registers-----------------------------------]
RAX: 0x7ffff6957c50 --> 0x0 
RBX: 0x400 
RCX: 0x0 
RDX: 0x687000 ('')
RSI: 0x7ffff69abf90 --> 0xff000000ffffffff 
RDI: 0x7fffffffae60 --> 0x666330 --> 0x666768
("/home/kirito/Desktop/fuzz/netpbm/fuzz_0/analysis/crashes_use/000017.tif")
RBP: 0x7fffffffac30 --> 0x7fffffffad10 --> 0x7fffffffad40 --> 0x100400 
RSP: 0x7fffffffac30 --> 0x7fffffffad10 --> 0x7fffffffad40 --> 0x100400 
RIP: 0x7ffff7b77b31 (<putgreytile+78>:    movzx  edx,BYTE PTR [rdx])
R8 : 0x8020 
R9 : 0x20 (' ')
R10: 0x66c010 --> 0x18ff10ff08ff00ff 
R11: 0x10 
R12: 0x20 (' ')
R13: 0x8020 
R14: 0x5 
R15: 0x7ffff65cb010 --> 0x0
EFLAGS: 0x10206 (carry PARITY adjust zero sign trap INTERRUPT direction
overflow)
[-------------------------------------code-------------------------------------]
   0x7ffff7b77b25 <putgreytile+66>:    lea    rdx,[rax+0x4]
   0x7ffff7b77b29 <putgreytile+70>:    mov    QWORD PTR [rbp-0x20],rdx
   0x7ffff7b77b2d <putgreytile+74>:    mov    rdx,QWORD PTR [rbp+0x20]
=> 0x7ffff7b77b31 <putgreytile+78>:    movzx  edx,BYTE PTR [rdx]
   0x7ffff7b77b34 <putgreytile+81>:    movzx  edx,dl
   0x7ffff7b77b37 <putgreytile+84>:    lea    rcx,[rdx*8+0x0]
   0x7ffff7b77b3f <putgreytile+92>:    mov    rdx,QWORD PTR [rbp-0x8]
   0x7ffff7b77b43 <putgreytile+96>:    add    rdx,rcx
[------------------------------------stack-------------------------------------]
0000| 0x7fffffffac30 --> 0x7fffffffad10 --> 0x7fffffffad40 --> 0x100400 
0008| 0x7fffffffac38 --> 0x7ffff7b76c0c (<gtStripContig+962>:    add   
rsp,0x20)
0016| 0x7fffffffac40 --> 0x0 
0024| 0x7fffffffac48 --> 0xfffeffc0 
0032| 0x7fffffffac50 --> 0x687000 ('')
0040| 0x7fffffffac58 --> 0x7ffff7b76b36 (<gtStripContig+748>:    cmp   
rax,0xffffffffffffffff)
0048| 0x7fffffffac60 --> 0x0 
0056| 0x7fffffffac68 --> 0x802000000020 
[------------------------------------------------------------------------------]
Legend: code, data, rodata, value
Stopped reason: SIGSEGV
0x00007ffff7b77b31 in putgreytile (img=0x7fffffffae60, cp=0x7ffff6957c54,
x=0x508f, y=0x1f, w=0x8020, 
    h=0x1c, fromskew=0x0, toskew=0xfffeffc0, pp=0x687000 <error: Cannot access
memory at address 0x687000>)
    at tif_getimage.c:1285
1285            *cp++ = BWmap[*pp][0];
gdb-peda$ bt
#0  0x00007ffff7b77b31 in putgreytile (img=0x7fffffffae60, cp=0x7ffff6957c54,
x=0x508f, y=0x1f, w=0x8020, 
    h=0x1c, fromskew=0x0, toskew=0xfffeffc0, pp=0x687000 <error: Cannot access
memory at address 0x687000>)
    at tif_getimage.c:1285
#1  0x00007ffff7b76c0c in gtStripContig (img=0x7fffffffae60,
raster=0x7ffff65cb010, w=0x8020, h=0x20)
    at tif_getimage.c:961
#2  0x00007ffff7b7579e in TIFFRGBAImageGet (img=0x7fffffffae60,
raster=0x7ffff65cb010, w=0x8020, h=0x20)
    at tif_getimage.c:513
#3  0x000000000040f711 in convertRasterInMemory (statusP=<synthetic pointer>,
verbose=0x0, 
    colormap=0x7fffffffaef0, fillorder=0x1, spp=0x1, bps=0x8, planarconfig=0x1,
photomet=0x1, tif=0x666330, 
    maxval=0xff, pnmOutP=0x7fffffffae10) at tifftopnm.c:1496
#4  convertRaster (verbose=0x0, noflipOk=0x0, flipOk=<optimized out>,
byrow=0x0, colormap=0x7fffffffaef0, 
    fillorder=0x1, maxval=0xff, tiffDir=..., tifP=0x666330,
pnmOutP=0x7fffffffae10) at tifftopnm.c:1530
#5  convertImage (tifP=tifP@entry=0x666330, alphaFileP=alphaFileP@entry=0x0, 
    imageoutFileP=imageoutFileP@entry=0x7ffff7838620 <_IO_2_1_stdout_>,
cmdline=...) at tifftopnm.c:1590
#6  0x000000000040267e in convertIt (cmdline=..., imageoutFile=0x7ffff7838620
<_IO_2_1_stdout_>, 
    alphaFile=0x0, tifP=0x666330) at tifftopnm.c:1616
#7  main (argc=argc@entry=0x2, argv=argv@entry=0x7fffffffe508) at
tifftopnm.c:1659
#8  0x00007ffff7494830 in __libc_start_main (main=0x4020c0 <main>, argc=0x2,
argv=0x7fffffffe508, 
    init=<optimized out>, fini=<optimized out>, rtld_fini=<optimized out>,
stack_end=0x7fffffffe4f8)
    at ../csu/libc-start.c:291
#9  0x0000000000402d99 in _start ()
gdb-peda$

I cannot reproduce on Ubuntu 16.04 with netpbm 10.0-15.3 and libtiff 4.0.6-1 or
libtiff CVS HEAD (post 4.0.7)

I also tried "tiff2rgba 000017.tif out.tif" and it doesn't crash.

In your analysis you mention "Tifftopnm calls this API  with illegal
arguments.". If that's the case, this is a tifftopnm issue. libtiff assumes in
a number of places that it is correctly called .

Created an attachment (id=744) [details]
the tifftopnm of netpbm 10.47.63

(In reply to comment #3)
> I cannot reproduce on Ubuntu 16.04 with netpbm 10.0-15.3 and libtiff 4.0.6-1 or
> libtiff CVS HEAD (post 4.0.7)
> 
> I also tried "tiff2rgba 000017.tif out.tif" and it doesn't crash.
> 
> In your analysis you mention "Tifftopnm calls this API  with illegal
> arguments.". If that's the case, this is a tifftopnm issue. libtiff assumes in
> a number of places that it is correctly called .


I don't understand the mean of "version 10.0-15.3" because netpbm named the
version as  a format like "10.XX.XX" and I tested this version on Ubuntu 16.04
x64 too with the newest release (version 10.47.63)
(https://sourceforge.net/projects/netpbm/files/super_stable/).

You say that it is a issue of tifopnm, but I think an the API should execute
the basic check and report some warning or error instead of causing a
Segmentation Fault during the API call.

I upload a tifftopnm of 10.47.63 that tested on ubuntu 16.04 x64 (with libtiff
CVS HEAD) that I compiled recently and you can test it if you think necessary
:)

kirito@ubuntu:~/Desktop/fuzz$ ./tifftopnm-ori --version
./tifftopnm-ori: /usr/lib/x86_64-linux-gnu/libtiff.so.5: no version information
available (required by ./tifftopnm-ori)
tifftopnm-ori: Using libnetpbm from Netpbm Version: Netpbm 10.47.63
tifftopnm-ori: Compiled Wed Jan  4 18:09:11 CST 2017 by user "kirito"
tifftopnm-ori: BSD defined
tifftopnm-ori: RGB_ENV='RGBDEF'
tifftopnm-ori: RGBENV= 'RGBDEF' (env vbl is unset)

kirito@ubuntu:~/Desktop/fuzz$ uname -a
Linux ubuntu 4.4.0-21-generic #37-Ubuntu SMP Mon Apr 18 18:33:37 UTC 2016
x86_64 x86_64 x86_64 GNU/Linux

kirito@ubuntu:~/Desktop/fuzz$ lsb_release -a
No LSB modules are available.
Distributor ID:    Ubuntu
Description:    Ubuntu 16.04 LTS
Release:    16.04
Codename:    xenial

kirito@ubuntu:~/Desktop/fuzz$ ./tifftopnm-ori ./000017.tif 
./tifftopnm-ori: /usr/lib/x86_64-linux-gnu/libtiff.so.5: no version information
available (required by ./tifftopnm-ori)
TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not
sorted in ascending order.
TIFFReadDirectory: Warning, Unknown field with tag 1301 (0x515) encountered.
TIFFFetchNormalTag: Warning, IO error during reading of "XResolution"; tag
ignored.
TIFFFetchNormalTag: Warning, IO error during reading of "YResolution"; tag
ignored.
_TIFFVSetField: ./000017.tif: Null count for "ICC Profile" (type 7, writecount
-3, passcount 1).
tifftopnm-ori: writing PGM file
P5
32800 32
255
tifftopnm-ori: WARNING: This TIFF image has an orientation that most TIFF
libraries converts incorrectly.  Use -byrow to circumvent.
Segmentation fault (core dumped)

#####gdb infomation
(gdb) run ./000017.tif 
Starting program: /home/kirito/Desktop/fuzz/tifftopnm-ori ./000017.tif
/home/kirito/Desktop/fuzz/tifftopnm-ori:
/usr/lib/x86_64-linux-gnu/libtiff.so.5: no version information available
(required by /home/kirito/Desktop/fuzz/tifftopnm-ori)
TIFFReadDirectoryCheckOrder: Warning, Invalid TIFF directory; tags are not
sorted in ascending order.
TIFFReadDirectory: Warning, Unknown field with tag 1301 (0x515) encountered.
TIFFFetchNormalTag: Warning, IO error during reading of "XResolution"; tag
ignored.
TIFFFetchNormalTag: Warning, IO error during reading of "YResolution"; tag
ignored.
_TIFFVSetField: ./000017.tif: Null count for "ICC Profile" (type 7, writecount
-3, passcount 1).
tifftopnm-ori: writing PGM file
P5
32800 32
255
tifftopnm-ori: WARNING: This TIFF image has an orientation that most TIFF
libraries converts incorrectly.  Use -byrow to circumvent.

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7b77b31 in putgreytile (img=0x7fffffffae10, cp=0x7ffff6957e14,
x=20511, 
    y=31, w=32800, h=28, fromskew=0, toskew=-65600, 
    pp=0x642000 <error: Cannot access memory at address 0x642000>)
    at tif_getimage.c:1285
1285    tif_getimage.c: No such file or directory.
(gdb) bt
#0  0x00007ffff7b77b31 in putgreytile (img=0x7fffffffae10, cp=0x7ffff6957e14,
x=20511, 
    y=31, w=32800, h=28, fromskew=0, toskew=-65600, 
    pp=0x642000 <error: Cannot access memory at address 0x642000>)
    at tif_getimage.c:1285
#1  0x00007ffff7b76c0c in gtStripContig (img=0x7fffffffae10,
raster=0x7ffff65cb010, 
    w=32800, h=32) at tif_getimage.c:961
#2  0x00007ffff7b7579e in TIFFRGBAImageGet (img=0x7fffffffae10,
raster=0x7ffff65cb010, 
    w=32800, h=32) at tif_getimage.c:513
#3  0x0000000000404d6b in convertRasterInMemory (pnmOutP=0x7fffffffb3e0,
maxval=255, 
    tif=0x621300, photomet=1, planarconfig=1, bps=8, spp=1, fillorder=1, 
    colormap=0x7fffffffb430, verbose=0, statusP=0x7fffffffb324) at
tifftopnm.c:1496
#4  0x0000000000404ea4 in convertRaster (pnmOutP=0x7fffffffb3e0, tifP=0x621300, 
    tiffDir=..., maxval=255, fillorder=1, colormap=0x7fffffffb430, byrow=0,
flipOk=1, 
    noflipOk=0, verbose=0) at tifftopnm.c:1530
#5  0x000000000040513f in convertImage (tifP=0x621300, alphaFileP=0x0, 
    imageoutFileP=0x7ffff7838620 <_IO_2_1_stdout_>, cmdline=...) at
tifftopnm.c:1590
#6  0x00000000004051e1 in convertIt (tifP=0x621300, alphaFile=0x0, 
    imageoutFile=0x7ffff7838620 <_IO_2_1_stdout_>, cmdline=...) at
tifftopnm.c:1616
#7  0x0000000000405347 in main (argc=2, argv=0x7fffffffe668) at
tifftopnm.c:1659

Ubuntu 16.04 version:

$ dpkg -l | grep netpbm
ii  libnetpbm10                                   2:10.0-15.3                  
                amd64        Graphics conversion tools shared libraries
ii  netpbm                                        2:10.0-15.3                  
                amd64        Graphics conversion tools between image formats

I can reproduce the issue with your attached tifftopnm-ori, but not with the
one provided with Ubuntu 16.04, so it looks like the issue is in (recent)
tifftopnm without further investigation. If you cannot reproduce with libtiff
utilities, then I'll likely close this issue as a non-libtiff issue.

> I think an the API should execute the basic check and report some warning or error instead of causing a Segmentation Fault during the API call.

This is not always possible and even when possible, there are plenty of
standard examples where this isn't done for various reasons. For example you
can call memcpy() with overlapping buffer ranges: memcpy() could check it, but
it does not.

(In reply to comment #6)
> Ubuntu 16.04 version:
> 
> $ dpkg -l | grep netpbm
> ii  libnetpbm10                                   2:10.0-15.3                  
>                 amd64        Graphics conversion tools shared libraries
> ii  netpbm                                        2:10.0-15.3                  
>                 amd64        Graphics conversion tools between image formats
> 
> I can reproduce the issue with your attached tifftopnm-ori, but not with the
> one provided with Ubuntu 16.04, so it looks like the issue is in (recent)
> tifftopnm without further investigation. If you cannot reproduce with libtiff
> utilities, then I'll likely close this issue as a non-libtiff issue.
> 
> > I think an the API should execute the basic check and report some warning or error instead of causing a Segmentation Fault during the API call.
> 
> This is not always possible and even when possible, there are plenty of
> standard examples where this isn't done for various reasons. For example you
> can call memcpy() with overlapping buffer ranges: memcpy() could check it, but
> it does not.

OK，I understand what your mean now. Although I think I still cannot tell
whether an issues is caused by a lib or the program accurately if I encounter
this situation in the future.
I will report the issues to netpbm group.
Thanks for your work and explaination.

I am the maintainer of Netpbm, at least the version that is demonstrating this
problem: that distributed from Sourceforge.

The Netpbm in Debian/Ubuntu is a fork of Sourceforge Netpbm from 17 years ago
that has been essentially unchanged since then.  The Sourceforge version added
the call to TIFFRGBAImageGet, which is what is failing here, 10 years ago.  So
that explains why Even cannot reproduce the problem with Ubuntu Tifftopnm.

Even, if I read the previous comments correctly, you do have a driver that
reproduces the crash in libtiff, and I presume you can do this with libtiff
code you compiled from your own source code, so can you give some insight into
the cause of the invalid memory reference?

This (TIFFRGBAImageBegin/Get) is such a simple API that I can't see what
Tifftopnm could do to cause libtiff to do an invalid memory access, other than
basic memory corruption or passing bad pointers.  Tifftopnm _does_ pass an
output buffer, but I've double checked, and the buffer does seem to be the
right size.

OK, I downloaded and built netpbm-10.47.63 from sources and could reproduce.

My analyis of the issue is that netpbm calls TIFFRGBAImageGet with width and
height parameters switched because it looks at the TIFF orientation tag and
thinks that TIFFRGBAImageGet will do a transposition. This is related to the
tifftopnm warnBrokenTiffLibrary() and getTiffDimensions() functions.

The man page of TIFFRGBAImageGet mentions: "The generated raster is assumed to
be an array of width times height 32-bit entries, where width must be less than
or equal to the width of the image (height may be any non-zero size)". This
assumption is violated here when switching width and height as the width passed
to TIFFRGBAImageGet becomes 32800 which is greater than the original width of
32.

So I think tifftopnm should use its -byrow code path by default in such
situations as it is unlikely (speaking for myself! facts may contradict)
libtiff behaviour will be changed in the foreseable future to implement image
transposition . If libtiff behaviour were to be changed, then tifftopnm could
test the libtiff version and revert to using TIFFRGBAImageGet for a libtiff
that would implement transposition.

OK, but how does that cause a segmentation violation?

I take the "width must be less than or equal to the width of the image" just to
mean the pixels won't lay out the way you would expect if the width is greater.
 I can't imagine how TIFFRGBAImageGet could end up addressing nonexistent
memory in that case.

Use CVE-2017-5849 for both 2654 and 2655.

http://www.openwall.com/lists/oss-security/2017/02/02/2

Bugzilla is no longer used for tracking libtiff issues. Remaining open tickets,
such as this one, have been migrated to the libtiff GitLab instance at
https://gitlab.com/libtiff/libtiff/issues .

The migrated tickets have their summary prefixed with [BZ#XXXX] where XXXX is
the initial Bugzilla issue number.