IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Les développeurs ignorent-ils trop les failles découvertes dans leur code ?
Prenez-vous en compte les remarques des autres ?

Le , par Hinault Romaric

256PARTAGES

8  0 
Les applications pendant leur cycle de vie sont le plus souvent sujettes à des bugs ou des failles de sécurité dues à des erreurs de programmation, des dysfonctionnements, etc.

Ces bugs et failles sont couramment découverts par d’autres tiers (experts en sécurité, testeurs, etc.) qui se chargent de décrire la faille, les risques et les conséquences que peut avoir une exploitation de celle-ci, ainsi que la fonction qui est à l’origine de la défaillance.

Face à de telles situations, le développeur doit le plus souvent essayer de mettre sur pied en fonction du degré de vulnérabilité un correctif de sécurité.

Cependant, il s’avère que souvent, le développeur ne s’aligne pas avec le rapport de l’expert en sécurité, affirme que les propositions faites par celui-ci sont inacceptables, ferme les yeux sur certaines failles en supposant qu’elles ne peuvent pas être exploitées ou qu’elles ne sont pas critiques, etc.

Un cas pareil pour l’application Calibre, un logiciel d’e-book libre et open source, qui organise, enregistre et gère les e-books sur plusieurs formats a attiré note attention.

Plusieurs vulnérabilités ont été découvertes et soumises au développeur du projet dans « calibre SUID mount helper », pouvant entrainer la suppression de n’importe quel répertoire vide sur le système, la création des répertoires root, la création et la suppression de « user_controlled _dir/.created_ by_calibre_ mount_helper » n’importe ou sur le système de fichier, la possibilité d’exécuter n’importe quel programme comme root.

Au lieu d’essayer de travailler de commun accord avec celui ayant soumis le rapport, le développeur du projet trouve dans un premier temps que certaines vulnérabilités ne sont pas des failles de sécurité, ou qu’elles ne peuvent pas être exploitées. Bref qu’elles ne sont d'aucunes importance.

Ensuite, il trouve que les mesures d’atténuation proposées par celui-ci sont inacceptables, et que finalement la menace (qui permet à des utilisateurs sans privilèges d’avoir un accès root) n’est pas critique.

Une telle situation et le nombre d’applications dont les versions s’enchainent souvent avec des failles de sécurité qui avaient déjà été découvertes ou qui ont été corrigées uniquement dès lors que la vulnérabilité et la preuve de réalisation (PoC) ont été divulguées publiquement, nous pousse à nous demander comment le développeur prend-il en compte le rapport des failles sur son programme ? Comment les classifie-t-il et fait-il appel à celui ayant découvert la faille pour apporter un correctif ?

Le rapport de failles sur Calibre et les échanges avec le développeur du projet

Une erreur dans cette actualité ? Signalez-nous-la !

Avatar de pcdwarf
Membre éprouvé https://www.developpez.com
Le 22/02/2012 à 22:43
ça ne devrait pas être le cas mais la sécurité informatique est une affaire de compromis. Parfois c'est un compromis Performance/sécurité (rare) mais le plus souvent c'est un compromis Ergonomie/sécurité.

Les décideurs ont tendance à vouloir une sécurité à toute épreuve mais refusent de se soumettre à des contrôles contraignants.

Généralement on commence par demander une super porte blindée avec plusieurs serrures sécurités et alarmes. Et puis avec le temps on se rends compte que c'est quand même pénible de taper le digicode 20 fois par jours pour faire sortir ou rentrer le chat qui miaule devant la porte. Alors au bout de 6 mois on demande d'y ajouter une chattière.
17  0 
Avatar de kolodz
Modérateur https://www.developpez.com
Le 22/02/2012 à 18:21
Certes dans le cadre où l'utilisateur du "bug" est l'utilisateur de la faille.
Il est possible qu'une autre application/ utilisateurs utilise ce "bug" pour ses propre besoin...

Pour ce qui est de la sécurisation, il faut avoir les moyen de se la payer... Car cela se paye ! C'est des heures de d'architectures/développement/tests...

Il est probable qu'une bonne partie des sites internet qui tournent actuellement tombe sur une simple injection SQL... Sans parler des mots de passe sous le clavier ou en carton...

On a souvent l'analogie de l'informatique avec le bâtiment. Et bien souvent, il manque le budget serrure dans les services SI ou les projets. Il est déjà bien d'avoir un bon maçon !
Car on ne se plein pas de la sécurité d'une application qui ne fonctionne pas...

Cordialement,
Patrick Kolodziejczyk.

Note : Me semble bien ce projet opensource, même si je trouve le "Design by Centresource Interactive Agency" légèrement prétentieux pour le travail réalisé.
13  0 
Avatar de deathness
Membre émérite https://www.developpez.com
Le 23/02/2012 à 9:13
Citation Envoyé par ZeRevo Voir le message
C'est un manque de connaissance et pas d'imcompétence. Les informaticiens en général ne sont pas assez sensibilisé et formé à la sécurité.
Je suis assez d'accord. La plupart des personnes n'ont par exemple jamais eu de formation sur comment parer les attaques par injections SQL.

Alors qu'avec une simple formation d'une demi-journée une personne pourrait apprendre à parer les attaques les plus communes.

J'ai remarqué que bien souvent on nomme une personne experte en sécurité qui est chargé de la sécurité de tout le bordel, et on dit aux autre "vous en préoccupez pas c'est lui qui sait faire!"
7  0 
Avatar de pmithrandir
Expert éminent https://www.developpez.com
Le 23/02/2012 à 9:17
Si on résume, dans l'exemple, on peut :
- supprimer des dossiers vides : la belle affaire
- créer des dossier en root, mais on ne parle pas de création de fichier... pas vraiment super critique non plus (pas de pertes de données)

Ca vous parait prioritaire ? Au point de travailler des heures dessus, de risquer de tout casser, etc ?

Quand on voit que 80% des projets peuvent se permettre de ne pas être actif pendant 2 heures, que personne n'a besoin de les pirater(ce n'est ni un challenge, ni profitable), et qu'en 10 minutes on a remis une nouvelle vm toute propre pour supprimer les conneries introduites par un tiers...

Pourquoi travailler des heures pour sécuriser ce type d'application ?

A la rigueur, lorsque l'on permet de lire des fichiers, de creer des fichiers(ce qui permet entre autre de remplir le disque, ou de tester les fichiers existants), je comprends que ca soit chiant et dangereux, mais la on est sur du petit qui semble pas bien grave... surtout qui s'applique a un smartphone perso(ou ebook reader) donc sans grande conséquences...
9  2 
Avatar de ZeRevo
Membre averti https://www.developpez.com
Le 22/02/2012 à 23:10
C'est un manque de connaissance et pas d'imcompétence. Les informaticiens en général ne sont pas assez sensibilisé et formé à la sécurité.
8  2 
Avatar de alex_vino
Membre émérite https://www.developpez.com
Le 23/02/2012 à 0:09
Microsoft, Adobe, ... sont tous dans le meme cas, car parfois colmater une faille répercute des erreurs sur des fonctions sous-jacentes, tout a retester...

Cela coute beaucoup plus cher que développer, et puis aucun logiciel n'est parfait (non pas a cause des developpeurs mais a cause de la nature humaine qui est faite ainsi), donc ce qui est vrai aujourd'hui pourra etre faux demain.

Je ne connaissais pas ce logiciel, mais d'apres l'article c'est un mec seul qui l'a réalisé, alors bon je pense qu'il a aussi d'autes chat a fouetter, surtout que son application est gratuite. Je serais plutot de l'avis pour dire que c'est une faille dans le systeme d'exploitation.

Bon concernant les autres cas avérés je ne parle pas de Siemens, du FBI et encore moins de Symantec...
6  0 
Avatar de coshibe
Membre averti https://www.developpez.com
Le 23/02/2012 à 8:47
Citation Envoyé par pcdwarf Voir le message
Les décideurs ont tendance à vouloir une sécurité à toute épreuve mais refusent de se soumettre à des contrôles contraignants.

Généralement on commence par demander une super porte blindée avec plusieurs serrures sécurités et alarmes. Et puis avec le temps on se rends compte que c'est quand même pénible de taper le digicode 20 fois par jours pour faire sortir ou rentrer le chat qui miaule devant la porte. Alors au bout de 6 mois on demande d'y ajouter une chatière.
Les chatières, le fléau des développeurs. Quand on arrive à livrer une application aussi sécurisée que ce qu'ils demandent tres souvent on recoit un mail quelques mois plus tard parce que l'application est penible d'utilisation et qu'il faut alléger tout ca. Ou alors on nous appelle parce que l'application bug et on s'apercoit que l'utilisateur en voulant contourner la sécurité(qu'il avait demandé) a tout fait planter...

Donc après il faut voir les risques encourus en fonction des données de l'entreprise, son domaine , sa taille, prevoir une sauvegarde back up et aviser... Ce qui m'intéresserait c'est de connaitre le nombre d'entreprises victimes de telles attaques.
6  1 
Avatar de martopioche
Membre éclairé https://www.developpez.com
Le 23/02/2012 à 12:08
Pour rebondir sur certains commentaires, j'ai personnellement découvert Calibre il y a quelque mois quand je cherchais un outil pour gérer mes eBooks (pdf et ePub). Un collègue adepte des liseuses m'a après dit qu'il s'agissait d'une référence dans le domaine. Et il y a de quoi. Mis à part qu'il est écrit dans le meilleur langage au monde, Python évidemment , il est surtout assez bien pensé : fonctionnement par bibliothèques qui sont des arborescences de fichiers, des bases SQLite dédiées (donc vous voulez faire un backup ou un déplacement, vous ne déplacez que le répertoire), multiplateformes (Windows, Linux, MacOs, même une version portable - donc synchro des bibliothèques possible) mais surtout avec des installateurs dédiés (msi, dmg...), connectivité aux liseuses, même à iTunes, récupération des infos sur le web, serveur web embarqué...

Bref, c'est pas la promo que je veux en faire là, mais souligner qu'il y a un vrai boulot derrière, avec une animation de communauté (Facebook, Twitter, etc...).

Alor le projet en lui même est ouvert (sources dispo), et les contributeurs sont acceptés. Mais j'ai l'impression qu'il s'agit de contributions ponctuelles, et que l'auteur est le seul "régulier".

Comme certains l'ont souligné, on compare souvent notre métier d'"Informaticien" au "Batiment", mais autant on accepte qu'il y ai des maçons, des électriciens, des plombiers, autant on a du mal à voir cette granularité dans notre métier. Je n'ai pas lu les 110 échanges du bug en question. Mais il me semble que non seulement des correctifs ont été tenté, mais aussi également que l'auteur n'a pas forcément une vision des conséquences à ce niveau. Mais l'auteur de l'article aurai pu souligner que Calibre étant ouvert, n'importe qui peut soumettre un patch. Et j'ai bien eu l'impression en survolant les posts que beaucoup d'énergie à été dépensée à démontrer la faiblesse plutôt qu'à la patcher...

Bref, on ne peut pas dire que les failles ont été ignorées, mais pour les cas des logiciels ouverts, la question est plutôt : comment le développeur peut il (ou "devrait-il" gérer un cas qu'il ne sait pas faire...
5  0 
Avatar de Michaël
Expert éminent https://www.developpez.com
Le 22/02/2012 à 22:01
On a récemment trouvé une caisse complète de problèmes de sécurité sur un de nos outils métier... Parmi les meilleures : le compte sa de SQL Server sans mot de passe (avec une version ancienne plus supportée depuis belle lurette), mot de passe admin de l'appli en clair dans les fichiers, fichier de config (avec le mot de passe admin bien sûr) d'une autre société possédant la même appli (sympa pour aller casser leur outil métier ), etc

On a remonté les problèmes mais il n'y a pas eu plus de réaction que ça de leur part (et pourtant on les paye grassement )

Donc oui, ils (certains en tout cas) ignorent les "failles", même quand ce sont des gouffres de sécurité
2  0 
Avatar de abriotde
Membre chevronné https://www.developpez.com
Le 23/02/2012 à 11:58
La vérité c'est un problème de temps et de pressions externes. N'importe quel développeurs peut sécurisé son applis la tester à fond... à condition d'avoir le temps. En général on lui signale 5 problème par jours en plus des nouvelles demandes... Il est obligé de faire un choix alors la petites évols du casse pied passe en dernier et la faille de sécurité encore après. Surtout qu'il faut rappeler que corriger une faille de sécurité c'est risquer d'introduire des bugs et des mécontentements parce que "ça marche plus, il y a plus le bouton" alors qu'il à juste été décalé d'1 cm ou qu'il faut attendre 3 secondes de plus.
2  0