From fungi at yuggoth.org Thu Apr 2 03:09:46 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Thu, 02 Apr 2020 03:09:46 -0000 Subject: [Openstack-security] [Bug 1837339] Re: CIDR's of the form 12.34.56.78/0 should be an error References: <156375919087.9213.7607119247969683231.malonedeb@chaenomeles.canonical.com> Message-ID: <158579698647.23125.9944097398091430522.malone@wampee.canonical.com> Per Tristan's suggestion, the VMT will treat this as a security hardening opportunity, no advisory needed. ** Changed in: ossa Status: Incomplete => Won't Fix ** Information type changed from Public Security to Public ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. 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): Confirmed Status in neutron: New Status in OpenStack Security Advisory: Won't Fix 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 From gouthampravi at gmail.com Sat Apr 4 00:01:13 2020 From: gouthampravi at gmail.com (Goutham Pacha Ravi) Date: Sat, 04 Apr 2020 00:01:13 -0000 Subject: [Openstack-security] [Bug 1654598] Re: User can list other tenant's and admin's export locations References: <20170106162013.26896.18892.malonedeb@chaenomeles.canonical.com> Message-ID: <158595847683.20605.11957315222349890807.launchpad@gac.canonical.com> ** Changed in: manila/train Status: Fix Committed => Fix Released ** Changed in: manila/stein Status: Fix Committed => Fix Released -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1654598 Title: User can list other tenant's and admin's export locations Status in Manila: Fix Released Status in Manila ocata series: Won't Fix Status in Manila pike series: In Progress Status in Manila queens series: Fix Committed Status in Manila rocky series: Fix Committed Status in Manila stein series: Fix Released Status in Manila train series: Fix Released Status in Manila ussuri series: Fix Released Bug description: Currently, the share export locations API is allowing any tenant to obtain export locations of any tenant's share. See the below URL: http://172.24.47.101:8786/v2/64350ec996cb4d91bfaa728fd7199313/shares/e93eb079-58fb-4758-9d95-a9a645b0250a/export_locations 64350ec996cb4d91bfaa728fd7199313: this is a non-admin tenant ID e93eb079-58fb-4758-9d95-a9a645b0250a: this is an admin's share ID This is because the API layer of the share export locations controller is going directly to the database to obtain the export locations of the supplied share ID. The ownership check is performed at the Share/API layer, which is not invoked in this workflow. Most surprisingly of all, the tempest tests: - test_export_locations.ExportLocationsTest.test_list_share_export_locations_by_member - test_export_locations.ExportLocationsTest.test_get_share_export_location_by_member ... should not be passing at all (and should be negative tests), as they are testing if a non-admin tenant is able to obtain and list export locations of a share created by the admin_client used by tempest. Affected releases: - Liberty - Mitaka - Newton - Ocata To manage notifications about this bug go to: https://bugs.launchpad.net/manila/+bug/1654598/+subscriptions From 1654598 at bugs.launchpad.net Mon Apr 6 17:36:29 2020 From: 1654598 at bugs.launchpad.net (OpenStack Infra) Date: Mon, 06 Apr 2020 17:36:29 -0000 Subject: [Openstack-security] [Bug 1654598] Related fix merged to manila-tempest-plugin (master) References: <20170106162013.26896.18892.malonedeb@chaenomeles.canonical.com> Message-ID: <158619458978.23234.16063341862101864486.malone@wampee.canonical.com> Reviewed: https://review.opendev.org/710661 Committed: https://git.openstack.org/cgit/openstack/manila-tempest-plugin/commit/?id=b5ed5dfaa5ed4989bdefc30abb00902a46052951 Submitter: Zuul Branch: master commit b5ed5dfaa5ed4989bdefc30abb00902a46052951 Author: Tom Barron Date: Sun Mar 1 21:27:26 2020 +0100 Fix export location negative tests When running as a regular user, attempts to get share export locations for a share belonging to another user should be forbidden. Share instance export locations are not available to regular users by virtue of default policy. Related-bug: #1654598 Closes-bug: #1655427 Change-Id: Iabe7fb68facd0ddffec738ab4e98d1de3a704ee4 Signed-off-by: Goutham Pacha Ravi -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1654598 Title: User can list other tenant's and admin's export locations Status in Manila: Fix Released Status in Manila ocata series: Won't Fix Status in Manila pike series: In Progress Status in Manila queens series: Fix Committed Status in Manila rocky series: Fix Committed Status in Manila stein series: Fix Released Status in Manila train series: Fix Released Status in Manila ussuri series: Fix Released Bug description: Currently, the share export locations API is allowing any tenant to obtain export locations of any tenant's share. See the below URL: http://172.24.47.101:8786/v2/64350ec996cb4d91bfaa728fd7199313/shares/e93eb079-58fb-4758-9d95-a9a645b0250a/export_locations 64350ec996cb4d91bfaa728fd7199313: this is a non-admin tenant ID e93eb079-58fb-4758-9d95-a9a645b0250a: this is an admin's share ID This is because the API layer of the share export locations controller is going directly to the database to obtain the export locations of the supplied share ID. The ownership check is performed at the Share/API layer, which is not invoked in this workflow. Most surprisingly of all, the tempest tests: - test_export_locations.ExportLocationsTest.test_list_share_export_locations_by_member - test_export_locations.ExportLocationsTest.test_get_share_export_location_by_member ... should not be passing at all (and should be negative tests), as they are testing if a non-admin tenant is able to obtain and list export locations of a share created by the admin_client used by tempest. Affected releases: - Liberty - Mitaka - Newton - Ocata To manage notifications about this bug go to: https://bugs.launchpad.net/manila/+bug/1654598/+subscriptions From bcafarel at redhat.com Tue Apr 21 11:07:46 2020 From: bcafarel at redhat.com (Bernard Cafarelli) Date: Tue, 21 Apr 2020 11:07:46 -0000 Subject: [Openstack-security] [Bug 1865036] Re: l3 agent metadata proxy allows access to metadata from any available network References: <158281263855.14801.16461719155643273924.malonedeb@soybean.canonical.com> Message-ID: <158746726705.24139.14860550461894321912.launchpad@gac.canonical.com> ** Tags added: neutron-proactive-backport-potential -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1865036 Title: l3 agent metadata proxy allows access to metadata from any available network Status in neutron: Fix Released Status in OpenStack Security Advisory: Won't Fix Bug description: Tested with Train release, by quick code check it affects also at least Rocky, Stein and Ussuri (current master). The security issue is than one can access metadata of an arbitrary other instance if the following conditions are met (let's call the "other instance" a "victim", it can be in any other project not normally available to the attacker): 1) Victim's port fixed IP address is known. 2) Victim's port network ID is known. 3) Attacker can use a network with access to l3 agent metadata proxy (i.e. can use routers) and deploy instances. The scenario is as follows: 1) create a self-service network including the targeted address 2) create an instance with the same fixed IP address 3) create a router and wire it up with that network (other connections irrelevant) 4) boot up the instance (make sure to drop the potential route to dhcp agent metadata proxy if used) 5) run e.g.: curl -H "X-Neutron-Network-ID: $VICTIM_NET_ID" 169.254.169.254/openstack/latest/meta_data.json Observed behaviour: Normally-secret information disclosure. Expected behaviour: Proxy ignores (removes) that extra header and proceeds as if nothing happened (most expected) OR proxy returns an error (and logs it / sends a notification about it) OR proxy blocks the request and calls the police as you are a bad boy :-) (least expected... but nice) Initial code analysis: 1) the haproxy config is inadequate: https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/driver.py#L68 ^ this should replace all current headers in the current trust model 2) the reason this works with l3 agent (and so far not with dhcp agent unless there is some other general header exploit in the stack) are the following lines: https://opendev.org/openstack/neutron/src/commit/6b9765c991da8731fe39f7e7eed1ed6e2bca231a/neutron/agent/metadata/agent.py#L146-L152 To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1865036/+subscriptions From fungi at yuggoth.org Mon Apr 27 19:42:54 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 27 Apr 2020 19:42:54 -0000 Subject: [Openstack-security] [Bug 1875439] Re: glance requires md5 implementation be available References: <158800463064.13196.9717923421823525270.malonedeb@gac.canonical.com> Message-ID: <158801657493.12352.7872798746368215858.malone@gac.canonical.com> Given this is only being fixed in master, and is also not in itself a vulnerability, I don't think we'll need a formal security advisory and CVE assignment. This is probably most accurately classified as a security hardening opportunity (report class D in the VMT's taxonomy): https://security.openstack.org/vmt-process.html#incident-report-taxonomy ** Also affects: ossa Importance: Undecided Status: New ** Changed in: ossa Status: New => Won't Fix ** Information type changed from Public Security to Public ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1875439 Title: glance requires md5 implementation be available Status in Glance: New Status in OpenStack Security Advisory: Won't Fix Bug description: Glance populates a legacy 'checksum' image property which is an md5 hash of image data content. It's a "legacy" property because it has not been required for the validation of downloaded image data since glance version 17.0.0 (Rocky) when the operator-configurable secure "multihash" was implemented. However, the 'checksum' property has continued to be populated for backward compatibility. In order to populate the field, even as a courtesy, an implementation of the md5 algorithm must be available to glance; but this cannot be guaranteed in environments that comply with various security standards (for example, FIPS). As a result, there are environments in which glance cannot be run, and of course, these are most likely exactly the environments in which people want to run glance. To remove the dependency on the insecure MD5 algorithm, glance should stop populating the legacy 'checksum' field. It has already been made redundant by the secure "multihash" and is unnecessary. In order to preserve backward compatibility, the field will not be removed. As a timeframe for fixing this: an announcement can be made to operators as part of the Ussuri release, and code using md5 will be removed during the Victoria development cycle. Thus the Victoria release will not require Glance to be executed in a non-compliant security environment. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1875439/+subscriptions From fungi at yuggoth.org Mon Apr 27 19:44:58 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 27 Apr 2020 19:44:58 -0000 Subject: [Openstack-security] [Bug 1875439] Re: glance requires md5 implementation be available References: <158800463064.13196.9717923421823525270.malonedeb@gac.canonical.com> Message-ID: <158801669811.10259.14926243493470273023.malone@soybean.canonical.com> The Ussuri announcement to operators is probably best covered in the release notes and highlights (as well as deprecation wording in Glance's documentation). The Victoria announcement might make sense to be accompanied by an OSSN (OpenStack Security Note). -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1875439 Title: glance requires md5 implementation be available Status in Glance: New Status in OpenStack Security Advisory: Won't Fix Bug description: Glance populates a legacy 'checksum' image property which is an md5 hash of image data content. It's a "legacy" property because it has not been required for the validation of downloaded image data since glance version 17.0.0 (Rocky) when the operator-configurable secure "multihash" was implemented. However, the 'checksum' property has continued to be populated for backward compatibility. In order to populate the field, even as a courtesy, an implementation of the md5 algorithm must be available to glance; but this cannot be guaranteed in environments that comply with various security standards (for example, FIPS). As a result, there are environments in which glance cannot be run, and of course, these are most likely exactly the environments in which people want to run glance. To remove the dependency on the insecure MD5 algorithm, glance should stop populating the legacy 'checksum' field. It has already been made redundant by the secure "multihash" and is unnecessary. In order to preserve backward compatibility, the field will not be removed. As a timeframe for fixing this: an announcement can be made to operators as part of the Ussuri release, and code using md5 will be removed during the Victoria development cycle. Thus the Victoria release will not require Glance to be executed in a non-compliant security environment. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1875439/+subscriptions From fungi at yuggoth.org Mon Apr 27 21:53:23 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Mon, 27 Apr 2020 21:53:23 -0000 Subject: [Openstack-security] [Bug 1786646] Re: Domain Existence Leaking without authentication References: <153402622402.7907.1399670648143392057.malonedeb@wampee.canonical.com> Message-ID: <158802440381.13196.3255964287535010494.malone@gac.canonical.com> As there seems to be some consensus, I've gone ahead and switched this bug to public, marking our security advisory task Won't Fix. I'll leave it to the Keystone maintainers to do the same with theirs. ** 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. This - embargo shall not extend past 2020-05-27 and will be made - public by or on that date if no fix is identified. - The Domain Configuration subsystem, specifically PATCH /domains/{domain_id}/config/{group} appears to leak data before enforcement. The method called from the routed path[0] performs a "domain exists" check[1] before sending to the 'update_domain_config' method [2] which is behind the @protected decorator. This has the potential to be used to verify existence of domains by ID without authentication. This is in-fact a data leak. However, since domains (outside of "default" and the keystone-root domain) are uuids, this is likely a C1 classification in the VMT Taxonomy [3] (Useful if an attacker is guessing UUIDs). The only case where this is more significant is that it can be used to determine if the default domain is enabled/configured; the usefulness of such data is relatively suspect and unlikely to be meaningful. However, with all that said, since this is a potential security flaw, the bug has been marked private security. [0] https://github.com/openstack/keystone/blob/c7ae6b798ad4b2164ed6248f1714ec44b27edb7a/keystone/resource/routers.py#L55 [1] https://github.com/openstack/keystone/blob/c7ae6b798ad4b2164ed6248f1714ec44b27edb7a/keystone/resource/controllers.py#L134 [2] https://github.com/openstack/keystone/blob/c7ae6b798ad4b2164ed6248f1714ec44b27edb7a/keystone/resource/controllers.py#L125-L131 [3] https://security.openstack.org/vmt-process.html#incident-report-taxonomy ** Information type changed from Private Security to Public ** Changed in: ossa Status: Incomplete => Won't Fix ** Tags added: security -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1786646 Title: Domain Existence Leaking without authentication Status in OpenStack Identity (keystone): Confirmed Status in OpenStack Security Advisory: Won't Fix Bug description: The Domain Configuration subsystem, specifically PATCH /domains/{domain_id}/config/{group} appears to leak data before enforcement. The method called from the routed path[0] performs a "domain exists" check[1] before sending to the 'update_domain_config' method [2] which is behind the @protected decorator. This has the potential to be used to verify existence of domains by ID without authentication. This is in-fact a data leak. However, since domains (outside of "default" and the keystone-root domain) are uuids, this is likely a C1 classification in the VMT Taxonomy [3] (Useful if an attacker is guessing UUIDs). The only case where this is more significant is that it can be used to determine if the default domain is enabled/configured; the usefulness of such data is relatively suspect and unlikely to be meaningful. However, with all that said, since this is a potential security flaw, the bug has been marked private security. [0] https://github.com/openstack/keystone/blob/c7ae6b798ad4b2164ed6248f1714ec44b27edb7a/keystone/resource/routers.py#L55 [1] https://github.com/openstack/keystone/blob/c7ae6b798ad4b2164ed6248f1714ec44b27edb7a/keystone/resource/controllers.py#L134 [2] https://github.com/openstack/keystone/blob/c7ae6b798ad4b2164ed6248f1714ec44b27edb7a/keystone/resource/controllers.py#L125-L131 [3] https://security.openstack.org/vmt-process.html#incident-report-taxonomy To manage notifications about this bug go to: https://bugs.launchpad.net/keystone/+bug/1786646/+subscriptions From rosmaita.fossdev at gmail.com Tue Apr 28 02:53:09 2020 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Tue, 28 Apr 2020 02:53:09 -0000 Subject: [Openstack-security] [Bug 1875439] Re: glance requires md5 implementation be available References: <158800463064.13196.9717923421823525270.malonedeb@gac.canonical.com> Message-ID: <158804239001.12622.2532538703741311225.malone@gac.canonical.com> Patch to the ussuri release notes: https://review.opendev.org/723638 -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1875439 Title: glance requires md5 implementation be available Status in Glance: New Status in OpenStack Security Advisory: Won't Fix Bug description: Glance populates a legacy 'checksum' image property which is an md5 hash of image data content. It's a "legacy" property because it has not been required for the validation of downloaded image data since glance version 17.0.0 (Rocky) when the operator-configurable secure "multihash" was implemented. However, the 'checksum' property has continued to be populated for backward compatibility. In order to populate the field, even as a courtesy, an implementation of the md5 algorithm must be available to glance; but this cannot be guaranteed in environments that comply with various security standards (for example, FIPS). As a result, there are environments in which glance cannot be run, and of course, these are most likely exactly the environments in which people want to run glance. To remove the dependency on the insecure MD5 algorithm, glance should stop populating the legacy 'checksum' field. It has already been made redundant by the secure "multihash" and is unnecessary. In order to preserve backward compatibility, the field will not be removed. As a timeframe for fixing this: an announcement can be made to operators as part of the Ussuri release, and code using md5 will be removed during the Victoria development cycle. Thus the Victoria release will not require Glance to be executed in a non-compliant security environment. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1875439/+subscriptions From rosmaita.fossdev at gmail.com Tue Apr 28 11:28:57 2020 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Tue, 28 Apr 2020 11:28:57 -0000 Subject: [Openstack-security] [Bug 1875439] Re: glance requires md5 implementation be available References: <158800463064.13196.9717923421823525270.malonedeb@gac.canonical.com> Message-ID: <158807333710.7438.6597232321338440909.malone@chaenomeles.canonical.com> I forgot to mention that I agree with Jeremy's assessment of this as class D. An OSSN during Victoria is a good idea; people for whom this is a problem may wish to plan ahead to upgrade their clouds. ** Changed in: glance Status: New => Triaged ** Changed in: glance Importance: Undecided => High -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1875439 Title: glance requires md5 implementation be available Status in Glance: Triaged Status in OpenStack Security Advisory: Won't Fix Bug description: Glance populates a legacy 'checksum' image property which is an md5 hash of image data content. It's a "legacy" property because it has not been required for the validation of downloaded image data since glance version 17.0.0 (Rocky) when the operator-configurable secure "multihash" was implemented. However, the 'checksum' property has continued to be populated for backward compatibility. In order to populate the field, even as a courtesy, an implementation of the md5 algorithm must be available to glance; but this cannot be guaranteed in environments that comply with various security standards (for example, FIPS). As a result, there are environments in which glance cannot be run, and of course, these are most likely exactly the environments in which people want to run glance. To remove the dependency on the insecure MD5 algorithm, glance should stop populating the legacy 'checksum' field. It has already been made redundant by the secure "multihash" and is unnecessary. In order to preserve backward compatibility, the field will not be removed. As a timeframe for fixing this: an announcement can be made to operators as part of the Ussuri release, and code using md5 will be removed during the Victoria development cycle. Thus the Victoria release will not require Glance to be executed in a non-compliant security environment. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1875439/+subscriptions From rosmaita.fossdev at gmail.com Tue Apr 28 11:44:38 2020 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Tue, 28 Apr 2020 11:44:38 -0000 Subject: [Openstack-security] [Bug 1875630] [NEW] issue OSSN when glance no longer requires an md5 implementation Message-ID: <158807427848.8151.9799056437284775242.malonedeb@chaenomeles.canonical.com> Public bug reported: See https://bugs.launchpad.net/glance/+bug/1875439 for background. ** Affects: glance Importance: Medium Status: Triaged ** Tags: documentation security ** Changed in: glance Importance: Undecided => Medium -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1875630 Title: issue OSSN when glance no longer requires an md5 implementation Status in Glance: Triaged Bug description: See https://bugs.launchpad.net/glance/+bug/1875439 for background. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1875630/+subscriptions From rosmaita.fossdev at gmail.com Tue Apr 28 11:40:47 2020 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Tue, 28 Apr 2020 11:40:47 -0000 Subject: [Openstack-security] [Bug 1875439] Re: glance requires md5 implementation be available References: <158800463064.13196.9717923421823525270.malonedeb@gac.canonical.com> Message-ID: <158807404708.7720.16156991322887525250.malone@chaenomeles.canonical.com> Filed https://bugs.launchpad.net/glance/+bug/1875629 so we don't forget about the documentation update that Jeremy suggested. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1875439 Title: glance requires md5 implementation be available Status in Glance: Triaged Status in OpenStack Security Advisory: Won't Fix Bug description: Glance populates a legacy 'checksum' image property which is an md5 hash of image data content. It's a "legacy" property because it has not been required for the validation of downloaded image data since glance version 17.0.0 (Rocky) when the operator-configurable secure "multihash" was implemented. However, the 'checksum' property has continued to be populated for backward compatibility. In order to populate the field, even as a courtesy, an implementation of the md5 algorithm must be available to glance; but this cannot be guaranteed in environments that comply with various security standards (for example, FIPS). As a result, there are environments in which glance cannot be run, and of course, these are most likely exactly the environments in which people want to run glance. To remove the dependency on the insecure MD5 algorithm, glance should stop populating the legacy 'checksum' field. It has already been made redundant by the secure "multihash" and is unnecessary. In order to preserve backward compatibility, the field will not be removed. As a timeframe for fixing this: an announcement can be made to operators as part of the Ussuri release, and code using md5 will be removed during the Victoria development cycle. Thus the Victoria release will not require Glance to be executed in a non-compliant security environment. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1875439/+subscriptions From rosmaita.fossdev at gmail.com Tue Apr 28 11:45:49 2020 From: rosmaita.fossdev at gmail.com (Brian Rosmaita) Date: Tue, 28 Apr 2020 11:45:49 -0000 Subject: [Openstack-security] [Bug 1875439] Re: glance requires md5 implementation be available References: <158800463064.13196.9717923421823525270.malonedeb@gac.canonical.com> Message-ID: <158807435004.7555.16297032041720750932.malone@chaenomeles.canonical.com> Filed https://bugs.launchpad.net/glance/+bug/1875630 so we don't forget about the OSSN. -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1875439 Title: glance requires md5 implementation be available Status in Glance: Triaged Status in OpenStack Security Advisory: Won't Fix Bug description: Glance populates a legacy 'checksum' image property which is an md5 hash of image data content. It's a "legacy" property because it has not been required for the validation of downloaded image data since glance version 17.0.0 (Rocky) when the operator-configurable secure "multihash" was implemented. However, the 'checksum' property has continued to be populated for backward compatibility. In order to populate the field, even as a courtesy, an implementation of the md5 algorithm must be available to glance; but this cannot be guaranteed in environments that comply with various security standards (for example, FIPS). As a result, there are environments in which glance cannot be run, and of course, these are most likely exactly the environments in which people want to run glance. To remove the dependency on the insecure MD5 algorithm, glance should stop populating the legacy 'checksum' field. It has already been made redundant by the secure "multihash" and is unnecessary. In order to preserve backward compatibility, the field will not be removed. As a timeframe for fixing this: an announcement can be made to operators as part of the Ussuri release, and code using md5 will be removed during the Victoria development cycle. Thus the Victoria release will not require Glance to be executed in a non-compliant security environment. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1875439/+subscriptions From fungi at yuggoth.org Tue Apr 28 18:01:29 2020 From: fungi at yuggoth.org (Jeremy Stanley) Date: Tue, 28 Apr 2020 18:01:29 -0000 Subject: [Openstack-security] [Bug 1875630] Re: issue OSSN when glance no longer requires an md5 implementation References: <158807427848.8151.9799056437284775242.malonedeb@chaenomeles.canonical.com> Message-ID: <158809688995.12570.5823908535281257471.launchpad@gac.canonical.com> ** Also affects: ossn Importance: Undecided Status: New -- You received this bug notification because you are a member of OpenStack Security SIG, which is subscribed to OpenStack. https://bugs.launchpad.net/bugs/1875630 Title: issue OSSN when glance no longer requires an md5 implementation Status in Glance: Triaged Status in OpenStack Security Notes: New Bug description: See https://bugs.launchpad.net/glance/+bug/1875439 for background. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1875630/+subscriptions