Due to a number of vulnerabilities found in the version of Apache we bundle with CFEngine hub, we have upgraded the CFEngine hub packages to use an updated version of Apache. We upgrade from Apache 2.4.39 to Apache 2.4.41. We are now releasing a new version, CFEngine Hub 3.12.2-5. Only new Hub packages are being released, as no other packages are affected by these vulnerabilities.
The issues fixed There are several issues that have been fixed with this new version of Apache. Out of these, only CVE-2019-10098 should affect CFEngine and is the one we were most concerned with. low: mod_rewrite potential open redirect (CVE-2019-10098) Redirects configured with mod_rewrite that were intended to be self-referential might be fooled by encoded newlines and redirect instead to an unexpected URL within the request URL. You can see the full list of issues fixed in Apache 2.4.41 here: https://httpd.apache.org/security/vulnerabilities_24.html This dependency upgrade is the only change we have made. So please upgrade your CFEngine hub today.
Problem to solve When working on the new Federated Reporting feature for CFEngine we had to solve the problem of collecting data from multiple CFEngine hubs (feeders) on a single hub (superhub). CFEngine hubs are using PostgreSQL to store data, so, more specifically, the problem was how to collect data from multiple PostgreSQL databases in one PostgreSQL database. And because we are talking about ~1 GiB of SQL data per feeder hub and for example 10 feeders connected to a superhub here, the initial and trivial solution using basically this ETL (Extract Transform Load) pipeline - pg_dump | gz | ssh | gunzip | psql - provided really poor performance. The problem was in the last part of the pipeline - importing data using psql. Reading and writing 10 GiB of data of course takes a while, but we soon realized that I/O speed was not the bottleneck in this case.
Where we are This is a very exciting time for the CFEngine product team, the community, and the user base. As we are getting closer to the release of CFEngine 3.15 LTS, we can look back at some great improvements in the last few years. CFEngine was the first product to tackle the challenge of managing large scale infrastructure. While there are now many other solutions in the market, CFEngine is still solving the hardest problems. Over the past few weeks, we met with customers and users that are managing infrastructures of 250 000 to around 1 million servers using CFEngine. These teams are just a handful of people, clearly showing how efficient CFEngine can be when it is coupled with a good strategy and has good alignment throughout the organization. CFEngine really thrives at scale! Other areas where we see CFEngine used widely, are several highly regulated or high-risk industries, like banking, finance, automotive, and so forth. We know, and our users know, that CFEngine is a stable, reliable and secure automation platform. This is a core value for us, something we cherish and will make sure stays true in future versions of CFEngine.
Today we are happy to announce the general availability of CFEngine 3.15.0 beta. CFEngine 3.15 is our upcoming LTS (Long Term Support) release. The main focus of this release has been the new Federated Reporting feature. It also contains a lot of performance work and stability improvements. You can download CFEngine 3.15 LTS beta here.
Beta program CFEngine 3.15 is a beta release that is not generally supported, however, the quality is good and interesting new features are available. So, in order for all the new features to be of the best quality, we make it available to you to test already now. We appreciate all the feedback we can get on this beta release. If you test it, you can provide any and all feedback through a quick survey here. We are eagerly awaiting your feedback. You can also email us, or contact us through our webpage.
Recently a security flaw, CVE-2019-1552, has been discovered in OpenSSL. This vulnerability affects the Windows Enterprise agent packages. To mitigate this security vulnerability we have rebuilt CFEngine with the fix to this issue. These packages have been re-released with the version number CFEngine 3.12.2-4. As always, you can download CFEngine Enterprise packages from the download page, Note that only the affected packages have been re-released. CFEngine Community wasn’t affected at all, due to lack of affected feature, Upgrade today, and make your automation even more secure!
Recently I wanted to start measuring the length of time it took for PostgreSQL to acquire a lock so that I could keep an eye on how it changes over time.
My PostgreSQL logs contain entries like the following that record the amount of time in ms it took to acquire a lock.
2019-06-11 18:49:39 GMT LOG: process 10427 acquired AccessShareLock on relation 17949 of database 16384 after 1118.396 ms at character 269 Measurement promises store and track values. Values can be sampled from either a pipe (command output) or a file as defined by the promises stream_type. Values are stored according to the promises history_type. When a measured value is not expected to change frequently a history_type of scalar or static will result in the measurement being sampled less frequently and the single value with compressed statistics will be stored. A history_type of log results in the measured value being logged as an infinite time-series in $(sys.statedir)/<PromiseHandle>_measure.log. A history_type of weekly results in the storing of a two-dimensional time average over a weekly period. Measurements with history_type of weekly are automatically graphed in Mission Portal if they are collected.
On [2019-07-29 Mon] we released new builds of our Enterprise Hub packages for 3.12.2 and 3.14.0. This release addresses CVE-2019-10164.
PostgreSQL versions 10.x before 10.9 and versions 11.x before 11.4 are vulnerable to a stack-based buffer overflow. Any authenticated user can overflow a stack-based buffer by changing the user’s own password to a purpose-crafted value. This often suffices to execute arbitrary code as the PostgreSQL operating system account.
CFEngine Enterprise LTS versions 3.12.0, 3.12.1, 3.12.2-1, 3.12.2-2, and non-LTS version 3.14.0 vendor PostgreSQL versions affected by this vulnerability. In the default configuration as access to root or cfpostgres local users must be achieved first.
Today we are very proud and happy to launch our latest non-supported release, CFEngine 3.14.0. 3.14 is a great number, being the closest we will get to π, we also wanted to introduce something very special this time around, and we did!
New features Let’s start with an overview of some new changes debuting in CFEngine 3.14.
Improved Role Based Access Control (RBAC) In CFEngine 3.14 we have introduced a new backend for managing RBAC settings, as well as a whole new UI in the Mission Portal to manage this. This allows for more granular RBAC settings and makes it simple to set up roles with very limited and specific access. This new Mission Portal & API RBAC is based on existing roles. RBAC is a tricky topic, and we advise to create specific roles when users should have specific access. The permissions are purely additive, i.e. they give permission to access something. Every role has a set of permissions, and in the case where a user has more than one role, she has access to all the permissions of those roles.
This post has been re-published with permission.
CFEngine provides the services promise type to manage the state of a given service. services type promises are an abstraction of agent bundles, they can be used to declare the desired state for a collection of things identified by a name. Most commonly services type promises are used to manage standard operating system services though they can be used for abstracting other logical states. By default, bundle agent standard_services is used for the service_method in promises that specify no specific service_method.
Description The CFEngine engineering team has recently discovered a severe security issue in the CFEngine Enterprise product. CFEngine is using some internal secrets for authentication to the Mission Portal API and the PostgreSQL database when running background maintenance tasks. These internal secrets are randomly generated during the installation process and stored in files which only the root user has access to. Unfortunately, the commands that generate and store the secrets were being logged to the /var/log/CFEngineHub-Install.log installation log which was world-readable and thus accessible for any user logged in to the system (on the hub machine). Please note that this only affects the hub hosts, agent hosts don’t generate and use such internal secrets.
