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.
* 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/
URL: (none) => http://sourceforge.net/mailarchive/message.php?msg_id=29534027CC: (none) => luigiwalserVersion: 2 => CauldronWhiteboard: (none) => MGA2TOO, MGA1TOO
Component: RPM Packages => Security
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
Hardware: i586 => AllVersion: Cauldron => 2Assignee: bugsquad => qa-bugsWhiteboard: MGA2TOO, MGA1TOO => MGA1TOO
Mandriva has issued an advisory for these today (July 13): http://www.mandriva.com/en/support/security/advisories/?dis=2011&name=MDVSA-2012:106 http://www.mandriva.com/en/support/security/advisories/?dis=2011&name=MDVSA-2012:107
No PoC's that I can find so just checking functionality.
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.
I see libexif12-common-0.6.21-1.mga1.x86_64.rpm in the build logs, so it should be there...
Oh I see what you mean. The -common package does not contain the library itself, so it shouldn't be named lib64.
Thanks David, not come across one like that before.
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*
CC: (none) => deri
Testing complete mga2 64 using some examples found in 'man exif' to create a thumbnail and view data. Thankyou too Deri
Whiteboard: MGA1TOO => MGA1TOO mga2-64-OK
Testing complete mga1 64
Whiteboard: MGA1TOO mga2-64-OK => MGA1TOO mga2-64-OK mga1-64-OK
(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.
Thats Dan. I tried a couple of the testcases on the binaries in Testing and no problems to report :)
Thanks even.
Testing complete mga1 32 Just needs mga2 32 to validate.
Whiteboard: MGA1TOO mga2-64-OK mga1-64-OK => MGA1TOO mga2-64-OK mga1-64-OK mga1-32-OK
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.
(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.
Done: bug #6777
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=6777
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
Keywords: (none) => validated_updateCC: (none) => davidwhodgins, sysadmin-bugsWhiteboard: MGA1TOO mga2-64-OK mga1-64-OK mga1-32-OK => MGA1TOO mga2-64-OK mga1-64-OK mga1-32-OK MGA2-32-OK
Update pushed: https://wiki.mageia.org/en/Support/Advisories/MGASA-2012-0167
Status: NEW => RESOLVEDCC: (none) => tmbResolution: (none) => FIXED