benja a écrit 1211 commentaires

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.

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.

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 ?

EDIT2: tu l'as en fait cette version…

Sorry je n'avais pas vu que tu avais copier ton sources.list, tu as effectivement la section non-free d'activée. C'est un bon début :p
Essaye quand même d'abord de voir si ça marche avec le pilote nvidia. Il peut y avoir aussi un réglage dans le bios pour forcer l'utilisation de telle ou telle carte graphique.

PS: la version du pilote intel que tu mentionnes est entre-temps passée de "experimental" à "sid" aka "unstable", cf. https://packages.debian.org/sid/xserver-xorg-video-intel . De tout de façon pour utiliser experimental, tu as besoin d'être en unstable avant.
EDIT: cette version est même aussi dans jessie-backports… donc bon tu es sensé déja l'avoir. as-tu mis à jour récemment ?

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.

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 ?

À ce que je sache, rien de ce que tu as cité nécessite d'avoir le compte root.
Mon étonnement reste entier…

As-tu le paquet nvidia-driver installé ? Peut-être te manque-t-il la section "non-free" dans ton fichier /etc/apt/sources.list (en plus de "main" et "contrib") ?
https://packages.debian.org/jessie/nvidia-driver

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 ?

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é…)

Si le compteur ne fuyait pas tu pourrais pas l'overflow car tu te mangerai le Out of Memory Killer bien avant ça.

Tu n'aurais, au contraire, rien du tout :p

Reste plus qu'a déclencher un syscall

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 appelle keyring->type->revoke(), il pourrait appeller keyring_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 deux trois 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…

1) La proposition impossible car complétement anti-performante

Impossible…?? C'est pas un peu le principe de udref ? Et les micro noyaux ?

http://aarddict.org/
Permet d'indexer et d'utiliser wiktionary off-line.
Je ne saurai en dire plus quand à la hackabilité de le leur bibiothèques python ou simplement de la réutilisation de leur fichier d'indexation, simplement que leur visionneuse marche toujours très bien chez moi et que la procédure d'indexation a duré une petite nuit sur un portable plus tout jeune (avec les version de septembre 2014, donc v1 et format aard cf. http://aarddict.org/1/aardtools/doc/aardtools.html ).

Apparemment maintenant, ils utilisent un autre format (slob) et ils fournissent des dico préindexés.

Slob format design is influenced by Aard Dictionary’s aard and ZIM file formats. Similar to Aard Dictionary, it allows to perform non-exact lookups based on UCA’s notion of collation strength. Similar to ZIM, it groups and compresses multiple content items to achieve high compression ratio and can combine several physical files into one logical container. Both aard and ZIM contain vestigial elements of predecessor formats as well as elements specific to a particular use case (such as implementing offline Wikipedia content access). Slob aims to provide a minimal framework to allow building such applications while remaining a simple, generic, read-only data store.

(* https://github.com/itkach/slob )

Bref, je ne saurais que te conseiller d'aller aussi étudier cette solution et de revenir ensuite partager avec nous les résultats de tes investigations ;-)

Au pire on peut peut-être tomber sur un tail < head, ce qui peut facilement être détecté par main.

Je me re-réponds à moi-même: dans ce cas ça ne marche évidemment pas car on utilise tail < head pour détecter un wrap… Désolé pour le bruit.

Ton alogithme me semble de loin similaire à ce que j'ai écris, il serait bien que tu l'écrive en formules et que tu le simplifie en suite. Le problème c'est que tu parles d'index, de status, etc. et au final tu te retrouve avec 4 variables écrites par les deux routines, ce qui est une recette pour un désastres et qui t'oblige à suspendre les interruptions (ce qui cf. les messages de a2g n'est sans doutes pas une mauvaise idée).

Au final, ton "index" vaut head pour le lecteur et tail pour l'écriveur… sz (== la taillle à lire) est calculée justement en faisant la différence des deux (ou en prennant le cas du wrap). Le lecteur se sert de tail pour avoir une estimmation de jusque où il peut lire, et tail utilise head pour savoir jusqu'où il peut écrire… Bref 2 variables, chacunes écrites une fois par chaque routine. Pas besoin de statuts vide, plein, demi-vide ou demi-plein ;-)

Ok j'ai fini de lire ton sus-cité message dans son intégralité :-P Merci j'ai eu ma réponse et je me coucherai moins ignorant ce soir!

Pourquoi désactiver les interruptions dans getreceiveddata ?

Ok lu ton message plus bàs, donc ce serait parce que c'est une quantité de 16 bits sur un micro 8 (en plus du fait que tes 2 routines modifient la mêm variable)? Admettons mon algorithme, est-ce vraiment un problème ? Par exemple si on écrit d'abord les bits de poids faibles, et comme la valeur est monotonique, on ne risque jamais d'avoir un "tail" qui pointe trop loin. Au pire on peut peut-être tomber sur un tail < head, ce qui peut facilement être détecté par main. Ça me semble bon, non ? Ou me tromperais-je ?

Ok. C'est plus simple de raisonner sur un code fonctionnel :-)

Pourquoi désactiver les interruptions dans getreceiveddata ?

Avec mon algorithme 1) copier tail dans une locale 2) calculer sz/freesz; il n'y a pas de problèmes vu que head n'est jamais touché par l'interruption. En gros à mes deux questions tu réponds: "je ne sais pas, j'empêche au cas où…".

