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 !

Android : des applications utilisant OpenSSL échappent à la faille HeartBleed
à cause d'un bug dans leur code source

Le , par Cedric Chevalier

0PARTAGES

1  1 
HeartBleed, c’est la nouvelle vulnérabilité critique qui fait parler d’elle en ce moment. Quoi de plus normal, puisqu’elle touche OpenSSL, une bibliothèque quasi universelle pour le chiffrement des données sur Internet.

Concrètement, il s’agit d’un dépassement de tampon (Buffer Overflow) qui affecte les versions 1.0.1 et 1.0.2 d’OpenSSL. Un hacker peut l’exploiter pour extraire des informations sensibles (clés privées par exemple) de la mémoire d’un serveur vulnérable.

L’inverse est aussi vrai. Autrement dit, un serveur compromis peut à son tour extraire les données sensibles de la mémoire des clients qui exécutent des versions vulnérables d’OpenSSL.

Dans une récente étude, le cabinet de sécurité Fire Eye estime que 150 millions d’applications Android téléchargées intègrent des versions vulnérables de la bibliothèque de chiffrement. Sauf qu’en pratique, certaines de ces applications ne sont pas du tout vulnérables à HeartBleed.

Un mystère que les experts du cabinet ont pu élucider. Ces applications contiennent un bug qui fait qu’elles utilisent les fonctionnalités de chiffrement natives de la plateforme de Google, et non celles de leur bibliothèque embarquée. Or, la bibliothèque native de la plateforme n’est pas vulnérable à HeartBleed. Comme quoi tous les bugs ne sont pas néfastes.

De plus, on note d’après Fire Eye que les applications Android les plus touchées sont les jeux et dans une moindre mesure les outils de productivité. Mais tout de même, dans l’ensemble, les développeurs réagissent bien face à HeartBleed. Le nombre d’applications vulnérables diminue de façon appréciable.

Source: Blog Fire Eye

Et vous ?

Avez-vous déjà été victime d'un bug "positif" comme celui-ci ?

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

Avatar de imikado
Rédacteur https://www.developpez.com
Le 26/04/2014 à 23:01
je pense avoir retrouvé
http://www.debian.org/security/2008/dsa-1571
2  0 
Avatar de rawsrc
Modérateur https://www.developpez.com
Le 25/04/2014 à 13:24
Citation Envoyé par Cedric Chevalier Voir le message
Comme quoi tous les bugs ne sont pas néfastes.
Toutafé : il est coutume de dire : "c'est un mal pour un bien"
0  0 
Avatar de imikado
Rédacteur https://www.developpez.com
Le 26/04/2014 à 15:17
J'ai mémoire d'un effet inverse: en croyant corriger un bug ça en a créé un:
En analysant le code source et voyant une variable non défini, la personne a défini cette variable (croyant corriger le problème) et en fait c'etait "fait exprès": le fait de ne pas initialiser la variable la mettait dans un etat "inconnu" nécessaire pour l'algo de chiffrage...

Mais ça c'est plutôt : le mieux est l'ennemie du bien
0  0 
Avatar de nirgal76
Membre chevronné https://www.developpez.com
Le 26/04/2014 à 16:10
Citation Envoyé par imikado Voir le message
J'ai mémoire d'un effet inverse: en croyant corriger un bug ça en a créé un:
En analysant le code source et voyant une variable non défini, la personne a défini cette variable (croyant corriger le problème) et en fait c'etait "fait exprès": le fait de ne pas initialiser la variable la mettait dans un etat "inconnu" nécessaire pour l'algo de chiffrage...

Mais ça c'est plutôt : le mieux est l'ennemie du bien
Faut plutôt revoir l'algo là (et les commentaires qui auraient dû prévenir en expliquant en peu). C'est du "poor programming" comme on dit chez nous.
0  0