Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Contact rédaction Contact site Forum
Flux RSS GitHub Discord

À propos

Abonnez-vous

Android : l’importante faille corrigée, la balle dans le camp des constructeurs

Certains n'auront d'autre choix que de faire attention

Android : l'importante faille corrigée, la balle dans le camp des constructeurs

Le 10 juillet 2013 à 08h25

Il  a quelques jours, une société de sécurité avertissait qu’une importante faille de sécurité dans Android pouvait permettre l’infection non détectable de 99 % des applications. On sait maintenant que Google a colmaté cette brèche et a envoyé les données aux constructeurs. À eux désormais de diffuser le patch de sécurité.

HTC One S gris

Le HTC One S

99 % des appareils potentiellement touchés 

Il y a une semaine, la société Bluebox Security avertissait la communauté des utilisateurs Android d’une importante faille de sécurité. Touchant toutes les versions du système mobile de Google depuis la 1.6 au minimum, elle concernait selon Bluebox Security 99 % des appareils. De fait se posait un évident problème lors de la mise à jour qui ne manquerait pas d’arriver puisqu’un grand nombre de ces appareils ne sont plus supportés depuis bien longtemps.

 

La faille décrite est importante. Elle réside dans la manière dont les applications Android sont d’abord vérifiées, puis installées. Chacune est accompagnée d’une clé de chiffrement qui permet de vérifier l’intégrité des données. La brèche permet  justement de pouvoir modifier le contenu d’application sans que cette clé soit affectée. En clair, même si une application authentique était modifiée pour devenir frelatée, Android ne verrait plus la différence.

 

Le problème était déjà sérieux avec des applications courantes telles que Facebook, Twitter, Instagram ou des jeux comme Angry Birds, mais il devenait plus grave avec certaines autres que les constructeurs livrent avec leurs smartphones. Ces applications maison sont souvent accompagnées de privilèges élevés destinés à leur permettre de gérer un matériel particulier. On pensera notamment aux modèles HTC intégrant la technologie audio Beats.

La faille corrigée, quid de son application concrète ? 

Google était visiblement conscient de cette faille puisque la firme a annoncé qu’elle était désormais corrigée. Dans une déclaration faite à ZDnet, l’entreprise indique que le correctif a déjà été envoyé aux constructeurs. Certains, à l’instar de Samsung, ont déjà commencé à le déployer, mais les modèles concernés ne sont pas encore connus.

 

Car la grande question qui se pose désormais est de savoir quel pourcentage des appareils va être mis à jour. Ces quatre dernières années, ce sont des montagnes de périphériques Android qui se sont vendus et les smartphones ont été depuis rejoints par les tablettes. Selon Bluebox Security, ce ne sont pas moins de 900 millions d’appareils qui seraient ainsi touchés par la faille. Cependant, puisqu’il est encore possible de voir des appareils Android 4.1 déjà abandonnés par leur constructeur, tels que le One S de HTC qui n’aura pas de mise à jour vers la version 4.2 du système alors même qu’il n’est sorti que l’année dernière. Que dire alors de la masse importante d’appareils Android 2.3, sans parler des moutures précédentes ?

 

Nous avons de notre côté contacté certains gros constructeurs tels que Samsung, Sony, HTC ou encore LG pour avoir plus d’informations sur cette mise à jour. Nous espérons notamment obtenir une liste précise des appareils qui seront concernés. Dans l’éventualité d’un modèle qui ne serait pas mis à jour, la meilleure défense sera de faire attention aux sources tierces pour l’installation des logiciels, notamment les boutiques promettant monts et merveilles... ce qui devrait de toute façon être une règle de base. 

Commentaires (103)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar







TRUCide a écrit :



Ravi que Google corrige la faille.



Reste plus qu’à savoir comment mettre à jour le téléphone. J’ai un androïd (Nexus 4) depuis 3 semaine et c’est pas encore au poil. <img data-src=" />





Lorsqu’il y a une mise à jour elle est proposée automatiquement ;)



Mais si tu veux vérifier c’est dans Paramètres &gt; A propos du téléphone &gt; Mises à jour système


votre avatar







PinoTM a écrit :



Lorsqu’il y a une mise à jour elle est proposée automatiquement ;)



Mais si tu veux vérifier c’est dans Paramètres &gt; A propos du téléphone &gt; Mises à jour système







Merci beaucoup <img data-src=" />


votre avatar

99% des appareils sauf le GS4, étrange ça :)



(Par chance j’ai le GS4 <img data-src=" /> )

votre avatar







psn00ps a écrit :



99% des Android, c’est pas assez large comme spectre ? <img data-src=" />







Ça c’est pour la faille. Dans l’article l’information est: la faille est corrigée, mais cette correction peut dans l’absolu concerner uniquement Android 4.1-4.2? ou les version 2.3 et +?, bref, ce que je voulais dire c’est que l’on a pas explicitement les versions d’androïd qui ont été auditée par Google.



Alors que pour la faille on a avait les détails des versions (toutes) <img data-src=" />



Je sais pas si je suis clair?


votre avatar







5h31k a écrit :



En même temps, si tu installe une appli non-officiel, je me demande pourquoi le malware ne serait déjà pas de base dans l’appli (puisque de toute façon rien va la vérifié). Là il s’agissait d’une utilisation sur le store directement.



Toi comprendre ?





Tu peux avoir une appli totalement legit sur un store non-officiel. Cependant la sécurité du store peut laisser à désirer, du coup un cracker peux arriver à remplacer tous les apk par les siens. Sans cette vérification de signature, personne ne s’en rendrait compte tant que le store ne découvre pas le problème (ou le dev qui voit un update qu’il n’a pas poussé).



On dit que les Gplay et Amazon AppStore sont sûre parce que les boites derrière sont plus ou moins sérieuses et donc du coup la sécurité est un minimum assurée. Mais ça n’empêcherait pas un cracker qui réussit à cracker le compte d’un dev de remplacer les apks liés au compte par les siens en utilisant ce bug.


votre avatar







Khalev a écrit :



Ah ouai quand même…



Là on n’est plus dans la partie publishing, ça te va?



http://developer.android.com/tools/building/index.html









Ceci dit si tu as des sources fiables qui disent le contraire je suis preneur…







bon, les vacances ont été courtes.



il s’agit de TA signature. en local. que n’importe qui peut modifier sur sa machine. si tu fais un logiciel open source, tous le monde aura une signature différente..



le seul but de cette correction c’est de s’assurer que l’apk que tu installes, a bien été signer avec la même clé que celle qui figurent sur le play store. Donc elle te permet d’être sûr que c’est bien tartampion qui à builder l’APK. point barre.



Sans cette correction, une appli qui ne prétend pas lire tes contactes ne les lira pas.



C’est pas une faille déjà à la base, à moins d’être totalement attardé.


votre avatar







plumachau a écrit :



Pour le coup, le système de mise à jour de l’iPhone est bien plus intelligent !!



Les constructeurs devraient diffuser les mises à jour, sans se soucier de l’opérateur mobile.



Je ne sais pas trop comment ça fonctionne avec WindowsPhone, mais on ne devrait plus être dépendant du bon vouloir des opérateurs. <img data-src=" />





Enfin pour iOS il y a qu’apple comme fabriquant d’iPHONE, manquerait plus qu’il soit pas d’accord avec lui même ^^.

Android : constructeurs : samsung, htc, lg, acer, asus, hp, archos alcatel… plus une pletor de no-name qui ont tous plus ou moins une custom rom d’android…

C’est la même différence entre Windows et mac os. Microsoft doit supporter un maximum de matos, apple juste son materiel


votre avatar







plumachau a écrit :



Pour le coup, le système de mise à jour de l’iPhone est bien plus intelligent !!





Il est surtout adapté à un “écosystème” où un seul acteur contrôle à la fois le software ET le hardware, dont il limite les déclinaisons <img data-src=" />







plumachau a écrit :



Les constructeurs devraient diffuser les mises à jour, sans se soucier de l’opérateur mobile.





Et augmenter le risque de les faire planter ? Tu ne crois pas qu’elles sont déjà assez moisies comme ça ces “ROMs Opérateur” ? <img data-src=" />







plumachau a écrit :



Je ne sais pas trop comment ça fonctionne avec WindowsPhone, mais on ne devrait plus être dépendant du bon vouloir des opérateurs. <img data-src=" />





Rien de plus simple : Sosh ou Red ou B&You ou FreeMobile + Achat Terminal nu <img data-src=" />

Même si ça peut faire “mal au portefeuille” la première fois, ça a certains avantages :





  • faire prendre conscience de la valeur d’un terminal nu,

  • éviter de se faire plumer par l’opérateur,

  • éviter les ROMs opérateurs qui sont souvent plus buggées, avec des Apps en plus, des fonctions en moins, et une mise à jour plus qu’aléatoire <img data-src=" />




votre avatar







TRUCide a écrit :



Ravi que Google corrige la faille.



Reste plus qu’à savoir comment mettre à jour le téléphone. J’ai un androïd (Nexus 4) depuis 3 semaine et c’est pas encore au poil. <img data-src=" />







Bah Android était libre, bidouillable à l’infini donc n’importe quel péquin peut aller choper les dépôts de mises à jour pour virer les cochonneries et autres..



Oh wait..<img data-src=" />



Finalement cette notion de liberté et de bidouille, qu’on nous balance à toutes les sauces me font bien rire <img data-src=" />


votre avatar

Google a très rapidement réagit, les grand constructeurs disent qu’ils bossent activement sur une mise à jour.



C’est bien joli tout ca… mais la plupart des opérateurs traient à publier les mises à jour et bien souvent ne se donnent même pas la peine de les distribuer.



Perso, je pense qu’il faudrait exclure les opérateurs de la boucle et mettre en place un système qui permette aux constructeurs de directement publier les mises à jour.



Après tout est ce que c’est votre FAI qui décident ou non de distribuer les mises à jour de votre OS sur votre ordinateur ?

Alors pourquoi est-ce qu’il doit avoir son mot à dire pour les smartphones/tablettes ??!

votre avatar







TheDidouille a écrit :



bon, les vacances ont été courtes.



il s’agit de TA signature. en local. que n’importe qui peut modifier sur sa machine. si tu fais un logiciel open source, tous le monde aura une signature différente..



le seul but de cette correction c’est de s’assurer que l’apk que tu installes, a bien été signer avec la même clé que celle qui figurent sur le play store. Donc elle te permet d’être sûr que c’est bien tartampion qui à builder l’APK. point barre.



Sans cette correction, une appli qui ne prétend pas lire tes contactes ne les lira pas.



C’est pas une faille déjà à la base, à moins d’être totalement attardé.





Tu changes de sujet là.



Ton premier message c’est :



TheDidouille a écrit :



heureusement, cette “correction” est contournable. On peut toujours installer des applications sans vérification de la signature. (si j’ai pas envie de mettre mon appli sur le play store par exemple).



Mr Hermann, normalement un peu plus prudent dans sa manière de rédiger, vous vous lachez là. Ça doit être les vacances. Vive les cliques, il y a rien qui se passe en ce moment.







Je te dis donc que non il n’est pas possible d’installer des apks non signés. Si tu veux utiliser ton apk à toi tu dois le resigner. (mais je ne suis pas contre une source fiable qui dise le contraire, hors faille bien entendu)



Pour le point que tu soulèves dans ce message :





TheDidouille a écrit :



bon, les vacances ont été courtes.



il s’agit de TA signature. en local. que n’importe qui peut modifier sur sa machine. si tu fais un logiciel open source, tous le monde aura une signature différente..



le seul but de cette correction c’est de s’assurer que l’apk que tu installes, a bien été signer avec la même clé que celle qui figurent sur le play store. Donc elle te permet d’être sûr que c’est bien tartampion qui à builder l’APK. point barre.





Je n’ai jamais dit le contraire, et mes liens non plus.





TheDidouille a écrit :



Sans cette correction, une appli qui ne prétend pas lire tes contactes ne les lira pas.



C’est pas une faille déjà à la base, à moins d’être totalement attardé.





Si le pirate pirate un apk qui avait déjà besoin de pouvoir accéder aux contacts et à internet, tu penses toujours que c’est une non-faille?



Parce que présumer que les pirates ne vont s’attaquer qu’a des applis qui n’ont pas de droits pour leur en rajouter c’est prendre les pirates pour plus bêtes qu’ils ne sont. (Sans compter le fait qu’on trouve encore pas mal d’applis qui demandent un peu plus de droits que ce dont elles ont besoin pour fonctionner)



Et c’est toujours sans compter le pirate qui aurait trouvé un moyen de by-passer ces droits par une autre faille.



Qu’ils soit possible de modifier un APK sans en modifier la signature c’est une faille, assez énorme en plus, quoique tu en dises. (Sinon pourquoi se faire chier à rendre obligatoire la signature si les autres protections, dont une dépend fortement de l’interface sol-écran, sont suffisantes)


votre avatar







plumachau a écrit :



Pour le coup, le système de mise à jour de l’iPhone est bien plus intelligent !!



Les constructeurs devraient diffuser les mises à jour, sans se soucier de l’opérateur mobile.



Je ne sais pas trop comment ça fonctionne avec WindowsPhone, mais on ne devrait plus être dépendant du bon vouloir des opérateurs. <img data-src=" />





Windows phone est sur le même principe que l’iphone.

La grosse différence c’est que android est open source et que sa popularisation est liée intimement au fait que les constructeurs puissent personnaliser les interfaces. Android a pris ainsi la place de windows phone à ce niveau.

De ce fait (et parce que les premières moutures n’étaient pas techniquement très optimisées) l’OS est très fragmenté entre les différents modèles/constructeurs etc.



Il n’est pas dit qu’un iphone jailbreaké ne pose pas le même type de pb d’ailleurs… le système n’est pas plus intelligent dans l’absolu, il est plus fermé/verrouillé. Pour le meilleur comme pour le pire, avec la liberté vient la liberté de faire des conneries ou de se mettre en danger. Ce n’est pas valable qu’en informatique <img data-src=" />


votre avatar







Znuf a écrit :



Surement pas. Ils sont très lent pour corriger les failles et sont très peu réactif. Attends une ROM du constructeur c’est plus rapide. Et en plus tu ne sera plus coincé en 2.3.



Sérieusement, je pense que la nightlies de demain ou même de ce soir corrigera la faille.







Tu m’as fais peur au début :)


votre avatar







the true mask a écrit :



Finalement cette notion de liberté et de bidouille, qu’on nous balance à toutes les sauces me font bien rire <img data-src=" />





T’as oublié CyanogenMod & co.



Le problème d’Android ce que Google ne publie les sources qu’après coup. Il ne font pas du développement open-source.



Et les différents mods ne font “que” intégrer leurs modifications à la dernière version d’Android fournie par Google.



Il y a aussi toutes les merdes proprio qu’ajoutent les constructeurs. Si le pilote de l’écran tactile est propriétaire et ne fonctionne que sous Android 4.0. Ah moins de le redévelopper pour la 4.2 from scratch, tu pourras pas installer la version 4.2 sur ton téléphone.



Le problème c’est que tous ces inputs/outputs ne sont pas forcément standards, et donc c’est la merde pour l’intégration. Sans compter les architectures proprios. On est loin du PC avec ses architectures standardisés.


votre avatar

Et mon HTC Tatoo sous 1.6 ?



J’ai trouvé la parade, il reste dans un tiroir sans en sortir comme ça il ne craint rien <img data-src=" />

votre avatar







Khalev a écrit :



T’as oublié CyanogenMod & co.



Le problème d’Android ce que Google ne publie les sources qu’après coup. Il ne font pas du développement open-source.



Et les différents mods ne font “que” intégrer leurs modifications à la dernière version d’Android fournie par Google.



Il y a aussi toutes les merdes proprio qu’ajoutent les constructeurs. Si le pilote de l’écran tactile est propriétaire et ne fonctionne que sous Android 4.0. Ah moins de le redévelopper pour la 4.2 from scratch, tu pourras pas installer la version 4.2 sur ton téléphone.



Le problème c’est que tous ces inputs/outputs ne sont pas forcément standards, et donc c’est la merde pour l’intégration. Sans compter les architectures proprios. On est loin du PC avec ses architectures standardisés.







Bah tu as parfaitement résumé là où je voulais en venir, qu’on arrête l’hypocrisie alors.

Parler de liberté, et de bidouille à souhait c’est juste de la foutaise.



Même sur Windows, les constructeurs et autres opérateurs ne peuvent pas bloquer, à ce que je sache, les mises à jours et encore moins les mises à jours de sécurité


votre avatar

Un paradoxe c’est que le correctif de Google devrait permettre aux malfaisants de mieux trouver cette faille, en comparant les sources AndrOS avant/après. <img data-src=" />

votre avatar







Khalev a écrit :



Tu changes de sujet là.



Ton premier message c’est :



Je te dis donc que non il n’est pas possible d’installer des apks non signés. Si tu veux utiliser ton apk à toi tu dois le resigner. (mais je ne suis pas contre une source fiable qui dise le contraire, hors faille bien entendu)







ok, sans vérifier que c’est vraiment la signature de Motorola.. mais une signature quelconque.



aujourd’hui, on peut distribuer une appli sans avoir de signature sur le store, c’est ce que je voulais dire (mais une signature qui sert à rien).





Si le pirate pirate un apk qui avait déjà besoin de pouvoir accéder aux contacts et à internet, tu penses toujours que c’est une non-faille?



le pirate pourra toujours pirater une apk, seulement il pourra pas dire qu’il est le Facebook du play store.



Je crois que tu as bien compris, moi je considère que FB n’a pas à voir mes contacts, où que FB peut se faire pirater mes contacts. à partir du moment où on lit mes contacts, qu’on soit FB, Sony, la RATP, les pagejaunes, electronic arts, ou autres, je me considère piraté.



un jeu n’a pas à voir tes contacts. Je connais pas le nom des dev de jeu, alors j’ai pas de raisons d’avoir plus confiance en lui qu’en un pirate.



C’est une faille en fonction de ton point de vue.

Le mec qui va télécharger un jeu sur du play store, qui lit ses contacts OU

Le mec qui va télécharger un jeu, qui lit ses contacts,

c’est quelque part la même chose. J’ai pas de raisons de faire plus confiance en la RATP qu’en un pirate Chinois.



Je dis ça, mais je ne pirate jamais d’apk et utilises exclusivement le play store, mais pour moi, je vrai contrôle, il se fait à l’installation, en fonction des droits de l’appli. Que ce soit un pirate ou pas, si l’appli ne dit pas quelle accède à mes contacts, elle ne le fait pas, et c’est ça le plus important.


votre avatar







Khalev a écrit :



T’as oublié CyanogenMod & co.



Le problème d’Android ce que Google ne publie les sources qu’après coup. Il ne font pas du développement open-source.



Et les différents mods ne font “que” intégrer leurs modifications à la dernière version d’Android fournie par Google.



Il y a aussi toutes les merdes proprio qu’ajoutent les constructeurs. Si le pilote de l’écran tactile est propriétaire et ne fonctionne que sous Android 4.0. Ah moins de le redévelopper pour la 4.2 from scratch, tu pourras pas installer la version 4.2 sur ton téléphone.



Le problème c’est que tous ces inputs/outputs ne sont pas forcément standards, et donc c’est la merde pour l’intégration. Sans compter les architectures proprios. On est loin du PC avec ses architectures standardisés.







Tu as accès aux sources et tu peux les modifier donc Android est open sources. Open sources ne veut pas dire développement communautaire.



Sinon ce qui prend plus de temps n’est pas les couches proprio du dessus qui s’adapte facilement mais tout le bas niveau.

Et là on ne peut pas faire grand chose à part limiter les plateformes comme le fait MS avec WP mais dans ce cas là on perdrait ce qui fait la force d’Android aux yeux des constructeur.


votre avatar







Khalev a écrit :



…

On est loin du PC avec ses architectures standardisés.







Oui mais combien de temps il a fallu pour que le PC soit effectivement standardisé ?





  • On a d’abord eu plusieurs connecteurs de disque avant que IDE apparaisse.



  • On a eu l’époque où chaque carte graphique (2D) nécessitait un driver spécifique pour commencer à afficher le moindre caractère.



  • On a eu les extensions RAM incompatibles.



  • On a jonglé avec les IRQs dans le BIOS et les settings des logiciels qu’on installait.



  • On a eu un driver pour chaque couple logiciel/imprimate.



    Bref, Parisla standardidation PC ne s’est pas faite en un jour, et celle d’Android est en marche. Je trouve que la convergence est plus rapide, mais la diff’érence c’est que plus de gens achètent un téléphone maintenant qu’un PC il y a 20 ans.


votre avatar







the true mask a écrit :



Bah Android était libre, bidouillable à l’infini donc n’importe quel péquin peut aller choper les dépôts de mises à jour pour virer les cochonneries et autres..



Oh wait..<img data-src=" />



Finalement cette notion de liberté et de bidouille, qu’on nous balance à toutes les sauces me font bien rire <img data-src=" />







C’est pourtant le cas, si Cyanogen existe c’est grâce au code source d’Android qui est disponible.


votre avatar

Il serait bien quand même que google sert la visse concernant androïd et qu’on ne doivent plus passer par le fabricant pour les MAJ si on se fout de la surcouche. Sans cela les produits Androïd donnerons toujours l’impression d’avoir une date de péremption inconnu sans raison technique. Le problème n’est plus seulement l’upgrade à la version supérieur mais le mode de fonctionnement d’android pose de gros problèmes de sécurité à présent car vu le nombre d’appareil connecté c’est un cible intéressante.

votre avatar

Pour ceux que ça intéresse techniquement, la criciticité de la faille est en fait assez basse pour 2 raisons :




  • les hash (modulo une hypothétique collision ) seront différents.

  • elle se détecte facilement en quelques lignes de python.



    Les grands markets alternatifs comme fdroid, apmazon app store, getjar devraient déjà détecter ces apk corrompues. Je n’ai pas de compte chez eux pour le vérifier.



    A partir du moment où vous installez une apk obtenue en dehors de la chaine de confiance que vous avez habituellement avec l’éditeur, vous prenez un risque : MasterKey ou autre.



    En ce qui concerne CyanogenMod, les nightlies sont corrigées et sont donc paradoxalement plus sécurisées que les roms officielles nexus…

votre avatar









knos a écrit :



Tu m’as fais peur au début :)







Mauvaise langue … c’est corrigé depuis 3 jours …. avant les constructeurs, maintenant regarder bien ceux qui vont appliquer le patch.



plus.google.com Google


votre avatar

L’équipe BlueBox derrière cet exploit a publié un outil pour tester la faille sur son terminal :play.google.com Google(Prenez quelques minutes pour regarder la structure de l’apk <img data-src=" />)



En ce qui concerne le scan de vos applications, l’application se propose de trouver les apk compromises avec MasterKey. J’étais sceptique et sur 3 apk perso corrompues différemment, aucune n’a été détectée.






votre avatar







Cékagé a écrit :



L’équipe BlueBox derrière cet exploit a publié un outil pour tester la faille sur son terminal :play.google.com Google(Prenez quelques minutes pour regarder la structure de l’apk <img data-src=" />)



En ce qui concerne le scan de vos applications, l’application se propose de trouver les apk compromises avec MasterKey. J’étais sceptique et sur 3 apk perso corrompues différemment, aucune n’a été détectée.





Marche pas l’appli, elle m’a même pas détecté Facebook comme malware ! <img data-src=" />



(sinon merci beaucoup, après scan, aucun soucis <img data-src=" />)


votre avatar







millman42 a écrit :



Tu as accès aux sources et tu peux les modifier donc Android est open sources. Open sources ne veut pas dire développement communautaire.





Oui effectivement, c’est ce que je voulais dire mais mes doigts ont fourchés. <img data-src=" />





millman42 a écrit :



Sinon ce qui prend plus de temps n’est pas les couches proprio du dessus qui s’adapte facilement mais tout le bas niveau.

Et là on ne peut pas faire grand chose à part limiter les plateformes comme le fait MS avec WP mais dans ce cas là on perdrait ce qui fait la force d’Android aux yeux des constructeur.





En parlant des blobs binaires constructeur, je parlais de tout ce qui était pilotes & co. J’avais totalement zappé que les constructeurs mettaient aussi une surcouche par dessus.

D’accord avec toi sur le dernier point.


votre avatar







TheDidouille a écrit :



Que ce soit un pirate ou pas, si l’appli ne dit pas quelle accède à mes contacts, elle ne le fait pas, et c’est ça le plus important.







Le problème se pose surtout si le pirate arrive à corrompre une application que tu as déjà installé (ou qui est installée par défaut) et en laquelle tu as confiance et qui potentiellement possède des permissions importantes.


votre avatar







levhieu a écrit :



…



Bref, Parisla standardidation PC ne s’est pas faite en un jour, et celle d’Android est en marche. Je trouve que la convergence est plus rapide, mais la diff’érence c’est que plus de gens achètent un téléphone maintenant qu’un PC il y a 20 ans.





Effectivement. C’est ce que je voulais dire, mais dit plus clairement <img data-src=" />


votre avatar







the true mask a écrit :



Même sur Windows, les constructeurs et autres opérateurs ne peuvent pas bloquer, à ce que je sache, les mises à jours et encore moins les mises à jours de sécurité







Sous Windows Phone 7, si. Malheureusement.



Il me manque 2 MaJ sur mon HTC Mozart, les versions nues les ont eues.



Merci l’agrume <img data-src=" />


votre avatar







marquis a écrit :



Sous Windows Phone 7, si. Malheureusement.



Il me manque 2 MaJ sur mon HTC Mozart, les versions nues les ont eues.



Merci l’agrume <img data-src=" />





Il te reste toujours la solution ROMs alternatives <img data-src=" />


votre avatar







marquis a écrit :



Merci l’agrume le subventionné<img data-src=" />





<img data-src=" />



A moins que ton téléphone soit issu d’une souscription à Sosh, auquel cas la situation est encore plus grave que ce que je pensais <img data-src=" />


votre avatar

Non acheté à la maison mère mais les MàJ passent par le réseau de celle ci.



Il me semble que le fait que les updates passaient par les serveurs des opérateurs, MS les avait autorisés à en bloquer certaines.



Ils appliquent comme ils en ont envie.



Sous WP8, ce sont les serveurs MS qui déploient.

votre avatar







TheDidouille a écrit :



ok, sans vérifier que c’est vraiment la signature de Motorola.. mais une signature quelconque.



aujourd’hui, on peut distribuer une appli sans avoir de signature sur le store, c’est ce que je voulais dire (mais une signature qui sert à rien).





N’étant pas sûr de l’écran que tu montrais (je ne me rappelle pas de l’icône “Verify & Install” sur mon téléphone) j’ai supposé que tu parlais de la signature de l’apk.





TheDidouille a écrit :



le pirate pourra toujours pirater une apk, seulement il pourra pas dire qu’il est le Facebook du play store.





C’est là où mes connaissances de publication sur l’app store arrivent à leurs limites, y-a-t-il d’autres vérifications mise en place que celle du Login-mdp? Si je publie une app via mon login et que le certificat fourni avec l’application est toujours le même, cela est-il suffisant pour poster un appli?



Si c’est le cas, alors il y a bien risque de faille en cas de vol de compte.

Si non, le Gplay peut-être considéré comme sûr, sauf Grosse compromission du compte avec tous les autres moyens en plus. (Je rappelle que le compte Gplay de SkyNews avait été piraté il y a quelques temps, leur appli a quand même quelques autorisations sympas, mais pas d’accès au contacts par contre).





TheDidouille a écrit :



Je crois que tu as bien compris, moi je considère que FB n’a pas à voir mes contacts, où que FB peut se faire pirater mes contacts. à partir du moment où on lit mes contacts, qu’on soit FB, Sony, la RATP, les pagejaunes, electronic arts, ou autres, je me considère piraté.



un jeu n’a pas à voir tes contacts. Je connais pas le nom des dev de jeu, alors j’ai pas de raisons d’avoir plus confiance en lui qu’en un pirate.





Là-dessus on est d’accord. Je viens de regarder les autorisations de l’appli Facebook, il faudrait mieux regarder les limitations parce que là… Je crois que j’ai jamais vu une appli avec autant d’autorisations.

play.google.com Google





TheDidouille a écrit :



C’est une faille en fonction de ton point de vue.

Le mec qui va télécharger un jeu sur du play store, qui lit ses contacts OU

Le mec qui va télécharger un jeu, qui lit ses contacts,

c’est quelque part la même chose. J’ai pas de raisons de faire plus confiance en la RATP qu’en un pirate Chinois.



Je dis ça, mais je ne pirate jamais d’apk et utilises exclusivement le play store, mais pour moi, je vrai contrôle, il se fait à l’installation, en fonction des droits de l’appli. Que ce soit un pirate ou pas, si l’appli ne dit pas quelle accède à mes contacts, elle ne le fait pas, et c’est ça le plus important.





On est d’accord là-dessus, mais croire que tout le monde fait ce contrôle, c’est être un poil optimiste. Les gens sont habitués à cliquer sur “OK” sans réfléchir.


votre avatar

” À eux désormais de diffuser le patch de sécurité.”



J’étais mort de rire quand j’ai lu ça … <img data-src=" />

votre avatar







plumachau a écrit :



Pour le coup, le système de mise à jour de l’iPhone est bien plus intelligent !! Les constructeurs devraient diffuser les mises à jour, sans se soucier de l’opérateur mobile.

Je ne sais pas trop comment ça fonctionne avec WindowsPhone, mais on ne devrait plus être dépendant du bon vouloir des opérateurs. <img data-src=" />





Sur Windows Phone pour l’instant y a pas de failles, pas de malwares, et c’est Microsoft qui fait les mises à jour pour tous les modèles, même ceux qui ont 3 ans (après il peut y avoir des différences de délais en fonctions des opérateurs/régions du monde/constructeurs…)!!



Comme ça au moins ça peut pas être plus simple <img data-src=" />


votre avatar







catseye a écrit :



“ À eux désormais de diffuser le patch de sécurité.”

J’étais mort de rire quand j’ai lu ça … <img data-src=" />



Pareil!! “you made my day” <img data-src=" />


votre avatar







marquis a écrit :



Sous Windows Phone 7, si. Malheureusement.

Il me manque 2 MaJ sur mon HTC Mozart, les versions nues les ont eues.

Merci l’agrume <img data-src=" />



c’est l’agrume qui prend les clients pour des cons mais normalement ils ont pas le droit!! Au pire tu te fais pas chier, tu te remets une rom nue et ruleez <img data-src=" />


votre avatar

Sinon, il y a ça que je dois tester.



Seven-Eighter

votre avatar







dj0- a écrit :



Le problème se pose surtout si le pirate arrive à corrompre une application que tu as déjà installé (ou qui est installée par défaut) et en laquelle tu as confiance et qui potentiellement possède des permissions importantes.







En faite pour exploiter la faille il faut impérativement que l’application pour lequel tu veux copier les permissions soit installé sinon cela sert à rien il va afficher la liste des permissions.







votre avatar

Je suis pressé qu’aie lieu la conférence où seront révélés plus de détails, car pour le moment on sait très peu de choses hormis que le faille permet d’exécuter un autre code avec les permissions d’une application légitime. Mais on ne sait rien sur les vecteurs d’infection, a priori l’installation d’une app tierce hors-market…

votre avatar







catseye a écrit :



“ À eux désormais de diffuser le patch de sécurité.”



J’étais mort de rire quand j’ai lu ça … <img data-src=" />



moi aussi. parce que je fais pas dans la sécurité <img data-src=" />


votre avatar

J’ai contacté sony pour voir si mon ancien Xperia X10 va avoir la correction et voici la réponse :



SONY: Il n’y a plus de mise à jour sur le X10.

Baptiste : et donc la faille ne sera pas corrigé?

SONY : Jusqu’à preuve du contraire, il n’est pas indiqué dans nos services que l’appareil dispose de cette faille. Donc, pas de correction prévue pour répondre à votre question.

Baptiste : Il a quelques jours, une société de sécurité avertissait qu’une importante faille de sécurité dans Android pouvait permettre l’infection non détectable de 99 % des applications. On sait maintenant que Google a colmaté cette brèche et a envoyé les données aux constructeurs. À eux désormais de diffuser le patch de sécurité.

SONY : Je sais, j’ai vu cette news moi aussi. Cela n’y change rien.

Baptiste : Touchant toutes les versions du système mobile de Google depuis la 1.6 au minimum, elle concernait selon Bluebox Security 99 % des appareils.

Baptiste : en gros sony s’en fiche !

SONY : Non, mais cette appareil ne recevra plus de mise à jour.



C’est moche …

votre avatar







bat79a a écrit :



J’ai contacté sony pour voir si mon ancien Xperia X10 va avoir la correction et voici la réponse :



SONY: Il n’y a plus de mise à jour sur le X10.

Baptiste : et donc la faille ne sera pas corrigé?

SONY : Jusqu’à preuve du contraire, il n’est pas indiqué dans nos services que l’appareil dispose de cette faille. Donc, pas de correction prévue pour répondre à votre question.

Baptiste : Il a quelques jours, une société de sécurité avertissait qu’une importante faille de sécurité dans Android pouvait permettre l’infection non détectable de 99 % des applications. On sait maintenant que Google a colmaté cette brèche et a envoyé les données aux constructeurs. À eux désormais de diffuser le patch de sécurité.

SONY : Je sais, j’ai vu cette news moi aussi. Cela n’y change rien.

Baptiste : Touchant toutes les versions du système mobile de Google depuis la 1.6 au minimum, elle concernait selon Bluebox Security 99 % des appareils.

Baptiste : en gros sony s’en fiche !

SONY : Non, mais cette appareil ne recevra plus de mise à jour.



C’est moche …





Un volontaire pour interroger HTC ?<img data-src=" />


votre avatar







Khalev a écrit :



C’est là où mes connaissances de publication sur l’app store arrivent à leurs limites, y-a-t-il d’autres vérifications mise en place que celle du Login-mdp? Si je publie une app via mon login et que le certificat fourni avec l’application est toujours le même, cela est-il suffisant pour poster un appli?



Si c’est le cas, alors il y a bien risque de faille en cas de vol de compte.

Si non, le Gplay peut-être considéré comme sûr, sauf Grosse compromission du compte avec tous les autres moyens en plus. (Je rappelle que le compte Gplay de SkyNews avait été piraté il y a quelques temps, leur appli a quand même quelques autorisations sympas, mais pas d’accès au contacts par contre).







C’est exactement ça, on n’a besoin que du certificat, et du login du dev pour publier une maj sur Google Play.

Google ne peut tester le hash lors d’une nouvelle soumission : si c’est une maj, le hash sera forcément différent.



Il y a effectivement un risque de faille en cas de vol de compte, mais sans ça, il n’y a aucune faille possible pour Google Play.

C’est ce dont j’ai essayé de te convaincre en vain il y a quelque jours : c’est une faille exploitable seulement si toutes les autres portes sont ouvertes.



Ceci dit, c’est exactement la même sur tous les stores du monde : si l’on a le login du dev, on peut tout faire.


votre avatar







TheDidouille a écrit :



en fait je sais pas pourquoi je perds du temps sur cette article





C’est pourtant une bonne article <img data-src=" />


votre avatar

en quoi cette maj est nécessaire pour ceux qui ne ‘chargent jamais rien, ou bien qui chargent avec beaucoup de restrictions (Commandes utilisateur&gt;Filtrage du contenu&gt;Pour tous) ?



<img data-src=" />

votre avatar







Glubglub a écrit :



C’est ce dont j’ai essayé de te convaincre en vain il y a quelque jours : c’est une faille exploitable seulement si toutes les autres portes sont ouvertes.





Sauf que les pirates vont réfléchir dans l’autre sens : j’ouvre d’abord l’autre porte (le login/mdp d’un compte) une fois que j’ai réussi je patch l’appli via la faille et ça passe en mise à jour pour tout les utilisateurs. Je ne pense pas que les compte Gplay soient exempt de piratage, donc une faille comme ça pourrait devenir du pain béni pour eux.





Glubglub a écrit :



Ceci dit, c’est exactement la même sur tous les stores du monde : si l’on a le login du dev, on peut tout faire.





Justement là non. Normalement le principe de signature empêche un pirate de se faire passer pour le dev légitime puisque seul ce dernier a la clé privée pour signer son appli, ce qui certifie donc que c’est lui. Le mieux qu’ils puissent faire (hors faille) c’est de créer une nouvelle appli avec leur clé à eux.



Tu veux qu’on recommence la discussion de l’autre jour? <img data-src=" />


votre avatar

Ce qui limite quand même les risques d’infections, car plus de 60 % ( et je dois être gentil) des gens n’iront pas en dehors du Google Play … le risque est surtout pour les markets alternatifs.

votre avatar

Aaaah Android <img data-src=" />

votre avatar

Bon bah j’attend l’update sur le nexus 4

votre avatar

Au final cette faille est plutôt une bonne nouvelle puisque Samsung en a profité pour déployer Jelly Bean sur le GS2 et le GN… J’y suis passé sur mes deux smartphones hier soir…

votre avatar

Cyanogen sera mis a jour pour ça?

votre avatar







Arimane a écrit :



Au final cette faille est plutôt une bonne nouvelle puisque Samsung en a profité pour déployer Jelly Bean sur le GS2 et le GN… J’y suis passé sur mes deux smartphones hier soir…







Yep,mais le Galaxy Note est sous Jelly depuis un moment (début 2013 il me semble),donc la faille doit forcement être présente,en tout cas,j’espère qu’une mise a jour est prévu pour le N7000 <img data-src=" />


votre avatar

On attend tous une mise à jour pour nos appareils déjà délaissés ; Pensez vous que le HTC Dream aura droit à son update ?

votre avatar

heureusement, cette “correction” est contournable. On peut toujours installer des applications sans vérification de la signature. (si j’ai pas envie de mettre mon appli sur le play store par exemple).



Mr Hermann, normalement un peu plus prudent dans sa manière de rédiger, vous vous lachez là. Ça doit être les vacances. Vive les cliques, il y a rien qui se passe en ce moment.

votre avatar







tuxicoman a écrit :



Cyanogen a déja diffusé une version corrigeant la faille dans ses nightly depuis le 7⁄07 et une version stable dispo dès demain :

http://tuxicoman.jesuislibre.net/2013/07/la-faille-masterkey-pour-android-deja-f…







Merci, j’avais pas eu le temps de suivre les màj cette semaine. <img data-src=" />



Dispo le 11/07/13?



Chez moi on est encore le 10/07/13…



Sinon je me doutais que ça serait bientôt corrigé. Bluebox donnait pas mal d’indice pour permettre à des pirates un peu motivé de trouver où chercher.



En plus à la fin du mois on aura l’explication technique et les POC dans la nature.



Je pense que c’est un gros appel du pied pour motiver les constructeurs à diffuser la correction.





P.S: vite faut que je poste sinon on sera le 11⁄07!


votre avatar







Raknor a écrit :



Sachant que tu as TRUSTE l’appli que tu as installé (en acceptant de l’installer, tu acceptes le certificat qui lui est associé, donc tu installes ce certificat), si le certificat de la MAJ est exactement le même (reconnaissable par la clé publique, le nom de l’éditeur, de l’émetteur, le numéro de série, voire une comparaison binaire du certificat si ça t’enchante), pour quelle raison tu ne ferais pas confiance à un certificat qui, en fait, implicitement, TU AS DEJA AUTORISE ET INSTALLE??? (je te rappelle que nous sommes dans le cas d’une MAJ)



J’ai déjà linké ceci dans l’autre article, un peu de lecture :

http://android-developers.blogspot.fr/2011/06/things-that-cannot-change.html



Je n’ai pas envie de te faire l’exemple du serveur web d’une banque, ni te présenter Alice et Bob.







Tu as répondu à côté de ma remarque :

Tu as beau avoir installé une application valide sur ta carte SD, tu ne peux être certain qu’elle n’a pas été altérée trois mois après.



Si tu souhaites vérifier la validité de la MaJ en mode hors-ligne, tu ne peux la vérifier qu’en la comparant avec ce que tu as déjà d’installé sur ta carte SD.

Autrement dit, tu la testes en la comparant avec des données LOCALES.

N’importe quel informaticien te dira que les données stockées localement chez l’utilisateur NE SONT JAMAIS FIABLES.



La faille dans ton raisonnement est simple :




  • Tu installes un APK valide, tu as un certificat et une signature la validant enregistré sur ta carte SD.

  • N’importe qui ayant accès à ta carte SD peut modifier ces données enregistrées par un autre certificat, et une nouvelle signature la validant (avec une nouvelle clef privée).

  • Tada ! Ton app peut se faire mettre à jour en hors ligne par le premier venu.



    Tu as beau me sortir avec mépris les exemples théoriques qui pourraient rendre ça possible, mais je suis à peu près certain qu’une MaJ en mode hors ligne n’existe ni sur Google Play, ni sur AUCUN autre store, et pour cause !



    Quoi qu’il en soit, une MaJ en mode hors-ligne avec vérification n’est pas disponible sur Android (ni iOS, ni WP….).



    La faille de sécurité décriée reste donc particulièrement ridicule :

    Seul un store pirate ou un APK téléchargé depuis un site obscur peut mettre en péril un appareil Android… Mais c’était déjà le cas avant !



    Et effectivement, si tu veux vraiment avoir raison, dans l’hypothèse où une MaJ hors-ligne avait été disponible, ça aurait pu créer une faille de plus.


votre avatar







Glubglub a écrit :





  • N’importe qui ayant accès à ta carte SD peut modifier ces données enregistrées par un autre certificat, et une nouvelle signature la validant (avec une nouvelle clef privée).







    La faille dans ton raisonnement est simple :

    N’importe qui ayant déjà accès à ta carte SD peut déjà directement véroler tes appli ou ton téléphone que de se faire chier à modifier des apk, des certificats, des signatures et attendre que l’utilisateur télécharge la mise à jour vérolée…. Pourquoi se rajouter une étape ? Fat logique.







    Glubglub a écrit :



    Tu as beau me sortir avec mépris les exemples théoriques qui pourraient rendre ça possible, mais je suis à peu près certain qu’une MaJ en mode hors ligne n’existe ni sur Google Play, ni sur AUCUN autre store, et pour cause !







    http://developer.android.com/tools/publishing/publishing_overview.html#publishing-release



    Android protects users from inadvertent download and install of apps from locations other than Google Play (which is trusted). It blocks such installs until the user opts-in Unknown sources in Settings &gt; Security, shown in Figure 2. To allow the installation of applications from other sources, users need to enable the Unknown sources setting on their devices, and they need to make this configuration change before they download your application to their devices.





    Le playstore est reconnu comme de confiance, probablement à l’aide d’une connexion SSL (à voir sur quel protocole, capture de trame?). Pour installer un apk d’une source AUTRE que le playstore, il faut activer cette option. Enfin, pour moi, une personne censée devrait se faire qu’avec “sources inconnues”, il faut commencer à être méfiant. voir capture d’écran ici pour illustration Sur ce point, nous sommes d’accord. C’était déjà connu. Donc certainement pas le sujet de la soit-disante faille.

    Va falloir que tu précises ce que tu veux dire par le mode hors ligne (et link moi une source tangible). Store alternatif? Depuis USB?





    Mais au final, on discute de quelque chose qui n’a rien à voir avec la prétendu faille. Déjà soulevé par Cékagé :





    Cékagé a écrit :



    L’équipe BlueBox derrière cet exploit a publié un outil pour tester la faille sur son terminal :play.google.com Google(Prenez quelques minutes pour regarder la structure de l’apk <img data-src=" />)



    En ce qui concerne le scan de vos applications, l’application se propose de trouver les apk compromises avec MasterKey. J’étais sceptique et sur 3 apk perso corrompues différemment, aucune n’a été détectée.







    Voir plus.google.com GoogleA confirmer mais l’auteur l’a déduit du bug report sur CM.


votre avatar







Raknor a écrit :



La faille dans ton raisonnement est simple :

N’importe qui ayant déjà accès à ta carte SD peut déjà directement véroler tes appli ou ton téléphone que de se faire chier à modifier des apk, des certificats, des signatures et attendre que l’utilisateur télécharge la mise à jour vérolée…. Pourquoi se rajouter une étape ? Fat logique.







Exactement !

Ce n’est pas une faille dans mon raisonnement, c’est EXACTEMENT ce que je voulais dire.

C’est la raison pour laquelle une MaJ hors ligne n’est pas sécurisée.

Tu semblais soutenir l’inverse sur TOUS tes posts de la page 9.







Raknor a écrit :



http://developer.android.com/tools/publishing/publishing_overview.html#publishing-release







Merci de valider mon point de vue par ce lien :

Il y est écris noir sur blanc que toutes les installations hors Google Play nécessitent de désactiver manuellement les vérifications des sources de l’APK dans les options d’Android !







Raknor a écrit :



Le playstore est reconnu comme de confiance, probablement à l’aide d’une connexion SSL (à voir sur quel protocole, capture de trame?). Pour installer un apk d’une source AUTRE que le playstore, il faut activer cette option. Enfin, pour moi, une personne censée devrait se faire qu’avec “sources inconnues”, il faut commencer à être méfiant. voir capture d’écran ici pour illustration Sur ce point, nous sommes d’accord. C’était déjà connu. Donc certainement pas le sujet de la soit-disante faille.

Va falloir que tu précises ce que tu veux dire par le mode hors ligne (et link moi une source tangible). Store alternatif? Depuis USB?





Mais au final, on discute de quelque chose qui n’a rien à voir avec la prétendu faille. Déjà soulevé par Cékagé : (…)







Je résume notre débat :



Moi (depuis une semaine) : Ce n’est pas une faille tant qu’on reste sur Google Play (ou Amazon Store…).

Toi : C’est un système de merde, Google Play ne fait aucune vérification.

Moi : Android est concu pour fonctionner sans Google, Google ne peut valider une installation externe à Google Play.

Toi : Avec la vérification du certificat et du hash sur la carte SD de l’utilisateur, on peut avoir une installation sécurisée sans avoir besoin de Google.

Moi : Les données présentes sur une carte SD d’un utilisateur ne peuvent être considérées comme fiables.

Toi (à l’instant) : Rien n’est fiable sur la carte SD de l’utilisateur, les installations hors Google Play ne sont pas validées (cf doc), et la faille n’en est pas une si l’on télécharge l’app depuis Google Play.



Merci ! Enfin !

On peut enfin clore le débat ? Je crois que l’on est d’accord.


votre avatar







Cékagé a écrit :



(…)

J’étais sceptique et sur 3 apk perso corrompues différemment, aucune n’a été détectée.







Erreur de ma part, la détection fonctionne très bien et les 3 cas ont été détectés par l’application. <img data-src=" />


votre avatar







Glubglub a écrit :



La faille dans ton raisonnement est simple :




  • Tu installes un APK valide, tu as un certificat et une signature la validant enregistré sur ta carte SD.

  • N’importe qui ayant accès à ta carte SD peut modifier ces données enregistrées par un autre certificat, et une nouvelle signature la validant (avec une nouvelle clef privée).

  • Tada ! Ton app peut se faire mettre à jour en hors ligne par le premier venu. [











    Glubglub a écrit :



    La faille dans ton raisonnement est simple :

    N’importe qui ayant déjà accès à ta carte SD peut déjà directement véroler tes appli ou ton téléphone que de se faire chier à modifier des apk, des certificats, des signatures et attendre que l’utilisateur télécharge la mise à jour vérolée…. Pourquoi se rajouter une étape ? Fat logique.



    Exactement !

    Ce n’est pas une faille dans mon raisonnement, c’est EXACTEMENT ce que je voulais dire.

    C’est la raison pour laquelle une MaJ hors ligne n’est pas sécurisée.

    Tu semblais soutenir l’inverse sur TOUS tes posts de la page 9.





    La seule personne qui peut accéder a tes applis en théorie n’est que l’utilisateur via l’OS ok? (et google pour virer des app interdits).

    Comment tu modifies tes apps?

    Soit MAJ (le cas de notre article)

    Soit une appli malveillante ou un hacker logué sur ton téléphone. Autrement dit, le téléphone est déjà corrompu. Pas la peine de MAJ après.

    Tu es quand même bon dans la mauvaise foi.



    Je résume les 2 articles



    Moi (et les autres) : Une faille touche 99% des android dans le monde. On cherchait juste à savoir ce que c’était.

    cf mon dernier link (sur le MasterKey, ce serait une histoire de dupliquer des fichier dans un apk, à la vérification de la signature, le fichier d’origine est checké lors de la signature, mais c’est le fichier dupliqué/vérolé qui est installé). Alors vérification ou pas vérification, playstore ou pas playstore, google ou pas google (et fait les mix que tu veux), ça passe tout de même. Difficile à comprendre?



    Toi : “Ce n’est pas une faille tant qu’on reste sur Google Play (ou Amazon Store…). ” = l’installation via sources inconnues est faillible. En soit, ce n’est pas une faille, vu que c’est documenté et connu depuis le début.



    En gros tu es hors sujet depuis le début.









    Glubglub a écrit :



    Toi : C’est un système de merde, Google Play ne fait aucune vérification.







    Merci de ne pas déformer mes propos. J’ai dit cela dans un cas précis de conditions à vérifier.

    D’ailleurs, avec tes histoires de MAJ hors ligne, sans vérification, c’est plutôt TA position.







    Glubglub a écrit :



    Moi : Android est concu pour fonctionner sans Google, Google ne peut valider une installation externe à Google Play.





    Oui c’est le principe d’Android. Mais Google ou pas google, playstore ou pas playstore, tu peux vérifier la signature de l’APK POUR vérifier l’AUTHENTICITE. Tu mélanges ! Il n’importe seulement que la MAJ que tu installe provient du même éditeur. Après, pour ce qui est du contenu de l’application ou de la MAJ, c’est a tes risques et périls (même sur le playstore vu que google ne fait qu’une vérification à posteriori)







    Glubglub a écrit :



    Toi : Avec la vérification du certificat et du hash sur la carte SD de l’utilisateur, on peut avoir une installation sécurisée sans avoir besoin de Google.

    Moi : Les données présentes sur une carte SD d’un utilisateur ne peuvent être considérées comme fiables.





    Rebelote, tu mélanges. C’est l’authenticité qu’on vérifie. Tu as fait confiance à un éditeur en installant son application. En partant de là, si tu a la preuve que la MAJ vient de lui (exactement le même certificat et signature vérifiée), tu peux, basé sur la confiance que tu lui as précédemment accordé, installer la MAJ,Google ou pas google, playstore ou pas playstore. Après, que cette MAJ soit sécurisé est une autre histoire. (par exemple, demande de droit des MAJ Facebook)

    Pour la fiabilité des données de la SD, je t’ai déjà répondu.







    Glubglub a écrit :



    Toi (à l’instant) : Rien n’est fiable sur la carte SD de l’utilisateur, les installations hors Google Play ne sont pas validées (cf doc), et la faille n’en est pas une si l’on télécharge l’app depuis Google Play.





    Rebelote, tu mélanges.

    “Rien n’est fiable sur la carte SD ” : C’est plutot TA position. En soit, je suis aussi d’accord. Dans le cas qui nous concerne ici, je t’ai déjà répondu.

    C’est quoi que tu appelles validation? Aucun sens ici. Aucune notion de validation par google dans le problème. Les utilisateurs peuvent installer des app hors playstore. cf résumé article.

    Mais la faille peut aussi s’appliquer sur une appli téléchargée sur le playstore.







    Glubglub a écrit :



    Merci ! Enfin !

    On peut enfin clore le débat ? Je crois que l’on est d’accord.







    J’espère bien en avoir fini







    Edit : pour un souci de quote


votre avatar







Raknor a écrit :







Je crois qu’effectivement on peut mettre un terme au débat.



Tu argumentes sur la fiabilité des données stockées chez l’utilisateur pour me contredire…

Et tu conclues le même post, en affirmant finalement être “plutôt d’accord” avec leur non-fiabilité.



Je crois que l’on peut effectivement s’arrêter là.



Android s’est fait littéralement craché dessus depuis cette semaine !

Tout le monde affirme que c’est une faille béante au système, que Google Play ne sera plus jamais fiable…



Je ne critique absolument pas Android, au contraire !

L’une des deux vérifications lors d’une soumission de MaJ à été fragilisée? iOS n’en a jamais eu qu’une seule : le login du dev.

Le système de permission d’Android a été fragilisé ? Sur iOS il n’y en a même pas ! Une simple installation et on peut faire n’importe quoi.



Si tu sembles faire partie des alarmistes, qui crient à l’insécurité sur Google Play, alors tant mieux pour toi.

Le temps nous dira si l’immense majorité des téléphones sans correctifs de sécurité vont devenir des portes ouvertes.



… Mais à mon avis, même avec cette “faille” non colmatée, le système est toujours au moins aussi fiable que son concurrent direct.


votre avatar

(parenthèse débat)



Tu mélanges encore 2 concepts : fiabilité et confiance.



Fiabilité : application vérolé ou pas.



Confiance : crédit accordé par l’utilisateur à l’application qu’il installe lui-même, qu’il soit fiable ou non.



Petite analogie :

Un site web publie un mensonge.

Un lecteur, reconnaît ce site comme de confiance et indûment fiable, reconnaît le mensonge comme vérité.

Le site publie une extension du mensonge.

Le lecteur, par confiance au site et au mensonge, reconnaît le nouveau mensonge comme vérité.



Retour à android:

J’installe et donc je fais confiance à l’application Gmail édité par Google Inc et, ayant une signature valide, est authentifié comme venant de Google Inc. (je n’ai jamais vu le certificat avant, je l’accepte). (remarque qu’on s’en fout de comment j’installe l’application) Implicitement donc, j’accepte l’application comme fiable.

(en réalité, elle peut être non fiable, ….mauvais exemple, bon en fait on ne devrait pas, PRISM xD… bref c’est juste pour l’exemple).



Pour quelle raison ne ferais-je pas confiance à la mise à jour de l’application Gmail édité par Google Inc. , même nom de package, même certificat et signature valide (et donc authentifié)? Parce que je ne fais plus confiance à ce que j’ai fait confiance et considéré comme fiable avant et utilisé? Superbe logique… Parce que j’ai accepté une MAJ que j’ai autorisé par confiance? Retour en haut. Parce qu’une appli malveillante a modifié l’appli de base? Le téléphone est déjà corrompu, ça ne changera rien. Corrompu + corrompu = corrompu. Et l’utilisateurs ne sait pas qu’il est déjà corrompu. A moins d’être paranoïaque… 99% des téléphones android?



Malheureusement, il faut se mettre du côté du téléphone et de l’utilisateur. A part de l’inconscience, je doute de la santé mentale d’un tel utilisateur qui ne ferait pas confiance en ses propres données (sauf paranoïaque)



Ce n’est pas grave, j’ajoute ça à:

mélange hash / signature

mélange validation / authentification



(fin parenthèse débat)









Glubglub a écrit :



Android s’est fait littéralement craché dessus depuis cette semaine !

Tout le monde affirme que c’est une faille béante au système, que Google Play ne sera plus jamais fiable…







Avis personnel : Oui enfin, pour ce qui est du trash et des failles béantes, on est habitué avec Microsoft. Le souci, relevé par tout le monde, n’est pas tant qu’avec la faille béante (que tu n’as toujours pas reconnu dans ton post, navré mais après tout ça…), mais avec la fragmentation android et le non support des anciennes versions, des anciens téléphones, il n’est pas assuré que tout le monde reçoive sa mise à jour de correction.







Glubglub a écrit :



Je ne critique absolument pas Android, au contraire !

L’une des deux vérifications lors d’une soumission de MaJ à été fragilisée? iOS n’en a jamais eu qu’une seule : le login du dev.

Le système de permission d’Android a été fragilisé ? Sur iOS il n’y en a même pas ! Une simple installation et on peut faire n’importe quoi.





Pour le peu que je connais d’iOS, Apple vérifie les applis avant publication non? Sempiternelle différence de modèle.







Glubglub a écrit :



Si tu sembles faire partie des alarmistes, qui crient à l’insécurité sur Google Play, alors tant mieux pour toi.

Le temps nous dira si l’immense majorité des téléphones sans correctifs de sécurité vont devenir des portes ouvertes.



… Mais à mon avis, même avec cette “faille” non colmatée, le système est toujours au moins aussi fiable que son concurrent direct.







Il est normal d’informer les gens quand on détecte une faille. (d’où BlueBox communique) Ca ne veut pas dire que l’on “crie” à l’insécurité. A l’origine, on voulait juste déterminer quelle était cette faille. Puis nous sommes parti depuis la semaine dernière dans notre bazar.



Au passage, pour ceux qui ont du bien rigolé….


votre avatar







Glubglub a écrit :



L’une des deux vérifications lors d’une soumission de MaJ à été fragilisée? iOS n’en a jamais eu qu’une seule : le login du dev.

Le système de permission d’Android a été fragilisé ? Sur iOS il n’y en a même pas ! Une simple installation et on peut faire n’importe quoi.





C’est toujours le problème quand tu ajoutes de la sécurité, tu deviens responsable à la place des utilisateurs.



Un exemple que je connais bien : On a installé des porte palière sur la ligne de métro 1 à Paris. Avant ces portes, les gens ne se collaient pas à la voie, ou s’ils le faisaient (en cas de forte affluence) ils restaient prudents et le conducteur entrait prudemment dans la station et la quittait tout aussi prudemment.



Maintenant qu’on a mis ces portes, les gens s’agglutinent contre les parois et les portes et les métro (automatiques) rentrent à toute berzingue en station.

Si les portes du quai ont un défaut et s’ouvrent quand le train entre en station c’est un massacre. Il est indispensable qu’elle ne puissent pas s’ouvrir si un train n’est pas à l’arrêt en station.

Pourtant ça n’empêche pas les stations sans portes d’être sûres et utilisées tous les jours par des millions de personnes sans (trop) d’accidents.



Ce que tu dis dans la citation au dessus c’est que c’est pas grave que les portes palières s’ouvrent quand le train entre en station puisque de toute façon dans les stations sans porte palière il n’y a pas plus d’accidents que ça.



Le fait de rajouter une sécurité déresponsabilise les gens qui s’appuient sur cette sécurité. Ils lui font confiance et font des choses qu’ils n’aurait jamais fait sans.


votre avatar







Raknor a écrit :



(parenthèse débat)

Pour le peu que je connais d’iOS, Apple vérifie les applis avant publication non? Sempiternelle différence de modèle.







Je comprends le questionnement validité / confiance, c’est l’un des rares questionnements qui m’a paru cohérent depuis une bonne semaine…



Mais (encore une fois) tu sembles facilement critiquer Android sans vraiment creuser le sujet…

Pour le peu que je connaisse d’Android, Google vérifie aussi les apps avant publication. Sempiternelle équivalence de modèle, avec quelques sécurités supplémentaires pour Google.

Ces sécurités supplémentaires ont des failles? Le reste est toujours aussi solide que l’AppStore, et le système reste inviolé.



Mais puisque tu lances ce sujet : Renseigne-toi sur l’offuscation de code, et demande-toi comment Apple et Google peuvent “vérifier” les apps…



D’expérience, dans ma boite, les seules apps s’étant vues refuser l’entrée sur l’AppStore étaient seulement celles contenant “Google” dans une chaîne de caractère.

(un des seuls éléments à échapper à l’offuscation, le reste du code étant illisible.)

Tout le reste passe sans aucun problème tant que ce n’est pas une app qui peut concurrencer une autre officielle d’Apple.







Khalev a écrit :



Le fait de rajouter une sécurité déresponsabilise les gens qui s’appuient sur cette sécurité. Ils lui font confiance et font des choses qu’ils n’aurait jamais fait sans.







Je suis entièrement d’accord.

Mais je trouve amusant le fait que tout le monde critique celui qui a deux sécurités dont une faible, alors que le principal concurrent n’a même pas installé la deuxième sécurité.





Ceci dit, si vous voulez continuer de croire la perfection du modèle Apple, tout en crachant sur Google, allez-y.

Et vous avez raison d’y ajouter du mépris, c’est d’autant plus savoureux.


votre avatar



Je comprends le questionnement validité / confiance, c’est l’un des rares questionnements qui m’a paru cohérent depuis une bonne semaine…





Pour ce qui est de la cohérence, j’invite les lecteurs (voir l’auteur de l’article) de PCI qui ont eu le courage de suivre ce qui a été et dire leur avis… (voir les coms sur les 2 articles). Besoin d’un arbitrage.





Mais (encore une fois) tu sembles facilement critiquer Android sans vraiment creuser le sujet…

Pour le peu que je connaisse d’Android, Google vérifie aussi les apps avant publication. Sempiternelle équivalence de modèle, avec quelques sécurités supplémentaires pour Google.

Ces sécurités supplémentaires ont des failles? Le reste est toujours aussi solide que l’AppStore, et le système reste inviolé.





Tiens, je n’ai jamais eu l’impression qu’en te corrigeant, j’ai paru anti android. C’est pourtant le contraire.

Ce serait bien si tu pouvais appuyer tes dires avec des sources fiables (comme nous nous l’avons fait). Autrement, tout ce que tu dis n’est que du vent.





Mais puisque tu lances ce sujet : Renseigne-toi sur l’offuscation de code, et demande-toi comment Apple et Google peuvent “vérifier” les apps…



D’expérience, dans ma boite, les seules apps s’étant vues refuser l’entrée sur l’AppStore étaient seulement celles contenant “Google” dans une chaîne de caractère.

(un des seuls éléments à échapper à l’offuscation, le reste du code étant illisible.)

Tout le reste passe sans aucun problème tant que ce n’est pas une app qui peut concurrencer une autre officielle d’Apple.





Nous n’avons jamais parlé de vérification de l’application par Google à part toi (tu parlais de MAJ hors ligne). La seule vérification dont nous avons parlé est la vérification de la signature de l’apk. L’obfuscation de code est donc hors sujet (mais intéressante je l’admet)





Mais je trouve amusant le fait que tout le monde critique celui qui a deux sécurités dont une faible, alors que le principal concurrent n’a même pas installé la deuxième sécurité.





Je répète, personne n’a critiqué Android en lui même. Ce qui est critiqué est la fragmentation. Fragmentation qui lève le problème de savoir si la faille sera corrigée sur tous les téléphones. Aujoud’hui, oui google a mis en place un mécanisme pour vérifier les applications sur le playstore cf lien. Donc oui, les applis téléchargés depuis le playstore ne sont plus sujet à cette faille normalement. Mais la faille ne sera entièrement colmaté que si tous les téléphones soient patchés (mais ça n’arrivera pas)





Ceci dit, si vous voulez continuer de croire la perfection du modèle Apple, tout en crachant sur Google, allez-y.

Et vous avez raison d’y ajouter du mépris, c’est d’autant plus savoureux.





Ah bon, on a dit ça? Si tu commences à imaginer des choses…. Allez de plus en plus de HS.



Allez dernière chose, comme tu n’as toujours pas l’air de vouloir reconnaître la faille : ici



Donc ok, si Google vérifie en profondeur les applis avant publication, il n’y aurait pas de problème avec le playstore (comme ça tu es content). Sinon, le playstore est vulnérable vu qu’il ne suffit que de pirater un compte développeur (pas besoin de son keystore).

Sauf que jusqu’ici, j’ai toujours considéré que contrairement à Apple, Google ne le fait qu’après publication (si tu as une source fiable qui dit le contraire, je suis preneur, je ne trouve rien en ce sens, quand même dingue de devoir faire des recherches à ta place pour vérifier tes propos) Il y a certes l’antivirus qu’ils font tourner (Google Bouncer, seulement depuis Février 2012). Ca reste un détecteur à base de “signature” et visiblement, il ne détectait pas la faille.

Autrement, je ne trouve rien.

Mais bon, le playstore a du être patché je te rappelle.

votre avatar







Raknor a écrit :



Pour ce qui est de la cohérence, j’invite les lecteurs (voir l’auteur de l’article) de PCI qui ont eu le courage de suivre ce qui a été et dire leur avis… (voir les coms sur les 2 articles). Besoin d’un arbitrage.





Niveau cohérence moi je suis plutôt avec toi. Mais on va dire que je suis juge et partie.



Glubglub a écrit :



Ceci dit, si vous voulez continuer de croire la perfection du modèle Apple, tout en crachant sur Google, allez-y.

Et vous avez raison d’y ajouter du mépris, c’est d’autant plus savoureux.





Stop la fumette, je n’ai fait que parler de principes de crypto et risques potentiels de cette faille au sein du Google Store. On peut très bien critiquer le store de Google sans être anti-google. Au contraire j’aurais plutôt tendance à me battre pour pointer les défauts d’un truc que j’aime bien et que j’utilise tous les jours.



C’est toi qui a parlé d’Apple, j’aurais été un fanboy c’est moi qui en aurait parlé.







Glubglub a écrit :



Je suis entièrement d’accord.

Mais je trouve amusant le fait que tout le monde critique celui qui a deux sécurités dont une faible, alors que le principal concurrent n’a même pas installé la deuxième sécurité.





Tu es d’accord mais tu rapproches deux aspects en occultant les autres autour. C’est donc que tu n’as pas compris ce que je voulais dire.



Pour reprendre l’exemple que je donnais, Google c’est les portes pallières, Apple c’est une haie d’employés qui bloquent l’accès aux quais. Toi tu dis que le problème des portes n’en est pas un puisque chez Apple il n’y a pas de porte et il n’y a pas plus d’accidents.

Sauf que tu oublies qu’il y a 50 employés sur le quai pour empêcher les gens d’accéder aux voies.


votre avatar







Khalev a écrit :



Niveau cohérence moi je suis plutôt avec toi. Mais on va dire que je suis juge et partie.







En effet. Malheureusement mais on ne trouvera plus personne dans les bas fonds des commentaires de cet article qui date de 3 jours (je ne parle même pas de celui de la semaine dernière)



On aurait dû faire ça dans un forum.


votre avatar







Raknor a écrit :



En effet. Malheureusement mais on ne trouvera plus personne dans les bas fonds des commentaires de cet article qui date de 3 jours (je ne parle même pas de celui de la semaine dernière)



On aurait dû faire ça dans un forum.





Ouai <img data-src=" /> on ne saura jamais qui a raison…


votre avatar







Raknor a écrit :



En effet. Malheureusement mais on ne trouvera plus personne dans les bas fonds des commentaires de cet article qui date de 3 jours (je ne parle même pas de celui de la semaine dernière)



On aurait dû faire ça dans un forum.





Ouai <img data-src=" /> on ne saura jamais qui a raison…


votre avatar







TheDidouille a écrit :



heureusement, cette “correction” est contournable. On peut toujours installer des applications sans vérification de la signature. (si j’ai pas envie de mettre mon appli sur le play store par exemple).



Mr Hermann, normalement un peu plus prudent dans sa manière de rédiger, vous vous lachez là. Ça doit être les vacances. Vive les cliques, il y a rien qui se passe en ce moment.







gné ?


votre avatar







al_bebert a écrit :



gné ?





Laisse, c’est les vacances, il se lâche…



<img data-src=" />


votre avatar

“La faille est corrigée”, et c’est la seule info? d’habitude on a le n° des versions de l’OS que cette correction concerne.



Bon je suppose que toutes les versions d’androïd peuvent être patchées donc, mais ils pourraient faire un effort sur leurs notes.

votre avatar







Arimane a écrit :



Au final cette faille est plutôt une bonne nouvelle puisque Samsung en a profité pour déployer Jelly Bean sur le GS2 et le GN… J’y suis passé sur mes deux smartphones hier soir…





jelly bean est dispo sur le GS2 depuis quelques temps deja, attendu que j’a eut la mise a jur de la version bouygues ca doit faire un mois au moins (et probablement plus, je passe pas mon temps a verifier)


votre avatar







al_bebert a écrit :



gné ?







tu peux avoir envie de modifier un apk avant de l’installer pour plein de raisons.



http://i.imgur.com/yU7RAma.png


votre avatar







TheDidouille a écrit :



tu peux avoir envie de modifier un apk avant de l’installer pour plein de raisons.



http://i.imgur.com/yU7RAma.png







heu oui ok tu peux avoir des raisons (crack, changement de police, icones…)



mais la ton screenshot je voie pas par contre :/


votre avatar







bandix400 a écrit :



On attend tous une mise à jour pour nos appareils déjà délaissés ; Pensez vous que le HTC Dream aura droit à son update ?





Et le Desire 1er du nom?

<img data-src=" />


votre avatar







TheDidouille a écrit :



tu peux avoir envie de modifier un apk avant de l’installer pour plein de raisons.



http://i.imgur.com/yU7RAma.png





http://developer.android.com/tools/publishing/app-signing.html





All applications must be signed. The system will not install an application on an emulator or a device if it is not signed.


votre avatar







Khalev a écrit :



http://developer.android.com/tools/publishing/app-signing.html





“PUBLISHING” == play store

en fait je sais pas pourquoi je perds du temps sur cette article



bien bonnes vacances


votre avatar

Si ça concerne les markets alternatifs hors Amazon App Store, je ne suis pas concerné <img data-src=" />

votre avatar

Ravi que Google corrige la faille.



Reste plus qu’à savoir comment mettre à jour le téléphone. J’ai un androïd (Nexus 4) depuis 3 semaine et c’est pas encore au poil. <img data-src=" />

votre avatar







after_burner a écrit :



“La faille est corrigée”, et c’est la seule info? d’habitude on a le n° des versions de l’OS que cette correction concerne.



Bon je suppose que toutes les versions d’androïd peuvent être patchées donc, mais ils pourraient faire un effort sur leurs notes.





99% des Android, c’est pas assez large comme spectre ? <img data-src=" />


votre avatar

Pour le coup, le système de mise à jour de l’iPhone est bien plus intelligent !!



Les constructeurs devraient diffuser les mises à jour, sans se soucier de l’opérateur mobile.



Je ne sais pas trop comment ça fonctionne avec WindowsPhone, mais on ne devrait plus être dépendant du bon vouloir des opérateurs. <img data-src=" />

votre avatar







TheDidouille a écrit :



“PUBLISHING” == play store

en fait je sais pas pourquoi je perds du temps sur cette article



bien bonnes vacances







En même temps, si tu installe une appli non-officiel, je me demande pourquoi le malware ne serait déjà pas de base dans l’appli (puisque de toute façon rien va la vérifié). Là il s’agissait d’une utilisation sur le store directement.



Toi comprendre ?


votre avatar







knos a écrit :



Cyanogen sera mis a jour pour ça?







Surement pas. Ils sont très lent pour corriger les failles et sont très peu réactif. Attends une ROM du constructeur c’est plus rapide. Et en plus tu ne sera plus coincé en 2.3.



Sérieusement, je pense que la nightlies de demain ou même de ce soir corrigera la faille.


votre avatar







TheDidouille a écrit :



“PUBLISHING” == play store

en fait je sais pas pourquoi je perds du temps sur cette article



bien bonnes vacances





Ah ouai quand même…



Là on n’est plus dans la partie publishing, ça te va?



http://developer.android.com/tools/building/index.html



To run an application on an emulator or device, the application must be signed using debug or release mode.







Once the .apk is built, it must be signed with either a debug or release key before it can be installed to a device.





Ceci dit si tu as des sources fiables qui disent le contraire je suis preneur…


votre avatar

Et il y a quelque jours, on t’expliquait que c’est une SIGNATURE (cf doc officielle)



D’après la doc officielle, pour publier une MAJ, il y a 2 paramètres qui doivent rester invariants : le nom et le certificat (autrement, l’appli sera considérée comme une nouvelle appli).



Du côté du playstore:

Soit il n’y a pas de vérification certificat/signature. Dans ce cas, seul le vol du compte du dev est suffisant pour publier une MAJ corrompue. Ce serait le cas d’après Glubglub. Et vu la politique de validation à posteriori, ça a du sens.



Soit il y a vérification (possible car le certificat permet de vérifier la signature). Là il faut donc aussi pirater la clé privée du développeur pour pouvoir publier



Mais il ne faut pas oublier cette partie, du côté de l’utilisateur :

Soit il y a vérification. Dans ce cas, pas possible d’installer une MAJ sans qu’elle ait été signée par le développeur d’origine. Mais je ne sais pas ce que fait le téléphone en tel cas.



Soit il n’y a pas de vérification. Dans ce cas, on revient au vol de compte du développeur.







Dans l’article mentionnée, la faille consiste à modifier l’apk sans changer la signature ; le magasin considérant que l’apk resterait légitime. Nous ne sommes pas dans le débat si google vérifie la signature ou pas, la faille est justement de bypasser cette vérification de signature.

Soit il y a vérification : punaise de faille (et c’est le but de l’article il me semble)

Soit il n’y a pas vérification : tout l’écosystème est merdique à la base.





Mais nous sommes d’accord sur un point, il faut voler les identifiants du dev pour publier sur le store.

votre avatar







Raknor a écrit :



Dans l’article mentionnée, la faille consiste à modifier l’apk sans changer la signature ; le magasin considérant que l’apk resterait légitime. Nous ne sommes pas dans le débat si google vérifie la signature ou pas, la faille est justement de bypasser cette vérification de signature.

Soit il y a vérification : punaise de faille (et c’est le but de l’article il me semble)

Soit il n’y a pas vérification : tout l’écosystème est merdique à la base.





Mais nous sommes d’accord sur un point, il faut voler les identifiants du dev pour publier sur le store.





Le truc c’est que dans l’article, et sur le post du blog de BlueBox ils parlent d’Android qui ne fait pas la vérif, donc le téléphone lui-même.

Pour le store vu que c’est Google aussi au mieux on peut penser qu’ils vérifient la signature aussi, mais il y a de fortes chance que se soit fait de la même manière que sous Android (mais dans ce cas google a déjà dû corriger le truc) ou alors ils ne font pas la vérif se disant que la vérif sera faites par le téléphone, mais ça me paraît un peu gros de laisser proposer des mise à jour sans savoir si elles seront validées par les téléphones, et dangereux pour les “primo-installants”.


votre avatar











le chat maigre a écrit :



en quoi cette maj est nécessaire pour ceux qui ne ‘chargent jamais rien, ou bien qui chargent avec beaucoup de restrictions (Commandes utilisateur&gt;Filtrage du contenu&gt;Pour tous) ?



<img data-src=" />







mis à part un certain coté esthétique… RIEN d’obligatoire pour les bouseux! j’en suis heureux, comme d’autres à qui je dirais ça.


votre avatar







Khalev a écrit :



Le truc c’est que dans l’article, et sur le post du blog de BlueBox ils parlent d’Android qui ne fait pas la vérif, donc le téléphone lui-même.

Pour le store vu que c’est Google aussi au mieux on peut penser qu’ils vérifient la signature aussi, mais il y a de fortes chance que se soit fait de la même manière que sous Android (mais dans ce cas google a déjà dû corriger le truc) ou alors ils ne font pas la vérif se disant que la vérif sera faites par le téléphone, mais ça me paraît un peu gros de laisser proposer des mise à jour sans savoir si elles seront validées par les téléphones, et dangereux pour les “primo-installants”.







On en revient au problème de la fragmentation. Si j’étais google, face à la multitude de rom constructeur, de rom opérateur et de rom alternates, je n’aurais aucune certitude que la vérification sera systématiquement faite. Pour assurer l’écosystème Android, il me semble alors normal de vérifier la signature des appli sur le store officiel (après pour les stores secondaires, à vos risques et périls)





La faille décrite est importante. Elle réside dans la manière dont les applications Android sont d’abord vérifiées, puis installées. Chacune est accompagnée d’une clé de chiffrement qui permet de vérifier l’intégrité des données. La brèche permet justement de pouvoir modifier le contenu d’application sans que cette clé soit affectée. En clair, même si une application authentique était modifiée pour devenir frelatée, Android ne verrait plus la différence.







All Android applications contain cryptographic signatures, which Android uses to determine if the app is legitimate and to verify that the app hasn’t been tampered with or modified. This vulnerability makes it possible to change an application’s code without affecting the cryptographic signature of the application – essentially allowing a malicious author to trick Android into believing the app is unchanged even if it has been.





Je ne vois null part où c’est marqué que la vérification n’est pas faite.


votre avatar







Raknor a écrit :



Je ne vois null part où c’est marqué que la vérification n’est pas faite.





Ça ne parle que d’Android, pas du store.


votre avatar

Bon excuse-moi rappelle-moi du problème alors. (c’est partit dans tous les sens)



Je suis resté à : on peut modifier un apk sans qu’il soit nécessaire de recalculer la signature. De ce fait, on peut faire passer un apk vérolé comme une MAJ et la faire installer sans que le téléphone soulève un problème.

votre avatar







Raknor a écrit :



Et il y a quelque jours, on t’expliquait que c’est une SIGNATURE (cf doc officielle)



D’après la doc officielle, pour publier une MAJ, il y a 2 paramètres qui doivent rester invariants : le nom et le certificat (autrement, l’appli sera considérée comme une nouvelle appli).



Du côté du playstore:

Soit il n’y a pas de vérification certificat/signature. Dans ce cas, seul le vol du compte du dev est suffisant pour publier une MAJ corrompue. Ce serait le cas d’après Glubglub. Et vu la politique de validation à posteriori, ça a du sens.



Soit il y a vérification (possible car le certificat permet de vérifier la signature). Là il faut donc aussi pirater la clé privée du développeur pour pouvoir publier







Du côté du PlayStore, il y a lors d’une MaJ, il y a une vérification du certificat et du nom de package de l’app.



Il y a quelques jours, vous me souteniez qu’il y avait une vérification de la signature, et que le hash de l’apk était la signature.

Je soutennait que c’était impossible : puisqu’il y a eu MaJ, le hash avait forcément changé. Il ne sert à rien de le tester.



Même s’il y a eu une erreur dans mon vocabulaire, tout le reste était valable :

Google Play ne teste pas le hash de l’app lors d’une soumission d’une MaJ.

Il ne peut tester que le certificat, et le nom du package.



C’est donc la solution n°1 : Vérification du certificat, et validation à postériori.

Et oui, un “simple” vol de compte permet de mettre à jour l’app officielle.

Et c’est pareil sur tous les stores : si tu laisse ta porte d’entrée ouverte, tu peux facilement te faire cambrioler.







Raknor a écrit :



Mais il ne faut pas oublier cette partie, du côté de l’utilisateur :

Soit il y a vérification. Dans ce cas, pas possible d’installer une MAJ sans qu’elle ait été signée par le développeur d’origine. Mais je ne sais pas ce que fait le téléphone en tel cas.



Soit il n’y a pas de vérification. Dans ce cas, on revient au vol de compte du développeur.



Dans l’article mentionnée, la faille consiste à modifier l’apk sans changer la signature ; le magasin considérant que l’apk resterait légitime. Nous ne sommes pas dans le débat si google vérifie la signature ou pas, la faille est justement de bypasser cette vérification de signature.







C’est un point que j’ai voulu aborder sans m’exprimer clairement :

Si tu télécharges sur Google Play, tout va bien.



Mais si tu télécharge un APK ailleurs, il n’y a aucune requête de vérification envoyée à Google Play.



Android a été concu pour pouvoir fonctionner sans Google Play.

Si l’on télécharge une app sur l’Amazon Store, on n’a aucune raison de demander quoi que ce soit à Google.

Si l’on télécharge un apk en torrent, on n’a aucune raison de faire une demande à un quelconque store.







Raknor a écrit :



Soit il y a vérification : punaise de faille (et c’est le but de l’article il me semble)

Soit il n’y a pas vérification : tout l’écosystème est merdique à la base.







C’est donc la solution n°2 : il n’y a pas de vérification, et le système n’est pas “merdique à la base”.

il est juste conçu pour être indépendant de Google, et vous vous plaignez que Google ne fasse pas toutes les vérifications.



Si un store est hacké, alors oui, il y aura une faille massive à ce moment là.

Mais jusqu’à présent, les seuls hacks de comptes Google Play que je connaisse sont dûs à des failles humaines (MDP trop simples ou bêtement divulgués).







Raknor a écrit :



Mais nous sommes d’accord sur un point, il faut voler les identifiants du dev pour publier sur le store.







Oui !


votre avatar







Raknor a écrit :



Bon excuse-moi rappelle-moi du problème alors. (c’est partit dans tous les sens)



Je suis resté à : on peut modifier un apk sans qu’il soit nécessaire de recalculer la signature. De ce fait, on peut faire passer un apk vérolé comme une MAJ et la faire installer sans que le téléphone soulève un problème.





C’est bien du seul problème dont parle l’article, après on a divergé sur le Play Store et on se demandait si cette faille en été vraiment une si on n’utilisait que ce store.

Du coup s’ils utilisent la même vérification que sur Android (ce qui semblerait logique, c’est la même boite) où est-ce qu’ils font d’autres vérifications qui empêcheraient l’utilisation de la faille dessus.



Le post de Glubglub reprend sa position.



Ma position c’est que la signature est composée du hash du fichier contenant les hash des fichiers chiffré avec la clé du développeur. Donc si on peut changer un apk sans modifier la signature c’est qu’on peu modifier un apk sans modifier ces fichiers et qu’il n’y a qu’une vérification de la signature.



Je pense effectivement qu’un “simple” recalcul du Hash d’un APK avec comparaison de l’ancien dans le cas d’une signature identique permettrait de combler la faille, mais apparemment ce n’était pas fait. Ils se basaient juste sur la signature et les fichiers associés. Les chercheurs ont donc dû trouver un moyen de modifier/ajouter des fichiers sans que ça ne se voit au niveau des fichiers analysés.







Glubglub a écrit :



Si un store est hacké, alors oui, il y aura une faille massive à ce moment là.

Mais jusqu’à présent, les seuls hacks de comptes Google Play que je connaisse sont dûs à des failles humaines (MDP trop simples ou bêtement divulgués).





Hacker un compte de dev d’une appli massivement utilisée et sa peut devenir une faille massive. <img data-src=" />


votre avatar







Glubglub a écrit :



Il y a quelques jours, vous me souteniez qu’il y avait une vérification de la signature, et que le hash de l’apk était la signature.

Je soutennait que c’était impossible : puisqu’il y a eu MaJ, le hash avait forcément changé. Il ne sert à rien de le tester.



Même s’il y a eu une erreur dans mon vocabulaire, tout le reste était valable :

Google Play ne teste pas le hash de l’app lors d’une soumission d’une MaJ.

Il ne peut tester que le certificat, et le nom du package.







Oui, ce que tu appelles hash est la signature.

Si tu fais une MAJ, en resignant, la siganture change et c’est normal. Mais Google peut vérifier cette signature car le certificat développeur est aussi packagé dans l’apk (cf cryptographie asymétrique).



L’interêt de le tester : justement vérifier que la MAJ founie provient bien du même éditeur. Se limiter au login/mdp est léger tout de même.

D’une part tu vérifies le nom du package et le certificat pour vérifier qu’il s’agit bien de la même appli (identification)

D’autre part, tu vérifies la signature pour confirmer qu’il provient du même développeur (authentification). Avec le login/mot de passe, cela donne au final une sorte d’authentification en 2 étapes.



Enfin ça c’est tel que je le conçoit et ça ne reste qu’un “Google peut”. Après, ta position est que google ne fait pas cette vérification de signature. Et ça, hormis ton experience personnel, aucun des 3 articles (les 2 de pcinpacts, le blog de bluebox), ne le confirme.





Mais au final, on s’en fout royalement de cette vérification puisque la faille, telle expliquée, permet de bypasser (dans le sens passer avec succès) cette vérification (qu’on se dispute depuis la semaine dernière) malgré une altération de l’apk.

Cela se traduit par la violation au niveau de cet authentification. Conceptuellement, un apk vérolé ne provient plus de l’éditeur d’origine. Mais la faille fera authentifier l’apk comme venant de lui tout de même.



Edit: grillé par Khalev.


votre avatar







Glubglub a écrit :



Il y a quelques jours, vous me souteniez qu’il y avait une vérification de la signature, et que le hash de l’apk était la signature.

Je soutennait que c’était impossible : puisqu’il y a eu MaJ, le hash avait forcément changé. Il ne sert à rien de le tester.



Même s’il y a eu une erreur dans mon vocabulaire, tout le reste était valable :







T’es gonflé, t’as raconté un peu n’importe quoi pendant un moment, quand même, ce n’était pas juste “une erreur de vocabulaire”.


votre avatar









NeVeS a écrit :



T’es gonflé, t’as raconté un peu n’importe quoi pendant un moment, quand même, ce n’était pas juste “une erreur de vocabulaire”.







Désolé, tu peux relire tous mes posts en remplaçant “signature” par “certificat”, et tu comprendras mon argument.

Tu remarquera aussi que je n’utilise plus le mot “signature” depuis, mais “hash” et “certificat”…







Raknor a écrit :



(…)





Mais au final, on s’en fout royalement de cette vérification puisque la faille, telle expliquée, permet de bypasser (dans le sens passer avec succès) cette vérification (qu’on se dispute depuis la semaine dernière) malgré une altération de l’apk.

Cela se traduit par la violation au niveau de cet authentification. Conceptuellement, un apk vérolé ne provient plus de l’éditeur d’origine. Mais la faille fera authentifier l’apk comme venant de lui tout de même.



Edit: grillé par Khalev.







On est d’accord sur tous les points précédents, et Google vérifie bien la partie “certificat du dev” de la signature lors d’une soumission.



Mais la partie en gras est la base de mon non-inquiétude :

Auprès de qui comptes-tu vérifier que l’apk vient bien de l’éditeur?

Si une application est falsifiée, elle ne peut finir sur Google Play ou Amazon Store (à moins d’avoir les logins, blablabla).



Puisque Android est un système indépendant de Google, il n’a pas à lui demander une vérification pour un APK téléchargé depuis un store pirate !



Il n’y a donc pas de faille à proprement parler :

Elle permet de contourner une vérification qui n’a pas lieu d’être !



Petit détail rigolo : J’ai un dev iOS dans mon bureau voisin qui m’a expliqué que le keystore (ce qui permet de signer l’app) n’existe pas vraiment chez eux.

Ils signent l’application depuis le compte dev de l’AppStore, ils y ont une procédure pour ça…



S’il m’a dit vrai, cette “faille” sur Android est une porte grande ouverte sur iOS…

Pourtant, je n’entends personne s’en inquiéter (et pour cause, c’est une faille qui ne donne accès à rien en l’état)



votre avatar







Glubglub a écrit :



Mais la partie en gras est la base de mon non-inquiétude :

Auprès de qui comptes-tu vérifier que l’apk vient bien de l’éditeur?

Si une application est falsifiée, elle ne peut finir sur Google Play ou Amazon Store (à moins d’avoir les logins, blablabla).







Et on ta déjà dit d’aller réviser tes cours sur le chiffrement asymétrique.





Pour faire simple :



Le premier jour, tu installes une application. Tu acceptes et reconnait donc un DOUBLET (nom package, éditeur) en réalité (nom package, certificat) car le nom de l’éditeur se trouve DANS le certificat.



Une particularité d’un certificat : il contient une clé publique, lié par une relation cryptographique (en fait mathématique à ce jour inviolée) à une clé privée (secrète, que personne ne peut deviner), celle qui a servi à signer l’application.



Autre particularité d’un certificat : il est signé. Qu’il soit autosigné ou par une autorité de certification (AC), la signature lie le nom de l’éditeur à la clé publique. (EDIT : et donc indirectement, la signature lie le nom de l’éditeur à sa clé privée)



Encore une autre : on dit qu’un certificat est valide si, entre autres critères, la signature valide les information du certificat. (après on a les considérations de date de validité, de CRL etc). Dans le cas d’un certificat autosigné, il s’agit de la même clé publique mentionné. Dans le cas d’une signature d’une AC, le certificat de l’AC doit être fournit. Tu reconnaît implicitement cet AC comme valide et de CONFIANCE.



Une clé publique ne correspond qu’à une seule clé privée.



Le jour d’après, tu as une MAJ, la vérification va se passer comme ça:





  • vérification du nom du package (facile, tu vérifie qu’il s’agit du même nom)

  • verification du certificat (tu vérifie notamment que le nom de l’éditeur ET la clé publique sont les mêmes et que le certificat est VALIDE

  • vérification de la signature







    Voilà, pas besoin de Google pour vérifier qu’un paquet vient du même éditeur.


votre avatar







Raknor a écrit :



Voilà, pas besoin de Google pour vérifier qu’un paquet vient du même éditeur.







Désolé, j’avais aussi invalidé cet argument, mais encore une fois je me suis mal exprimé. (c’est encore ma faute…)



Premièrement, tu as raison dans le cas d’une vérification hors-ligne.

Cette fameuse faille permettrait donc tout à fait ce que me dit : Tu peux mettre à jour ton app téléchargée depuis Google Play avec un APK vicié téléchargé sur eMule.



Donc tu me proposes de vérifier le certificat de la nouvelle APK… Avec le certificat de l’app déjà sur ta carte SD ?

Je ne crois pas que quiconque considère comme fiable ce qui est enregistré en local sur l’appareil de l’utilisateur (sur une carte SD ou la mémoire interne).

Toutes les données sur lesquelles tu vas appuyer ta vérification hors-ligne sont altérables, donc je ne pense pas qu’une telle vérification soit fiable.


votre avatar

ça passera inaperçu mais la mise a jour a été diffusée par Samsung sur le note 2 (je pense qu’a partir du S3 tous devrait prochainement la recevoir…)

j’ai reçu la mise a jour hier pour info

votre avatar

Cyanogen a déja diffusé une version corrigeant la faille dans ses nightly depuis le 7⁄07 et une version stable dispo dès demain :

http://tuxicoman.jesuislibre.net/2013/07/la-faille-masterkey-pour-android-deja-f…

votre avatar







Glubglub a écrit :



Donc tu me proposes de vérifier le certificat de la nouvelle APK… Avec le certificat de l’app déjà sur ta carte SD ?







Sachant que tu as TRUSTE l’appli que tu as installé (en acceptant de l’installer, tu acceptes le certificat qui lui est associé, donc tu installes ce certificat), si le certificat de la MAJ est exactement le même (reconnaissable par la clé publique, le nom de l’éditeur, de l’émetteur, le numéro de série, voire une comparaison binaire du certificat si ça t’enchante), pour quelle raison tu ne ferais pas confiance à un certificat qui, en fait, implicitement, TU AS DEJA AUTORISE ET INSTALLE??? (je te rappelle que nous sommes dans le cas d’une MAJ)



J’ai déjà linké ceci dans l’autre article, un peu de lecture :

http://android-developers.blogspot.fr/2011/06/things-that-cannot-change.html



Je n’ai pas envie de te faire l’exemple du serveur web d’une banque, ni te présenter Alice et Bob.


Android : l’importante faille corrigée, la balle dans le camp des constructeurs

  • 99 % des appareils potentiellement touchés 

  • La faille corrigée, quid de son application concrète ? 

Fermer