Merge branch 'stable-2.14' into stable-2.15
authorHrvoje Ribicic <riba@google.com>
Wed, 16 Dec 2015 11:09:38 +0000 (12:09 +0100)
committerHrvoje Ribicic <riba@google.com>
Wed, 16 Dec 2015 11:17:52 +0000 (12:17 +0100)
* stable-2.14
  Revision bump for 2.14.2
  Update NEWS file for 2.14.2

* stable-2.13
  Revision bump for 2.13.3
  Update NEWS file for 2.13.3

* stable-2.12
  Bump revision number for 2.12.6
  Update NEWS file for 2.12.6

* stable-2.11
  Revision bump for 2.11.8
  Update NEWS file for 2.11.8

* stable-2.10
  Version bump for 2.10.8
  Update NEWS file for 2.10.8

* stable-2.9
  Bump revision number
  Update NEWS file for 2.9.7 release
  Improve RAPI section on security

Conflicts:
  NEWS - Merge entries
  configure.ac - Take 2.15 revision numbers

Signed-off-by: Hrvoje Ribicic <riba@google.com>
Reviewed-by: Klaus Aehlig <aehlig@google.com>

NEWS
doc/security.rst

diff --git a/NEWS b/NEWS
index d6e1820..348d513 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -81,6 +81,87 @@ This was the second beta release in the 2.15 series. All important changes
 are listed in the latest 2.15 entry.
 
 
+Version 2.14.2
+--------------
+
+*(Released Tue, 15 Dec 2015)*
+
+Important changes and security notes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Security release.
+
+CVE-2015-7944
+
+Ganeti provides a RESTful control interface called the RAPI. Its HTTPS
+implementation is vulnerable to DoS attacks via client-initiated SSL
+parameter renegotiation. While the interface is not meant to be exposed
+publicly, due to the fact that it binds to all interfaces, we believe
+some users might be exposing it unintentionally and are vulnerable. A
+DoS attack can consume resources meant for Ganeti daemons and instances
+running on the master node, making both perform badly.
+
+Fixes are not feasible due to the OpenSSL Python library not exposing
+functionality needed to disable client-side renegotiation. Instead, we
+offer instructions on how to control RAPI's exposure, along with info
+on how RAPI can be setup alongside an HTTPS proxy in case users still
+want or need to expose the RAPI interface. The instructions are
+outlined in Ganeti's security document: doc/html/security.html
+
+CVE-2015-7945
+
+Ganeti leaks the DRBD secret through the RAPI interface. Examining job
+results after an instance information job reveals the secret. With the
+DRBD secret, access to the local cluster network, and ARP poisoning,
+an attacker can impersonate a Ganeti node and clone the disks of a
+DRBD-based instance. While an attacker with access to the cluster
+network is already capable of accessing any data written as DRBD
+traffic is unencrypted, having the secret expedites the process and
+allows access to the entire disk.
+
+Fixes contained in this release prevent the secret from being exposed
+via the RAPI. The DRBD secret can be changed by converting an instance
+to plain and back to DRBD, generating a new secret, but redundancy will
+be lost until the process completes.
+Since attackers with node access are capable of accessing some and
+potentially all data even without the secret, we do not recommend that
+the secret be changed for existing instances.
+
+Minor changes
+~~~~~~~~~~~~~
+
+- Allow disk attachment to diskless instances
+- Calculate correct affected nodes set in InstanceChangeGroup
+  (Issue 1144)
+- Do not retry all requests after connection timeouts to prevent
+  repeated job submission
+- Fix reason trails of expanding opcodes
+- Make lockConfig call retryable
+- Extend timeout for gnt-cluster renew-crypto
+- Return the correct error code in the post-upgrade script
+- Make OpenSSL refrain from DH altogether
+- Fix faulty iallocator type check
+- Improve cfgupgrade output in case of errors
+- Fix upgrades of instances with missing creation time
+- Make htools tolerate missing "dtotal" and "dfree" on luxi
+- Fix default for --default-iallocator-params
+- Renew-crypto: stop daemons on master node first
+- Don't warn about broken SSH setup of offline nodes (Issue 1131)
+- At IAlloc backend guess state from admin state
+- Set node tags in iallocator htools backend
+- Only search for Python-2 interpreters
+- Handle Xen 4.3 states better
+- Improve xl socat migrations
+- replace-disks: fix --ignore-ipolicy
+- Fix disabling of user shutdown reporting
+- Allow userspace-only disk templates
+- Fix instance failover in case of DTS_EXT_MIRROR
+- Fix operations on empty nodes by accepting allocation of 0 jobs
+- Fix instance multi allocation for non-DRBD disks
+- Redistribute master key on downgrade
+- Allow more failover options when using the --no-disk-moves flag
+
+
 Version 2.14.1
 --------------
 
@@ -229,6 +310,81 @@ This was the first beta release of the 2.14 series. All important changes
 are listed in the latest 2.14 entry.
 
 
+Version 2.13.3
+--------------
+
+*(Released Mon, 14 Dec 2015)*
+
+Important changes and security notes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Security release.
+
+CVE-2015-7944
+
+Ganeti provides a RESTful control interface called the RAPI. Its HTTPS
+implementation is vulnerable to DoS attacks via client-initiated SSL
+parameter renegotiation. While the interface is not meant to be exposed
+publicly, due to the fact that it binds to all interfaces, we believe
+some users might be exposing it unintentionally and are vulnerable. A
+DoS attack can consume resources meant for Ganeti daemons and instances
+running on the master node, making both perform badly.
+
+Fixes are not feasible due to the OpenSSL Python library not exposing
+functionality needed to disable client-side renegotiation. Instead, we
+offer instructions on how to control RAPI's exposure, along with info
+on how RAPI can be setup alongside an HTTPS proxy in case users still
+want or need to expose the RAPI interface. The instructions are
+outlined in Ganeti's security document: doc/html/security.html
+
+CVE-2015-7945
+
+Ganeti leaks the DRBD secret through the RAPI interface. Examining job
+results after an instance information job reveals the secret. With the
+DRBD secret, access to the local cluster network, and ARP poisoning,
+an attacker can impersonate a Ganeti node and clone the disks of a
+DRBD-based instance. While an attacker with access to the cluster
+network is already capable of accessing any data written as DRBD
+traffic is unencrypted, having the secret expedites the process and
+allows access to the entire disk.
+
+Fixes contained in this release prevent the secret from being exposed
+via the RAPI. The DRBD secret can be changed by converting an instance
+to plain and back to DRBD, generating a new secret, but redundancy will
+be lost until the process completes.
+Since attackers with node access are capable of accessing some and
+potentially all data even without the secret, we do not recommend that
+the secret be changed for existing instances.
+
+Minor changes
+~~~~~~~~~~~~~
+
+- Calculate correct affected nodes set in InstanceChangeGroup
+  (Issue 1144)
+- Do not retry all requests after connection timeouts to prevent
+  repeated job submission
+- Fix reason trails of expanding opcodes
+- Make lockConfig call retryable
+- Extend timeout for gnt-cluster renew-crypto
+- Return the correct error code in the post-upgrade script
+- Make OpenSSL refrain from DH altogether
+- Fix upgrades of instances with missing creation time
+- Make htools tolerate missing "dtotal" and "dfree" on luxi
+- Fix default for --default-iallocator-params
+- Renew-crypto: stop daemons on master node first
+- Don't warn about broken SSH setup of offline nodes (Issue 1131)
+- At IAlloc backend guess state from admin state
+- Only search for Python-2 interpreters
+- Handle Xen 4.3 states better
+- Improve xl socat migrations
+- replace-disks: fix --ignore-ipolicy
+- Fix disabling of user shutdown reporting
+- Fix operations on empty nodes by accepting allocation of 0 jobs
+- Fix instance multi allocation for non-DRBD disks
+- Redistribute master key on downgrade
+- Allow more failover options when using the --no-disk-moves flag
+
+
 Version 2.13.2
 --------------
 
@@ -401,6 +557,76 @@ This was the first beta release of the 2.13 series. All important changes
 are listed in the latest 2.13 entry.
 
 
+Version 2.12.6
+--------------
+
+*(Released Mon, 14 Dec 2015)*
+
+Important changes and security notes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Security release.
+
+CVE-2015-7944
+
+Ganeti provides a RESTful control interface called the RAPI. Its HTTPS
+implementation is vulnerable to DoS attacks via client-initiated SSL
+parameter renegotiation. While the interface is not meant to be exposed
+publicly, due to the fact that it binds to all interfaces, we believe
+some users might be exposing it unintentionally and are vulnerable. A
+DoS attack can consume resources meant for Ganeti daemons and instances
+running on the master node, making both perform badly.
+
+Fixes are not feasible due to the OpenSSL Python library not exposing
+functionality needed to disable client-side renegotiation. Instead, we
+offer instructions on how to control RAPI's exposure, along with info
+on how RAPI can be setup alongside an HTTPS proxy in case users still
+want or need to expose the RAPI interface. The instructions are
+outlined in Ganeti's security document: doc/html/security.html
+
+CVE-2015-7945
+
+Ganeti leaks the DRBD secret through the RAPI interface. Examining job
+results after an instance information job reveals the secret. With the
+DRBD secret, access to the local cluster network, and ARP poisoning,
+an attacker can impersonate a Ganeti node and clone the disks of a
+DRBD-based instance. While an attacker with access to the cluster
+network is already capable of accessing any data written as DRBD
+traffic is unencrypted, having the secret expedites the process and
+allows access to the entire disk.
+
+Fixes contained in this release prevent the secret from being exposed
+via the RAPI. The DRBD secret can be changed by converting an instance
+to plain and back to DRBD, generating a new secret, but redundancy will
+be lost until the process completes.
+Since attackers with node access are capable of accessing some and
+potentially all data even without the secret, we do not recommend that
+the secret be changed for existing instances.
+
+Minor changes
+~~~~~~~~~~~~~
+
+- Calculate correct affected nodes set in InstanceChangeGroup
+  (Issue 1144)
+- Do not retry all requests after connection timeouts to prevent
+  repeated job submission
+- Fix reason trails of expanding opcodes
+- Make lockConfig call retryable
+- Return the correct error code in the post-upgrade script
+- Make OpenSSL refrain from DH altogether
+- Fix upgrades of instances with missing creation time
+- Make htools tolerate missing "dtotal" and "dfree" on luxi
+- Fix default for --default-iallocator-params
+- At IAlloc backend guess state from admin state
+- Only search for Python-2 interpreters
+- Handle Xen 4.3 states better
+- replace-disks: fix --ignore-ipolicy
+- Fix disabling of user shutdown reporting
+- Fix operations on empty nodes by accepting allocation of 0 jobs
+- Fix instance multi allocation for non-DRBD disks
+- Allow more failover options when using the --no-disk-moves flag
+
+
 Version 2.12.5
 --------------
 
@@ -759,6 +985,66 @@ This was the first beta release of the 2.12 series. All important changes
 are listed in the latest 2.12 entry.
 
 
+Version 2.11.8
+--------------
+
+*(Released Mon, 14 Dec 2015)*
+
+Important changes and security notes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Security release.
+
+CVE-2015-7944
+
+Ganeti provides a RESTful control interface called the RAPI. Its HTTPS
+implementation is vulnerable to DoS attacks via client-initiated SSL
+parameter renegotiation. While the interface is not meant to be exposed
+publicly, due to the fact that it binds to all interfaces, we believe
+some users might be exposing it unintentionally and are vulnerable. A
+DoS attack can consume resources meant for Ganeti daemons and instances
+running on the master node, making both perform badly.
+
+Fixes are not feasible due to the OpenSSL Python library not exposing
+functionality needed to disable client-side renegotiation. Instead, we
+offer instructions on how to control RAPI's exposure, along with info
+on how RAPI can be setup alongside an HTTPS proxy in case users still
+want or need to expose the RAPI interface. The instructions are
+outlined in Ganeti's security document: doc/html/security.html
+
+CVE-2015-7945
+
+Ganeti leaks the DRBD secret through the RAPI interface. Examining job
+results after an instance information job reveals the secret. With the
+DRBD secret, access to the local cluster network, and ARP poisoning,
+an attacker can impersonate a Ganeti node and clone the disks of a
+DRBD-based instance. While an attacker with access to the cluster
+network is already capable of accessing any data written as DRBD
+traffic is unencrypted, having the secret expedites the process and
+allows access to the entire disk.
+
+Fixes contained in this release prevent the secret from being exposed
+via the RAPI. The DRBD secret can be changed by converting an instance
+to plain and back to DRBD, generating a new secret, but redundancy will
+be lost until the process completes.
+Since attackers with node access are capable of accessing some and
+potentially all data even without the secret, we do not recommend that
+the secret be changed for existing instances.
+
+Minor changes
+~~~~~~~~~~~~~
+
+- Make htools tolerate missing "dtotal" and "dfree" on luxi
+- Fix default for --default-iallocator-params
+- At IAlloc backend guess state from admin state
+- replace-disks: fix --ignore-ipolicy
+- Fix instance multi allocation for non-DRBD disks
+- Trigger renew-crypto on downgrade to 2.11
+- Downgrade log-message for rereading job
+- Downgrade log-level for successful requests
+- Check for gnt-cluster before running gnt-cluster upgrade
+
+
 Version 2.11.7
 --------------
 
@@ -1117,6 +1403,83 @@ This was the first beta release of the 2.11 series. All important changes
 are listed in the latest 2.11 entry.
 
 
+Version 2.10.8
+--------------
+
+*(Released Fri, 11 Dec 2015)*
+
+Important changes and security notes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Security release.
+
+CVE-2015-7944
+
+Ganeti provides a RESTful control interface called the RAPI. Its HTTPS
+implementation is vulnerable to DoS attacks via client-initiated SSL
+parameter renegotiation. While the interface is not meant to be exposed
+publicly, due to the fact that it binds to all interfaces, we believe
+some users might be exposing it unintentionally and are vulnerable. A
+DoS attack can consume resources meant for Ganeti daemons and instances
+running on the master node, making both perform badly.
+
+Fixes are not feasible due to the OpenSSL Python library not exposing
+functionality needed to disable client-side renegotiation. Instead, we
+offer instructions on how to control RAPI's exposure, along with info
+on how RAPI can be setup alongside an HTTPS proxy in case users still
+want or need to expose the RAPI interface. The instructions are
+outlined in Ganeti's security document: doc/html/security.html
+
+CVE-2015-7945
+
+Ganeti leaks the DRBD secret through the RAPI interface. Examining job
+results after an instance information job reveals the secret. With the
+DRBD secret, access to the local cluster network, and ARP poisoning,
+an attacker can impersonate a Ganeti node and clone the disks of a
+DRBD-based instance. While an attacker with access to the cluster
+network is already capable of accessing any data written as DRBD
+traffic is unencrypted, having the secret expedites the process and
+allows access to the entire disk.
+
+Fixes contained in this release prevent the secret from being exposed
+via the RAPI. The DRBD secret can be changed by converting an instance
+to plain and back to DRBD, generating a new secret, but redundancy will
+be lost until the process completes.
+Since attackers with node access are capable of accessing some and
+potentially all data even without the secret, we do not recommend that
+the secret be changed for existing instances.
+
+Minor changes
+~~~~~~~~~~~~~
+
+- Make htools tolerate missing "dtotal" and "dfree" on luxi
+- At IAlloc backend guess state from admin state
+- replace-disks: fix --ignore-ipolicy
+- Fix instance multi allocation for non-DRBD disks
+- Check for gnt-cluster before running gnt-cluster upgrade
+- Work around a Python os.minor bug
+- Add IP-related checks after master-failover
+- Pass correct backend params in move-instance
+- Allow plain/DRBD conversions regardless of lack of disks
+- Fix MonD collector thunk leak
+- Stop MonD when removing a node from a cluster
+- Finalize backup only if successful
+- Fix file descriptor leak in Confd Client
+- Auto-upgrade hv_state_static and disk_state_static
+- Do not hardcode the Python path in CLI tools
+- Use the Python interpreter from ENV
+- ganeti.daemon: fix daemon mode with GnuTLS >= 3.3 (Issues 961, 964)
+- Ganeti.Daemon: always install SIGHUP handler (Issue 755)
+- Fix DRBD version check for non VM capable nodes
+- Fix handling of the --online option
+- Add warning against hvparam changes with live migrations
+- Only verify LVs in configured VG during cluster verify
+- Fix network info in case of multi NIC instances
+- On upgrades, check for upgrades to resume first
+- Pause watcher during upgrade
+- Allow instance disks to be added with --no-wait-for-sync
+
+
 Version 2.10.7
 --------------
 
@@ -1465,6 +1828,67 @@ before rc1.
 - Issue 623: IPv6 Masterd <-> Luxid communication error
 
 
+Version 2.9.7
+-------------
+
+*(Released Fri, 11 Dec 2015)*
+
+Important changes and security notes
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Security release.
+
+CVE-2015-7944
+
+Ganeti provides a RESTful control interface called the RAPI. Its HTTPS
+implementation is vulnerable to DoS attacks via client-initiated SSL
+parameter renegotiation. While the interface is not meant to be exposed
+publicly, due to the fact that it binds to all interfaces, we believe
+some users might be exposing it unintentionally and are vulnerable. A
+DoS attack can consume resources meant for Ganeti daemons and instances
+running on the master node, making both perform badly.
+
+Fixes are not feasible due to the OpenSSL Python library not exposing
+functionality needed to disable client-side renegotiation. Instead, we
+offer instructions on how to control RAPI's exposure, along with info
+on how RAPI can be setup alongside an HTTPS proxy in case users still
+want or need to expose the RAPI interface. The instructions are
+outlined in Ganeti's security document: doc/html/security.html
+
+CVE-2015-7945
+
+Ganeti leaks the DRBD secret through the RAPI interface. Examining job
+results after an instance information job reveals the secret. With the
+DRBD secret, access to the local cluster network, and ARP poisoning,
+an attacker can impersonate a Ganeti node and clone the disks of a
+DRBD-based instance. While an attacker with access to the cluster
+network is already capable of accessing any data written as DRBD
+traffic is unencrypted, having the secret expedites the process and
+allows access to the entire disk.
+
+Fixes contained in this release prevent the secret from being exposed
+via the RAPI. The DRBD secret can be changed by converting an instance
+to plain and back to DRBD, generating a new secret, but redundancy will
+be lost until the process completes.
+Since attackers with node access are capable of accessing some and
+potentially all data even without the secret, we do not recommend that
+the secret be changed for existing instances.
+
+Minor changes
+~~~~~~~~~~~~~
+
+- gnt-instance replace-disks no longer crashes when --ignore-policy is
+  passed to it
+- Stop MonD when removing a node from a cluster
+- Fix file descriptor leak in Confd client
+- Always install SIGHUP handler for Haskell daemons (Issue 755)
+- Make ganeti-cleaner switch to a safe working directory (Issue 880)
+- Make htools tolerate missing "spfree" on Luxi
+- DRBD parser: consume initial empty resource lines (Issue 869)
+- KVM: set IFF_ONE_QUEUE on created tap interfaces
+- Set exclusion tags correctly in requested instance
+
+
 Version 2.9.6
 -------------
 
index ab8eea1..7521bab 100644 (file)
@@ -185,6 +185,44 @@ Paths for certificate, private key and CA files required for SSL/TLS
 will be set at source configure time. Symlinks or command line
 parameters may be used to use different files.
 
+The RAPI binds to all interfaces by default, and allows read-only
+requests without the need for authentication. In the case that one of
+the interfaces RAPI binds to is publicly exposed, this will allow
+anyone in the world to read the state of the cluster, divulging
+potentially useful data such as the names of instances, their IP
+addresses, etc. Since the RAPI daemon resides on the master node as
+well, DoS attacks can result in Ganeti outages or issues with instances
+located on the master node.
+
+We recommend that you reduce the attack surface by either placing RAPI
+in an environment where you can control access to it, or should you
+need to expose it publicly, use various RAPI daemon options to lock
+functionality down to only what you need. RAPI daemon options are best
+added to ``/etc/default/ganeti``, the ``RAPI_ARGS`` variable. Some
+examples of situations where you might want to expose the RAPI are
+cross-cluster instance moves, which can be done only via the RAPI.
+
+If you do not use RAPI at all, we recommend that you lock it down by
+binding it to the loopback interface. This can be done by passing the
+``-b 127.0.0.1`` parameter to the RAPI daemon. Preventing the RAPI
+from starting or making it unreachable on the master node is not
+recommended, as the watcher performs health checks and will attempt to
+restart the daemon repeatedly.
+
+If you intend to use the RAPI and to expose it to the public, make sure
+to use the ``--require-authentication`` flag, disabling anonymous HTTP
+requests.
+
+Ganeti currently cannot protect users adequately from DoS attacks based
+on client-side HTTPS parameter renegotiation due to the Python OpenSSL
+library lacking necessary features. To protect yourself from these, the
+use of a HTTPS proxy handling this correctly is needed (e.g. nginx).
+Useful options for setting RAPI up for cooperation with the proxy are:
+
+- ``-p PORT`` for allowing the default RAPI port to be used by the
+  proxy
+- ``--no-ssl`` to disable SSL as it will be handled by the proxy anyway
+
 Inter-cluster instance moves
 ----------------------------