pasBill pasGates a écrit 16225 commentaires

Alors cela s'est bien amélioré, il faut quand même le dire mais … nombre de fois ou Outlook / Office (toutes versions confondues) et plein d'autres produits merdoie lamentablement et de manière bizarre ce à quoi je répond … reboot on en parle après … et que l'on en parle plus

Tout ce que cela signifie est que tu es incompétent pour administrer ces systèmes, et rien d'autre.

mais c'est pareil sur les serveurs … un produit mal écrit, ou du réseau pas franchement stable et tu peut être sur d'avoir des trous dans la mémoire

Non vraiment, arrètes de t'enfoncer, ce que tu écrit est totalement ridicule et faux.

Tu m'excuseras de trouver ce commentaire ridicule…

Mozilla a certainement plus fait pour répandre les LL sur la machine de Mr tout le monde que n'importe quel autre projet libre à part Android.

Que ces dirigeants là doivent être remplacés, je ne vais pas juger, je ne suis pas assez Mozilla pour juger.

Mais il est certain que si ils doivent partir, alors il faut les remplacer par un vrai CEO et un vrai CFO, pas par un comptable et une secrétaire…

Mais cela n'a RIEN à voir que le but soit lucratif ou pas !

Développer l'écosystème du libre, faire que Firefox se répande, etc… cela demande les même compétences, cela demande des contacts, … c'est la même chose. Simplement l'objectif final est diffèrent.

Si tu crois qu'enlever ces rôles pour y mettre un comptable et une secrétaire sera une avancée positive c'est que tu n'as pas compris grand chose aux interactions à ce niveau entre larges sociètés. Le résultat sera un désastre.

Je n'ai parlé que du président de la MoFo, du trésorier, du directeur, etc.
Ce sont des fonctions classiques d'administration et je ne vois pas pourquoi cela mériterait un salaire d'un million de dollars par an.

Faut revenir sur terre hein… un CEO ou un CFO ce n'est pas une secrétaire et un comptable !

Ces gens là font bcp, bcp plus que de la simple administration. Ils développent la vision de la boite sur plusieurs plans, ils utilisent leurs réseaux de contacts pour aider la boite, ils savent manager des groupes larges de manière efficace, … Ce n'est pas un boulot simple.

Il y a une bonne raison pour laquelle ils gagnent plus que n'importe quelle développeur. Ca ne veut pas dire non plus qu'il est justifié de les payer 23 millions par an comme certaines boites, mais ce sont des gens très importants pour la boite qui ont certainement une valeur ajoutée.

Croire que tu peux les remplacer par un gars a 100K/an, réutiliser le reste pour payer des devs et que tout sera mieux c'est vraiment se mettre le doigt dans l'oeil très profondemment. Il n'y a pas que le technique qui importe dans une boite hein… et je dis ça en tant qu'ingénieur.

Ben oui t'as tout à fait raison.

Il y a doute, un gros doute.

Ensuite, effectivement on peut y croire, ou pas.

On peut aussi croire que ce sont les extra-terrestres qui sont en charge de toute d'ailleurs, voire Satan.

Ou même Donald Duck pour certains, la probabilité est la même.

Et encore, si ce n'était que ça…

Mais il a aussi empeché Linux de vaincre sur le desktop !!!

Quelle enflure !

Aucune contradiction.

Ne pas vouloir être considéré comme responsable de la découverte de failles par des blackhats != vouloir sécuriser la planète

Obliger à concourir avec des béquilles? Tu te fiches de qui là? MS n'obliges personne à quoi qu ce soit. Il ne donnent pas leurs outils internes c'est leur choix, rien n'empêche les autres de développer eux même, se mettre ensemble pour développer… des outils.

Faudrait quand même arrêter avec cette obsession a vouloir critiquer MS à tout prix, ca en devient pathétique.

Bill Gates a en partie écrit le BASIC de l'Altair entre autres. De l'assembleur sur une machine de ce type, on va dire que c'est légerement plus bas niveau que ce que 90% des gens sur linuxfr font :)

Dépend comment tu vois ca. SAGE a aidé à sécuriser des softs comme Word, Excel, Windows,… et a trouvé un sacrément large nombre de bugs dedans durant leur développement. Quand tu penses au nombre d'utilisateurs de ces softs, je te dirais que très peu de fuzzers ont eu un tel impact.

Maintenant, est-ce qu'il aurait pu avoir un impact bcp plus large en étant public, c'est évident que oui.

