Details on a security issue in liblzo were released on June 26: http://openwall.com/lists/oss-security/2014/06/26/20 The issue is fixed upstream in 2.08. Upstream has some commentary on the issue: http://www.oberhumer.com/opensource/lzo/ Updated packaged uploaded for Mageia 3, Mageia 4, and Cauldron. Advisory: ======================== Updated liblzo packages fix security vulnerability: An integer overflow in liblzo before 2.07 allows attackers to cause a denial of service or possibly code execution in applications using performing LZO decompression on a compressed payload from the attacker (CVE-2014-4607). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4607 http://openwall.com/lists/oss-security/2014/06/26/20 ======================== Updated packages in core/updates_testing: ======================== liblzo2_2-2.08-1.mga3 liblzo-devel-2.08-1.mga3 liblzo2_2-2.08-1.mga4 liblzo-devel-2.08-1.mga4 from SRPMS: liblzo-2.08-1.mga3.src.rpm liblzo-2.08-1.mga4.src.rpm Reproducible: Steps to Reproduce:
Whiteboard: (none) => MGA3TOO
Fedora has issued an advisory for this on June 30: https://lists.fedoraproject.org/pipermail/package-announce/2014-July/134999.html Updated advisory. Advisory: ======================== Updated liblzo packages fix security vulnerability: An integer overflow in liblzo before 2.07 allows attackers to cause a denial of service or possibly code execution in applications using performing LZO decompression on a compressed payload from the attacker (CVE-2014-4607). References: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-4607 https://lists.fedoraproject.org/pipermail/package-announce/2014-July/134999.html
URL: (none) => http://lwn.net/Vulnerabilities/604237/
Tested on Mageia 3 & 4, i586 & x86_64 This bug only plausable for 32 bit systems. I'm not sure if a motherboard exists yet that could handle the amount of memory needed to pull this off on a 64 bit system. Tested on both anyway just to be sure. According to this post: http://www.oberhumer.com/opensource/lzo/ A DoS is only possible if the client program tries to decompress data in a single function call to a buffer in excess of 16MiB in size, the decompressed data is larger than that and composed of all zeroes. Such client programs are scarse to non-existent, so testing to make sure the update doesn't break things. Steps taken: 1: Installed liblzo2_2, liblzo-devel and lzop 2: Created a 32MiB file composed of all zeros 3: Compressed and uncompressed the file using lzop. Before and after updates no problems detected. ------------------------------------------ Update validated. Thanks. Advisories: See comment #1 SRPMS: liblzo-2.08-1.mga3.src.rpm liblzo-2.08-1.mga4.src.rpm Could sysadmin please push from core/updates_testing to core/updates. Thank you! ------------------------------------------
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs, warrendiogeneseWhiteboard: MGA3TOO => MGA3TOO MGA3-64-OK MGA3-32-OK MGA4-64-OK MGA4-32-OK
Advisory uploaded.
Whiteboard: MGA3TOO MGA3-64-OK MGA3-32-OK MGA4-64-OK MGA4-32-OK => MGA3TOO advisory MGA3-64-OK MGA3-32-OK MGA4-64-OK MGA4-32-OK
http://advisories.mageia.org/MGASA-2014-0290.html
Status: NEW => RESOLVEDCC: (none) => pterjanResolution: (none) => FIXED
As noted in the changelog it only affected 32 bit.
CC: (none) => oe