Pour désactiver les interruptions dans le gestionnaire d'interruption tu as sans-doutes raison d'insister sur ce point, j'imagine qu'un avr est trop petit pour avoir un interrupt controller qui gère les priorités entre les interruptions. Mais cela dépend vraiment de la platforme et de comment qu'on programme l'IC, ça n'est pas toujours nécessaire.

À part ça, merci pour partager ton code. J'aime bien l'idée d'utiliser un masque pour gèrer le clamping, peut-être qu'il serait encore plus malin de le définir en puissance de 2 (2 << POWER) pour éviter une bête erreur, fin bon ça c'est du détail…

en tout cas merci pour ces indications qui me feront avancer. J'ai une ou deux idées que je vous présenterai si ça vous intéresse.

Tout à fait! Merci d'avance :)

Salut a2g,

Merci pour ton input et tes idées.

Il y a-t-il un risque que main utilise une mauvaise valeur de tail ? Idem, non je ne crois pas.

Et bien si!

Je crois que tu souffres du même problème que j'ai à lire les messages dans leur intégralité: deux lignes plus loin j'écris exactement la même chose que toi concernant sz/freesz avec en substance le même message que tu aides à faire passer du coup, parfait ;-)

Ici j'évoquais le problème que main pourrait avoir à avoir une valeur de tail moins actuelle: donc soit une estimmation trop petite du nombres des données, soit ne pas détecter un wrapping qui sont tous deux sans conséquence.

L'objet de mon message étant quand même d'insister sur le fait que mettre volatile à tout bout de champs n'est certainement pas une bonne idée… Bref, pas de volatile du tout avec un code proprement découpé en fonctions couplé d'une inspection de l'assembleur généré est une possibilité tout à fait viable et bug-free !

Ici il n'y a qu'une variable suceptible d'être modifiée par dessous le tapis -> pas besoin de mutex.

J'entends bien "par un seul des agents"… Évidemment si plusieurs agents (ou contextes d'exécution) modifient la même variable, il y a besoin d'une synchronisation.

note cela concerne quiconque a utilisé le client OpenSSH, à la louche 90% des utilisateurs (j'en laisse 10 à putty et 0,0001 à lsh et autres gnueries) ET qui s'est connecté une fois sans utiliser un agent ssh (donc soit avec ssh -i maclef ou avec ~/.ssh/id_rsa ce qui correspond aussi à la louche à plus de 90% des utilisations) à un serveur compromis ou malicieux …
En gros 99% des gens qui utilisent un prestataire d'hébergement (vps, etc.) peuvent changer leurs clefs et auditer tous leurs serveurs… :p

Ou quiconque qui a subit un MitM et qui a accepté la nouvelle clef du serveur (mais bon là ça veut dire qu'on l'a bien cherché).

Ouais euh ici la faille concerne le client, pas le serveur. Donc dropbear ou pas ça n'a rien à voir, il n'y a pas de client dropbear (afaik).

"The authentication of the server host key prevents exploitation
by a man-in-the-middle, so this information leak is restricted
to connections to malicious or compromised servers."

Donc le risque c'est d'avoir subit un M-i-M et d'avoir accèpté la clef du serveur malicieux. Où de s'être connecté à un serveur compromis, sans agent-ssh (i.e. avec ssh -i maclef, ou en utilisant la même .ssh/id_rsa partout).

J'espère que personne ici utilise la même .ssh/id_rsa pour se connecter à différents serveurs ;-) Ċa pue quand même cette faille…

Amha le problème c'est que le client ne fait pas de dhcp-release avant de basculer, du coup dhcpd pense que l'ip est toujours utilisée. Sur les exemples glannés sur internet ils rajoutent la directive hostname, est-ce que cela change qq chose ? En tout cas chez moi ça marche avec openwrt/dnsmasq. Et visiblement selon internet isc-dhcpd peut le faire aussi (et le faisait même avant).

Pour complèter un peu au sujet des mutex.
Ici il n'y a qu'une variable suceptible d'être modifiée par dessous le tapis -> pas besoin de mutex.

S'il y avait plusieurs valeurs à lire, alors dans ce cas tu es obligé de trouver un mécanisme de synchronisation, pour t'assurer qu'il n'y aie pas eu d'interruption entre le moment où tu as lu la première valeur et la dernière. Dans ton cas, un simple compteur de génération devrait suffire car tu as la certitude que celui qui incrémente le compeur ne peut pas être interrompu. Sinon tu devras passer par un compare-and-swap, mutex ou rcu (mais bon là on est loin du cadre du dévelopement de micro-controlleurs).

Au sujet des volatile: le volatile ne sert qu'à "forcer" la lecture en ram, ce qui n'est que (probablement) uniquement nécessaire dans le cas d'une boucle, pas si tu lis les valeurs dans le prologue d'une fonction (car le compilo ne peut pas supposer que telle valeur sera déja présente dans un registre, sauf si tu utilises un compileur qui fait de l'analyse globale avec un -O42 et -f-i-dont-care-about-c-standard).
Par contre pour le cas d'un compteur de génération, c'est peut-être mieux de le mettre en volatile car tu veux probablement "forcer" une lecture à chaque fois qu'il est utilisé. L'important c'est de bien raisonner en fonction de ton code-flow. Si une lecture détermine un chemin d'exécution particulier alors de deux choses l'une: soit tu ne veux probablement plus réutiliser sa valeur et dans ce cas un volatile est OK, soit tu veux réutiliser sa valeur plus tard et un volatile n'est absolument pas OK! Dans le cas d'un compteur, il faut voir sa valeur comme une valeur à un instant T, chaque fois que tu vas le lire, c'est par définition une valeur différente.