Glibc : des correctifs à appliquer sans tarder

Les experts en sécurité conseillent les entreprises d’appliquer immédiatement les correctifs disponibles pour éliminer le risque d’exécution de code à distance via l’exploitation d’une vulnérabilité nouvellement identifiée au sein de glibc.

De fait, si les ingénieurs de Google à l’origine de sa découverte indiquent qu’elle est difficile à exploiter, ils ont également montré que c’est possible. Dès lors, mieux vaut ne pas en prendre le risque.

Selon les ingénieurs de Google, le code de recherche de domaine au sein de glibc contient un bug susceptible de permettre à un attaquant d’implanter du code au sein de la mémoire d’un appareil affecté pour permettre son exécution à distance.

Comme pour les vulnérabilités Heartbleed et Shellshock, celle de glibc n’est aujourd’hui mise en lumière que plusieurs années après sont introduction et pourrait déjà être exploitée par des pirates.

De la même manière, puisque l’utilisation de la librairie open source standard glibc est largement répandue, des centaines de milliers de serveurs et de terminaux sont susceptibles d’être menacés.

La vulnérabilité de glibc pourrait également permettre à un attaquant de compromettre des applications et de prendre contrôle à des systèmes accédant à des serveurs DNS, soit détournés, soit par le biais d’attaques de type man-in-the-middle, souligne Patrick Carey de Black Duck, qui aide les organisations à utiliser de manière sécurisée des composants open source.

Pour lui, maintenant que la vulnérabilité a été rendue publique, la course est engagée entre équipes de développement et pirates : « dès qu’un correctif est disponible pour votre système d’exploitation, déployez-le », résume ainsi Paul Ducklin, de Sophos. Red Hat est l’un des premiers éditeurs de distributions Linux à proposer ici un correctif.

Si glibc est un composant majeur de nombreux systèmes Unix et dérivées, Ducklin est plutôt optimiste pour les objets connectés : nombre d’entre eux ne l’utilisent pas en raison de sa taille et lui préfèrent des implémentations plus compactes. Android n’est ainsi pas affecté. Toutefois, savoir si des objets connectés sont affectés ou pas n’a rien de trivial en raison de la difficulté d’accès à leurs logiciels internes.

Pour David Flower, de Carbon Black, la vulnérabilité de glibc est d’autant plus sérieuse qu’elle « permet à des pirates de contourner des mesures de sécurité de base comme les systèmes anti-virus ou même des solutions de sécurité réseau plus sophistiquées ».

Dès lors, il lui paraît particulièrement important que les entreprises aient « la capacité de surveiller les activités survenant sur les terminaux pour détecter, prévenir et contrecarrer les comportements malicieux qui indiquent qu’un pirate a pris le contrôle à distance de leurs systèmes, pour les arrêter avant qu’ils ne puissent causer des dommages ».

De son côté, Thomas Fisher, chercheur chez Digital Guardian, estime que la vulnérabilité de glibc est plus susceptible d’affecter les équipements réseau que les serveurs et les terminaux car ces derniers sont généralement dotés de protections de la mémoire et de techniques d’isolation plus robustes, pour contrôler ce qu’exécute le processeur : « de telles protections ne sont pas implémentées dans les équipements intégrés tels que les routeurs en raison de leur nature onéreuse ». Et là encore, il recommande d’appliquer les correctifs disponibles aussi vite que possible.

En outre, Fisher relève plusieurs mesures de protection à utiliser, à commencer par forcer les appareils connectés à utiliser un serveur DNS interne, à limiter les délais de réponse DNS acceptables, ou enocre à éviter les requêtes sur les champs AAAA.

De leur côté, les chercheurs de Google à l’origine de la découverte recommandent de limiter la taille des réponses acceptées par les résolveurs DNS, « via DNSmaq ou des programmes similaires », et de s’assurer que ceux-ci n’interrogent que des serveurs qui limitent la taille des réponses en UDP en activant le bit de troncature.

Adapté de l’anglais.