[Openstack] [OSSN-0084] Data retained after deletion of a ScaleIO volume

[Luke Hinds]

Data retained after deletion of a ScaleIO volume
---

### Summary ###
Certain storage volume configurations allow newly created volumes to
contain previous data. This could lead to leakage of sensitive
information between tenants.

### Affected Services / Software ###
Cinder releases up to and including Queens with ScaleIO volumes
using thin volumes and zero padding.

### Discussion ###
Using both thin volumes and zero padding does not ensure data contained
in a volume is actually deleted. The default volume provisioning rule is
set to thick so most installations are likely not affected. Operators
can check their configuration in `cinder.conf` or check for zero padding
with this command `scli --query_all`.

 Recommended Actions 

Operators can use the following two workarounds, until the release of
Rocky (planned 30th August 2018) which resolves the issue.

1. Swap to thin volumes

2. Ensure ScaleIO storage pools use zero-padding with:

`scli --modify_zero_padding_policy
(((--protection_domain_id  |
--protection_domain_name )
--storage_pool_name ) | --storage_pool_id )
(--enable_zero_padding | --disable_zero_padding)`

### Contacts / References ###
Author: Nick Tait
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0084
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1699573
Mailing List : [Security] tag on openstack-...@lists.openstack.org
OpenStack Security Project : https://launchpad.net/~openstack-ossg



signature.asc
Description: OpenPGP digital signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [OSSN-0083] Keystone policy rule "identity:get_identity_providers" was ignored

[Luke Hinds]

Keystone policy rule "identity:get_identity_providers" was ignored
---

### Summary ###
A policy rule in Keystone did not behave as intended leading to a less
secure configuration than would be expected.

### Affected Services / Software ###
OpenStack Identity Service (Keystone) versions through Mitaka, as well
as Newton (<= 10.0.3), and Ocata (<= 11.0.3).

### Discussion ###
Deployments were unaffected by this problem if the default rule was
changed or the "get_identity_providers" rule was manually changed to
be "get_identity_provider" (singular) in keystone's `policy.json`.

A spelling mistake in the default policy configuration caused these
rules to be ignored. As a result operators that attempted to restrict
this API were unlikely to actually enforce it.

### Recommended Actions ###
Update Keystone to a minimum version of 12.0.0.0b3. Additionally, this
fix has been backported to Ocata (11.0.3) and Newton (10.0.3).

Fix any lingering rules: `identity:get_identity_providers` should
be changed to `identity:get_identity_provider`.

### Contacts / References ###
Author: Nick Tait
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0083
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1703369
Mailing List : [Security] tag on openstack-...@lists.openstack.org
OpenStack Security Project : https://launchpad.net/~openstack-ossg


0x3C202614.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [OSSN-0082] Heap and Stack based buffer overflows in dnsmasq prior to version 2.78

[Luke Hinds]

Heap and Stack based buffer overflows in dnsmasq prior to version 2.78
--

### Summary ###
A series of heap and stack based buffer overflows have been discovered
in versions of dnsmasq prior to release 2.78.

### Affected Services / Software ###
Any neutron based OpenStack deployment on a version of dnsmasq prior to
2.78.

### Discussion ###
The following attack vectors have been assigned the following CVE numbers.

* CVE-2017-14491
* CVE-2017-14492
* CVE-2017-14493
* CVE-2017-14494
* CVE-2017-14495
* CVE-2017-14496
* CVE-2017-13704

Each of these CVE's exposes a neutron based OpenStack deployment to
various attacks such as leakage of sensitive memory information or
causing a denial of service. Nodes are exposed to this risk by the
crafting of various nefarious DNS or DHCP requests.

### Recommended Actions ###
Operators should update the dnsmasq service using the affected nodes
operating systems packaging tools to version 2.78 and later, or a
distribution packaged version that contains relevant backports for these
vulnerabilities.

### Contacts / References ###
Author: Luke Hinds 
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0082
Mailing List : [Security] tag on openstack-...@lists.openstack.org
Launchpad Bug: https://bugs.launchpad.net/neutron/+bug/1721063
CVE: CVE-2017-14491
OpenStack Security Project : https://launchpad.net/~openstack-ossg



