[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20161006011255.GB5763@sin.redhat.com>
Date: Thu, 6 Oct 2016 11:42:56 +1030
From: Doran Moppert <dmoppert@...hat.com>
To: Raphael Geissert <geissert@...ian.org>
Cc: Open Source Security <oss-security@...ts.openwall.com>
Subject: CVE request: openjpeg: incorrect fix for CVE-2013-6045 (was Re:
openjpeg CVE-2016-3181, CVE-2016-3182 .. and CVE-2013-6045)
Subject amended to reflect the need for a new CVE.
On Oct 05 2016, Raphael Geissert wrote:
> > http://seclists.org/oss-sec/2013/q4/412
> >
> > segfault-1.patch uses:
> >
> > + tilec->data = (int*) opj_aligned_malloc((comp0size+3) * sizeof(int));
> >
> > which should have used compcsize instead of comp0size.
>
> Yes, indeed. This patch also introduced a regression in the processing
> of some images.
> Cf. https://bugs.debian.org/734238
Thanks for the reference. The corrected patch attached to
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=734238#53 agrees with
my analysis.
> Do you specifically know of a distribution that still has that patch?
Red Hat Enterprise Linux and Ubuntu LTS seem to be still carrying the
original patch. Possibly others, but these are the only ones I've
identified.
> If I remember the context correctly, the use of comp0size could then
> lead to a heap buffer overflow later on. Was that what you noticed?
Yes: the use of comp0size under-allocates buffers for components 1..N,
which are then overflowed in later processing.
using issue725.jp2 from
https://github.com/uclouvain/openjpeg-data/tree/master/input/nonregression/
$ valgrind j2k_to_image -i issue725.jp2 -o o.ppm
[INFO] tile 1 of 1
==13969== Invalid write of size 4
==13969== at 0x4E52B3A: t1_decode_cblks (t1.c:1560)
==13969== by 0x4E5BD53: tcd_decode_tile (tcd.c:1424)
==13969== by 0x4E42749: j2k_read_eoc (j2k.c:1670)
==13969== by 0x4E42EB7: j2k_decode (j2k.c:1998)
==13969== by 0x4E468C4: opj_jp2_decode (jp2.c:778)
==13969== by 0x4E49A2F: opj_decode_with_info (openjpeg.c:168)
==13969== by 0x4E4999F: opj_decode (openjpeg.c:157)
==13969== by 0x404294: main (j2k_to_image.c:674)
==13969== Address 0x64b7a1c is 0 bytes after a block of size 396 alloc'd
==13969== at 0x4C29BFD: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==13969== by 0x4E5BCD0: tcd_decode_tile (tcd.c:1418)
==13969== by 0x4E42749: j2k_read_eoc (j2k.c:1670)
==13969== by 0x4E42EB7: j2k_decode (j2k.c:1998)
==13969== by 0x4E468C4: opj_jp2_decode (jp2.c:778)
==13969== by 0x4E49A2F: opj_decode_with_info (openjpeg.c:168)
==13969== by 0x4E4999F: opj_decode (openjpeg.c:157)
==13969== by 0x404294: main (j2k_to_image.c:674)
==13969==
--
Doran Moppert
Red Hat Product Security
Content of type "application/pgp-signature" skipped
Powered by blists - more mailing lists
Please check out the
Open Source Software Security Wiki, which is counterpart to this
mailing list.
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
