Stagefright : ce que l'on sait de la faille qui permet de pirater Android via un simple MMS

Stagefright : ce que l’on sait de la faille qui permet de pirater Android via un simple MMS

Patch is not enough

Avatar de l'auteur
Vincent Hermann

Publié dans

Société numérique

28/07/2015 8 minutes
147

Stagefright : ce que l'on sait de la faille qui permet de pirater Android via un simple MMS

Un très sérieux problème de sécurité affecte actuellement la plupart des appareils sous Android. Une faille permet en effet de déclencher l’exécution d’un code arbitraire via un simple MMS. Et si un correctif existe, beaucoup risquent de passer à côté. On fait le point.

Les problèmes de sécurité ne sont pas rares sur Android, mais ils sont le plus souvent liés aux mauvaises manipulations des utilisateurs eux-mêmes. Le système mobile laisse le choix notamment d’installer des applications par d’autres sources que le Play Store, pavant la voie aux malwares contenus dans certains distributeurs bien peu scrupuleux. Mais cette fois, il est question d'un problème bien plus sérieux. Car un utilisateur peut voir son smartphone piraté sans qu’il ait besoin d’effectuer la moindre action.

Une faille dans Stagefright, responsable des contenus multimédias

La vulnérabilité réside dans Stagefright, une bibliothèque Android en charge de la lecture de certains formats multimédia. Elle a été trouvée par une équipe de chercheurs de Zimperium, qui indique qu’en raison des impératifs de performances au niveau du multimédia justement, le code est rédigé en C++, « plus souvent sujet aux corruptions de mémoire que les langages memory-safe tels que Java ».

Pour les chercheurs, qui ont trouvé la brèche en analysant le code d’Android via l’AOSP (Android Open Source Project), le problème serait le plus sérieux jamais découvert puisqu’il toucherait pas moins de 95 % des utilisateurs de la plateforme mobile. Zimperium, en se basant sur un chiffre d’un milliard d’appareils en circulation, estime donc que 950 millions d’entre eux sont vulnérables, les anciennes versions d’Android étant encore plus exposées.

Le problème de la bibliothèque Stagefright est qu’elle est appelée chaque fois qu’un contenu pris en charge est repéré. Il suffit par exemple qu’un simple MMS arrive sur un téléphone pour qu’elle commence à traiter la photo ou la vidéo qui y est contenue. L’utilisateur n’a pas besoin de réveiller son téléphone et d’aller lire le MMS en question, puisque le travail est effectué en amont.

Si un code particulier est intégré dans un cliché, Stagefright se charge de le lire et de le traiter, ouvrant alors la voie à un malware. Un autre scénario possible est la visite d’une page web spécialement conçue puisque la bibliothèque est appelée par d’autres applications pour lire les photos, vidéos, etc. Cela est donc loin de concerner seulement les outils de messageries.

stagefright

Facile à mettre en œuvre et à masquer

En fait, la faille ouvre tellement de portes qu’une attaque bien préparée pourrait ne laisser aucune trace. Selon les chercheurs, des pirates pourraient tout à fait préparer un MMS contenant à la fois le code d’un malware et une séquence d’instructions visant notamment à supprimer le message. L’utilisateur peut très bien avoir été piraté la nuit pendant qu’il dormait et ne pas trouver le moindre signe d’une activité suspecte à son réveil. C’est évidemment tout le danger : aucune action n'étant nécessaire.

En elle-même, la faille peut donner accès à un certain nombre de données, au minimum la pellicule photo, aux périphériques audio ainsi qu’au stockage externe (carte mémoire). Zimperium indique bien qu’une sandbox permet en théorie de bloquer ce type d’accès, mais les chercheurs insistent sur le peu d’étapes qu’une attaque aurait à accomplir pour s’affranchir de cette limite. Le problème est pire sur les anciennes versions d’Android car les privilèges accordés au code lu par Stagefright sont plus importants.

La faille est en fait décrite comme « pire que Heartbleed », puisque toutes les versions d’Android sont concernées à partir de la 2.2. Les moutures du système antérieures à la 4.3 sont les plus concernées car aucun mécanisme d’atténuation n’est présent dans le système.

Google a réagi rapidement, mais... 

Pourtant, Google a manifestement été très rapide à réagir, Zimperium remerciant d’ailleurs la firme pour sa promptitude. Les chercheurs ont fourni les explications ainsi que des patchs pour le code d’Android, que Google a analysés et intégrés dans son système en à peine 48 heures. Mais voilà, cela date de plusieurs mois puisque ces informations ont été envoyées en avril et en mai à Google. Le problème est donc connu depuis plus de trois mois.

Et le fait d’intégrer les correctifs dans le code d’Android n’est que la première d’une longue série d’étapes, car l’arrivée effective du patch sur les appareils mobiles prendra plus de temps. Selon Zimperium, seul le Nexus 6 est en partie protégé, sans qu'il soit précisé pourquoi. Sans doute parce qu’il possède une version plus récente d’Android, qui contient une correction partielle.

Les autres appareils Nexus n’ont pas encore été mis à jour, mais Google a indiqué à Forbes que les correctifs commenceraient à être déployés à partir de la semaine prochaine « dans le cadre d'une mise à jour de sécurité régulière ». On se demande par contre bien pourquoi le patch n'a pas été envoyé bien plus tôt, cette faille étant corrigée depuis plusieurs semaines.

Certains utilisateurs sont déjà protégés contre la faille de sécurité, en particulier ceux qui ont fait l’acquisition d’un Blackphone de SilentCircle, via la mise à jour 1.1.7 du système d’exploitation PrivatOS. Si le navigateur Firefox est également touché, la version 38 contient le correctif (la version actuelle étant la 39). 

Les utilisateurs de CyanogenMod 11 recevront une mise à jour ce week-end, mais les moutures 12 et 12.1 ne sont actuellement corrigées que dans les « nightlies ». Rien n'a par ailleurs été dit concernant CyanogenMod 10 et les versions antérieures. Pour les autres - et donc tous les dérivés d'Android - l’attente va être de rigueur et Zimperium encourage tous les acteurs fournissant des dérivés d’Android à prendre contact pour obtenir au plus vite des correctifs à implémenter.

... les correctifs n'arriveront que plus tard (ou pas du tout)

Pour les autres constructeurs justement, il n'y aura pas de salut tant que les correctifs ne seront pas prêts et surtout déployés sur l'ensemble des terminaux, et c'est bien là le problème. 

Google a indiqué dans un communiqué que les partenaires avaient été avertis et que des mises à jour seraient fournies « dans les prochaines semaines ou les prochains mois » sans plus de précisions. Et pour le moment, rares sont ceux qui ont communiqué sur la question, HTC  ayant été le seul à confirmer à Forbes que les correctifs étaient bien en cours de préparation.

Mais pour quels smartphones exactement ? Zimperium doute que les modèles âgés de plus de 18 mois seront mis à jour, et le niveau de fragmentation d'Android va dans le même sens. Une situation ubuesque puisque face à un souci de sécurité aussi important, les constructeurs ne comptent corriger le problème que par l'intermédiaire de nouveaux firmwares, et donc pour les appareils les plus récents. Si tel était le cas, on peut penser que les choses n'en resteront pas là, et que certaines associations de consommateurs pourraient prendre le relais.

Que faire en attendant ?

Car les solutions ne sont pas nombreuses pour ceux qui veulent se protéger d'ici une éventuelle mise à jour. Les utilisateurs peuvent désactiver dans les applications concernées le chargement automatique des photos et des vidéos, tout en s’assurant auprès de l’expéditeur qu’il s’agit d’un contenu légitime. Malheureusement, cela ne préviendra pas les autres scénarios d’attaque, particulièrement le fait de visiter une page web conçue pour exploiter la vulnérabilité. 

Des détails supplémentaires sur la faille (qui n'ont été partagés qu'avec Google en privé) seront dévoilés le 5 août lors de la conférence Black Hat, puis le 7 août à la DEF CON. Zimperium vient également de prévenir qu'une vidéo de démonstration serait publiée plus tard dans la semaine, et même qu'un code d'exploitation serait fourni à la Black Hat, en même temps qu'un patch en open source. Ce qui ne pourra qu'augmenter le sentiment d'urgence chez les utilisateurs et mettra un peu plus la pression sur les constructeurs.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Une faille dans Stagefright, responsable des contenus multimédias

Facile à mettre en œuvre et à masquer

Google a réagi rapidement, mais... 

... les correctifs n'arriveront que plus tard (ou pas du tout)

Que faire en attendant ?

Fermer

Commentaires (147)


Et voilà, encore une fois, le gros drame d’Android c’est que les failles sont rapidement corrigées, mais elles mettent du temps à être déployées vers les utilisateurs… voire elles n’arrivent pas du tout <img data-src=" />


+1…


Je ne serais jamais mis à jour, sur et certain.


Dans l’article on ne parle pas d’Hangout qui serait le principal vecteur de la faille, qui a tort ou raison la dessus ?




le problème serait le plus sérieux jamais découvert puisqu’il toucherait pas moins de 95 % des utilisateurs de la plateforme mobile. Zimperium, en se basant sur un chiffre d’un milliard d’appareils en circulation, estime donc que 950 millions d’entre eux sont vulnérables



La grosse vanne.



Déjà il faut que se soit Hangout qui gère les SMS/MMS et ce n’est pas l’application par défaut pour ceux-ci.



Il faut installer et lancer Hangout soit-même, quand ce dernier nous demande si on veut qu’il gère les SMS/MMS on à le choix de dire oui ou non et de garder l’application par défaut des SMS/MMS.



