duplicity-team team mailing list archive

[Kenneth Loafman <kenneth@xxxxxxxxxxx>]

The real problem is that this works since it's all valid pathname chars:
    echo foo > ' --log-file=xxx --partial-dir='
which means that
    /bug/ --log-file=xxx --partial-dir=/tmp
is a quite valid filename.

So, Catch-22, allow all valid filenames, or restrict somehow?

I'm going with allow all valid filenames.

BTW, you can remove with:
    rm ./' --log-file=xxx --partial-dir='

On Wed, Dec 2, 2015 at 11:28 AM, edso <1520691@xxxxxxxxxxxxxxxxxx>
wrote:

> On 02.12.2015 17:48, Bernd Dietzel wrote:
> > Ok, found why it not works.
> > The character "/" ist automatically added at the end, so it results in
> "--log-file=xxx/" wtich wont work.
> > If some valid parameter is at the end witch likes the "/" added, it
> works.
> > In this Demo, i added "--partial-dir=/tmp" witch gets to
> "--partial-dir=/tmp/" witch i s valid.
> > The xxx file was created in my home folder.
> >
> > duplicity 'rsync://127.0.0.1/bug/ --log-file=xxx --partial-dir=/tmp'
> > /home/Downloads/
> >
> > So, when i use the rsync backend, any parameter witch allows to have a
> > "/" at the end will be executed.
> >
>
>
> whilst imperfect, i will not spend time fixing this obvious flaw. as i
> wrote, the same can be achieved "properly" by using --rsync-options. also
> using rsync plainly with these arguments would have an identical result.
>
> the only way to fix this is to patch each and every backend and have it
> shlex/pipes.quote() each and every string we use in the cmd line. but
> until i see a vulnerability springing from this issue i am not going to
> invest the effort, speaking only for myself here of course ;)
>
> ..ede/duply
>
> --
> You received this bug notification because you are subscribed to
> Duplicity.
> https://bugs.launchpad.net/bugs/1520691
>
> Title:
>    Shell Code Injection in hsi backend
>
> Status in Duplicity:
>   Fix Committed
>
> Bug description:
>   https://bugs.launchpad.net/ubuntu/+source/duplicity/+bug/1519103
>
>   The "hsi" backend of duplicity is vulnerabe to code injections.
>
>   It uses os.popen3() with should be replaced with subprocess.Popen().
>
>   Thank you.
>
>   File :
>   -------
>   /usr/lib/python2.7/dist-packages/duplicity/backends/hsibackend.py
>
>   This is the function witch is vulnerable :
>   ------------------------------------------------------------
>       def _list(self):
>           commandline = '%s "ls -l %s"' % (hsi_command, self.remote_dir)
>           l = os.popen3(commandline)[2].readlines()[3:]
>
>   Exploit Demo :
>   ============
>
>   On the Terminal type in :
>
>   $ duplicity 'hsi://bug/";xeyes;"/test/' /tmp/bug
>
>   --> This will start the program xeyes , but should not.
>
>   I attached a screenshot of the exploit demo.
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/duplicity/+bug/1520691/+subscriptions
>

-- 
You received this bug notification because you are a member of
duplicity-team, which is subscribed to the bug report.
https://bugs.launchpad.net/bugs/1520691

Title:
   Shell Code Injection in hsi backend

Status in Duplicity:
  Fix Committed

Bug description:
  https://bugs.launchpad.net/ubuntu/+source/duplicity/+bug/1519103

  The "hsi" backend of duplicity is vulnerabe to code injections.

  It uses os.popen3() with should be replaced with subprocess.Popen().

  Thank you.

  File :
  -------
  /usr/lib/python2.7/dist-packages/duplicity/backends/hsibackend.py

  This is the function witch is vulnerable :
  ------------------------------------------------------------
      def _list(self):
          commandline = '%s "ls -l %s"' % (hsi_command, self.remote_dir)
          l = os.popen3(commandline)[2].readlines()[3:]

  Exploit Demo :
  ============

  On the Terminal type in :

  $ duplicity 'hsi://bug/";xeyes;"/test/' /tmp/bug

  --> This will start the program xeyes , but should not.

  I attached a screenshot of the exploit demo.

To manage notifications about this bug go to:
https://bugs.launchpad.net/duplicity/+bug/1520691/+subscriptions