On 28 Jun 2014 at 6:33, Isaac Dunham wrote: Date sent: Sat, 28 Jun 2014 06:33:35 -0700 From: Isaac Dunham <[email protected]> To: [email protected] Subject: LZO security bug might affect Busybox
> There's an integer overflow in LZO (LMS-2014-06-16-1): > http://www.openwall.com/lists/oss-security/2014/06/26/20 > > I suspect that this affects Busybox; the code would be in > archival/libarchive/lzo1x_d.c > But I wouldn't be able to verify that or to fix it. > Couple of items. >From http://www.oberhumer.com/opensource/lzo/ Version 2.07 25 Jun 2014 Copyright (C) 1996 - 2014 Markus F.X.J. Oberhumer News LZO 2.07 has been released: Fixed a potential integer overflow condition in the "safe" decompressor variants which could result in a possible buffer overrun when processing maliciously crafted compressed input data. Fortunately this issue only affects 32-bit systems and also can only happen if you use uncommonly huge buffer sizes where you have to decompress more than 16 MiB (> 2^24 bytes) untrusted compressed bytes within a single function call, so the practical implications are limited. POTENTIAL SECURITY ISSUE. But then, I personally do not know about any client program that actually is affected. TL;DR: the Linux kernel is *not* affected; media hype. >From my understanding, someone has to make a file to produce the problem. I did download and compile the new LZO 2.07, and it creates a new library file, but it has the .la extention instead of the .so extension that the standard lzop is linked with. My G4L project uses the lzop within busybox as the default compression program, and have never had an issue, but am interested in elimanating any potential issues. > Thanks, > Isaac Dunham > _______________________________________________ > busybox mailing list > [email protected] > http://lists.busybox.net/mailman/listinfo/busybox +----------------------------------------------------------+ Michael D. Setzer II - Computer Science Instructor Guam Community College Computer Center mailto:[email protected] mailto:[email protected] http://www.guam.net/home/mikes Guam - Where America's Day Begins G4L Disk Imaging Project maintainer http://sourceforge.net/projects/g4l/ +----------------------------------------------------------+ http://setiathome.berkeley.edu (Original) Number of Seti Units Returned: 19,471 Processing time: 32 years, 290 days, 12 hours, 58 minutes (Total Hours: 287,489) BOINC@HOME CREDITS ROSETTA 16875087.457129 | SETI 28014256.354595 ABC 16613838.513356 | EINSTEIN 26934147.994939 _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