Ensuite je ne vois pas le rapport avec le patch d’une ROM puisque c’est simplement l’application qui gère les SMS/MMS qui est en cause.




Les utilisateurs de CyanogenMod 11 recevront une mise à jour ce week-end

Je ne pensais pas être concerné, cool qu’il y ait un suivi de sécurité. <img data-src=" />


C’est tout de même fou qu’aucune action ne soit nécessaire pour exécuter le code.

&nbsp;

Surtout quand on lit que l’exploitation de la faille peut s’être faite sans que l’on ne remarque quoique ce soit. <img data-src=" />



Et le problème risque de persister vu la politique de MàJ des constructeurs.

Cependant, la faille à l’air de se restreindre au stockage externe et aux photos, un moindre mal si on ne stocke pas de données sensible sur son tél ni de photo de soitounu! Bref une affaire à suivre de près.


D’où l’intérêt d’un Xiaomi, et du suivi des maj quasi hebdomadaires…


Hangouts aggrave le problème puisque la vidéo est automatiquement traitée, contrairement aux autres applications de messagerie qui traitent la vidéo uniquement lorsque l’utilisateur ouvre le MMS. Il est d’ailleurs possible que d’autres applis de messagerie “lisent” la vidéo avant que l’utilisateur n’ouvre le MMS. Le principal problème venant bien de la bibliothèque Stagefright qui comporte la faille.








Soltek a écrit :



La grosse vanne.



Déjà il faut que se soit Hangout qui gère les SMS/MMS et ce n’est pas l’application par défaut pour ceux-ci.



Il faut installer et lancer Hangout soit-même, quand ce dernier nous demande si on veut qu’il gère les SMS/MMS on à le choix de dire oui ou non et de garder l’application par défaut des SMS/MMS.



Ensuite je ne vois pas le rapport avec le patch d’une ROM puisque c’est simplement l’application qui gère les SMS/MMS qui est en cause.





Mais si c’est la bibliothèque Stagefright qui est chargée en amont, quelles que soit l’ apps qui est par la suite (Hangout ou SMS/MMS stock) les conséquence sont les mêmes non ?&nbsp; <img data-src=" />



Tu es sûr de ça ? Il n’est mentionné nul part que seul hangout utilise cette bibliothèque. Il est juste dit que certains types de contenus sont gérés par cette bibliothèque, donc peut importe le support sur lequel on le regarde (type de navigateur ou type de messagerie) c’est le média en lui même le problème. Ou alors la news est incomplète. Ou alors j’ai raté un passage.








mononokehime a écrit :



Dans l’article on ne parle pas d’Hangout qui serait le principal vecteur de la faille, qui a tort ou raison la dessus ?









Soltek a écrit :



La grosse vanne.



Déjà il faut que se soit Hangout qui gère les SMS/MMS et ce n’est pas l’application par défaut pour ceux-ci.



Il faut installer et lancer Hangout soit-même, quand ce dernier nous demande si on veut qu’il gère les SMS/MMS on à le choix de dire oui ou non et de garder l’application par défaut des SMS/MMS.



Ensuite je ne vois pas le rapport avec le patch d’une ROM puisque c’est simplement l’application qui gère les SMS/MMS qui est en cause.





Cela ne touche pas que Hangout, puisque ce n’est pas la seule application à exploiter&nbsp;Stagefright, c’est pour ça que même si l’exemple du MMS est le plus parlant, ce n’est pas le seul vecteur d’attaque. Le billet de Zimperium ne fait d’ailleurs pas référence à cette app en particulier.



J’allais le dire: merci pour le résumé! <img data-src=" />


Je viens de recevoir un push d’une MAJ logicielle sur mon galaxy, mais certainement pas de rapport (ça arrive de temps en temps, à chaque fois dans les 500Mo, et sans upgrade de l’OS)


Ouais et la seule solution pour l’instant est :



Remediation:

Zimperium’s advanced Enterprise Mobile Threat Protection solution, zIPS, protects its enterprise customers from Stagefright vulnerability.

Ça tombe bien hein <img data-src=" />


De mon point de vue c’est une “excellente nouvelle”.&nbsp;

&nbsp;

On va enfin voir comment l’écosystème Android va réagir à une vraie faille grave et exploitable simplement …&nbsp;

&nbsp;

Est ce que les OEM pourront se contenter de dire “oh apres 18 mois on s’en fout”&nbsp;

Est ce que les opérateurs vont réagir en forcant les OEM à publier au plus vite une update ?&nbsp;

Est ce que les opérateurs pourraient “pousser une sorte d’antimalware” dans les flux MMS ?&nbsp;

&nbsp;

On va enfin pouvoir voir si Google dans ce genre de sénario potentiellement déstructeur “tient” l’écosystème Android …

&nbsp;

De mon point de vue, ça peut être l’équivalent de “Blaster” chez Microsoft (un impact utilisateur réel et grave, qui a poussé Ms à mettre en place plus de sécurité dans son OS).








Soltek a écrit :



Ouais et la seule solution pour l’instant est :



Remediation:

Zimperium’s advanced Enterprise Mobile Threat Protection solution, zIPS, protects its enterprise customers from Stagefright vulnerability.

Ça tombe bien hein <img data-src=" />







Eteindre son téléphone est aussi une bonne solution



Si on désactive la récupération automatique des MMS ça change quelque chose ?








Douflou a écrit :



.









M3t3or a écrit :



.









Cwoissant a écrit :



.









David_L a écrit :



.





Oui merci de m’avoir corrigé ! M’enfin c’est quand même drôle que d’après leur billet il soit les seuls à pouvoir délivrer (vendre) une solution.







Tchekoto a écrit :



Si on désactive la récupération automatique des MMS ça change quelque chose ?





Si tu ne récupères jamais le MMS en question oui du coup ça ne te fera rien.









David_L a écrit :



Cela ne touche pas que Hangout, puisque ce n’est pas la seule application à exploiter&nbsp;Stagefright, c’est pour ça que même si l’exemple du MMS est le plus parlant, ce n’est pas le seul vecteur d’attaque. Le billet de Zimperium ne fait d’ailleurs pas référence à cette app en particulier.



Ouais mais a ce moment la, il doit etre possible de fournir une version particulière &nbsp;de la lib avec l’application au lieu d’utiliser celle du systeme, non?



Je pense que pour qu’une réaction apparaisse, il faudrait que la faille soit exploitée et que les utilisateurs montrent leur mécontentement.



Mais je suis d’accord sur le fait que ça serait bien que les choses bougent.


Pour ce genre de problème, c’est pas jouable que Google pousse les MAJ directement plutôt que de passer par les OEM?&nbsp;


Ca ne te fera rien, tant que le vecteur utilisé est le MMS (qui est pour le coup, le plus simple et le plus répendu).

&nbsp;

La librairie est utilisée dans différentes parties de l’OS, donc ça veux dire que le vecteur peut être une app, une pub, une personne qui te contacte par Hangout en direct, ou par Telegram …&nbsp;

&nbsp;

D’ailleurs je me demande si le fait que Google n’ait pas encore trop “publié le patch”, ne pourrait pas être pour éviter de trop attirer l’attention sur la faille, le temps que les OEM publient des patch …&nbsp;

&nbsp;

&nbsp;Tout comme avec Blaster, c’est la diffusion du patch qui avait permis aux hacker d’identifier la source de la faille de sécurité.


Ca sent le futur gros spam via MMS avec gros générateur de numéro de téléphone ça <img data-src=" />








boglob a écrit :



Eteindre son téléphone est aussi une bonne solution





Non.

Quand tu le rallumeras, genre pour téléphoner, tu seras hacké.



Si les OEM ne réagissent pas, la faille sera exploitée, c’est une certitude … je prend un exemple : les personnes qui ont un téléphone Android mais sans data (j’ai une tante qui est dans cette configuration).&nbsp;

&nbsp;

&nbsp;Elle n’aura pas le correctif (vu qu’elle ne se connecte jamais au web), mais sera une cible parfaite pour la faille de sécu.

&nbsp;

&nbsp;Et il suffit de faire quelques appels vers un numéro surtaxé et il y a du gros pognon à se faire …

&nbsp;

&nbsp;Et dans ce cas, qui est résponsable ? Ma tante de ne pas avoir mis de mise à jour (si elle existe ?), l’OEM de ne pas avoir mis à dispo le correctif, ou l’opérateur qui n’a pas “sécurisé son reseau” ?&nbsp;




Les utilisateurs peuvent désactiver dans les applications concernées le

chargement automatique des photos et des vidéos, tout en s’assurant

auprès de l’expéditeur qu’il s’agit d’un contenu légitime.



&nbsp;

&nbsp;Quelqu’un pourrait expliquer comment faire cela?

&nbsp;Ce serait utile de rajouter cette info dans la news.

&nbsp;



&nbsp;Bon par contre, ça confirme qu’android est une grosse faille à lui tout seul.

&nbsp;

Mon prochain tel sera donc soit un BB soit un firefoxOS soit un autre système un peu plus sécurisé. Pas le choix au final.








Konrad a écrit :



Et voilà, encore une fois, le gros drame d’Android c’est que les failles sont rapidement corrigées, mais elles mettent du temps à être déployées vers les utilisateurs… voire elles n’arrivent pas du tout <img data-src=" />





+1

Politique merdique de du système de “ROM” monobloc unique pour chaque modèle. Je ne comprend pas comment android est incapable de faire ce que font Windows et n’importe quelle distrib Linux depuis des décennies, une seul version pour n’importe quel modèle d’appareil (modulo l’architecture processeur : X86).







