| 2016-01-13 15:46:22 |
Sergey Kraynev |
bug |
|
|
added bug |
| 2016-01-13 15:47:10 |
Sergey Kraynev |
mos: assignee |
|
Oleksii Chuprykov (ochuprykov) |
|
| 2016-01-13 15:48:30 |
Sergey Kraynev |
nominated for series |
|
mos/8.0.x |
|
| 2016-01-13 15:48:30 |
Sergey Kraynev |
bug task added |
|
mos/8.0.x |
|
| 2016-01-13 15:48:30 |
Sergey Kraynev |
nominated for series |
|
mos/7.0.x |
|
| 2016-01-13 15:48:30 |
Sergey Kraynev |
bug task added |
|
mos/7.0.x |
|
| 2016-01-13 15:48:30 |
Sergey Kraynev |
nominated for series |
|
mos/9.0.x |
|
| 2016-01-13 15:48:30 |
Sergey Kraynev |
bug task added |
|
mos/9.0.x |
|
| 2016-01-13 15:48:37 |
Sergey Kraynev |
mos/7.0.x: status |
New |
Triaged |
|
| 2016-01-13 15:48:39 |
Sergey Kraynev |
mos/9.0.x: status |
New |
Triaged |
|
| 2016-01-13 15:48:41 |
Sergey Kraynev |
mos/7.0.x: importance |
Undecided |
High |
|
| 2016-01-13 15:48:42 |
Sergey Kraynev |
mos/9.0.x: importance |
Undecided |
High |
|
| 2016-01-13 15:48:56 |
Sergey Kraynev |
mos/7.0.x: assignee |
|
Oleksii Chuprykov (ochuprykov) |
|
| 2016-01-13 15:49:04 |
Sergey Kraynev |
mos/9.0.x: assignee |
|
Oleksii Chuprykov (ochuprykov) |
|
| 2016-01-13 15:49:18 |
Sergey Kraynev |
bug task deleted |
mos/9.0.x |
|
|
| 2016-01-13 15:49:25 |
Sergey Kraynev |
mos/7.0.x: importance |
High |
Critical |
|
| 2016-01-13 15:49:27 |
Sergey Kraynev |
mos/7.0.x: importance |
Critical |
High |
|
| 2016-01-13 15:50:20 |
Sergey Kraynev |
mos/7.0.x: assignee |
Oleksii Chuprykov (ochuprykov) |
Vitaly Sedelnik (vsedelnik) |
|
| 2016-01-13 15:53:48 |
Sergey Kraynev |
information type |
Private |
Private Security |
|
| 2016-01-13 16:00:31 |
Sergey Kraynev |
nominated for series |
|
mos/6.1.x |
|
| 2016-01-13 16:00:31 |
Sergey Kraynev |
bug task added |
|
mos/6.1.x |
|
| 2016-01-13 16:00:31 |
Sergey Kraynev |
nominated for series |
|
mos/5.0.x |
|
| 2016-01-13 16:00:31 |
Sergey Kraynev |
bug task added |
|
mos/5.0.x |
|
| 2016-01-13 16:00:31 |
Sergey Kraynev |
nominated for series |
|
mos/6.0.x |
|
| 2016-01-13 16:00:31 |
Sergey Kraynev |
bug task added |
|
mos/6.0.x |
|
| 2016-01-13 16:00:31 |
Sergey Kraynev |
nominated for series |
|
mos/5.1.x |
|
| 2016-01-13 16:00:31 |
Sergey Kraynev |
bug task added |
|
mos/5.1.x |
|
| 2016-01-13 16:12:31 |
Sergey Kraynev |
description |
Steven Hardy from Red Hat reported a vulnerability in Heat template
validation. By referencing a local file like /dev/zero, an authenticated
user may trick the heat engine service to load arbitrary local file
content resulting in a Denial of Service attack through memory
exhaustion. Note that the file content is not written back to the user,
though the user can determine if a file exists and if it is readable by
heat-engine. All Heat setups are affected. |
This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments.
in service.py validate_template, we do an env.get_class bypassing
the global_environment(), which ends up calling
template_resource.generate_class, which wrongly defaults the get_template_file
allowed schemas to "('file',)"
https://github.com/openstack/heat/blob/master/heat/engine/service.py#L958
https://github.com/openstack/heat/blob/master/heat/engine/resources/template_resource.py#L31
The net result of this is that any call to template-validate which
specifies type: foo.yaml will read that file from the filesystem of the
heat service - this actually means template-validate calls which should
fail work on typical devstack env's where the client and heat-engine are
co-located (it took me a while to work out why!!)
I've not figured out any way for this to be exploitable, but it definitely
seems wrong that we allow user-provided paths to be read like this,
and there could be some risk if folks could work out a way to make
validation blow up with a stack-trace containing any file contents. |
|
| 2016-01-13 16:13:40 |
Sergey Kraynev |
description |
This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments.
in service.py validate_template, we do an env.get_class bypassing
the global_environment(), which ends up calling
template_resource.generate_class, which wrongly defaults the get_template_file
allowed schemas to "('file',)"
https://github.com/openstack/heat/blob/master/heat/engine/service.py#L958
https://github.com/openstack/heat/blob/master/heat/engine/resources/template_resource.py#L31
The net result of this is that any call to template-validate which
specifies type: foo.yaml will read that file from the filesystem of the
heat service - this actually means template-validate calls which should
fail work on typical devstack env's where the client and heat-engine are
co-located (it took me a while to work out why!!)
I've not figured out any way for this to be exploitable, but it definitely
seems wrong that we allow user-provided paths to be read like this,
and there could be some risk if folks could work out a way to make
validation blow up with a stack-trace containing any file contents. |
This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments.
in service.py validate_template, we do an env.get_class bypassing
the global_environment(), which ends up calling
template_resource.generate_class, which wrongly defaults the get_template_file
allowed schemas to "('file',)"
https://github.com/openstack/heat/blob/master/heat/engine/service.py#L958
https://github.com/openstack/heat/blob/master/heat/engine/resources/template_resource.py#L31
The net result of this is that any call to template-validate which
specifies type: foo.yaml will read that file from the filesystem of the
heat service - this actually means template-validate calls which should
fail work on typical devstack env's where the client and heat-engine are
co-located (it took me a while to work out why!!)
I've not figured out any way for this to be exploitable, but it definitely
seems wrong that we allow user-provided paths to be read like this,
and there could be some risk if folks could work out a way to make
validation blow up with a stack-trace containing any file contents.
Link on original bug: https://bugs.launchpad.net/heat/+bug/1496277 |
|
| 2016-01-13 16:29:26 |
Adam Heczko |
bug |
|
|
added subscriber Adam Heczko |
| 2016-01-13 16:49:34 |
Sergey Kraynev |
mos/8.0.x: assignee |
Oleksii Chuprykov (ochuprykov) |
Sergey Kraynev (skraynev) |
|
| 2016-01-13 16:49:39 |
Sergey Kraynev |
mos/8.0.x: milestone |
|
8.0 |
|
| 2016-01-14 08:17:11 |
Vitaly Sedelnik |
mos/7.0.x: assignee |
Vitaly Sedelnik (vsedelnik) |
MOS Maintenance (mos-maintenance) |
|
| 2016-01-14 08:17:20 |
Vitaly Sedelnik |
mos/7.0.x: milestone |
|
7.0-updates |
|
| 2016-01-14 08:17:24 |
Vitaly Sedelnik |
mos/6.1.x: milestone |
|
6.1-updates |
|
| 2016-01-14 08:17:28 |
Vitaly Sedelnik |
mos/6.0.x: milestone |
|
6.0-updates |
|
| 2016-01-14 08:17:34 |
Vitaly Sedelnik |
mos/5.1.x: milestone |
|
5.1.1-updates |
|
| 2016-01-14 08:17:39 |
Vitaly Sedelnik |
mos/5.0.x: milestone |
|
5.0-updates |
|
| 2016-01-14 08:17:46 |
Vitaly Sedelnik |
mos/6.1.x: assignee |
|
MOS Maintenance (mos-maintenance) |
|
| 2016-01-14 08:17:52 |
Vitaly Sedelnik |
mos/6.0.x: assignee |
|
MOS Maintenance (mos-maintenance) |
|
| 2016-01-14 08:17:58 |
Vitaly Sedelnik |
mos/5.1.x: assignee |
|
MOS Maintenance (mos-maintenance) |
|
| 2016-01-14 08:18:03 |
Vitaly Sedelnik |
mos/5.0.x: assignee |
|
MOS Maintenance (mos-maintenance) |
|
| 2016-01-14 08:18:06 |
Vitaly Sedelnik |
mos/6.1.x: importance |
Undecided |
High |
|
| 2016-01-14 08:18:08 |
Vitaly Sedelnik |
mos/6.0.x: importance |
Undecided |
High |
|
| 2016-01-14 08:18:09 |
Vitaly Sedelnik |
mos/5.1.x: importance |
Undecided |
High |
|
| 2016-01-14 08:18:11 |
Vitaly Sedelnik |
mos/5.0.x: importance |
Undecided |
High |
|
| 2016-01-14 08:18:14 |
Vitaly Sedelnik |
mos/6.1.x: status |
New |
Confirmed |
|
| 2016-01-14 08:18:16 |
Vitaly Sedelnik |
mos/6.0.x: status |
New |
Confirmed |
|
| 2016-01-14 08:18:18 |
Vitaly Sedelnik |
mos/5.1.x: status |
New |
Confirmed |
|
| 2016-01-14 08:18:21 |
Vitaly Sedelnik |
mos/5.0.x: status |
New |
Confirmed |
|
| 2016-01-15 07:45:34 |
Sergey Kraynev |
cve linked |
|
2015-5295 |
|
| 2016-01-19 09:15:44 |
Sergey Kraynev |
mos/8.0.x: status |
Triaged |
Fix Committed |
|
| 2016-01-21 15:00:30 |
Vitaly Sedelnik |
mos/6.1.x: milestone |
6.1-updates |
6.1-mu-5 |
|
| 2016-01-21 15:01:43 |
Vitaly Sedelnik |
mos/7.0.x: milestone |
7.0-updates |
7.0-mu-3 |
|
| 2016-01-21 15:41:05 |
Vitaly Sedelnik |
bug |
|
|
added subscriber Sergii Rizvan |
| 2016-01-21 15:41:16 |
Vitaly Sedelnik |
mos/7.0.x: assignee |
MOS Maintenance (mos-maintenance) |
Sergii Rizvan (srizvan) |
|
| 2016-01-21 15:41:22 |
Vitaly Sedelnik |
mos/6.1.x: assignee |
MOS Maintenance (mos-maintenance) |
Sergii Rizvan (srizvan) |
|
| 2016-01-27 16:36:49 |
Sergii Rizvan |
mos/7.0.x: status |
Triaged |
In Progress |
|
| 2016-02-02 14:43:06 |
Vitaly Sedelnik |
mos/6.0.x: milestone |
6.0-updates |
6.0-mu-8 |
|
| 2016-02-02 14:43:09 |
Vitaly Sedelnik |
mos/5.1.x: milestone |
5.1.1-updates |
5.1.1-mu-3 |
|
| 2016-02-04 10:34:25 |
Vitaly Sedelnik |
mos/6.0.x: assignee |
MOS Maintenance (mos-maintenance) |
Sergii Rizvan (srizvan) |
|
| 2016-02-04 10:54:10 |
Sergii Rizvan |
mos/6.1.x: status |
Confirmed |
In Progress |
|
| 2016-02-04 10:54:19 |
Sergii Rizvan |
mos/5.1.x: assignee |
MOS Maintenance (mos-maintenance) |
Sergii Rizvan (srizvan) |
|
| 2016-02-04 12:44:13 |
Sergii Rizvan |
mos/6.0.x: status |
Confirmed |
In Progress |
|
| 2016-02-09 15:37:23 |
Sergii Rizvan |
mos/5.1.x: status |
Confirmed |
In Progress |
|
| 2016-02-10 20:51:03 |
Vitaly Sedelnik |
mos/6.0.x: status |
In Progress |
Fix Committed |
|
| 2016-02-19 04:49:00 |
Vitaly Sedelnik |
mos/6.1.x: status |
In Progress |
Fix Committed |
|
| 2016-02-19 10:11:27 |
Timur Nurlygayanov |
bug |
|
|
added subscriber Alexander Nagovitsyn |
| 2016-02-19 11:41:28 |
Alexander Nagovitsyn |
tags |
heat |
heat on-verification |
|
| 2016-02-19 13:53:48 |
Sergii Rizvan |
mos/6.0.x: status |
Fix Committed |
Fix Released |
|
| 2016-02-20 14:58:57 |
Alexander Nagovitsyn |
mos/8.0.x: status |
Fix Committed |
Fix Released |
|
| 2016-03-01 08:33:55 |
Vitaly Sedelnik |
information type |
Private Security |
Public Security |
|
| 2016-03-14 14:02:12 |
Dmitry |
tags |
heat on-verification |
heat |
|
| 2016-03-14 14:02:28 |
Dmitry |
tags |
heat |
heat on-verification |
|
| 2016-03-15 10:21:51 |
Vitaly Sedelnik |
mos/7.0.x: status |
In Progress |
Fix Committed |
|
| 2016-03-15 18:12:21 |
Dmitry |
tags |
heat on-verification |
heat |
|
| 2016-03-15 18:12:26 |
Dmitry |
mos/6.1.x: status |
Fix Committed |
Fix Released |
|
| 2016-03-18 11:34:46 |
Alexey Stupnikov |
tags |
heat |
heat wontfix-munotapplic |
|
| 2016-03-18 11:34:57 |
Alexey Stupnikov |
mos/5.0.x: status |
Confirmed |
Won't Fix |
|
| 2016-03-21 11:50:11 |
Dmitry |
tags |
heat wontfix-munotapplic |
heat on-verification wontfix-munotapplic |
|
| 2016-03-22 14:49:18 |
Dmitry |
tags |
heat on-verification wontfix-munotapplic |
heat wontfix-munotapplic |
|
| 2016-03-22 14:51:21 |
Dmitry |
mos/7.0.x: status |
Fix Committed |
Fix Released |
|
| 2016-07-05 14:01:55 |
Vitaly Sedelnik |
mos/5.1.x: status |
In Progress |
Fix Committed |
|
| 2016-12-16 21:03:31 |
Vitaly Sedelnik |
mos/5.1.x: milestone |
5.1.1-mu-3 |
5.1.1-updates |
|
| 2019-08-29 19:58:42 |
Jeremy Stanley |
description |
This issue is being treated as a potential security risk under embargo. Please do not make any public mention of embargoed (private) security vulnerabilities before their coordinated publication by the OpenStack Vulnerability Management Team in the form of an official OpenStack Security Advisory. This includes discussion of the bug or associated fixes in public forums such as mailing lists, code review systems and bug trackers. Please also avoid private disclosure to other individuals not already approved for access to this information, and provide this same reminder to those who are made aware of the issue prior to publication. All discussion should remain confined to this private bug report, and any proposed fixes should be added to the bug as attachments.
in service.py validate_template, we do an env.get_class bypassing
the global_environment(), which ends up calling
template_resource.generate_class, which wrongly defaults the get_template_file
allowed schemas to "('file',)"
https://github.com/openstack/heat/blob/master/heat/engine/service.py#L958
https://github.com/openstack/heat/blob/master/heat/engine/resources/template_resource.py#L31
The net result of this is that any call to template-validate which
specifies type: foo.yaml will read that file from the filesystem of the
heat service - this actually means template-validate calls which should
fail work on typical devstack env's where the client and heat-engine are
co-located (it took me a while to work out why!!)
I've not figured out any way for this to be exploitable, but it definitely
seems wrong that we allow user-provided paths to be read like this,
and there could be some risk if folks could work out a way to make
validation blow up with a stack-trace containing any file contents.
Link on original bug: https://bugs.launchpad.net/heat/+bug/1496277 |
in service.py validate_template, we do an env.get_class bypassing
the global_environment(), which ends up calling
template_resource.generate_class, which wrongly defaults the get_template_file
allowed schemas to "('file',)"
https://github.com/openstack/heat/blob/master/heat/engine/service.py#L958
https://github.com/openstack/heat/blob/master/heat/engine/resources/template_resource.py#L31
The net result of this is that any call to template-validate which
specifies type: foo.yaml will read that file from the filesystem of the
heat service - this actually means template-validate calls which should
fail work on typical devstack env's where the client and heat-engine are
co-located (it took me a while to work out why!!)
I've not figured out any way for this to be exploitable, but it definitely
seems wrong that we allow user-provided paths to be read like this,
and there could be some risk if folks could work out a way to make
validation blow up with a stack-trace containing any file contents.
Link on original bug: https://bugs.launchpad.net/heat/+bug/1496277 |
|