signature.asc
Description: OpenPGP digital signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [OSSN-0081] sha512_crypt is insufficient for password hashing

[Luke Hinds]

sha512_crypt is insufficient for password hashing
-

### Summary ###

Use of sha512_crypt for password hashing in versions of Keystone prior
to Pike, is insufficient and provides limited protection against
brute-forcing of password hashes.

### Affected Services / Software ###
OpenStack Identity Service (Keystone). OpenStack Releases Ocata, Newton.

### Discussion ###

Keystone uses sha512_crypt for password hashing. This provides
insufficient and limited protection, since sha512_crypt algorithm has a
low computational cost factor, therefore making it easier to crack
passwords offline in a short period of time.

The correct mechanism is to use the more secure hashing algorithms with
a higher computational cost factor such as bcrypt, scrypt, or
pbkdf2_sha512 instead of sha512_crypt.

### Recommended Actions ###

It is recommended that operators upgrade to the Pike release where all
future passwords would be bcrypt hashed.

Operators should also force password changes on all users [1], which
will result in the users newly generated passwords being bcrypt hashed.

### Contacts / References ###
Author: Luke Hinds 
[1]:
https://docs.openstack.org/keystone/latest/admin/identity-security-compliance.html#force-users-to-change-password-upon-first-use
[2] http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0081
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1668503
Mailing List : [Security] tag on openstack-...@lists.openstack.org
OpenStack Security Project : https://launchpad.net/~openstack-ossg



signature.asc
Description: OpenPGP digital signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [OSSN 0080] Aodh can be used to launder Keystone trusts

[Luke Hinds]

Aodh can be used to launder Keystone trusts
---

### Summary ###

When adding an alarm action with the scheme `trust+http:` Aodh does not
verify that the user creating the alarm is the trustor or has the same
rights as the trustor, not that the trust is for the same project as the
alarm.

### Affected Services / Software ###

Aodh the alarm engine of the Telemetry project.

Pike, Ocata and Newton

### Discussion ###

When adding an alarm action with the scheme `trust+http:`, Aodh allows
the user to provide a trust ID to acquire a token with which to make a
webhook request. (If no trust ID is provided then Aodh creates a trust
internally, in which case the issue is not present.) However, Aodh makes
no attempt to verify that the user creating the alarm is the trustor or
has the same rights as the trustor - it also does not attempt to check
that the trust is for the same project as the alarm.

The nature of the `trust+http:` alarm notifier is that it allows the
user to obtain a token given the ID of a trust for which Aodh is the
trustee, since the URL is arbitrary and not limited to services in the
Keystone catalog.

### Recommended Actions ###

A patchfile is attached to the launchpad bug referenced below. It will
block use of trust URLs which contain trust ID's and log an error
message of "trust URL cannot contain a trust ID.". Any trust action
without a trust ID will result in Aodh internally creating a trust ID as
before.

You will also need to restart the web server used for Aodh API. This is
typically apache. In cases of eventlet (in older versions) it will
require restart openstack-aodh-api for centos/RHEL/Suse and aodh-api
for ubuntu.

The fix has also been merged to master (Pike), Ocata and Newton.

### Contacts / References ###
Discoverer: Zane Bitter, Red Hat
Author: Luke Hinds, Red Hat
CVE: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2017-12440
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0080
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1649333
OpenStack Security Project : https://launchpad.net/~openstack-ossg



signature.asc
Description: OpenPGP digital signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [OSSN-0078] Ceph credentials included in logs using older versions of libvirt/qemu

[Luke Hinds]

Ceph credentials included in logs using older versions of libvirt/qemu
--

### Summary ###
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 available in the logs.

### Affected Services / Software ###
Versions 2.5 and earlier of QEMU and libvirt versions of 2.1 or earlier.

The issue has been resolved in all QEMU versions 2.6 and above and
libvirt 2.2 and above.

No patches or specific releases of Nova or Ceph are required, the
issue is completely resolved in QEMU and libvirt.

### Discussion ###
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.

A local attacker could then use this flaw to gain access of the cephx
secret key and perform certain privileged operations within the cluster.

An existing CVE is already present for this issue.

