Warning: Cannot modify header information - headers already sent by (output started at /home/gillesbld/www/weblog/inc/config.php:41) in /home/gillesbld/www/weblog/inc/clearbricks/common/lib.http.php on line 222

Warning: Cannot modify header information - headers already sent by (output started at /home/gillesbld/www/weblog/inc/config.php:41) in /home/gillesbld/www/weblog/inc/clearbricks/common/lib.http.php on line 224

Warning: Cannot modify header information - headers already sent by (output started at /home/gillesbld/www/weblog/inc/config.php:41) in /home/gillesbld/www/weblog/inc/public/lib.urlhandlers.php on line 65

Warning: Cannot modify header information - headers already sent by (output started at /home/gillesbld/www/weblog/inc/config.php:41) in /home/gillesbld/www/weblog/inc/clearbricks/common/lib.http.php on line 247
Tag - sécurité - Embedded weblog

Embedded weblog

Aller au contenu | Aller au menu | Aller à la recherche

mercredi, avril 15 2009

no comment

Vista today, post-Service Pack 2, which is now in the marketplace, is the safest, most reliable OS we've ever built. It's also the most secure OS on the planet, including Linux and open source and Apple Leopard. It's the safest and most secure OS on the planet today.

Remarks by Kevin Turner, chief operating officer for Microsoft, about the role of CIOs in a changing economy
MidMarket CIO Summit
Redmond, Wash.
April 6, 2009

mercredi, novembre 12 2008

embedded virus

On voit cela comme une grande nouvelle : une boîte déclare qu'il n'y a pas besoin d'antivirus pour Android. Il faut dire qu'une autre entreprise jouait déjà du FUD pour proposer sa propre solution de sécurité. Décidément, on vit dans un monde infecté par le Desktop et l'ignorance qui va avec (surtout pour les utilisateurs windowsiens, formés à l'assainissement régulier d'OS). Tout d'abord, tordons le cou à une assertion débile du second acteur sécuritaire : l'OpenSource impliquerait l'apparition de virus, théorie fort chère à Microsoft (la sécurité est impliquée uniquement par l'obscurantisme du code, il n'y a qu'à considérer leurs produits pour s'en convaincre), dont on peut évidemment vérifier la vérité tous les jours à l'aide de son Linux ou de son BSD. Très sérieusement : c'est n'importe quoi. Et du côté des obscurs, on ira voir RIM (qui ne cache pas certaines failles alarmantes du passé), ou on se penchera sur la réponse d'Apple et de son système de signature d'applications autorisées qui a rapidement été outrepassé.

Analysons objectivement la sécurité des systèmes embarqués : c'est effectivement un soucis qu'il faut prendre au sérieux, j'en parle d'ailleurs dans les cours que je dispense. En informatique, rien n'est magique, il faut donc déjà passer outre les images d'Epinal de "bestioles" rampantes qui s'incrustent dans les appareils et les rendent fou, ou en tirent des informations secrètes (on admet que par "virus" on désigne un peu tout ce qui concerne les failles de sécurité, notamment -- et surtout -- les vers). Déjà, pour les appareils communicants (ce ne sont que ceux-là qui sont concernés, sinon comment s'introduire ?), il faut déjà filtrer les entrées et les sorties : firewall, chiffrage, voire analyse de détection sur des données manifestement mal formattées (les réseaux GSM de SFR limitent par exemple de façon tout à fait arbitraire la taille des URL). Ensuite, il ne faut pas écarter l'apparition de code malveillant, et ici il faut se pencher sur la seule et unique question : comment fait-il pour s'exécuter, et quelle réponse y apporter ?

Plusieurs cas. On peut faire du buffer overflow avec des données corrompues : il suffit de protéger la pile, des solutions comme PaX font cela très bien, en marquant les zones hors piles comme non exécutables. Il y a aussi l'option -fstack-protector-all de GCC, qui met en place des canaris : comme dans les mines où les volatiles jaunes révélaient la présence de gaz en mourant et donc en arrêtant de piailler, la technique consiste à mettre aux extrémités de la pile d'exécution des bouts de données qui, si elles sont écrasées (par un shellcode, au hasard), provoquent l'arrêt immédiat du programme. Et cela sans compter que Android est basé sur du Java, ce qui constitue déjà en soi une boîte à sable pouvant se révéler très efficace (pour avoir programmé en J2ME en 2004 sur téléphone portable, je peux même assurer que l'accès aux données physiques est fortement contrôlé, mais effectivement on peut de plus en plus accéder à des fonctionalités du téléphone, afin d'être plus user-friendly).

On peut ensuite avoir tout simplement un programme tiers téléchargé et exécuté à la main, par l'utilisateur. A ce niveau, il faut évidemment responsabiliser l'utilisateur (ne pas exécuter cette application manifestement malveillante). Notons que l'argument consistant à évoquer la multplicité des OS sur plate-formes mobiles n'est pas recevable, puisqu'accéder au répertoire téléphonique, SMS, ou autres données sensibles de la carte SIM, tout comme le fait de lancer des appels, se fait par commandes AT à un second kernel, très souvent du Nucleus ; et entre Symbian, RIM OS, WinCE/Mobile, Linux et Darwin, on voit mal ce que l'on appelle "grande multiplicité" (surtout que Symbian est toujours majoritaire). Dans tous les cas, éviter de lancer un programme en root, sandboxer (en Java, c'est quasiment natif), filtrer des commandes interdites (ce que fait nativement un BSD avec jail, en somme), et déjà je souhaite une grande chance aux pirates pour s'en sortir.

Il y a en outre la possibilité, pour les appareils communicants, de se mettre à jour. Il faut bien faire attention à la procédure (notamment il faut doubler les OS présents : l'un, très minimal, doit toujours être présent au cas où la mise à jour aurait échoué, afin de pouvoir la reprendre), mais tous les appareils modernes supporte ce genre de fonctionnalité. Cependant, mettre à jour le noyau lui-même peu s'avérer très périlleux, si ce n'est impossible. En effet, pour des raisons pratiques mais aussi de de sécurité, le noyau Linux est placé "en dur", en dehors de tout file system, dans le firmware : c'est une pratique extrêmement courante qui a énormément d'avantages. Le problème est que son remplacement n'est alors pas si aisé, voire inenvisageable. J'ai travaillé, il y a plus d'un an, sur une solution avec un noyau qui s'est avéré six mois plus tard être frappé de la faille sur la mémoire virtuelle qui permet de prendre les droits "kernel" (plus que root, on se retrouve en kernel land) ; pourtant, j'ai continé à bien dormir (sachant que c'est une solution dont le marché prévu recoupait des choses aussi diverses que la gestion de terminaux bancaires).

Car il existe une excellente solution de protection pour Linux : RSBAC. Je vous laisse découvrir la chose, la première fois que l'on se fait jeter d'un "su" alors que l'on est root est une expérience étrange. La faille est donc peut-être présente, mais le mode opératoire pour arriver à en profiter est totalement hors de portée. De même, les solutions de paravirtualisation embarquée sont là pour répondre à cette problématique : un OS se charge de ce qui est sensible, et l'autre de ce qui est pour "le fun" ; l'imperméabilité totale est assurée au niveau électronique, la communication se fait par des canaux très définis, limités et filtrés, et en cas de problème sur le second OS, le premier n'est pas atteint.

Bref, pour peu que l'on réfléchisse avant, des solutions libres pour une parfaite sécurité dans l'embarqué existent, et ne sont pas bien difficile à mettre en oeuvre (l'option de stack protector de GCC n'est pas activée par défaut dans OpenEmbedded, et certains programmes compilent mal avec, mais c'est juste une question de jours pour résoudre les divers problèmes, quant à RSBAC il faut bien le configurer, et une option de démarrage est là pour se mettre en "mode apprentissage automatique"). J'ose croire que les concepteurs de téléphonie mobile (et j'y ai quelque peu travaillé, je peux donc assurer qu'ils ont très paranoïaques) prennent le problème très au sérieux. Et même, que ce que l'on reproche à RIM et son Blackberry, à savoir le manque de transparence sur le trasit des données, ne pourrait être reproché à une solution libre. Les clients de Linagora, qui font le choix de Linux ou BSD pour des opérations très sensibles, pourront sans doute aucun confirmer.