Cette semaine, nous allons couvrir deux vulnérabilités de haute sévérité, l'une dans Rubygems et l'autre dans Rsyslogs. Nous discuterons également de l'importance de définir des pratiques de codage sécurisées.
Prise de contrôle non autorisée de gemmes dans Rubygems
Rubygems est un registre de paquets utilisé pour fournir des logiciels pour l'écosystème du langage Ruby. En raison d'un bug dans l'action yank, il était possible pour n'importe quel utilisateur de RubyGems.org de supprimer et de remplacer certaines gemmes même si cet utilisateur n'était pas autorisé à le faire.
Pour être vulnérable, il faut un joyau :
- Un ou plusieurs tirets dans son nom
- Une pierre précieuse contrôlée par l'attaquant dont le nom est précédé d'un tiret
- Création dans les 30 jours OU pas de mise à jour depuis plus de 100 jours
Atténuation
Selon l'équipe de Bundler, l'utilisation de Bundler en mode -frozen ou -deployment dans l'intégration continue et lors des déploiements garantira que votre application ne bascule pas silencieusement vers des versions créées à l'aide de cet exploit.
Pour vérifier l'historique de votre application afin de détecter d'éventuels exploits antérieurs, consultez votre fichier Gemfile.lock et recherchez les gemmes dont la plate-forme a changé alors que le numéro de version n'a pas été modifié. Par exemple, la mise à jour de gemname-3.1.2 en gemname-3.1.2-java pourrait indiquer un abus possible de cette vulnérabilité. RubyGems.org a été corrigé et n'est plus vulnérable à ce problème.
Débordement potentiel de tampon basé sur un tas dans Rsyslogs
Rsyslog est un système rapide comme l'éclair pour le traitement des journaux. Certains modules de réception TCP syslog présentent un débordement de la mémoire tampon du tas lorsque l'encadrement par octets est utilisé. Dans ce cas, chaque message est précédé de la longueur réelle du message, de sorte que le destinataire sait exactement où le message se termine. L'attaquant peut corrompre les valeurs du tas, ce qui entraîne des problèmes d'intégrité des données et un impact sur la disponibilité. L'exécution de code à distance est peu probable mais pas impossible. Les versions 8.2204.0 et inférieures sont affectées par cette vulnérabilité.
Atténuation
Le cadrage avec comptage d'octets n'est pas très courant. En général, il doit être spécifiquement activé par les expéditeurs. Si les utilisateurs n'en ont pas besoin, ils peuvent le désactiver pour les modules les plus importants. Cela atténuera la vulnérabilité. La manière de procéder dépend du module. Voir ici pour les modules concernés et les détails de configuration en fonction des modules. Le correctif est disponible dans la version 8.2204.1.
L'importance de définir un code sécurisé
Le codage sécurisé est une pratique qui consiste, pour des développeurs compétents, à écrire un code exempt de vulnérabilités dès le début du cycle de vie du développement logiciel (SDLC). Ce n'est qu'une fois cette pratique définie que la communauté des développeurs peut travailler à la réalisation de cet objectif. Secure Code Warrior a mené l'enquête The state of developer-driven security survey, 2022 en partenariat avec Evans Data Corp en décembre 2021, interrogeant 1 200 développeurs dans le monde entier pour comprendre les compétences, les perceptions et les comportements en matière de pratiques de codage sécurisé, ainsi que leur impact et leur pertinence perçue dans le SDLC.
Voici quelques points saillants de l'enquête :
- Sur 1 200 développeurs de logiciels actifs, seuls 14 % d'entre eux placent le codage sécurisé en tête de leurs priorités.
- 37 % des développeurs interrogés dans le cadre de l'enquête ont déclaré avoir laissé des vulnérabilités connues dans leur code parce que les délais serrés ne leur permettaient pas de disposer du temps nécessaire pour les corriger ou pour coder correctement dès le départ.
- 36 % des personnes interrogées ont également déclaré qu'elles souhaitaient éliminer les vulnérabilités de leur code, mais qu'elles n'avaient pas les compétences ou les connaissances nécessaires pour le faire.
- Dans de nombreux cas, les développeurs ont du mal à écrire du code sécurisé parce que les organisations pour lesquelles ils travaillent n'ont pas identifié les meilleures pratiques nécessaires pour produire du code sécurisé et n'ont pas consacré suffisamment de ressources à la formation ou à l'habilitation de leurs développeurs pour qu'ils atteignent ces objectifs.
Ainsi, outre une définition correcte des pratiques de codage sécurisé, les organisations doivent également prévoir des délais plus longs afin de donner aux développeurs suffisamment de temps pour coder correctement et leur fournir une formation pratique qui les aide à identifier et à corriger les vulnérabilités du code de manière efficace.
Vous pouvez obtenir des informations plus détaillées sur l'enquête en cliquant ici.
Commentaires