Bug 6768 - libexif 0.6.21 release to fix security vulnerabilities
: libexif 0.6.21 release to fix security vulnerabilities
Status: RESOLVED FIXED
Product: Mageia
Classification: Unclassified
Component: Security
: 2
: All Linux
: Normal Severity: major
: ---
Assigned To: QA Team
:
: http://sourceforge.net/mailarchive/me...
: MGA1TOO mga2-64-OK mga1-64-OK mga1-32...
: validated_update
:
:
  Show dependency treegraph
 
Reported: 2012-07-12 23:38 CEST by Dan Fandrich
Modified: 2012-07-14 01:25 CEST (History)
5 users (show)

See Also:
Source RPM: libexif-0.6.20-1.mga1.src.rpm
CVE:


Attachments

Description Dan Fandrich 2012-07-12 23:38:04 CEST
libexif 0.6.21 (and exif 0.6.21) have been released to fix a number of security vulnerabilities. It should be a drop-in replacement for 0.6.20.
Comment 1 David Walser 2012-07-13 02:44:17 CEST
* Fixed a number of security and stability issues due to buffer overflows,
  bad pointer dereferences and division-by-zero including bug #3434540
  and bug #3434545 (CVE-2012-2812, CVE-2012-2813, CVE-2012-2814,
  CVE-2012-2836, CVE-2012-2837, CVE-2012-2840, CVE-2012-2841,
  CVE-2012-2845)

http://libexif.sourceforge.net/
Comment 2 David Walser 2012-07-13 04:39:20 CEST
Updated packages uploaded for Mageia 1, Mageia 2, and Cauldron.

Advisory:
========================

Updated libexif and exif packages fix security vulnerabilities:

A heap-based out-of-bounds array read in the exif_entry_get_value
function in libexif/exif-entry.c in libexif 0.6.20 and earlier allows
remote attackers to cause a denial of service or possibly obtain
potentially sensitive information from process memory via an image with
crafted EXIF tags (CVE-2012-2812).

A heap-based out-of-bounds array read in the exif_convert_utf16_to_utf8
function in libexif/exif-entry.c in libexif 0.6.20 and earlier allows
remote attackers to cause a denial of service or possibly obtain
potentially sensitive information from process memory via an image with
crafted EXIF tags (CVE-2012-2813).

A buffer overflow in the exif_entry_format_value function in
libexif/exif-entry.c in libexif 0.6.20 allows remote attackers to cause
a denial of service or possibly execute arbitrary code via an image
with crafted EXIF tags (CVE-2012-2814).

A heap-based out-of-bounds array read in the exif_data_load_data
function in libexif 0.6.20 and earlier allows remote attackers to cause
a denial of service or possibly obtain potentially sensitive
information from process memory via an image with crafted EXIF tags
(CVE-2012-2836).

A divide-by-zero error in the mnote_olympus_entry_get_value function
while formatting EXIF maker note tags in libexif 0.6.20 and earlier
allows remote attackers to cause a denial of service via an image
with crafted EXIF tags (CVE-2012-2837).

An off-by-one error in the exif_convert_utf16_to_utf8 function in
libexif/exif-entry.c in libexif 0.6.20 and earlier allows remote
attackers to cause a denial of service or possibly execute arbitrary
code via an image with crafted EXIF tags (CVE-2012-2840).

An integer underflow in the exif_entry_get_value function can cause a
heap overflow and potentially arbitrary code execution while formatting
an EXIF tag, if the function is called with a buffer size parameter
equal to zero or one (CVE-2012-2841).

An integer overflow in the function jpeg_data_load_data in the exif
program could cause a data read beyond the end of a buffer, causing an
application crash or leakage of potentially sensitive information when
parsing a crafted JPEG file (CVE-2012-2845).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2812
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2813
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2814
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2836
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2837
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2840
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2841
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2845
http://sourceforge.net/mailarchive/message.php?msg_id=29534027
========================

Updated packages in core/updates_testing:
========================
libexif-devel-0.6.21-1.mga1
libexif12-0.6.21-1.mga1
libexif12-common-0.6.21-1.mga1
exif-0.6.21-1.mga1
libexif-devel-0.6.21-1.mga2
libexif12-0.6.21-1.mga2
libexif12-common-0.6.21-1.mga2
exif-0.6.21-1.mga2

