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.