Apache Log4j 2, une bibliothèque de journalisation basée sur Java et développée par la fondation Apache, est utilisée par de nombreuses applications d’entreprise et services en nuage pour fournir des capacités de journalisation avancées. Selon que vous utilisez actuellement un service géré ou non géré, vous pouvez être vulnérable à cette nouvelle exploitation de type “Zero Day”. Pour les clients qui profitent des avantages d’un service géré, comme nos utilisateurs de VPS géré, d’hébergement dédié géré ou d’hébergement partagé, vous n’avez pas à vous inquiéter, car nos services ont été patchés dès qu’ils ont été disponibles. Pour tous ceux qui gèrent eux-mêmes leurs services, c’est le moment de faire une mise à jour si ce n’est déjà fait.

Le 24 novembre 2021, l’équipe de sécurité d’Alibaba Cloud a signalé à Apache une vulnérabilité d’exécution de code à distance de Log4j 2. L’exploit tire parti de certaines fonctions de Log4j qui effectuent une analyse récursive. Ce qui, avec des requêtes malveillantes spécialement construites, permet aux attaquants de déclencher l’exécution de code à distance.

La vulnérabilité a un impact sur les configurations par défaut de plusieurs frameworks Apache, notamment :

• Druide Apache
• Apache Flink
• Apache Solr
• Apache Struts2

Dans les versions d’Apache Log4j2 jusqu’à la version 2.14.1 incluse (à l’exclusion des versions de sécurité 2.3.1, 2.12.2 et 2.12.3), les fonctionnalités JNDI utilisées dans les configurations, les messages de journal et les paramètres ne protègent pas contre les points d’extrémité LDAP et autres points d’extrémité liés à JNDI contrôlés par des attaquants. Un attaquant qui peut contrôler les messages de journal ou les paramètres des messages de journal peut exécuter du code arbitraire chargé à partir de serveurs LDAP lorsque la substitution de recherche de message est activée. ^{Source :}

Le 10 décembre 2021, cette vulnérabilité a été officiellement désignée dans la base de données nationale des vulnérabilités du NIST comme CVE-2021-44228 (également connue sous le nom de vulnérabilité “Log4Shell”). Ce phénomène s’est ensuite étendu à plusieurs autres vulnérabilités découvertes, puis corrigées, répertoriées sous les noms de CVE-2021-45046 et CVE-2021-45105.

Il a été constaté que la correction de la CVE-2021-44228 dans Apache Log4j 2.15.0 était incomplète dans certaines configurations autres que celles par défaut. Lorsque la configuration de l’enregistrement utilise une disposition de modèle non par défaut avec une recherche de contexte (par exemple, $$${ctx:loginId}), les attaquants ayant le contrôle des données d’entrée de Thread Context Map (MDC) peuvent créer des données d’entrée malveillantes à l’aide d’un motif JNDI Lookup, ce qui entraîne une fuite d’informations et l’exécution de code à distance dans certains environnements et l’exécution de code local dans tous les environnements ; l’exécution de code à distance a été démontrée sur macOS mais aucun autre environnement testé.

CVE-2021-45046

Les versions 2.0-alpha1 à 2.16.0 d’Apache Log4j2, à l’exception de la 2.12.3, n’offraient pas de protection contre les récursions incontrôlées provenant de recherches autoréférentielles. Lorsque la configuration de la journalisation utilise une disposition de motif non par défaut avec une recherche de contexte (par exemple, $${ctx:loginId}), les attaquants qui contrôlent les données d’entrée de la carte de contexte de thread (MDC) peuvent créer des données d’entrée malveillantes contenant une recherche récursive, ce qui entraîne une erreur de type StackOverflowError qui met fin au processus. Cette attaque est également connue sous le nom de DOS (Denial of Service).

CVE-2021-45105

Comment la vulnérabilité vous affecte-t-elle ?

Selon le type de compte d’hébergement que vous avez avec The Core Hosting, vous pouvez ou non avoir à prendre des mesures :

Comptes WordPress partagés, revendeurs et gérés

Si vous avez un compte d’hébergement WordPress partagé, revendeur ou géré, vous n’avez rien à faire. Ces serveurs reçoivent automatiquement des mises à jour fréquentes qui incluent des correctifs pour la vulnérabilité de Log4j 2.

cPanel a publié une mise à jour pour atténuer la CVE-2021-44228 le jour même où la vulnérabilité a été annoncée. Pour plus d’informations, consultez l’article du blog de cPanel.

Managed VPS et dédiés

Si vous disposez d’un serveur dédié géré ou d’un serveur VPS géré, vous n’avez probablement pas besoin de prendre de mesures – votre serveur est mis à jour automatiquement avec des correctifs pour la vulnérabilité Log4j 2. La seule exception est que si vous avez installé un logiciel utilisant log4j en dehors de cPanel/WHM, vous devez vous assurer que ces installations sont mises à jour. Tous les logiciels installés et gérés par The Core Hosting ont déjà été mis à jour.

cPanel a publié une mise à jour pour atténuer la CVE-2021-44228 (et les correctifs ultérieurs) le jour même de l’annonce de la vulnérabilité. Pour plus d’informations, consultez l’article du blog de cPanel.

VPS et serveurs dédiés non gérés

Si vous disposez d’un serveur VPS non géré ou d’un serveur dédié non géré, veillez à le maintenir à jour avec les derniers correctifs de sécurité. Si vous avez besoin d’aide à ce sujet, notre incroyable équipe d’assistance est prête à vous aider ! Nous savons que ce type d’exploit peut être dangereux et parfois difficile à corriger. Alors, laissez-nous vous aider.

Si vous utilisez Log4j 2, il est très important de vous assurer que vous avez mis à jour la version la plus récente. Le premier patch incluait une autre vulnérabilité qui nécessitait un second patch.

Les utilisateurs de Java 8 (ou d’une version ultérieure) doivent effectuer une mise à niveau vers la version 2.17.0 ou supérieure.

Les utilisateurs de Java 7 doivent passer à la version 2.12.3 ou supérieure.

Les utilisateurs de Java 6 doivent passer à la version 2.3.1 ou supérieure.

Vous trouverez de plus amples informations sur le site Apache.

Pour plus d’informations sur la façon d’installer des mises à jour sur des serveurs non gérés, veuillez consulter cet article de la base de connaissances.

La ligne de fond

Heartbleed, Shellshock; la vulnérabilité de Log4j n’est que la dernière d’une longue série de bogues de sécurité. Ce n’est pas le premier, et ce ne sera sûrement pas le dernier.

Si vous avez un compte d’hébergement géré, vous pouvez être sûr que nous nous occupons de la configuration et des mises à jour du serveur pour vous. Si vous disposez d’un serveur non géré, nous vous recommandons vivement de mettre votre équipe à niveau dès que possible, ou de contacter notre service d’assistance pour obtenir de l’aide concernant cet exploit de type “Zero Day”.

Quelles sont les améliorations et les fonctionnalités de PHP 8

Exécution de code plus rapide

La dernière version de PHP apporte beaucoup de nouveautés, mais celle qui nous obsède est JIT (compilateur juste à temps). C’est la première fois que la version PHP a un compilateur – JIT – qui met en cache une version de votre code déjà interprété et génère un code machine en sortie (le code machine est activé avec des 0 et des 1 uniquement). Le compilateur « juste à temps » promet des améliorations de vitesse pour les tâches et les algorithmes complexes et ouvre de nouvelles opportunités pour le langage PHP d’élargir sa portée et ses applications.

Certains d’entre vous se demandent peut-être comment JIT se rapporte à l’Opcache, qui a apporté des gains de performance significatifs à de nombreux sites Web? Le travail principal de l’Opcache est de couper les processus de tokenisation, d’analyse et de compilation des Opcodes, qui sont ensuite traités par le moteur Zend. Le rôle du JIT est d’économiser sur l’exécution des Opcodes par le moteur Zend, il unit donc ses forces et intervient pour économiser des ressources là où l’Opcache ne peut pas aider.

Il convient de mentionner quelques inconvénients que nous avons remarqués jusqu’à présent:

• L’exécution de PHP 8 avec JIT peut rendre plus difficile pour vous de résoudre les erreurs de code car il peut être plus difficile de localiser quelle partie de votre code dans cette version interprétée est réellement en faute.
• Si vous utilisez un site WordPress, vous ne pourrez peut-être pas noter d’améliorations significatives des performances grâce à JIT. Les développeurs de WP travaillent toujours à rendre WP compatible avec PHP 8 et font maintenant appel à des testeurs, ce qui signifie que vous ne pourrez pas vraiment tester PHP8 sur votre site WP tout de suite. De plus, en raison de la façon dont WP interagit avec MySQL, une grande partie du temps d’attente ne provient pas de la compilation PHP, mais du temps de réponse MySQL, qui ne peut pas être résolu avec l’aide du compilateur JIT.

Code de meilleure qualité

L’une des principales différences que vous remarquerez est que bon nombre des avertissements et des avis qui n’étaient pas interceptables sont maintenant des exceptions ou des erreurs, qui peuvent être détectées et enregistrées. Il est possible qu’en raison de ce changement, de nombreux problèmes qui sont restés cachés avec les versions précédentes de PHP fassent maintenant surface. C’est une grande amélioration, car cela permettra aux développeurs de repérer plus facilement les problèmes potentiels. Cependant, gardez à l’esprit que cela peut être une bonne idée de définir display_errors=Off si vous décidez d’utiliser PHP 8 sur un site en direct pour ne pas montrer de telles erreurs aux visiteurs de votre site.

Code plus propre et plus court

Certains des nouveaux éléments, tels que l’opérateur nullsafe, améliorent considérablement la lisibilité du code, le rendant plus court et plus net. Au lieu d’imbriquer plusieurs « if », vous pouvez utiliser l’opérateur « null » pour écrire tous ceux-ci dans seulement 1 ligne de code.

La tendance « type »

Depuis plusieurs versions maintenant, PHP a essayé de définir les arguments que chaque méthode pourrait adapter et devenir plus un langage typé. Dans cette dernière version, il existe une fonctionnalité appelée « types d’union » qui vous permet de définir 2 types de valeur pour chaque fonction, ce qui est une continuation naturelle de cette tendance. Comme le montre l’exemple ci-dessous, la fonction peut renvoyer un entier ou un float :

fonction publique getNumber(): int|float {
retour $this-numéro>;
}

La liste des nouvelles fonctionnalités continue et nous suggérons cet article comme un bon point de référence pour les développeurs PHP:

https://stitcher.io/blog/new-in-php-8
https://stitcher.io/blog/php-jit
https://wiki.php.net/rfc/nullsafe_operator

Comment profiter de PHP 8 sur notre plateforme ?

Tous nos clients peuvent modifier la version PHP de leurs sites à partir de leur panneau de contrôle – Pour les clients WordPress gérés, accédez à votre panneau de configuration, sélectionnez Paramètres PHP, puis modifiez la version – Pour l’hébergement partagé, le panneau de configuration cPanel –> Gestionnaire MultiPHP pour changer votre version PHP. PHP8 étant toujours un Release Candidate, nous vous conseillons fortement de ne pas l’activer pour vos sites en direct, mais d’exécuter des tests avec lui sur notre environnement de préparation (les environnements de préparation peuvent être créés sur n’importe quel plan, si vous rencontrez des difficultés pour le faire, n’hésitez pas à contacter notre équipe de support pour obtenir des informations sur la façon de procéder.), ou créez des copies de vos sites dans vos comptes si vous ne disposez pas de la fonctionnalité de mise en scène.

Actuellement indisponible en PHP 8

Les extensions et modules suivants ne sont actuellement pas disponibles pour PHP 8 :

• PHP-PSR
• Snuffleupagus
• Phalcon 4
• ionCube 10
• Memcache
• SourceGuardian

Incompatible avec PHP 8

Le logiciel suivant ne fonctionne actuellement pas avec PHP 8. Cette liste n’est pas exhaustive.

• DSO — cPanel & WHM ne prend pas en charge le gestionnaire DSO avec PHP 8.
• Les extensions XMLRPC — Cette extension a été déplacée vers PECL.
• L’extension JSON — Cette fonctionnalité est incluse dans PHP 8 par défaut.

Commencez à apprendre PHP

Commencez à apprendre PHP dans ces endroits exceptionnels:

• https://jobtensor.com/Tutorial/PHP/en/Introduction

Dites-nous ce que vous en pensez

Nous avons essayé de vous donner une vue d’ensemble de ce qu’est le nouveau PHP 8. Maintenant, nous aimerions savoir ce que vous en pensez réellement, une fois que vous aurez eu la chance de l’essayer. Qu’aimez-vous et qu’est-ce que vous n’aimez pas? Comment cela fonctionne-t-il sur votre site Web? Constatez-vous des améliorations de performances ? Nous cherchons à explorer comment nos utilisateurs plus expérimentés tirent parti de cette version préliminaire candidate avant qu’elle ne devienne officielle.