Une faille qui existe depuis 2012 a été découverte dans Linux (et corrigée).
Et quoi… pas encore de journal sur linuxfr pour en parler !?
http://www.cyberciti.biz/faq/linux-cve-2016-0728-0-day-local-privilege-escalation-vulnerability-fix/
Journal faille Linux 0 day du 19 janvier 2016
19
jan.
2016
# Un problème. Où ca?
Posté par tuxicoman (site web personnel) . Évalué à 6.
update, reboot , dodo
https://security-tracker.debian.org/tracker/CVE-2016-0728
[^] # Re: Un problème. Où ca?
Posté par zurvan . Évalué à 10.
Ok pour ça, mais sur Android j'ai comme l'impression que ça sera plus long à déployer les correctifs…
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Un problème. Où ca?
Posté par ekyo . Évalué à 5.
Ça permettra de rooter sans avoir à faire sauter la garantie ;) De toute manière pour ce que ça change… Android est déjà une énorme faille de sécurité en soi, à moins de passer sur une aosp sans les outils Google.
[^] # Re: Un problème. Où ca?
Posté par patrick_g (site web personnel) . Évalué à 7.
Le bug a été introduit à partir du noyau 3.8 et il me semble que l'énorme majorité des smartphones Android ont un noyau < 3.8 donc ne sont pas concernés par ce problème.
Par exemple mon Nexus 4 est en version Android 5.1.1 et a un noyau 3.4.
Mais je peux me tromper donc c'est à prendre avec des pincettes.
[^] # Re: Un problème. Où ca?
Posté par matteli . Évalué à 4.
J'ai Android 6.0.1 (la dernière version) sur Nexus 5 et je suis aussi en noyau 3.4
[^] # Re: Un problème. Où ca?
Posté par zurvan . Évalué à 3.
Le noyau 3.8 date de 2013, le 3.4 date de mai 2012, étrange que ça reste dans cet état. Peut-être également que le bogue a été renvoyé dans la version en cours du noyau android (du code backporté sans que ça change de numéro de version). Le second lien indique que ça affecte 66 % de tous les appareils sous Android.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Un problème. Où ca?
Posté par Anthony Jaguenaud . Évalué à 6.
Pourquoi ? Un industriel veut que ça marche, si la version 3.4 fonctionne correctement, n’a pas de faille de sécurité. Pourquoi aller payer des semaines de test pour être sûr que ça passe sur des millions d’appareils alors qu’on sait déjà que ça fonctionne correctement ?
Mettre la dernière version sur ton ordi à la maison, ok. Pour une société, c’est un risque. C’est d’ailleurs pour ça qu’au boulot, j’ai encore du RedHat 6 entreprise.
[^] # Re: Un problème. Où ca?
Posté par Renault (site web personnel) . Évalué à 3.
Note que la version 3.4 est toujours maintenu depuis, ce qui n'est pas le cas du 3.8.
Cependant cela se terminera en septembre 2016, sauf énième report
[^] # Re: Un problème. Où ca?
Posté par pralines . Évalué à 1. Dernière modification le 20 janvier 2016 à 20:44.
merdouille
Wiko pulp 4G v8
Android 5.1.1
Noyau 3.10.49 !!!!!!!!!!!!!!!!!!!
faudra que je regarde si je peux passer en aosp (pour l'instant je n'utilise pas les services google)
Envoyé depuis mon Archlinux
[^] # Re: Un problème. Où ca?
Posté par Prosper . Évalué à 2.
le kernel d'AOSP 6 , c'est un 3.18 , c'est étonnant de trouver un 3.4 sur le nexus 5.
[^] # Re: Un problème. Où ca?
Posté par matteli . Évalué à 1.
C'est pourtant ce que j'ai sous les yeux :
Numéro de Modèle : Nexus 5
Version d'Android : 6.0.1
Niveau du correctif de sécurité Android : 1 janvier 2016
Version du noyau : 3.4.0-g7717f76 blabla (4/11/2015)
[^] # Re: Un problème. Où ca?
Posté par matteli . Évalué à 3.
Je me réponds.
J'ai fait les mises à jour officiel en OTA.
Apparemment dans ce cas le 1er noyau installé est laissé. C'est par des patchs que sont réparés les failles du noyau.
[^] # Re: Un problème. Où ca?
Posté par woprandi . Évalué à 1.
Tu ne changes jamais de version de noyau même lors des mise à jour Android
[^] # Re: Un problème. Où ca?
Posté par Marotte ⛧ . Évalué à 0.
ça sera plus long de déployer les correctifs
French, do you speak it…
# Tester ?
Posté par M.Poil (site web personnel) . Évalué à 2.
Quelqu'un a-t-il trouvé un moyen de tester l'existance de la faille sans pour autant l'exploiter ?
Encore mieux dans un langage interprété ?
Is it a Bird? Is it a Plane?? No, it's Super Poil !!!
[^] # Re: Tester ?
Posté par MarbolanGos (site web personnel) . Évalué à 3.
Il y a ce bout de code : https://gist.github.com/PerceptionPointTeam/18b1e86d1c0f8531ff8f
gcc cve_2016_0728.c -o cve_2016_0728 -lkeyutils -Wall
./cve_2016_0728 PP1
[^] # Re: Tester ?
Posté par M.Poil (site web personnel) . Évalué à 1.
Oui j'ai vu ça, mais ce que je voudrais c'est faire un fact puppet pour lister dans le temps cette vulnérabilitée (y compris sur de futurs déploiement de serveurs), je pourrais bien sure lister par OS tous les noyaux incriminés mais c'est toujours compliqué de ne rien rater; alors qu'une détection …
Is it a Bird? Is it a Plane?? No, it's Super Poil !!!
[^] # Re: Tester ?
Posté par benja . Évalué à 1. Dernière modification le 21 janvier 2016 à 08:59.
Cet exploit (comme beaucoup d'autres) contient des adresse "hardcodées" afin de fonctionner. Si ces adresses ne correspondent pas à un noyau, il ne fonctionnera pas dessus. Mais cela ne veut pas pour autant dire que ce noyau n'est pas vulnérable…
Tu as aussi le projet métasploit qui, à ma connaissance, a pour objet de faire ce que tu demandes; mais à nouveau, je ne me fierais pas à l'absence d'un test positif pour conclure à la non vulnérabilité…
Bref je crois tu vas devoir y couper ;-) Tiens, comment fais(ais)-tu jusqu'à présent pour les autres alertes de sécu ?
(Une autre solution serait d'avoir moins d'hétérogénité dans le parc que tu maintiens, malheureusement c'est aussi une arme à double tranchant en matière de sécurité…)
# Keyctl, qui utilise ça ?
Posté par superna (site web personnel) . Évalué à 2.
Franchement je viens de découvrir les fonctions, qui peut trouver un soft qui se sert de cette API ?
[^] # Re: Keyctl, qui utilise ça ?
Posté par goeb . Évalué à 4.
keyctl est utilisé pour ecryptfs (pour chiffrer un répertoire).
https://www.kernel.org/doc/Documentation/security/keys-ecryptfs.txt
Extrait :
# Bof
Posté par MTux . Évalué à 8.
Peut-être parce que les journaux plus généralistes en font des tonnes parce qu'il s'agit de Linux, mais au fond cette faille n'est exploitable que si tu as déjà un accès au serveur donc ça limite quand même énormément l'impact. On est pas au niveau d'une faille heartbeat qui s'utilise à distance.
[^] # Re: Bof
Posté par Tangi Colin . Évalué à 5.
Tu raisonne serveur mais si tu pense aux rootkit android la faille est déjà beaucoup plus sérieuse.
[^] # Re: Bof
Posté par Elfir3 . Évalué à 5.
Je ne suis pas expert en sécurité, mais il me semble qu'il est rare d'exploiter une seule faille lorsque le but est un accès root à la machine.
En général on compartimente un maximum un serveur pour cette raison. Les failles sur services sont relativement courantes, mais quand c'est configuré correctement le hackeur n'a accès qu'à un compte utilisateur et donc des ressources limitées. Avec ce genre de faille dans la nature, un compte utilisateur devient quasiment équivalent à un compte root pour le hackeur.
Bref, je ne pense pas que l'impacte soit si limité que ça.
[^] # Re: Bof
Posté par MTux . Évalué à 1.
Ben je dirai qu'a partir du moment où l'attaquant réussi à ouvrir un compte sur ton serveur, même s'il n'est pas root, c'est déjà grave.
# Journal bookmark inutile.
Posté par totof2000 . Évalué à 2.
La faille aurait pu être résumée en une ou deux phrases ….
[^] # Re: Journal bookmark inutile.
Posté par zurvan . Évalué à 5.
Commentaire inutile : au lieu de te plaindre tu aurais pu écrire ce fameux résumé.
Je n'ai pas les connaissances techniques pour percevoir la quintessence de cette faille, désolé.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Journal bookmark inutile.
Posté par Tangi Colin . Évalué à 10. Dernière modification le 20 janvier 2016 à 21:05.
le deuxième lien décrit assez bien le problème.
Un problème de "fuite(leak)" d'un compteur dans du code kernel contrôlable facilement par syscall (tu peux incrémenter un compteur sans que les objets qu'est sensé compter se compteur existent). Le compteur est codé sur 32 bits (quelque soit l'architecture 32 ou 64 bit), donc si tu arrive à "overflow" le compteur (tu fait un tour de boucle et donc passe ton compteur à 0), le kernel croit qu'il n'y a plus d'objet référencé et va donc dés-allouer un emplacement mémoire. (use after free attack). Si le compteur ne fuyait pas tu pourrais pas l'overflow car tu te mangerai le Out of Memory Killer bien avant ça.
Suffit alors de ré-allouer l'emplacement mémoire par du code user-space qui va appeler la fonction kernel suivante :
commit_creds(prepare_kernel_cred(0));
Cette fonction aura pour but de te donner l'uid et guid 0 à ton process. (ret2usr attack)
Ré-allouer le même emplacement mémoire est assez simple, l'allocateur mémoire SLAB du kernel linux est facilement prédictible. Pour des raisons de performance si tu demande une allocation d'un bloc mémoire de même taille juste après un dés-allocation, par soucis de performance (et pour pas se prendre la tête et éviter de la fragmentation mémoire), le noyau va te redonner le même emplacement mémoire.
Reste plus qu'a déclencher un syscall, (pour rappel syscall = exeption, passage en ring 0 (kernel)), qui va alors utilisé ton code userspace à toi, qui va appeller la fontion commit_creds.
Voila pour l'explication grosse maille, dans les faits l'exploit est un peu plus élaborer, puisque du code décrementant le compteur utilise le mécanisme de RCU (read copy update) et il est donc plus difficile de savoir quand on a réellement fait l'overflow du compteur. ça demande des synchro a grand coup de sleep. (donc leur exploit prend environ 30 min sur un coeur I7 pour passer root).
Il y a pas mal de mécanisme qu'on peut mettre en place pour se protéger de se genre d'attaque (se protéger du ret2user attack). https://www.usenix.org/sites/default/files/conference/protected-files/sec14_slides_kemerlis.pdf
1) La proposition impossible car complétement anti-performante :
Faire une séparation entre la mémoire user et kernel (arreté de mapper la mémoire kernel dans tous les processus user) et faire un context switch à chaque syscall.
Facile à faire mais complétement irréaliste car ça tuerai toute performance.
2) Identifier les zones mémoires ne devant pas s'exécuter en ring 0 :
Plusieurs techniques soft et aussi hard tels que PaX's KERNEXEC and UDEREF ou PXN (Priviligied Never Execute) sur ARM64.
Cette protection peut malheureusement aussi être contourner si on arrive à utiliser la zone mémoire physmap (voir https://www.usenix.org/sites/default/files/conference/protected-files/sec14_slides_kemerlis.pdf). Mais on complique déjà la vie des attaquant avec ces protections.
3) empêcher l'appel à la fonction kernel commit_creds (l'appel ce fait par symbole).
Le symbole (l'emplacement mémoire de la fonction) est facilement connaissable (définie statiquement à la compilation et dépend uniquement de l'architecture utilisée et du compilateur (gcc ici)). Suffit de mettre de l'aléatoire en place à travers la technique de KASLR (Kernel Address Space Layout Randomisation). Dans ce cas il faut alors éviter de laisser des informations fuitées sur l'emplacement des symboles (voir par example kptr_restrict pour censurer /proc/kallsyms).
Voila ce que j'en ai compris (ps: je suis pas expert en sécurité donc il y a certainement quelques raccourcies).
[^] # Re: Journal bookmark inutile.
Posté par benja . Évalué à 5.
Tu n'aurais, au contraire, rien du tout :p
Pas n'importe quel syscall: justement un syscall qui va utiliser l'objet keyring associé au process courant. Cet object contient, à une indirection près, un pointeur vers une fonction que ce syscall va appeller.
J'en profite pour poser la question de l'éventualité d'une 4)me méthode de protection:
Remplacer toutes ces pointeurs vers une "
struct xxx_ops" par un index sur tableau statique. Dans ce cas, au lieu que le noyau appellekeyring->type->revoke(), il pourrait appellerkeyring_methods[keyring->type]->revoke(). On pourrait même borner le keyring->type avec un masque de manière très peu coûteuse… Serait-ce pensable ?L'explication en
deuxtrois lignes serait: à cause d'un overflow sur un compteur de référence que le noyau oublie de décrémenter, le noyau va être amené à libéré la mémoire représentant le keyring associé au processus attaquant sans pour autant effacer l'association qu'a ce processus à ce keyring. Ensuite le processus, au moyen de sous-système d'ipc, va faire allouer de mémoire noyau qui va être mappée dans son espace utilisateur et, en s'appuyant sur une spécificité de l'allocateur slab, cela va avoir pour résultat que c'est cette même mémoire qui va se retrouver mappée (donc maintenant manipulable par le processus attaquant). Pas de chance, cette mémoire est sensée contenir un pointeur vers une fonction que le noyau va tout naturellement exécuter lors d'un appel système keyring/revoke, sans se douter que ce pointeur pointe maintenant vers du code contrôlé par le processus attaquant…Impossible…?? C'est pas un peu le principe de udref ? Et les micro noyaux ?
[^] # Re: Journal bookmark inutile.
Posté par Sufflope (site web personnel) . Évalué à 3.
https://en.wikipedia.org/wiki/Tanenbaum%E2%80%93Torvalds_debate
[^] # Re: Journal bookmark inutile.
Posté par Tangi Colin . Évalué à 3.
J'ai un doute en lisant ta réponse, si le compteur ne fuyait pas je pourrait toujours faire un overflow. Il s'agit ici bien d'un overflow et non d'un underflow, il faut donc faire 232 appel de syscall, en soit ça il y a rien pour empêcher un programme en userspace d’appeler 232 fois le même syscall. Mais si tu avais pas de fuite du compteur, tu aurais 232 fois l'allocation de l'objet de keyring est niveau mémoire ça passerai difficilement (voir pas avec l'OOM killer qui rentrai en jeu). Parce que si j'ai bien compris, la dés-allocation est faite par le garbage collecteur qui croit qu'il n'y a plus d'objet référencé et donc clean la mémoire. Si j'avais 232 objets alloué le comportement serai le même, il me dés-allouerai le premier objet en croyant qu'il n'existe plus (compteur à 0). Mais avoir 232 allocation du même objet, en mémoire ça passera difficilement.
Y a quelque chose de faux dans mon raisonnement ?
La proposition 4 est intéressante et je me demande pourquoi cela n'est pas fait, sans doute parce cette struct xxx_ops doit être utilisé à beaucoup d'endroit avec des appels vers différentes functions. Si tu remplace le pointeur par un tableau statique tu fais grandir la taille de ta structure (un index par fonction référencé). J'ai bon ?
Les micro-noyaux c'est un autre débats, la méthode est anti-performante dans une architecture monolithique.
Mais pour ma culture personnelle, quel micro noyau existe (en dehors du monde universitaire) ? La plupart du temps les "micro-noyaux" ne sont en fait que des architecture hybride et niveau performance ça pas la panacée.
UDEREF j'ai pas encore creusé le sujet, c'est quoi le principe ? ça marche sur architecture ARM ou c'est uniquement du X86? Et pour quelles contraintes sur les performances ?
```
[^] # Re: Journal bookmark inutile.
Posté par benja . Évalué à 2. Dernière modification le 21 janvier 2016 à 17:26.
Non il n'y a qu'un objet keyring par processus. Le refcount est là pour pemettre le partage entre plusieurs processus. Il n'y a pas de "leak" de mémoire à proprement parler.
Au sujet des micro-noyaux, il y a tout la famille de L4 qui a montré que l'overhead réel sur un i386 avec mmu n'était en fait que de l'ordre < 5% (milieu-fin des années 90). Comme système complet, il y a minix et hurd mais ils utilisent un modèle d'ipc moins performant. Ensuite cela est vrai que beaucoup sont utilisés en configuration hybride: L4Linux, puce radio qui tourne sous SeL4, hyperviseurs nova, etc. Mais bon je ne suis pas un expert non plus.
C'est juste qu'ils réussissent à utiliser la mmu pour faire de l'ipc sans avoir une dichotomie kernel/noyau aussi bourinne qu'avec un noyau monolithique, sans pour autant se payer un flush tlb à chaque changement de contexte. Après, un système planté sera toujours moins performant qu'un système qui tourne 1-2% moins vite en conditions normales.
[^] # Re: Journal bookmark inutile.
Posté par benja . Évalué à 1.
En fait en appellant systématiquement keyctl(JOIN…) avec le même identifiant, le bug du noyau linux va incrémenter le compteur comme si un nouveau processus utilisait le même keyring. Il n'y a pas de création d'un objet supplémentaire. Et ce jusqu'à l'overflow qui va permettre à l'user de mettre la main sur la mémoire qui contient cet objet.
Je suppose que l'on pourrait théoriquement arriver au même résultat sans le bug mais en lançant 232 processus différents; sauf que là effectivement on va avoir un autre problème d'exhaustion de resources avant.
[^] # Re: Journal bookmark inutile.
Posté par benja . Évalué à 0. Dernière modification le 21 janvier 2016 à 17:56.
Pour le 4, je suppose que cela rendrait plus hardu la conception modulaire du noyau. C.-à-d. qu'on doit soit réserver le petit tableau au moment du link de vmlinux (donc limiter arbitrairement le nombre, p.e., de module de filesystem que tu peux charger et perdre un peu de mémoire), soit payer un coût pour une indirection supplémentaire, soit faire du runtime linking plus sophistiqué.
Enfin bon, c'est juste une supposition lancée en l'air, je n'en sais vraiment pas plus; sauf que ça me semblerait être une mesure effective à un côut quasi-nul de perf :p
[^] # Re: Journal bookmark inutile.
Posté par benja . Évalué à 1.
L'idée c'est au lieu d'avoir par exemple:
on aurait
Donc en gros rajouter une opération arithmétique sur un pointeur (l'addresse de mount_ops est connu au moment du link) pour calculer l'addresse de la function1(), Pour le même nombre de déférencement de pointeurs. (vnode->idx, mount_opt+IDX->ext2_mount_ops+OFFSET versus vnode->mount_ops->0+OFFSET). Ça serait peut-être même mieux au niveau de l'utilisation du cache cpu et pourrait consommer moins de mémoire car IDX n'a pas besoin d'avoir la représentation d'un pointeur, un octet devrait être suffisant. Que de spéculations :p
[^] # Re: Journal bookmark inutile.
Posté par pasBill pasGates . Évalué à 2.
Il y a une autre approche bien plus simple…
Encoder les pointeurs de fonction avec une valeur générée au démarrage (bref un XOR) et decoder la valeur avant de déréférencer le pointeur.
Bon par contre cela demande qu'il n'y ait pas d'info leak dans le kernel qui permette à l'attaquant de deviner la valeur avec laquelle le pointeur a été encodé.
[^] # Re: Journal bookmark inutile.
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Il me semblait que l'on pouvait facilement retrouver la valeur de la clef du XOR si on xor 2 valeurs, ayant été "xoré". Je me trompe ? C'est le principe du 1 time padding, si jamais tu utilises 2 fois la clef, tu es mort.
"La première sécurité est la liberté"
[^] # Re: Journal bookmark inutile.
Posté par pasBill pasGates . Évalué à -2.
Si tu connais la valeur de base d'une autre valeur "xore" alors oui. C'est pour cela que je parles d'info leak : il ne faut pas que le kernel révele quoi que ce soit à propos de cette valeur.
Mais avoir 2 pointeurs encodés ne va pas te dire grand-chose (a part les quelques bits qui font la diffèrence entre kernel et use space + ceux pour l'alignement typiquement) car tu ne sais pas à quoi comparer.
[^] # Re: Journal bookmark inutile.
Posté par zurvan . Évalué à 1.
Très bien (même si je n'ai pas beaucoup plus compris), mais le monsieur en haut avait demandé un résumé en 2 phrases ;)
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Journal bookmark inutile.
Posté par totof2000 . Évalué à 3. Dernière modification le 21 janvier 2016 à 22:22.
Un résumé que le P.I aurai pu faire en 2 phrases :
"Je ne suis pas sufissamment calé techniquement pour comprendre les tenants et les aboutissants de cette faille. Les détais sont sur (lien), et si quelqu'un pouvait aider à décoder ce qui y est dit, il en est remercié d'avance."
# Android certes, mais Firefox OS
Posté par antistress (site web personnel) . Évalué à 5. Dernière modification le 20 janvier 2016 à 23:44.
On parle des distributions GNU/Linux, des distributions Linux Android mais quid des distributions Linux Firefox OS ?
D'ailleurs comment on peut sa version de Linux sur Firefox IS (ZTE Open C 2.6 nigthly pour moi) ?
[^] # Re: Android certes, mais Firefox OS
Posté par benja . Évalué à -10.
J'avoue que je ne parviens pas à comprendre la raison de l'émoi des utilisateurs d' Android. N'ont-ils pas déja vendu leur souveraineté digitale au grand marketing ? À quoi sert une escalation de privilège quand la porte est déja entre-ouverte ?
[^] # Re: Android certes, mais Firefox OS
Posté par fearan . Évalué à 9. Dernière modification le 21 janvier 2016 à 09:32.
Il y a une différence entre donner ses données personnelles au grand google, et laisser n'importe quel pirate vider ton compte en banque (achat in-app, espionnage de trafic web, remplacement des appli chrome/firefox de ton android ou des appli installé par des versions sniffant tes mots de passes ou clés privées…)
Bref même google à des limites, alors qu'un pirate pourrait remplacer ta sonnerie par du J. Beiber, te collant l'affiche dans tout le wagon de métro.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Android certes, mais Firefox OS
Posté par benja . Évalué à -6.
À ce que je sache, rien de ce que tu as cité nécessite d'avoir le compte root.
Mon étonnement reste entier…
[^] # Re: Android certes, mais Firefox OS
Posté par benja . Évalué à -7.
Afin de me défendre de troller, je vais reformuler (en passant donc le fait qu'Android est conçu pour nous transformer en produit commercial): comment peut-on raisonnablement avoir confiance en une technologie propriétaire et fermée ?
[^] # Re: Android certes, mais Firefox OS
Posté par fearan . Évalué à 10.
En gros tu te fous de notre gueule, tu ne vois pas de différence entre filer tes infos perso à une boite que tu connais au moins de nom, et installer une appli d'horloge qui promis ne fait que horloge (pas d'accès au stockage/réseau/comptes perso…) qui vide ton compte en banque et sniffe toutes tes données?
Oui google peut déjà le faire, mais lui est "de confiance", il est identifié.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Android certes, mais Firefox OS
Posté par benja . Évalué à -8. Dernière modification le 21 janvier 2016 à 10:19.
Non je ne vois pas la différence entre faire confiance à une horloge qui "promis ne fera rien" et faire confiance à une entreprise "de confiance" (sic), la dite entreprise qui ne s'engage, comme par hasard, à rien en cas de problème.
Je te dis que le problème viens de la méthodologie.
J'attends toujours une réponse à ma question. Vas-y, continues, je sens que tu avances dans ta démonstration; pas la peine de devenir vulgaire.
ps: je suis désolé de t'enlever tes illusions.
[^] # Re: Android certes, mais Firefox OS
Posté par Moonz . Évalué à 10.
Assez de théorie : en pratique, donne moi juste un exemple d’une entreprise type Google qui fasse un coup de pute dans ton dos de type ransomware (un truc qui arrive dans la vie réelle et qui justifie de s’inquiéter d’une faille de sécurité type décrite dans le journal)
Pour l’instant, le pire truc que m’ait fait Google c’est cibler les 2 publicités/an qui arrivent à passer à travers adblock. Je peux concevoir que ça emmerde certains, mais de là à mettre ça au même niveau qu’un ransomware, faut vraiment avoir un sens des priorités bien étrange.
[^] # Re: Android certes, mais Firefox OS
Posté par benja . Évalué à -10.
3 lettres… États-Unis d'Amérique… (Il y en a qui ont la mémoire courte quand même)
Donc tu as mon contre-exemple et la proposition de pouvoir faire confiance en un système propriétaire et fermé est tenue pour indémontrable.
Un système est démontré sécurisé et jusqu'à preuve du contraire. Ici, on me parle d'avoir "confiance" et de "sens des priorités"… Alors que rationnellement rien ne te permets de t'assurer de ta confiance, ni de contrôler l'usage que tu autorises par celle-ci. C'est absurde comme situation.
Moi je dis que l'on ne peut même pas avoir avoir confiance dans le dialogue qui nous dit qu'on peut avoir confiance dans l'application X (et donc encore moins à l'application X, mais ça c'est déja bien entendu), pour la simple et bonne raison que tu n'as ni la possibilité ni les moyens d'étudier et de contrôler son fonctionnement. C'est bon ? On a fait le tour de la question ? Ou on demande directement à google de nous concevoir les prochaines machines à voter ?
[^] # Re: Android certes, mais Firefox OS
Posté par fearan . Évalué à 10.
Et moi je te dis que tu n'as pas les moyens de contrôler que la machine que tu utilises est digne de confiance; même si tu as compilé toi même l'os après avoir vérifié le code source il te reste
Bref en quoi l'OS que tu utilises pour troller est il plus digne de confiance?
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Android certes, mais Firefox OS
Posté par Moonz . Évalué à 10. Dernière modification le 21 janvier 2016 à 11:27.
Ben justement, la sécurité c’est pas « confiance absolue » / « confiance nulle ». Si c’est ça ton approche de la sécurité, arrête tout de suite l’informatique (et même toute vie en société). On sait que la NSA a les moyens d’intercepter les colis Amazon pour mettre un mouchard dans le hardware du laptop que tu as commandé s’ils en ont vraiment envie, alors tu pense bien que ta sortie « je fais confiance au libre et pas au proprio », ça les fait bien rigoler.
La sécurité dans la vie réelle c’est confiance/pas confiance dans un contexte donné, pour un scénario donné, pour un attaquant donné. Oui, on sait que Android n’est pas de confiance pour l’attaquant NSA et le scénario « je veux garder secrètes des activités politiques sensibles ». Mais ce n’est pas du tout ce dont il est question ici ; ici le scénario c’est « je télécharge une appli sur l’AppStore, je ne veux pas me retrouver avec mes données chiffrées et un Russe qui me vend la clé pour 100€ ».
On s’inquiète de cette faille parce qu’elle fait passer le modèle de sécurité d’Android de « sûr » à « non sûr » pour ce scénario face à cet attaquant. Et ne t’en déplaise, pour l’écrasante majorité de la population, c’est ce scénario et cet attaquant la plus grande menace en pratique (et de très très loin), pas Google qui utilise tes données pour cibler la publicité (ça tout le monde le sait et s’en accommode ou s’en fout) ou la NSA qui t’espionne.
[^] # Re: Android certes, mais Firefox OS
Posté par benja . Évalué à -7.
Je complète:
- une appli dont je n'ai aucun moyen d'attester qu'elle n'est pas malveillante
- AppStore dont les règles de fonctionnement sont opaques, arbitraires et qui n'assurerait qu'une sécurité au finale toute relative (de l'ordre du placebo)
- mes données de valeurs qui se trouvent enregistrées dans le même téléphonnent que j'utilise pour installer la première application "horloge" qui passe.
Enfin bref c'est bien beau de venir me faire la leçon sur ce qu'est ou pas la sécurité, mais j'ai surtout l'impression qu'on ne veut pas voir la poutre que l'on a dans l'oeil. C'est pas comme si c'était la première faille de ce genre en plus… Mais non on persiste à ne pas vouloir regarder que le problème se situe au moment on l'on a décidé de faire tourner n'importe quoi dans son téléphonne et d'y enregistrer toutes sorte de données en croyant que l'on pouvoit garder un quelconque contrôle sur qui ferait quoi avec nos données.
[^] # Re: Android certes, mais Firefox OS
Posté par fearan . Évalué à 7.
Un appli dont les droit son connu et qui sauf faille de sécurité n'a accès qu'a un sous ensemble signalé du système, par exemple elle n'a pas accès aux comptes mail, ni le stockage de la carte.
Et toi tu viens dire que la capacité d'une appli a sortir de son sous ensemble restreint est sans incidence?
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Android certes, mais Firefox OS
Posté par Frank-N-Furter . Évalué à -2.
Depending on the time of day, the French go either way.
[^] # Re: Android certes, mais Firefox OS
Posté par Cioran_Naroic . Évalué à 1. Dernière modification le 21 janvier 2016 à 14:05.
Un seul exemple de système démontré sécurisé que tu utilises dans la vie de tous les jours ? Aucun.
[^] # Re: Android certes, mais Firefox OS
Posté par benja . Évalué à -3. Dernière modification le 21 janvier 2016 à 17:07.
C'est bien pourquoi je ne me permets pas de venir pleurnicher.
Après, les audits de code et la preuve formelle, cela se fait. Mais il faudrait déjà avoir le code en question et un moyen de l'utiliser…
Donc en bref, oui désolé j'ai plus confiance en du code ouvert qu'en du code fermé (qui plus est, contrôlé par une entreprise américaine qui n'a que pour seul objectif que de se faire du pognon sur mon dos), et oui cette confiance n'est pas absolue.
Mais bon je tourne en rond ici, je vais donc arrêter d'argumenter; c'est pas bon pour mon karma en plus.
[^] # Re: Android certes, mais Firefox OS
Posté par Zenitram (site web personnel) . Évalué à 1. Dernière modification le 21 janvier 2016 à 20:50.
Etant donné qu'il n'y a aucun CPU libre qui tienne la route dans la vraie vie, je me permet de te rappeler que tu fais deux poids deux mesures : tu refuses de faire confiance ç Google tout en faisant confiance au fabriquant du matos que tu as.
Je vais te faire peur : les deux peuvent faire exactement la même chose.
ta critique est juste de la connerie anti-proprio sans réalité, surtout pas ta réalité que tu utilises : tu nous dis de ne pas avoir confiance alors que toi-même y fais confiance (pas la même entreprise, mais le même principe).
Bref, tu racontes n'importe quoi, et le premier à qui tu mens en terme de fausse croyance d'être en sécurité car tu n'as pas "un OS proprio", c'est toi-même (ne pas avoir Android ne change rien à la sécurité de ton smartphone, il "craint" toujours de la même façon).
au fait, ton OS libre, tu l'as compilé toi-même? Regardé toutes les lignes de code? Si tu n'as pas fais ça, pourquoi avoir plus confiance en lui qu'en Android?
[^] # Re: Android certes, mais Firefox OS
Posté par benja . Évalué à 4. Dernière modification le 21 janvier 2016 à 21:23.
D'un côté on me reproche d'être noir/blanc alors que la sécurité est une science de l'évaluation des risques d'une perte comparé au coût de sa protection et non une science de la certitude, et maintenant tu me reproches d'être inconstant et de ne pas rechercher une sécurité absolue en applicant les mêmes mesures drastiques à deux menaces qui, excuse moi je crois que l'on peut au moins être d'accord là dessus, ne sont pas équivalentes. Bref à force de tirer, le troll va finir par s'user.
Là où je me plante, c'est effectivement d'avoir pensé qu'il était évident pour tout le monde qu'utiliser un smartphone comportait des risques relativement importants. Plus important qu'utiliser un os libre sur du matos pas libre. Voilà risque = chance, rapport cas (dé)favorables/# de cas, on peut se baser sur des chiffres objectifs pour l'évaluer avec plus ou moins de réussite. C'est certain que'à ne pas avoir de smartphone, je m'expose néanmoins au risque d'être la victime d'un spyware+exploit et/ou backdoor matériel sous mon matos/os actuel. Il est juste relativement très, très, faible. Loin derrière le risque de me faire aggresser devant chez moi parce que quelqu'un s'est suffisemment endetté pour achetter un téléphonne du bonheur. Et figures toi que je dors encore très bien. C'est dommage de voir que même sans la composante politique, i.e. le fait que google/grosse corporation n'en a foncierement rien à caller de ma "sécurité", mon discour soit si difficile à accepter sur le plan rationnel et technique.
J'ai encore l'ambition de terminer cette tâche. Le simple fait que d'autres et moi-même pouvons le faire augmente mon degré de confiance. C'est bien de ça dont on parlait ?
[^] # Re: Android certes, mais Firefox OS
Posté par Zenitram (site web personnel) . Évalué à -2.
Au cas où tu n'as pas compris, c'est justement la démonstration que tu es noir/blanc quand ça t'arrange et qu'en fait tu n'as rien à faire toi-même des commentaires que tu écris (tu ne te les appliques pas à toi-même).
Bon, tu te plantes sur bien d'autres choses en fait…
Ha ha ha.
Bon, vas-y, crois-y que tu es l'incompris face aux idiots…
(hint : ton discours n'est ni rationnel ni technique, c'est plutôt le contraire)
[^] # Re: Android certes, mais Firefox OS
Posté par benja . Évalué à 4. Dernière modification le 21 janvier 2016 à 22:36.
Pardon ? Dans un autre commentaire du me demande par "curiosité" la liste de mes choix, alors écoutes: je n'ai pas smartphone parce que je n'en ai pas l'utilité et que je trouves ça stupide voir néfaste: processus de fabrication inhumain, pollution, prône une forme de dé-socialisation, peu respectueux de mes droits et libertés, contraintes budgétaires, matériel décevant, pas possible de l'utiliser pleinement (car fermé et proprio), etc. C'est vrai que le principe de sécurité n'est pas sur cette liste mais c'est parce que je considère que la sécurité ne peut être que le produit d'un processus ouvert par opposition à proprio/fermé*. J'ai le même gsm depuis +6ans, le modèle basique qui a remplacé le précédent que j'ai malencontreusement égaré ou détruit. Je sais c'est pas libre, et qu'au niveau de la technique/sécurité c'est le pire de tous, mais on ne va pas me piquer mon numéro de CB avec. Est-ce pour ça que je n'applique pas mes propres principes ? Oui probablement, selon ta logique binaire.
Après je pourrais te répondre n'importe quoi tu vas quand même me ressortir ton argument : "ah ben tu vois, vu que tu ne fonde pas tes puces toi même, ben tout tes principes tu peux te les garder", ou me taxer de deux poids deux mesures, ou encore me la faire celle de "ah tu mets des mots dans ma bouche, je n'ai jamais dit ça" (ah non ça tu ne me l'as pas encore faite, je faisais attention… on va voir si ça passe toujours ici… :p)
Désolé: primo, ça n'est pas ce que j'appelle être pragmatique. Deusio: je crois que ce journal tient toute la substance factuelle dont on a besoin. La prochaine fois, je laisserai simplement un flyer pour la prochaine réunion des UAS (utilisateurs anonymes de smartphone).
*: point sur lequel je suis visiblement en désaccord avec tout le monde ici, c'est marrant à une autre époque le débat priorio/libre vs sécurité s'articulait de manière différente ici. Y a plus que pBpG qui a une discution sensée maintenant qu'il ne doit plus s'occuper des aspects idéologiques ;-)
[^] # Re: Android certes, mais Firefox OS
Posté par fearan . Évalué à 8.
Si tu vas dans ce sens là arrête toute suite l'informatique, Microsoft n'est pas plus digne de confiance que Google, ou même que Redhat, même un LFS peut être corrompu alors que tu as relu toutes les sources, le compilo peut s'occuper de rajouter les failles qui vont bien. J'ose espérer que tu ne bosses que sur du matériel fabriqué par tes soins, sur un réseau que tu peux contrôler de bout en bout…
Bref à un moment on décide de faire confiance, et si je fais confiance à google pour vendre mes données personnelle, je lui fais aussi confiance pour ne pas vider mon compte ou publier volontairement mes mots de passe ou coordonnées bancaires. Lorsqu'on installe une application android, il y a une liste de droit associés, (et je refuse un nombre considérable d'appli sur cette base là), si aucun droit n'est associé à l'appli (comme une horloge par exemple), je ne m'attends à ce qu'elle puisse siphonner mon compte, remplacer mes appli…
Attetion en droit français, un cluf dont des points sont léonin et expurgé des clauses léonines.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Android certes, mais Firefox OS
Posté par benja . Évalué à -6.
C'est l'hopital qui se fout de la charité là ;-)
Oui, je ne m'émeut pas pour une faille Android, mais non, je m'émouvrais bien s' il y a une backdoor dans RH ou gcc.
Car dans le premier cas, l'entreprise doit être supposée malfaisante, tandis que dans l'autre le degré de perversion est incomparable/inimaginable.
[^] # Re: Android certes, mais Firefox OS
Posté par fearan . Évalué à 5.
Trois lettre USA (deux commentaires plus haut)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Android certes, mais Firefox OS
Posté par benja . Évalué à -4.
NSA, ou en 7: Snowden. Bref on des documents concrets mouillants les "grands".
C'est vrai que l'on doit tenir red-hat aussi impliqué vu les obligations qu'elle doit tenir vis-à-vis du gouvernement américain. Néanmoins la vraissemblance d'une backdoor dans red-hat est proprement improbable et, de plus, détruirait toute leur crédibilité et leur commerce de manière tragique…
Bref, je retiens que le sens de la mesure ne doit s'appliquer qu'en fonction de sa religion, c'est consternant de lire ceci sur ce site.
[^] # Re: Android certes, mais Firefox OS
Posté par fearan . Évalué à 5. Dernière modification le 21 janvier 2016 à 12:18.
En fait tu ne fais pas la différence entre un état, un braqueur, une assurance; par contre une mutuelle c'est cool.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Android certes, mais Firefox OS
Posté par benja . Évalué à -4.
Heu… gni ? "Il dit qu'il voit pas le rapport."
[^] # Re: Android certes, mais Firefox OS
Posté par Antoine . Évalué à 5.
Comme pour n'importe quel éditeur de logiciels, libres ou pas.
[^] # Re: Android certes, mais Firefox OS
Posté par benja . Évalué à 1. Dernière modification le 21 janvier 2016 à 23:20.
Argument facile mais attendu. Aller, prenons un exemple, genre Macromedia/Adobe ? Au nombre de failles, on pourrait quasiment parler de backdoor. Bizarrement je n'ai jamais entendu parler d'une institution qui faisait tourner son "core-business" sur de l'action script. On est d'accord que la nature d'une relation client-entreprise est singulière à ce client et à cette entreprise et que ce n'est donc pas une constance au sein d'un même secteur d'activité ?
PS (pour le karma): Dans cette relation, il y d'autres composantes que cette confiance économique et rationnelle qui rentre en compte: par exemple il y a souvent une dimension psychologique mais aussi un aspect "prise d'otage" (aussi très présent en informatique) tel que la contrainte Oracle pour ne prendre qu'un exemple peu sujet à polémique, mais bon suivez mon regards… Bref la nature des relations que Red-Hat entretient avec ses clients me semble plus exposée aux conséquences d'un tel agissement, que d'autres de ses concurrents si on cherche vraiment à comparer. Mais bon ça n'est pas un gage de garantie absolue, ça déplace juste le curseurs du bon côté…
[^] # Re: Android certes, mais Firefox OS
Posté par Antoine . Évalué à 4.
Je suis d'accord. Mais cette relation ne dépend pas vraiment de la licence du logiciel. Je ne pense pas que Microsoft ait plus que Red Hat intérêt à mettre une backdoor dans le noyau Windows.
Et on peut trouver des logiciels libres ayant un nombre de failles aussi grand que Flash (qu'on pense à la grande époque de sendmail, ou à la multitude de bouses genre PHPNuke).
[^] # Re: Android certes, mais Firefox OS
Posté par zurvan . Évalué à 4.
Là tu fais dans l'idéologie, c'est ridicule. Comme dit plus haut, arrête l'informatique, outil du grand capital, et internet, outil de surveillance des masses.
Même s'il est légitime de questionner la prépondérance que peuvent avoir certains acteurs de l'informatique (apple, google, microsoft, facebook), et chercher à limiter sa dépendance à ceux-ci.
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Android certes, mais Firefox OS
Posté par benja . Évalué à -3.
Appelles cela comme tu veux, j'assume pleinement.
Venir pleurer que son téléphonne est troué alors qu'il est de notoriété publique que le dit téléphonne est déja sorti obsolète, ne sera jamais ou rarement offert la possibité d'être mis à jour et ce pendant une durée bien trop réduite, ne fonctionne qu'avec des logiciels fermés, et au bon vouloir d'un éditeur et du constructeur, etc. et ben moi je trouve cela complètement naïf, voir ridicule.
Visiblement cela ne caresse pas la majorité dans le sens du poil. :-D (rire démoniaque)
PS: je fréquence ce site justement parce que j'ai fais certains choix en informatique. Merci de ne pas tirer de conclusions sur ce que je fais ou devrais faire.
[^] # Re: Android certes, mais Firefox OS
Posté par zurvan . Évalué à 4.
d'ailleurs je ne vois pas pourquoi tu es venu cracher sur android alors que ce fil posait des questions sur firefoxOS
« Le pouvoir des Tripodes dépendait de la résignation des hommes à l'esclavage. » -- John Christopher
[^] # Re: Android certes, mais Firefox OS
Posté par benja . Évalué à -4.
Yes, Mea culpa d'avoir hijacké le thread d'antistress. J'ai lu "firefoxOS", j'ai cru qu'on était vendredi ;-)
[^] # Re: Android certes, mais Firefox OS
Posté par Zenitram (site web personnel) . Évalué à 2.
Par curiosité, lesquels?
Par exemple, ton choix sur Steam (très utilisé par les gens qui fréquentent ce site), ton choix sur l'OS, ton choix sur le CPU, sur le GPU, sur le BIOS, sur la carte réseau (ou radio), tous c'est endroits donc les gens qui fréquentent ce site acceptent le "proprio qui met des backdoors voir les 3 lettres magique" sur la majorité de ce que je viens de liste ce qui invalide ta hargne contre un point unique que j'ai cité (tous sont pareil : ils peuvent mettre des backdoor, surveiller… Chacun de son côté, du moment qu'il y a un contact privilégié avec la carte-mère)
Ici, pas mal de gens aime le libre mais n'en fait pas une haine du proprio (ok, il y en a, tout comme il y a des rigolos qui mettent une limite artificielle entre des logiciels "libre obligatoire" et "proprio? bon OK j'accepte" suivant le sens du vent, mais pour la grosse majorité ça mélange plutôt du libre et du proprio suivant ses choix persos et ce qu'il y a de dispo, sans cracher sur le proprio avec des critiques tout aussi valable pour le libre, genre "une backdoor" ben Debian peut en poser une sur tous les binaires qu'il délivre, ex-aequo avec Google)
[^] # Re: Android certes, mais Firefox OS
Posté par benja . Évalué à 4.
J'en fais pas un haine du proprio, j'écris si mal que ça ? Je dis juste que pour miniser les risques il y a une solution plus intelligente qu'utiliser un smartphone proprio et d'installer n'importe quoi dessus (et puis venir chercher des infos sur, tiens, un forum web).
Pour moi il s'agit d'une analyse rationnelle. Biensûr comme la pluspart des gens je fais des compromis, parfois parce que pas-le-choix, parfois par facilité/confort. Et ? Dois-je vraiment étaler la liste de mes choix avant de pouvoir écrire que faire une confiance aveugle à des processus industriels sur lequel on a aucune vibilité, aucun contrôle, qui sont réputés pour ne pas être fiables, qui ont des objectifs en conflit avec ma propre indépendance, semble naïf ?
J'aimes beaucoup ton pragmatisme, sauf que, pratiqué religieusement de la sorte, il n'en porte plus que le nom.
[^] # Re: Android certes, mais Firefox OS
Posté par groumly . Évalué à 8.
La probabilite pour que google siphone ton compte en banque avec des in app purchase, des sms surtaxes, te colles un ransomware et autres joyeusetes qui arrivent du cote obscure de la force est quand meme proche de 0.
Apres, si tu vois pas la difference entre quelqu'un qui veut te coller des pubs partout en restant dans le cadre legale et une mafia qui va te faire l'equivalent virtuel de te peter les deux genous parce que c'est des psychopates, je sais pas quoi te dire.
Linuxfr, le portail francais du logiciel libre et du neo nazisme.
# Faillie Android 180 day
Posté par Antoine . Évalué à 5.
Juste pour un point de comparaison amusant (et en rapport avec le fil de discussion du dessus), mon téléphone Motorola vient de se voir proposer une mise à jour Android pour corriger la faille "Stagefright". Cette faille a été devoilée publiquement il y a six mois…
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.