What steps will reproduce the problem?
1. Tamper a J2K image in such a way that jp2_read_boxhdr() reads a negative
value for 'length'.
2.The code in jp2_read_boxhdr() checks for zero and it checks for sizes too
large, but it does not check for negative values.
3.Later on, the negative size will be used in a call to cio_skip(), which can
move the buffer pointer *before* the start of the buffer.
4.The next byte read from the buffer will then crash... if you are lucky.
What is the expected output? What do you see instead?
Either the box length should be made an unsigned integer, or checks should be
added to jp2_read_boxhdr(), cio_skip() and possibly to cio_seek() in order to
ensure that the cio buffer pointer can never be moved before the start of the
buffer as a result of the operation.
What version of the product are you using? On what operating system?
Version 1.5.0 on Gentoo Linux (amd64).
Please provide any additional information below.
This bug is dangerous because poppler uses openjpeg for rendering JP2K images
contained in PDF files.
An attacker could maliciously modify a PDF file to include an JPEG2000 data
stream with a negative length read by jp2_read_boxhdr(), invoking a crash of
the PDF viewing application. Controlled crashing of an application is a
well-known attack vector as a starting point for more serious attacks.
I encountered this bug by debugging a crash in Evince, but I assume all
applications using poppler with JPEG-2000 support enabled are affected.
And, btw, another minor issue: The error message in jp2_read_boxhdr states that
box sizes higher than 2^32 are not supported.
As box sizes are signed, it rather cannot be higher than 2^31 - 1.
Original issue reported on code.google.com by gbr932...@gmx.net on 2 Jul 2012 at 7:05
Original issue reported on code.google.com by
gbr932...@gmx.net
on 2 Jul 2012 at 7:05