Mots-clés : Networks processeur, FPGA, ASICLa conception d'équipements matériels de sécurité se doit de respecter un certain nombre de contraintes. Dans le cas des équipements « en ligne », la principale contrainte est la performance. L'évolution des architectures a mené à la définition de nouveaux composants, et, parmi eux, les network processors. L'étude de ces composants est intéressante à deux titres. D'abord, elle permet de couvrir un large éventail d'aspects techniques tant les architectures, les fonctionnalités et, par conséquent, les schémas de mise en œuvre peuvent différer d'un fabricant à un autre. Ensuite, elle met au jour de manière flagrante les choix d'architecture qui sont à la base des différents produits du marché, mettant en évidence leurs forces et faiblesses intrinsèques.

Poussé par la convergence des technologies (téléphonie et informatique), la consolidation des solutions et la réduction des coûts, l'infrastructure réseau est un élément critique pour la fourniture de nombreux services. La mode du tout IP, avec des interfaces et des réseaux ouverts n'est pas sans poser de nouveaux problèmes : réseaux locaux qui s'ouvrent à l'Internet et réseaux « Internet » des opérateurs qui deviennent des réseaux IP où l'Internet n'est plus qu'un « sous-réseau » qu'on transporte et non l'inverse. Ce changement de positionnement de l'Internet par rapport au réseau multi-transport IP implique que l'on change d'approche pour la sécurisation de son cœur de réseau (le « best effort Internet » n'est plus suffisant et la possibilité de contacter tous les éléments d'un réseau n'est plus désirable).

L'exploitation de failles applicatives de type buffer overflow sur architecture MIPS [2] s'avère légèrement plus complexe que sur architecture IA-32. Ceci est principalement lié à la désynchronisation des caches d'instructions et de données. Afin de forcer cette synchronisation et pouvoir exécuter le code injecté durant le débordement, une opération de cache writeback peut s'avérer nécessaire. Cependant, ce service1 fourni par la bibliothèque C n'est pas systématiquement présent. C'est le cas, par exemple, des dernières versions de µClibc livrées dans les firmwares des routeurs Linksys de type WRTxxx2.Nous proposons, en premier lieu, une méthode permettant d'effectuer un appel à cacheflush(), même si celle-ci n'est pas présente dans la bibliothèque C. Nous détaillons ensuite une méthodologie d'appels de fonctions de la bibliothèque C permettant de s'affranchir de l'injection de code exécutable.

Selon un rapport de la Rand Corporation [1], l’intérêt particulier du gouvernement japonais pour les menaces de guerre de l’information (GI) [2] potentielles trouverait son origine dans la grande crise du Yen de 1998, lorsque la monnaie perdit 22% de sa valeur en deux jours seulement. Après quelques mois d’enquêtes, on imputait la chute du Yen à l’action d’un cheval de Troyes créé par des Chinois et des organisations criminelles asiatiques. Au début des années 2000, le Japon n'en est encore qu'au début de sa réflexion sur les moyens à déployer (cellules de crise, forces spéciales, structures et matériels spécifiques) en matière de GI.Si l’on en croit les propos tenus en mars 2000 par le Colonel Koji Shimohira, attaché de défense à l'ambassade du Japon à Paris, rapportés sur le site infoguerre.com [3], du fait de sa situation, de sa culture et de la domination absolue des milieux économiques sur la société japonaise, le Japon ne distingue que deux sphères dans lesquelles la GI peut se développer : la sphère civile (économique et sociopolitique étant confondus), et la sphère militaire. Dans la première, les cyber-conflits font rage, le Japon est attaqué de toutes parts et ses systèmes d’information (SI) [4] mis à mal (§I). Dans la seconde, la réflexion s’est engagée avec prudence, essentiellement autour du concept de révolution dans les affaires militaires (§II).

De plus en plus, les développeurs en tout genre mesurent l'impact que peut avoir une faille dans leur application. Pour les éviter, ils essaient de mettre en place des bonnes pratiques. Néanmoins, ces bonnes pratiques ne sont pas parfaites.

Ne vous êtes vous jamais retrouvé devant un assert() qui saute et devoir lire des centaines de lignes de code avant de comprendre quel cheminement votre programme avait dû suivre pour en arriver là ? Ne vous êtes vous jamais posé la question de savoir si tout ce travail était réellement nécessaire ou s'il ne pourrait pas être délégué à un quelconque processus qui tourne en tâche de fond ? Ne se pourrait-il pas que les debuggers puissent évoluer et devenir capables de trouver ces bugs eux-mêmes sans intervention humaine ? Science-fiction ou réalité ?Cet article essaye de faire le point sur certaines techniques récentes de vérification logicielle et d'analyse de code et des répercussions possibles que ces récentes avancées pourraient avoir sur nos outils de debuggage dans un avenir proche.

Toute personne pratiquant des audits de sécurité ou bien des tests d'intrusion s'est trouvée un jour (ou plusieurs ;)) dans la situation où l'identification du système d'exploitation donnée par nmap était totalement erronée. En analysant le problème, je suis arrivé à la conclusion que l'approche de nmap n'était plus adaptée pour une utilisation dans les conditions réseau d'aujourd'hui. Seule solution, écrire un nouvel outil d'OSFP avec comme objectif : un système d'exploitation détecté pour un port TCP ouvert. Mise en garde : étant l'auteur de l'outil, il se peut que cet article soit un peu biaisé ;)

La publication par Microsoft du correctif de sécurité MS06-040 au mois d'août dernier a réveillé la crainte de nombreuses personnes de voir apparaître un nouveau ver du même type que Sasser ou Blaster. En effet, cette faille de sécurité touche l'ensemble des systèmes Windows et est accessible anonymement. Cependant, depuis 2 ans, une grande partie de ces systèmes ont migré sous XP SP2 ou 2003 SP1 et ont, grâce à cela, profité de nouvelles mesures de sécurité censées protéger de ce type d'attaque. L'analyse de ce correctif devrait permettre de mieux comprendre les risques encourus.