[Yahoo-eng-team] [Bug 1703369] Re: get_identity_providers policy should be singular
Sounds right Mircea, but it won't be a security issue this time, as its in docs / unit tests, rather than code that could be used in production. Still needs a bug raised in horizon though, and well spotted. ** Changed in: ossn Status: Confirmed => 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/1703369 Title: get_identity_providers policy should be singular Status in OpenStack Identity (keystone): Fix Released Status in OpenStack Identity (keystone) newton series: Fix Committed Status in OpenStack Identity (keystone) ocata series: Fix Committed Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released 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 1721063] Re: vulnerability in dnsmasq
** Changed in: ossn 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/1721063 Title: vulnerability in dnsmasq Status in neutron: Won't Fix Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Fix Released Bug description: As per [1],[2] , there have been some vulnerability issue in dnsmasq. The same have been fixed in dnsmasq version 2.78 In order to avoid the vulnerabilities, it would be advisable to update dnsmasq to version 2.78 [1]: https://security.googleblog.com/2017/10/behind-masq-yet-more-dns-and-dhcp.html [2]: https://thehackernews.com/2017/10/dnsmasq-network-services.html?utm_source=feedburner_medium=feed_campaign=Feed%3A+TheHackersNews+%28The+Hackers+News+-+Security+Blog%29&_m=3n.009a.1592.dj0ao06ba4.yhy To manage notifications about this bug go to: https://bugs.launchpad.net/neutron/+bug/1721063/+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
** Changed in: ossn Status: Fix Committed => 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/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: Fix Released 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 1686743] Re: Ceph credentials included in logs using older libvirt/qemu
** Changed in: ossn 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/1686743 Title: Ceph credentials included in logs using older libvirt/qemu Status in OpenStack Compute (nova): Opinion Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: 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. Older versions of libvirt included network storage authentication information on the qemu command line. If libvirt raises an exception which logs the qemu command line it used, for example an error starting a domain, this authentication information will end up in the logs. There is an existing CVE for this issue here: https://access.redhat.com/security/cve/CVE-2015-5160 Specifically, if a deployment is using ceph, a libvirt error starting a domain would log the cephx secret key and the monitor addresses on the qemu command line. The issue has been resolved upstream. Users running qemu version 2.6 or later, and libvirt version 2.2 or later, are not vulnerable. No change is required in Nova to resolve this issue. Red Hat users running RHEL 7.3 or later are not vulnerable. It's not 100% clear to me that an OpenStack CVE is required here as it's not a bug in an OpenStack component, and it's already fixed upstream. However, it did come to my attention after a user publicly posted their ceph credentials on IRC, so evidently some OpenStack users are running vulnerable systems, and this is a very common configuration. In Nova, we currently have: MIN_LIBVIRT_VERSION = (1, 2, 9) MIN_QEMU_VERSION = (2, 1, 0) so anybody running the minimum supported versions will be vulnerable. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1686743/+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"
will add a docs bug for this issue.
** Changed in: ossn
Status: New => 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/1618615
Title:
Potential information disclosure in EC2 "credentials"
Status in OpenStack Identity (keystone):
New
Status in OpenStack Security Advisory:
Won't Fix
Status in OpenStack Security Notes:
Won't Fix
Bug description:
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
{
"credential": {
"blob": "{\"access\":\"\u\",\"secret\":\"secretKey\"}",
"project_id": "12345",
"type": "ec2",
"user_id": "12345"
}
}
HTTP/1.1 500 Internal Server Error
Date: Tue, 30 Aug 2016 20:06:16 GMT
Server: Apache/2.4.7 (Ubuntu)
Vary: X-Auth-Token
Content-Length: 143
Content-Type: application/json
{"error": {"message": "An unexpected error
[Yahoo-eng-team] [Bug 1673085] Re: scheduler hints are unbounded and never deleted
** Changed in: ossn Status: New => 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/1673085 Title: scheduler hints are unbounded and never deleted Status in OpenStack Compute (nova): New Status in OpenStack Security Advisory: Won't Fix Status in OpenStack Security Notes: Won't Fix Bug description: I'm initially reporting this as a potential security issue but it might not be, I'm just looking for feedback from the VMT. The scheduler_hints in the compute API are stored in the request_specs.spec column in the nova_api database: https://github.com/openstack/nova/blob/15.0.1/nova/db/sqlalchemy/api_models.py#L171 There is no limit on the size of the keys or values, or number of hints, in the API: https://github.com/openstack/nova/blob/15.0.1/nova/api/openstack/compute/schemas/scheduler_hints.py#L18 There are some pre-defined hints, but additionalProperties=True in the json schema means that one can provide any hints they want. So I could boot a server with a scheduler_hints dict that has a million keys which are a million characters long. At best that just results in a 500 because the column size limit in the database rejects the json blob size. According to the mysql 5.7 docs: https://dev.mysql.com/doc/refman/5.7/en/string-type-overview.html "TEXT[(M)] [CHARACTER SET charset_name] [COLLATE collation_name] A TEXT column with a maximum length of 65,535 (216 − 1) characters. The effective maximum length is less if the value contains multibyte characters. Each TEXT value is stored using a 2-byte length prefix that indicates the number of bytes in the value." At worst, I'm able to work backward from a million until I found out the limit at which I can fill the request_specs.spec column and then just hammer the compute API, filling up the nova_api database. So there are two issues: 1. No key/value size limit in the API json schema for scheduler hints. 2. No quota limit on the number of hints one can provide (unlike quota limits on user-provided metadata key/value pairs which are limited to 255 for the key/value and 128 for the quota). Add to this the fact that we never delete request_specs entries from the nova_api database automatically (that's being worked on here: https://review.openstack.org/#/c/391060/ ). This might not be a security issue, it might just be poor API design and we can tighten things up to avoid a 500 error with quota limits and json schema validation on the key/value size on each hint, and also delete request specs when we delete an instance. To manage notifications about this bug go to: https://bugs.launchpad.net/nova/+bug/1673085/+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 1649248] Re: Glance image upload wizard does not restrict invalid image files
After discussing this in the OSSP meeting, I will mark this as won't fix for the OSSN, as we already have covered this the recommended actions in several previous OSSNs. There is also a good amount of info in the security guide around protecting end points and access controls available for glance. ** Changed in: ossn Status: New => 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/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: Won't Fix 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 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. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1649248/+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 1606495] Re: copy_from in api v1 allows network port scan
** Changed in: ossn 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/1606495 Title: copy_from in api v1 allows network port scan Status in Glance: New Status in OpenStack Security Advisory: Opinion Status in OpenStack Security Notes: 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. copy_from allows to create Images with an url like http://localhost:22 The remote content gets copied unverified in the defined glance store. E.g. after downloading the image with copy_from url http://localhost:22, you see the OpenSSH banner. This is a security issue, as it allows users to do network "scans" for open ports and it copies remote (potentially malicious) content unverified to your configured glance store. glance api v1 is still the default in horizon. To manage notifications about this bug go to: https://bugs.launchpad.net/glance/+bug/1606495/+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 1585831] Re: Horizon dashboard leaks internal information through cookies
OSSN released: https://wiki.openstack.org/wiki/OSSN/OSSN-0073 ** Changed in: ossn Status: Confirmed => 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/1585831 Title: Horizon dashboard leaks internal information through cookies Status in OpenStack Dashboard (Horizon): Invalid Status in OpenStack Security Notes: Fix Released Bug description: When horizon is configured where: 1) internalURL and publicURL are on different networks 2) horizon uses the internalURL endpoint for authentication The cookie "login_region" will be set to the value configured as OPENSTACK_KEYSTONE_URL. This URL contains the IP address of the internalURL of keystone. In the case of a deployment where the internal network is different than the public network, the IP address of the internal network is considered sensitive information. By putting the OPENSTACK_KEYSTONE_URL in the cookie that is sent to the public network, horizon leaks the values of the internal network IP addresses. To manage notifications about this bug go to: https://bugs.launchpad.net/horizon/+bug/1585831/+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
** Changed in: ossn Status: Confirmed => 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/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: Fix Released 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
