release of the web content management system . The release is notable for completing of implementing update and add-on verification through digital signatures.
Until now, when installing updates in WordPress, the main security factor was trust in the WordPress infrastructure and servers (after downloading, a hash check was performed without source verification). In the event of server compromise, attackers could substitute the update and spread malicious code among WordPress sites using the automatic update system. Under the previously used trust delivery model, such substitution on the user side would go unnoticed.
Considering that according to the w3techs project, the WordPress platform is used on 33.8% of websites on the internet, the incident would have had catastrophic implications. Moreover, the threat of infrastructure compromise was not hypothetical but quite real. For example, several years ago, one security researcher discovered a vulnerability that allowed an attacker to execute their code on the api.wordpress.org server.
In the case of using digital signatures, gaining control over the update distribution server would not compromise user systems, as conducting an attack would additionally require obtaining a separately stored private key used for signing updates.
The implementation of update source verification through digital signatures was hindered by the fact that support for the necessary cryptographic algorithms became available in PHP's standard distribution relatively recently. The required cryptographic algorithms were introduced thanks to the integration of the library into the core of . However, the minimum supported version of PHP declared in WordPress 5.2.4 release (starting from WordPress 5.2 — 5.6.20). Enabling support for digital signatures would have significantly raised the requirements for the minimum supported PHP version or added external dependencies, which developers could not afford given the widespread use of various PHP versions in hosting systems.
The solution was and the inclusion in WordPress 5.2 of a compact version of Libsodium — , which implements a minimal set of algorithms in PHP for verifying digital signatures. The implementation leaves much to be desired in terms of performance but fully addresses compatibility issues and allows plugin developers to begin integrating modern cryptographic algorithms.
The algorithm used for generating digital signatures is , developed with the participation of Daniel J. Bernstein. A digital signature is formed for the SHA384 hash value computed from the contents of the archive being updated. Ed25519 offers a higher level of security than ECDSA and DSA, demonstrating very high verification and signature creation speeds. The resilience to attacks for Ed25519 is around 2^128 (on average, an attack on Ed25519 requires performing 2^140 bit operations), which corresponds to the resilience of algorithms like NIST P-256 and RSA with a key size of 3000 bits or a 128-bit block cipher. Ed25519 is also immune to hash collision issues, is not susceptible to cache-timing attacks, and is resistant to side-channel attacks.
In the release of WordPress 5.2, digital signature verification currently only covers the core platform updates and does not by default block updates but merely informs the user of any issues. The decision was made not to enable blocking by default due to the need for complete verification and circumvention of . In the future, verification via digital signatures is also planned to be added for the installation source verification of themes and plugins (manufacturers will be able to sign releases with their key).
In addition to supporting 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 for site administrators;
- The implementation of the ‘white screen of death’ has been added, which is displayed in the event of fatal issues and helps administrators to fix problems related to plugins or themes by entering a special recovery mode after a crash;
- The compatibility check system with plugins has been implemented, automatically verifying the plugin's usability in the current configuration considering the applied PHP version. If a newer PHP version is required for the plugin to function, the system will automatically prevent the activation of that plugin;
- Support has been added for enabling modules with JavaScript code using and ;
- A new template privacy-policy.php has been added, allowing customization of the content of the privacy compliance page;
- For themes, the wp_body_open hook has been added, allowing code to be inserted immediately after the body tag;
- The minimum PHP version requirement has been raised to 5.6.20, and namespaces and anonymous functions can now be used in plugins and themes;
- 13 new icons have been added.
Additionally, it is worth mentioning a critical vulnerability in the WordPress plugin (CVE-2019-11185). The vulnerability allows arbitrary PHP code to be executed on the server. The plugin is used on over 27 thousand sites to facilitate interactive chat with visitors, including on sites of companies such as IKEA, Adobe, Huawei, PayPal, Tele2, and McDonald’s (Live Chat is often utilized for implementing pop-up chat prompts on company websites offering to connect with staff).
The issue arises in the file upload code on the server and allows bypassing acceptable file type checks to upload a PHP script to the server, which can then be executed directly via the web. Interestingly, a similar vulnerability (CVE-2018-12426) was discovered in Live Chat last year, which allowed uploading PHP code disguised as an image by specifying a different content type in the Content-type field. Additional checks against whitelists and content MIME type were added as part of the issue resolution. However, these checks were implemented incorrectly and can be easily bypassed.
Specifically, direct file uploads with a ‘.php’ extension are prohibited, but the ‘.phtml’ extension was not added to the blacklist, which is associated with the PHP interpreter on many servers. The whitelist only allows for image uploads, but can be bypassed by specifying a double extension, such as ‘.gif.phtml’. To circumvent MIME type checks at the beginning of the file, before opening the PHP code tag, it was sufficient to include the string ‘GIF89a’.
Source: opennet.ru