FunnyD a écrit :



Je ne serais jamais mis à jour, sur et certain.







Le problème, c’est qu’en ville, les signaux de fumée, ça ne passe pas très bien, ça a une mauvaise réception. Et je ne parle pas dans le métro. Et tu es aussi tout le temps emmerdé par les mecs qui se disent malade à cause des signaux de fumée.



Tout OS a des failles … aucun OS n’est épargné …&nbsp;

Le bug de SMS de Windows Phone (crash à la récéption de SMS), et celui de IOS (SMS avec carractére spécial =&gt; crash en boucle), sont juste l’étape 1 avant d’identifier une faille de sécu dans l’OS.&nbsp;

&nbsp;

&nbsp;Si tu ne veux pas un OS avec une faille de sécurité, ne prend pas de téléphone&nbsp;<img data-src=" />


En espérant que BB ne fasse pas que du Android mais continue à faire du BB OS&nbsp;<img data-src=" />








atomusk a écrit :



Tout OS a des failles … aucun OS n’est épargné …&nbsp;

Le bug de SMS de Windows Phone (crash à la récéption de SMS), et celui de IOS (SMS avec carractére spécial =&gt; crash en boucle), sont juste l’étape 1 avant d’identifier une faille de sécu dans l’OS.&nbsp;

&nbsp;

&nbsp;Si tu ne veux pas un OS avec une faille de sécurité, ne prend pas de téléphone&nbsp;<img data-src=" />





C’est ce que j’allais dire : tout produit comporte des failles. L’important c’est surtout de voir comment et avec quelle rapidité elles sont corrigées.



Sachant que sans forfait Data, le MMS ne peux pas être récupéré, aucun soucis de ce côté.

Je prend aussi en estime qu’elle ne téléchargera pas d’application “bizarre”.


Et quand ton FirefoxOS sera l’OS mobile le plus répandu ça sera lui le moins sécurisé.



Non parce qu’aucun n’est plus sécurisé qu’un autre, c’est juste qu’on cible le plus gros marché hein.








atomusk a écrit :



Tout OS a des failles … aucun OS n’est épargné … 

Le bug de SMS de Windows Phone (crash à la récéption de SMS), et celui de IOS (SMS avec carractére spécial =&gt; crash en boucle), sont juste l’étape 1 avant d’identifier une faille de sécu dans l’OS. 

 

 Si tu ne veux pas un OS avec une faille de sécurité, ne prend pas de téléphone <img data-src=" />





Oui c’est sur, mais le problème va venir plutôt de la politique de mise à jours.



C’est la fameuse “Tata Jeanine”?&nbsp;<img data-src=" />


Le souci est comment savoir si son téléphone Android a été patché avec le correctif.

Mon Galaxy S4 a reçu récemment une mise à jour Lollipop mais le correctif y est-il présent ? Peut-on voir dans une release note quelconque si le correctif est présent ?


Et si on poussait le patch par MMS en utilisant la vulnérabilité, justement ?

Soigner le mal par le mal, c’est-y pas joli ?


Atta, je t’envoie un message, rien ne vaut la vérification par le test <img data-src=" />


Ça serait de toute beauté&nbsp;<img data-src=" />








atomusk a écrit :



&nbsp;Si tu ne veux pas un OS avec une faille de sécurité, ne prend pas de téléphone&nbsp;<img data-src=" />





Je crois que je vais y venir à force. <img data-src=" />









Soltek a écrit :



Et quand ton FirefoxOS sera l’OS mobile le plus répandu ça sera lui le moins sécurisé.



Non parce qu’aucun n’est plus sécurisé qu’un autre, c’est juste qu’on cible le plus gros marché hein.





Vais créer mon propre OS alors.

&nbsp; Avec un seul utilisateur, les risques seront fortement réduits du coup.&nbsp;<img data-src=" />



<img data-src=" /> Les forfaits sans data peuvent recevoir des MMS si le téléphone est compatible… les opérateurs font très bien la différence entre un message multimédia et de la “simple donnée”.

D’autant qu’il existe encore de forfait sms/mms et sans data.



C’est surtout que les gens sans data ont des téléphones qui supportent pas les MMS.


Ce serait tellement beau ! Mais il faudrait un moyen d’élever les privilèges depuis la faille. Il en faut une autre !


Ptain une faille pareille :&nbsp; on dirait Windows des années 90 <img data-src=" />, en plus c’est une attaque de destruction ultra massive ( pas moins de 95 % des utilisateurs )

&nbsp;

&nbsp;Bon espérons qu’un correctif sera rapidement déployé…Attend….Bah mince j’ai oublié qu’on parle d’Android là <img data-src=" />


L’article indique que si on a Firefox &gt; 38, on est protégé… Cela veut-il dire qu’installer FF upgrade la lib en question ? Ca, tout le monde peut le faire !

&nbsp;








atomusk a écrit :



Si tu ne veux pas un OS avec une faille de sécurité, ne prend pas de téléphone&nbsp;<img data-src=" />

&nbsp;







&nbsp;Si si tu peux avoir un téléphone avec un os sans faille de sécurité :

&nbsp;

&nbsp;http://www.amazon.fr/OPIS-60s-CABLE-t%C3%A9l%C3%A9phone-vintage/dp/B00859RGJG/re…

&nbsp;



&nbsp;Ma mère a toujours le sien, plus de 30 ans et il marche ! lol

&nbsp;

&nbsp;edit&nbsp; : sinon j’ai un vieu nokia symbian (?)

&nbsp;

le truc que plus personne n’a ou n’utilise donc je suis peinard lol :)



C’est sur que les téléphones blackberry sous Blackberry OS 7 qui n’ont jamais été mis à jour à BB10 sont la preuve que BB est irréprochable sur les MAJ&nbsp;<img data-src=" />

&nbsp;

Par exemple :&nbsphttp://www.gsmarena.com/blackberry_9720-5625.php (sorti en Aout 2013)


Il y a faille et faille hein..

&nbsp;

N’essaies pas de les mettre toutes au même niveau.. De ce que je viens de lire, là c’est nettement plus grave.

&nbsp;

D’autant plus que sur les autres plateformes, les correctifs sont rapidement déployés ( Enfin je ne sais pas trop pour windows phone/8)








tazvld a écrit :



+1

Politique merdique de du système de “ROM” monobloc unique pour chaque modèle. Je ne comprend pas comment android est incapable de faire ce que font Windows et n’importe quelle distrib Linux depuis des décennies, une seul version pour n’importe quel modèle d’appareil (modulo l’architecture processeur : X86).







Le problème, c’est qu’en ville, les signaux de fumée, ça ne passe pas très bien, ça a une mauvaise réception. Et je ne parle pas dans le métro. Et tu es aussi tout le temps emmerdé par les mecs qui se disent malade à cause des signaux de fumée.



Acer Liquid MT <img data-src=" />





linkin623 a écrit :



<img data-src=" /> Les forfaits sans data peuvent recevoir des MMS si le téléphone est compatible… les opérateurs font très bien la différence entre un message multimédia et de la “simple donnée”.

D’autant qu’il existe encore de forfait sms/mms et sans data.



C’est surtout que les gens sans data ont des téléphones qui supportent pas les MMS.





il parait que je peux recevoir des MMS, ca n’a jamais marché <img data-src=" />



En effet, il y a faille et faille, et le fait que Android est Open Source facilite franchement le travail de la personne qui veux transformer un “crash quand j’envoi une image mal formée” en “super faille de sécurité”.

&nbsp;

&nbsp;Aussi encore une fois, tout OS a des failles, et prétendre le contraire, c’est prêter le flan à beaucoup de railleries …&nbsp;

&nbsp;

&nbsp;ps: attendons de voir comment les OEM géreront les correctifs avant de juger.

&nbsp;Et je serai pas contre un petit article avec la liste des mauvais eleves chez les OEM qui n’ont pas déployé le correctif à temps … et si même Google publiera le correctif sur les “anciens Nexus”.








atomusk a écrit :



C’est sur que les téléphones blackberry sous Blackberry OS 7 qui n’ont jamais été mis à jour à BB10 sont la preuve que BB est irréprochable sur les MAJ <img data-src=" />

 

Par exemple :&#160http://www.gsmarena.com/blackberry_9720-5625.php (sorti en Aout 2013)





A j’ai pas dis le contraire. Encore que la, la différence c’est que BB c’est quoi ? 1% des smartphone dans le monde. Android c’est quoi ? 80% ?.







the true mask a écrit :



Ptain une faille pareille :  on dirait Windows des années 90 <img data-src=" />, en plus c’est une attaque de destruction ultra massive ( pas moins de 95 % des utilisateurs )





la première décennie des années 2000 plutôt.









DotNerk a écrit :



Pour ce genre de problème, c’est pas jouable que Google pousse les MAJ directement plutôt que de passer par les OEM?







Je ne crois pas non. Les ROM étant faites et compilées pour un modèle par les constructeurs, seul les constructeurs ont ne serait-ce qu’un début de “main” sur les maj. Mais le problème s’ajoute lors de maj majeur qui necessite le flashage de la ROM, c’est le fait que l’opérateur entre en jeu, et il faut attendre que l’opérateur (modifie et) publie une ROM pour ton modèle.







js2082 a écrit :



Quelqu’un pourrait expliquer comment faire cela?

 Ce serait utile de rajouter cette info dans la news.

 



 Bon par contre, ça confirme qu’android est une grosse faille à lui tout seul.

 

Mon prochain tel sera donc soit un BB soit un firefoxOS soit un autre système un peu plus sécurisé. Pas le choix au final.





