Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Mon, 17 Aug 2015 16:19:09 -0400 (EDT)
Subject: Re: CVE request: ansible zone/chroot/jail escape

Hash: SHA256

> I recently found a symlink attack that enables a malicious
> zone/chroot/jail managed by ansible to escape into the managing host.
> This was fixed in ansible 1.9.2 (commit list below

We think we understand this well enough to make an initial CVE ID
assignment. It is possible that some of our comments below are not
really correct, or that additional CVE IDs will be needed.

Our understanding is that the essential issue is that file copying
must be performed by code that is operating within the restricted
environment (chroot, jail, or zone). It is wrong to do the file
copying by operating outside the restricted environment, and relying
on the addition of a leading pathname substring, because that doesn't
address the symlink case.

This essential issue is what is covered by:
      Fix problem with chroot connection plugins and symlinks from within
      the chroot.
      Fix problem with jail and zone connection plugins and symlinks from
      within the jail/zone.

from your commit list.

Use CVE-2015-6240 for this issue.

There were a few differences in the code for chroot versus jail and
zone, but we don't believe that the differences require a separate CVE
ID. (Roughly, it appeared that code for operating within the
restricted environment did exist in the jail and zone cases, i.e.,
calls to jexec and zlogin existed, but this code was not used in the
applicable place. By contrast, code for operating within the
restricted environment did not exist in the chroot case.)

>     Use BUFSIZE when putting file as well as fetching file.

We think this is an unrelated performance improvement that probably
has no practical effect on security (maybe an attacker who had access
within a restricted environment could create a huge file that would be
copied with a 512-byte block size rather than a 65536-byte block size,
and thus trigger more resource consumption). There is currently no CVE
ID for this commit.

>     Fix exec_command to not use a shell

We didn't completely understand this. One guess is that, given that
the new code is operating within the restricted environment, it would
be unsafe to rely on the pathname /bin/sh within the restricted
environment, because the contents of /bin/sh are controllable by the
attacker, or because /bin/sh might not exist. In that situation,
there is no CVE ID because the previous code wasn't operating within
the restricted environment, and thus the status of /bin/sh within the
restricted environment was originally irrelevant.

This might raise the question of text such as:

       p = self._buffered_exec_command('dd if=%s bs=%s' % (in_path, BUFSIZE), None)
   except OSError:
       raise errors.AnsibleError("jail connection requires dd command in the jail")

in the next commit. In other words, we don't understand why it is safe
to run a dd program found inside the restricted environment, given the
original premise that the attacker has write access inside the
restricted environment.

It is also conceivable that this commit addresses a
shell-metacharacter issue that is independent of which /bin/sh
pathname is used. The CVE project team has not researched this.

>     Fix problem with jail and zone connection plugins and symlinks from
>     within the jail/zone.

There is no CVE ID for the code problem that was fixed by this commit.
(For completeness, we should mention that the analogous code changes
for the chroot case are contained in
952166f48eb0f5797b75b160fd156bbe1e8fc647.) In other words, the
existence of dd within the restricted environment was originally
irrelevant. As mentioned above, it is conceivable that a CVE ID is
needed for a code problem introduced by running an attacker-controlled
dd program, but the CVE project team has not researched this and does
not know whether it could ever be an exploitable vulnerability.

- -- 
CVE assignment team, MITRE CVE Numbering Authority
M/S M300
202 Burlington Road, Bedford, MA 01730 USA
[ PGP key available through ]
Version: GnuPG v1


Powered by blists - more mailing lists

Please check out the Open Source Software Security Wiki, which is counterpart to this mailing list.

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.