Lorsque l’on parle de programmation sécurisée, on pense d’abord à un dépassement d’indice d’un tableau ou à des droits d’accès non respectés, puisque ces aspects sont visibles par le programmeur. Par contre, la pile est sous le contrôle absolu du compilateur et le contrat implicite est que « ça fonctionne » tant que nous le laissons faire son travail, qui est de plus en plus alambiqué. L’article précédent [1] détaillait de façon lovecraftienne les soucis de flexibilité et de sécurité inhérents au modèle de programmation à une seule pile, utilisé par (quasiment) tous les compilateurs actuels. J’ai amalgamé tous ces problèmes dans le terme « Single Stack Syndrome », mais il n’y a pas que le C ou le x86 dans la vie ! Nous pouvons trouver des inspirations dans d’autres langages, d’autres architectures et d’autres ères.

Nous proposons dans cet article une analyse approfondie des mécanismes de sécurité intégrés aux équipements FortiGate. Nous présenterons la manière dont un chercheur peut les contourner jusqu’à pouvoir modifier le firmware et déboguer l’équipement.

Selon Sonatype, depuis décembre 2021, 29 % des téléchargements de Log4J le sont sur des versions vulnérables à Log4Shell. Cette statistique démontre l’importance pour les entreprises de renforcer la prise en compte de la sécurité dans les équipes de développement. Comment la mise en place d’un programme de security champions peut-elle améliorer l’intégration de la sécurité au plus tôt dans les projets ?

Les mots de passe, quelle galère ! Il en faut de plus en plus, sécurisés, difficiles à retenir, changés facilement, etc. L’utilisation de clefs asymétriques est une bonne alternative, mais les hébergeurs ne semblent pas prêts à les utiliser et préfèrent les mots de passe. Les logiciels KeePass* permettent de faciliter leur utilisation au quotidien.