### Recommended Actions ###
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 or Ceph to resolve this issue.

### Contacts / References ###
Author: Luke Hinds, Red Hat
https://access.redhat.com/security/cve/CVE-2015-5160
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0079
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1686743
OpenStack Security Project : https://launchpad.net/~openstack-ossg



signature.asc
Description: OpenPGP digital signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [OSSN-0078] copy_from in Image Service API v1 allows network port scan

[Luke Hinds]

copy_from in Image Service API v1 allows network port scan
---

### Summary ###
The `copy_from` feature in Image Service API v1 supplied by Glance can
allow an attacker to perform masked network port scans.

### Affected Services / Software ###
Version 1 of the Glance Image Service (deprecated in Newton).

### Discussion ###
In Version 1 of the Glance Image Service API it is possible to create
images with a URL such as `http://localhost:22`. This could then allow
an attacker to enumerate internal network details while appearing
masked, since the scan would appear to originate from the Glance image
service.

### Recommended Actions ###
Version 1 of the Glance Image Service API was deprecated in the Newton
cycle, so operators should upgrade to a later version that will allow
use of Version 2.

Existing deployments can limit policy on `copy_from` by restricting use
to `admin` within `policy.json` as follows:

"copy_from": "role:admin"

### Contacts / References ###
Author: Luke Hinds, Red Hat
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0078
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1606495
OpenStack Security Project : https://launchpad.net/~openstack-ossg




signature.asc
Description: OpenPGP digital signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [OSSN 0065] Users of Glance may be able to replace active image data

[Luke Hinds]

Users of Glance may be able to replace active image data
---

### Summary ###
When Glance has been configured with the "show_multiple_locations"
option enabled with default policy for set and delete locations, it is
possible for a non-admin user having write access to the image metadata
to replace active image data.

### Affected Services / Software ###
Glance, Havana, Icehouse, Juno, Kilo, Liberty, Mitaka, Newton, Ocata

### Discussion ###

As a convenience to operators, Glance has a multiple location feature,
disabled by default, that allows a single image to be stored in multiple
places. This is intended to offer an extra degree of resilience by
improving the availability of Glance images. This feature involves a
user setting a new entry in an image's 'locations' list, not visible to
users by default, via the Glance API. However, this process does not
involve taking a checksum of the data in a newly created image location,
and hence does not involve comparing the 'checksum' field of the image
(which is always visible to users) with the checksum of any added
locations. This design opens the possibility that a malicious user
could create an image in Glance, set an additional location on that
image pointing to an altered image, then delete the original location,
so that consumers of the original image would unwittingly be using the
malicious image. Note, however, that this attack vector cannot change
the original image's checksum, and it is limited to images that are
owned by the attacker.

### Recommended Actions ###

The reach of this attack depends upon how broadly usage of the original
image is spread among consumers who do not checksum images before they
are used. Glance enables three ways for an image to be made
available to other users:

1 Making an image "public". This makes an image available to all users
  of a cloud. The ability to do this is governed by the
  'publicize_image' policy, which is restricted to the admin role by
  default since the Juno release.

2 Making an image "community". *This feature is only available since
  Ocata.* This makes an image available to all users of a cloud, but
  unlike a "public" image, it does not appear in the default image-list
  response of any user (other than the owner). It is governed by the
  'communitize_image' policy, which is unrestricted by default.

3 Making an image "shared". Glance allows project-to-project image
  sharing, in which a user in project A shares an image with project B
  by making project B a *member* of the image. The ability to do this
  is governed by the 'add_member' policy, which is unrestricted by
  default.

  * Project-to-project sharing is the default, based on the
'owner_is_tenant' configuration setting in Glance. In a cloud
configured so that 'owner_is_tenant' is false, image sharing is
user-to-user. This is a cloud-wide configuration, users may not
determine whether sharing is project-to-project or owner-to-owner.

Note that what has been discussed so far is independent of the specific
vulnerability discussed in this notice. We encourage cloud operators to
review their current settings for the policies mentioned above. In
particular, we recommend that the 'publicize_image' policy be restricted
to admins (as it has been by default since the Juno release) so that
users can rely on the trustworthiness of a "public" image.

