pasBill pasGates a écrit 16057 commentaires

La SEULE methode qui est valide, c'est une analyse statique du binaire compile pour s'assurer que son comportement est identique au binaire de reference.

C'est quelque chose qui se fait dans le monde de la securite pour diverses raisons (analyse de nos patchs pour y trouver la faille qu'on a patche par exemple…)

Ensuite, comme tu l'as dit, cacher un bug subtil est extremement simple. Et ca, tout le monde y est sujet, nous, openbsd, Linux, Chrome, Firefox…
Il est assez simple pour la NSA de regarder nos offres d'emploi, proposer un gars fort qui se fera engager et voila. Idem pour les projets open-sources ou ils prennent un gars qui envoient de bons patchs pendant un petit moment histoire de mettre la confiance, et hop un jour il insere un petit bug…

Informations techniques != code source

Possible (j'ai pas regarde dernierement), mais le fait est que pendant longtemps, le principal compilo du monde open source a eu ce comportement. Qu'on ne vienne pas me dire que c'est un truc fantaisiste / bug ou autre.

Pour le reste, j'imagines que bcp de gros softs utilisent du profile guided optimization, donc faudrait aussi filer ces fichiers de profile pour arriver au meme resultat.

Les différences sont :
- Taille critique Facebook, Google… ont été prié de filer des choses. pas l’agrégateur du coin.

Redhat c'est situe ou deja ? Ils ont combien de developpeurs qui posent du code dans le noyau et ailleurs ?
Mozilla et les developpeurs de Chrome, ceux qui developpent les principaux browsers pour Linux, tu sais les vecteurs principaux d'entree sur un systeme pour une attaque, ils sont situes ou eux aussi ?

- Si Linux sur le desktop devenait intéressant pour la NSA, plus de monde a potentiellement la possibilité de scanner.

a) Et les serveurs ca compte pas ? Et vu que le code entre les serveurs et desktops et en grosse partie le meme…
b) Le potentiel c'est sympa, mais on a tres bien vu ce que ca donne en pratique

C'etait le cas a l'epoque de gcc 3.x : http://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Optimize-Options.html

-fno-guess-branch-probability Do not guess branch probabilities using a randomized model.
Sometimes gcc will opt to use a randomized model to guess branch probabilities, when none are available from either profiling feedback (-fprofile-arcs) or __builtin_expect. This means that different runs of the compiler on the same program may produce different object code.

Les gouvernements d'habitude ne s'interessent pas a employer un exploit sur 3 millions de machines, c'est pour des attaques tres ciblees (un activiste chinois, un terroriste X, etc…) et ils savent d'habitude tres bien quel systeme cibler. Bref, c'est pas un probleme pour eux.

Pour le spammer qui veut se faire un botnet c'est different.

a) 100% d'accord avec ca. Tu remarqueras qu'avec ce modele, Linux est exactement a la meme enseigne.
b) Les gouvernements rapportent de temps en temps des failles, et certaines fois les gardent pour eux…

C'est drole.

En fait, la France, la Chine, la Russie, plein d'autres gouvernements et meme societes, ont acces aux sources.

Et pourtant, elles continuent toutes a utiliser ce Windows bourre de backdoors de la NSA.

Qu'est ce qu'ils sont stupides quand meme… Ils trouvent la backdoor, ok ils peuvent pas en parler a cause du NDA, mais ils continuent a utiliser l'OS !!!

Heureusement les gars de LinuxFr eux savent mieux qu'eux…

Mais quelle arrogance quand meme ici… c'est franchement dingue.

Le jour ou il sera possible de blinder 30 millions de lignes de code C/C++ tu me fais signe, j'ai un poste pour toi chez MS paye 10 millions par an(au moins). Et probablement un prix Nobel aussi.

Ton ordinateur est quantique, doté d'un générateur aléatoire pour générer les binaires ?
Cet argument me paraît mauvais, avec le même code source et la même version du compilateur je vois mal comment tu pourrais obtenir des binaires différents. Normalement il va optimiser de la même manière car c'est le même code !

Gcc le fait, cf. ma reponse a Zenitram. Comme quoi il faudrait penser a reevaluer ces "on-dit" traditionels que tout le monde repete mais que personne ne s'amuse a verifier dans le monde reel.

Si même config en entrée --> résultat différent, tu me fais peur. Microsoft met un rand() quelque part?

Tu devrais aller demander aux gars de gcc comment fguess-branch-probability fonctionne… tu vas etre surprise

J'ose imaginer qu'il y a une clé publique W pour vérifier la signature de celui qui se connecte, et donc sans la clé privée, je ne peux rien démontrer du tout de cette manière.
Raté.

Tu penses ? Tu crois que demontrer la presence de la cle publique dans le code et le fait que la verification ouvre une porte ne va rien montrer ?

Si poster les sources prouve quelque chose, alors poster le code assembleur venant du binaire officiel donne EXACTEMENT le meme resultat.

Mon argument n'est certainement pas plus fallacieux que cette connerie du compilo de Ken Thompson qui fait rire tout le monde dans le monde de la securite.

Le kernel Linux, avec les drivers, c'est des millions de lignes de code. L'OS entier encore plus. Idem pour Windows.

Faudrait vraiment etre con pour s'emmerder a inserer une backdoor dans le compilo alors qu'il suffit d'inserer un petit integer overflow qui ressemble a une erreur quelque part dans ces millions de lignes.

La question est de savoir si on arrive à avoir exactement le même binaire (même SHA-512) de chaque fichier.
Si un bit change, tout ce qu'on peut dire c'est que le source filé est bon, mais on ne peut rien dire sur le binaire filé (qui peut s'être pris un .patch dans un coin).

Bien qu'en theorie vrai, c'est en fait faux.
a) Le header par exemple va changer (il y a un timestamp dans le header PE)
b) Le compilo(meme version du compilo, memes sources) pourrait optimiser de maniere differente le code

La seule maniere c'est de faire une analyse statique du code binaire entre les 2 fichiers et s'assurer que le code execute a le meme comportement.

Personne avant Snowden avait senti le besoin de dire que PRISM existait, sans doute à cause de ce qu'il lui arrive en ce moment (pas forcément agréable de vivre dans une zone internationale d'aéroport russe, tout comme il n'est pas agréable d'être bloqué dans une ambassade), peux-tu dire sans mentir que la personne qui postera une telle démonstration ne se prendra pas les foudres des Etats-Unis avec la même violence juste parce qu'il a osé le dire?

Je bosses pour X(gouvernement, universite, entreprise…), j'ai acces aux sources de Windows. Je decouvres la backdoor. Je prends un binaire officiel (DVD de Windows), et je decris comment trouver la faille a partir du binaire officiel. (= impossible de tracer que j'ai acces aux sources)

Je me crees un compte sur mail.ru ou mail.cn, je m'installes une VM toute propre, je prends ma voiture et me gare a cote d'un café avec acces Wi-Fi ou autre, je postes la description sur tous les forums que je veux.

Bonne chance pour me retrouver.

Pas tout le monde. Bien que ton argumentation se tienne, quelqu'un qui publierait ces sources enfreindrait un NDA et donc la loi. Peut-être que le Snowden du source code ne s'est pas encore manifesté !

Super !

a) Et tu crois que tout le monde lit les sources de Linux ?
b) Poster une maniere de trouver cette backdoor de maniere anonyme sur le net("regardez le binaire xyz, si vous passez les parametres a et b a la function p, ca declenche la backdoor" par exemple) est on ne peut plus simple et sur
c) "Pas encore" ? C'est quoi cette connerie ? On est coupable jusqu'a ce qu'on soit prouve innocent ?

1) Plein de gens ont acces aux source de Windows depuis des annees (oui, avec possibilite de recompiler, etc…) a travers toute la planete, pas une personne n'a encore senti le besoin de poster en ligne cette soi-disant backdoor(normal, elle n'existe pas), pas un gouvernement sur cette planete a decide d'eliminer l'usage de Windows.

Aucune idee de ce qu'est ce truc, faudrait regarder une trace reseau et voir ce qui merde. Ca pourrait etre l'authentification par exemple, ou autre, dur a dire comme ca.

Moi ce que je vois :

• Meme noyau
• Memes softs
• Binaire sur l'un peut tourner sur l'autre (memes syscalls, memes librairies, …)

Bref, c'est vraiment le meme OS a la base, juste configure differemment ou avec des binaires de versions differentes. Il n'y a aucunes differences architecturales ou incompatibilite binaire.

Ce sont des classes, qui se trouvent dans une "assembly" (l'equivalent d'une librairie en .NET en gros).

Il y a 2 manieres pour Powershell de les retrouver :
a) Registration, tu peux "enregistrer" l'assembly, ce qui fait que Powershell saura quels cmdlet sont dans quelle assembly
b) Tu utilises "Import-Module" qui charge dynamiquement une assembly contenant des cmdlet. Powershell v3 rend les choses encore plus simples car il importe automatiquement tous les modules qui se trouvent dans le path qu'il a

Pour le vase clos, tu peux toujours lancer des softs non-cmdlet, simplement ce qu'ils retournent ne sera pas structure.

Ben justement non…

Avec Powershell, tout cela est implemente avec un threadpool, dans un processus, t'as un nombre limite de threads cree, tout est propre.
La methode de lancer un ssh par machine, sur un reseau de 5000 machines par exemple (et 5000 c'est vraiment pas enorme, surtout avec la manie d'aujourd'hui de virtualiser tout et n'importe quoi), ca te cree … 5000 processus !
Ca te met la machine a genoux tout de suite, parce que ces 5000 processus il faut leur allouer de la RAM, rien que la stack prend 2mb par thread par defaut sur Linux x86(en tout cas Redhat). Et c'est sans compter le fait que tu n'as aucun moyen de savoir lequel des processus s'est rate sans faire une tambouille bien sale alors qu'avec Powershell t'as un systeme de retour d'erreur bien propre pour chaque tache cree.

Resultat, avec bash/tcsh, il faut te taper la gestion en batch a la main, faut te trouver un moyen de retourner les erreurs pour chaque processus plutot que le dernier comme wait le fait, … bref, c'est le bordel.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms714395(v=vs.85).aspx

Une "commande" powershell est un cmdlet, n'importe qui peut les ecrire, ils s'ecrivent en .net et derivent d'une classe parente nommee… cmdlet.

L'utilisateur ecrit tout ce dont il a besoin la dedans : il definit les parametres, fait ce qu'il faut pour arriver a resultat(il peut faire des connections reseau, lire la registry, faire des appels DCOM, interpreter un parameter en ligne de commande comme etant un script dans un langage donne, invoquer des poupees voodoo etc…), et retourne un objet qui contient le resultat.

Oh, et un truc bien sympa dans Powershell, il permet de tirer parti de toute l'infrastructure asynchrone presente dans .NET :
Tu veux la liste de tous les softs installes sur toutes les machines du reseau, ben pas besoin que le script fasse une machine après l'autre, il peut faire les requetes en asynchrones sur toutes les machines, les resultats arrivent quand ils arrivent et il suffit de faire un 'wait' a la fin sur tous les resultats pour avoir le resultat final. Ca amenera le resultat enormement plus vite qu'un script qui fait une machine après l'autre. Bonne chance pour faire un truc pareil en bash/tcsh…

Mais tu vas le voir comment ?

Si ils rajoutent une colonne qui contient un entier devant une autre colonne qui contient un entier, ton script il ne va pas planter, il va juste te filer le mauvais resultat, et selon ce que le script fait, tu pourrais:
- ne rien voir pendant des semaines alors que le script te fait perdre/endommager des donnees lentement mais surement
- t'en rendre compte tres vite sans dommages
- t'en rendre compte parce que la moitie de ton parc a disparu du reseau et tous tes utilisateurs hurlent.

C'est un vrai cauchemard ce genre de truc, surtout le 1, parce que bonne chance pour aller debugger tes scripts qui s'appellent les uns les autres, et arriver a comprendre ce qui se passe exactement.

C'est pas pour rien que les interfaces definies et solides sont importantes, que les donnees structurees sont importantes, c'est justement pour eviter ce genre de bordel. Si le format n'est pas bon ca plante, ca ne corrompt rien. Si l'interface est definitive, ca ne plante pas.

Un script qui plante un jour, suite à une montée de version. Mais facile à corriger.

Il plante ? Ou il te rend le mauvais resultat sans que tu t'en rende compte, ce qui est infiniment plus grave. Surtout selon ce que le script fait.

Euh… tu regardes la liste que tu donne sur la page, tu regardes la derniere colonne, c'est ecrit hein. 13/27 creent du MSI. Les autres font leur proper sauce, mais au final stockent ce qu'ils doivent au bon endroit. Ils ne remplissent probablement pas la base MSI par contre.

D'après toi, quels sont les logiciels d'empaquetage qui ont le vent en poupe actuellement sous Windows ?

MSI est le format de loin le plus utilise. Install Shield et WiX semblent etre les installers les plus souvent vus de mon experience.

df c'est posix, eh, ps aussi c'est posix, va donc lancer cette commande sur 3 Unix differents et dis moi si la sortie est identique…

Pour dpkg : https://launchpad.net/debian/+source/dpkg/+changelog

1.16.5

Superseded in sid-release on 2012-07-02

Add an Architecture column to «dpkg-query -l» before the Description column

Je te laisse imaginer ce que ce genre de changements aurait eu comme effet sur un script utilisant awk ou cut

T'as remarque que ma commande ne comportait pas la liste des attributs mais un '*' ? Pas besoin de tous les lister

Une entrée par ligne, ça revient exactement à un objet avec des membres.

Pas trop non, il y a les dates, tailles, etc… qui sont des attributs aussi. Ensuite sous tcsh/bash/… il faut arriver a les lier a l'element de depart quand tu les passes d'une commande a l'autre, etc… Compare a Powershell c'est totalement primitif