from SRPMS:
libexif-0.6.21-1.mga1.src.rpm
exif-0.6.21-1.mga1.src.rpm
libexif-0.6.21-1.mga2.src.rpm
exif-0.6.21-1.mga2.src.rpm
Comment 4 claire robinson 2012-07-13 16:03:34 CEST
No PoC's that I can find so just checking functionality.
Comment 5 claire robinson 2012-07-13 16:16:54 CEST
mga2 64 doesn't seem to package lib64exif12-common but it exists as libexif12-common in x86_64 arch.

Is this an error or by design? It seems to break our library naming conventions.

# urpmq -i libexif12-common
Name        : libexif12-common
Version     : 0.6.20
Release     : 1.mga1
Group       : Graphics
Size        : 1350402                      Architecture: x86_64
Source RPM  : libexif-0.6.20-1.mga1.src.rpm

Checking with urpmf it seems to just be locales so it seems should either be noarch or lib64exif12-common on x86_64 probably.
Comment 6 David Walser 2012-07-13 16:27:12 CEST
I see libexif12-common-0.6.21-1.mga1.x86_64.rpm in the build logs, so it should be there...
Comment 7 David Walser 2012-07-13 16:28:59 CEST
Oh I see what you mean.  The -common package does not contain the library itself, so it shouldn't be named lib64.
Comment 8 claire robinson 2012-07-13 16:37:02 CEST
Thanks David, not come across one like that before.
Comment 9 Deri James 2012-07-13 16:44:43 CEST
ested on Mag 2 x86_64.

Notes: 

1. Just selecting exif does not bring in the libraries as well (no requires). Selected manually.

