Am 31.07.2018 um 04:01 schrieb jhcha54008: > Hi, > > Is it the right place to report a possible regression bug against > busybox-static version 1:1.22.0-9+deb8u2 ? It is. Thank you for contacting us. > 1) It seems it can't gunzip large files. > > $ dpkg -l busybox-static > ... > ii busybox-static 1:1.22.0-9+deb8u2 amd64 Standalone rescue shell with tons of builtin utilities > > $ dd if=/dev/zero of=test0-2292 bs=1 count=2292 > $ dd if=/dev/zero of=test0-2293 bs=1 count=2293 > $ gzip test0-2292 test0-2293 > $ busybox gunzip - < test0-2292.gz | wc > 0 0 2292 > $ busybox gunzip - < test0-2293.gz | wc > 0 0 0 > > and I get the same (anomalous) result with files bigger than 2293 bytes. This is apparently related to CVE-2015-9261. The upstream patch is correctly applied but this is not intended. I will look into it. > 2) It doesn't extract symlinks from a cpio archive if the target > path contains (at least) one slash (ie absolute symlinks and > relative symlinks towards another directory are not extracted). [...] This is related to CVE-2011-5325 and at first glance this looks correct to me. CVE-2011-5325 was about a symlinking attack. Taken from CVE-2011-5325_part1.patch: For example, consider a .tar created via: tar cvf bug.tar anything.txt ln -s /tmp symlink tar --append -f bug.tar symlink rm symlink mkdir symlink tar --append -f bug.tar symlink/evil.py This will result in an archive that contains: tar --list -f bug.tar anything.txt symlink [-> /tmp] symlink/evil.py Untarring bug.tar would otherwise place evil.py in '/tmp'. The patch fixes the issue. Your example matches this scenario because you have a lib64 directory and a symlink that is also called lib64/ld-linux-x86-64.so.2. This change is still present in the latest busybox release in Debian. We could revert it but then you would be vulnerable again. > This bug affects the usage of debirf on jessie. > > I hope this will help to find a solution. Regards, Markus
Attachment:
signature.asc
Description: OpenPGP digital signature