With respect to the image location vulnerability described above, we
recommend that operators review the settings of the following
configuration options and policies:

* The configuration option 'show_multiple_locations'. If this is set to
  False, this attack vector is not available.

* The policy 'set_image_location'. When 'show_multiple_locations' is
  set to True, we recommend that this policy be restricted to
  administrators, and if necessary, to trusted users. It is currently
  unrestricted by default.

* The policies 'get_image_location' and 'delete_image_location'. These
  policies are unrestricted by default (but note that if
  'show_multiple_locations' is False, they do not come into play).

Additionally, image consumers should be encouraged to checksum images
they consume and compare the result to the 'checksum' field in the
response from the Images API.

Finally, in addition to reviewing the specific location policy targets
mentioned above, we encourage operators to review the 'default' target
in their Glance policy.json file. This target is used when the software
references a policy target that is not specifically defined in the
policy.json file, as may happen when new targets are introduced in the
software but the policy file being used is from a prior release. Since
Newton, Glance has shipped with "default":"role:admin", but prior to
that, Glance shipped with "default":"", which would make any target not
specifically mentioned in the file unrestricted.

### Contacts / References ###
Author: Robert Clark, IBM
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0065
Origin

[Openstack] [OSSN-0074] Nova metadata service should not be used for sensitive information

[Luke Hinds]

OpenStack Security Note: 0074

Nova metadata service should not be used for sensitive information

---

### Summary ###
A recent security report has highlighted how users may be using the
metadata service to store security sensitive information.

The Nova metadata service should not be considered a secure repository
of confidential information required by compute instances.

### Affected Services / Software ###
Nova, All Versions

### Discussion ###
A recent vulnerability report for Nova stated that the metadata service
will obey the `X-Forwarded-For` HTTP header. This header is often
supplied by proxies so that the end service can identify which IP the
request originated from.

The Nova metadata service typically uses the source IP address of the
incoming request to respond with the appropriate data for the compute
instance making the request. This is a sort of weak authentication,
designed to ensure that metadata for one tenant isn't accidentally
provided to another.

If the request contains a `X-Forwarded-For` HTTP header then the
metadata service will use that for the source authentication rather than
the actual TCP/IP source.

An attacker with access to a compute instance in the cloud could send a
request to the metadata service and include the `X-Forwarded-For` header
in order to effectively spoof their source and cause the metadata
service to provide information that should not have been provided to
that instance.

Consider the following:
Alice creates a compute instance. She places the root password for that
instance in the metadata service. The instance is assigned a 10.1.2.2
IP address. Alice believes that the root password for her instance is
safe within the metadata service.

Alice retrieves metadata by running a command similar to:
`curl http://169.254.169.254/latest/meta-data
`
this will retrieve any metadata stored for Alice's compute instance,
which has an IP address of 10.1.2.2

Bob has a compute instance with IP address 10.1.9.9 however Bob wants
access to the metadata for Alice's compute instance. If Bob runs a
similar command to Alice, but includes a customer header as below, he
will get access to all of Alice's metadata, including the root password
she chose to store there:
`curl -H "X-Forwarded-For:
10.1.2.2" http://169.254.169.254/latest/meta-data
`

The Nova metadata service is a useful utility within OpenStack but
clearly not intended as a strongly authenticated system for storing
sensitive data such as private keys or passwords.

### Recommended Actions ###
The metadata service should not be used to store sensitive information.

The IP forwarding issue is not a defect of itself, it exists to allow
the metadata service to provide IP addresses for instances that are
behind a proxy as may be the case in more complex deployments.

Cloud users who have a requirement to store sensitive information that
compute instances require for operation should instead look to the
Config drive to provide this service. It's operation is much more
tightly bound to individual compute instances.

Where use of config drive is not an option, operators should consider
other mitigations such as placing a proxy in front of the metadata service
which can filter out these sorts of malicious activities.

### Contacts / References ###
Author: Robert Clark, IBM
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0074
Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1563954

Mailing List : [Security] tag on openstack-...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg

Config Drive
: http://docs.openstack.org/user-guide/cli-config-drive.html




0x3C202614.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [OSSN-0066] (Errata) MongoDB guest instance allows any user to connect