C'est là ou tu as tout faux. De nouveau tu fais des supputations sur ce que tu ne connais pas.

J'ai passé la majorité de ma carrière à faire des fuzzers oui. Je n'étais pas dans l'équipe qui a fait SAGE par contre. C'est une autre organisation. Mes fuzzers étaient du type pseudo-aléatoire et pas des solveurs.

Je n'ai aucun intérêt personnel à aller dire que SAGE est le top du top. Ce n'étais ni moi ni mon groupe et ce n'est plus ma boite depuis 2 ans. C'était plus proche d'un concurrent a mon travail qu'autre chose mais je regarde la chose honnêtement, c'est simplement un constat de ce que j'ai vu.

Mais visiblement tu as du mal à accepter une opinion qui va contre la tienne.

Ton opinion biaisée à l'emporte pièce sur MS, on va dire qu'elle vaut ce qu'elle vaut tu sais…

Belle idée, on y avait réflechi (pour des outils autres que SAGE), et au final ce n'était pas faisable car :

a) Il faudrait un moyen de s'assurer que la personne est vraiment l'auteur du soft --> etape manuelle et couteuse

b) Il n'est vraiment pas simple de supporter un utilisateur qui n'a pas acces au soft, donc pas la possibilité de voir tout ce qui se passe de près, à moins d'investir sérieusement dans l'UI, logs, etc… il fera régulirement appel au support, et c'est chiant

c) Il faut gérer le cas ou le gars te fait un upload de son soft qui n'est qu'wrapper qu'il utilise pour tester le soft de qq'un d'autre, pas simple

d) C'est bien trop d'efforts pour un truc qui au final n'est pas le coeur de métier de l'organisation ou j'étais. Cette org ne s'occupe pas de sécuriser la planète, mais les softs et services MS.

C'est pourtant simple. MS a des dizaines et dizaines d'ingénieurs sécurité et a (avait ?) des milliers de testeurs, dont l'objectif est de trouver des bugs.

Vu l'objectif, ils essayent évidemment tout ce qui se trouve à l'exterieur, car c'est évidemment plus facile d'utiliser un truc existant qu'un truc qui n'existe pas et qu'il faut écrire. Il y a d'autres contraintes qui entrent en jeu aussi, genre le support disponible, possibilités d'intégration, voire même la licence, mais évidemment que les groupes sécurité MS regardent tout ce qui est publique est recommandé publiquement, ils ne sont pas stupide.

Non, c'est l'exploration des chemins qui prend un temps infini, l'exploration des branches est réalisable.

Oui, mauvaise utilisation de termes, c'est évidemment les chemins que SAGE suit.

Pour quelqu'un qui a passé 8 ans à travailler avec c'est un normal quelque soit le logiciel.

Ah si seulement c'était vrai, ca me ferait plaisir…

C'est quoi le plan vu que tu a était dans le secret des dieux ? Se toucher la nouille en expliquant qu'on a la plus grosse mais en la cachant du mieux que l'on peut ?

T'as raté la partie ou MS Research a publié plusieurs papiers décrivant ce qu'ils font ?

Il n'y a que le code source qui compte maintenant ?

Non il est en interne uniquement.

Pour ce qui est du coté "vaporware", ben tu peux croire ce que tu veux… ou voir des choses genre http://talosintel.com/files/publications_and_presentations/presentations/Fuzzing_and_Patch_Analysis-SAGEly_Advice.pdf

qui, oh surprise, est une tentative de réimplementer SAGE en open source… par qui ? Par un ancien ingénieur sécurité de MS (ancien collègue à moi plus précisement) qui est maintenant chez CISCO.

On se demande pourquoi, après avoir quitté MS, il essaierait de réimplementer un vaporware…

Ou https://www.syscan360.org/slides/2012_EN_SecurityEngineeringAndProductImprovementsInTheNewOffice_TomGallagher.pdf avec le manager securité d'Office décrivant l'utilisation de SAGE pour Office.

Conspiration globale à travers la boite, et même les ex-employés pour vanter un outil interne qui n'existerait pas ?

On va dire que c'est plutôt amusant comme idée, mais pas très réaliste.

oui, et afl qui a mouliné quelques jpg a trouvé de nouveaux bugs dans des produits microsoft. OMG! le fuzzer le plus perfectionné au monde qui ne travaille pas au hasard et qui prend tous les branchements de code aurait laissé passé un bug? Mais comment est-ce possible?

Comment ? Ben en comprenant que les branches ca ne fait pas tout, et qu'explorer toutes les branches prend un temps infini. C'est pas pour rien qu'au premier post j'ai parlé d'asymptotique.

afl, tout simple et bête qu'il est, va être capable de dire, tiens le chemin d'exécution:
a() -> b() est différent de b() -> a(). Et différent de a() -> a() -> a() -> b() -> a() -> crash!

Parce que tu crois que SAGE ne connais que a()->b() ? Mais tu n'as vraiment rien compris à SAGE mon cher ! Il suit l'execution depuis le debut du processus, il ne se limite pas un subset.

Sage, ça reste ardu à mettre en oeuvre. Les équivalents, idem. C'est lourd, c'est long, ça demande un temps délirant à démarrer et il faut 25 ingénieurs qui le surveillent en permanence.

Mais arrètes de raconter n'importe quoi… SAGE c'est un répertoire avec executables et libraries, c'est un executable a lancer avec diverses options, tu mets 1h grand maximum à comprendre comment le lancer et quelles sont les options principales, et tu peux le lancer à l'aveugle avec des options de base en 5 minutes.
C'est quand même dingue… tu ne l'as jamais utilisé, et tu essayes d'expliquer à un gars qui l'a utilisé de manière répetéee comment il marche…

Combien d'années de recherches à MS? Combien d'années.hommes? Et tu as afl. Quelques semaines de taf d'une personne. Nombre de bugs trouvés: énormes. Il faudrait que MS research porte afl sur leurs produits et teste un coup. Je serais très curieux du résultat.

C'est ta naiveté qui te fait croire que MS ne connait pas AFL et ne l'a jamais utilisé et testé ?

Ce n'est pas spécialement "pour te protèger" (quoique ca joue un peu), mais plutôt pour "que tu ne me fasses pas la gueule quand ils t'attaquent, et que je n'aie pas l'air con si ils trouvent des failles dans mes propres softs"

Rien à voir avec l'avantage concurrentiel. J'ai vécu la chose personnellement, je suis sur à 100% de la raison. Je ne l'aime pas beaucoup, mais je la comprend d'un point de vue business.

Si SAGE donnait de bons résultats, ce serait un produit connu, vendu et/ou livré avec Visual Studio.

LOL, justement non. MS ne fera jamais cela, pour la même raison qu'aucun des outils que j'ai développé là-bas n'a été publié.

Si MS publiait un outil offensif comme SAGE ou autre fuzzer non ridicule (ils ont publié un minifuzz qui était un gros gag et qui ne trouvera jamais rien de sérieux, il a été publié principalement pour que des débutants puissent gentiment se mettre à faire des tests de sécurité) les gens utiliseraient un outil MS pour attaquer des softs d'éditeurs et clients de MS, voire des softs MS. MS ne veut certainement pas entuber tout le monde en faisant ca, et n'a certainement pas envie que des gens trouvent des failles dans ses softs, avec ses propres outils d'attaque.

Et pour le premier guignol qui voudrait sortir "si ils avaient fait tourner ces softs eux-même personne ne trouverait de failles dans les softs MS", j'invite ce guignol potentiel à s'informer et comprendre comment des softs qui doivent explorer un espace de recherche infini fonctionnent.

En fait même s'il donnait des résultats moyens, vu que Microsoft n'a aucune hésitation à sortir des trucs honteux lorque l'occasion se présente (je pense en particulier à Microsoft Dynamics NAV, anciennement Navision, car je l'ai connu, mais il y a bien d'autres exemples).

Ce que j'aime chez toi c'est cette force à parler de trucs dont tu ne connais rien et dire qu'ils sont à chier.

T'es gentil :)

Je te rappelle donc que j'ai passé 13 ans à MS. A peu près 8 de ces années ont été passées à construire des fuzzing frameworks et fuzzers. SAGE j'ai revu son design, je l'ai utilisée de manière répetée moi-même, j'en ai parlé avec les auteurs directement, j'en ai parlé avec des dizaines de testeurs et ingénieurs sécurité qui l'utilisent, j'ai vu les bugs qu'il a trouvé, je sais exactement comment il fonctionne et ce qu'il faut pour qu'il fonctionne.

Pour résumer, on a Sage qui est apparemment génial, qui demande un bac+18 pour être mis en oeuvre, sur un sous-ensemble réduit de fonctionnalités.

Tu en sais quoi ? Tu n'a aucune idée de la manière de l'utiliser. Et devines quoi, tu as totalement tort.

Dans le monde réél, je ne crois pas avoir lu: "This bug has been found with Sage". Par contre, j'ai beaucoup lu "Alors le bug machin qui a été trouvé, on a essayé de le reproduire avec Sage, on a monitoré la fonction coupable et on a réussi à retrouver la faille, regardez comme Sage c'est génial et ça écrase les fuzzers".

C'est parce que tu ne lis pas au bon endroit. Lien donné par Benoit Sibaud plus haut : http://research.microsoft.com/en-us/um/people/pg/public_psfiles/SAGE-in-1slide-for-PLDI2013.pdf

1/3 des bugs trouvés dans les composants desktop & multimedia de Windows 7 l'ont été par SAGE. Ca inclue tout ce qui est PNG/JPG/MPG/… et bien plus, et c'était donc avant 2009, SAGE a été optimisé et amélioré depuis pour optimiser ses prioritizations de branches et sa manière de surveiller les processus.

Tu peux lancer SAGE sur Word ou Excel donc, c'est légérement plus qu'un soft de 8 lignes.

Tu as visiblement focalisé sur le fait que SAGE vient de MS Research, et donc est probablement juste un projet de recherche inutilisable dans le monde réel. Tu as faux sur toute la ligne, c'est un projet qui a été construit dans l'idée de l'utiliser en production, par des testeurs normaux, pour trouver des bugs, et il en trouve à la pelle.

J'ai dit plus haut que c'était le système le plus efficace que j'ai jamais vu, je dis ça en connaissance de cause. Je connais Sulley, Peach, AFL, SAGE, les fuzzers que j'ai construit moi-même, Codenomicon, … SAGE les éclate tous en ce qui concerne le fuzzing de fichiers (pour le traffic réseau c'est une autre pair de manche vu le coté transactionnel des protocoles réseaux)

Ca revient à cela :

SAGE va passer un fichier de base à ton soft(en réalité il y a un corpus, de manière à accélérer SAGE en utilisant plusieurs fichiers qui ensemble couvrent de base la majorité des branches). Il va regarder toutes les instructions que ton code éxécute pendant le parsing du fichier. Il va ensuite regarder quelles sont les branches de code qui pourraient être prises et qui ne l'ont pas été. Il va alors créer des fonctions mathématiques pour résoudre le problème suivant :
- a quoi devrait ressembler le fichier pour que la branche X soit éxécutée ?

Il va ensuite utiliser un solveur (Z3 de MS Research) pour résoudre cela, créer le fichier, et le repasser dans le soft.

Il fait ça constamment, pour au final éxécuter toutes les branches de ton code (idéalement, en asymptotique).

La différence avec AFL :

• AFL fait un changement au hasard, et si une branche diffèrente est éxécutée, il fait un changement de plus, pour essayer d'avancer dans la nouvelle branche. C'est une méthode un peu à l'aveugle
• SAGE sait exactement ce qu'il faut faire pour avancer dans une branche, de manière mathématique

SAGE a des limites : genre si t'as une one-way hash dans ton format, il ne va évidemment pas pouvoir faire une résolution pour trouver une valeur de hash correcte, et si il y a de la compression, cela ralentit SAGE de manière significative. Mais c'est de loin, très loin, le système de fuzzing le plus efficace que j'ai jamais vu( au point ou je préféres ne pas utiliser le mot fuzzing pour SAGE, parce que justement ce n'est pas aléatoire du tout), et j'ai passé la majorité de ma carrière sur ce sujet précis à MS.

Cette approche est une forme primitive de résolution de contraintes appliquée aux tests sécurité. Quelque chose que Microsoft fait depuis presque 10 ans avec SAGE :

http://research.microsoft.com/en-us/um/people/pg/public_psfiles/ndss2008.pdf

Techniquement parlant oui ce serait idéal. Le problème est que ta méthode ajoute une étape pour tous les utilisateurs, ce qui garantit des problèmes car le papier avec la clé est perdu ou autre. Et cette étape devrait être ajoutée à tout le monde pour résoudre un problème qui ne touche que 1% des gens en gros… Bref en théorie bien, en pratique pas top.

Tu as oublié l'élément le plus important: La productivité des employés.

Quand aux éditeurs, le fait qu'ils se plaignent de piratage ne signifie pas forcément que la gestion de licence soit une partie importante du tco pour les entreprises, ces 2 choses ne sont pas liées.