[Yahoo-eng-team] [Bug 1813439] Re: an instance can see other instances' unicast packages when security group firewall_driver is openvswitch
** Also affects: ossn Importance: Undecided Status: New ** No longer affects: ossn -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1813439 Title: an instance can see other instances' unicast packages when security group firewall_driver is openvswitch Status in neutron: Confirmed Status in OpenStack Security Advisory: Incomplete Bug description: We found that instances on the same host can see each others' unicast packages out to instances on the different host if these instances are on the same subnet when security group firewall_driver is openvswitch. # How to reproduce 1. create 3 vms on the same subnet, no matter vlan or vxlan, called them vm1, vm2, vm3: vm1: 192.168.100.3 (compute 1) vm2: 192.168.100.12 (compute 1) vm3: 192.168.100.17 (compute 2) vm1 and vm2 are on the same host, while vm3 is on the other host. 2. ping vm3 from vm2 3. tcpdump eth0 on vm1, you will see icmp request packages from vm2 to vm3 are captured # tcpdump -enni eth0 icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 09:01:59.361792 fa:16:3e:8e:49:5c > fa:16:3e:8f:ca:a7, ethertype IPv4 (0x0800), length 98: 192.168.100.12 > 192.168.100.17: ICMP echo request, id 1145, seq 4, length 64 09:02:00.361772 fa:16:3e:8e:49:5c > fa:16:3e:8f:ca:a7, ethertype IPv4 (0x0800), length 98: 192.168.100.12 > 192.168.100.17: ICMP echo request, id 1145, seq 5, length 64 09:02:01.361785 fa:16:3e:8e:49:5c > fa:16:3e:8f:ca:a7, ethertype IPv4 (0x0800), length 98: 192.168.100.12 > 192.168.100.17: ICMP echo request, id 1145, seq 6, length 64 09:02:02.361798 fa:16:3e:8e:49:5c > fa:16:3e:8f:ca:a7, ethertype IPv4 (0x0800), length 98: 192.168.100.12 > 192.168.100.17: ICMP echo request, id 1145, seq 7, length 64 4. ping vm2 from vm3 5. tcpdump eth0 on vm1, you will see icmp reply packages from vm2 to vm3 are captured # tcpdump -enni eth0 icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 09:03:39.608748 fa:16:3e:8e:49:5c > fa:16:3e:8f:ca:a7, ethertype IPv4 (0x0800), length 98: 192.168.100.12 > 192.168.100.17: ICMP echo reply, id 1144, seq 3, length 64 09:03:40.609475 fa:16:3e:8e:49:5c > fa:16:3e:8f:ca:a7, ethertype IPv4 (0x0800), length 98: 192.168.100.12 > 192.168.100.17: ICMP echo reply, id 1144, seq 4, length 64 09:03:41.609444 fa:16:3e:8e:49:5c > fa:16:3e:8f:ca:a7, ethertype IPv4 (0x0800), length 98: 192.168.100.12 > 192.168.100.17: ICMP echo reply, id 1144, seq 5, length 64 TCP/UDP packages have the same problem, this will have performance issue and security problem on the production. This will not happen when the security group firewall driver is iptables_hybrid or disable port security. # Versions I am testing this on N and R release, both have the same problem, the R release neutron package versions are: openstack-neutron-ml2-13.0.2-1.el7.noarch openstack-neutron-openvswitch-13.0.2-1.el7.noarch python2-neutronclient-6.9.1-1.el7.noarch openstack-neutron-common-13.0.2-1.el7.noarch openstack-neutron-fwaas-13.0.1-1.el7.noarch openstack-neutron-13.0.2-1.el7.noarch openstack-neutron-lbaas-13.0.0-1.el7.noarch python2-neutron-lib-1.18.0-1.el7.noarch python-neutron-lbaas-13.0.0-1.el7.noarch python-neutron-13.0.2-1.el7.noarch python-neutron-fwaas-13.0.1-1.el7.noarch and the operating system and kernel are: [root@node-30 ~]# cat /etc/redhat-release CentOS Linux release 7.5.1804 (Core) [root@node-30 ~]# uname -a Linux node-30 3.10.0-862.9.1.el7.x86_64 #1 SMP Mon Jul 16 16:29:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux and the openvswitch version is : openvswitch-2.9.0-3.el7.x86_64 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1813439/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1837339] Re: CIDR's of the form 12.34.56.78/0 should be an error
According to the VMT's taxonomy ( https://security.openstack.org/vmt- process.html#incident-report-taxonomy ) this seems like a class D. ** Also affects: ossn Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1837339 Title: CIDR's of the form 12.34.56.78/0 should be an error Status in OpenStack Dashboard (Horizon): New Status in OpenStack Security Advisory: Incomplete Status in OpenStack Security Notes: New Bug description: The problem is that some users do not understand how CIDRs work, and incorrectly use /0 when they are trying to specify a single IP or a subnet in an Access Rule. Unfortunately 12.34.56.78/0 means the same thing as 0.0.0.0/0. The proposed fix is to insist that /0 only be used with 0.0.0.0/0 and the IPv6 equivalent ::/0 when entering or updating Access Rule CIDRs in via the dashboard. I am labeling this as a security vulnerability since it leads to naive users creating instances with ports open to the world when they didn't intend to do that. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1837339/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1813439] Re: an instance can see other instances' unicast packages when security group firewall_driver is openvswitch
Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions. Is this a mis-configuration from neutron or is it an ovs issue? ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Incomplete -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1813439 Title: an instance can see other instances' unicast packages when security group firewall_driver is openvswitch Status in neutron: New Status in OpenStack Security Advisory: Incomplete Bug description: We found that instances on the same host can see each others' unicast packages out to instances on the different host if these instances are on the same subnet when security group firewall_driver is openvswitch. # How to reproduce 1. create 3 vms on the same subnet, no matter vlan or vxlan, called them vm1, vm2, vm3: vm1: 192.168.100.3 (compute 1) vm2: 192.168.100.12 (compute 1) vm3: 192.168.100.17 (compute 2) vm1 and vm2 are on the same host, while vm3 is on the other host. 2. ping vm3 from vm2 3. tcpdump eth0 on vm1, you will see icmp request packages from vm2 to vm3 are captured # tcpdump -enni eth0 icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 09:01:59.361792 fa:16:3e:8e:49:5c > fa:16:3e:8f:ca:a7, ethertype IPv4 (0x0800), length 98: 192.168.100.12 > 192.168.100.17: ICMP echo request, id 1145, seq 4, length 64 09:02:00.361772 fa:16:3e:8e:49:5c > fa:16:3e:8f:ca:a7, ethertype IPv4 (0x0800), length 98: 192.168.100.12 > 192.168.100.17: ICMP echo request, id 1145, seq 5, length 64 09:02:01.361785 fa:16:3e:8e:49:5c > fa:16:3e:8f:ca:a7, ethertype IPv4 (0x0800), length 98: 192.168.100.12 > 192.168.100.17: ICMP echo request, id 1145, seq 6, length 64 09:02:02.361798 fa:16:3e:8e:49:5c > fa:16:3e:8f:ca:a7, ethertype IPv4 (0x0800), length 98: 192.168.100.12 > 192.168.100.17: ICMP echo request, id 1145, seq 7, length 64 4. ping vm2 from vm3 5. tcpdump eth0 on vm1, you will see icmp reply packages from vm2 to vm3 are captured # tcpdump -enni eth0 icmp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 09:03:39.608748 fa:16:3e:8e:49:5c > fa:16:3e:8f:ca:a7, ethertype IPv4 (0x0800), length 98: 192.168.100.12 > 192.168.100.17: ICMP echo reply, id 1144, seq 3, length 64 09:03:40.609475 fa:16:3e:8e:49:5c > fa:16:3e:8f:ca:a7, ethertype IPv4 (0x0800), length 98: 192.168.100.12 > 192.168.100.17: ICMP echo reply, id 1144, seq 4, length 64 09:03:41.609444 fa:16:3e:8e:49:5c > fa:16:3e:8f:ca:a7, ethertype IPv4 (0x0800), length 98: 192.168.100.12 > 192.168.100.17: ICMP echo reply, id 1144, seq 5, length 64 TCP/UDP packages have the same problem, this will have performance issue and security problem on the production. This will not happen when the security group firewall driver is iptables_hybrid or disable port security. # Versions I am testing this on N and R release, both have the same problem, the R release neutron package versions are: openstack-neutron-ml2-13.0.2-1.el7.noarch openstack-neutron-openvswitch-13.0.2-1.el7.noarch python2-neutronclient-6.9.1-1.el7.noarch openstack-neutron-common-13.0.2-1.el7.noarch openstack-neutron-fwaas-13.0.1-1.el7.noarch openstack-neutron-13.0.2-1.el7.noarch openstack-neutron-lbaas-13.0.0-1.el7.noarch python2-neutron-lib-1.18.0-1.el7.noarch python-neutron-lbaas-13.0.0-1.el7.noarch python-neutron-13.0.2-1.el7.noarch python-neutron-fwaas-13.0.1-1.el7.noarch and the operating system and kernel are: [root@node-30 ~]# cat /etc/redhat-release CentOS Linux release 7.5.1804 (Core) [root@node-30 ~]# uname -a Linux node-30 3.10.0-862.9.1.el7.x86_64 #1 SMP Mon Jul 16 16:29:36 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux and the openvswitch version is : openvswitch-2.9.0-3.el7.x86_64 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1813439/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1742102] Re: Simple user can disable compute
Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions. ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Incomplete -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1742102 Title: Simple user can disable compute Status in OpenStack Compute (nova): In Progress Status in OpenStack Security Advisory: Incomplete Bug description: Hi, When I tested a fresh deploy of Pike, I created a private network with a little subnet like /28. If you try to create a lot of new instances, nova failed because which doesn't have free IP for the creation of new instances. The fail trace is https://thepasteb.in/p/zmh8qDG2ZYJIZ So after that, the trigger consecutive_build_service_disable_threshold up to 10 very fast and computes are disable. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1742102/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1774527] Re: Too many errors can trigger compute failed_builds to get incremented
*** This bug is a duplicate of bug 1742102 *** https://bugs.launchpad.net/bugs/1742102 ** Also affects: ossa Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1774527 Title: Too many errors can trigger compute failed_builds to get incremented Status in OpenStack Compute (nova): New Status in OpenStack Security Advisory: New Bug description: So let's analyze what can cause a compute managers failed_builds to get incremented and point out that some of them should not be causing failed_builds to get incremented (which then can have the 'nice' effect of auto-disabling a nova-compute service). So the return code of self._do_build_and_run_instance returns a result code; the catch of all exceptions also triggers the setting of a result code to failed; when this is failed it will cause the failed_build counter to get incremented. Some unrelated to nova-compute exceptions that from reading the code can trigger this to happen: - Unable to base64 decode injected files. - Failure of notify_about_instance_create to actually send (some inner exception perhaps?) - exception.NoMoreNetworks, exception.NoMoreFixedIps - exception.FlavorDiskTooSmall, exception.FlavorMemoryTooSmall, exception.ImageNotActive, exception.ImageUnacceptable, exception.InvalidDiskInfo, exception.InvalidDiskFormat, cursive_exception.SignatureVerificationError, exception.VolumeEncryptionNotSupported, exception.InvalidInput, exception.RequestedVRamTooHigh --- these bubble up as BuildAbortException - exception.InstanceNotFound, exception.UnexpectedDeletingTaskStateError - Anything that pops out of _build_resources - Failed to allocate network And many more? To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1774527/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1711117] Re: paste_deploy flavor in sample configuration file shows misleading default
** Also affects: ossn Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/177 Title: paste_deploy flavor in sample configuration file shows misleading default Status in Glance: New Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: The "flavor" option of the "[paste_deploy]" section defaults to "None", but the sample configuration and documentation [1] suggests that it is "keystone". This can lead to unsecure deployments without authentication. The "glance-api.conf" file shows the following: # # Deployment flavor to use in the server application pipeline. # # Provide a string value representing the appropriate deployment # flavor used in the server application pipleline. This is typically # the partial name of a pipeline in the paste configuration file with # the service name removed. # # For example, if your paste section name in the paste configuration # file is [pipeline:glance-api-keystone], set ``flavor`` to # ``keystone``. # # Possible values: # * String value representing a partial pipeline name. # # Related Options: # * config_file # # (string value) #flavor = keystone This is misleading and can lead operators to think that the default flavor being used is "keystone", but this is not the case: DEBUG glance.common.config [-] paste_deploy.flavor= None log_opt_values /usr/lib/python2.7/dist- packages/oslo_config/cfg.py:2626 Previously, in Mitaka, the flavor was defined something like this: # Partial name of a pipeline in your paste configuration file with the # service name removed. For example, if your paste section name is # [pipeline:glance-api-keystone] use the value "keystone" (string # value) #flavor = Therefore, somebody upgrading from a previous version would think that the default is now set to "keystone" instead of "None". In such cases the operator could remove the "flavor=keystone" definition, assuming that the default value is correct. Moreover, the configuration reference states that the default is "keystone" [1], but this is not the case as the option does not set a default vale, but a sample default [2] [1] https://docs.openstack.org/glance/latest/configuration/glance_api.html#paste_deploy [2] https://github.com/openstack/glance/blob/c4b0fbe632f759b00a1c326c17a05f134e93553d/glance/common/config.py#L33 Taking into account that if the flavor for paste is not set this will lead to a deployment without authentication. If the sample default is different from the actual default, this should be stated clearly in the comment for that option. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/177/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1736674] Re: sg rules are sometimes not applied
Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions. ** Also affects: ossa Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1736674 Title: sg rules are sometimes not applied Status in neutron: New Status in OpenStack Security Advisory: New Bug description: Failure of negative test in gate: http://logs.openstack.org/19/523319/5/check/neutron-tempest-plugin- scenario-linuxbridge/47b85c6/job- output.txt.gz#_2017-12-01_23_09_02_843619 Reproducing locally with a debug patch, I see that iptables_manager first applies the correct rules and then removes them again immediately after that, see http://paste.openstack.org/show/628245/ Steps to reproduce (taken from neutron_tempest_plugin.scenario.test_security_groups.NetworkDefaultSecGroupTest.test_ip_prefix_negative, possibly not minimal): - create two security groups - add ssh access to first, icmp access to second one - create an instance with these two security groups applied - run iptables-save and discover no rules applied to the instance To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1736674/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1708580] Re: ovsfw ignores port_ranges under some conditions
IWAMOTO, I guess you could use this definition: https://cve.mitre.org/about/terminology.html#vulnerability Then regarding the OSSA task, we don't issue advisories for experimental feature, and if I understand correctly, ovsfw is still experimental/incomplete. Thus if it's not a class D, then it is at best a class B3. I have created an OSSN task to discuss the scope of this bug, perhaps it could use a security note. ** Also affects: ossn Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1708580 Title: ovsfw ignores port_ranges under some conditions Status in neutron: Fix Released Status in OpenStack Security Advisory: Incomplete Status in OpenStack Security Notes: New Bug description: ovsfw ignores port_ranges when protocol is not literal udp or tcp. sctp and numeric protocol values don't work and result in too permissive filtering. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1708580/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1708580] Re: ovsfw ignores port_ranges under some conditions
Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions. Back in Mitaka, OVS was an experimental security groups driver. Is it deemed production ready in Newton ? ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Incomplete -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1708580 Title: ovsfw ignores port_ranges under some conditions Status in neutron: In Progress Status in OpenStack Security Advisory: Incomplete Bug description: ovsfw ignores port_ranges when protocol is not literal udp or tcp. sctp and numeric protocol values don't work and result in too permissive filtering. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1708580/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1668503] Re: sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing
Adding OSSN task based on comment #3 ** Also affects: ossn Importance: Undecided Status: New ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1668503 Title: sha512_crypt is insufficient, use pbkdf2_sha512 for password hashing Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) mitaka series: Won't Fix Status in OpenStack Identity (keystone) newton series: Won't Fix Status in OpenStack Identity (keystone) ocata series: Won't Fix Status in OpenStack Identity (keystone) pike series: Fix Released Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: Keystone uses sha512_crypt for password hashing. This is insufficient and provides limited protection (even with 10,000 rounds) against brute-forcing of the password hashes (especially with FPGAs and/or GPU processing). The correct mechanism is to use bcrypt, scrypt, or pbkdf2_sha512 instead of sha512_crypt. This bug is marked as public security as bug #1543048 has already highlighted this issue. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1668503/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1703369] Re: get_identity_providers policy should be singular
I've added an OSSN task to see if a Security Note would make more sense here since this is kind of an insecure default config value (class B2). ** Also affects: ossn Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1703369 Title: get_identity_providers policy should be singular Status in OpenStack Identity (keystone): In Progress Status in OpenStack Identity (keystone) newton series: New Status in OpenStack Identity (keystone) ocata series: New Status in OpenStack Security Advisory: Incomplete Status in OpenStack Security Notes: New Bug description: identity:get_identity_providers should be identity:get_identity_provider (singular) since a GET is targeted on a single provider and the code is setup to check for identity:get_identity_provider (singular). See https://github.com/openstack/keystone/blob/c7e29560b7bf7a44e44722eea0645bf18ad56af3/keystone/federation/controllers.py#L112 found in master (pike) The ocata default policy.json also has this problem. Unless someone manually overrode policy to specify identity:get_identity_provider (singular), the result would be that the default rule was actually used for that check instead of identity:get_identity_providers. We could go back and fix the default policy.json for past releases, but the default actually has the same value as identity:get_identity_providers, and if nobody has complained it's probably safer to just leave it. It is, after all, just defaults there and anyone can override by specifying the correct value. But we must fix in pike to go along with the shift of policy into code. Policy defaults in code definitely need to match up with what the code actually checks. There should no longer be any reliance on the default rule. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1703369/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1618615] Re: Potential information disclosure in EC2 "credentials"
Switched to public security, closed the OSSA task and added an OSSN task
based on above comments.
** Description changed:
- 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.
-
-
When creating a "credential" in Keystone, instead of using uuid.uuid4()
like in most places to generate a unique identifier, the id is created
from the SHA256 hash value of whatever is passed in as the "access" key
in the POST request (Code here:
https://github.com/openstack/keystone/blob/master/keystone/credential/controllers.py#L36-L60)
= EXAMPLE REQUEST =
POST /v3/credentials HTTP/1.1
Host: [ENDPOINT]
X-Auth-Token: [ADMIN TOKEN]
Content-Length: 231
Content-Type: application/json
{
"credential": {
"blob":
"{\"access\":\"alert(2)\",\"secret\":\"secretKey\"}",
"project_id": "12345",
"type": "ec2",
"user_id": "12345"
}
}
HTTP/1.1 201 Created
Date: Tue, 30 Aug 2016 19:14:54 GMT
Server: Apache/2.4.7 (Ubuntu)
Vary: X-Auth-Token
Content-Length: 383
Content-Type: application/json
{"credential": {"user_id": "12345", "links": {"self":
"[ENDPOINT]/v3/credentials/141ce7a938b5973dd71c90bcdd7e4097317ee7374259cf6d8774fdfd86c1f8ea"},
"blob":
"{\"access\":\"alert(2)\",\"secret\":\"secretKey\"}",
"project_id": "12345", "type": "ec2", "id":
"141ce7a938b5973dd71c90bcdd7e4097317ee7374259cf6d8774fdfd86c1f8ea"}}
= /EXAMPLE =
The id from the example above is
"141ce7a938b5973dd71c90bcdd7e4097317ee7374259cf6d8774fdfd86c1f8ea",
which is the same as the SHA256 value of "alert(2)"
(you can test this with `echo -n "alert(2)" | openssl
dgst -sha256` on *nix)
The documentation here seems to show MD5s and possibly tenant IDs used
as "access" values: http://developer.openstack.org/api-
ref/identity/v3/?expanded=assign-role-to-user-on-projects-owned-by-
domain-detail,create-policy-detail,show-credential-details-detail,list-
credentials-detail,create-credential-detail#list-credentials
Bruteforcing an actual MD5 isn't a huge security risk (i.e. trying to
predict all 32 characters from thin air), but if the MD5 is a hash of a
known value (i.e. the string "admin"), it would be trivial to test for
common values:
md5(admin) = 21232f297a57a5a743894a0e4a801fc3
sha256(21232f297a57a5a743894a0e4a801fc3) =
465c194afb65670f38322df087f0a9bb225cc257e43eb4ac5a0c98ef5b3173ac
If tenant IDs are used, this task becomes even easier: just generate
SHA256 hashes for 0 - 99
A non-admin user can determine whether there are credentials using a
given access key by attempting to access the resource from its sha256
url identifier:
= EXAMPLE REQUESTS =
Existing credential
GET
/v3/credentials/141ce7a938b5973dd71c90bcdd7e4097317ee7374259cf6d8774fdfd86c1f8ea
HTTP/1.1
Host: [ENDPOINT]
X-Auth-Token: [NON-ADMIN TOKEN]
Content-Type: application/json
Connection: close
HTTP/1.1 403 Forbidden
Date: Tue, 30 Aug 2016 19:55:24 GMT
Server: Apache/2.4.7 (Ubuntu)
Vary: X-Auth-Token
Content-Length: 140
Content-Type: application/json
{"error": {"message": "You are not authorized to perform the
requested action: identity:get_credential", "code": 403, "title":
"Forbidden"}}
Non-existent credential
GET /v3/credentials/deadbeef HTTP/1.1
Host: [ENDPOINT]
X-Auth-Token: [NON-ADMIN TOKEN]
Content-Type: application/json
HTTP/1.1 404 Not Found
Date: Tue, 30 Aug 2016 20:03:38 GMT
Server: Apache/2.4.7 (Ubuntu)
Vary: X-Auth-Token
Content-Length: 96
Content-Type: application/json
{"error": {"message": "Could not find credential: deadbeef", "code":
404, "title": "Not Found"}}
= /EXAMPLE =
It is also possible to get a 500 error by creating a credential with an
invalid character in the "access" key:
= EXAMPLE REQUEST =
POST /v3/credentials HTTP/1.1
Host: [ENDPOINT]
X-Auth-Token: [ADMIN TOKEN]
Content-Length: 212
Content-Type: application/json
{
[Yahoo-eng-team] [Bug 1682062] Re: Nova polcy allows all users with same tenant to delete/resize servers with all roles (viewer, non-admin roles)
Since this report concerns a possible security risk, an incomplete
security advisory task has been added while the core security reviewers
for the affected project or projects confirm the bug and discuss the
scope of any vulnerability along with potential solutions.
** Also affects: ossa
Importance: Undecided
Status: New
** Changed in: ossa
Status: New => Incomplete
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1682062
Title:
Nova polcy allows all users with same tenant to delete/resize servers
with all roles (viewer, non-admin roles)
Status in OpenStack Compute (nova):
New
Status in OpenStack Security Advisory:
Incomplete
Bug description:
Nova policies mention the rule as "admin_or_owner" for critical
compute operations such as resize, update, create_server, reboot etc,
which basically should be allowed ONLY for ADMIN OR OWNER of the
server instance. But current nova policy allows all users
(irrespective of admin, viewer, member) to perform these operations.
For eg: If User1 (member user) creates an instance(eg test_server)
under demo tenant and User2 (viewer user) is able to resize
test_server or delete test_server, whereas User2 should be allowed to
ONLY VIEW test_server and not able to perform any operation.
Although Openstack users can update the custom policy.py/policy.json files,
the naming convention is a misnomer as it says ADMIN_OR_OWNER which is a big
security vulnerability. We need to change the default behavior of Nova
operations to allow only following scenarios
1. ONLY Admin belonging to the tenant should create/update/resize/delete
server instances
2. OWNER User who created the Instance should be able to
create/update/resize/delete server instances.
Apart from above scenarios, we should not allow any other user to
perform such critical operations even as a default operation for NOVA.
stack@devstack:~/devstack$ nova show test_server_pk
/usr/local/lib/python2.7/dist-packages/novaclient/client.py:278: UserWarning:
The 'tenant_id' argument is deprecated in Ocata and its use may result in
errors in future releases. As 'project_id' is provided, the 'tenant_id'
argument will be ignored.
warnings.warn(msg)
+--++
| Property | Value
|
+--++
| OS-DCF:diskConfig| MANUAL
|
| OS-EXT-AZ:availability_zone | nova
|
| OS-EXT-STS:power_state | 1
|
| OS-EXT-STS:task_state| -
|
| OS-EXT-STS:vm_state | active
|
| OS-SRV-USG:launched_at | 2017-04-12T08:42:59.00
|
| OS-SRV-USG:terminated_at | -
|
| accessIPv4 |
|
| accessIPv6 |
|
| config_drive |
|
| created | 2017-04-11T12:09:23Z
|
| description | -
|
| flavor | ds512M (d1)
|
| hostId |
87b5e4756d250749a8c02c0afa91c37ae08654b85c3a46903767b78d |
| id | b209b443-0a94-407f-aa5b-a0ce8d426add
|
| image| cirros-0.3.4-x86_64-uec
(f4e982cb-5d76-4782-bf90-172a067fbf11) |
| key_name | -
|
| locked | False
|
| metadata | {}
|
| name | test_server_pk
|
| os-extended-volumes:volumes_attached | []
|
| private network
[Yahoo-eng-team] [Bug 1649248] Re: Glance image upload wizard does not restrict invalid image files
Opening this report and adding an OSSN task based on above comments. ** Description changed: - 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. - - -- - An unrestricted file upload exists when an application allows users to upload files without proper validation. glance fails to properly validate image files across four key factors including file extension, mime-type, size, and upload frequency. In addition, glance does not appear to scan uploaded files for known malware. Failing to restrict file uploads affects the security of the OpenStack environment in a number of ways. Attacker may commonly use file upload functionality to upload viruses or malware onto trusted servers. In addition to spreading malware, attacker can upload source code files (.aspx and .jsp for example) which may be rendered as valid application pages to end users. Additionally, if users are able to upload files of any size or at any frequency, an attacker may abuse this functionality to exhaust the server’s disk space. Steps To Reproduce: 1. Login to the OpenStack as an admin 2. Click on Images tab and create a new image by uploading a EICAR text file with anti-malware string (EICAR anti-malware test file can be downloaded from http://www.eicar.org/ ) 3. Observe that file is uploaded successfully without any pre-checks being done. The application should validate uploaded files for type and size, and limit how often the user is able to perform uploads. The following validation can be performed: a) If the application requires uploaded files to be of a specific type such as img, vmdk, the application should validate the extension. b) The first four bytes of the file i.e. Magic Numbers can be validated. These first few bytes are known as the file’s ‘Magic Number’ and will uniquely identify the file type. For example all PDF files start with the byte-sequence ‘%PDF’. c) An upper limit on file size can be enforced. In addition to the primary criteria above, all uploaded files should be scanned for known malware/viruses. ** Changed in: ossa Status: Incomplete => Won't Fix ** Information type changed from Private Security to Public ** Also affects: ossn Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1649248 Title: Glance image upload wizard does not restrict invalid image files Status in OpenStack Dashboard (Horizon): New Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: An unrestricted file upload exists when an application allows users to upload files without proper validation. glance fails to properly validate image files across four key factors including file extension, mime-type, size, and upload frequency. In addition, glance does not appear to scan uploaded files for known malware. Failing to restrict file uploads affects the security of the OpenStack environment in a number of ways. Attacker may commonly use file upload functionality to upload viruses or malware onto trusted servers. In addition to spreading malware, attacker can upload source code files (.aspx and .jsp for example) which may be rendered as valid application pages to end users. Additionally, if users are able to upload files of any size or at any frequency, an attacker may abuse this functionality to exhaust the server’s disk space. Steps To Reproduce: 1. Login to the OpenStack as an admin 2. Click on Images tab and create a new image by uploading a EICAR text file with anti-malware string (EICAR anti-malware test file can be downloaded from http://www.eicar.org/ ) 3. Observe that file is uploaded successfully without any pre-checks being done. The application should validate uploaded files for type and size, and limit how often the user is able to perform uploads. The following validation can be performed: a) If the application requires uploaded files to be of a specific type such as img, vmdk, the application should validate the extension. b) The first four bytes of the file i.e. Magic Numb
[Yahoo-eng-team] [Bug 1606500] Re: [OSSA 2016-013] Heat: template source URL allows network port scan (CVE-2016-9185)
** Summary changed:
- Heat: template source URL allows network port scan (CVE-2016-9185)
+ [OSSA 2016-013] Heat: template source URL allows network port scan
(CVE-2016-9185)
** Changed in: ossa
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1606500
Title:
[OSSA 2016-013] Heat: template source URL allows network port scan
(CVE-2016-9185)
Status in heat:
Fix Released
Status in OpenStack Dashboard (Horizon):
Invalid
Status in OpenStack Security Advisory:
Fix Released
Bug description:
Launching a new Heat stack and giving the template from an URL like
http://localhost:22
Results in an error message like:
ERROR: Could not retrieve template: Failed to retrieve template:
('Connection aborted.', BadStatusLine('SSH-2.0-OpenSSH_6.6.1\r\n',))
This is a security issue as it allows users to scan the network for
listening ports.
heat CLI does not allow that:
heat stack-create -u http://localhost:22 test
[Errno 104] Connection reset by peer
To manage notifications about this bug go to:
https://bugs.launchpad.net/heat/+bug/1606500/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1606500] Re: Heat: template source URL allows network port scan
CVE has been requested with this affect line: <=5.0.3, >=6.0.0 <=6.1.0
and ==7.0.0
@Daniel, the bug is now public, feel free to submit patches to gerrit
for master (Ocata), Newton, Mikata and Liberty.
** Description changed:
- 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.
-
Launching a new Heat stack and giving the template from an URL like
http://localhost:22
Results in an error message like:
ERROR: Could not retrieve template: Failed to retrieve template:
('Connection aborted.', BadStatusLine('SSH-2.0-OpenSSH_6.6.1\r\n',))
This is a security issue as it allows users to scan the network for
listening ports.
heat CLI does not allow that:
heat stack-create -u http://localhost:22 test
[Errno 104] Connection reset by peer
** Information type changed from Private Security to Public Security
** Changed in: ossa
Status: Incomplete => In Progress
** Changed in: horizon
Status: New => Invalid
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1606500
Title:
Heat: template source URL allows network port scan
Status in heat:
Triaged
Status in OpenStack Dashboard (Horizon):
Invalid
Status in OpenStack Security Advisory:
In Progress
Bug description:
Launching a new Heat stack and giving the template from an URL like
http://localhost:22
Results in an error message like:
ERROR: Could not retrieve template: Failed to retrieve template:
('Connection aborted.', BadStatusLine('SSH-2.0-OpenSSH_6.6.1\r\n',))
This is a security issue as it allows users to scan the network for
listening ports.
heat CLI does not allow that:
heat stack-create -u http://localhost:22 test
[Errno 104] Connection reset by peer
To manage notifications about this bug go to:
https://bugs.launchpad.net/heat/+bug/1606500/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1625619] Re: It is possible to download key pair for other user at the same project
Removed the security tags since it's a class E (or at best class D) according to the VMT taxonomy: https://security.openstack.org/vmt- process.html#incident-report-taxonomy. ** Information type changed from Public Security to Public ** Changed in: ossa Status: Incomplete => Won't Fix ** Tags removed: security -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1625619 Title: It is possible to download key pair for other user at the same project Status in OpenStack Dashboard (Horizon): New Status in OpenStack Identity (keystone): New Status in OpenStack Compute (nova): New Status in OpenStack Security Advisory: Won't Fix Bug description: Bug was reproduced in mitaka openstack release. Steps to reproduce: 1. Login to horizon. 2. Click Project-> Compute -> Access and Security 3. Click "Key Pairs" tab 4. Click "Create Key Pair" button, enter keypair name. 5. On the next screen with download key dialog copy URL from browser URL field URL will be like http://server/horizon/project/access_and_security/keypairs//download 6. Click cancel to close download window. 7. Click Project->Compute->Instances. 8. In opened window select other key pair name from KEY PAIR column (it could be key pair for different user) 9. open new browser window, paste URL string from step 5. 10. Change in URL with name obtained from step 8 and press enter You will be prompted to download private key for other user. It isn't correct user should be able to download only his own keys To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1625619/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1625833] Re: Prevent open redirects as a result of workflow action
I agree on the C1 class. ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1625833 Title: Prevent open redirects as a result of workflow action Status in OpenStack Dashboard (Horizon): In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: For example: /admin/flavors/create/?next=http://www.foobar.com/ If a user is tricked into clicking that link, the flavor create workflow will be shown, but the redirect on form post will unexpectedly take the user to another site. Prevent this by checking that the next_url in WorkflowView.post is same origin. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1625833/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1625619] Re: It is possible to download key pair for other user at the same project
Oops, wrong bug updated. Well now that this is public, I've added keystone to check that bug. ** Also affects: keystone Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1625619 Title: It is possible to download key pair for other user at the same project Status in OpenStack Dashboard (Horizon): New Status in OpenStack Identity (keystone): New Status in OpenStack Security Advisory: Incomplete Bug description: Bug was reproduced in mitaka openstack release. Steps to reproduce: 1. Login to horizon. 2. Click Project-> Compute -> Access and Security 3. Click "Key Pairs" tab 4. Click "Create Key Pair" button, enter keypair name. 5. On the next screen with download key dialog copy URL from browser URL field URL will be like http://server/horizon/project/access_and_security/keypairs//download 6. Click cancel to close download window. 7. Click Project->Compute->Instances. 8. In opened window select other key pair name from KEY PAIR column (it could be key pair for different user) 9. open new browser window, paste URL string from step 5. 10. Change in URL with name obtained from step 8 and press enter You will be prompted to download private key for other user. It isn't correct user should be able to download only his own keys To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1625619/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1407092] Re: cinder-api reflects JavaScript input
** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1407092 Title: cinder-api reflects JavaScript input Status in Cinder: Won't Fix Status in OpenStack Dashboard (Horizon): Invalid Status in Mirantis OpenStack: Invalid Status in Mirantis OpenStack 5.0.x series: Won't Fix Status in Mirantis OpenStack 5.1.x series: Won't Fix Status in Mirantis OpenStack 6.0.x series: Won't Fix Status in Mirantis OpenStack 6.1.x series: Won't Fix Status in Mirantis OpenStack 7.0.x series: Invalid Status in Mirantis OpenStack 9.x series: Invalid Status in OpenStack Security Advisory: Won't Fix Bug description: cinder-api reflects JavaScript input which could be used to perform Cross-Site-Scripting attack on a browser which is visiting Horizon interface and working with cinder related gui items To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1407092/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1589821] Re: cleanup_incomplete_migrations periodic task regression with commit 099cf53 (CVE-2016-7498)
** Changed in: ossa Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1589821 Title: cleanup_incomplete_migrations periodic task regression with commit 099cf53 (CVE-2016-7498) Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) mitaka series: Fix Committed Status in OpenStack Security Advisory: Fix Released Bug description: Patch [1] changes the instance filtering condition in periodic task "cleanup_incomplete_migrations" introduced in [2], in such a way that it generates new issue, [3] After change [1] lands, the condition changes filtering logic, so now all instances on current host are filtered, which is not expected. We should filter all instances where instance uuids are associated with migration records and those migration status is set to 'error' and instance is marked as deleted. [1] https://review.openstack.org/#/c/256102/ [2] https://review.openstack.org/#/c/219299/ [2] https://bugs.launchpad.net/nova/+bug/1586309 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1589821/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1618879] Re: iptables rule always be thrashed when update a little rule
Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions. I've add the OSSA task since it's reported as a Security bug, though it doesn't like a vulnerability but more of a bug with (some) security implications (class D according to VMT taxonomy). ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Incomplete -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1618879 Title: iptables rule always be thrashed when update a little rule Status in neutron: In Progress Status in OpenStack Security Advisory: Incomplete Bug description: When update meter label or rule, iptables_manager will update iptables rule in router's namespace. In order to, it will clean traffic counter number collected in interval time, the other iptables always trashing that will clean old iptalbes rule and generate new same significance iptables rule. the example from update meter label: Generated by iptables_manager *filter :neutron-meter-neutron-met - [0:0] :neutron-meter-r-00599199-632 - [0:0] -I FORWARD 2 -j neutron-meter-FORWARD -D FORWARD 4 -I INPUT 1 -j neutron-meter-INPUT -D INPUT 3 -I OUTPUT 2 -j neutron-meter-OUTPUT -D OUTPUT 4 -I neutron-filter-top 1 -j neutron-meter-local -D neutron-filter-top 3 -D neutron-meter-l-00e4e019-099 1 -I neutron-meter-l-00e4e019-099 1 -D neutron-meter-l-01e4e019-099 1 -I neutron-meter-l-01e4e019-099 1 -I neutron-meter-r-00599199-632 1 -i qg-f0732f6f-8e -d 192.168.10.0/24 -j neutron-meter-l-00599199-632 COMMIT # Completed by iptables_manager # Generated by iptables_manager *raw -I OUTPUT 1 -j neutron-meter-OUTPUT -D OUTPUT 3 -I PREROUTING 1 -j neutron-meter-PREROUTING -D PREROUTING 3 COMMIT # Completed by iptables_manager To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1618879/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1611991] Re: [ovs firewall] Port 23 is open on booted vms with only ping/ssh on 22 allowed.
Closing the OSSA task, reason: B3 type of bug according to VMT taxonomy ( https://security.openstack.org/vmt-process.html#incident-report- taxonomy ). ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1611991 Title: [ovs firewall] Port 23 is open on booted vms with only ping/ssh on 22 allowed. Status in neutron: In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: Seen on master devstack, ubuntu xenial. Steps to reproduce: 1. Enable ovs firewall in /etc/neutron/plugins/ml2/ml2.conf [securitygroup] firewall_driver = openvswitch 2. Create a security group with icmp, tcp to 22. 3. Boot a VM, assign a floating ip. 4. Check that port 23 can be accessed via tcp (telnet, nc, etc). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1611991/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1597864] Re: Horizon exposes keystone endpoint url when viewing login source code
Closing the OSSA task, reason: C1 type of bug according to VMT taxonomy ( https://security.openstack.org/vmt-process.html#incident-report- taxonomy ). ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1597864 Title: Horizon exposes keystone endpoint url when viewing login source code Status in OpenStack Dashboard (Horizon): Invalid Status in OpenStack Security Advisory: Won't Fix Bug description: When viewing source code on Horizon login this line of code is exposing the Keystone internal url endpoint. Both examples are default, no customizations. MOS 6.1 http://172.16.108.2:5000/v2.0"; /> root@node-6:~# openstack endpoint show keystone +--+--+ | Field| Value| +--+--+ | adminurl | http://172.16.108.2:35357/v2.0 | | enabled | True | | id | 4f781d4ac9f9463d9ab37632146d45bc | | internalurl | http://172.16.108.2:5000/v2.0| | publicurl| http://172.16.107.226:5000/v2.0 | | region | RegionOne| | service_id | 1a4391f1448a4225846e0a9d01b9af90 | | service_name | keystone | | service_type | identity | +--+—+ http://pastebin.com/yHC8eT8g MOS 8.0 http://192.168.0.2:5000/v2.0"; /> root@node-27:~# openstack endpoint show identity +--+--+ | Field| Value| +--+--+ | adminurl | http://192.168.0.2:35357/v2.0| | enabled | True | | id | 2c02316fd1684863b1858da06a766535 | | internalurl | http://192.168.0.2:5000/v2.0 | | publicurl| http://172.16.0.3:5000/v2.0 | | region | RegionOne| | service_id | 6e7a33ba6751453fb96d497244a89470 | | service_name | keystone | | service_type | identity | +--+--+ I was not able to find an associated CVE for this issue but it looks like there should be. Environment MOS 6.1, 8.0 To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1597864/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1611171] Re: re-runs self via sudo
Since this report concerns a possible security risk, an incomplete
security advisory task has been added while the core security reviewers
for the affected project or projects confirm the bug and discuss the
scope of any vulnerability along with potential solutions.
It seems like a class D type of bug (e.g., hardening opportunity)
according to VMT taxonomy ( https://security.openstack.org/vmt-
process.html#incident-report-taxonomy ).
** Also affects: ossa
Importance: Undecided
Status: New
** Changed in: ossa
Status: New => Incomplete
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1611171
Title:
re-runs self via sudo
Status in Cinder:
New
Status in Designate:
In Progress
Status in ec2-api:
New
Status in gce-api:
New
Status in Manila:
New
Status in masakari:
New
Status in OpenStack Compute (nova):
New
Status in OpenStack Security Advisory:
Incomplete
Status in Rally:
New
Bug description:
Hello, I'm looking through Designate source code to determine if is
appropriate to include in Ubuntu Main. This isn't a full security
audit.
This looks like trouble:
./designate/cmd/manage.py
def main():
CONF.register_cli_opt(category_opt)
try:
utils.read_config('designate', sys.argv)
logging.setup(CONF, 'designate')
except cfg.ConfigFilesNotFoundError:
cfgfile = CONF.config_file[-1] if CONF.config_file else None
if cfgfile and not os.access(cfgfile, os.R_OK):
st = os.stat(cfgfile)
print(_("Could not read %s. Re-running with sudo") % cfgfile)
try:
os.execvp('sudo', ['sudo', '-u', '#%s' % st.st_uid] +
sys.argv)
except Exception:
print(_('sudo failed, continuing as if nothing happened'))
print(_('Please re-run designate-manage as root.'))
sys.exit(2)
This is an interesting decision -- if the configuration file is _not_
readable by the user in question, give the executing user complete privileges
of the user that owns the unreadable file.
I'm not a fan of hiding privilege escalation / modifications in
programs -- if a user had recently used sudo and thus had the
authentication token already stored for their terminal, this 'hidden'
use of sudo may be unexpected and unwelcome, especially since it
appears that argv from the first call leaks through to the sudo call.
Is this intentional OpenStack style? Or unexpected for you guys too?
(Feel free to make this public at your convenience.)
Thanks
To manage notifications about this bug go to:
https://bugs.launchpad.net/cinder/+bug/1611171/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1567673] Re: [OSSA-2016-010] Possible client side template injection in horizon (CVE-2016-4428)
** Changed in: ossa Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1567673 Title: [OSSA-2016-010] Possible client side template injection in horizon (CVE-2016-4428) Status in OpenStack Dashboard (Horizon): Fix Released Status in OpenStack Security Advisory: Fix Released Bug description: I'm working through my groups process to deploy a new web app so that we can provide openstack in our production environment. Part of that process is having an authenticated security scan done by Acunetix. I've attached a screenshot of the report for the alert received during the scan. Unfortunately I'm not a dev, so I'm not sure if this is a false alarm or not. Quick research found the following link which talks about the issue in general: http://blog.portswigger.net/2016/01/xss-without-html-client- side-template.html Any input would be greatly appreciated. Thanks! Brandon To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1567673/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1502933] Re: [OSSA-2016-009] ICMPv6 anti-spoofing rules are too permissive (CVE-2015-8914)
** Summary changed:
- ICMPv6 anti-spoofing rules are too permissive (CVE-2015-8914)
+ [OSSA-2016-009] ICMPv6 anti-spoofing rules are too permissive (CVE-2015-8914)
** Changed in: ossa
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1502933
Title:
[OSSA-2016-009] ICMPv6 anti-spoofing rules are too permissive
(CVE-2015-8914)
Status in neutron:
Fix Committed
Status in OpenStack Security Advisory:
Fix Released
Bug description:
ICMPv6 default firewall rules are too permissive on the hypervisors
leaving VMs able to do ICMPv6 source address spoofing.
Pre-condition:
- having a provider-network providing IPv6 connectivity to the VMs
- in my case the controllers are providing statefull DHCPv6 and my physical
router provides the default gateway using Router Advertisements.
How to reproduce:
- spin a VM and attach to it an IPv6 enabled network
- obtain an IPv6 address using #dhclient -6
- try to ping6 an IPv6 enabled host
- remove your IPv6 address from the interface: #sudo ip addr del
2001:0DB8::100/32 dev eth0
- add a forged IPv6 address to your interface, into the same subnet of the
original IPv6 address: #sudo ip addr add 2001:0DB8::200/32 dev eth0
- try to ping6 the previous IPv6 enabled host, it will still work
- try to assign another IPv6 address to your NIC, completely outside your
IPv6 assignment: sudo ip addr add 2001:dead:beef::1/64 dev eth0
- try to ping6 the previous IPv6 enabled host -> the destination will still
receive your echo requests with your forget address but you won't receive
answers, they won't be router back to you.
Expected behavior:
- VMs should not be able to spoof their IPv6 address and issue forged
ICMPv6 packets. The firewall rules on the hypervisor should restrict
ICMPv6 egress to the VMs link-local and global-unicast addresses.
Affected versions:
- I saw the issue into OpenStack Juno, under Ubuntu 14.04. But
according to the upstream code, the issue is still present into the
master branch, into; neutron/agent/linux/iptables_firewall.py, into
line 385:
ipv6_rules += [comment_rule('-p icmpv6 -j RETURN',
comment=ic.IPV6_ICMP_ALLOW)]
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1502933/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1558658] Re: [OSSA-2016-009] Security Groups do not prevent MAC and/or IPv4 spoofing in DHCP requests (CVE-2016-5362 and CVE-2016-5363)
** Summary changed:
- Security Groups do not prevent MAC and/or IPv4 spoofing in DHCP requests
(CVE-2016-5362 and CVE-2016-5363)
+ [OSSA-2016-009] Security Groups do not prevent MAC and/or IPv4 spoofing in
DHCP requests (CVE-2016-5362 and CVE-2016-5363)
** Changed in: ossa
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1558658
Title:
[OSSA-2016-009] Security Groups do not prevent MAC and/or IPv4
spoofing in DHCP requests (CVE-2016-5362 and CVE-2016-5363)
Status in neutron:
Fix Released
Status in neutron kilo series:
Fix Released
Status in OpenStack Security Advisory:
Fix Released
Bug description:
The IptablesFirewallDriver does not prevent spoofing other instances
or a routers MAC and/or IP addresses. The rule to permit DHCP
discovery and request messages:
ipv4_rules += [comment_rule('-p udp -m udp --sport 68 --dport 67 '
'-j RETURN', comment=ic.DHCP_CLIENT)]
is too permissive, it does not enforce the source MAC or IP address.
This is the IPv4 case of public bug
https://bugs.launchpad.net/neutron/+bug/1502933, and a solution was
previously mentioned in June 2013 in
https://bugs.launchpad.net/neutron/+bug/1427054.
If L2population is not used, an instance can spoof the Neutron
router's MAC address and cause the switches to learn a MAC move,
allowing the instance to intercept other instances traffic potentially
belonging to other tenants if this is shared network.
The solution for this is to permit this DHCP traffic only from the
instance's IP address and the unspecified IPv4 address 0.0.0.0/32
rather than from an IPv4 source, additionally the source MAC address
should be restricted to MAC addresses assigned to the instance's
Neutron port.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1558658/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1575225] Re: Neutron only permits IPv6 MLDv1 not v2
Ok my bad, then the OSSA task needs to be removed. Thanks! ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1575225 Title: Neutron only permits IPv6 MLDv1 not v2 Status in neutron: In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: IPv6 Multicast Listener Discovery (MLD) v2 [1] is used on recent version of Linux, currently Neutron only permits MLDv1 in the ICMPV6_ALLOWED_TYPES, so duplicate address discovery (DAD) doesn't not actually detect duplicate addresses should Neutron actually enforce ICMPv6 source addresses (bug/1502933). While Neutron should not assign duplicate addresses, instances where duplicate addresses are possible on provider networks between instances and external devices and on user assign addresses when using allowed address pairs. Here is a dump showing duplicate address detection on a recent Linux kernel: $ uname -r 4.4.0-0.bpo.1-amd64 $ sudo ip link add veth0 type veth peer name veth1 $ sudo ip link set veth1 up $ sudo tcpdump -npel -i veth1 & [1] 15528 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on veth1, link-type EN10MB (Ethernet), capture size 262144 bytes $ sudo ip link set veth0 up $ 09:47:38.853762 5e:9b:3c:4f:a3:e0 > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 09:47:38.853774 b2:29:3a:34:bc:eb > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 09:47:39.113772 b2:29:3a:34:bc:eb > 33:33:ff:34:bc:eb, ethertype IPv6 (0x86dd), length 78: :: > ff02::1:ff34:bceb: ICMP6, neighbor solicitation, who has fe80::b029:3aff:fe34:bceb, length 24 09:47:39.141766 5e:9b:3c:4f:a3:e0 > 33:33:ff:4f:a3:e0, ethertype IPv6 (0x86dd), length 78: :: > ff02::1:ff4f:a3e0: ICMP6, neighbor solicitation, who has fe80::5c9b:3cff:fe4f:a3e0, length 24 09:47:39.505764 b2:29:3a:34:bc:eb > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 09:47:39.717759 5e:9b:3c:4f:a3:e0 > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 09:47:40.113807 b2:29:3a:34:bc:eb > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: fe80::b029:3aff:fe34:bceb > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 09:47:40.113827 b2:29:3a:34:bc:eb > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: fe80::b029:3aff:fe34:bceb > ff02::2: ICMP6, router solicitation, length 16 09:47:40.121756 b2:29:3a:34:bc:eb > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: fe80::b029:3aff:fe34:bceb > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 09:47:40.141811 5e:9b:3c:4f:a3:e0 > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: fe80::5c9b:3cff:fe4f:a3e0 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 09:47:40.141836 5e:9b:3c:4f:a3:e0 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: fe80::5c9b:3cff:fe4f:a3e0 > ff02::2: ICMP6, router solicitation, length 16 09:47:40.149763 5e:9b:3c:4f:a3:e0 > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: fe80::5c9b:3cff:fe4f:a3e0 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 1. https://www.ietf.org/rfc/rfc3810.txt To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1575225/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1577558] Re: [OSSA 2016-008] v2.0 fernet tokens audit ids are inconsistent (CVE-2016-4911)
** Changed in: ossa Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1577558 Title: [OSSA 2016-008] v2.0 fernet tokens audit ids are inconsistent (CVE-2016-4911) Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Security Advisory: Fix Released Bug description: If you set the token provider to token.provider = fernet, get an unscoped token from v2.0, then rescope that token to a project, you'll notice the audit ids don't match. I've recreated this issue in a test [0]. What should happen is that the unscoped token response will have a list of audit_ids containing a single audit_id. The project scoped token response from the unscoped token will also have a list of audit_ids in the token response but the original audit_id from the unscoped token will be in the list of the project scoped token. Right now this behavior doesn't exist in with the fernet provider on v2.0. [0] https://review.openstack.org/#/c/311816/1 To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1577558/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1589821] Re: cleanup_incomplete_migrations periodic task regression with commit 099cf53925c0a0275325339f21932273ee9ce2bc
Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions. So IIUC, nova mitaka version(s) is affected by OSSA 2015-017. Does the impact description still applies ? Title: Nova may fail to delete images in resize state Description: If an authenticated user deletes an instance while it is in resize state, it will cause the original instance to not be deleted from the compute node it was running on. An attacker can use this to launch a denial of service attack. All Nova setups are affected. This may need a new OSSA for this regression. ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Incomplete -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1589821 Title: cleanup_incomplete_migrations periodic task regression with commit 099cf53925c0a0275325339f21932273ee9ce2bc Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) mitaka series: Fix Committed Status in OpenStack Security Advisory: Incomplete Bug description: Patch [1] changes the instance filtering condition in periodic task "cleanup_incomplete_migrations" introduced in [2], in such a way that it generates new issue, [3] After change [1] lands, the condition changes filtering logic, so now all instances on current host are filtered, which is not expected. We should filter all instances where instance uuids are associated with migration records and those migration status is set to 'error' and instance is marked as deleted. [1] https://review.openstack.org/#/c/256102/ [2] https://review.openstack.org/#/c/219299/ [2] https://bugs.launchpad.net/nova/+bug/1586309 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1589821/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1575909] Re: VPN shared PSK shown in plaintext
Based on above comment, I removed the OSSA task. ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1575909 Title: VPN shared PSK shown in plaintext Status in OpenStack Dashboard (Horizon): New Status in OpenStack Security Advisory: Won't Fix Bug description: In the neutron VPN details and form, https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/vpn/templates/vpn/_ipsecsiteconnection_details.html#L43 and https://github.com/openstack/horizon/blob/master/openstack_dashboard/dashboards/project/vpn/forms.py#L249 don't offer the option of hiding the string. Typically sensitive information like passwords is hidden by default, requiring the user to explicitly choose to make it visible by clicking an icon (like the eye icon). Filing this as a security bug out of an overabundance of caution; while it is related to security it doesn't describe a vulnerability that can be exploited by means other than shoulder surfing. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1575909/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1584510] [NEW] internal server error when using a boolean instead of router port id
Public bug reported:
When calling the neutron-server api directly with '{"port_id": false}' like:
curl -X PUT
http://127.0.0.1:9696/v2.0/routers/${ROUTER_ID}/add_router_interface.json -d
'{"port_id": false}'
The neutron.api.v2.resource fails with this exception:
Traceback (most recent call last):
File "neutron/db/l3_dvr_db.py", line 252, in add_router_interface
context, router, interface_info['port_id'], device_owner)
File "neutron/db/l3_db.py", line 600, in _add_interface_by_port
self._check_router_port(context, port_id, '')
File "neutron/db/l3_db.py", line 586, in _check_router_port
port = self._core_plugin.get_port(context, port_id)
File "neutron/db/db_base_plugin_v2.py", line 1344, in get_port
port = self._get_port(context, id)
File "neutron/db/db_base_plugin_common.py", line 224, in _get_port
port = self._get_by_id(context, models_v2.Port, id)
File "neutron/db/common_db_mixin.py", line 212, in _get_by_id
return query.filter(model.id == id).one()
File "sqlalchemy/orm/query.py", line 2702, in one
"Multiple rows were found for one()")
MultipleResultsFound: Multiple rows were found for one()
It seems like the _get_by_id method expects a uuid str and it is fooled
by a boolean that get used in the sqlalchemy filter. The error is miss-
leading and could be prevented if the port_id type was forced to be a
string.
While this doesn't affect the service availability, it gets quickly
overly verbose when port_id is an empty list (e.g.: '{"port_id": []}'),
then the server.log grow by 13k per request, see attached log file.
** Affects: neutron
Importance: Undecided
Status: New
** Attachment added: "dberror_traceback.txt"
https://bugs.launchpad.net/bugs/1584510/+attachment/4668187/+files/dberror_traceback.txt
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1584510
Title:
internal server error when using a boolean instead of router port id
Status in neutron:
New
Bug description:
When calling the neutron-server api directly with '{"port_id": false}' like:
curl -X PUT
http://127.0.0.1:9696/v2.0/routers/${ROUTER_ID}/add_router_interface.json -d
'{"port_id": false}'
The neutron.api.v2.resource fails with this exception:
Traceback (most recent call last):
File "neutron/db/l3_dvr_db.py", line 252, in add_router_interface
context, router, interface_info['port_id'], device_owner)
File "neutron/db/l3_db.py", line 600, in _add_interface_by_port
self._check_router_port(context, port_id, '')
File "neutron/db/l3_db.py", line 586, in _check_router_port
port = self._core_plugin.get_port(context, port_id)
File "neutron/db/db_base_plugin_v2.py", line 1344, in get_port
port = self._get_port(context, id)
File "neutron/db/db_base_plugin_common.py", line 224, in _get_port
port = self._get_by_id(context, models_v2.Port, id)
File "neutron/db/common_db_mixin.py", line 212, in _get_by_id
return query.filter(model.id == id).one()
File "sqlalchemy/orm/query.py", line 2702, in one
"Multiple rows were found for one()")
MultipleResultsFound: Multiple rows were found for one()
It seems like the _get_by_id method expects a uuid str and it is
fooled by a boolean that get used in the sqlalchemy filter. The error
is miss-leading and could be prevented if the port_id type was forced
to be a string.
While this doesn't affect the service availability, it gets quickly
overly verbose when port_id is an empty list (e.g.: '{"port_id":
[]}'), then the server.log grow by 13k per request, see attached log
file.
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1584510/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1575225] Re: Neutron only permits IPv6 MLDv1 not v2
Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions. ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Incomplete -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1575225 Title: Neutron only permits IPv6 MLDv1 not v2 Status in neutron: In Progress Status in OpenStack Security Advisory: Incomplete Bug description: IPv6 Multicast Listener Discovery (MLD) v2 [1] is used on recent version of Linux, currently Neutron only permits MLDv1 in the ICMPV6_ALLOWED_TYPES, so duplicate address discovery (DAD) doesn't not actually detect duplicate addresses should Neutron actually enforce ICMPv6 source addresses (bug/1502933). While Neutron should not assign duplicate addresses, instances where duplicate addresses are possible on provider networks between instances and external devices and on user assign addresses when using allowed address pairs. Here is a dump showing duplicate address detection on a recent Linux kernel: $ uname -r 4.4.0-0.bpo.1-amd64 $ sudo ip link add veth0 type veth peer name veth1 $ sudo ip link set veth1 up $ sudo tcpdump -npel -i veth1 & [1] 15528 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on veth1, link-type EN10MB (Ethernet), capture size 262144 bytes $ sudo ip link set veth0 up $ 09:47:38.853762 5e:9b:3c:4f:a3:e0 > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 09:47:38.853774 b2:29:3a:34:bc:eb > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 09:47:39.113772 b2:29:3a:34:bc:eb > 33:33:ff:34:bc:eb, ethertype IPv6 (0x86dd), length 78: :: > ff02::1:ff34:bceb: ICMP6, neighbor solicitation, who has fe80::b029:3aff:fe34:bceb, length 24 09:47:39.141766 5e:9b:3c:4f:a3:e0 > 33:33:ff:4f:a3:e0, ethertype IPv6 (0x86dd), length 78: :: > ff02::1:ff4f:a3e0: ICMP6, neighbor solicitation, who has fe80::5c9b:3cff:fe4f:a3e0, length 24 09:47:39.505764 b2:29:3a:34:bc:eb > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 09:47:39.717759 5e:9b:3c:4f:a3:e0 > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: :: > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 09:47:40.113807 b2:29:3a:34:bc:eb > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: fe80::b029:3aff:fe34:bceb > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 09:47:40.113827 b2:29:3a:34:bc:eb > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: fe80::b029:3aff:fe34:bceb > ff02::2: ICMP6, router solicitation, length 16 09:47:40.121756 b2:29:3a:34:bc:eb > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: fe80::b029:3aff:fe34:bceb > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 09:47:40.141811 5e:9b:3c:4f:a3:e0 > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: fe80::5c9b:3cff:fe4f:a3e0 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 09:47:40.141836 5e:9b:3c:4f:a3:e0 > 33:33:00:00:00:02, ethertype IPv6 (0x86dd), length 70: fe80::5c9b:3cff:fe4f:a3e0 > ff02::2: ICMP6, router solicitation, length 16 09:47:40.149763 5e:9b:3c:4f:a3:e0 > 33:33:00:00:00:16, ethertype IPv6 (0x86dd), length 90: fe80::5c9b:3cff:fe4f:a3e0 > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 1. https://www.ietf.org/rfc/rfc3810.txt To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1575225/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1534652] Re: Host machine exposed to tenant networks via IPv6
Based on a similar report (bug 1302080), I've closed the OSSA task. However I've added an OSSN task to discuss an eventual Note about compute and controller firewalling requirements. ** Also affects: ossn Importance: Undecided Status: New ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1534652 Title: Host machine exposed to tenant networks via IPv6 Status in networking-midonet: Fix Released Status in neutron: Fix Released Status in neutron kilo series: New Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: When creating a new interface Neutron creates interface and brings link up without disabling default IPv6 binding. By default Linux brings IPv6 link local addresses to all interfaces, this is different behavior than IPv4 where an administrator must explicitly configure an address on the interface. The is significantly exposed in LinuxBridgeManager ensure_vlan() and ensure_vxlan() where a new VLAN or VXLAN interface is created and set link up before being enslaved in the bridge. In the case of compute node joining and existing network, there is a time window in which VLAN or VXLAN interface is created and has connectivity to the tenant network before it has been enslaved in bridge. Under normal circumstances this time window is less than the time needed to preform IPv6 duplicate address detection, but under high load this assumption may not hold. I recommend explicitly disabling IPv6 via sysctl on each interface which will be attached to a bridge prior bringing the interface link up. This is already done for the bridge interfaces themselves, but should be done for all Neutron configured interfaces in the default namespace. This issue was referenced in https://bugs.launchpad.net/neutron/+bug/1459856 Related issue addressed being addressed in Nova: https://review.openstack.org/#/c/198054/ To manage notifications about this bug go to: https://bugs.launchpad.net/networking-midonet/+bug/1534652/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1576765] Re: Potential DOS: Keystone Extra Fields
Based on above comments, I've switch that bug to public and removed the OSSA task. ** Information type changed from Private Security to Public ** Description changed: - 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. - - -- - A user that has rights to update a resource in Keystone (project, user, domain, etc) can inject extra data (near unlimited amounts) with data that is only limited by the maximum request size. The extra fields cannot be deleted (ever) in the current design (the value of the field can be set to ~1byte minimum). An update excluding the field leaves the field data intact as is. This means that a bad actor can update a keystone resource and do one of the following to DOS Keystone cluster, database replication, database traffic, etc: 1) Create endless numbers of fields with very little data, that will cause longer and longer json serialization/deserailization times due to the volume of elements. 2) Create endless numbers of fields with large data sets, increasing the delta of what is stored in the RDBMS and putting extra load on the replication/etc processes for the shared data. This potentially could be used as a vector to run the DB server out of ram/cache/buffers/disk. This also causes the issue itemized above (1). 3) With HMT, it is possible to duplicate (as a domain/user) the above listed items with more and more resources. Memcache/caching will offset some of these issues until the memcache server can no longer store the data from the keystone resource due to exceeding the slab size (1MB) which could cause excessive load on the memcached servers/caching servers. With caching enabled, it is possible to run the keystone processes out of memory/DOS due to the request_local cache in use to ensure that the resources are fetched from the backend a single time (using a msgpack of the data stored in memory) for a given HTTP request. --- PROPOSED FIX -- * Issue a security bug fix that by default disables the ability to store data in the extra fields for *ALL* keystone resources * Migrate any/all fields that keystone supports to first class-attributes (columns) in the SQL backend[s]. * 2-Cycle deprecation before removal of the support for "extra" field storage (toggled via config value) - in the P Cycle extra fields will no longer be supported. All non-standard data will need to be migrated to an external metadata storage. ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1576765 Title: Potential DOS: Keystone Extra Fields Status in OpenStack Identity (keystone): New Status in OpenStack Security Advisory: Won't Fix Bug description: A user that has rights to update a resource in Keystone (project, user, domain, etc) can inject extra data (near unlimited amounts) with data that is only limited by the maximum request size. The extra fields cannot be deleted (ever) in the current design (the value of the field can be set to ~1byte minimum). An update excluding the field leaves the field data intact as is. This means that a bad actor can update a keystone resource and do one of the following to DOS Keystone cluster, database replication, database traffic, etc: 1) Create endless numbers of fields with very little data, that will cause longer and longer json serialization/deserailization times due to the volume of elements. 2) Create endless numbers of fields with large data sets, increasing the delta of what is stored in the RDBMS and putting extra load on the replication/etc processes for the shared data. This potentially could be used as a vector to run the DB server out of ram/cache/buffers/disk. This also causes the issue itemized above (1). 3) With HMT, it is possible to duplicate (as a domain/user) the above listed items with more and more resources. Memcache/caching will offset some of these issues until the memcache server can no longer store the data from the keystone resource due to exceeding the slab size (1MB) which could caus
[Yahoo-eng-team] [Bug 1553324] Re: potential DOS with revoke by id or audit_id
** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1553324 Title: potential DOS with revoke by id or audit_id Status in OpenStack Identity (keystone): New Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: New Bug description: With our default policy, token revocation can be self-served. Without any rate limiting or SIEM mechanism in place, any user can potentially flood the revocation_event table to cause significant performance degradation or worst DOS. I've attached a simple script to continuously revoking one's own token and time the token validation time. On a vanilla devstack, with dogpile cache enabled, token validation time go from roughly 40ms to over 300ms with about 2K revocation events. We don't cleanup the revocation events till token expiration plus expiration_buffer, which is 30 minutes by default. With the default token TTL of 3600 seconds, a user could potentially fill up at least a few thousand events during that time. I know this may sound like a broken record, and yes, rate limiting or SIEM should be used. Perhaps we can add this to security hardening or OSSN? In the long run, I think we need to rethink how we handle revoke by ID as self-service. Now that we have shadow user accounts, maybe we can implement something to suspend that user if we detect token revocation abuse? To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1553324/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1558697] Re: [kilo] libvirt block migrations fail due to disk_info being an encoded JSON string
** Changed in: ossa Status: Confirmed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1558697 Title: [kilo] libvirt block migrations fail due to disk_info being an encoded JSON string Status in OpenStack Compute (nova): Invalid Status in OpenStack Compute (nova) kilo series: Fix Committed Status in OpenStack Security Advisory: Fix Released Bug description: The fix for OSSA 2016-007 / CVE-2016-2140 in f302bf04 assumed that disk_info is always a plain, decoded list. However prior to Liberty when preforming a live block migration the compute manager populates disk_info with an encoded JSON string when calling self.driver.get_instance_disk_info. In the live migration case without block migration disk_info remains a plain decoded list. More details with an example trace downstream in the following bug : live migration without shared storage fails in pre_live_migration after upgrade to 2015.1.2-18.2 https://bugzilla.redhat.com/show_bug.cgi?id=1318722 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1558697/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1558697] Re: [kilo] libvirt block migrations fail due to disk_info being an encoded JSON string
Since f302bf04 was referenced in the advisory, we may have to send another ERRATA to include the additional patch. I've added an OSSA task to keep track of that effort. ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Incomplete -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1558697 Title: [kilo] libvirt block migrations fail due to disk_info being an encoded JSON string Status in OpenStack Compute (nova): Invalid Status in OpenStack Compute (nova) kilo series: In Progress Status in OpenStack Security Advisory: Incomplete Bug description: The fix for OSSA 2016-007 / CVE-2016-2140 in f302bf04 assumed that disk_info is always a plain, decoded list. However prior to Liberty when preforming a live block migration the compute manager populates disk_info with an encoded JSON string when calling self.driver.get_instance_disk_info. In the live migration case without block migration disk_info remains a plain decoded list. More details with an example trace downstream in the following bug : live migration without shared storage fails in pre_live_migration after upgrade to 2015.1.2-18.2 https://bugzilla.redhat.com/show_bug.cgi?id=1318722 To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1558697/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1548450] Re: [OSSA 2016-007] Host data leak during resize/migrate for raw-backed instances (CVE-2016-2140)
** Changed in: ossa Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1548450 Title: [OSSA 2016-007] Host data leak during resize/migrate for raw-backed instances (CVE-2016-2140) Status in OpenStack Compute (nova): Fix Released Status in OpenStack Compute (nova) kilo series: Fix Committed Status in OpenStack Compute (nova) liberty series: Fix Committed Status in OpenStack Security Advisory: Fix Released Bug description: First, a caveat. This report is from code inspection only. I haven't attempted to replicate it, and I have no immediate plans to. It's possible it doesn't exist due to an interaction which isn't immediately obvious. When resizing an instance using the libvirt driver, we run LibvirtDriver.migrate_disk_and_power_off on the source host. If there is no shared storage, data is copied. Specifically, there's a loop in that function which loops over disk info: for info in disk_info: # assume inst_base == dirname(info['path']) ... copy the disk Note that this doesn't copy disk.info, because it's not a disk. I have actually confirmed this whilst investigating another bug. The problem with this is that disk.info contains file format information, which means that when the instance starts up again, the format of all its disks are re-inspected. This is the bug. It means that a malicious user can write data to an ephemeral or root disk which fakes a qcow2 header, and on re-inspection it will be detected as qcow2 and data from a user-specified backing file will be served. I am moderately confident that this is a real bug. Unlike the previous file format bug I reported, though, this bug would be mitigated by the fact that the user would have to access the disk via libvirt/qemu. Assuming they haven't disabled SELinux (nobody does that, right?) this severely limits the data which can be accessed, possibly to the point that it isn't worth exploiting. I also believe it would only be exploitable on deployments using raw storage, which I believe isn't common. Given that I don't think it's all that serious in practise, I'm not going to work on this immediately as I don't have the time. If it's still around when I'm less busy I'll pick it up. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1548450/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1129748] Re: image files in _base should not be world-readable
The /var/lib/nova/instances directory is likely to be a packaging issue, I don't know how disk image mode bits are set, but at least the disk info is explicitly written as 644 by nova/virt/libvirt/imagebackend.py. Anyway I closed the OSSA task since multi-user system is not a realistic threat for openstack system. ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1129748 Title: image files in _base should not be world-readable Status in OpenStack Compute (nova): Opinion Status in OpenStack Security Advisory: Won't Fix Bug description: Already public in https://bugzilla.redhat.com/show_bug.cgi?id=896085 , so probably no point making this private. But I checked the security vulnerability box anyway so someone else can decide. We create image files in /var/lib/nova/instances/_base with default permissions, usually 644. It would be better to not make the image files world-readable, in case they contain private data. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1129748/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1129748] Re: image files in _base should not be world-readable
Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions. I agree with Robert, this expose OpenStack user instance data to all context running on the compute node. Shell users aside, I fail to see why would apache or even the nobody user be allowed to list and read disk files. ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Incomplete -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1129748 Title: image files in _base should not be world-readable Status in OpenStack Compute (nova): Opinion Status in OpenStack Security Advisory: Incomplete Bug description: Already public in https://bugzilla.redhat.com/show_bug.cgi?id=896085 , so probably no point making this private. But I checked the security vulnerability box anyway so someone else can decide. We create image files in /var/lib/nova/instances/_base with default permissions, usually 644. It would be better to not make the image files world-readable, in case they contain private data. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1129748/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1545789] Re: keystone ADMIN_TOKEN set by default can lead to default insecure deployment
Agreed on the B1 (insecure default value), and I added an OSSN task for an eventual Security Note. Thank! ** Also affects: ossn Importance: Undecided Status: New -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1545789 Title: keystone ADMIN_TOKEN set by default can lead to default insecure deployment Status in OpenStack Identity (keystone): Triaged Status in OpenStack Security Notes: New Bug description: The Keystone configuration sets the ADMIN_TOKEN option to "ADMIN" by default, which means that unless the deployment specifically changes this value to a secure value, the filter "admin_auth_token" will accept the value of "ADMIN" as an all-access administrative token for the openstack deployment (when interacting with keystone). https://github.com/openstack/keystone/blob/406fbfaa2689255fb54cf1eb07403f392c735c53/keystone/common/config.py#L49-L56 The fix will be to make this value "None" by default, and if the option is unset, the "admin_token_auth" filter will simply pass, continuing to allow normal credentials to work. This is a CLASS B1 (my assessment) https://security.openstack.org/vmt- process.html#incident-report-taxonomy This bug was opened so we can issue an OSSA/OSSN with the fix. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1545789/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1540208] Re: CSRF mechanism is not safe.
** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1540208 Title: CSRF mechanism is not safe. Status in OpenStack Dashboard (Horizon): Invalid Status in OpenStack Security Advisory: Won't Fix Bug description: I'm using burp suite to check secure of horizon 8.0.0.0. CSRF mechanism is not safe. I saw : csrftoken equals with csrfmidlewaretoken ==> the reques is valid. Example: Do update network's name. The first request: - I got csrftoken and csrfmidlewaretoken: PvVPmsOEqepSWnWgJa1GKYtBxcSXMTu1 - network's name : attt_net_test_129 then I change csrftoken and csrfmidlewaretoken to "1" , network 's name value to "attt_net_test_121" Final, do send request ==> Network is updated succesfuly. (attach file) To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1540208/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1525915] Re: [OSSA 2016-006] Normal user can change image status if show_multiple_locations has been set to true (CVE-2016-0757)
** Description changed:
- 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.
-
- --
-
User (non admin) can set image back to queued state by deleting
location(s) from image when "show_multiple_locations" config parameter
has been set to true.
This breaks the immutability promise glance has similar way as described
in OSSA 2015-019 as the image gets transitioned from active to queued
and new image data can be uploaded.
ubuntu@devstack-02:~/devstack$ glance image-show
f4bb4c9e-71ba-4a8c-b70a-640dbe37b3bc
+--+--+
| Property | Value
|
+--+--+
| checksum | eb9139e4942121f22bbc2afc0400b2a4
|
| container_format | ami
|
| created_at | 2015-12-14T09:58:54Z
|
| disk_format | ami
|
| id | f4bb4c9e-71ba-4a8c-b70a-640dbe37b3bc
|
| locations| [{"url":
"file:///opt/stack/data/glance/images/f4bb4c9e-71ba-4a8c-b70a- |
| | 640dbe37b3bc", "metadata": {}}]
|
| min_disk | 0
|
| min_ram | 0
|
| name | cirros-test
|
| owner| ab69274aa31a4fba8bf559af2b0b98bd
|
| protected| False
|
| size | 25165824
|
| status | active
|
| tags | []
|
| updated_at | 2015-12-14T09:58:54Z
|
| virtual_size | None
|
| visibility | private
|
+--+--+
ubuntu@devstack-02:~/devstack$ glance location-delete --url
file:///opt/stack/data/glance/images/f4bb4c9e-71ba-4a8c-b70a-640dbe37b3bc
f4bb4c9e-71ba-4a8c-b70a-640dbe37b3bc
ubuntu@devstack-02:~/devstack$ glance image-show
f4bb4c9e-71ba-4a8c-b70a-640dbe37b3bc
+--+--+
| Property | Value|
+--+--+
| checksum | eb9139e4942121f22bbc2afc0400b2a4 |
| container_format | ami |
| created_at | 2015-12-14T09:58:54Z |
| disk_format | ami |
| id | f4bb4c9e-71ba-4a8c-b70a-640dbe37b3bc |
| locations| [] |
| min_disk | 0|
| min_ram | 0|
| name | cirros-test |
| owner| ab69274aa31a4fba8bf559af2b0b98bd |
| protected| False|
| size | None |
| status | queued |
| tags | [] |
| updated_at | 2015-12-14T13:43:23Z
[Yahoo-eng-team] [Bug 1528676] Re: OpenLDAP password policy not enforced for password changes
Agreed on class D, I closed the OSSA task, this could be re-opened whenever the situation changes. ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1528676 Title: OpenLDAP password policy not enforced for password changes Status in OpenStack Identity (keystone): New Status in OpenStack Security Advisory: Won't Fix Bug description: Hello there, I'm on Ubuntu 14.04.3, Openstack Juno and OpenLDAP v2.4.31 releases. I configured OpenLDAP as an identity backend for Keystone and configured it according to official documentation from: http://docs.openstack.org/developer/keystone/configuration.html I'd like my users to be able to change their own passwords, but at the same time OpenLDAP password policy to be enforced upon password changes. I've set to true all allow_creates, allow_updates and allow_deletes not to be restricted in any way by keystone. The problem is the following: RootDN account is used for binding when the user is changing his/her password. OpenLDAP password policy is not enforced when RootDN performs the password change. As a result, no password policy is enforced during password change. If I don't set LDAP user/password in keystone.conf, then users cannot change their own passwords at all. Please recommend how I can allow the users to change their own passwords and at the same time enforce OpenLDAP password policy. Thank you, Nodir To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1528676/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1490804] Re: [OSSA 2015-005] PKI Token Revocation Bypass (CVE-2015-7546)
** Summary changed: - [OSSA 2015-006] PKI Token Revocation Bypass (CVE-2015-7546) + [OSSA 2015-005] PKI Token Revocation Bypass (CVE-2015-7546) ** Changed in: ossa Status: Confirmed => Fix Released ** Summary changed: - [OSSA 2015-005] PKI Token Revocation Bypass (CVE-2015-7546) + [OSSA 2016-005] PKI Token Revocation Bypass (CVE-2015-7546) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1490804 Title: [OSSA 2016-005] PKI Token Revocation Bypass (CVE-2015-7546) Status in django-openstack-auth: Invalid Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) kilo series: Fix Committed Status in keystonemiddleware: Fix Released Status in OpenStack Security Advisory: Fix Released Status in OpenStack Security Notes: Fix Released Status in python-keystoneclient: Won't Fix Bug description: A keystone token which has been revoked can still be used by manipulating particular byte fields within the token. When a Keystone token is revoked it is added to the revoked list which stores the exact token value. Any API will look at the token to see whether or not it should accept a token. By changing a single byte within the token, the revocation can be bypassed. see the testing script [1]. It is suggested that the revocation should be changed to only check the token's inner ID. [1] http://paste.openstack.org/show/436516/ To manage notifications about this bug go to: https://bugs.launchpad.net/django-openstack-auth/+bug/1490804/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1534232] Re: Glance is still using outdated md5 for image signing
*** This bug is a duplicate of bug 1516031 *** https://bugs.launchpad.net/bugs/1516031 ** Information type changed from Private Security to Public ** Changed in: ossa Status: Incomplete => Won't Fix ** This bug has been marked a duplicate of bug 1516031 Use of MD5 in OpenStack Glance image signature (CVE-2015-8234) -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1534232 Title: Glance is still using outdated md5 for image signing Status in Glance: New Status in OpenStack Security Advisory: Won't Fix Bug 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. -- Glance is still using md5 for image signing. MD5 is outdated and should not be used for security reason. It makes it possible for malicious users to generate malicious image with same hash values. https://specs.openstack.org/openstack/glance-specs/specs/liberty/image-signing-and-verification-support.html Glance already supports computing checksums of images when an image is uploaded, and this checksum is stored with the image. This same hash (which by default is MD5) will be used for the signature verification. In the code: https://github.com/openstack/glance/blob/2682dfe2000604bd1a77cfad5ad259f084a1359f/glance/image_cache/__init__.py line 242: def cache_tee_iter(self, image_id, image_iter, image_checksum): try: current_checksum = hashlib.md5() with self.driver.open_for_write(image_id) as cache_file: for chunk in image_iter: try: cache_file.write(chunk) finally: current_checksum.update(chunk) yield chunk cache_file.flush() To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1534232/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1534322] Re: On new port, traffic flow is allowed before security groups are programmed
I've removed the privacy settings and put the OSSA tasks as Won't Fix since it's a C1 type of bug (according to VMT taxonomy https://security.openstack.org/vmt-process.html#incident-report-taxonomy ), This can be put back to incomplete if the situation changes. ** Information type changed from Private Security to Public ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1534322 Title: On new port, traffic flow is allowed before security groups are programmed Status in neutron: Triaged Status in OpenStack Security Advisory: Won't Fix Bug 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. -- Description: During the creation of a neutron port, in the ovs_neutron_agent, traffic flow is enabled shortly before security groups are programmed. File: neutron/plugins/ml2/drivers/openvswitch/agent/ovs_neutron_agent.py Funtion: process_network_ports Step-by-step: During the creation of a neutron port, the following calls are made: - treat_devices_added_or_updated - sg_agent.setup_port_filters - _bind_devices Before early November, process_network_ports called sg_agent.setup_port_filters before it called _bind_devices. This meant that security groups were programmed before traffic flow is enabled by _bind_devices, which sets the port-lvm mapping in br-int. Bug #1512636 reversed this order of operation, so that _bind_devices is called before sg_agent.setup_port_filters. This opens up a brief security hole, allowing traffic to flow for a short time before security groups are applied. Proposed solution: Revert bug# 1512636 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1534322/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1524274] Re: [OSSA 2016-001] Unprivileged api user can access host data using instance snapshot (CVE-2015-7548)
** Changed in: ossa Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1524274 Title: [OSSA 2016-001] Unprivileged api user can access host data using instance snapshot (CVE-2015-7548) Status in OpenStack Compute (nova): In Progress Status in OpenStack Security Advisory: Fix Released Bug 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. There is a qcow2 format vulnerability in LibvirtDriver.snapshot. The impact is that on an affected system, an unprivileged api user can retrieve any file on the host readable by the nova user. This includes guest data of other instances on the same host, and credentials used by nova to access other services externally. LibvirtDriver.snapshot does: source_format = libvirt_utils.get_disk_type(disk_path) ... snapshot_backend = self.image_backend.snapshot(instance, disk_path, image_type=source_format) ... snapshot_backend.snapshot_extract(out_path, image_format) libvirt_utils.get_disk_type falls back to image inspection for disks which are not lvm, rbd or ploop, which means raw and qcow2 images. The vulnerability only exists when a user can write to a raw volume which is later erroneously detected as qcow2. This means that the vulnerability is only present on systems using the libvirt driver which have defined use_cow_images=False in nova.conf. This is not the default, so by default nova is not vulnerable. libvirt.utils.extract_snapshot() expects to be reading from an instance disk and writing to a temporary directory created by nova for storing snapshots before transferring them to glance. As nova directly creates this directory and its contents, the 'qemu-img convert' process does not need to run privileged. This means that the exposure is limited to files directly readable by the nova user. Unfortunately, as is clear from the context this includes all instance data which, despite being owned by the qemu user, is world readable. Additionally, because the qemu-img process is executed by nova directly, it does not benefit from any confinement by libvirt. Specifically, SELinux is not likely to be a defence on a typical deployment. I have tested this exploit on a Fedora 23 system running devstack as of 8th Dec 2015: Ensure nova.conf contains use_cow_images = False in the DEFAULT section. As an unprivileged api user, do: $ nova boot --image cirros --flavor m1.tiny foo Somewhere, run: $ qemu-img create -f qcow2 -o backing_file=/etc/passwd bad.qcow2 Ensure bad.qcow2 is available in the foo instance. Log into foo, and execute as root: # dd if=bad.qcow2 of=/dev/vda conv=fsync As an unprivileged api user, do: $ nova image-create foo passwd $ glance image-download --file passwd The unprivileged api now has the contents of /etc/passwd from the host locally. Mitigations: Nova is not vulnerable by default. The user must have configured use_cow_images=False. Nova configurations using ceph or lvm for instance storage are not vulnerable. An attacker must know the uuid of another user's instance in order to be able to access its data. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1524274/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1524675] Re: lbaasv2-agent is logging credentials from barbican
This is a class B3 type of bug (according to https://security.openstack.org/vmt-process.html#incident-report-taxonomy ) ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1524675 Title: lbaasv2-agent is logging credentials from barbican Status in neutron: In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: In liberty, a neutron-lbaasv2-agent is logging credentials retrieved from barbican when debug=True. (e.g. cert, private key, passphrase) this makes security issue. example: http://paste.openstack.org/show/481439/ (part of /var/log/neutron/neutron-lbaasv2-agent.log) To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1524675/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1528676] Re: OpenLDAP password policy not enforced for password changes
Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions. ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Incomplete -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1528676 Title: OpenLDAP password policy not enforced for password changes Status in OpenStack Identity (keystone): New Status in OpenStack Security Advisory: Incomplete Bug description: Hello there, I'm on Ubuntu 14.04.3, Openstack Juno and OpenLDAP v2.4.31 releases. I configured OpenLDAP as an identity backend for Keystone and configured it according to official documentation from: http://docs.openstack.org/developer/keystone/configuration.html I'd like my users to be able to change their own passwords, but at the same time OpenLDAP password policy to be enforced upon password changes. I've set to true all allow_creates, allow_updates and allow_deletes not to be restricted in any way by keystone. The problem is the following: RootDN account is used for binding when the user is changing his/her password. OpenLDAP password policy is not enforced when RootDN performs the password change. As a result, no password policy is enforced during password change. If I don't set LDAP user/password in keystone.conf, then users cannot change their own passwords at all. Please recommend how I can allow the users to change their own passwords and at the same time enforce OpenLDAP password policy. Thank you, Nodir To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1528676/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1526244] Re: Able to create objects by admin in the particular domain, for incorrect domain Id field name "domain-id".
According to VMT taxonomy, this is a class E.
** Changed in: ossa
Status: Incomplete => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1526244
Title:
Able to create objects by admin in the particular domain, for
incorrect domain Id field name "domain-id".
Status in OpenStack Identity (keystone):
In Progress
Status in OpenStack Security Advisory:
Won't Fix
Bug description:
Admin is able to create objects(user,group,.) in a particular domain,
though field name is misspelt as "domain-id" instead of "domain_id".
Step Followed: User creation by admin with incorrect field name
"domain-id"
ubuntu@ubuntu:~$ curl -i -k -X POST -H "Content-Type: application/json" -H
"X-AUTH-TOKEN:ae5ed453cf444969953850532cb9b581" /v3/users -d '{
> "user":
> {
> "name":"User Pwr Ranger 50",
> "password":"pwd",
> "description":"User Creation in another domain",
> "domain-id":"37a09709db404e7d97f8a211ebebc93f"
> }
> }'
HTTP/1.1 201 Created
Date: Fri, 13 Nov 2015 12:38:22 GMT
Server: Apache/2.4.7 (Ubuntu)
Vary: X-Auth-Token
x-openstack-request-id: req-1cc05a23-065f-4a25-9fcd-90fa827722d3
Content-Length: 290
Content-Type: application/json
{"user": {"links": {"self":
"/v3/users/90776556002948dfb44227aef3b042e7"},
"description": "User Creation in another domain", "name": "User Pwr
Ranger 50", "enabled": true, "id": "90776556002948dfb44227aef3b042e7",
"domain_id": "37a09709db404e7d97f8a211ebebc93f"}}
The user got created in a specified domain "domain-
id":"37a09709db404e7d97f8a211ebebc93f", even though domain Id field is
misspelt as "domain-id" instead of "domain_id".
Hence the issue has to be resolved by creating objects in "default"
domain when the field name is spelt wrongly.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1526244/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1522524] Re: User can delete deactivated images
Until a clear consensus about whenever this bug caused an actual security vulnerability, the OSSA task is now Won't Fix. ** Changed in: ossa Status: Confirmed => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1522524 Title: User can delete deactivated images Status in Glance: In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: Overview: In glance once an admin has marked a image as deactivated a user can no longer download or delete that image. This is so an image can be inspected by the admins without the user interfering. However, these restrictions can be avoided specifically allowing a user to delete a deactivated image. Meaning an admin would not be able to guarantee the status of a deactivated image. What should happen: 403 What does happen: 200 How to reproduce: 1. Create an image. echo test | glance image-create --name 3 --container-format bare --disk-format raw 2. Deactivate the image. glance image-deactivate 0630d5e4-6009-4723-94e6-1ad056ab649a 3. Check image is deactivated. glance image-show 0630d5e4-6009-4723-94e6-1ad056ab649a 4. Using the v1 API delete the image. curl -X DELETE http://localhost:9292/v1/images/0630d5e4-6009-4723-94e6-1ad056ab649a -H 'X-Auth-token: 108322e43f6346ebadb3c2fb72831913' 5. Image is now gone. glance image-show 0630d5e4-6009-4723-94e6-1ad056ab649a To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1522524/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1515444] Re: Routed ICMP v6 traffic goes through with no security group rules with DVR
** Information type changed from Private Security to Public ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1515444 Title: Routed ICMP v6 traffic goes through with no security group rules with DVR Status in neutron: Invalid Status in OpenStack Security Advisory: Won't Fix Bug 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. - V6 traffic flows between two dual stacked instances connected via DVR despite absence of security group rule allowing so. V4 traffic is blocked. Build: Master Nov. 11/11/15 Setup: One controller/Network node, Two Compute nodes. Steps: 1. create net1 and net2. 2. create IPv4 and IPv6 subnet(slaac/slaac*) on each network. 3. create DVR. 4. Add router interface for each of four subnets to DVR. 5. Boot instance with nic on net1 and other with nic on net2. 6. Delete all security group rules if any exists. 7. Ping6 v6 IP from one instance to the other. Expected: Traffic does not go through. Observed: Traffic goes through. *also observed with dhcpv6-stateful addressing. To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1515444/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1449062] Re: qemu-img calls need to be restricted by ulimit (CVE-2015-5162)
The proposed change did not effectively fixed that issue. ** Changed in: nova Status: Fix Released => Confirmed -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1449062 Title: qemu-img calls need to be restricted by ulimit (CVE-2015-5162) Status in Cinder: New Status in Glance: In Progress Status in OpenStack Compute (nova): Confirmed Status in OpenStack Security Advisory: Confirmed Bug description: Reported via private E-mail from Richard W.M. Jones. Turns out qemu image parser is not hardened against malicious input and can be abused to allocated an arbitrary amount of memory and/or dump a lot of information when used with "--output=json". The solution seems to be: limit qemu-img ressource using ulimit. Example of abuse: -- afl1.img -- $ /usr/bin/time qemu-img info afl1.img image: afl1.img [...] 0.13user 0.19system 0:00.36elapsed 92%CPU (0avgtext+0avgdata 642416maxresident)k 0inputs+0outputs (0major+156927minor)pagefaults 0swaps The original image is 516 bytes, but it causes qemu-img to allocate 640 MB. -- afl2.img -- $ qemu-img info --output=json afl2.img | wc -l 589843 This is a 200K image which causes qemu-img info to output half a million lines of JSON (14 MB of JSON). Glance runs the --output=json variant of the command. -- afl3.img -- $ /usr/bin/time qemu-img info afl3.img image: afl3.img [...] 0.09user 0.35system 0:00.47elapsed 94%CPU (0avgtext+0avgdata 1262388maxresident)k 0inputs+0outputs (0major+311994minor)pagefaults 0swaps qemu-img allocates 1.3 GB (actually, a bit more if you play with ulimit -v). It appears that you could change it to allocate arbitrarily large amounts of RAM. To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1449062/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1516031] Re: Use of MD5 in OpenStack Glance image signature (CVE-2015-8234)
Since this does not qualify for an OpenStack Security Advisory (OSSA),
I've added an OSSN task to assess if a Security Note would work better
here.
** Also affects: ossn
Importance: Undecided
Status: New
** Changed in: ossa
Status: Incomplete => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1516031
Title:
Use of MD5 in OpenStack Glance image signature (CVE-2015-8234)
Status in Glance:
Triaged
Status in OpenStack Security Advisory:
Won't Fix
Status in OpenStack Security Notes:
New
Bug description:
This have been reported by Daniel P. Berrange:
"
In the OpenStack Liberty release, the Glance project added support for image
signature verification.
http://specs.openstack.org/openstack/glance-specs/specs/liberty/image-
signing-and-verification-support.html
The verification code was added in the following git commit
https://github.com/openstack/glance/commit/484ef1b40b738c87adb203bba6107ddb4b04ff6e
Unfortunately the design of this signature verification method is flawed by
design.
The generalized approach to creating signatures of content is to apply
a hash to the content and then encrypt it in some manner. Consider
that the signature is defined to use hash=sha256 and cipher=rsa we can
describe the signature computation as
signature = rsa(sha256(content))
In the case of verifying a disk image, the content we care about
verifying is the complete disk image file. Unfortunately, the glance
specification chose *not* to compute the signature against the disk
image file. Glance already had an MD5 checksum calculated for the disk
image file, so they instead chose to compute the signature against the
MD5 checksum instead. ie glance is running
signature = rsa(sha256(md5(disk-image-content)))
This degrades the security of the system to that of the weakest hash,
which is obviously MD5 here.
The code where glance verifies the signature is in the
glance/locations.py, the 'set_data' method where is does
result = signature_utils.verify_signature(
self.context, checksum, self.image.extra_properties)
if result:
LOG.info(_LI("Successfully verified signature for image %s"),
self.image.image_id)
The 'checksum' variable is populate by the glance_store driver, but it
is hardcoded to always be md5 in all current glance storage backends:
$ git grep hashlib glance_store/_drivers/ | grep checksum
glance_store/_drivers/filesystem.py: checksum = hashlib.md5()
glance_store/_drivers/rbd.py: checksum = hashlib.md5()
glance_store/_drivers/s3.py: checksum = hashlib.md5()
glance_store/_drivers/s3.py: checksum = hashlib.md5()
glance_store/_drivers/sheepdog.py: checksum = hashlib.md5()
glance_store/_drivers/swift/store.py: checksum =
hashlib.md5()
glance_store/_drivers/vmware_datastore.py: self.checksum =
hashlib.md5()
Since we will soon be shipping OpenStack Liberty release, we need to at least
give a security notice to alert our customers to the fact that the signature
verification is cryptographically weak/broken. IMHO, it quite likely deserves a
CVE though
NB, this is public knowledge as I first became aware of this flawed
design in comments / discussion on a public specification proposed to
implement the same approach in the Nova project.
My suggested way to fix this is to simply abandon the current impl and
re-do it such that it directly computes the signature against the
disk image, and does not use the existing md5 checksum in any way.
Regards,
Daniel
"
Mailing list thread for Nova impl:
http://lists.openstack.org/pipermail/openstack-dev/2015-November/079348.html
Nova Spec: https://review.openstack.org/#/c/188874/
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1516031/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1499555] Re: You can crash keystone or make the DB very slow by assigning many roles
Then according to VMT taxonomy ( https://security.openstack.org/vmt- process.html#incident-report-taxonomy ), this sounds more like a class D. ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Identity (keystone). https://bugs.launchpad.net/bugs/1499555 Title: You can crash keystone or make the DB very slow by assigning many roles Status in OpenStack Identity (keystone): In Progress Status in OpenStack Security Advisory: Won't Fix Bug description: This is applicable for UUID and PKI tokens. Token table has extra column where we store role information. It is a blob with 64K limit. Basically we can do the following to fill the BLOB Say user is U, and Project is P for i =1 to 1000 ( or any large number) role x = create role i with some large name assign role x for user U and Project P create a project scoped token for user U To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1499555/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1501206] Re: router:dhcp ports are open resolvers
Alright, removing the security class and closing the OSSA task. ** Changed in: ossa Status: Incomplete => Won't Fix ** Information type changed from Public Security to Public -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1501206 Title: router:dhcp ports are open resolvers Status in neutron: New Status in OpenStack Security Advisory: Won't Fix Bug description: When configuring an public IPv4 subnet with DHCP enabled inside Neutron (and attaching it to an Internet-connected router), the DNS recursive resolver service provided by dnsmasq inside the qdhcp network namespace will respond to DNS queries from the entire Internet. This is a huge problem from a security standpoint, as open resolvers are very likely to be abused for DDoS purposes. This does not only cause significant damage to third parties (i.e., the true destination of the DDoS attack and every network in between), but also on the local network or servers (due to saturation of all the available network bandwidth and/or the processing capacity of the node running the dnsmasq instance). Quoting from http://openresolverproject.org/: «Open Resolvers pose a significant threat to the global network infrastructure by answering recursive queries for hosts outside of its domain. They are utilized in DNS Amplification attacks and pose a similar threat as those from Smurf attacks commonly seen in the late 1990s. [...] What can I do? If you operate a DNS server, please check the settings. Recursive servers should be restricted to your enterprise or customer IP ranges to prevent abuse. Directions on securing BIND and Microsoft nameservers can be found on the Team CYMRU Website - If you operate BIND, you can deploy the TCP-ANY patch» It seems reasonable to expect that the dnsmasq instance within Neutron would only respond to DNS queries from the subnet prefixes it is associated with and ignore all others. Note that this only occurs for IPv4. That is however likely just a symptom of bug #1499170, which breaks all IPv6 DNS queries (external as well as internal). I would assume that when bug #1499170 is fixed, the router:dhcp ports will immediately start being open resolvers over IPv6 too. For what it's worth, the reason I noticed this issue in the first place was that NorCERT (the national Norwegian Computer Emergency Response Team - http://www.cert.no/) got in touch with us, notifying us about the open resolvers they had observed in our network and insisted that we lock them down ASAP. It only took NorCERT couple of days after the subnet was first created to do so. Tore To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1501206/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1511061] Re: Images in inconsistent state when calls to registry fail during image deletion
Thanks Erno, I've removed the OSSA task ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1511061 Title: Images in inconsistent state when calls to registry fail during image deletion Status in Glance: Triaged Status in Glance juno series: New Status in Glance kilo series: New Status in Glance liberty series: New Status in OpenStack Security Advisory: Won't Fix Bug description: [0] shows a sample image that was left in an inconsistent state when a call to registry failed during image deletion. Glance v1 API makes two registry calls when deleting an image. The first call [1] is made to to set the status of an image to deleted/pending_delete. And, the other [2], to delete the rest of the metadata, which sets 'deleted_at' and 'deleted' fields in the db. If the first call fails, the image deletion request fails and the image is left intact in it's previous status. However, if the first call succeeds and the second one fails, the image is left in an inconsistent status where it's status is set to pending_delete/deleted but it's 'deleted_at' and 'deleted' fields are not set. If delayed delete is turned on, these images are never collected by the scrubber as they won't appear as deleted images because their deleted field is not set. So, these images will continue to occupy storage in the backend. Also, further attempts at deleting these images will fail with a 404 because the status is already set to pending_delete/deleted. [0] http://paste.openstack.org/show/477577/ [1]: https://github.com/openstack/glance/blob/master/glance/api/v1/images.py#L1115-L1116 [2]: https://github.com/openstack/glance/blob/master/glance/api/v1/images.py#L1132 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1511061/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1516031] [NEW] Use of MD5 in OpenStack Glance image signature
*** This bug is a security vulnerability ***
Public security bug reported:
This have been reported by Daniel P. Berrange:
"
In the OpenStack Liberty release, the Glance project added support for image
signature verification.
http://specs.openstack.org/openstack/glance-specs/specs/liberty/image-
signing-and-verification-support.html
The verification code was added in the following git commit
https://github.com/openstack/glance/commit/484ef1b40b738c87adb203bba6107ddb4b04ff6e
Unfortunately the design of this signature verification method is flawed by
design.
The generalized approach to creating signatures of content is to apply a
hash to the content and then encrypt it in some manner. Consider that
the signature is defined to use hash=sha256 and cipher=rsa we can
describe the signature computation as
signature = rsa(sha256(content))
In the case of verifying a disk image, the content we care about
verifying is the complete disk image file. Unfortunately, the glance
specification chose *not* to compute the signature against the disk
image file. Glance already had an MD5 checksum calculated for the disk
image file, so they instead chose to compute the signature against the
MD5 checksum instead. ie glance is running
signature = rsa(sha256(md5(disk-image-content)))
This degrades the security of the system to that of the weakest hash,
which is obviously MD5 here.
The code where glance verifies the signature is in the
glance/locations.py, the 'set_data' method where is does
result = signature_utils.verify_signature(
self.context, checksum, self.image.extra_properties)
if result:
LOG.info(_LI("Successfully verified signature for image %s"),
self.image.image_id)
The 'checksum' variable is populate by the glance_store driver, but it
is hardcoded to always be md5 in all current glance storage backends:
$ git grep hashlib glance_store/_drivers/ | grep checksum
glance_store/_drivers/filesystem.py: checksum = hashlib.md5()
glance_store/_drivers/rbd.py: checksum = hashlib.md5()
glance_store/_drivers/s3.py: checksum = hashlib.md5()
glance_store/_drivers/s3.py: checksum = hashlib.md5()
glance_store/_drivers/sheepdog.py: checksum = hashlib.md5()
glance_store/_drivers/swift/store.py: checksum =
hashlib.md5()
glance_store/_drivers/vmware_datastore.py: self.checksum =
hashlib.md5()
Since we will soon be shipping OpenStack Liberty release, we need to at least
give a security notice to alert our customers to the fact that the signature
verification is cryptographically weak/broken. IMHO, it quite likely deserves a
CVE though
NB, this is public knowledge as I first became aware of this flawed
design in comments / discussion on a public specification proposed to
implement the same approach in the Nova project.
My suggested way to fix this is to simply abandon the current impl and
re-do it such that it directly computes the signature against the disk
image, and does not use the existing md5 checksum in any way.
Regards,
Daniel
"
Mailing list thread for Nova impl:
http://lists.openstack.org/pipermail/openstack-dev/2015-November/079348.html
Nova Spec: https://review.openstack.org/#/c/188874/
** Affects: glance
Importance: Undecided
Status: New
** Affects: ossa
Importance: Undecided
Status: Incomplete
** Also affects: ossa
Importance: Undecided
Status: New
** Changed in: ossa
Status: New => Incomplete
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1516031
Title:
Use of MD5 in OpenStack Glance image signature
Status in Glance:
New
Status in OpenStack Security Advisory:
Incomplete
Bug description:
This have been reported by Daniel P. Berrange:
"
In the OpenStack Liberty release, the Glance project added support for image
signature verification.
http://specs.openstack.org/openstack/glance-specs/specs/liberty/image-
signing-and-verification-support.html
The verification code was added in the following git commit
https://github.com/openstack/glance/commit/484ef1b40b738c87adb203bba6107ddb4b04ff6e
Unfortunately the design of this signature verification method is flawed by
design.
The generalized approach to creating signatures of content is to apply
a hash to the content and then encrypt it in some manner. Consider
that the signature is defined to use hash=sha256 and cipher=rsa we can
describe the signature computation as
signature = rsa(sha256(content))
In the case of verifying a disk image, the content we care about
verifying is the complete disk image file. Unfortunately, the glance
specification chose *not* to compute the signature against the disk
image file. Glance already had an MD5 checksum calculated for the disk
image file, so they instead chose to compute the signature against the
MD5 checksum instead. ie glance is running
signature = rsa(sha256(md5(disk-image-content)))
[Yahoo-eng-team] [Bug 1511061] Re: Images in inconsistent state when calls to registry fail during image deletion
Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions. Can user make the image deletion to fail ? e.g., can this be abused trivially ? ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Incomplete -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1511061 Title: Images in inconsistent state when calls to registry fail during image deletion Status in Glance: Triaged Status in Glance juno series: New Status in Glance kilo series: New Status in Glance liberty series: New Status in OpenStack Security Advisory: Incomplete Bug description: [0] shows a sample image that was left in an inconsistent state when a call to registry failed during image deletion. Glance v1 API makes two registry calls when deleting an image. The first call [1] is made to to set the status of an image to deleted/pending_delete. And, the other [2], to delete the rest of the metadata, which sets 'deleted_at' and 'deleted' fields in the db. If the first call fails, the image deletion request fails and the image is left intact in it's previous status. However, if the first call succeeds and the second one fails, the image is left in an inconsistent status where it's status is set to pending_delete/deleted but it's 'deleted_at' and 'deleted' fields are not set. If delayed delete is turned on, these images are never collected by the scrubber as they won't appear as deleted images because their deleted field is not set. So, these images will continue to occupy storage in the backend. Also, further attempts at deleting these images will fail with a 404 because the status is already set to pending_delete/deleted. [0] http://paste.openstack.org/show/477577/ [1]: https://github.com/openstack/glance/blob/master/glance/api/v1/images.py#L1115-L1116 [2]: https://github.com/openstack/glance/blob/master/glance/api/v1/images.py#L1132 To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1511061/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1491307] Re: [OSSA 2015-021] secgroup rules doesn't work for instance immediately (CVE-2015-7713)
** Changed in: ossa Status: In Progress => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1491307 Title: [OSSA 2015-021] secgroup rules doesn't work for instance immediately (CVE-2015-7713) Status in OpenStack Compute (nova): Fix Released Status in OpenStack Security Advisory: Fix Released Bug description: I have an OpenStack kilo setup on RHEL7.1 with a controller and a compute node (network-compute + network-network)，the config is following: # /etc/nova.nova.conf on contrller node [DEFAULT] network_api_class = nova.network.api.API security_group_api = nova # /etc/nova/nova.conf on compute node [DEFAULT] network_api_class = nova.network.api.API security_group_api = nova firewall_driver = nova.virt.libvirt.firewall.IptablesFirewallDriver network_manager = nova.network.manager.FlatDHCPManager network_size = 254 allow_same_net_traffic = False multi_host = True send_arp_for_ha = True share_dhcp_address = True force_dhcp_release = True flat_network_bridge = br100 flat_interface = eth0 public_interface = eth0 steps for test 1: 1) create and start VM instance-1 with secgroup default; 2) VM instance-1 ping br100: OK; 3) br100 ping VM instance-1: operation not permitted (because of no secgroup-rules for ICMP) 4) nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0 5) br100 ping VM instance-1: i got the same wrong message, not expected. steps for test 2: 1) nova secgroup-add-rule default icmp -1 -1 0.0.0.0/0; 2) create and start VM instance-2 with secgroup default; 3) br100 ping instance-2: OK It seems that command "nova secgroup-add-rule ..." doesn't work immediately for the existed or running VM instances? To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1491307/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1392527] Re: [OSSA 2015-017] Deleting instance while resize instance is running leads to unuseable compute nodes (CVE-2015-3280)
** Changed in: ossa Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1392527 Title: [OSSA 2015-017] Deleting instance while resize instance is running leads to unuseable compute nodes (CVE-2015-3280) Status in OpenStack Compute (nova): New Status in OpenStack Compute (nova) juno series: Fix Committed Status in OpenStack Compute (nova) kilo series: Fix Committed Status in OpenStack Security Advisory: Fix Released Bug description: Steps to reproduce: 1) Create a new instance,waiting until it’s status goes to ACTIVE state 2) Call resize API 3) Delete the instance immediately after the task_state is “resize_migrated” or vm_state is “resized” 4) Repeat 1 through 3 in a loop I have kept attached program running for 4 hours, all instances created are deleted (nova list returns empty list) but I noticed instances directories with the name “_resize> are not deleted from the instance path of the compute nodes (mainly from the source compute nodes where the instance was running before resize). If I keep this program running for couple of more hours (depending on the number of compute nodes), then it completely uses the entire disk of the compute nodes (based on the disk_allocation_ratio parameter value). Later, nova scheduler doesn’t select these compute nodes for launching new vms and starts reporting error "No valid hosts found". Note: Even the periodic tasks doesn't cleanup these orphan instance directories from the instance path. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1392527/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1498163] Re: [OSSA 2015-020] Glance storage quota bypass when token is expired (CVE-2015-5286)
** Changed in: ossa Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1498163 Title: [OSSA 2015-020] Glance storage quota bypass when token is expired (CVE-2015-5286) Status in Glance: Fix Released Status in OpenStack Security Advisory: Fix Released Bug description: About a year ago it was a vulnerability called 'Glance user storage quota bypass': https://security.openstack.org/ossa/OSSA-2015-003.html, where any user could overcome the quota and clog up the storage. The fix was proposed in master and all other stable branches, but it turned out, that it doesn't completely remove the issue and any user still can exceed the quota. It happens in case if user token is expired during file upload and when glance tries to update image status from 'saving' to 'active'. Then glance gets Unauthenticated exception from registry server and fails with 500 error. On the other side garbage file is left in storage. Steps to reproduce mostly coincide with the related from the previous bug, but in general it is: 1. Set some value (like 1Gb) to user_storage_quota in glance-api.conf and restart the server. 2. Make sure that your token will expire soon, when you'll be able to create an image instance in DB and begin the upload, but the token will expire during it. 3. Create an image, begin the upload and quickly remove the image with 'glance image-delete'. 4. After the upload check that image is not in the list, i.e. it's deleted, and file is still located in the store. 5. Perform steps 2-4 several times to make sure that user quota is exceeded. Related script (test_images.py from here https://bugs.launchpad.net/glance/+bug/1398830) works fine, too, but it's better to reduce token life time in keystone config to 1 or 2 minutes, just for not to wait for one hour. Glance api v2 is affected as well, but only if registry db_api is enabled. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1498163/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1482371] Re: [OSSA 2015-019] Image status can be changed by passing header 'x-image-meta-status' with PUT operation using v1 (CVE-2015-5251)
** Changed in: ossa Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1482371 Title: [OSSA 2015-019] Image status can be changed by passing header 'x -image-meta-status' with PUT operation using v1 (CVE-2015-5251) Status in Glance: Fix Committed Status in OpenStack Security Advisory: Fix Released Bug description: Using Glance v1, one is able to change the status of an image to any one of the valid statuses by passing the header 'x-image-meta-status' with PUT on /images/. This bug provides a way for an image to transition states that are otherwise not possible in an image's lifecycle. See http://paste.openstack.org/show/pNL7kvIZUz7cWJQwX64d/ for a reproduction of this behavior on devstack. As shown in the above paste, though one is able to change the status of an active image to queued, uploading data after re-setting the status to queued fails with a 400[1]. Though the purpose of [1] appears to be slightly different, it's fortunately saving us from badly breaking the immutability guarantees of glance images. [1] https://github.com/openstack/glance/blob/master/glance/api/v1/images.py#L760-L765 NOTE: Marking this as a security vulnerability for now as users would be able to activate the deactivated images on their own. This probably affects deployments only where v1 is exposed publicly. However, it's probably worth discussing this from a security perspective as well. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1482371/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1489111] Re: [OSSA 2015-018] IP, MAC, and DHCP spoofing rules can by bypassed by changing device_owner (CVE-2015-5240)
** Changed in: ossa Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to neutron. https://bugs.launchpad.net/bugs/1489111 Title: [OSSA 2015-018] IP, MAC, and DHCP spoofing rules can by bypassed by changing device_owner (CVE-2015-5240) Status in neutron: Fix Committed Status in OpenStack Security Advisory: Fix Released Bug 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. -- The anti-IP spoofing rules, anti-MAC spoofing rules, and anti-DHCP spoofing rules can be bypassed by changing the device_owner field of a compute node's port to something that starts with 'network:'. Steps to reproduce: Create a port on the target network: neutron port-create some_network Start a repeated update of the device_owner field to immediately change it back after nova sets it to 'compute:' on VM attachment. (This has to be done quickly because the owner has to be set to 'network:something' before the L2 agent wires up the security group rules.) watch neutron port-update --device-owner network:hello Then boot the VM with the port UUID: nova boot test --nic port-id= --flavor m1.tiny --image cirros-0.3.4-x86_64-uec This VM will now have no iptables rules applied because it will be treated as a network owned port (e.g. router interface, DHCP interface, etc). To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1489111/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1483382] Re: Able to request a V2 token for user and project in a non-default domain
** Changed in: ossa
Status: Incomplete => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1483382
Title:
Able to request a V2 token for user and project in a non-default
domain
Status in Keystone:
Fix Released
Status in Keystone kilo series:
In Progress
Status in OpenStack Security Advisory:
Won't Fix
Bug description:
Using the latest devstack, I am able to request a V2 token for user
and project in a non-default domain. This problematic as non-default
domains are not suppose to be visible to V2 APIs.
Steps to reproduce:
1) install devstack
2) run these commands
gyee@dev:~$ openstack --os-identity-api-version 3 --os-username admin
--os-password secrete --os-user-domain-id default --os-project-name admin
--os-project-domain-id default --os-auth-url http://localhost:5000 domain list
+--+-+-+--+
| ID | Name| Enabled | Description
|
+--+-+-+--+
| 769ad7730e0c4498b628aa8dc00e831f | foo | True|
|
| default | Default | True| Owns users and
tenants (i.e. projects) available on Identity API v2. |
+--+-+-+--+
gyee@dev:~$ openstack --os-identity-api-version 3 --os-username admin
--os-password secrete --os-user-domain-id default --os-project-name admin
--os-project-domain-id default --os-auth-url http://localhost:5000 user list
--domain 769ad7730e0c4498b628aa8dc00e831f
+--+--+
| ID | Name |
+--+--+
| cf0aa0b2d5db4d67a94d1df234c338e5 | bar |
+--+--+
gyee@dev:~$ openstack --os-identity-api-version 3 --os-username admin
--os-password secrete --os-user-domain-id default --os-project-name admin
--os-project-domain-id default --os-auth-url http://localhost:5000 project list
--domain 769ad7730e0c4498b628aa8dc00e831f
+--+-+
| ID | Name|
+--+-+
| 413abdbfef5544e2a5f3e8ac6124dd29 | foo-project |
+--+-+
gyee@dev:~$ curl -k -H 'Content-Type: application/json' -d '{"auth":
{"passwordCredentials": {"userId": "cf0aa0b2d5db4d67a94d1df234c338e5",
"password": "secrete"}, "tenantId": "413abdbfef5544e2a5f3e8ac6124dd29"}}'
-XPOST http://localhost:35357/v2.0/tokens | python -mjson.tool
% Total% Received % Xferd Average Speed TimeTime Time
Current
Dload Upload Total SpentLeft Speed
100 3006 100 2854 100 152 22164 1180 --:--:-- --:--:-- --:--:-- 22472
{
"access": {
"metadata": {
"is_admin": 0,
"roles": [
"2b7f29ebd1c8453fb91e9cd7c2e1319b",
"9fe2ff9ee4384b1894a90878d3e92bab"
]
},
"serviceCatalog": [
{
"endpoints": [
{
"adminURL":
"http://10.0.2.15:8774/v2/413abdbfef5544e2a5f3e8ac6124dd29";,
"id": "3a92a79a21fb41379fa3e135be65eeff",
"internalURL":
"http://10.0.2.15:8774/v2/413abdbfef5544e2a5f3e8ac6124dd29";,
"publicURL":
"http://10.0.2.15:8774/v2/413abdbfef5544e2a5f3e8ac6124dd29";,
"region": "RegionOne"
}
],
"endpoints_links": [],
"name": "nova",
"type": "compute"
},
{
"endpoints": [
{
"adminURL":
"http://10.0.2.15:8776/v2/413abdbfef5544e2a5f3e8ac6124dd29";,
"id": "64338d9eb3054598bcee30443c678e2a",
"internalURL":
"http://10.0.2.15:8776/v2/413abdbfef5544e2a5f3e8ac6124dd29";,
"publicURL":
"http://10.0.2.15:8776/v2/413abdbfef5544e2a5f3e8ac6124dd29";,
"region": "RegionOne"
}
],
"endpoints_links": [],
"name": "cinderv2",
"type": "volumev2"
},
{
"endpoints": [
{
[Yahoo-eng-team] [Bug 1479385] Re: Cause conflicts within glance public metadefs
Until this can be safely backported, the OSSA task is switched to Won't
fix.
** Changed in: ossa
Status: Triaged => Won't Fix
** Information type changed from Public Security to Public
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1479385
Title:
Cause conflicts within glance public metadefs
Status in Glance:
Triaged
Status in OpenStack Security Advisory:
Won't Fix
Bug description:
Overview:
Through creation of a new public namespace by any user of the system,
you can create a clash of namespaces, that breaks all accessibility to
that namespace. This therefore can be used to cause a denial of
service attack or you have to disable the service completely.
How to produce:
As a regular user run the command:
curl -v -X POST http://16.49.138.140:9292/v2/metadefs/namespaces -H
"Content-Type: application/json" -H "X-Auth-Token:
1a499605071a46a8b9b2a938fac5fac7" -d '{"namespace": "OS::Computer::WebServers",
"visibility": "public"}'
This will create a new namespace with the same name as the existing
namespace. This has now rendered the original namespace inaccessible. If a GET
request is done to the namespaces name by any other user via (or viewing in
horizon):
curl -v -X GET
http://16.49.138.140:9292/v2/metadefs/namespaces/OS::Computer::WebServers -H
"Content-Type: application/json" -H "X-Auth-Token:
1a499605071a46a8b9b2a938fac5fac7"
It will cause the following output in the api console:
2015-07-28 23:41:42.175 ERROR glance.api.v2.metadef_properties
[req-e3a80995-6f37-4e5c-b7dd-a1ce978478c7 f76c222365fb490792300f9e49ec9bd0
9db14ac3320b4396b58222f99dd04e4e] Multiple rows were found for one()
Returning a 500 to the user and therefore the namespace inaccessible
meaning a successful denial of service to most of the metadefs api as
most require it.
Attempted preventative measures:
In the policy.json files there are only the following values:
"get_metadef_namespace": "",
"get_metadef_namespaces":"",
"modify_metadef_namespace":"",
"add_metadef_namespace":"",
meaning that creating namespaces has to be disabled completely(not default )
as there in no publicize option.
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1479385/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1482301] Re: 'X-Openstack-Request-ID' lenght limited only by header size
** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1482301 Title: 'X-Openstack-Request-ID' lenght limited only by header size Status in Glance: In Progress Status in Glance juno series: New Status in Glance kilo series: New Status in OpenStack Security Advisory: Won't Fix Bug description: Glance accepts 'X-Openstack-Request-ID' header and includes the value in log-files. The length of the Request ID is limited only by max_header_line parameter that defaults to 16384. This opens possibility to flood the logs. Public as this vulnerability was already discussed today on Glance weekly meeting. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1482301/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1387543] Re: [OSSA 2015-015] Resize/delete combo allows to overload nova-compute (CVE-2015-3241)
** Changed in: ossa Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1387543 Title: [OSSA 2015-015] Resize/delete combo allows to overload nova-compute (CVE-2015-3241) Status in OpenStack Compute (nova): Fix Committed Status in OpenStack Compute (nova) juno series: Fix Committed Status in OpenStack Compute (nova) kilo series: Fix Committed Status in OpenStack Security Advisory: Fix Released Bug description: If user create instance, and resize it to larger flavor and than delete that instance, migration process does not stop. This allow user to repeat operation many times, causing overload to affected compute nodes over user quota. Affected installation: most drastic effect happens on 'raw-disk' instances without live migration. Whole raw disk (full size of the flavor) is copied during migration. If user delete instance it does not terminate rsync/scp keeping disk backing file opened regardless of removal by nova compute. Because rsync/scp of large disks is rather slow, it gives malicious user enough time to repeat that operation few hundred times, causing disk space depletion on compute nodes, huge impact on management network and so on. Proposed solution: abort migration (kill rsync/scp) as soon, as instance is deleted. Affected installation: Havana, Icehouse, probably Juno (not tested). To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1387543/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1471912] Re: [OSSA 2015-014] Format-guessing and file disclosure via image conversion (CVE-2015-5163)
** Changed in: ossa
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1471912
Title:
[OSSA 2015-014] Format-guessing and file disclosure via image
conversion (CVE-2015-5163)
Status in Glance:
Fix Committed
Status in OpenStack Security Advisory:
Fix Released
Bug description:
This is a security flaw that allows files from the Glance host to be
obtained by a user.
I'm using the Glance file store and have set in /etc/glance/glance-api.conf:
[taskflow_executor]
engine_mode=serial # not sure if needed
conversion_format=raw
Make a malicious image available via HTTP.
$ sudo qemu-img create -f qcow2 /var/www/html/test_image 1M
$ sudo qemu-img rebase -u -b /etc/passwd /var/www/html/test_image
$ glance --os-image-api-version 2 task-create --type import --input
'{"import_from_format": "qcow2", "import_from": "http://127.0.0.1/test_image";,
"image_properties": {"name": "my_image_test", "disk_format": "qcow2",
"container_format": "bare"}}'
$ glance image-download my_image_test --file downloaded_image
$ head downloaded_image
This happens because Glance runs this command which doesn't specify a format,
and uses qemu-img's format auto-detection:
qemu-img convert -O raw file:///tmp/28e1f5e8-9f62-4c01-84be-9feae8852ea4
/tmp/28e1f5e8-9f62-4c01-84be-9feae8852ea4.converted
Similar to Cinder bug 1415087.
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1471912/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1415087] Re: [OSSA 2015-011] Format-guessing and file disclosure in image convert (CVE-2015-1850, CVE-2015-1851)
The OSSA tasks is now closed. If Nova turns out to be affected, a new OSSA will be required anyway. ** Changed in: ossa Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1415087 Title: [OSSA 2015-011] Format-guessing and file disclosure in image convert (CVE-2015-1850, CVE-2015-1851) Status in Cinder: Fix Released Status in Cinder icehouse series: Fix Released Status in Cinder juno series: Fix Committed Status in Cinder kilo series: Fix Released Status in OpenStack Compute (nova): Triaged Status in OpenStack Security Advisory: Fix Released Bug description: Cinder does not provide input format to several calls of "qemu-img convert". This allows the attacker to play the format guessing by providing a volume with a qcow2 signature. If this signature contains a base file, this file will be read by a process running as root and embedded in the output. This bug is similar to CVE-2013-1922. Tested with: lvm backed volume storage, it may apply to others as well Steps to reproduce: - create volume and attach to vm, - create a qcow2 signature with base-file[1] from within the vm and - trigger upload to glance with "cinder upload-to-image --disk-type qcow2"[2]. The image uploaded to glance will have /etc/passwd from the cinder-volume host embedded. Affected versions: tested on 2014.1.3, found while reading 2014.2.1 Fix: Always specify both input "-f" and output format "-O" to "qemu- img convert". The code is in module cinder.image.image_utils. Bastian Blank [1]: qemu-img create -f qcow2 -b /etc/passwd /dev/vdb [2]: The disk-type != raw triggers the use of "qemu-img convert" To manage notifications about this bug go to: https://bugs.launchpad.net/cinder/+bug/1415087/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1482301] Re: 'X-Openstack-Request-ID' lenght limited only by header size
** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Incomplete -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1482301 Title: 'X-Openstack-Request-ID' lenght limited only by header size Status in Glance: In Progress Status in Glance juno series: New Status in Glance kilo series: New Status in OpenStack Security Advisory: Incomplete Bug description: Glance accepts 'X-Openstack-Request-ID' header and includes the value in log-files. The length of the Request ID is limited only by max_header_line parameter that defaults to 16384. This opens possibility to flood the logs. Public as this vulnerability was already discussed today on Glance weekly meeting. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1482301/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1472243] [NEW] Router interface add port with a mac address raise runtime error
Public bug reported:
Trace:
ERROR neutron.agent.l3.agent [-] Failed to process compatible router
'1794ed9d-68d6-402c-a4e5-8041de4c4186'
TRACE neutron.agent.l3.agent Traceback (most recent call last):
TRACE neutron.agent.l3.agent File
"/usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py", line 452, in
_process_router_update
TRACE neutron.agent.l3.agent self._process_router_if_compatible(router)
TRACE neutron.agent.l3.agent File
"/usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py", line 406, in
_process_router_if_compatible
TRACE neutron.agent.l3.agent self._process_updated_router(router)
TRACE neutron.agent.l3.agent File
"/usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py", line 420, in
_process_updated_router
TRACE neutron.agent.l3.agent ri.process(self)
TRACE neutron.agent.l3.agent File
"/usr/lib/python2.7/site-packages/neutron/common/utils.py", line 346, in call
TRACE neutron.agent.l3.agent self.logger(e)
TRACE neutron.agent.l3.agent File
"/usr/lib/python2.7/site-packages/oslo_utils/excutils.py", line 85, in __exit__
TRACE neutron.agent.l3.agent six.reraise(self.type_, self.value, self.tb)
TRACE neutron.agent.l3.agent File
"/usr/lib/python2.7/site-packages/neutron/common/utils.py", line 343, in call
TRACE neutron.agent.l3.agent return func(*args, **kwargs)
TRACE neutron.agent.l3.agent File
"/usr/lib/python2.7/site-packages/neutron/agent/l3/router_info.py", line 605,
in process
TRACE neutron.agent.l3.agent self._process_internal_ports()
TRACE neutron.agent.l3.agent File
"/usr/lib/python2.7/site-packages/neutron/agent/l3/router_info.py", line 361,
in _process_internal_ports
TRACE neutron.agent.l3.agent self.internal_network_added(p)
TRACE neutron.agent.l3.agent File
"/usr/lib/python2.7/site-packages/neutron/agent/l3/router_info.py", line 312,
in internal_network_added
TRACE neutron.agent.l3.agent INTERNAL_DEV_PREFIX)
TRACE neutron.agent.l3.agent File
"/usr/lib/python2.7/site-packages/neutron/agent/l3/router_info.py", line 288,
in _internal_network_added
TRACE neutron.agent.l3.agent prefix=prefix)
TRACE neutron.agent.l3.agent File
"/usr/lib/python2.7/site-packages/neutron/agent/linux/interface.py", line 252,
in plug
TRACE neutron.agent.l3.agent ns_dev.link.set_address(mac_address)
TRACE neutron.agent.l3.agent File
"/usr/lib/python2.7/site-packages/neutron/agent/linux/ip_lib.py", line 270, in
set_address
TRACE neutron.agent.l3.agent self._as_root([], ('set', self.name,
'address', mac_address))
TRACE neutron.agent.l3.agent File
"/usr/lib/python2.7/site-packages/neutron/agent/linux/ip_lib.py", line 222, in
_as_root
TRACE neutron.agent.l3.agent use_root_namespace=use_root_namespace)
TRACE neutron.agent.l3.agent File
"/usr/lib/python2.7/site-packages/neutron/agent/linux/ip_lib.py", line 69, in
_as_root
TRACE neutron.agent.l3.agent log_fail_as_error=self.log_fail_as_error)
TRACE neutron.agent.l3.agent File
"/usr/lib/python2.7/site-packages/neutron/agent/linux/ip_lib.py", line 78, in
_execute
TRACE neutron.agent.l3.agent log_fail_as_error=log_fail_as_error)
TRACE neutron.agent.l3.agent File
"/usr/lib/python2.7/site-packages/neutron/agent/linux/utils.py", line 137, in
execute
TRACE neutron.agent.l3.agent raise RuntimeError(m)
TRACE neutron.agent.l3.agent RuntimeError:
TRACE neutron.agent.l3.agent Command: ['sudo', 'neutron-rootwrap',
'/etc/neutron/rootwrap.conf', 'ip', 'link', 'set', 'qr-a848e3a3-ce', 'address',
'00:00:00:00:00:00']
TRACE neutron.agent.l3.agent Exit code: 2
TRACE neutron.agent.l3.agent Stdin:
TRACE neutron.agent.l3.agent Stdout:
TRACE neutron.agent.l3.agent Stderr: RTNETLINK answers: Cannot assign requested
address
Steps to reproduce:
router_id=$(neutron router-create test | grep ' id ' | awk '{ print $4 }')
neutron net-create test
neutron subnet-create test 192.168.0.1/24
port_id=$(neutron port-create --mac_address '00:00:00:00:00:00' test | grep '
id ' | awk '{ print $4 }')
neutron router-interface-add $router_id port=$port_id
Impact:
Raise RuntimeError instead of NeutronError
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1472243
Title:
Router interface add port with a mac address raise runtime error
Status in OpenStack Neutron (virtual network service):
New
Bug description:
Trace:
ERROR neutron.agent.l3.agent [-] Failed to process compatible router
'1794ed9d-68d6-402c-a4e5-8041de4c4186'
TRACE neutron.agent.l3.agent Traceback (most recent call last):
TRACE neutron.agent.l3.agent File
"/usr/lib/python2.7/site-packages/neutron/agent/l3/agent.py", line 452, in
_process_router_update
TRACE neutron.agent.l3.agent self._process_router_if_compatible(router)
TRACE neutron.agent.l3.agent File
"/usr/lib/python2.7/site-packages/neutron/agent/
[Yahoo-eng-team] [Bug 1472242] [NEW] Router interface add port without subnet raise indexerror
Public bug reported:
Trace:
ERROR neutron.api.v2.resource [req-dbf179d1-62ac-4537-be15-c2088669f75c ]
add_router_interface failed
TRACE neutron.api.v2.resource Traceback (most recent call last):
TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/neutron/api/v2/resource.py", line 83, in
resource
TRACE neutron.api.v2.resource result = method(request=request, **args)
TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/neutron/api/v2/base.py", line 207, in
_handle_action
TRACE neutron.api.v2.resource return getattr(self._plugin, name)(*arg_list,
**kwargs)
TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/neutron/db/l3_dvr_db.py", line 306, in
add_router_interface
TRACE neutron.api.v2.resource router_id, port['tenant_id'], port['id'],
subnets[-1]['id'],
TRACE neutron.api.v2.resource IndexError: list index out of range
Steps to reproduce:
router_id=$(neutron router-create test | grep ' id ' | awk '{ print $4 }')
neutron net-create test
port_id=$(neutron port-create test | grep ' id ' | awk '{ print $4 }')
neutron router-interface-add $router_id port=$port_id
Impact:
Raise an IndexError exception instead of NeutronError
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1472242
Title:
Router interface add port without subnet raise indexerror
Status in OpenStack Neutron (virtual network service):
New
Bug description:
Trace:
ERROR neutron.api.v2.resource [req-dbf179d1-62ac-4537-be15-c2088669f75c ]
add_router_interface failed
TRACE neutron.api.v2.resource Traceback (most recent call last):
TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/neutron/api/v2/resource.py", line 83, in
resource
TRACE neutron.api.v2.resource result = method(request=request, **args)
TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/neutron/api/v2/base.py", line 207, in
_handle_action
TRACE neutron.api.v2.resource return getattr(self._plugin,
name)(*arg_list, **kwargs)
TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/site-packages/neutron/db/l3_dvr_db.py", line 306, in
add_router_interface
TRACE neutron.api.v2.resource router_id, port['tenant_id'], port['id'],
subnets[-1]['id'],
TRACE neutron.api.v2.resource IndexError: list index out of range
Steps to reproduce:
router_id=$(neutron router-create test | grep ' id ' | awk '{ print $4 }')
neutron net-create test
port_id=$(neutron port-create test | grep ' id ' | awk '{ print $4 }')
neutron router-interface-add $router_id port=$port_id
Impact:
Raise an IndexError exception instead of NeutronError
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1472242/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1471966] [NEW] Invalid json types cause stacktrace
Public bug reported:
Incorrect json input cause error instead of being invalidated properly:
Type error in dns_nameservers raise keyerror:
ERROR neutron.api.v2.resource [req-be58f6e1-db2f-4b2e-9620-afb49bdd4552 demo
d1da3f8632e3413b915eda78899806d7] create failed
Traceback (most recent call last):
File "/opt/stack/neutron/neutron/api/v2/resource.py", line 87, in resource
result = method(request=request, **args)
File "/opt/stack/neutron/neutron/api/v2/base.py", line 379, in create
allow_bulk=self._allow_bulk)
File "/opt/stack/neutron/neutron/api/v2/base.py", line 637, in
prepare_request_body
attr_vals['validate'][rule])
File "/opt/stack/neutron/neutron/api/v2/attributes.py", line 275, in
_validate_nameservers
msg = _validate_ip_or_hostname(host)
File "/opt/stack/neutron/neutron/api/v2/attributes.py", line 257, in
_validate_ip_or_hostname
name_err = _validate_hostname(host)
File "/opt/stack/neutron/neutron/api/v2/attributes.py", line 370, in
_validate_hostname
trimmed = data if data[-1] != '.' else data[:-1]
TRACE neutron.api.v2.resource KeyError: -1
TRACE neutron.api.v2.resource·
INFO neutron.wsgi [req-be58f6e1-db2f-4b2e-9620-afb49bdd4552 demo
d1da3f8632e3413b915eda78899806d7] 10.43.97.9 - - [05/Jul/2015 11:28:35] "POST
//v2.0/subnets.json HTTP/1.1" 500 359 0.029233
Steps to reproduce:
token=$(keystone token-get | grep ' id ' | awk '{ print $4}')
curl -H "X-Auth-Token:${token}" -H 'Content-Type:application/json' -X POST
http://localhost:9696//v2.0/subnets.json \
-d '{"subnet": {"dns_nameservers": [{}], "cidr": "192.168.0.1/24",
"network_id": "----", "ip_version": "4"}}'; echo
Various sql errors with security-group params:
Trace:
ERROR neutron.api.v2.resource [req-0f32e171-029c-465a-872e-d3533fc191c7 demo
4a2f46b3469240589af5db1ffd3e56e7] create failed
TRACE neutron.api.v2.resource Traceback (most recent call last):
TRACE neutron.api.v2.resource File
"/opt/stack/neutron/neutron/api/v2/resource.py", line 87, in resource
TRACE neutron.api.v2.resource result = method(request=request, **args)
TRACE neutron.api.v2.resource File
"/opt/stack/neutron/neutron/api/v2/base.py", line 448, in create
TRACE neutron.api.v2.resource obj = obj_creator(request.context, **kwargs)
TRACE neutron.api.v2.resource File
"/opt/stack/neutron/neutron/db/securitygroups_db.py", line 137, in
create_security_group
TRACE neutron.api.v2.resource context.session.add(egress_rule)
TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 447, in
__exit__
TRACE neutron.api.v2.resource self.rollback()
TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/dist-packages/sqlalchemy/util/langhelpers.py", line 58, in
__exit__
TRACE neutron.api.v2.resource compat.reraise(exc_type, exc_value, exc_tb)
TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 444, in
__exit__
TRACE neutron.api.v2.resource self.commit()
TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 354, in
commit
TRACE neutron.api.v2.resource self._prepare_impl()
TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 334, in
_prepare_impl
TRACE neutron.api.v2.resource self.session.flush()
TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 1818, in
flush
TRACE neutron.api.v2.resource self._flush(objects)
TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 1936, in
_flush
TRACE neutron.api.v2.resource transaction.rollback(_capture_exception=True)
TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/dist-packages/sqlalchemy/util/langhelpers.py", line 58, in
__exit__
TRACE neutron.api.v2.resource compat.reraise(exc_type, exc_value, exc_tb)
TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/session.py", line 1900, in
_flush
TRACE neutron.api.v2.resource flush_context.execute()
TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/unitofwork.py", line 372, in
execute
TRACE neutron.api.v2.resource rec.execute(self)
TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/unitofwork.py", line 525, in
execute
TRACE neutron.api.v2.resource uow
TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/persistence.py", line 64, in
save_obj
TRACE neutron.api.v2.resource table, insert)
TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/dist-packages/sqlalchemy/orm/persistence.py", line 541, in
_emit_insert_statements
TRACE neutron.api.v2.resource execute(statement, multiparams)
TRACE neutron.api.v2.resource File
"/usr/lib/python2.7/dist-packages/sqlalchemy/engine/base.py", line 662, i
[Yahoo-eng-team] [Bug 1471957] [NEW] Invalid subnet cidr cause dhcp runtimerror
Public bug reported:
Trace:
ERROR neutron.agent.linux.utils [req-26ce0148-4bc4-40bd-96ac-e9d484f37b61 demo
12b3399d1cb64da488e20f6a7c355d10]
Command: ['sudo', '/usr/local/bin/neutron-rootwrap',
'/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec',
'qdhcp-6cdefebf-ab88-4f55-b2b9-719286a7b75b', 'ip', 'route', 'replace',
'default', 'via', '0.0.0.1', 'dev', 'tapb81e677c-8c']
Exit code: 2
Stdout: ''
Stderr: 'RTNETLINK answers: Network is unreachable\n'
ERROR neutron.agent.dhcp_agent [req-26ce0148-4bc4-40bd-96ac-e9d484f37b61 demo
12b3399d1cb64da488e20f6a7c355d10] Unable to enable dhcp for
6cdefebf-ab88-4f55-b2b9-719286a7b75b.
Traceback (most recent call last):
File "/opt/stack/neutron/neutron/agent/dhcp_agent.py", line 128, in
call_driver
getattr(driver, action)(**action_kwargs)
File "/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 205, in enable
interface_name = self.device_manager.setup(self.network)
File "/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 1056, in setup
self._set_default_route(network, interface_name)
File "/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 928, in
_set_default_route
device.route.add_gateway(subnet.gateway_ip)
File "/opt/stack/neutron/neutron/agent/linux/ip_lib.py", line 395, in
add_gateway
self._as_root(*args)
File "/opt/stack/neutron/neutron/agent/linux/ip_lib.py", line 242, in _as_root
kwargs.get('use_root_namespace', False))
File "/opt/stack/neutron/neutron/agent/linux/ip_lib.py", line 74, in _as_root
log_fail_as_error=self.log_fail_as_error)
File "/opt/stack/neutron/neutron/agent/linux/ip_lib.py", line 86, in _execute
log_fail_as_error=log_fail_as_error)
File "/opt/stack/neutron/neutron/agent/linux/utils.py", line 84, in execute
raise RuntimeError(m)
TRACE neutron.agent.dhcp_agent RuntimeError:
TRACE neutron.agent.dhcp_agent Command: ['sudo',
'/usr/local/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns',
'exec', 'qdhcp-6cdefebf-ab88-4f55-b2b9-719286a7b75b', 'ip', 'route', 'replace',
'default', 'vi
a', '0.0.0.1', 'dev', 'tapb81e677c-8c']
TRACE neutron.agent.dhcp_agent Exit code: 2
TRACE neutron.agent.dhcp_agent Stdout: ''
TRACE neutron.agent.dhcp_agent Stderr: 'RTNETLINK answers: Network is
unreachable\n'
TRACE neutron.agent.dhcp_agent
Steps to reproduce:
NET_NAME=test-ip
neutron net-create ${NET_NAME}
neutron port-create ${NET_NAME}
neutron subnet-create ${NET_NAME} 0.0.0.0/8
Impact:
cause logs to grow more than necessary
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1471957
Title:
Invalid subnet cidr cause dhcp runtimerror
Status in OpenStack Neutron (virtual network service):
New
Bug description:
Trace:
ERROR neutron.agent.linux.utils [req-26ce0148-4bc4-40bd-96ac-e9d484f37b61
demo 12b3399d1cb64da488e20f6a7c355d10]
Command: ['sudo', '/usr/local/bin/neutron-rootwrap',
'/etc/neutron/rootwrap.conf', 'ip', 'netns', 'exec',
'qdhcp-6cdefebf-ab88-4f55-b2b9-719286a7b75b', 'ip', 'route', 'replace',
'default', 'via', '0.0.0.1', 'dev', 'tapb81e677c-8c']
Exit code: 2
Stdout: ''
Stderr: 'RTNETLINK answers: Network is unreachable\n'
ERROR neutron.agent.dhcp_agent [req-26ce0148-4bc4-40bd-96ac-e9d484f37b61 demo
12b3399d1cb64da488e20f6a7c355d10] Unable to enable dhcp for
6cdefebf-ab88-4f55-b2b9-719286a7b75b.
Traceback (most recent call last):
File "/opt/stack/neutron/neutron/agent/dhcp_agent.py", line 128, in
call_driver
getattr(driver, action)(**action_kwargs)
File "/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 205, in enable
interface_name = self.device_manager.setup(self.network)
File "/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 1056, in setup
self._set_default_route(network, interface_name)
File "/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 928, in
_set_default_route
device.route.add_gateway(subnet.gateway_ip)
File "/opt/stack/neutron/neutron/agent/linux/ip_lib.py", line 395, in
add_gateway
self._as_root(*args)
File "/opt/stack/neutron/neutron/agent/linux/ip_lib.py", line 242, in
_as_root
kwargs.get('use_root_namespace', False))
File "/opt/stack/neutron/neutron/agent/linux/ip_lib.py", line 74, in
_as_root
log_fail_as_error=self.log_fail_as_error)
File "/opt/stack/neutron/neutron/agent/linux/ip_lib.py", line 86, in
_execute
log_fail_as_error=log_fail_as_error)
File "/opt/stack/neutron/neutron/agent/linux/utils.py", line 84, in execute
raise RuntimeError(m)
TRACE neutron.agent.dhcp_agent RuntimeError:
TRACE neutron.agent.dhcp_agent Command: ['sudo',
'/usr/local/bin/neutron-rootwrap', '/etc/neutron/rootwrap.conf', 'ip', 'netns',
'exec', 'qdhcp-6cdefebf-ab88-4f55-b2b9-719286a7b75b', 'ip', 'route', 'replace',
'default', 'vi
a', '0.0.0.1', 'dev', 'tap
[Yahoo-eng-team] [Bug 1471959] [NEW] Dhcp error in network with two subnet when one is disabled
Public bug reported:
Trace:
ERROR neutron.agent.dhcp_agent [-] Unable to enable dhcp for
125c7403-1ef1-489c-bc0c-cf6a0f83e742.
Traceback (most recent call last):
File "/opt/stack/neutron/neutron/agent/dhcp_agent.py", line 128, in
call_driver
getattr(driver, action)(**action_kwargs)
File "/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 207, in enable
self.spawn_process()
File "/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 376, in
spawn_process
'--dhcp-optsfile=%s' % self._output_opts_file(),
File "/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 646, in
_output_opts_file
isolated_subnets = self.get_isolated_subnets(self.network)
File "/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 812, in
get_isolated_subnets
if subnets[alloc.subnet_id].gateway_ip == alloc.ip_address:
KeyError: u'f1ff257b-ddb8-4069-bf9f-8a60bd704097'
TRACE neutron.agent.dhcp_agent KeyError: u'f1ff257b-ddb8-4069-bf9f-8a60bd704097'
TRACE neutron.agent.dhcp_agent
Steps to reproduce:
NET_NAME=test-key
I=11
neutron net-create ${NET_NAME}
neutron port-create ${NET_NAME}
neutron subnet-create --name "${NET_NAME}-sub001" ${NET_NAME} 192.168.${I}.1/24
neutron subnet-create --name "${NET_NAME}-sub002" ${NET_NAME} 192.168.${I}1.1/24
while [ "$(neutron port-list | grep "192.168.${I}" | wc -l)" != 2 ]; do
echo "waiting for dhcp port on both subnet"
done
neutron subnet-update --disable-dhcp "${NET_NAME}-sub002"
sleep 10
if [ "$(neutron port-list | grep "192.168.${I}" | wc -l)" != 2 ]; then
echo "failed"
fi
Impact:
cause logs to grow more than necessary
** Affects: neutron
Importance: Undecided
Status: New
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1471959
Title:
Dhcp error in network with two subnet when one is disabled
Status in OpenStack Neutron (virtual network service):
New
Bug description:
Trace:
ERROR neutron.agent.dhcp_agent [-] Unable to enable dhcp for
125c7403-1ef1-489c-bc0c-cf6a0f83e742.
Traceback (most recent call last):
File "/opt/stack/neutron/neutron/agent/dhcp_agent.py", line 128, in
call_driver
getattr(driver, action)(**action_kwargs)
File "/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 207, in enable
self.spawn_process()
File "/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 376, in
spawn_process
'--dhcp-optsfile=%s' % self._output_opts_file(),
File "/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 646, in
_output_opts_file
isolated_subnets = self.get_isolated_subnets(self.network)
File "/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 812, in
get_isolated_subnets
if subnets[alloc.subnet_id].gateway_ip == alloc.ip_address:
KeyError: u'f1ff257b-ddb8-4069-bf9f-8a60bd704097'
TRACE neutron.agent.dhcp_agent KeyError:
u'f1ff257b-ddb8-4069-bf9f-8a60bd704097'
TRACE neutron.agent.dhcp_agent
Steps to reproduce:
NET_NAME=test-key
I=11
neutron net-create ${NET_NAME}
neutron port-create ${NET_NAME}
neutron subnet-create --name "${NET_NAME}-sub001" ${NET_NAME}
192.168.${I}.1/24
neutron subnet-create --name "${NET_NAME}-sub002" ${NET_NAME}
192.168.${I}1.1/24
while [ "$(neutron port-list | grep "192.168.${I}" | wc -l)" != 2 ]; do
echo "waiting for dhcp port on both subnet"
done
neutron subnet-update --disable-dhcp "${NET_NAME}-sub002"
sleep 10
if [ "$(neutron port-list | grep "192.168.${I}" | wc -l)" != 2 ]; then
echo "failed"
fi
Impact:
cause logs to grow more than necessary
To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1471959/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1461054] Re: [OSSA 2015-012] Adding 0.0.0.0/0 to allowed address pairs breaks l2 agent (CVE-2015-3221)
** Changed in: ossa
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1461054
Title:
[OSSA 2015-012] Adding 0.0.0.0/0 to allowed address pairs breaks l2
agent (CVE-2015-3221)
Status in OpenStack Neutron (virtual network service):
Fix Committed
Status in neutron juno series:
Fix Committed
Status in neutron kilo series:
Fix Committed
Status in OpenStack Security Advisories:
Fix Released
Bug 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.
vagrant@node1:~$ neutron port-update $PORT_ID --allowed_address_pairs
list=true type=dict ip_address=0.0.0.0/0
Updated port: 28dc7eb1-6f95-429f-8e30-adaefffcec70
This does not work - the ipset man page says that zero prefix size is not
allowed for type hash:net.
But it also breaks the l2 agent and so affects other ports/vms/tenants ... -
so opening as security vulnerability.
2015-06-02 11:02:31.897 ERROR neutron.agent.linux.utils
[req-6dfc4e3b-7162-4528-b821-295de80aa7ed None None]
Command: ['ipset', 'add', '-exist', u'NETIPv48a445928-2f41-43de-a',
u'0.0.0.0/0']
Exit code: 1
Stdin:
Stdout:
Stderr: ipset v6.20.1: The value of the CIDR parameter of the IP address is
invalid
2015-06-02 11:02:31.898 DEBUG oslo_concurrency.lockutils
[req-6dfc4e3b-7162-4528-b821-295de80aa7ed None None] Releasing file lock
"/opt/stack/data/neutron/lock/neutron-ipset" after holding it for 0.006s
release /usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:227
2015-06-02 11:02:31.898 DEBUG oslo_concurrency.lockutils
[req-6dfc4e3b-7162-4528-b821-295de80aa7ed None None] Lock "ipset" released by
"set_members" :: held 0.006s inner
/usr/local/lib/python2.7/dist-packages/oslo_concurrency/lockutils.py:456
2015-06-02 11:02:31.898 ERROR
neutron.plugins.openvswitch.agent.ovs_neutron_agent
[req-6dfc4e3b-7162-4528-b821-295de80aa7ed None None] Error while processing VIF
ports
2015-06-02 11:02:31.898 3679 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent Traceback (most recent call
last):
2015-06-02 11:02:31.898 3679 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent File
"/opt/stack/neutron/neutron/plugins/openvswitch/agent/ovs_neutron_agent.py",
line 1640, in rpc_loop
2015-06-02 11:02:31.898 3679 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent ovs_restarted)
2015-06-02 11:02:31.898 3679 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent File
"/opt/stack/neutron/neutron/plugins/openvswitch/agent/ovs_neutron_agent.py",
line 1434, in process_network_ports
2015-06-02 11:02:31.898 3679 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent
port_info.get('updated', set()))
2015-06-02 11:02:31.898 3679 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent File
"/opt/stack/neutron/neutron/agent/securitygroups_rpc.py", line 302, in
setup_port_filters
2015-06-02 11:02:31.898 3679 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent
self.prepare_devices_filter(new_devices)
2015-06-02 11:02:31.898 3679 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent File
"/opt/stack/neutron/neutron/agent/securitygroups_rpc.py", line 159, in
decorated_function
2015-06-02 11:02:31.898 3679 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent *args, **kwargs)
2015-06-02 11:02:31.898 3679 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent File
"/opt/stack/neutron/neutron/agent/securitygroups_rpc.py", line 185, in
prepare_devices_filter
2015-06-02 11:02:31.898 3679 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent security_groups,
security_group_member_ips)
2015-06-02 11:02:31.898 3679 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent File
"/usr/lib/python2.7/contextlib.py", line 24, in __exit__
2015-06-02 11:02:31.898 3679 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent self.gen.next()
2015-06-02 11:02:31.898 3679 TRACE
neutron.plugins.openvswitch.agent.ovs_neutron_agent File
"/opt/stack/neutron/neutron/agent/firewall.py", line 106, in defer_apply
2015-06-02 11:02:31.898 3679 TRACE
neutron.
[Yahoo-eng-team] [Bug 1461728] Re: V2.0 API not calling defined external auth
** Changed in: ossa
Status: Incomplete => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Keystone.
https://bugs.launchpad.net/bugs/1461728
Title:
V2.0 API not calling defined external auth
Status in OpenStack Identity (Keystone):
Won't Fix
Status in OpenStack Security Advisories:
Won't Fix
Bug description:
When keystone.conf is defined with external auth , all V2.0 API calls
do not get intercepted by the defined external auth.
this is my keystone.conf
[auth]
methods=password,token,external
external=keystone.auth.plugins.idm_external.IDMDefaultDomain
V.20 CURL to initiate external auth.
curl -X POST -d '{"auth":{}}' -H "Content-type: application/json" -H
"REMOTE_USER: admin" http://localhost:5000/v2.0/tokens
What I'm seeing is the call gets to the keystone/token/controller.py,
where it checks for the auth{} and executes the external
authentication
if "token" in auth:
# Try to authenticate using a token
auth_info = self._authenticate_token(
context, auth)
else:
# Try external authentication
try:
auth_info = self._authenticate_external(
context, auth)
except ExternalAuthNotApplicable:
# Try local authentication
auth_info = self._authenticate_local(
context, auth)
...
def _authenticate_external(self, context, auth):
"""Try to authenticate an external user via REMOTE_USER variable.
Returns auth_token_data, (user_ref, tenant_ref, metadata_ref)
"""
if 'REMOTE_USER' not in context.get('environment', {}):
raise ExternalAuthNotApplicable()
#NOTE(jamielennox): xml and json differ and get confused about what
# empty auth should look like so just reset it.
if not auth:
auth = {}
username = context['environment']['REMOTE_USER']
try:
user_ref = self.identity_api.get_user_by_name(
username, CONF.identity.default_domain_id)
user_id = user_ref['id']
except exception.UserNotFound as e:
raise exception.Unauthorized(e)
metadata_ref = {}
tenant_id = self._get_project_id_from_auth(auth)
tenant_ref, metadata_ref['roles'] = self._get_project_roles_and_ref(
user_id, tenant_id)
expiry = core.default_expire_time()
bind = None
if ('kerberos' in CONF.token.bind and
context['environment'].
get('AUTH_TYPE', '').lower() == 'negotiate'):
bind = {'kerberos': username}
return (user_ref, tenant_ref, metadata_ref, expiry, bind)
The _authenticate_external should not assume and have its own
REMOTE_USER implementation, instead it should look for the external
method defined in keystone.conf and appropriately call the defined
external class.
The V3 call works fine and calls the right external class defined.
curl -X POST -d
'{"auth":{"identity":{"methods":["external"],"external":{' -H
"REMOTE_USER:admin" -H "Content-type: application/json"
http://localhost:5000/v3/auth/tokens
This is potentially a security hole as well, which will allow all V2
API's to get Keystone token w/o password.
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1461728/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1456228] Re: Trusted vm can be powered on untrusted host
Sylvain, if the trusted computing feature of Nova doesn't prevent an instance to spawn on a compromised node, then maybe the feature should be removed, or at least have a clear mention about that behavior. According to vulnerability taxonomy, this issue falls in the B2 class ( https://security.openstack.org/vmt-process.html#incident-report-taxonomy ), I've set the OSSA tasks to won't fix and added a new OSSN tasks. ** Also affects: ossn Importance: Undecided Status: New ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1456228 Title: Trusted vm can be powered on untrusted host Status in OpenStack Compute (Nova): Invalid Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: This is related to the trusted compute. I recently setup trusted compute pool in my company and have observed that although new trusted vm is not able to be launched from an untrusted host, but if an trusted vm that have launched earlier on a trusted host which is compromised later on, that VM can still be powered on. 1. Exact version of Nova/Openstack: [root@grunt2 ~]# rpm -qa | grep nova python-nova-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-network-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-compute-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-conductor-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-cells-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-api-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-console-2014.1.2-100+45c2cbc.fc20.noarch python-novaclient-2.17.0-2.fc21.noarch openstack-nova-cert-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-scheduler-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-objectstore-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-common-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-novncproxy-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-doc-2014.1.2-100+45c2cbc.fc20.noarch 2. Relevant log files: this is not a error, don't think logs will help.. 3. Reproduce steps: * create trusted compute pool with only one compute node * create an trusted VM on that compute node * compromise the trusted compute node by changing the boot order * power on the trusted Vm created earlier. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1456228/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1464750] Re: Service accounts can be used to login horizon
** Changed in: ossa Status: Incomplete => Won't Fix ** Information type changed from Private Security to Public ** Also affects: ossn Importance: Undecided Status: New ** Changed in: ossn Status: New => Incomplete -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Dashboard (Horizon). https://bugs.launchpad.net/bugs/1464750 Title: Service accounts can be used to login horizon Status in OpenStack Dashboard (Horizon): Incomplete Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: Incomplete Bug description: This is not a bug and may / may not be a security issue ... but it appears that the service account created in keystone are of the same privileges level as any other admin accounts created through keystone and I don't like that. Would it be possible to implement something that would distinguish user accounts from service accounts? Is there a way to isolate some service accounts from the remaining of the openstack APIs? One kick example on this is that any service accounts have admin privileges on all the other services . At this point, I'm trying to figure out why are we creating a distinct service account for each service if nothing isolate them. IE: glance account can spawn a VM cinder account can delete an image heat account can delete a volume nova account can create an image All of these service accounts have access to the horizon dashboard. One small hack could be to prevent those accounts from logging in Horizon. Thanks, Dave To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1464750/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1461433] Re: Automatically generated admin password is not complex enough
This is a class D type of bug ( https://security.openstack.org/vmt- process.html#incident-report-taxonomy ). ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1461433 Title: Automatically generated admin password is not complex enough Status in OpenStack Compute (Nova): New Status in OpenStack Security Advisories: Won't Fix Bug description: When performing actions such as create instances, evacuate instances, rebuild instances, rescue instances and update instances' admin password. When the user dose not provide admin password, generate_password() in utils.py is used to generate an admin password. Generate_password() now uses two password symbol groups: default and easier, the default symbol group contains numbers, upper case letters and small case letters. the easier symbol group contains only numbers and upper case letters. The generated password is not complex enough and can cause security problems. One possible solution is to add a new symbol group: STRONGER_PASSWORD_SYMBOLS which contains numbers, upper case letters, lower case letters and also special characters such as `~!@#$%^&*()-_=+ and space. Then adding a new option in configuration file: generate_strong_password = True, when this option is set, nova will generate password using STRONGER_PASSWORD_SYMBOLS symbol group and with longer password length. If this option is not set, the password will be generated using the default symbol group and default length. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1461433/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1461431] Re: Enable admin password complexity verification
Agreed on class D type of bug. ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1461431 Title: Enable admin password complexity verification Status in OpenStack Compute (Nova): New Status in OpenStack Security Advisories: Won't Fix Bug description: When performing actions such as create instances, evacuate instances, rebuild instances, rescue instances and update instances' admin password. The complexity of user provided admin password has not been verified. This can cause security problems. One solution will be adding a configuration option: using_complex_admin_password = True, if this option is set in configure file by administrator, then Nova will perform password complexity checks, the check standards can be set to following the IT industry general standard, if the provided admin password is not complex enough, an exception will be throw. If this option is not set in configure file, then the complexity check will be skipped. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1461431/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1453074] Re: [OSSA 2015-010] help_text parameter of fields is vulnerable to arbitrary html injection (CVE-2015-3219)
All patches are now merged, shouldn't series task be added to Horizon ?
** Changed in: ossa
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1453074
Title:
[OSSA 2015-010] help_text parameter of fields is vulnerable to
arbitrary html injection (CVE-2015-3219)
Status in OpenStack Dashboard (Horizon):
Fix Committed
Status in OpenStack Security Advisories:
Fix Released
Bug description:
The Field class help_text attribute is vulnerable to code injection if
the text is somehow taken from the user input.
Heat UI allows to create stacks from the user input which define
parameters. Those parameters are then converted to the input field
which are vulnerable.
The heat stack example exploit:
description: Does not matter
heat_template_version: '2013-05-23'
outputs: {}
parameters:
param1:
type: string
label: normal_label
description: hack=">alert('YOUR HORIZON IS PWNED')"
resources: {}
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1453074/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1443798] Re: Restrict netmask of CIDR to avoid DHCP resync
Thanks Salvatore for the detail.
** Changed in: ossa
Status: Incomplete => Won't Fix
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1443798
Title:
Restrict netmask of CIDR to avoid DHCP resync
Status in OpenStack Neutron (virtual network service):
Fix Committed
Status in neutron icehouse series:
Incomplete
Status in neutron juno series:
Incomplete
Status in neutron kilo series:
Fix Released
Status in OpenStack Security Advisories:
Won't Fix
Bug description:
If any tenant creates a subnet with a netmask of 31 or 32 in IPv4,
IP addresses of network will fail to be generated, and that
will cause constant resyncs and neutron-dhcp-agent malfunction.
[Example operation 1]
- Create subnet from CLI, with CIDR /31 (CIDR /32 has the same result).
$ neutron subnet-create net 192.168.0.0/31 --name sub
Created a new subnet:
+---+--+
| Field | Value|
+---+--+
| allocation_pools | |
| cidr | 192.168.0.0/31 |
| dns_nameservers | |
| enable_dhcp | True |
| gateway_ip| 192.168.0.1 |
| host_routes | |
| id| 42a91f59-1c2d-4e33-9033-4691069c5e4b |
| ip_version| 4|
| ipv6_address_mode | |
| ipv6_ra_mode | |
| name | sub |
| network_id| 65cc6b46-17ec-41a8-9fe4-5bf93fc25d1e |
| subnetpool_id | |
| tenant_id | 4ffb89e718d346b48fdce2ac61537bce |
+---+--+
[Example operation 2]
- Create subnet from API, with cidr /32 (CIDR /31 has the same result).
$ curl -i -X POST -H "content-type:application/json" -d '{"subnet": { "name":
"badsub", "cidr" : "192.168.0.0/32", "ip_version": 4, "network_id": "8
8143cda-5fe7-45b6-9245-b1e8b75d28d8"}}' -H "x-auth-token:$TOKEN"
http://192.168.122.130:9696/v2.0/subnets
HTTP/1.1 201 Created
Content-Type: application/json; charset=UTF-8
Content-Length: 410
X-Openstack-Request-Id: req-4e7e74c0-0190-4a69-a9eb-93d545e8aeef
Date: Thu, 16 Apr 2015 19:21:20 GMT
{"subnet": {"name": "badsub", "enable_dhcp": true, "network_id":
"88143cda-5fe7-45b6-9245-b1e8b75d28d8", "tenant_id":
"4ffb89e718d346b48fdce2ac61537bce", "dns_nameservers": [],
"gateway_ip": "192.168.0.1", "ipv6_ra_mode": null, "allocation_pools":
[], "host_routes": [], "ip_version": 4, "ipv6_address_mode": null,
"cidr": "192.168.0.0/32", "id": "d210d5fd-8b3b-4c0e-b5ad-
41798bd47d97", "subnetpool_id": null}}
[Example operation 3]
- Create subnet from API, with empty allocation_pools.
$ curl -i -X POST -H "content-type:application/json" -d '{"subnet": { "name":
"badsub", "cidr" : "192.168.0.0/24", "allocation_pools": [], "ip_version": 4,
"network_id": "88143cda-5fe7-45b6-9245-b1e8b75d28d8"}}' -H
"x-auth-token:$TOKEN" http://192.168.122.130:9696/v2.0/subnets
HTTP/1.1 201 Created
Content-Type: application/json; charset=UTF-8
Content-Length: 410
X-Openstack-Request-Id: req-54ce81db-b586-4887-b60b-8776a2ebdb4e
Date: Thu, 16 Apr 2015 19:18:21 GMT
{"subnet": {"name": "badsub", "enable_dhcp": true, "network_id":
"88143cda-5fe7-45b6-9245-b1e8b75d28d8", "tenant_id":
"4ffb89e718d346b48fdce2ac61537bce", "dns_nameservers": [],
"gateway_ip": "192.168.0.1", "ipv6_ra_mode": null, "allocation_pools":
[], "host_routes": [], "ip_version": 4, "ipv6_address_mode": null,
"cidr": "192.168.0.0/24", "id": "abc2dca4-bf8b-46f5-af1a-
0a1049309854", "subnetpool_id": null}}
[Trace log]
2015-04-17 04:23:27.907 16641 DEBUG oslo_messaging._drivers.amqp [-]
UNIQUE_ID is e0a6a81a005d4aa0b40130506afa0267. _add_unique_id
/usr/local/lib/python2.7/dist-packages/oslo_messaging/_drivers/amqp.py:258
2015-04-17 04:23:27.979 16641 ERROR neutron.agent.dhcp.agent [-] Unable to
enable dhcp for 88143cda-5fe7-45b6-9245-b1e8b75d28d8.
2015-04-17 04:23:27.979 16641 TRACE neutron.agent.dhcp.agent Traceback (most
recent call last):
2015-04-17 04:23:27.979 16641 TRACE neutron.agent.dhcp.agent File
"/opt/stack/neutron/neutron/agent/dhcp/agent.py", line 112, in call_driver
2015-04-17 04:23:27.979 16641 TRACE neutron.agent.dhcp.agent
getattr(driver, action)(**action_kwargs)
2015-04-17 04:23:27.979 16641 TRACE neutron.agent.dhcp.agent File
"/opt/stack/neutron/neutron/agent/linux/dhcp.py", line 201, in enable
2015-04-17 04:23:27.979 16641 TRACE neutron.agent.dhcp.agen
[Yahoo-eng-team] [Bug 1455582] Re: Hypervisor compromise may result in malicious trust creation
** Also affects: ossn Importance: Undecided Status: New ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1455582 Title: Hypervisor compromise may result in malicious trust creation Status in OpenStack Identity (Keystone): Confirmed Status in OpenStack Security Advisories: Won't Fix Status in OpenStack Security Notes: New Bug description: If a hypervisor is compromised, and the hypervisor is a a Nova compute node, the end user now has access to every token that passes through that node. By default, a keystone token can be exchanged for another token. There is no restriction on scoping of the new token. A scoped token can be exchanged for an unscoped token, or a token scoped to a different project. We had set the default time limit for tokens down to 1 hour, to reduce the surface area of the attack. However, many workloads require a single token for the whole workload, and these workloads take more than one hour, so several installations have increased token lifespans back to the old value of 24 hours. A token can be used to change a password. If this is done, all tokens are revoked for the user. With the trust API, a user can set up a long term delegation that allows another user to perform an operation on their behalf. While tokens created via trusts are limited in what they can do, the limitations are only on things like change passwords or create a new token. Thus, if an attacker compromises a compute node and harvests tokens, the highest value attack for them is to automatically create a trust from the compromised user to some other account. This bypasses the time limitation of the token expiration, and will allow the attacker to perform operations on the users resources at the attackers convenience. Any site that is running a recent version of Heat would be expected to have many trusts set up from the customer user accounts to the Heat service user. Heat creates trusts using the users tokens, so we know this approach is not just theoretical, but actively used. This leaves a fairly obvious trail, in that a user can see all of the trusts created with the user as the trustor. Any trusts that do not have a Heat user as the trustee are suspect. It might even be possible to compromise Heat users, so even those should be audited. There are other ways that a harvested token can be abused, but the trust approach is the one I find the most worrysome, as it could be done as a "sleeper" agent. The same issues apply to the OAUTH1.0a extension. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1455582/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1461095] Re: Token is not revoked when removing a user from project in Horizon
Then it's an OSSA class E type of bug. ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1461095 Title: Token is not revoked when removing a user from project in Horizon Status in OpenStack Identity (Keystone): Invalid Status in OpenStack Security Advisories: Won't Fix Bug description: Steps: 1. Login to dashboard as admin 2. Create project (as example - `project_1`) 3. Create Member-user. 4. add Member-user to `project_1` 5. In another browser login as Member-user 6. go to `/project/instance` (the behavior is typical for another pages - `volumes`, `images`, `identity`) 7. refresh (or go to page) - 3-5 times. Stay of this page. 8. Then, as admin, remove Member-user from `project_1` 9. as Member-user try go to `/project/instance` -- you don't get error To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1461095/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1461095] Re: Token is not revoked when removing a user from project in Horizon
** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Incomplete -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1461095 Title: Token is not revoked when removing a user from project in Horizon Status in OpenStack Identity (Keystone): New Status in OpenStack Security Advisories: Incomplete Bug description: Steps: 1. Login to dashboard as admin 2. Create project (as example - `project_1`) 3. Create Member-user. 4. add Member-user to `project_1` 5. In another browser login as Member-user 6. go to `/project/instance` (the behavior is typical for another pages - `volumes`, `images`, `identity`) 7. refresh (or go to page) - 3-5 times. Stay of this page. 8. Then, as admin, remove Member-user from `project_1` 9. as Member-user try go to `/project/instance` -- you don't get error To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1461095/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1449260] Re: [OSSA 2015-009] Sanitation of metadata label (CVE-2015-3988)
** Summary changed:
- Sanitation of metadata label (CVE-2015-3988)
+ [OSSA 2015-009] Sanitation of metadata label (CVE-2015-3988)
** Changed in: ossa
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Dashboard (Horizon).
https://bugs.launchpad.net/bugs/1449260
Title:
[OSSA 2015-009] Sanitation of metadata label (CVE-2015-3988)
Status in OpenStack Dashboard (Horizon):
Fix Committed
Status in OpenStack Security Advisories:
Fix Released
Bug description:
1) Start up Horizon
2) Go to Images
3) Next to an image, pick "Update Metadata"
4) From the dropdown button, select "Update Metadata"
5) In the Custom box, enter a value with some HTML like
'alert(1)//', click +
6) On the right-hand side, give it a value, like "ee"
7) Click "Save"
8) Pick "Update Metadata" for the image again, the page will fail to load,
and the JavaScript console says:
SyntaxError: invalid property id
var existing_metadata = {"
An alternative is if you change the URL to update_metadata for the
image (for example,
http://192.168.122.239/admin/images/fa62ba27-e731-4ab9-8487-f31bac355b4c/update_metadata/),
it will actually display the alert box and a bunch of junk.
I'm not sure if update_metadata is actually a page, though... can't
figure out how to get to it other than typing it in.
To manage notifications about this bug go to:
https://bugs.launchpad.net/horizon/+bug/1449260/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1443598] Re: [OSSA 2015-008] backend_argument containing a password leaked in logs (CVE-2015-3646)
** Changed in: ossa Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1443598 Title: [OSSA 2015-008] backend_argument containing a password leaked in logs (CVE-2015-3646) Status in OpenStack Identity (Keystone): Fix Committed Status in Keystone icehouse series: Fix Committed Status in Keystone juno series: Fix Committed Status in Keystone kilo series: Fix Released Status in OpenStack Security Advisories: Fix Released Bug description: The keystone.conf has an option backend_argument to set various options for the caching backend. As documented, some of the potential values can contain a password. Snippet from http://docs.openstack.org/developer/keystone/developing.html#dogpile- cache-based-mongodb-nosql-backend [cache] # Global cache functionality toggle. enabled = True # Referring to specific cache backend backend = keystone.cache.mongo # Backend specific configuration arguments backend_argument = db_hosts:localhost:27017 backend_argument = db_name:ks_cache backend_argument = cache_collection:cache backend_argument = username:test_user backend_argument = password:test_password As a result, passwords can be leaked to the keystone logs since the config options is not marked secret. To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1443598/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1456228] Re: Trusted vm can be powered on untrusted host
Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions. Can a Nova core confirm that report ? ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Incomplete -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1456228 Title: Trusted vm can be powered on untrusted host Status in OpenStack Compute (Nova): New Status in OpenStack Security Advisories: Incomplete Bug description: This is related to the trusted compute. I recently setup trusted compute pool in my company and have observed that although new trusted vm is not able to be launched from an untrusted host, but if an trusted vm that have launched earlier on a trusted host which is compromised later on, that VM can still be powered on. 1. Exact version of Nova/Openstack: [root@grunt2 ~]# rpm -qa | grep nova python-nova-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-network-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-compute-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-conductor-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-cells-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-api-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-console-2014.1.2-100+45c2cbc.fc20.noarch python-novaclient-2.17.0-2.fc21.noarch openstack-nova-cert-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-scheduler-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-objectstore-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-common-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-novncproxy-2014.1.2-100+45c2cbc.fc20.noarch openstack-nova-doc-2014.1.2-100+45c2cbc.fc20.noarch 2. Relevant log files: this is not a error, don't think logs will help.. 3. Reproduce steps: * create trusted compute pool with only one compute node * create an trusted VM on that compute node * compromise the trusted compute node by changing the boot order * power on the trusted Vm created earlier. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1456228/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1429093] Re: nova allows to boot images with virtual size > root_gb specified in flavor
I've mark the OSSA task as won't fix as it's considered a vulnerability per se. ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1429093 Title: nova allows to boot images with virtual size > root_gb specified in flavor Status in OpenStack Compute (Nova): Fix Committed Status in OpenStack Compute (nova) kilo series: Fix Released Status in OpenStack Security Advisories: Won't Fix Bug description: It's currently possible to boot an instance from a QCOW2 image, which has the virtual size larger than root_gb size specified in the given flavor. Steps to reproduce: 1. Download a QCOW2 image (e.g. Cirros - https://launchpad.net/cirros/trunk/0.3.0/+download/cirros-0.3.0-i386-disk.img) 2. Resize the image to a reasonable size: qemu-img resize cirros-0.3.0-i386-disk.img +9G 3. Upload the image to Glance: glance image-create --file cirros-0.3.0-i386-disk.img --name cirros- 10GB --is-public True --progress --container-format bare --disk-format qcow2 4. Boot the first VM using a 'correct' flavor (root_gb > virtual size of the Cirros image), e.g. m1.small (root_gb = 20) nova boot --image cirros-10GB --flavor m1.small demo-ok 5. Wait until the VM boots. 6. Boot the second VM using an 'incorrect' flavor (root_gb < virtual size of the Cirros image), e.g. m1.tiny (root_gb = 1): nova boot --image cirros-10GB --flavor m1.tiny demo-should-fail 7. Wait until the VM boots. Expected result: demo-ok is in ACTIVE state demo-should-fail is in ERROR state (failed with FlavorDiskTooSmall) Actual result: demo-ok is in ACTIVE state demo-should-fail is in ACTIVE state To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1429093/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1435386] Re: Specific config setting may result in VMs being taken over through VNC
** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to OpenStack Compute (nova). https://bugs.launchpad.net/bugs/1435386 Title: Specific config setting may result in VMs being taken over through VNC Status in OpenStack Compute (Nova): Invalid Status in OpenStack Manuals: New Status in OpenStack Security Advisories: Won't Fix Bug description: Jonathan Hogg from Chargebox reports (edited): On a single-machine cloud running OpenStack Icehouse and over the last week we have seen compromises of all of the Ubuntu 14.04 VMs running on the machine. Scenario shows the attacker gaining access through VNC (via controlled reboot to reset root password). QEMU instances are running with -vnc 0.0.0.0:1, which may or may not be the issue. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1435386/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1435396] Re: No notifications for role grants using v2
Since this report concerns a possible security risk, an incomplete security advisory task has been added while the core security reviewers for the affected project or projects confirm the bug and discuss the scope of any vulnerability along with potential solutions. ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Incomplete -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1435396 Title: No notifications for role grants using v2 Status in OpenStack Identity (Keystone): In Progress Status in OpenStack Security Advisories: Incomplete Bug description: If you use the v3 API to add or remove role grants, you get notifications that it happened, but if you use the v2.0 API, you don't get notifications. Keystone needs to send notifications when the v2 API is used, also. For example, start with devstack, then grant a role: $ keystone user-role-add --user demo --tenant admin --role admin - gets a notification for identity.authenticate, but none for identity.created.role_assignment Same for revoke: $ keystone user-role-remove --user demo --tenant admin --role admin - gets a notification for identity.authenticate, but none for identity.deleted.role_assignment v3 works fine: $ curl -X PUT -H "X-Auth-Token: $TOKEN" http://localhost:5000/v3/projects/$PROJECT_ID/users/$USER_ID/roles/$ROLE_ID $ curl -X DELETE -H "X-Auth-Token: $TOKEN" http://localhost:5000/v3/projects/$PROJECT_ID/users/$USER_ID/roles/$ROLE_ID To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1435396/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1409142] Re: [OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server (CVE-2015-0259)
** Changed in: ossa
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Compute (nova).
https://bugs.launchpad.net/bugs/1409142
Title:
[OSSA 2015-005] Websocket Hijacking Vulnerability in Nova VNC Server
(CVE-2015-0259)
Status in OpenStack Compute (Nova):
Fix Committed
Status in OpenStack Compute (nova) icehouse series:
Fix Released
Status in OpenStack Compute (nova) juno series:
Fix Committed
Status in OpenStack Security Advisories:
Fix Released
Bug 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 as to
the bug as attachments.
OpenStack Vulnerability Team:
Brian Manifold (bmani...@cisco.com) from Cisco has discovered a
vulnerability in the Nova VNC server implementation. We have a patch for
this vulnerability and consider this a very high risk.
Please email Dave McCowan (dmcco...@cisco.com) for more details on the
attached patch.
Issue Details:
Horizon uses a VNC client which uses websockets to pass information. The
Nova VNC server does not validate the origin of the websocket request,
which allows an attacker to make a websocket request from another domain.
If the victim opens both an attacker's site and the VNC console
simultaneously, or if the victim has recently been using the VNC console
and then visits the attacker's site, the attacker can make a websocket
request to the Horizon domain and proxy the connection to another
destination.
This gives the attacker full read-write access to the VNC console of any
instance recently accessed by the victim.
Recommendation:
Verify the origin field in request header on all websocket requests.
Threat:
CWE-345
* Insufficient Verification of Data Authenticity -- The software does not
sufficiently verify the origin or authenticity of data, in a way that
causes it to accept invalid data.
CWE-346
* Origin Validation Error -- The software does not properly verify that
the source of data or communication is valid.
CWE-441
* Unintended Proxy or Intermediary ('Confused Deputy') -- The software
receives a request, message, or directive from an upstream component, but
the software does not sufficiently preserve the original source of the
request before forwarding the request to an external actor that is outside
of the software's control sphere. This causes the software to appear to be
the source of the request, leading it to act as a proxy or other
intermediary between the upstream component and the external actor.
Steps to reproduce:
1. Login to horizon
2. Pick an instance, go to console/vnc tab, wait for console to be loaded
3. In another browser tab or window, load a VNC console script from local
disk or remote site
4. Point the newly loaded VNC console to the VNC server and a connection
is made
Result:
The original connection has been been hijacked by the second connection
Root cause:
Cross-Site WebSocket Hijacking is concept that has been written about in
various security blogs.
One of the recommended countermeasures is to check the Origin header of
the WebSocket handshake request.
To manage notifications about this bug go to:
https://bugs.launchpad.net/nova/+bug/1409142/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1427533] Re: keystone logs password in log message
Thanks Brant for the quick feedback! I opened the bug since it only concerns master, can you please confirm the keystone part and tag it for kilo in order to have it fixed before the release ? ** Information type changed from Private Security to Public Security ** Changed in: ossa Status: Incomplete => Won't Fix -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Keystone. https://bugs.launchpad.net/bugs/1427533 Title: keystone logs password in log message Status in OpenStack Identity (Keystone): New Status in OpenStack Security Advisories: Won't Fix Bug description: Current master branch logs request at https://github.com/openstack/keystone/blob/master/keystone/common/wsgi.py#L230 Sample log (keystone.common.wsgi): 2015-03-03 05:42:36,072 INFO wsgi __call__ POST /auth/tokens?auth=%7Bu%27scope%27%3A+%7Bu%27project%27%3A+%7Bu%27domain%27%3A+%7Bu%27name%27%3A+u%27Default%27%7D%2C+u%27name%27%3A+u%27admin%27%7D%7D%2C+u%27identity%27%3A+%7Bu%27password%27%3A+%7Bu%27user%27%3A+%7Bu%27domain%27%3A+%7Bu%27id%27%3A+u%27default%27%7D%2C+u%27password%27%3A+u%27admin%27%2C+u%27name%27%3A+u%27admin%27%7D%7D%2C+u%27methods%27%3A+%5Bu%27password%27%5D%7D%7D c^[:^C If do url decode, you can easily see the user's password To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1427533/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1371118] Re: [OSSA 2015-004] Image file stays in store if image has been deleted during upload (CVE-2014-9684)
** Changed in: ossa Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of Yahoo! Engineering Team, which is subscribed to Glance. https://bugs.launchpad.net/bugs/1371118 Title: [OSSA 2015-004] Image file stays in store if image has been deleted during upload (CVE-2014-9684) Status in OpenStack Image Registry and Delivery Service (Glance): Fix Released Status in Glance icehouse series: Invalid Status in Glance juno series: Fix Committed Status in OpenStack Security Advisories: Fix Released Bug description: When I create a new task in v2 to upload an image, it creates the image record in db, sets status to "saving" and then begins the uploading. If the image is deleted by appropriate API call while its content is still being uploaded, an exception is raised and it is not handled in the API code. This leads to the fact that the uploaded image file stays in a storage and clogs it. File "/opt/stack/glance/glance/common/scripts/image_import/main.py", line 62, in _execute uri) File "/opt/stack/glance/glance/common/scripts/image_import/main.py", line 95, in import_image new_image = image_repo.get(image_id) File "/opt/stack/glance/glance/api/authorization.py", line 106, in get image = self.image_repo.get(image_id) File "/opt/stack/glance/glance/domain/proxy.py", line 86, in get return self.helper.proxy(self.base.get(item_id)) File "/opt/stack/glance/glance/api/policy.py", line 179, in get return super(ImageRepoProxy, self).get(image_id) File "/opt/stack/glance/glance/domain/proxy.py", line 86, in get return self.helper.proxy(self.base.get(item_id)) File "/opt/stack/glance/glance/domain/proxy.py", line 86, in get return self.helper.proxy(self.base.get(item_id)) File "/opt/stack/glance/glance/domain/proxy.py", line 86, in get return self.helper.proxy(self.base.get(item_id)) File "/opt/stack/glance/glance/db/__init__.py", line 72, in get raise exception.NotFound(msg) NotFound: No image found with ID e2285448-a56f-45b1-9e6e-216d2b304967 This bug is very similar to https://bugs.launchpad.net/glance/+bug/1188532, but it relates to task mechanism in v2. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1371118/+subscriptions -- Mailing list: https://launchpad.net/~yahoo-eng-team Post to : yahoo-eng-team@lists.launchpad.net Unsubscribe : https://launchpad.net/~yahoo-eng-team More help : https://help.launchpad.net/ListHelp
[Yahoo-eng-team] [Bug 1420696] Re: [OSSA 2015-004] Image data remains in backend after deleting the image created using task api (import-from) (CVE-2015-1881)
** Changed in: ossa
Status: In Progress => Fix Released
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to Glance.
https://bugs.launchpad.net/bugs/1420696
Title:
[OSSA 2015-004] Image data remains in backend after deleting the image
created using task api (import-from) (CVE-2015-1881)
Status in OpenStack Image Registry and Delivery Service (Glance):
Fix Committed
Status in Glance icehouse series:
Invalid
Status in Glance juno series:
Fix Committed
Status in OpenStack Security Advisories:
Fix Released
Bug 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 as to the bug
as attachments.
--
Trying to delete image created using task api (import-from) image gets
deleted from the database, but image data remains in the backend.
Steps to reproduce:
1. Create image using task api
$ curl -i -X POST -H 'User-Agent: python-glanceclient' -H 'Content-
Type: application/json' -H 'Accept-Encoding: gzip, deflate, compress'
-H 'Accept: */*' -H 'X-Auth-Token: 35a9e49237b74eddbe5057eb434b3f9e'
-d '{"type": "import", "input": {"import_from":
"http://releases.ubuntu.com/14.10/ubuntu-14.10-server-i386.iso";,
"import_from_format": "raw", "image_properties": {"disk_format":
"raw", "container_format": "bare", "name": "task_image"}}}'
http://10.69.4.176:9292/v2/tasks
2. wait until image becomes active.
3. Confirm image is in active state.
$ glance image-list
4. Delete the image
$ glance image-delete
5. Verify image-list does not show deleted image
$ glance image-list
Image gets deleted from the database but image data presents in the
backend.
Problem:
Import task does not update the location of the image and it remains None
even image becomes active.
Location entry is not added in the database in image_locations table.
While deleting the image it checks if location is present for image
[1][2] then only it deletes that image data from that location.
[1] v1:
https://github.com/openstack/glance/blob/master/glance/api/v1/images.py#L1066
[2] v2:
https://github.com/openstack/glance/blob/master/glance/location.py#L361
This issue is reproducible in stable/juno as well as in current
master.
Note: You need to replace auth_token in above curl command, otherwise it will
raise error for authentication failure.
(Use 'keystone token-get' command to generate the new token)
To manage notifications about this bug go to:
https://bugs.launchpad.net/glance/+bug/1420696/+subscriptions
--
Mailing list: https://launchpad.net/~yahoo-eng-team
Post to : yahoo-eng-team@lists.launchpad.net
Unsubscribe : https://launchpad.net/~yahoo-eng-team
More help : https://help.launchpad.net/ListHelp
