Discussion :

[Gordon Fowler]

Microsoft veut aider les développeurs à écrire des codes plus sûrs
Et publie un Template pour VisualStudio et un paper de 18 pages


Microsoft vient de publier son traditionnel rapport de sécurité, le Microsoft’s Security Intelligence Report.

Il en ressort que sur les 6 premiers mois de 2009, 19% des vulnérabilités se trouvent dans les navigateurs. Parmi les autres (soit 81%), au total 5 % seulement concerneraient des produits de Microsoft.

David Ladd, un des principaux responsables en charge des problèmes de sécurité à Redmond, note que pour ses autres confrères développeurs d'applications "jusqu'ici, la sécurité n'a pas été une priorité" par rapport au développement de nouvelles fonctionnalités de l'amélioration des ergonomies. "Ce n'est pas une critique, c'est juste un impératif commercial".

Mais les clients, de plus en plus conscients de ces impératifs, commencent à donner une place importante à la sécurité dans leurs cahiers des charges. Avec Windows, l'OS le plus populaire au monde, Microsoft a toujours été une cible privilégiée pour les hackers et entend faire partager son expertise.

Depuis les années 90, la société a créé un groupe de réflexion, le Microsoft’s Trustworthy Computing (TwC). Une des premières missions du TwC a été de publier un process de développement pour minimiser le nombre de vulnérabilités dans les applications : ce Security Development Lifecycle (SDL)

Depuis 2004, ce SDL est appliqué dans la conception de tous les produits Microsoft.

En 2008, Redmond a décidé de rendre public son "guide de bonnes pratiques pour l'industrie logiciel" en proposant quatre outils de développement : un outil de modélisation des menaces, le Minifuzz file fuzzer, l'analyseur de binaires Binscope, et le SDL Process Template du Visual Studio Team System. "En partageant ce que nous avons appris notre but est d'accélérer le processus d'apprentissage de tous les développeurs".

Continuant sur sa lancée, Microsoft vient de présenter de nouveaux outils lors du Black Hat de Washington.

L'objectif, cette fois-ci, est de rendre les outils SDL plus simples d'utilisation pour aussi bien pour les groupes internationaux que pour les PME de quelques développeurs. Pour ce faire, un document de 18 pages, intitulé “Simplified Implementation of the Microsoft SDL", est disponible au téléchargement sur le Microsoft Download Center.

Microsoft souligne que ce processus, spécialement imaginé pour s'intégrer dans les méthodes Agiles, n'est pas cantonné à Windows ou à ses produits maisons.

Mais Redmond ne s'arrête pas là. La beta d'un Template pour VisualStudio 2008 vient également d'être mis à la disposition des développeurs. La version pour VisualStudio 2010 est également prévue dès que ce dernier sera finalisé.

Depuis hier, le paper de 18 pages est disponible ici, tout comme le Template pour VS2008.



Source : le site officiel du SDL

Lire aussi

Les Rubriques (news, tutos, forums) de Developpez.com :

Windows
.NET
Conception
Sécurité


Et vous ?

Que pensez-vous des méthodes et des outils SDL proposés par Microsoft : efficaces ou inadaptés ?
Êtes-vous d'accord avec David Ladd quand il dit que jusqu'ici la sécurité n'a pas été une priorité pour les développeurs d'applications par rapport à la création de nouvelles fonctionnalités ou l'amélioration des ergonomies ?

[dams78]

C'est cool ils vont pouvoir l'utiliser pour les prochaines version de Windows .
Sinon je trouve ça bien comme approche, mais c'est une peu déplacer le faute sur les développeurs, je trouve...

[B][SIZE="4"] Que pensez-vous des méthodes et des outils SDL proposés par Microsoft : efficaces ou inadaptés ?

J'ai pas assez de connaissances en la matière pour me prononcer, mais c'est une bonne chose qu'ils en prennent conscience de la sécurité je pense.

[B][SIZE="4"] Êtes-vous d'accord avec David Ladd quand il dit que jusqu'ici la sécurité n'a pas été une priorité pour les développeurs d'applications par rapport à la création de nouvelles fonctionnalités ou l'amélioration des ergonomies ?

Tout dépend de quelles applications on parle...

[bubulemaster]

Êtes-vous d'accord avec David Ladd quand il dit que jusqu'ici la sécurité n'a pas été une priorité pour les développeurs d'applications par rapport à la création de nouvelles fonctionnalités ou l'amélioration des ergonomies ?

