Description of problem: A flaw was discovered in the LZW decompressor code from BSD compress, that is re-used by several projects, including heirloom mailx / nail, see bug #727624 for the details about the issues. While the bug had security implication for some components embedding the code, it should only be used on trusted inputs in mailx (imap cache and spam filter database mailx itself creates). It's unclear to me if upstream is still active or not, CVS stats suggest there was no upstream activity for almost a year. If the patch is prepared, please submit upstream as well. mailx unlzw code comes from FreeBSD, which does not have a fix yet. The problem seem to have been addressed in OpenBSD and NetBSD: http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/compress/zopen.c#rev1.17 http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/compress/zopen.c#rev1.14 http://cvsweb.netbsd.org/bsdweb.cgi/src/usr.bin/compress/zopen.c#rev1.15 The second NetBSD fix is probably preferred, as it's more efficient.
The first NetBSD fix looks more preferred for me because it looks more simple. Since unlzw functionality is not a key feature of Heirloom mailx, and it is performed on the trust input only, I think such a simple patch should be good. Whether updates for the current branches are needed, or rawhide only is enough?
Created attachment 518669 [details] The patch I am going to apply
Created attachment 518677 [details] The actual patch applied Rebuild in rawhide. Reopen this bug if I need to rebuild for f14/f15/f16 as well.
(In reply to comment #1) > The first NetBSD fix looks more preferred for me because it looks more simple. > Since unlzw functionality is not a key feature of Heirloom mailx, and it is > performed on the trust input only, I think such a simple patch should be good. The simpler patch as higher performance impact, for both valid and corrupted LZW streams. > Whether updates for the current branches are needed, or rawhide only is enough? Rawhide-only should be ok, ty!