[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-Id: <20150817201909.DB2D46C002C@smtpvmsrv1.mitre.org>
Date: Mon, 17 Aug 2015 16:19:09 -0400 (EDT)
From: cve-assign@...re.org
To: mcarpenter@...e.fr
Cc: cve-assign@...re.org, oss-security@...ts.openwall.com, tkuratomi@...ible.com
Subject: Re: CVE request: ansible zone/chroot/jail escape
-----BEGIN PGP SIGNED MESSAGE-----
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:
https://github.com/ansible/ansible/commit/952166f48eb0f5797b75b160fd156bbe1e8fc647
Fix problem with chroot connection plugins and symlinks from within
the chroot.
https://github.com/ansible/ansible/commit/ca2f2c4ebd7b5e097eab0a710f79c1f63badf95b
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.)
> https://github.com/ansible/ansible/commit/548a7288a90c49e9b50ccf197da307eae525b899
> 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.
> https://github.com/ansible/ansible/commit/270be6a6f5852c5563976f060c80eff64decc89c
> 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:
try:
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.
> https://github.com/ansible/ansible/commit/0777d025051bf5cf3092aa79a9e6b67cec7064dd
> 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 http://cve.mitre.org/cve/request_id.html ]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQEcBAEBCAAGBQJV0kEVAAoJEKllVAevmvmsLigH/0osp9n+2cpYhkHT4DmYoGdz
0nJ8Mpu9BH9XgWANHbBLya2K0r6H/Injn39wngmRZaDZ2VWW+aqq4PDg5WHPKYG4
SVgo4WbeRCb6FwPkTWs8omw/CkhuvQ8htviHaOMO5JiFPxRGiVCB6ucLNY87BSxP
WD3YUH2DoFvZf4r6dATtxRSiix1+lLK6R9qzu+1WFtjNIKgXnN46lblK1dygcycC
/MFhcApekA3k79QHRkBalBlCRw8Droj0Dzq52FiLnv10QnQcBrA8+JAdKBzbN0pt
olUKhW20vQtXHphcsvXivgBQuEVwb0Kjno9NCR74/ZgwQbT7QIeZ40Sd0E4QNik=
=ugTB
-----END PGP SIGNATURE-----
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.