C'est pas totalement faux. Disons, aussi que la sécurité saute moins aux yeux que l'ergonomie.
Heureusement, certains projets (Firefox par exemple) font les deux. Mais leurs cycle de développement est plus long (ce qui n'est pas un mal, ça évite de passer ses journées à faire des mises à jour).

[travon]

mdr

Microsoft qui publie un papier et des outils pour rendre les codes des développeurs plus sûrs !!!!!



Et y s'en servent eux au moins, parce que on dirait pas !!!

[jmnicolas]

Et y s'en servent eux au moins, parce que on dirait pas !!!

Troll bas de gamme : ça fait longtemps que Microsoft ne sort plus des OS passoires (depuis XP SP2 en fait).

Bien sûr qu'il y a encore des vulnérabilités, mais amha ils ont largement rattrapé la concurrence.

[dams78]

Troll bas de gamme : ça fait longtemps que Microsoft ne sort plus des OS passoires (depuis XP SP2 en fait).

Bien sûr qu'il y a encore des vulnérabilités, mais amha ils ont largement rattrapé la concurrence.

Oué enfin d'autre côté depuis XP ya eu quoi? Vista qui a vite été remplacé par Seven, et ceci il y a peu, donc bon...

[smyley]

Êtes-vous d'accord avec David Ladd quand il dit que jusqu'ici la sécurité n'a pas été une priorité pour les développeurs d'applications par rapport à la création de nouvelles fonctionnalités ou l'amélioration des ergonomies ?

Personnellement oui. Autant dans les beaux cours magistraux on fait de belles théories sur les "bonnes pratiques" et on a des jolis papiers sur la sécurité "en général", autant en pratique, j'ai souvent vu des codes à bidouillage actif et fonctionnement étrange.

Le but premier c'est "ça compile". Le deuxième c'est "ça fait ce qu'on attend de lui si tout va bien". Et après, bizarrement, ça livre ...

[pseudocode]

Il en ressort que sur les 6 premiers mois de 2009, 19% des vulnérabilités se trouvent dans les navigateurs. Parmi les autres (soit 81%), au total 5 % seulement concerneraient des produits de Microsoft.

?

De quelles vulnérabilités ils parlent. Non parce que, pour moi, pouvoir prendre le contrôle d'un PC a distance c'est une vulnérabilité de l'OS... quand bien même l'attaque se fait via une application tierce qui tourne dessus.

A moins de faire une application explicitement concue pour prendre le contrôle (comme un "bureau distant"), je ne vois aucune raison pour que l'OS soit compromis. non ?

[Skyounet]

?

De quelles vulnérabilités ils parlent. Non parce que, pour moi, pouvoir prendre le contrôle d'un PC a distance c'est une vulnérabilité de l'OS... quand bien même l'attaque se fait via une application tierce qui tourne dessus.

Il y a des OS qui savent se protéger des buffer overflows ? (c'est une vraie question).

[pseudocode]

Il y a des OS qui savent se protéger des buffer overflows ? (c'est une vraie question).

Les buffer overflows, c'est toujours possible avec des langages comme le C.

Mais empecher que des octets injectés par buffer-overflow se transforment en code valide, que ce code soit exécuté, et qu'il permette d'outrepasser les droits de l'application originale, et par là prendre le contrôle de l'OS... Désolé, mais pour moi c'est de la responsabilité de l'OS de ne pas permettre que tout cela arrive.

Tout comme il y a l'isolation des zones mémoire entre les processus, il devrait aussi y avoir une isolation des fonctionnalités accessibles. Un peu ce que fait SE-Linux.

Ou dans un autre esprit, Singularity.

[atha2]

Il y a des OS qui savent se protéger des buffer overflows ? (c'est une vraie question).

oui :
http://www.developpez.net/forums/d79...ipe-recherche/

après peut-on vraiment parler d'OS, c'est une autre question...

[smyley]

Mais empecher que des octets injectés par buffer-overflow se transforment en code valide, que ce code soit exécuté, et qu'il permette d'outrepasser les droits de l'application originale, et par là prendre le contrôle de l'OS... Désolé, mais pour moi c'est de la responsabilité de l'OS de ne pas permettre que tout cela arrive.

C'est pas le rôle du DEP justement ?

[pseudocode]

C'est pas le rôle du DEP justement ?

Oui, le DEP permet d'empêcher que du code injecté dans une page marquée "data" soit exécuté par le processeur. Mais ca signifie que si on ecrit dans une page qui n'est pas marquée, ou que si on supprime la marque, alors ca sera exécuté.

Mais surtout, ce que je veux dire c'est que le problème est pris à l'envers.

Limiter les buffer-overflow ou se protéger de l'execution de code en zone data, c'est bien. Mais, malgré tout, l'OS ne devrait pas tolérer qu'une application "anodine" (genre lecteur flash) puisse accéder a des fonctions systèmes permettant une prise de contrôle.

Ms a fait cet effort en créant une sandbox autour de son navigateur internet. Mais ca devrait être généralisé a toutes les applications et donc, pour plus de simplicité, géré directement par l'OS.

[smyley]

Ms a fait cet effort en créant une sandbox autour de son navigateur internet. Mais ca devrait être généralisé a toutes les applications et donc, pour plus de simplicité, géré directement par l'OS.

Mais par défaut sur Vista/Seven, une application est lancée à travers l'UAC et elle n'a pas la possibilités de faire des changements sur le système, à moins d'être lancée avec le jeton d'administrateur complet.

En théorie ça limite la casse, si casse il y a ... non ?

[pseudocode]

Mais par défaut sur Vista/Seven, une application est lancée à travers l'UAC et elle n'a pas la possibilités de faire des changements sur le système, à moins d'être lancée avec le jeton d'administrateur complet.

En théorie ça limite la casse, si casse il y a ... non ?

Oui ca limite. Mais ca me donne tout de même l'impression que le système de sécurité est a l'envers. Par défaut tout est autorisé, et on rajoute des verrous par-ci par-là pour "limiter la casse". C'est tout de même curieux.

[Franck SORIANO]

Oui ca limite. Mais ca me donne tout de même l'impression que le système de sécurité est a l'envers. Par défaut tout est autorisé, et on rajoute des verrous par-ci par-là pour "limiter la casse". C'est tout de même curieux.

Il ne faut pas oublier que l'UAC ne concerne que les comptes administrateur. Microsoft a été obligé d'introduire l'UAC parce que bon nombre d'applications sont males écrites, que les administrateurs gèrent mal les sécurités... et qu'au final les utilisateurs lambda travaillent en étant administrateur !
Donc oui, ils ont tous les droits. Mais non, ce n'est pas le comportement par défaut, c'est eux qui se les sont données.
L'UAC a été introduite pour pouvoir sécuriser un peu l'OS malgré cette mauvaise pratique chez les utilisateurs.

Sinon je trouve ça bien comme approche, mais c'est une peu déplacer le faute sur les développeurs, je trouve...

Et bien cette réflexion illustre bien la raison des plus gros problèmes de sécurité.
La sécurité est l'affaire de tous, pas seulement de l'OS, du réseau ou du système :
- Supposons que l'OS et les navigateurs soient complètement blindés et invulnérables
- Les admins ont parfaitement bien fait leur boulot, les serveurs sont dans des DMZ, avec des firewall partout...
- Un hackeur n'a aucune possibilité pour s'introduire sur le réseau, et même s'il y parvenait il ne pourrait rien faire.

=> Et bien même dans ce cas là, ta forteresse partirait en miettes si par exemple, les développeurs ont pondus un site web sensible aux injections SQL et que l'intru s'en sert pour se connecter avec un compte super-utilisateur sur le site, accéder aux données de ses concurents et voler tout ce qu'il veut...

Or l'immense majorité des attaques ne portent pas sur le système, mais sont issues de clients ou d'utilisateurs qui disposent déjà d'un point d'entrée (au pire ils ont volés un login et un mot passe par un moyen X ou Y) et qui contournent les sécurités applicatives pour faire des choses et accéder à des données confidentielles qui leur sont interdites...

Un des gros problèmes c'est justement que les développeurs s'imaginent que la sécurité n'est qu'un problème système et ne les concerne pas.
Ils n'ont même pas conscience des vulnérabilités du code qu'ils écrivent.

Donc les problématiques de sécurité ne sont pas prises en compte lors des développements.

Le but premier c'est "ça compile". Le deuxième c'est "ça fait ce qu'on attend de lui si tout va bien". Et après, bizarrement, ça livre ...

Oui, et très souvent, il n'y a pas que la sécurité qui est sacrifiée dans ce processus ("tout ce qui compte c'est que ça marche, je me fiche de savoir comment").

[pseudocode]

Il ne faut pas oublier que l'UAC ne concerne que les comptes administrateur. Microsoft a été obligé d'introduire l'UAC parce que bon nombre d'applications sont males écrites, que les administrateurs gèrent mal les sécurités... et qu'au final les utilisateurs lambda travaillent en étant administrateur !
Donc oui, ils ont tous les droits. Mais non, ce n'est pas le comportement par défaut, c'est eux qui se les sont données.
L'UAC a été introduite pour pouvoir sécuriser un peu l'OS malgré cette mauvaise pratique chez les utilisateurs.

Comme tu le montres, l'approche actuelle de la sécurité est orientée "utilisateur".
C'est à dire que ce que PEUT faire un processus sur le système dépend de QUI est entrain de l'exécuter.

Déjà, pour moi, c'est pas normal. C'est pas parce que je regarde une video flash en etant Administrateur que le player flash à le droit d'aller ecrire en base de registre.

Les fonctions systèmes accessibles par un processus ne devrait dépendre que de :
1. ce qui a été déclaré dans le processus, définies par le développeur (=manifest)
2. ce qui a été autorisé pour ce processus, définies par l'utilisateur (=profil)

Bref, une approche de la sécurité orientée processus, et pas utilisateur.
L'approche utilisateur impliquerait de créer des utilisateurs differents a chaque fois qu'on veut des autorisation différentes. C'est sans doute la raison pour laquelle on a des utilisateurs spéciaux sous windows ("local", "system", "service", "authority")

Enfin voila. Tout ca pour dire que si je code un "démineur" en C++, je ne devrais pas avoir a me poser des questions de sécurité relatives au système d'exploitation. Relatives à mon application : ok. Mais pas plus.