[Luke Hinds]

MongoDB guest instance allows any user to connect
---

### Summary ###
When creating a new MongoDB single instance or cluster the default
setting in MongoDB `security.authorization` was set as disabled. This
resulted in no need to provide user credentials to connect to the mongo
instance and perform read / write operations from any network that is
attached on instance create.

### Affected Services / Software ###
Trove, Liberty

### Discussion ###
MongoDB contains a security config set within `mongo.conf` as follows:

security:
authorization: "enabled"

When creating a new MongoDB instance, or cluster within Trove the
`security` value was not populated resulting in MongoDB adopting the
default value of `disabled`. With security authorization disabled there
would be no enforcement of user authentification, allowing users to
connect and perform read/write data operations from any network that is
attached on instance create.

A fix was implemented within Mitaka and back ported to Liberty that
addresses the problem by enabling authorization by default on single
instances. This can be toggled via configuration groups.

Cluster security is determined by the Trove config variable
`mongodb.cluster_secure`. This cannot be toggled once the cluster is
created.

### Recommended Actions ###
Single instances now use role based access control (RBAC) by default. To
disable RBAC, the Trove user can attach a security group with
`security.authorization` set to `disabled`. It can be re-enabled by
detaching the security group or changing the value to `enabled`.

The Trove config variable `mongodb.cluster_secure`
(boolean type, in `trove.conf`) determines the RBAC state of MongoDB
clusters that are created. Setting this to true enables RBAC while false
disables it. This applies to all MongoDB clusters, and requires a
restart of the trove-api service to change, and cannot be toggled on
running clusters.

Existing mongoDB instances can be secured by using the following changes
to `mongo.conf`

   security:
   authorization: "enabled

### Errata ###
This OSSN previously incorrectly stated that the fix was back ported to
Liberty release. This is not the case and the fix was applied only to
Mitaka.

### Contacts / References ###
Author: Luke Hinds, Red Hat
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0066
Original LaunchPad Bug : https://bugs.launchpad.net/trove/+bug/1507841
Mailing List : [Security] tag on openstack-...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg



0x3C202614.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [OSSN-0076] Glance Image service v1 and v2 api image-create vulnerability

[Luke Hinds]

Glance Image service v1 and v2 api image-create vulnerability
---

### Summary ###
No limits are enforced within the Glance image service for both v1 and
v2 `/images` API POST method for authenticated users, resulting in
possible denial of service attacks through database table saturation.

### Affected Services / Software ###
All versions of Glance image service.

### Discussion ###
Within the Glance image service, calls to the POST method within v1 or
v2/images creates an image (record) in `queued` status. There is no
limit enforced within the Glance API on the number of images a single
tenant may create, just on the total amount of storage a single user may
consume.

Therefore a user could either maliciously or unintentionally fill
multiple database tables (images, image_properties, image_tags,
image_members) with useless image records, thereby causing a denial of
service by lengthening transaction response times in the Glance database.

### Recommended Actions ###
For all versions of Glance that expose either the v1 and v2/images API,
operators are recommended to deploy external rate-limiting proxies or
web application firewalls, to provide a front layer of protection to
glance. The Glance database should be monitored for abnormal growth.
Although rate-limiting does not eliminate this attack vector, it will
slow it to the point where you can react prior to a denial of service
occurring.

The following solutions may be considered, however it is key that the
operator carefully plans and considers the individual performance needs
of users and services within their OpenStack cloud, when configuring any
rate limiting functionality.

 Repose 
Repose provides a rate limiting filter, that can utilise limits by IP,
Role (OpenStack Identity v3 filter) or header.

https://repose.atlassian.net/wiki/display/REPOSE/Rate+Limiting+Filter

 NGINX 
NGINX provides the limit_req_module, which can be used to provide a
global rate
limit. By means of a `map`, it can be limited to just the POST method.

Further details can be found on the nginx site:
http://nginx.org/en/docs/http/ngx_http_limit_req_module.html

 HAProxy 
HAProxy can provide inherent rate-limiting using stick-tables with a General
Purpose Counter (gpc)

Further details can be found on the haproxy website:

http://blog.haproxy.com/2012/02/27/use-a-load-balancer-as-a-first-row-of-defense-against-ddos

 Apache 
A number of solutions can be explored here as follows.

# mod_ratelimit #
http://httpd.apache.org/docs/2.4/mod/mod_ratelimit.html

# mod_qos #
http://opensource.adnovum.ch/mod_qos/dos.html

# mod_evasive #
https://www.digitalocean.com/community/tutorials/how-to-protect-against-dos-and-ddos-with-mod_evasive-for-apache-on-centos-7

# mod_security #
https://www.modsecurity.org/

 Limit `add_image` to admin role 

Another possible mitigation is to restrict image creation to the admin
role, however this should only be done for those cases in which there
are Glance nodes dedicated to end-user access only. Restriction to admin
only on Glance nodes that serve OpenStack services will for example,
remove the ability to create snapshots from the Compute API or to create
bootable volumes from Cinder.

To restrict image creation to the role admin only, amend
`/etc/glance/policy.json` accordingly.

"add_image": "role:admin",

### Contacts / References ###
Author: Luke Hinds, Red Hat
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0076
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1545092
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg




0x3C202614.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [OSSN-0066] MongoDB guest instance allows any user to connect

[Luke Hinds]

MongoDB guest instance allows any user to connect
---

### Summary ###
When creating a new MongoDB single instance or cluster the default
setting in MongoDB `security.authorization` was set as disabled. This
resulted in no need to provide user credentials to connect to the mongo
instance and perform read / write operations from any network that is
attached on instance create.

### Affected Services / Software ###
Trove, Liberty

### Discussion ###
MongoDB contains a security config set within `mongo.conf` as follows:

security:
authorization: "enabled"

When creating a new MongoDB instance, or cluster within Trove the
`security` value was not populated resulting in MongoDB adopting the
default value of `disabled`. With security authorization disabled there
would be no enforcement of user authentification, allowing users to
connect and perform read/write data operations from any network that is
attached on instance create.

A fix was implemented within Mitaka and back ported to Liberty that
addresses the problem by enabling authorization by default on single
instances. This can be toggled via configuration groups.

Cluster security is determined by the Trove config variable
`mongodb.cluster_secure`. This cannot be toggled once the cluster is
created.

### Recommended Actions ###
Single instances now use role based access control (RBAC) by default. To
disable RBAC, the Trove user can attach a security group with
`security.authorization` set to `disabled`. It can be re-enabled by
detaching the security group or changing the value to `enabled`.

The Trove config variable `mongodb.cluster_secure`
(boolean type, in `trove.conf`) determines the RBAC state of MongoDB
clusters that are created. Setting this to true enables RBAC while false
disables it. This applies to all MongoDB clusters, and requires a
restart of the trove-api service to change, and cannot be toggled on
running clusters.

### Contacts / References ###
Author: Luke Hinds, Red Hat
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0066
Original LaunchPad Bug : https://bugs.launchpad.net/trove/+bug/1507841
Mailing List : [Security] tag on openstack-...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg


0x3C202614.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [OSSN-0075] Deleted Glance image IDs may be reassigned

[Luke Hinds]

Deleted Glance image IDs may be reassigned
---

### Summary ###
It is possible for image IDs from deleted images to be reassigned to
other images.  This creates the possibility that:

 - Alice creates a VM that boots from image ID X which has been shared
 with her by a trusted party, Bob.
 - Bob (image X's owner) deletes the image.  As per design, Alice
 receives no notification this happened.
 - Mallory creates a new image and specifies that the ID should be X.
 - Mallory shares image X with Alice.  Again, per design, Alice is not
 notified of this change.
 - Alice boots her VM without realizing that the image has changed.

It's worth noting that in this scenario Mallory needs to know Alice's
project ID to share the new image with Alice.  This isn't enough to
mitigate the issue as project IDs weren't designed to be confidential.

Also, if the environment allows non-administrators to publish images,
Mallory doesn't have to explicitly share with Alice or know her project
ID to perform this attack.

### Affected Services / Software ###
Glance, Liberty, Mitaka, Newton

### Discussion ###
Glance's image table doesn't maintain a list of previously used image
IDs.  Previously assigned image IDs will be listed in the image table
as deleted, but these records may be removed (for performance reasons)
with the `glance-manage db purge` utility or manually by an
administrator.

If these records are removed a malicious user may intentionally upload
a new image using the same ID (Glance allows an image creator to
optionally specify the image ID).  This would cause any victim
instances referencing the ID to use an attacker supplied image.

### Recommended Actions ###
The combination of purged Glance database entries and non-admin image
upload is dangerous.  In environments where normal users are permitted
to upload images, the `images` table should not be purged.  It is
however safe to delete rows from `image_properties`, `image_tags`,
`image_members`, and `image_locations` tables.

### Contacts / References ###
Author: Travis McPeak, IBM
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0075
Original LaunchPad Bug : https://bugs.launchpad.net/glance/+bug/1593799/
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg




0x3C202614.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [OSSN-0073] Horizon dashboard leaks internal information through cookies

[Luke Hinds]

Horizon dashboard leaks internal information through cookies
---

### Summary ###
When horizon is configured, its URL contains the IP address of
the internal URL of keystone, as the default value for the identity
service is "internalURL".[1]

The cookie "login_region" will be set to the value configured as
OPENSTACK_KEYSTONE_URL, given in the local_settings.py file.

Usually, the OPENSTACK_KEYSTONE_URL is the publicURL, and hence the
cookie URL will also be the public one. If set to internal URL (by
default), then the login cookie URL will be the internal URL or IP. So,
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
address.

### Affected Services and Software ###
Horizon

### Discussion ###
This is not a bug in horizon, but a possible misconfiguration issue.

Exposing the internal URL is not a bug, since one can view the internal
URL as it's a freely accessible endpoint to authorized users, or it's
hidden behind a firewall. Also, the data for internal URLs are freely
available in the catalog and the catalog is not considered private
information.

### Contacts / References ###
Author: Khanak Nangia, Intel
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0073
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1585831
Related bug : https://bugs.launchpad.net/horizon/+bug/1597864
OpenStack Security ML : openstack-...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
[1]: http://docs.openstack.org/developer/horizon/topics/settings.html


0x3C202614.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [OSSN-0069] Host machine exposed to tenant networks via IPv6

[Luke Hinds]

Host machine exposed to tenant networks via IPv6
---

### Summary ###

New interfaces created by Neutron in the default namespace, were done so
without disabling IPv6 link-local addresses. This resulted in instances
gaining the ability to directly access the host OS, therefore breaking
guest isolation.

In Linux, link-local IPv6 addresses are assigned to all active
interfaces, unlike IPv4 addresses where an administrator must configure
each interface explicitly. This leads to a time window between when the
interface is enabled and when it is attached to bridge device. Within
this time window the host could be accessed from a tenant network.

IPv6 is now disabled automatically by both Neutron and Nova, prior to
bringing any links up, however operators should still be aware of the
security risks associated with re-enabling IPv6 link-local addresses.

### Affected Services / Software ###

Nova, Neutron, networking-midonet, Kilo, Liberty

### Discussion ###

Linux assigns link-local IPv6 addresses to all the active interfaces,
which is different to that of IPv4 addresses, where an administrator
must configure each interface explicitly. Once an interface is enslaved
in a bridge, all addresses assigned to it are ignored and only the
addresses on the bridge are active. They are exposed via
LinuxBridgeManager calls to `ensure_vlan` and `ensure_vxlan` where a new
VLAN or VXLAN interface is created prior to enslaving the interfaces in
the bridge.

Both Neutron and Nova now disable IPv6 on all interfaces before bringing
the interface up. This avoids exposing a time window between when the
interface is enabled and when it is attached to a bridge device, during
which time the host could be accessible from a tenant network.

### Recommended Actions ###

IPv6 should remain disabled for each interface, before the interface is
brought to link up. If an operator, for any given reason, needs to
re-enable link-local IPv6 adreses, they should be aware of the security
implications of allowing tenant networks access of the host.

IPv6 is now disabled by default using root_dev.disable_ipv6() in
interface.py, which calls the method common.ip_utils.is_enabled()

We can verify the value of the IPv6 parameters within sysctl.conf by
using the following command:

  $ sysctl -a | grep disable | grep ipv6

A value of `0` represents IPv6 enabled, with `1` as disabled.

  net.ipv6.conf.default.disable_ipv6 = 1
  net.ipv6.conf.$IFACE.disable_ipv6 = 1

Here $IFACE refers to the interface for which IPv6 is disabled by
default in Neutron.

Note: The value set at /proc/sys/net/ipv6/conf/$IFACE/disable_ipv6 is
equivalent to net.ipv6.conf.$IFACE.disable_ipv6 in sysctl.conf

### Contacts / References ###

Author: Vinay Potluri, Intel & Luke Hinds, Red Hat
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0069
Original LaunchPad Bug : https://bugs.launchpad.net/ossn/+bug/1534652
This issue was referenced in https://bugs.launchpad.net/Neutron/+bug/1459856
Related issue addressed in Nova: https://review.openstack.org/#/c/313070/
OpenStack Security ML : openstack-...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg


0x3C202614.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

Re: [Openstack] Advice on how to get started

[Luke Hinds]

On Sun, Sep 4, 2016 at 7:44 PM, Turbo Fredriksson  wrote:

> On Sep 4, 2016, at 7:25 PM, Karishma Sharma wrote:
>
> > Is it DevStack that I need to build or something else?
>
> _Personally_ I prefer to learn the hard way. That is, install the
> package(s) and configure them manually.
>
> It takes longer, it require _A LOT_ of patience and is extremely
> frustrating at times, but once you get things working, the reward
> is so much greater!
>
>
+1 - devstack is great for a quick environment on demand, but you can't
beat walking through the official installation guides and building it by
hand.  It will be the difference between have a good foundation of the
component parts of openstack, or seeing thousands of lines whiz past on
your console and then wondering what just happened.


> The core thing to get working is Keystone ("The Authenticator").
> --
> Med ett schysst järnrör slår man hela världen med häpnad
> - Sockerconny
>
>
> ___
> Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
> Post to : openstack@lists.openstack.org
> Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/
> openstack
>
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [OSSN 0070] Bandit versions lower than 1.1.0 do not escape HTML in issue reports

[Luke Hinds]

Bandit versions lower than 1.1.0 do not escape HTML in issue reports
---

### Summary ###

Bandit versions lower than 1.1.0 have a bug in the HTML report formatter
that does not escape HTML in issue context snippets. This could lead to
an XSS if HTML reports are hosted as part of a CI pipeline.

### Affected Services / Software ###

Bandit: < 1.1.0

### Discussion ###

Bandit versions lower than 1.1.0 have a bug in the HTML report formatter
that does not escape HTML in issue context snippets. This could lead to
an XSS attack if HTML reports are hosted as part of a CI pipeline
because HTML in the source code would be copied verbatim into the report.

For example:

  import subprocess
  subprocess.Popen("alert(1)", shell=True)

Will cause "alert(1)" to be inserted into the HTML
report. This issue could allow for arbitrary code injection into CI/CD
pipelines that feature accessible HTML reports generated from Bandit runs.

### Recommended Actions ###

Update bandit to version 1.1.0 or greater.

### Contacts / References ###
Author: Tim Kelsey , HPE
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0070
Original LaunchPad Bug : https://bugs.launchpad.net/bandit/+bug/1612988
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg
CVE: N/A


0x3C202614.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack

[Openstack] [OSSN 0068] Repeated token revocation requests, can lead to service degradation or disruption

[Luke Hinds]

.com/community/tutorials/how-to-protect-against-dos-and-ddos-with-mod_evasive-for-apache-on-centos-7)

# mod_security #####
https://www.modsecurity.org/

### Contacts / References ###
Author: Luke Hinds, Red Hat
This OSSN : https://wiki.openstack.org/wiki/OSSN/OSSN-0068
Original LaunchPad Bug : https://bugs.launchpad.net/nova/+bug/1553324
OpenStack Security ML : openstack-secur...@lists.openstack.org
OpenStack Security Group : https://launchpad.net/~openstack-ossg


0x3C202614.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Mailing list: http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack
Post to : openstack@lists.openstack.org
Unsubscribe : http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack