EricMitt blog : Security

Brain Computer Interface, (BIC) et si les hackers en voulaient à votre cerveau :-)

ericmitt — Tue, 28 Jul 2009 20:35:10 GMT

Je vous en parlai il y a quelques temps sur ce blog, les Interfaces directes sur le cerveau (ou plus précisément sur son activité, qui peut être captée, sans implantation d’électrode…) continue d’évoluer. Des applications médicales ont vu le jour (fauteuil roulant pour Toyota, ou applications dans le cas d’affection par la maladie de Parkinson’s). Le concept est fascinant et surement clé pour des IHM encore difficile a imaginer… (je verrai cela quand je serai à la retraite…aux conférences organisées par les jeunes :-), idem pour les ordinateurs quantiques… mais la c’est même pas sur que je les vois !)

Ainsi que le souligne cet article de Wired, les hackers risque d’avoir avec ces nouvelles Interfaces, un nouveau champs d’action. Ainsi bon nombre d’équipement vont être équipé de fonction de contrôle a distance via du WiFi (ou son successeur demain…), et la tentation sera bien grande de tenter de s’immiscer entre le BI et le C, autrement dit de venir interférer et donc hacker les échanges entre capteur et ordinateur, afin de prendre la main sur l’ordinateur cible… Oui il est temps que l’on apprenne de nos erreurs passées, et reste à espérer que la sécurisation des échanges (et les protocoles associés) soit des le départ pensé en terme de sécurité.

L’auteur de l’article insiste sur la corrélation entre complexité du code et présence de bug (potentiel trou de sécurité), c’est un vaste sujet (pour ne pas dire un théorème, via les technologies actuelles de développement…) et des recherches très sérieuses et très longues sont menées dans différents laboratoires de recherche à travers le monde (dont MSResearch), les travaux sur la vérification et la preuve formelle mathématique, visent en effet a atteindre cet objectif. Démonter mathématiquement la validité en toute situation d’un code donné, voila un graal digne de ce nom ! Mais ce n’est déjà plus un mythe, le code embarqué dans l' aéronautique (et plus généralement dans tout ce qui expose un risque pour l’homme) ou un sous ensemble de drivers sous Windows (introduit dans Vista, Windows7 ou Serveur 2008) sont “prouvés” mathématiquement (à suivre …)

Bon la ca se voit pas, mais je gonfle ma joue droite… et donc arrête ce post pour aujourd’hui :-) … à bientôt sur ce sujet !

Eric.Not.Yet.Brain.Connected

IE8 et malware : Super costaud IE8 :-)

ericmitt — Wed, 25 Mar 2009 19:29:00 GMT

Une étude comparative vient d'être publiée sur clubic .Il apparait que IE 8 sort vainqueur de cette étude visant à mesurer l’efficacité du navigateur à protéger l’utilisateur face aux malwares et autres mauvaises choses du Web.... Vous trouverez l'étude complète ici :

A bientôt

Eric

!exploitable : une extension à WinDbg pour tracker les problèmes de sécurité

ericmitt — Wed, 25 Mar 2009 16:45:48 GMT

!exploitable (“bang exploitable”) est une extension à WinDBG qui permet l'analyse de crash et notamment sous l'angle des risques liés à la sécurité.

L'outil identifie un gradient au potentiel problème de sécurité rencontré : Exploitable, Probably Exploitable, Probably Not Exploitable, ou Unknown. Toutes les infos et le download ici.
Créé par le groupe Microsoft Security Engineering Center (MSEC) Security Science Team, plus d'infos sur leurs activités sur Security Research and Development blog .

Vraiment c'est flippant :-)

ericmitt — Thu, 11 Sep 2008 17:38:00 GMT

Aaaaghh !

Les MecaPoulets sont la :-) Ou SDL en mode fun (http://www.mecapoulet-lefilm.fr)

ericmitt — Mon, 08 Sep 2008 19:54:00 GMT

Ca y est nous y sommes, cela fait quelques mois que j'ai initié avec mes compères habituel (F Bojman et E Vernié) un des trucs les plus ouf que j'ai fait en 10 ans de Microsoft. Vous savez que je m'occupe de sécurité logicielle et notamment les bonnes pratiques en terme de développement. SDL est la méthodologie issue de l'initiative Trusworthy computing, et décrit comment mettre en œuvre la sécurité dans un projet informatique. Souvent nous avons du mal a solliciter de l’intérêt (ou au moins une oreille attentive sur ce sujet), aussi après moulte réflexions nous nous sommes dit qu’une vidéo « sympa » ferait bien l’affaire. Et malgré l'aspect déjanté de la vidéo, SDL a fait ses preuves chez MS (notament SQL2005 entièrement développé via SDL et qui depauis sa sortie n'a pas diffusé un seul Patch de sécurité critique : Yeahhhh)

Issus de nos cerveaux agités (et ceux de notre agence) le résultat est maintenant dispo ici

Faites y un tour et dites moi ce que vous en pensez… moi je reste convaincu qu’on peut faire des choses très sérieuses avec un minimum de fun J

Que SDL soit avec vous, have fun avec la sécurité J

Eric.Geek.pareil ;-)

Microsoft classé comme l’OS le plus sécurisé !

ericmitt — Thu, 22 Mar 2007 20:08:00 GMT

C’est pas nous qui le disons mais Symantecs, voir la news sur internetnews.

Le rapport est dispo chez Symantec, et riche en infos...

En synthèse :

The report found that Microsoft Windows had the fewest number of patches and the shortest average patch development time of the five operating systems it monitored in the last six months of 2006. During this period, 39 vulnerabilities, 12 of which were ranked high priority or severe, were found in Microsoft Windows and the company took an average of 21 days to fix them. It's an increase of the 22 vulnerabilities and 13-day turnaround time for the first half of 2006 but still bested the competition handily.

L’article passé en revue les « autres » OS et fait tomber quelques idées reçus…notament sur Mac.

A bientôt,

Eric

UAC complément

ericmitt — Mon, 12 Mar 2007 17:26:00 GMT

UAC…

En complément de mon précédent post, deux schémas qui vous aiderons a apréhender plus avant UAC..

Vous trouverez sur MDN un excellent article sur UAC d'ou j'ai extrait ces deux schémas, je vous en recommande « chaudement » la lecture.

Eric

5 minutes pour comprendre UAC et ses implications sur nos codes sous Vista

ericmitt — Fri, 09 Mar 2007 13:29:00 GMT

UAC en 10 lignes :

L’objectif d’UAC est de filtrer (limiter) les droits du jeton associé à un processus Windows Vista.

A la création d’un processus en mode user, le système créé depuis l’origine de WindowsNT (Win32) un jeton de sécurité.

Ce jeton associé au processus et donc aux threads évoluant dans celui ci, est utilisé pour fournir les droits lorsque des permissions sont demandés pour accéder aux différentes ressources du système.

Sans UAC et lorsque rien n’est précisé explicitement en terme de droits et/ou utilisateur, (ie, passer null dans les différentes structures de création de processus ou de thread), c’est le jeton par défaut qui est utilisé : celui de votre log-on (notons que ce sont ces même droits dans ce cas, qui sont a la « portée » d’un hacker….).

Avec UAC, le jeton est filtré à la création du processus. Le système limite ainsi les droits associés a celui-ci, ce qui peut impacter le bon fonctionnement de vos applications, mais permettant de garder le contrôle sur un certain nombre d’actions (ie celle proche du système).

En complément du filtrage des droits du jeton, Vista apporte une virtualisation du registre et des dossiers systèmes. Ainsi une application n’atteindra pas réellement HKLocalMachine ou c:\program file, mais sera déroutée vers un dossier par utilisateur. Cette virtualisation limite les accès aux ressources clé du système et doit donc le protéger d’actions malveillantes ou « hasardeuses »

UAC a un impact sur nos codes tournant sur Vista

Il est crucial de valider le bon fonctionnement de votre application sur Vista, et le cas échéant opter pour une stratégie d’adaptation.

En premier lieu sachez qu’il existe des outils pour tester le fonctionnement de vos application avec UAC et la virtualisation du registre et des dossiers système active (Standard User Analyser permet de tracer toutes les actions d’une application comme les accès au registre les droits demandés ou les répertoires utilisés)

Au regard des résultats des tests, plusieurs options s’offrent à nous :

Forcer l’application a tourner en mode admin non filtrés

Run as admin de l’ explorateur Windows

Inclure un manifeste dans l’application indiquant les doits nécessaires dés le démarrage(c’est également par ce biais que l’on peut désactiver la virtualisation)

Se relancer en admin

Cas du Gestionnaire de tâche de Windows

Lancer un second processus

Création » manuelle » d’un nouveau processus (shellexecute)

Création automatique d’un second processus (Moniker COM, sur un objet en mode exe)

Dernière info pour aller plus loin, il viens d’être publié sur Channel9 une interview de Jon Schwartz, Architecte d’UAC, ca vaut le coup de prendre une heure pour l’écouter…

Eric

Liste des API à bannir en terme de sécurité

ericmitt — Fri, 09 Mar 2007 12:26:00 GMT

M Howard et Leblanc, viennent de publier une liste d'API a proscrire dans une démarche SDL de sécurité.

Cette liste concerne essentiellement les développeurs C/C++ désireux de corriger leur code ou de planifier des développements mettant en œuvre une méthodologie de sécurité (SDL et dérivé). Bien sur tout cela tourne autour de la Runtime C et le support des « bonnes vieilles fonctions C». Dans ce domaine plusieurs initiatives ont été menés ces dernières années :

· StrSafe : strsafe.h expose un pool de fonctions en remplacement de strcpy par StringCchCopy

· Safe CRT : L’approche la plus simple pour sécurisé la runtimeC, en remplaçant strcpy par strcpy_s : Même signature et paramètre en plus optionnel

· Les « n » fonctions. Remplace strcpy par strncpy ne sont pas a conseiller, car leur mise en œuvre n’est pas aisée et peut générer des soucis…

Sur le sujet des chaines, qui est le sujet qui fâche, notez que les auteurs insistent pour utiliser dans le C++ d’autre type que les buffers:

If you are using C++, you should seriously consider using the std::string template class rather than manipulating buffers directly.

Il en va de même en code .NET (ici le C++/CLI) ou le type System::String ou System ::Text::StringBuilder sont fortement conseillées.

Eric