Description of problem:
Victor Stinner identified an interger overflow that might result into
buffer overflow in libexif/exif-data.c:exif_data_load_data_entry().
The commit message states, that other similar issues had been solved.
The problem results in possible overflow in memcpy() call, so should be caught
by _FORTIFY_SOURCE=2, therefore mitigating the possible arbitrary code execution
to just a crash.
Created attachment 154677 [details]
Reproducer for libexif integer overflow
I was unable to reproduce it with this both on a 32 and 64 bit systems with
gimp, gphoto2 and nautilus.
# repoquery --whatrequires --alldeps libexif
No other similar issues were found and fixed in the release, according to output
of cvs diff -D20070510 -rlibexif-0_6_14-release
Created attachment 154678 [details]
Fix for libexif integer overflow
Extracted from upstream CVS.
Applies against FC-5, FC-6, RHEL-4, RHEL-5
Created attachment 155358 [details]
Minimal testcase, currently segfaults
This flaw will not be caught by _FORTIFY_SOURCE=2 See this message:
This usage of memcpy is as such:
/* 4) Not known if correct, not checkable at runtime.
The compiler doesn't know the buffer size, no checking
is done. Overflows will go undetected in these cases. */
This flaw is not exploitable to be anything other than a crash. The problem is
that the code execute this line:
memcpy (entry->data, d + doff, s);
As we can from gdb:
(gdb) print entry->data
$8 = (unsigned char *) 0x8eca498 ""
(gdb) print d
$9 = (const unsigned char *) 0x8eca1c6 "MM"
(gdb) print doff
$10 = 4294901874
(gdb) print s
$11 = 65535
(gdb) print d+doff
$12 = (const unsigned char *) 0x8eba238 <Address 0x8eba238 out of bounds>
d+doff is an OOB memory address, which means this bug crashes due to a bad read,
which cannot be exploited.
NVD statment for this issue has been published:
Red Hat does not consider this flaw to have security consequences.
Fedora packages were update to fixed upstream version, which among other fixes
introduced fix for this issue: