Re: A possible regression in busybox-static version 1:1.22.0-9+deb8u2
Hi again,
I haven't studied thoroughly the code of busybox.
But with the patch below applied I recover the expected
behaviour of busybox cpio on the example archive.cpio.gz
from the previous message.
I hope it will help to find a solution
Thank you for your work to keep jessie usable !
Regards,
JH Chatenet
archival/cpio.c : add function 'create_symlinks_from_list' (as in tar.c),
to avoid forgetting all absolute symlinks or symlinks with '..' in their
target paths.
Index: busybox-1.22.0/archival/cpio.c
===================================================================
--- busybox-1.22.0.orig/archival/cpio.c
+++ busybox-1.22.0/archival/cpio.c
@@ -480,6 +480,8 @@ int cpio_main(int argc UNUSED_PARAM, cha
while (get_header_cpio(archive_handle) == EXIT_SUCCESS)
continue;
+ create_symlinks_from_list(archive_handle->symlink_placeholders);
+
if (archive_handle->cpio__blocks != (off_t)-1
&& !(opt & OPT_QUIET)
) {
Le jeudi 2 août à 12h 41mn 56s (+0200), jhcha54008 a écrit :
> Hi,
> Thank you for your quick answer and for this corrected version 1:1.22.0-9+deb8u3
>
> Le mardi 31 juillet à 08h 09mn 07s (+0800), Markus Koschany a écrit :
> > Am 31.07.2018 um 04:01 schrieb jhcha54008:
> > > Hi,
> > >
> > > 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.
> >
> >
> > Regards,
> >
> > Markus
> >
>
> Thank you for your explanation. But I am probably still missing something : what is the
> rule to distinguish legitimate/evil symlinks ?
>
> My question was : is it still possible to do system backup restoration with busybox-static cpio ?
>
> I get a restored system with numerous symlinks missing and no dynamically linked
> executable may run (because the path to the ELF-loader is missing too) - including /sbin/init
> (the system doesn't boot farther)
>
> Rewriting the example of my previous message (with busybox-static 1:1.22.0-9+deb8u3) :
>
> $ zcat archive.cpio.gz | cpio -itv
> drwxr-xr-x 14 root root 0 Jul 26 21:57 lib
> drwxr-xr-x 3 root root 0 Jul 26 21:57 lib/x86_64-linux-gnu
> -rwxr-xr-x 1 root root 140928 Jul 26 21:57 lib/x86_64-linux-gnu/ld-2.19.so
> drwxr-xr-x 2 root root 0 Jul 26 21:57 lib64
> lrwxrwxrwx 1 root root 32 Jul 26 21:57 lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-2.19.so
> 277 blocks
> $ busybox gunzip - < archive.cpio.gz | busybox cpio -i
> 277 blocks
> $ ls -ARlF
> .:
> total 0
> drwxr-xr-x 3 me me 60 Aug 2 12:14 lib/
> drwxr-xr-x 2 me me 40 Aug 2 12:14 lib64/
>
> ./lib:
> total 0
> drwxr-xr-x 2 me me 60 Aug 2 12:14 x86_64-linux-gnu/
>
> ./lib/x86_64-linux-gnu:
> total 140
> -rwxr-xr-x 1 me me 140928 Aug 2 12:14 ld-2.19.so*
>
> ./lib64:
> total 0
>
> Regards,
> JH Chatenet
>
>
Reply to: