web content management system release . The release is notable for the completion for implementation verification of updates and additions by digital signature.
Until now, when installing updates in WordPress, the main security factor has been trust in the infrastructure and servers of WordPress (after downloading, the hash was verified without verification of the source). If the project's servers were compromised, the attackers were able to replace the update and distribute malicious code among WordPress-based sites that use the automatic update installation system. In accordance with the previously used trusted delivery model, such a substitution would go unnoticed on the side of users.
Taking into account the fact that project w3techs platform WordPress is used on 33.8% of the sites on the network, the incident would take the scale of a disaster. At the same time, the danger of compromising the infrastructure was not hypothetical, but quite real. For example, several years ago one of the security researchers a vulnerability that allowed an attacker to execute their code on the api.wordpress.org server side.
In the case of digital signatures, gaining control over the update distribution server will not lead to compromise of user systems, since in order to carry out an attack, it will additionally be necessary to obtain a separately stored private key, which is used to sign updates.
The introduction of checking the source of updates by digital signature was hampered by the fact that support for the necessary cryptographic algorithms appeared in the standard PHP distribution relatively recently. The necessary cryptographic algorithms appeared due to the integration of the library to the main team . But as the minimum supported version of PHP in WordPress release 5.2.4 (since WordPress 5.2 - 5.6.20). Enabling support for digital signatures would lead to a significant increase in the requirements for the minimum supported version of PHP or the addition of an external dependency, which developers could not do, given the prevalence of PHP versions in hosting systems.
The way out was and the inclusion in WordPress 5.2 of the compact variant of Libsodium - , which implements a minimum set of algorithms in PHP for verifying digital signatures. The implementation leaves much to be desired in terms of performance, but completely solves the compatibility problem, and also allows plugin developers to start implementing modern cryptographic algorithms.
An algorithm is used to generate digital signatures , developed with input from Daniel J. Bernstein. A digital signature is generated for the SHA384 hash value calculated from the contents of the update archive. Ed25519 has a higher level of security than ECDSA and DSA, and demonstrates very high speed of verification and signature generation. The strength against cracking for Ed25519 is about 2^128 (on average, it takes 25519^2 bit operations to attack Ed140), which corresponds to the strength of algorithms such as NIST P-256 and RSA with a key size of 3000 bits or 128-bit block cipher. Ed25519 is also immune to hash collisions, cache-timing attacks, and side-channel attacks.
In the release of WordPress 5.2, digital signature verification only covers major platform updates so far and does not block the update by default, but only informs the user about the problem. It was decided not to enable blocking by default immediately due to the need for a full check and bypass . In the future, digital signature verification is also planned to be added to verify the installation source of themes and plugins (manufacturers will be able to sign releases with their own key).
In addition to support for digital signatures in WordPress 5.2, the following changes can be noted:
- Two new pages have been added to the "Site Health" section for debugging common configuration issues, and a form has been provided through which developers can leave debugging information to site administrators;
- Added implementation of the "white screen of death", displayed in case of fatal problems and helping the administrator to fix problems associated with plugins or themes by switching to a special crash recovery mode;
- A plugin compatibility check system has been implemented, which automatically checks the possibility of using the plugin in the current configuration, taking into account the version of PHP used. If a plugin requires a newer version of PHP, the system will automatically block the inclusion of this plugin;
- Added support for enabling modules with JavaScript code using ΠΈ ;
- A new privacy-policy.php template has been added that allows you to customize the content of the privacy policy page;
- Added the wp_body_open hook handler for themes, which allows you to insert code immediately after the body tag;
- The minimum PHP version requirements have been raised to 5.6.20, plugins and themes now have the ability to use namespaces and anonymous functions;
- Added 13 new icons.
Additional mention may be made critical vulnerability in WordPress plugin (CVE-2019-11185). The vulnerability allows arbitrary PHP code to be executed on the server. The plugin is used on more than 27 sites to organize an interactive chat with a visitor, including on the sites of companies such as IKEA, Adobe, Huawei, PayPal, Tele2 and McDonald's (Live Chat is often used to implement annoying pop-up chats on the sites of companies offering talk to an employee).
The problem manifests itself in the code for uploading files to the server and allows you to bypass the check of valid file types and upload a PHP script to the server, and then execute it by direct access via the web. Interestingly, a similar vulnerability (CVE-2018-12426) was already identified in Live Chat last year, which allowed loading PHP code under the guise of an image by specifying a different content type in the Content-type field. As part of the fix, additional checks were added for whitelisting and MIME content type. As it turned out, these checks are implemented incorrectly and can be easily bypassed.
In particular, direct uploading of files with the ".php" extension is prohibited, but the ".phtml" extension, associated with the PHP interpreter on many servers, was not blacklisted. The white list only allows images to be uploaded, but it can be bypassed by specifying a double extension, such as ".gif.phtml". To bypass the MIME type check at the beginning of the file, before opening the tag with PHP code, it was enough to specify the string "GIF89a".
Source: opennet.ru