[derij@localhost ~]$ exif -v
0.6.21
[derij@localhost ~]$ exif pdrm0002.jpg 
EXIF tags in 'pdrm0002.jpg' ('Intel' byte order):
--------------------+----------------------------------------------------------
Tag                 |Value
--------------------+----------------------------------------------------------
Image Description   |TOSHIBA Exif JPEG
Manufacturer        |TOSHIBA
Model               |PDR-M4 
Orientation         |Top-left
X-Resolution        |72
Y-Resolution        |72
Resolution Unit     |Inch
Software            |Digital Camera PDR-M4 Ver1.21
Date and Time       |2000:05:28 17:32:25
YCbCr Positioning   |Co-sited
Compression         |JPEG compression
Orientation         |Top-left
X-Resolution        |72
Y-Resolution        |72
Resolution Unit     |Inch
YCbCr Positioning   |Co-sited
Exposure Time       |1/130 sec.
F-Number            |f/3.2
Exposure Program    |Normal programme
Exif Version        |Exif Version 2.1
Date and Time (Origi|2000:05:28 17:32:25
Date and Time (Digit|2000:05:28 17:32:25
Components Configura|Y Cb Cr -
Shutter Speed       |7.00 EV (1/128 sec.)
Aperture            |3.36 EV (f/3.2)
Exposure Bias       |0.00 EV
Flash               |Flash fired
Maker Note          |20 bytes undefined data
FlashPixVersion     |FlashPix Version 1.0
Colour Space        |sRGB
Pixel X Dimension   |800
Pixel Y Dimension   |600
File Source         |DSC
Interoperability Ind|R98
Interoperability Ver|0100
--------------------+----------------------------------------------------------
EXIF data contains a thumbnail (4490 bytes).

[derij@localhost ~]$ ll /usr/lib64/libexif*
lrwxrwxrwx 1 root root     17 Jul 13 15:03 /usr/lib64/libexif.so.12 -> libexif.so.12.3.3*
-rwxr-xr-x 1 root root 285656 Jul 13 03:06 /usr/lib64/libexif.so.12.3.3*
Comment 10 claire robinson 2012-07-13 16:50:28 CEST
Testing complete mga2 64 using some examples found in 'man exif' to create a thumbnail and view data.

Thankyou too Deri
Comment 11 claire robinson 2012-07-13 17:06:49 CEST
Testing complete mga1 64
Comment 12 Dan Fandrich 2012-07-13 17:40:31 CEST
(In reply to comment #4)
> No PoC's that I can find so just checking functionality.

There are now some corrupted test images in the libexif-testsuite repository (http://libexif.cvs.sourceforge.net/libexif/libexif-testsuite/) that are run as part of the overall test suite to verify some of the fixes. Most (if not all) of these tests will only show problems on 64-bit architectures, and many require running them with valgrind, which is only done by manually tweaking the test configuration.
Comment 13 claire robinson 2012-07-13 18:08:53 CEST
Thats Dan. I tried a couple of the testcases on the binaries in Testing and no problems to report :)
Comment 14 claire robinson 2012-07-13 18:09:06 CEST
Thanks even.
Comment 15 claire robinson 2012-07-13 18:29:57 CEST
Testing complete mga1 32

Just needs mga2 32 to validate.
Comment 16 Dan Fandrich 2012-07-13 22:08:32 CEST
Note that there is a short test suite built-in to the libexif package (and another one for the exif package). It's a good way to sanity check the release, and I'd recommend adding it to the .spec file; just do a 'make check' after the build. There's a separate full-fledged libexif test suite also available, but that's not something I'd recommend adding to the package.
Comment 17 David Walser 2012-07-13 22:40:08 CEST
(In reply to comment #16)
> Note that there is a short test suite built-in to the libexif package (and
> another one for the exif package). It's a good way to sanity check the release,
> and I'd recommend adding it to the .spec file; just do a 'make check' after the
> build. There's a separate full-fledged libexif test suite also available, but
> that's not something I'd recommend adding to the package.

Thanks Dan.  Can you file another bug report stating that and CC me on it?  I'll be working 10-11 hour days and be very busy the next couple weeks, but I'll get to it at some point if nobody else does.
Comment 18 Dan Fandrich 2012-07-13 23:14:58 CEST
Done: bug #6777
Comment 19 Dave Hodgins 2012-07-13 23:28:08 CEST
Testing complete on Mageia 2 i586.

Could someone from the sysadmin team push the srpms
libexif-0.6.21-1.mga2.src.rpm
exif-0.6.21-1.mga2.src.rpm
from Mageia 2 Core Updates Testing to Core Updates and the srpms
libexif-0.6.21-1.mga1.src.rpm
exif-0.6.21-1.mga1.src.rpm
from Mageia 1 Core Updates Testing to Core Updates.

Advisory: Updated libexif and exif packages fix security vulnerabilities:

A heap-based out-of-bounds array read in the exif_entry_get_value
function in libexif/exif-entry.c in libexif 0.6.20 and earlier allows
remote attackers to cause a denial of service or possibly obtain
potentially sensitive information from process memory via an image with
crafted EXIF tags (CVE-2012-2812).

A heap-based out-of-bounds array read in the exif_convert_utf16_to_utf8
function in libexif/exif-entry.c in libexif 0.6.20 and earlier allows
remote attackers to cause a denial of service or possibly obtain
potentially sensitive information from process memory via an image with
crafted EXIF tags (CVE-2012-2813).

A buffer overflow in the exif_entry_format_value function in
libexif/exif-entry.c in libexif 0.6.20 allows remote attackers to cause
a denial of service or possibly execute arbitrary code via an image
with crafted EXIF tags (CVE-2012-2814).

A heap-based out-of-bounds array read in the exif_data_load_data
function in libexif 0.6.20 and earlier allows remote attackers to cause
a denial of service or possibly obtain potentially sensitive
information from process memory via an image with crafted EXIF tags
(CVE-2012-2836).

A divide-by-zero error in the mnote_olympus_entry_get_value function
while formatting EXIF maker note tags in libexif 0.6.20 and earlier
allows remote attackers to cause a denial of service via an image
with crafted EXIF tags (CVE-2012-2837).

An off-by-one error in the exif_convert_utf16_to_utf8 function in
libexif/exif-entry.c in libexif 0.6.20 and earlier allows remote
attackers to cause a denial of service or possibly execute arbitrary
code via an image with crafted EXIF tags (CVE-2012-2840).

An integer underflow in the exif_entry_get_value function can cause a
heap overflow and potentially arbitrary code execution while formatting
an EXIF tag, if the function is called with a buffer size parameter
equal to zero or one (CVE-2012-2841).

An integer overflow in the function jpeg_data_load_data in the exif
program could cause a data read beyond the end of a buffer, causing an
application crash or leakage of potentially sensitive information when
parsing a crafted JPEG file (CVE-2012-2845).

References:
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2812
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2813
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2814
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2836
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2837
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2840
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2841
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2012-2845
http://sourceforge.net/mailarchive/message.php?msg_id=29534027

https://bugs.mageia.org/show_bug.cgi?id=6768
Comment 20 Thomas Backlund 2012-07-14 01:25:13 CEST
Update pushed:
https://wiki.mageia.org/en/Support/Advisories/MGASA-2012-0167

Note You need to log in before you can comment on or make changes to this bug.