J’ai vraiment l’impression que depuis le début, Android est le projet de personnes spécialisé sur l’interface utilisateur mais vraiment des tanches (ça reste relatif disons) en développement.

J’avais cru lire il y a quelques années aussi que de base, selon un ancien développeur, les cascade d’événement derrière le déclenchement d’une actions était d’un tel bordel qu’une interface Android aura toujours un énorme lag.









tazvld a écrit :



Android aura toujours un énorme lag





28 juillet 2015, toujours le même discours <img data-src=" />

Y’a pas que des Wiko à 50 balles sur Android hein.

Et pas non plus besoin d’un truc à 600 boules pour que se soit fluide (Moto bonjour).









NMP a écrit :



L’article indique que si on a Firefox &gt; 38, on est protégé… Cela veut-il dire qu’installer FF upgrade la lib en question ? Ca, tout le monde peut le faire !

&nbsp;





Non, ça veut juste dire que FF bloque la faille au niveau de son application (ou n’utile plus StageFright), il ne corrige pas le problème.









Soltek a écrit :



Y’a pas que des Wiko à 50 balles sur Android hein.



nan, ya aussi Archos! ^^

Mon appareil a 11 mois, j’attends toujours la maj 4.4 promise avant qu’il sorte (ya 11 mois)…



En même temps si tu achètes Archos… Tu devais bien savoir à quoi t’attendre non ?


Ne pas proposer de patch (pour les terminaux plus vieux que 18 mois) ne pourrait-il pas être assimilié à de l’obsolescence programmée ?

&nbsp;

Eh bien non : “L’obsolescence programmée se définit par l’ensemble des techniques

par lesquelles un metteur sur le marché vise à réduire délibérément la

durée de vie d’un produit pour en augmenter le taux de remplacement.”



A moins qu’on arrive à démontrer que la faille de sécurité est délibérée, même avec cette super nouvelle loi, il n’y a aucune obligation de la corriger… Alors autant la laisser et conseiller aux consommateurs de s’acheter un nouveau smartphone…

&nbsp;

C’est de l’obsolecense devenue programmée en cours de route, c’est très différent de l’obsolecense initialement programmée, si si !


Reste à savoir si les utilisateurs seront massivement informés.



Si seulement 20% des utilisateurs sont informés (soit 190 millions, selon l’estimation donnée du nombre d’appareils), cela suffira déjà à bien faire entendre la grogne. Sinon, ça passera comme une lettre à la poste.



Si l’info reste chez NXI, sans être relayée dans les médias (TV + journaux), il se peut qu’il ne se passe quasiment rien…








Soltek a écrit :



28 juillet 2015, toujours le même discours <img data-src=" />

Y’a pas que des Wiko à 50 balles sur Android hein.

Et pas non plus besoin d’un truc à 600 boules pour que se soit fluide (Moto bonjour).





L’article que je te parles a 3ans, et en gros, de ce que je me rappelle, le gars disait que le lag sera toujours relativement important par rapport à la puissance de l’appareil et comme les erreurs sont pratiquement au cœurs de l’OS, il serait très difficile de les réparer. Depuis, cette époque, à l’age d’or du galaxy S2, le S3 allé être annoncé, les téléphones ont bien évolué, et même le Wiko à 50 boules est au moins aussi puissant que le S2.



Mais bon, toujours est-il, c’était pour illustrer le fait que le projet Android a du être fait par des personnes qui était avant tout spécialisé dans l’interface utilisateur. Déjà à la version 1.6, 1ère version officiel de l’OS, l’interface était très bonne et pratiquement tout était déjà là (je crois qu’il y avait déjà le volet de notification et même le multitâche). Mais derrière, ce ne semblait pas être d’excellent développeur.









Bob le Moche a écrit :



Non, ça veut juste dire que FF bloque la faille au niveau de son application (ou n’utile plus StageFright), il ne corrige pas le problème.





Justement, il semble que non, c’est assez étant si on regarde les modification de code dans FF Android sur le dépôt&nbsp;https://hg.mozilla.org/mozilla-central/log?rev=stagefright ya plusieurs corrections dans la bibliothèque stagefright qui semble incluse concernant des overflow qui nécessite des permissions spéciale afin de consulter le rapport de bug (les diff restent accessible)

&nbsp; &nbsp;

&nbsp;









Soltek a écrit :



En même temps si tu achètes Archos… Tu devais bien savoir à quoi t’attendre non ?





Ouais, un produit pas cher mais fiable.

J’ai déjà eu une tablette, + mon actuelle. Donc je connaissais le matos.



Après, il s’agissait de promesses à la sortie du matos…









kyrios123 a écrit :



Ne pas proposer de patch (pour les terminaux plus vieux que 18 mois) ne pourrait-il pas être assimilié à de l’obsolescence programmée ?

Eh bien non



J’y ai pensé, en effet.

Mais ne pas corriger une faille critique…

Windows a une durée de support, quid d’android et des constructeurs?



Pourquoi ne pas distribuer le hotfix en exploitant la faille ? Ca aurait du style et ça limiterait la casse vite et bien (950 millions de targets potentielles justifierait cette méthode).


+10


J’imagine les MMS de 50Mo&nbsp;<img data-src=" />

&nbsp;








pmiam999 a écrit :



Pourquoi ne pas distribuer le hotfix en exploitant la faille ? Ca aurait du style et ça limiterait la casse vite et bien (950 millions de targets potentielles justifierait cette méthode).





Parce que personne ne voudra payer l’envoi de 950 millions de MMS&nbsp;<img data-src=" />



tu fais crasher la lib juste pour lancer le script qui récupères le patch et l’applique, un bon programmeur doit pouvoir faire tenir ça dans un SMS ;)


Et si le MMS ouvre le lien pour télécharger la mise à jour?&nbsp;<img data-src=" />


c’est pas plus bête que laisser pourrir des millions de devices vérolés qui vont rejoindre un botnet tôt ou tard

&nbsp;

Edit: surtout si tu as 95% du parc vulnérable et qu’il faut 0 action pour prendre la main dessus. Il y a urgence.


Je ne suis pas un expert dans le domaine, mais pour moi, le but d’une ROM est justement de rendre impossible la mise à jour d’une partie de code sans passer par la phase “flashage”.&nbsp;

&nbsp;

&nbsp;Donc ça passerai de toute façon par la création d’un “patch” adapté à la plateforme, signé, validé & co.&nbsp;

&nbsp;

&nbsp;Donc, de mon point de vue, n’apporterai sans doute pas grand chose.


Erf, avec mon Galaxy Note de première génération qui n’a pas été updaté depuis la 4.1.2 je n’ai donc plus qu’à essayer de désactiver la réception de MMS et dire à mes contacts que ça ne sert plus à rien de m’en envoyer … WTF ?!?


Alors, sauf erreur de ma part, depuis Kitkat, il est possible de mettre à jour à la volée une lib système sans flasher l’intégralité du système. Pour les versions précédentes (et vulnérables) par contre …


Non, tu désactive le téléchargement auto des MMS, pas que tu els bloques, tu pourras toujours les lire si tu le souhaite.


Merci pour la réf.



Ce qui m’épate aussi, c’est la manière dont un fichier “neutre” peut embarquer du code, qu’il soit bienveillant ou malveillant.

Je m’explique : je prends le cas d’une image Bitmap car c’est simple à expliquer, mais bien sûr ça s’applique pour tout format d’image, de vidéo, etc.

Une image bitmap c’est une suite d’octets, groupés 3 par 3. Chaque groupe de 3 octets permettent de coder la couleur d’un pixel, et les groupes se suivent comme les pixels de la ligne 1 puis 2, etc. L’algorithme qui va interpréter le fichier va prendre ces groupes d’octets, les décoder, colorier un pixel puis passer au suivant.



Comment peut-on inclure du code là-dedans ?? Pourquoi les algorithmes de traitement d’images ont-ils toujours été sujets aux failles ??








Muageto a écrit :



Erf, avec mon Galaxy Note de première génération qui n’a pas été updaté depuis la 4.1.2 je n’ai donc plus qu’à essayer de désactiver la réception de MMS et dire à mes contacts que ça ne sert plus à rien de m’en envoyer … WTF ?!?





QUOI?! Je ne suis pas le seul à encore l’utiliser?! \o/

(bon sauf que je suis passé à CM donc j’ai une ROM équivalente à une 4.3.1, mais de là à avoir la mise à jour, pas gagné sans passer par une autre ROM encore plus alternative…)



Ca vous appendra à utiliser des logiciels dits libres dans le cas d’Android <img data-src=" />


parler d’android et de sécurité… moui moui


Dans Hangouts, j’ai désactivé le rapatriement automatique des mms. Donc, normalement, je ne devrais pas avoir à m’en faire je pense.








Drepanocytose a écrit :



Et si on poussait le patch par MMS en utilisant la vulnérabilité, justement ?

Soigner le mal par le mal, c’est-y pas joli ?





J’aime le principe. <img data-src=" />



Je ne comprends pas pourquoi Google ne puisse pas déployer directement les correctifs sur les appareils comme le fait MS sur windows , et ce quelque soit le fabricant de la machine.

Parce que bon, je veux bien croire en l’excuse d’Open source pour justifier tous les défauts , mais quand ça devient aussi problématique il faut quand même revoir un peu le modèle.



D’autant plus qu’Android vise aujourd’hui majoritairement le grand publique, pour qui le coté gratuit et Open Source de l’OS n’est pas transparent et ne veut absolument rien dire* et pour qui aussi l’exploitation de ce genre faille ne pardonne pas.



Bref un suivi et un entretien minimum me semble quand même nécessaire (que soit de la part de Google et/ou des OEM)



* Je veux dire par là Ils ne vont pas s’amuser à rooter leurs appareils et une marque comme samung par exemple ne va pas s’amuser à casser les prix des appareils juste parce que l’OS et gratuit et Open Source


L’Open Source n’a strictement rien avoir ici. C’est simplement que Google n’a pas la main sur les mises à jours des smartphones des constructeurs.


CM 12.1 marche du feu de dieu sur un Note première génération :



http://forum.xda-developers.com/galaxy-note/development/rom-t2938649


Bah l’argument que je lis souvent sur l’absence de mis à jours des constructeurs est justement le fait qu’Android soit open source. Par conséquent tout le monde et principalement les constructeurs ont le droit de le modifier, de ne pas déployer les mis à jours etc…

Peut être que ça n’a rien à voir , mais ça a quand même l’air d’être employé comme motif pour justifier tout et n’importe quoi.


Cool, j’avais regardé à l’époque des CM11 et le Note ne faisait presque jamais partie des tél compatibles. Va falloir que je teste ça un de ces quatre du coup (de toute manière, au point où mon tél en est, au pire ça précipitera son renouvellement, au mieux ça me permettra d’attendre encore un peu&nbsp;<img data-src=" /> )


est ce qu’avoir un téléphone en x86 change quelque chose? y’a t’il un patch via xposed?


pour moi le plus gros défaut, c’est qu’il faut “donner la possibilité à Google de le faire”.

&nbsp;

Donc, potentiellement permettre à Google d’avoir une clé de signature “maitre” qui fonctionne sur 100% des téléphones, et du coup, donner à Google la possibilité de modifier la ROM de tous les mobiles du marché.

&nbsp;

J’imagine que certains trouveraient la perspéctive terrifiante&nbsp;<img data-src=" />

&nbsp;

Sans compter le fait que les OEM seraient encore plus tenté de dire : ah non, on ne fait pas de mise à jour, vu que les MAJ de sécurité sont géré gracieusement par Google&nbsp;<img data-src=" />

&nbsp;

&nbsp;Pour moi, la meilleure solution :&nbsp;&nbsp;identifier les constructeurs mauvais élèves, et ne plus jamais acheter du matos chez eux …

&nbsp;

&nbsp;Il n’y a que comme ça qu’on poussera les constructeurs a faire leur taff.








Nozalys a écrit :



Ce qui m’épate aussi, c’est la manière dont un fichier “neutre” peut embarquer du code, qu’il soit bienveillant ou malveillant. (…)

Comment peut-on inclure du code là-dedans ?? Pourquoi les algorithmes de traitement d’images ont-ils toujours été sujets aux failles ??





Exemple stupide, mais illustratif :

Ton programme est fait pour gérer des lignes de 1980 pixels, soit 5940 octets. Parce que tu est un peu fainéant (inutile de nier!), tu as mis cette valeur en dur dans le code à l’endroit où tu alloues la mémoire permettant de cpier une ligne. Sauf que comme tu es étourdis (cumulard!), tu as oublié de mettre le test qui interdit d’ouvrir des images de plus de 1980 pixels de larges.

Du coup, quand quelqu’un essaies d’ouvrir une image de 3000 pixels, des données sont copiées en dehors de la zone prévue. Si tu n’as pas de chance, c’est à un endroit sensible, par exemple l’endroit où sont stoquées les prochaines instructions qu’exécutera le processeur. La plupart du temps, le programme (voire le système) va lamentablement crasher, sans grand dommage. Mais si l’image ouverte est soigneusement étudiée pour que ces données qui débordent aient un sens pour le processeur, ça peut faire très mal.



Bon en vrai c’est un peu plus subtil que ça, il y a des tas de protection du système à contourner, mais ça donne une idée du principe.









atomusk a écrit :



pour moi le plus gros défaut, c’est qu’il faut “donner la possibilité à Google de le faire”.

 

Donc, potentiellement permettre à Google d’avoir une clé de signature “maitre” qui fonctionne sur 100% des téléphones, et du coup, donner à Google la possibilité de modifier la ROM de tous les mobiles du marché.

 

J’imagine que certains trouveraient la perspéctive terrifiante <img data-src=" />

 

Sans compter le fait que les OEM seraient encore plus tenté de dire : ah non, on ne fait pas de mise à jour, vu que les MAJ de sécurité sont géré gracieusement par Google <img data-src=" />

 

 Pour moi, la meilleure solution :  identifier les constructeurs mauvais élèves, et ne plus jamais acheter du matos chez eux …

 

 Il n’y a que comme ça qu’on poussera les constructeurs a faire leur taff.







Autre solution : que Google ajoute une condition à l’utilisation d’Android OHA, « obligation de propager les mises à jour de sécurité sur vos Android pendant au moins 2 ans » (par exemple).



Il y a un constructeur qui ait été régulièrement bon élève sur ce sujet?

Tout ceux que j’ai un peu regardé m’ont bien déçu. C’est les iPhones et Lumias qui me paraissent les meilleurs en la matière, et de loin, ce qui est assez paradoxal par rapport à ce que devrait permettre l’open source.








atomusk a écrit :



&nbsp;

J’imagine que certains trouveraient la perspéctive terrifiante&nbsp;<img data-src=" />





&nbsp;Un peu plus ou un peu moins de la part de Google… Ils récupéraient déjà les credentials wifi avec leurs Google Cars et récemment le bug “du micro” <img data-src=" />



Autre solution : que Google passe à iOS.

&nbsp;



Master troll <img data-src=" />








DotNerk a écrit :



Un peu plus ou un peu moins de la part de Google… Ils récupéraient déjà les credentials wifi avec leurs Google Cars et récemment le bug “du micro” <img data-src=" />







Pas besoin de parler au passé. Parmi les informations stockées dans le Cloud de Google, il y a les mots de passe des réseaux WiFi auxquels tu t’es connecté. Si tu changes de téléphone, il suffit de te resynchroniser avec ton compte Google et hop ! Tous tes mots de passe WiFi sont restaurés, tu n’as pas besoin de les renseigner.



Du coup, ça veut dire qu’une grande partie des mots de passe WiFi du monde sont stockés chez Google…



Google knows nearly every Wi-Fi password in the world









M_Michu a écrit :



Bah l’argument que je lis souvent sur l’absence de mis à jours des constructeurs est justement le fait qu’Android soit open source. Par conséquent tout le monde et principalement les constructeurs ont le droit de le modifier, de ne pas déployer les mis à jours etc…

Peut être que ça n’a rien à voir , mais ça a quand même l’air d’être employé comme motif pour justifier tout et n’importe quoi.





Je pense pas. Les constructeurs doivent approuver les termes et conditions pour intégrer Android sur leurs mobiles de manière normale. Et Google pourrait très bien imposer certaines règles en terme de mise à jours. Ils ne l’ont pas fait pour laisser le maximum de liberté aux constructeurs et je pense aussi pour ne pas trop se compliquer la vie (ils n’ont pas à faire de maintenance).



Le problème serait le même avec un logiciel proprio. Non il faudrait qu’ils revoient leur règles pour imposer certaines bonnes pratiques aux constructeurs utilisant Android.



Les Nexus sur Android sont “en général” de bons élèves sur Android .

&nbsp;

Apres, en effet, iOS (si on retire l’ipad 1) et les Windows Phone (si on retire WinPho7) on un bon rapport de mise à jour.

&nbsp;

&nbsp;Mais, ça ne sera malheureusement, jamais parfait.

&nbsp;

&nbsp;Apres l’open source a bon dos, tant que ce sont les constructeurs / opérateurs qui ont le dernier mot, et qu’une grosse partie des drivers & co sont en “close source”, le problème restera entier …

&nbsp;

&nbsp;Apres il y a toujours Cyano.


Dieu merci, je n’utilise pas leurs produits <img data-src=" />


Le problème, c’est que Nexus ne fait plus que des tablettes qui téléphonent <img data-src=" />, Cyano crée plus de problème qu’il n’en résout (dans mon expérience, c’est probablement lié au fait que j’ai un téléphone d’entrée de gamme qui n’intéresse pas grand monde), et qu’iOS nécessite de vendre un rein. J’attends de voir WP10.



Sinon ta réponse me donne l’impression que je n’ai pas été clair : ma critique ne porte pas sur l’open-source, mais sur la bien piètre utilisation de son potentiel par les fabricants.


&nbsp;Si non en attendant mieux,&nbsp; l’appli de gestion de sms/mms sécurisé et chiffré,&nbsp; Textsecure propose une sécurité contre justement l’attaque invisible en veille présenté par cette faille.

&nbsp;

Elle n’utilise pas Stagefright pour préchargé les mms, elle l’utilise uniquement pour les ouvrir. Du coup impossible d’être touché avec le téléphone&nbsp; sans une action de la part de l’utilisateur.&nbsp; Tant que l’on ne tape pas sur la preview pas de souci, si on ouvre que des photo dont le destinataire vient de nous dire qu’il nous l’envoie sa réduit pas mal les risques !

&nbsp;



&nbsp;voici les commentaire du développeur :

&nbsp;https://github.com/WhisperSystems/TextSecure/issues/3817



We don’t do any pre-processing that involves stagefright. There are no

technical details at all available about this vulnerability (for maximum

hype), but you’d have to physically tap on the media and then click

through a warning about playing media insecurely before stagefright got

involved.

&nbsp;

&nbsp;

&nbsp;Puis tout à l’heure à 13H00, il à ajouté :

&nbsp;https://lists.riseup.net/www/arc/whispersystems/2015-07/msg00084.html



&nbsp;Hey&nbsp;Arun,&nbsp;unfortunately&nbsp;there&nbsp;are&nbsp;no&nbsp;details&nbsp;about&nbsp;the&nbsp;vulnerability



available.&nbsp;&nbsp;Maybe&nbsp;it’s&nbsp;really&nbsp;bad,&nbsp;maybe&nbsp;it’s&nbsp;all&nbsp;hype.







Supposedly&nbsp;the&nbsp;vulnerability&nbsp;is&nbsp;in&nbsp;stagefright,&nbsp;which&nbsp;is&nbsp;the&nbsp;Android



framework&nbsp;responsible&nbsp;for&nbsp;audio/video&nbsp;encoding/decoding&nbsp;and&nbsp;playback.



TextSecure&nbsp;doesn’t&nbsp;do&nbsp;any&nbsp;pre-processing&nbsp;of&nbsp;received&nbsp;audio/video



messages,&nbsp;so&nbsp;it&nbsp;seems&nbsp;unlikely&nbsp;that&nbsp;a&nbsp;vulnerability&nbsp;in&nbsp;stagefright&nbsp;could



be&nbsp;triggered&nbsp;simply&nbsp;by&nbsp;sending&nbsp;audio/video&nbsp;to&nbsp;a&nbsp;TextSecure&nbsp;user.







TextSecure&nbsp;plays&nbsp;audio/video&nbsp;by&nbsp;handing&nbsp;it&nbsp;to&nbsp;the&nbsp;system’s&nbsp;default&nbsp;media



player.&nbsp;&nbsp;If&nbsp;there’s&nbsp;a&nbsp;stagefright&nbsp;vulnerability,&nbsp;it’s&nbsp;possible&nbsp;that&nbsp;the



system’s&nbsp;default&nbsp;media&nbsp;player&nbsp;is&nbsp;vulnerable.&nbsp;&nbsp;From&nbsp;TextSecure,&nbsp;that



interaction&nbsp;should&nbsp;only&nbsp;happen&nbsp;by&nbsp;physically&nbsp;tapping&nbsp;on&nbsp;an&nbsp;audio/video



attachment,&nbsp;then&nbsp;tapping&nbsp;through&nbsp;a&nbsp;warning&nbsp;dialog&nbsp;about&nbsp;insecure



playback.&nbsp;&nbsp;At&nbsp;that&nbsp;point,&nbsp;it’s&nbsp;out&nbsp;of&nbsp;our&nbsp;hands.


Pour info, les commits de jduck dans CyanogenMod concernant les failles de la lib stagefright&nbsp;:

&nbsp;

https://github.com/CyanogenMod/android_frameworks_av/commits/cm-12.1?author=jduc…

&nbsp;








Zerdligham a écrit :



Du coup, quand quelqu’un essaies d’ouvrir une image de 3000 pixels, des données sont copiées en dehors de la zone prévue. Si tu n’as pas de chance, c’est à un endroit sensible, par exemple l’endroit où sont stockées les prochaines instructions qu’exécutera le processeur.







Suis un peu “old school” en informatique, mais de mon temps (je parle d’un temps que les moins de vingt ans etc …) et sur les vielles babasses que je pratiquais (VAX par exemple) une zone de mémoire ayant l’attribut “données” ne pouvait en aucun cas être exécutée par le CPU, même en contenant des instructions valides.

Toute tentative de le faire se soldait par une magnifique exception/trap.

Et même, la solution de modifier un pointeur de retour dans la pile en le faisant pointer vers du code injecté n’était pas réaliste car d’une part les adresses relatives codes/données n’était pas fixes d’une exécution à l’autre et de toutes façon il était impossible à une appli en mode user d’écrire dans un segment type “code”



Comment se fait-il qu’on en soit là plus de 30 ans plus tard?









atomusk a écrit :



Tout OS a des failles … aucun OS n’est épargné … 

Le bug de SMS de Windows Phone (crash à la récéption de SMS), et celui de IOS (SMS avec carractére spécial =&gt; crash en boucle), sont juste l’étape 1 avant d’identifier une faille de sécu dans l’OS.







Un crash c’est chiant je le concède mais pas du même ordre qu’une faille de sécurité non plus.









CoooolRaoul a écrit :



Suis un peu “old school” en informatique, mais de mon temps (je parle d’un temps que les moins de vingt ans etc …) et sur les vielles babasses que je pratiquais (VAX par exemple) une zone de mémoire ayant l’attribut “données” ne pouvait en aucun cas être exécutée par le CPU, même en contenant des instructions valides.

Toute tentative de le faire se soldait par une magnifique exception/trap.

Et même, la solution de modifier un pointeur de retour dans la pile en le faisant pointer vers du code injecté n’était pas réaliste car d’une part les adresses relatives codes/données n’était pas fixes d’une exécution à l’autre et de toutes façon il était impossible à une appli en mode user d’écrire dans un segment type “code”



Comment se fait-il qu’on en soit là plus de 30 ans plus tard?





Bah comme d’habitude, la rapidité à gagné sur la conception et après il à fallu gérer la compatibilité… mais c’est pas uniquement dans les CPU, va faire un tour dans les apis windows par exemple <img data-src=" />

&nbsp;



On finit par regretter le bon vieux temps ou c’était “plus propre” et coder de façon plus “intelligente” (ressources limitées, temps calcul précieux…)&nbsp;<img data-src=" />


Depuis plusieurs années je m’inquiète de cette bombe à retardement que constituent la pléthore d’appareils qui ne sont plus maintenus par leurs fabricants.



Tout appareil qui connecté sur l’internet et qui n’est plus mis à jour est un danger potentiel pour ses utilisateurs et pour le réseau tout entier.



C’est un problème évident de sécurité à l’échelle mondiale, ce qui implique que des mesures devraient être prises.



Ceux qui savent qu’un smartphone est (techniquement parlant) un ordinateur se demanderont pourquoi n’importe quel PC peut recevoir de nouveaux Os pendant des années… et pas les smartphones.



La première évidence qui saute aux yeux, c’est l’absence de couche bios/uefi standard qui permettrait de booter et d’installer un Os de façon standardisé. Cette absence constitue de manière évidente une régression majeure.



La seconde, c’est le support dans le temps très limité des composants par certains fabricants.



Ces problèmes doivent faire l’objet d’une régulation dans l’intérêt de tous.



Tout appareil grand public non muni d’un bios standardisé et de mécanismes permettant de changer d’Os doit être interdit à la vente.



Tout fabricant de composant doit être astreint à un suivi de compatibilité des drivers pendant au moins 10 ans.


Ce serait marrant qu’un hacker utilise la faille pour créer un réseau de spam à destination des constructeurs : “vous n’avez pas mis vos équipements à jour”, “veuillez fournir des roms secure à vos clients”, etc.

<img data-src=" />








geekounet85 a écrit :



est ce qu’avoir un téléphone en x86 change quelque chose? y’a t’il un patch via xposed?





J’imagine que ca touche aussi les x86. Par contre, si exploitation il y a, on peut supposer que les premières attaques vont viser la majorité du parc -&gt; arm.



Moi maintenant j’attends la maj du Zenfone2 (oui j’ai craqué après ta réponse la dernière fois, j’ai même le cover <img data-src=" />)









geekounet85 a écrit :



est ce qu’avoir un téléphone en x86 change quelque chose? y’a t’il un patch via xposed?





Ouhhhh. Un patch par xposed : pas con du tout !!!!



Ce qui serait cool serait de savoir si on peut patcher nous mêmes, en root, et comment le faire.









Drepanocytose a écrit :



Ouhhhh. Un patch par xposed : pas con du tout !!!!



Ce qui serait cool serait de savoir si on peut patcher nous mêmes, en root, et comment le faire.





Va falloir surveiller xda :)



Edit: Apparemment il y en a qui desactive via le build.prop…









Muageto a écrit :



Erf, avec mon Galaxy Note de première génération qui n’a pas été updaté depuis la 4.1.2 je n’ai donc plus qu’à essayer de désactiver la réception de MMS et dire à mes contacts que ça ne sert plus à rien de m’en envoyer … WTF ?!?







On parle de MMS car c’est le vecteur de propagation le plus rapide, mais d’après la news, la faille reste toujours exploitable via n’importe quel application (intégré au tel ou téléchargé sur le store ou apk) à partir du moment elle va utiliser la librairie Stagefright pour gérer une image.







Reznor26 a écrit :



Autre solution : que Google passe à iOS.

 



Master troll <img data-src=" />







Je valide <img data-src=" />









Mithrill a écrit :



Ce cas de figure est inquiétant, ça risque de jeter le trouble cette faille… bon bah les FAI n’ont pas qu’à imposer une mise à jour forcée redémarrant chaque tél Android… si c’est possible ? Coup dur pour cet OS.







Vu la quantité énormes de modèles de téléphone différents, je doute que cela soit humainement possible.



Un coup dur pour Android ? Sans l’ombre d’un doute.



Le problème, c’est qu’il était totalement prévisible.



Trop de matériel différent. Mais surtout, du matériel beaucoup trop fermé pour être pris en charge d’une manière centralisée comme sur une distribution Linux pour PC.



Tout cela a abouti à une fragmentation ingérable.



Ce modèle n’est pas viable.



Mais ça se vend…








CryoGen a écrit :



J’imagine que ca touche aussi les x86. Par contre, si exploitation il y a, on peut supposer que les premières attaques vont viser la majorité du parc -&gt; arm.



Moi maintenant j’attends la maj du Zenfone2 (oui j’ai craqué après ta réponse la dernière fois, j’ai même le cover <img data-src=" />)





<img data-src=" />

moi aussi pour le cover. il est super bien géré en plus je trouve. du très bon matos! En espérant qu’Asus fasse une mise à jour (rapidement?)



si j’ai bien compris : il y a juste une MAJ d’une librairie d’androïd à faire, mais s’pas possible.

Cadeau : les conseils&nbsp;de l’ANSSI :(

&nbsp;

&nbsp;Fallait peut-être réfléchir avant…








MuadJC a écrit :



nan, ya aussi Archos! ^^

Mon appareil a 11 mois, j’attends toujours la maj 4.4 promise avant qu’il sorte (ya 11 mois)…







Chez Archos … Un conseil flash ton périphériques avec une ROM alternatives …. Serieux ce constructeur ce fou de la gueule du monde ….



Un amis a acheté une tablette recente et c’est une horreur …. J’ai du la flasher avec un firmware chinois ( Ho la jolie biatch à l’allumage de la tablette <img data-src=" /> ) heureusment les mec se sont basé sur la Android avec toutes les langues ….



Depuis il en est super content !









sr17 a écrit :



Vu la quantité énormes de modèles de téléphone différents, je doute que cela soit humainement possible.



Un coup dur pour Android ? Sans l’ombre d’un doute.



Le problème, c’est qu’il était totalement prévisible.



Trop de matériel différent. Mais surtout, du matériel beaucoup trop fermé pour être pris en charge d’une manière centralisée comme sur une distribution Linux pour PC.



Tout cela a abouti à une fragmentation ingérable.



Ce modèle n’est pas viable.







Google n’en a rien à sirer ….



Ils vont te dire : Regarder on a patché en 48H nous ….



Bha peux être bien oui mais plus de 70% (j’exagère peut être) de ton parc mobile ne sera de toute façon pas mis à jour avec ta correction … donc bon ….









Drepanocytose a écrit :



Ce serait marrant qu’un hacker utilise la faille pour créer un réseau de spam à destination des constructeurs : “vous n’avez pas mis vos équipements à jour”, “veuillez fournir des roms secure à vos clients”, etc.

<img data-src=" />









‘Ha ha ha vous n’avez pas mis a jour vos produits !’



Cf Jurrasic parc et l’écran du dev :P



Effectivement ça serait marrant <img data-src=" />



les chinois aussi :-)


Elle à été rapidement corrigée mais il y a quand même eu un problème de communication si j’en crois l’article. Ce n’est que maintenant qu’ils en parle et bien sûr aucun correctif n’a été déployée.

&nbsp;



&nbsp;Pourquoi ne pas avoir jouer la carte franc jeu alors qu’ils s’amuse à donner des leçons la dessus, au hazard quand MS prend plus de 3mois pour lancer un correctif?

&nbsp;



Bon enfin, on va pas en profiter pour relancer le débat Google VS MS <img data-src=" /> mais c’est une occasion pour les constructeurs de montrer ce qu’ils comptent faire dans cette situation, avec leur politique de suivi des smartphones…



  • Google annonce que une faille non corrigé au bout de 3 mois fera l’objet d’une full disclosure =&gt; Microsoft met plus de 3 mois à sortir le patch : c’est la faute de Google



    &nbsp;- une équipe de hacker annonce qu’en Aout il y aura une full disclosure de la faille d’Android, Google publie l’anomalie en 48h sur son code source et pousse au cul les OEM pour avoir une publication de correctif pour la date de full disclosure, l’objectif étant de ne pas attirer l’attention sur cette faille non encore exploitée, pour éviter le reverse engineering du bug (chose qui était arrivée avec Blaster). Entre temps l’équipe de hacker balance le morceau et annoncent publiquement 15 jours avant le full disclosure la faille et la librairie qui a la faille : c’est la faute de Google

    &nbsp;

    &nbsp;

    Je rêve ou il y a double standard ?&nbsp;<img data-src=" />








atomusk a écrit :





  • Google annonce que une faille non corrigé au bout de 3 mois fera l’objet d’une full disclosure =&gt; Microsoft met plus de 3 mois à sortir le patch : c’est la faute de Google



    &nbsp;- une équipe de hacker annonce qu’en Aout il y aura une full disclosure de la faille d’Android, Google publie l’anomalie en 48h sur son code source et pousse au cul les OEM pour avoir une publication de correctif pour la date de full disclosure, l’objectif étant de ne pas attirer l’attention sur cette faille non encore exploitée, pour éviter le reverse engineering du bug (chose qui était arrivée avec Blaster). Entre temps l’équipe de hacker balance le morceau et annoncent publiquement 15 jours avant le full disclosure la faille et la librairie qui a la faille : c’est la faute de Google

    &nbsp;

    &nbsp;

    Je rêve ou il y a double standard ?&nbsp;<img data-src=" />





    Meuh non, je dis juste qu’ils ont été en quelque sorte pris à leur propre jeu.&nbsp;

    &nbsp;

    &nbsp;<img data-src=" /><img data-src=" />

    &nbsp;

    &nbsp;Selon l’article, ça fait plus de 3mois, je sais pas quand en avril que ça été remonté mais c’est forcément début avril pour que ça fasse plus de 3 mois maintenant. Mais bon c’est pas l’important, j’attends de voir comment ça va être gérer auprès des constructeurs. <img data-src=" />









after_burner a écrit :



…j’attends de voir comment ça va être gérer auprès des constructeurs. <img data-src=" />





pourquoi une correction d’un OS devrait-elle être gérée par un fabricant ?



N’empêche ça la fout mal pour Google.

Ils se gênent pas pour balancer les failles des autres sociétés (MS en tête) rapidement mais celle-ci traine depuis des mois et par la faute de leur méthode de mise à jour elle va trainer encore des années.



Si seulement ça pouvait faire réfléchir les acheteurs avant d’acheter de l’android


Parce que sur Android c’est comme ça que ça marche :

&nbsp;- Google donne un OS open source

&nbsp;- les OEM prennent l’OS, le customisent à l’envie, ajoutent des drivers & autres saloperies

&nbsp;- les opérateurs ont leur mot à dire sur le couple OS/hardware (stabilité, comportement sur le réseau …) et peuvent même rajouter leur propre merde dans l’OS

&nbsp;

Le concept de Android (et accessoirement ce qui fait que c’est un succès auprès de OEM et des opérateurs vu qu’ils ont liberté totale avec), c’est que c’est le constructeur qui gère sa ROM avec ses contraintes perso.



&nbsp;Google n’a pas le pouvoir de pousser des patchs (et ils essayent de limiter l’impact de cette contrainte, par exemple en poussant depuis quelques temps les patchs de la webview par le play store - vu que c’est une grosse source de faille de sécu)


Encore une fois double standard.

&nbsp;

Google est en faute d’avoir mis une deadline et demander à Ms de s’y tenir.

et quand c’est les chercheurs qui balancent la faille en avance, c’est toujours la faute de Google.

&nbsp;

Google a corrigé la faille et le patch arrivera en temps et en heure.&nbsp;

Si tu veux faire ton boudin va pleurer auprès des OEM.


Perso, j’attend de voir quels acteurs prendront leurs responsabilités.

&nbsp;

Est ce que Google publiera une mise à jour de Hangout pour “cacher la librairie fautive” (rejetant le bug sur les autres appli tierces qui n’ont pas fait le même correctif), est ce que les opérateurs vont faire un système de filtre sur les MMS entrant (cachant la faille sur les MMS, mais laissant la porte ouverte aux attaques sur les apps), ou les OEM vont prendre leurs responsabilités (ce que j’espère franchement).

&nbsp;

Après j’ai un Nexus et un Sony récent, donc je ne m’en fait pas trop perso&nbsp;<img data-src=" />








atomusk a écrit :



Encore une fois double standard.

 

Google est en faute d’avoir mis une deadline et demander à Ms de s’y tenir.

et quand c’est les chercheurs qui balancent la faille en avance, c’est toujours la faute de Google.

 

Google a corrigé la faille et le patch arrivera en temps et en heure. 

Si tu veux faire ton boudin va pleurer auprès des OEM.







En l’occurence, tu me fais dire ce que je n’ai pas dit. MS était clairement en tort pour ne pas avoir corrigé la faille à temps. Ici Google n’a rien à se reprocher du côté correctif, par contre leur modèle vis à vis du déploiement des mises à jour est clairement mauvais et à revoir.

Devoir passer par les OEMs et en plus éventuellement par les opérateurs n’est pas une bonne solution. Des patchs devraient pouvoir être poussé directement par Google



Pour que Google puisse faire des mises à jour, il faudrait qu’ils aient la maitrise du matériel, ce qui n’est pas le cas, seul les OEMs l’ont. Donc c’est aux OEMs de faire le boulot de mise à jour.

&nbsp;

La seule solution pour que Google puisse faire les mises à jour de l’OS, aurait été d’imposer (ou de proposer) un standard à respecter par chaque OEMs acceptant des mises à jour de l’OS. Je ne suis pas sur que beaucoup d’OEMs auraient choisi cette voie. <img data-src=" />

&nbsp;


Est ce que Cyanogenmod est concerné ?


Il y a forcement porosité entre données et exécutable. Après tout, un programme qu’on télécharge a été donnée, et sera exécuté plus tard. On peut imaginer que pour contourner une telle séparation, le débordement permette d’écrire dans la zone donnée d’un autre programme, dont le rôle est de charger du code et de l’exécuter, pour lui faire croire qu’il faut exécuter tel truc à la place du code légitime. Ce programme s’occuperait lui-même de passer le code malicieux de la zone donnée à la zone exécutable.

Bon après je n’ai pas la prétention de connaitre tous les mécanismes possibles (ni les protections matérielles et système à contourner), je voulais juste illustrer comment un simple traitement de données théoriquement neutres peut aller foutre le bazar ailleurs.

La réalité est évidemment plus complexe que mon exemple.


c’est indiqué dans la news :

&nbsp;

&nbsp;Les utilisateurs de CyanogenMod 11 recevront une mise à jour ce week-end, mais les moutures 12 et 12.1 ne sont actuellement corrigées que dans les « nightlies ». Rien n’a par ailleurs été dit concernant&nbsp;CyanogenMod 10 et les versions antérieures. Pour les autres - et donc tous les dérivés d’Android - l’attente va être de rigueur et Zimperium encourage tous les acteurs fournissant des dérivés d’Android à prendre contact pour obtenir au plus vite des correctifs à implémenter.


Il a pas totalement tort :

Déjà du point de vue de l’image (“ça la fout mal”), dans la tête des gens, Android, c’est Google. Si Android marche pas, c’est la faute de Google, ils font pas nécessairement le lien avec les bricolages du constructeur. C’est peut-être pas juste, mais c’est l’image de Google qui prendra le plus si cette faille fait de gros dégats.



Ensuite, la stratégie de Google sur le sujet est très critiquable : c’est Google qui a choisi de diffuser Android avec ce modèle reposant sur les constructeurs, et qui continue bien que ce modèle ait prouvé maintes fois qu’il était incapable de propager les mises à jour.

Pour faire une comparaison trollesque, si pour avoir une mise à jour de sécurité Windows il fallait tout réinstaller à zéro, on critiquerait les admins qui laissent des portes ouvertes dans leurs systèmes, mais aussi MS qui s’acharne dans un modèle de MAJ totalement inefficace. Là c’est pareil, on critique les OEM qui ne prennent pas la peine de propager les MAJ, mais ça n’empêche pas de critiquer aussi la stratégie de Google qui s’avère totalement inefficace.

Bon point pour eux, ils essaient de corriger le tir, mais il reste encore pas mal de chemin à faire avant que je songe à racheter un téléphone Android.


Sérieusement, on peut pas attendre la full disclosure pour voir quels OEM n’ont pas déployé le patch avant de hurler à la mort ?&nbsp;<img data-src=" />

&nbsp;

Si tous les OEM publient des correctifs pour 99% des devices, ca validera tout le modèle de fonctionnement de Google et on aura hurlé à la mort pour rien&nbsp;<img data-src=" />

&nbsp;

C’est si difficile de dire “wait & see”, ce que ça veux dire chez Google “on travaille avec les OEM pour déployer le patch” ?


Mon commentaire est général, concerne toutes les MAJ d’Android, et s’appuie sur l’expérience passée, mais ne fait pas spécifiquement référence à cette faille problème.

Après, mon pronostic est que cette MAJ ne fera pas exception, mais Wait and see, comme tu dis, je serais content de me tromper. Pour tous ceux qui comme moi ont un téléphone pas flambant neuf, mais surtout parce que ce serait un bon signal pour les futures mises à jour, même moins critiques.








geekounet85 a écrit :



<img data-src=" />

moi aussi pour le cover. il est super bien géré en plus je trouve. du très bon matos! En espérant qu’Asus fasse une mise à jour (rapidement?)







Oui mais y a quand même un ou deux truc qui m’embête :




  1. L’écran ne s’allume pas quand on reçoit une notification (comme un email par exemple), je trouve ca un peu dommage, surtout qu’on a pas le système prévu par lollipop non plus (ambient light si je ne m’abuse)

  2. Pas de retro eclairage des touches… bon c’est loin d’être dramatique vu qu’il y en a que 3 <img data-src=" />







Les autres MAJ ont un INpact en général largement plus important (ici on parle de changer une librairie), et le fait de ne pas les pousser a une incidence largement plus grave sur l’utilisateur.

&nbsp;

&nbsp;On verra donc … si à l’avenir je ne conseillerai plus jamais que de prendre des Nexus&nbsp;<img data-src=" />








Kiroha a écrit :



Chez Archos … Un conseil flash ton périphériques avec une ROM alternatives …. Serieux ce constructeur ce fou de la gueule du monde ….



J’ai fait mumuse avec des ROM sur un wiko, je suis pas convaincu à 100%

On y gagne parfois 5 avantages, mais toujours en en perdant un (et un seul) autre: appareil photo, GPS encore + pourri que de base, ou bien l’autonomie.

Du coup j’ai pas envie de rejouer avec ça, quand mes matos tournent bien.



Bref, on résume…

Les systèmes d’exploitation grand public sont l’exemple même de ce que la “pompe à pognon” peut faire: Il faut que ce soit le “moins cher” possible, et pour les fabricants de smartphone, si le système est gratuit, ils n’ouvriront jamais la boite de pandore qu’il y a derrière le mot “sécurité”. Et ils ont parfaitement raison, car les failles de sécurité existent aussi sur les logiciels “propriétaires”. En gros, ce n’est pas que les développeurs qui “sévissent” dans ce type de système d’exploitation codent avec leurs pieds (quoique c’est toujours possible, selon le “niveau” de développeur retenu par le donneur d’ordre…), mais plutôt que les dits développeurs&nbsp; ont à leur “disposition” des “assistants” redoutables: Les marketteux et les financiers, les uns et les autres exigeant un maximum de résultats en un minimum de temps! En gros, on veut de la quantité, et surtout pas de la qualité. Et même pour un système “collaboratif”, la pression des marketteux peut devenir catastrophique, empêchant de facto des procédures de recette, non pas exhaustives, mais poussées.

En passant, oser affirmer que Java est “memory-safe”, alors que justement, c’est la base java elle-même qui est truffée de trous de sécurité peut faire rire jaune, mais bon, la boite qui a levé le loup “doit” vendre sa solution miracle, alors tout est permis!


Oups j’avais zappé ce paragraphe. Merci&nbsp;<img data-src=" />


Qui a dit que la librairie en question était codée en Java ?&nbsp;<img data-src=" />

&nbsp;

Ce genre de librairie est forcément en C++ pour avoir les meilleures perfs possible … Android n’est pas un OS codé en Java tu sais ?&nbsp;<img data-src=" />


oui j’avoue que ce sont deux point (et encore, pour les notifications, c’est mineur, mais le rétro-éclairage manque) qui sont perfectibles. dommage que le 3 ne soit prévu pour être x86 (enfin de ce que j’ai compris.)








Zerdligham a écrit :



Il y a un constructeur qui ait été régulièrement bon élève sur ce sujet?

Tout ceux que j’ai un peu regardé m’ont bien déçu. C’est les iPhones et Lumias qui me paraissent les meilleurs en la matière, et de loin, ce qui est assez paradoxal par rapport à ce que devrait permettre l’open source.





Apple fait une distribution directe de son système et n’a pas besoin des opérateurs, de plus il est son propre constructeur, c’est donc beaucoup plus facile d’adapter le logiciel et le matériel. Un iPhone brandé Orange ou SFR n’existe tout simplement pas, c’est un iPhone.

&nbsp;

Pour Microsoft c’est encore un peu différent, &nbsp;il y a un aller retour de chaque version entre le constructeur et l’opérateur pour valider toutes les mises a jour, comme il n’y a que très peu de constructeur et de téléphone, on peut estimer que ça va plus vite.&nbsp;

Apparemment Windows 10 va changer ça en forçant la mise a jour par Microsoft directement d’après ce que j’ai compris.

&nbsp;

Pour Android c’est encore plus différent, Google fournit le code source de l’OS, ce code source est adapté pour chaque téléphone et constructeur, ensuite il y a très souvent un dialogue entre opérateur et constructeur pour fournir la Rom opérateur, ou bien c’est le constructeur qui fournit une Rom standard mais dans tout les cas ça doit être adapté, impossible de faire autrement.

&nbsp;

D’ou l’énorme délai de mis a jour constaté pour chaque téléphone car a chaque fois il faut tout recommencer et tout recompiler, tout vérifier et enfin distribuer la mise a jour tant attendu, qui parfois n’arrive jamais. D’ou aussi l’impression que parfois il est plus rentable de changer de mobile plutot que d’attendre une hypothétique mise a jour qui risque aussi d’être la proie des failles.

De plus les constructeurs n’ont pas forcement l’envie de mettre des ressources dans le support de vieux téléphones quand ils pourraient en sortir des nouveaux plus intéressant.

&nbsp;

Il y a aussi la possibilité de passer par des Roms alternative type Cyanogen, mais encore une fois chaque Rom doit être adapté pour chaque téléphone, ça va aussi plus vite du fait qu’on ne passe pas par l’opérateur pour la validation.

&nbsp;



Bah les notifications me manquent plus que le retro éclairage :p

L’autre truc énervant avec le cover : comme il n’y a pas de contrôle de proximité, il faut ouvrir pour pouvoir raccrocher ou voir les détails de l’appel une fois qu’on a décroché… mais bon ca c’est pas dramatique non plus.


tu peux double taper sur l’écran sinon, même avec le cover.


Ou cyanogen, en appliquant les nightlies :)


Ouep mais curieusement ca n’a pas l’air fonctionnel pendant l’appel… je reessairai.



Par contre le double tap c’est juste magique ! J’adore cette fonctionnalité