Hi,
I've had a look at CVE-2018-6544 in mupdf, and after some investigations
I think that we can reasonably consider the Wheezy version as unaffected
by this issue and mark it no-dsa.
The issue is not reproducible with Valgrind in wheezy. I couldn't build
the Wheezy version of mupdf with asan in Jessie because the codebase isn't
compatible with the dependencies (looks like an api break in libopenjpeg).
However, analysis of the patches[0][1] suggests that the code present
in Wheezy isn't completely affected by the issue.
One could describe CVE-2018-6544 as composed of two separate issues,
one triggering the other:
* Concerning the first one:
In pdf_open_raw_filter (pdf-stream.c), a full exception stack could lead
the catch block to be executed before fz_keep_stream(ctx, chain), leading
to fz_drop_stream free-ing data that would actually be needed later
('keep' should really be called before 'drop' in this case). This may lead
heap-use-after-free bugs later.
If I understand the code well, mupdf in Wheezy isn't affected by this issue
because:
- it doesn't call fz_drop_stream at all in the failure case
(actually this function doesn't exists in the 0.9 branch, at that
time it was named fz_close[2]). In fact, while the more recent versions
execute fz_keep_stream in a codebase specific try block (with
fz_drop_stream in the catch), the 0.9 version handles errors by looking
at the return value and exiting if necessary.
- fz_keep_stream(ctx, chain) is called at the beginning of the function
and I can't see any reason why the stream would be freed before keep
is called.
* Concerning the second part:
Because of buggy exception handling in pdf-xref.c, mupdf could enter in an
"infinite" error-handling recursion only bounded by the exception stack.
This bug would then trigger the previously discussed case where the try block
is called with a full exception stack, leading to direct execution of the catch
block and freeing of actually needed data.
I'm still quite unsure on whether the Wheezy version is affected by the
second part of this issue or not because the code is quite different and
error handling has changed a lot. I'd say it is not impossible that wheezy
is affected by this issue.
However, IMO if the first part of the issue (the actual heap-use-after-free)
isn't affecting Wheezy, then there's no real need to care about this issue
which, in the worst case, could maybe crash mupdf (but I'm not even sure
of that) and I'm not convinced that taking so much time to fix and test it
would be the right way to use my assigned time. :)
If anybody wants to have a look, feel free to do so, otherwise I'll mark
this issue no-dsa (I'd rather avoid 'not-affected' since I'm not 100% sure
of that and I think it's not worth taking any more time for this issue).
Regards,
Hugo
[0] http://git.ghostscript.com/?p=mupdf.git;h=b03def134988da8c800adac1a38a41a1f09a1d89
[1] http://git.ghostscript.com/?p=mupdf.git;h=26527eef77b3e51c2258c8e40845bfbc015e405d
[2] http://git.ghostscript.com/?p=mupdf.git;a=commit;h=681039767f2ccc72e236246178893eb0989169c9
--
Hugo Lefeuvre (hle) | www.owl.eu.com
4096/ 9C4F C8BF A4B0 8FC5 48EB 56B8 1962 765B B9A8 BACA
Attachment:
signature.asc
Description: PGP signature