Created attachment 531923 [details] Valgrind output. The PDF at http://sites.amd.com/us/Documents/48423B_fusion_whitepaper_WEB.pdf is causing evince to crash. The PDF displays momentarily, and then evince suffers a SIGSEGV. Valgrind shows a number of errors. On the basis that this is triggered by downloaded content, marking as a security bug.
This issue did NOT affect the versions of the evince package, as shipped with Red Hat Enterprise Linux 5 and 6. -- This issue did NOT affect the version of the evince package, as shipped with Fedora release of 14 and 15. -- This issue did NOT affect the versions of the cairo package, as shipped with Red Hat Enterprise Linux 5 and 6. -- This issue did NOT affect the versions of the cairo package, as shipped with Fedora release of 14.
I dont think we should be calling this security in the first place, here is my reasoning: cairo_new_path() is part of the cairo API. None of the external API functions exposed by cairo check for the sanity of the input values. It is the responsibility of the calling function to make sure they pass sane arguments. Consider this simple program [ using cario_new_path() ] [huzaifas@babylon tmp]$ cat crash1.c #include <cairo.h> void main(void) { cairo_t *cr; cr = NULL; cairo_new_path(cr); } $ gcc -g `pkg-config --libs --cflags cairo` -o crash1 crash1.c [huzaifas@babylon tmp]$ gdb -q ./crash1 Reading symbols from /tmp/crash1...done. (gdb) run Starting program: /tmp/crash1 [Thread debugging using libthread_db enabled] Program received signal SIGSEGV, Segmentation fault. INT_cairo_new_path (cr=0x0) at cairo.c:1647 1647 if (unlikely (cr->status)) Repeating the process, this time i am using the cairo_move_to function, code looks like: [huzaifas@babylon tmp]$ cat crash2.c #include <cairo.h> void main(void) { cairo_t *cr; cr = NULL; cairo_move_to(cr, (double) 10, (double) 20); } This still crashes at the same point. So the point here, dont pass un-sanitized input to cairo API functions.
And yes, this is a null pointer de-reference in cairo, which can be triggered by any application passing bad data to cairo. So this isnt a security issue with such applications (like evince) also, though this does cause a crash
I cannot reproduce the valgrind output in comment #1. After installing a fully update fedora-16 i686 machine, it seems that the OOB reads actually arise from fontconfig and not evince as such
Created attachment 532772 [details] valgrind logs with fully updated f-16
I can reproduce the valgrind output. I can even reproduce it without a PDF opened and I have a similar output for eog. The backtrace of the first OOB read starts in both cases in g_option_context_parse() in corresponding main.c. The second backtrace (the rsvg one) starts to be similar from pango_layout_check_lines(). So it seems that these OOB reads are not caused by evince. Marek
> The second backtrace (the rsvg one) starts to be similar from > pango_layout_check_lines(). It should be: "(the FcConfigFileExists() one)"
Hi Marek, thanks for follow up on this one. (In reply to comment #11) > I can reproduce the valgrind output. I can even reproduce it without a PDF > opened and I have a similar output for eog. So you are saying these OOB reports are sourced in glib (for the first case), then in librsvg2 (for the second case)? [thus regardless of the underlying binary calling / using those libraries, these reports are still here?] > > The backtrace of the first OOB read starts in both cases in > g_option_context_parse() in corresponding main.c. > The second backtrace (the rsvg one) starts to be similar from > pango_layout_check_lines(). > > So it seems that these OOB reads are not caused by evince. Ok, good. Yet, are we able to say if these are due evince / eog calling glib / librsvg2 with strange arguments or due these calling those libraries with potentially unitialized variables? (just trying to find out why by proper libraries API calls those would be here) Thanks && Regards, Jan. > > Marek
Evince did not properly use cairo API and passed wrong values to it, which causes evince to crash in cairo libraries. The crash is caused due to NULL pointer de-reference. Corresponding code snippet: 1647 if (unlikely (cr->status)) where #define unlikely(expr) (expr) This causes a NULL pointer de-reference and hence crash. Red Hat does not consider crash of an end user application, such an evince, to be a security issue.
I found out that the crash is caused by this commit: http://cgit.freedesktop.org/poppler/poppler/commit/?h=poppler-0.18&id=3a574f13fa22b7c31eda0d0437f4094a5a39ff34. I'll commit a simple check for cairo != NULL for now. The upstream fix would need soname bump. The upstream fix is already in rawhide. Marek
poppler-0.18.0-2.fc16 has been submitted as an update for Fedora 16. https://admin.fedoraproject.org/updates/poppler-0.18.0-2.fc16
Package poppler-0.18.0-2.fc16: * should fix your issue, * was pushed to the Fedora 16 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing poppler-0.18.0-2.fc16' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2011-15788 then log in and leave karma (feedback).
poppler-0.18.0-2.fc16 has been pushed to the Fedora 16 stable repository. If problems still persist, please make note of it in this bug report.
*** Bug 743844 has been marked as a duplicate of this bug. ***
*** Bug 744414 has been marked as a duplicate of this bug. ***
*** Bug 747097 has been marked as a duplicate of this bug. ***