Re: tiff / CVE-2018-18661
Ola Lundqvist <ola@inguza.com> 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# valgrind tiff2bw /tmp/poc /dev/null
==4412== Memcheck, a memory error detector
==4412== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==4412== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==4412== Command: tiff2bw /tmp/poc /dev/null
==4412==
TIFFReadDirectory: Warning, Unknown field with tag 292 (0x124) encountered.
TIFFScanlineSize: Integer arithmetic overflow.
TIFFReadDirectory: Cannot handle zero scanline size.
==4412==
==4412== HEAP SUMMARY:
==4412== in use at exit: 0 bytes in 0 blocks
==4412== total heap usage: 33 allocs, 33 frees, 3,943 bytes allocated
==4412==
==4412== All heap blocks were freed -- no leaks are possible
==4412==
==4412== For counts of detected and suppressed errors, rerun with: -v
==4412== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
(stretch-i386-default)root@silverfish:/tmp/brian/tmpcvxwwflu/build/i386# valgrind -v tiff2bw /tmp/poc /dev/null
==4508== Memcheck, a memory error detector
==4508== Copyright (C) 2002-2015, and GNU GPL'd, by Julian Seward et al.
==4508== Using Valgrind-3.12.0.SVN and LibVEX; rerun with -h for copyright info
==4508== Command: tiff2bw /tmp/poc /dev/null
==4508==
--4508-- Valgrind options:
--4508-- -v
--4508-- Contents of /proc/version:
--4508-- Linux version 4.17.0-0.bpo.3-amd64 (debian-kernel@lists.debian.org) (gcc version 6.3.0 20170516 (Debian 6.3.0-18+deb9u1)) #1 SMP Debian 4.17.17-1~bpo9+1 (2018-08-27)
--4508--
--4508-- Arch and hwcaps: X86, LittleEndian, x86-mmxext-sse1-sse2-sse3-lzcnt
--4508-- Page sizes: currently 4096, max supported 4096
--4508-- Valgrind library directory: /usr/lib/valgrind
--4508-- Reading syms from /usr/bin/tiff2bw
--4508-- Considering /usr/lib/debug/.build-id/fa/2a69bd4b42864c37053e0e1fed86b96a26efe1.debug ..
--4508-- .. build-id is valid
--4508-- Reading syms from /lib/i386-linux-gnu/ld-2.24.so
--4508-- Considering /usr/lib/debug/.build-id/f1/ae5f623e170729016ce9b68a6c98c5aa2f5cd3.debug ..
--4508-- .. build-id is valid
--4508-- Reading syms from /usr/lib/valgrind/memcheck-x86-linux
--4508-- Considering /usr/lib/valgrind/memcheck-x86-linux ..
--4508-- .. CRC mismatch (computed 903ab9f6 wanted c13efb00)
--4508-- Considering /usr/lib/debug/usr/lib/valgrind/memcheck-x86-linux ..
--4508-- .. CRC is valid
--4508-- object doesn't have a dynamic symbol table
--4508-- Scheduler: using generic scheduler lock implementation.
--4508-- Reading suppressions file: /usr/lib/valgrind/default.supp
==4508== embedded gdbserver: reading from /tmp/vgdb-pipe-from-vgdb-to-4508-by-root-on-???
==4508== embedded gdbserver: writing to /tmp/vgdb-pipe-to-vgdb-from-4508-by-root-on-???
==4508== embedded gdbserver: shared mem /tmp/vgdb-pipe-shared-mem-vgdb-4508-by-root-on-???
==4508==
==4508== TO CONTROL THIS PROCESS USING vgdb (which you probably
==4508== don't want to do, unless you know exactly what you're doing,
==4508== or are doing some strange experiment):
==4508== /usr/lib/valgrind/../../bin/vgdb --pid=4508 ...command...
==4508==
==4508== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==4508== /path/to/gdb tiff2bw
==4508== and then give GDB the following command
==4508== target remote | /usr/lib/valgrind/../../bin/vgdb --pid=4508
==4508== --pid is optional if only one valgrind process is running
==4508==
--4508-- REDIR: 0x4019770 (ld-linux.so.2:strlen) redirected to 0x3804a602 (vgPlain_x86_linux_REDIR_FOR_strlen)
--4508-- REDIR: 0x4019480 (ld-linux.so.2:index) redirected to 0x3804a5dd (vgPlain_x86_linux_REDIR_FOR_index)
--4508-- Reading syms from /usr/lib/valgrind/vgpreload_core-x86-linux.so
--4508-- Considering /usr/lib/valgrind/vgpreload_core-x86-linux.so ..
--4508-- .. CRC mismatch (computed a861379f wanted ba578d67)
--4508-- Considering /usr/lib/debug/usr/lib/valgrind/vgpreload_core-x86-linux.so ..
--4508-- .. CRC is valid
--4508-- Reading syms from /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so
--4508-- Considering /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so ..
--4508-- .. CRC mismatch (computed ca0375fa wanted fcf2e5ee)
--4508-- Considering /usr/lib/debug/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so ..
--4508-- .. CRC is valid
==4508== WARNING: new redirection conflicts with existing -- ignoring it
--4508-- old: 0x04019770 (strlen ) R-> (0000.0) 0x3804a602 vgPlain_x86_linux_REDIR_FOR_strlen
--4508-- new: 0x04019770 (strlen ) R-> (2007.0) 0x04831430 strlen
--4508-- Reading syms from /usr/lib/i386-linux-gnu/libtiff.so.5.3.0
--4508-- Considering /usr/lib/debug/.build-id/d6/a2dd9aaee2e7257d491a88f3ff5e17035b3772.debug ..
--4508-- .. build-id is valid
--4508-- Reading syms from /lib/i386-linux-gnu/libc-2.24.so
--4508-- Considering /usr/lib/debug/.build-id/84/b54a647b1e3cfda03461e51afce2354d2c91db.debug ..
--4508-- .. build-id is valid
--4508-- Reading syms from /lib/i386-linux-gnu/liblzma.so.5.2.2
--4508-- object doesn't have a symbol table
--4508-- Reading syms from /usr/lib/i386-linux-gnu/libjbig.so.0
--4508-- object doesn't have a symbol table
--4508-- Reading syms from /usr/lib/i386-linux-gnu/libjpeg.so.62.2.0
--4508-- object doesn't have a symbol table
--4508-- Reading syms from /lib/i386-linux-gnu/libz.so.1.2.8
--4508-- object doesn't have a symbol table
--4508-- Reading syms from /lib/i386-linux-gnu/libm-2.24.so
--4508-- Considering /usr/lib/debug/.build-id/4e/3f88c4c125fd1b94fcbe6bfb0a4c13d7a602d5.debug ..
--4508-- .. build-id is valid
--4508-- Reading syms from /lib/i386-linux-gnu/libdl-2.24.so
--4508-- Considering /usr/lib/debug/.build-id/ba/52e03776c30e3f9d4c626dcce7485989720025.debug ..
--4508-- .. build-id is valid
--4508-- Reading syms from /lib/i386-linux-gnu/libpthread-2.24.so
--4508-- Considering /usr/lib/debug/.build-id/92/356811c5e5204ea6b78765c7442ad66dc0700f.debug ..
--4508-- .. build-id is valid
--4508-- REDIR: 0x4936c00 (libc.so.6:strncasecmp) redirected to 0x48285c0 (_vgnU_ifunc_wrapper)
--4508-- REDIR: 0x493d800 (libc.so.6:memrchr) redirected to 0x48285c0 (_vgnU_ifunc_wrapper)
--4508-- REDIR: 0x49501d0 (libc.so.6:wcslen) redirected to 0x48285c0 (_vgnU_ifunc_wrapper)
--4508-- REDIR: 0x4936d60 (libc.so.6:memcpy) redirected to 0x48285c0 (_vgnU_ifunc_wrapper)
--4508-- REDIR: 0x4936710 (libc.so.6:memset) redirected to 0x48285c0 (_vgnU_ifunc_wrapper)
--4508-- REDIR: 0x49346a0 (libc.so.6:strcmp) redirected to 0x48285c0 (_vgnU_ifunc_wrapper)
--4508-- REDIR: 0x4936640 (libc.so.6:memmove) redirected to 0x48285c0 (_vgnU_ifunc_wrapper)
--4508-- REDIR: 0x4936320 (libc.so.6:bcmp) redirected to 0x48285c0 (_vgnU_ifunc_wrapper)
--4508-- REDIR: 0x4934750 (libc.so.6:strcpy) redirected to 0x48285c0 (_vgnU_ifunc_wrapper)
--4508-- REDIR: 0x49b4500 (libc.so.6:__memcpy_chk) redirected to 0x48285c0 (_vgnU_ifunc_wrapper)
--4508-- REDIR: 0x4934d20 (libc.so.6:strlen) redirected to 0x48285c0 (_vgnU_ifunc_wrapper)
--4508-- REDIR: 0x49388b0 (libc.so.6:rawmemchr) redirected to 0x48285c0 (_vgnU_ifunc_wrapper)
--4508-- REDIR: 0x49344a0 (libc.so.6:index) redirected to 0x48285c0 (_vgnU_ifunc_wrapper)
--4508-- REDIR: 0x4934ea0 (libc.so.6:strncmp) redirected to 0x48285c0 (_vgnU_ifunc_wrapper)
--4508-- REDIR: 0x4935ad0 (libc.so.6:strstr) redirected to 0x4835970 (strstr)
--4508-- REDIR: 0x4934f80 (libc.so.6:__GI_strrchr) redirected to 0x4830e40 (__GI_strrchr)
--4508-- REDIR: 0x4934d60 (libc.so.6:__GI_strlen) redirected to 0x48313b0 (__GI_strlen)
--4508-- REDIR: 0x493daf0 (libc.so.6:__strlen_sse2_bsf) redirected to 0x4831390 (strlen)
--4508-- REDIR: 0x4930b30 (libc.so.6:malloc) redirected to 0x482e210 (malloc)
--4508-- REDIR: 0x49e57e0 (libc.so.6:__memset_sse2) redirected to 0x4834950 (memset)
--4508-- REDIR: 0x493dc20 (libc.so.6:__strcpy_ssse3) redirected to 0x4831470 (strcpy)
--4508-- REDIR: 0x4931160 (libc.so.6:realloc) redirected to 0x48303c0 (realloc)
--4508-- REDIR: 0x49e7e80 (libc.so.6:__memcpy_ssse3) redirected to 0x4832d20 (memcpy)
--4508-- REDIR: 0x49310a0 (libc.so.6:free) redirected to 0x482f3d0 (free)
--4508-- REDIR: 0x4936dd0 (libc.so.6:__GI_memcpy) redirected to 0x4833030 (__GI_memcpy)
--4508-- REDIR: 0x49389c0 (libc.so.6:strchrnul) redirected to 0x48352d0 (strchrnul)
TIFFReadDirectory: Warning, --4508-- REDIR: 0x4936820 (libc.so.6:__GI_mempcpy) redirected to 0x4835500 (__GI_mempcpy)
Unknown field with tag 292 (0x124) encountered.
TIFFScanlineSize: Integer arithmetic overflow.
TIFFReadDirectory: Cannot handle zero scanline size.
==4508==
==4508== HEAP SUMMARY:
==4508== in use at exit: 0 bytes in 0 blocks
==4508== total heap usage: 33 allocs, 33 frees, 3,943 bytes allocated
==4508==
==4508== All heap blocks were freed -- no leaks are possible
==4508==
==4508== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==4508== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
=== cut ===
4kb allocated, nope that doesn't look like the problem.
It puzzles me that I see an additional "Integer arithmetic
overflow". The revelant code is. I believe tmsize_t==tsize_t which is a
signed int32, although I only can see this mentioned in a comment. I
can't find the definition of tsize_t.
=== code ===
tmsize_t
TIFFScanlineSize(TIFF* tif)
{
static const char module[] = "TIFFScanlineSize";
uint64 m;
tmsize_t n;
m=TIFFScanlineSize64(tif);
n=(tmsize_t)m;
if ((uint64)n!=m) {
TIFFErrorExt(tif->tif_clientdata,module,"Integer arithmetic overflow");
n=0;
}
return(n);
}
=== code ===
If tsize_t was int64 or uint64 on some platforms - e.g. Ubuntu - this
might explain some things.
Still looking.
--
Brian May <bam@debian.org>
Reply to: