ADVISORY : La méthode OPTIONS peut divulguer la mémoire du serveur Apache

Actuellement, les vulnérabilités sont de sortie: la semaine dernière, nous communiquions à propos d’une exécution de commande à distance (RCE) découverte dans Apache Struts 2, et maintenant, une divulgation d’informations a été découverte dans le serveur HTTP Apache. En envoyant des requêtes http utilisant la méthode « OPTIONS », le serveur peut répondre avec un en-tête « Allow » contenant des blocs arbitraires de mémoire. Cette fuite de mémoire ne peut être déclenchée que lorsque le serveur Apache utilise un ensemble de règle d’accès via la directive « <Limit> » dans des fichiers « .htaccess » ainsi qu’une directive « AllowOverride Limit » dans le fichier principal de configuration « httpd.conf ».

Détails de la vulnérabilité

Le processus « httpd » du serveur Apache permet aux attaquants distants de lire des données arbitraires à partir de la mémoire du processus si la directive « <Limit> » est définie dans le fichier « .htaccess » d’un utilisateur (notamment dans le cas d’environnements d’hébergement partagés) et si le fichier « httpd.conf » contient des règles d’accès peu strictes, aka Optionsbleed.
Cela affecte les versions 2.2.x à 2.2.34 et 2.4.x à 2.4.27 du serveur HTTP Apache. L’attaquant envoie une requête OPTIONS HTTP non authentifiée lors de la tentative de lecture de données arbitraires. Il s’agit d’un problème de type « use-after-recycle/free » et, par conséquent, les données secrètes peuvent être divulguées (bien que les données binaires soient bloquées dans les dernières versions 2.2.x et 2.4.x des serveurs Apache); les données spécifiques dépendent de nombreux facteurs, y compris la configuration, et sont peu susceptibles d’être contrôlés par le client. L’exploitation de la faille par l’intermédiaire du fichier « .htaccess » peut cependant être bloquée en mettant à jour la fonction «ap_limit_section » dans « server / core.c » ou en supprimant le token « Limit » (non présent par défaut) de la directive « AllowOverride » du fichier de configuration principal (« httpd.conf », non accessible en écriture par les utilisateurs).

Les produits DenyAll sont-ils touchés par cette divulgation ?

Les produits DenyAll ne sont pas impactés car nous n’utilisons pas la directive « <Limit> » dans nos configurations Reverse Proxy. Comme la vulnérabilité peut être exploitée en utilisant la méthode « OPTIONS » dans les requêtes HTTP, une règle bloquant toutes les requêtes contenant cette méthode suffit à atténuer les exploitations de failles.
Si vos backends d’Apache sont vulnérables, nous vous recommandons d’appliquer la règle suivante:

DenyAll WAF et i-Suite

Comme vous le préférez, la règle peut être appliquée pour DenyAll WAF et i-Suite dans Workflow ou dans une configuration ICX.

Dans le Workflow :
Ajoutez un nœud de décision dans Workflow pour bloquer la méthode « OPTIONS ».

Dans la configuration ICX :
Ajoutez une règle négative dans la configuration ICX pour bloquer la méthode « OPTIONS ».

Produit rWeb

Si vous utilisez la configuration par défaut de la politique Requêtes HTTP dans rWeb, seules les méthodes standard sont autorisées (GET, HEAD et POST). La méthode « OPTIONS » sera bloquée par défaut.

Sinon, nous vous recommandons d’ajouter une règle personnalisée Blacklist pour bloquer la méthode « OPTIONS ».

Pour tout autre détail, nous vous invitons à contacter l’équipe de support DenyAll.

Xavier Quoniam, Marketing Manager on Linkedin
Xavier Quoniam, Marketing Manager
Xavier est notre Marketing Manager. Il est passionné par les nouvelles technologies qui transforment la façon dont les entreprises communiquent. Il nous apporte sa passion, sa curiosité et ses idées innovantes pour promouvoir au mieux DenyAll et Cloud Protector.