Passer au contenu

Le code source du logiciel pcAnywhere de Symantec a fuité

Symantec s’est résolu à l’admettre : le code source de sa suite d’utilitaires pcAnywhere (permettant je cite de “gérer efficacement les ordinateurs, résoudre rapidement les problèmes…

Symantec s’est résolu à l’admettre : le code source de sa suite d’utilitaires pcAnywhere (permettant je cite de “gérer efficacement les ordinateurs, résoudre rapidement les problèmes d’assistance et connecter des équipements distants en toute simplicité et en toute sécurité”) a été récupéré par un hacker, arborant le pseudo de YamaTough.

Ce dernier, membre du groupe Lords of Dharmaraja (qui ne cache pas ses relations étroites avec les Anonymous) s’est vu proposé par Symantec (plutôt, par des apparentés agents officiels ayant tenté de le piéger, la preuve ICI) la coquette somme de 50 000$, afin qu’il conserve le silence, et qu’il ne diffuse pas ce code source sur la toile.

Depuis, les négociations sont restées bloquées : Symantec n’a pas payé la somme, le hacker a dans un premier temps diffusé des bribes du code source, avant de visiblement en balancer l’intégralité sur The Pirate Bay, via un fichier dépassant le Go. A confirmer.

🟣 Pour ne manquer aucune news sur le Journal du Geek, abonnez-vous sur Google Actualités. Et si vous nous adorez, on a une newsletter tous les matins.

12 commentaires
  1. Et ça change quoi ? Tout logiciel se basant sur ce code sera illégal. Donc les ventes de Symantec ne devraient pas être trop impactées, surtout coté entreprises. Si le code source est correctement fait, il ne devrait pas y avoir de problèmes de sécurité. Ah, on me dit que Symantec a peur coté sécurité…

  2. @Tofe : Ca change entre autre qu’un hacker malin pourra compiler une version vérolée/backdoorée de la suite afin de la foutre sur le net voir même de remplacer celle a dispo sur le site de l’éditeur (ce qui s’est déjà vu chez d’autres). Donc ya un réel impact :).

  3. Oui, je suis conscient de ce que j’écris. Quelqu’un qui installe une version pirate dans un coin du Net doit prendre ses précautions, sinon bien fait pour lui. Et si l’éditeur n’est pas fichu de maîtriser les binaires qu’il vend sur son site web (les checksum c’est fait pour ça), ce n’est pas la divulgation du code source qui va changer ce risque.

    Le patch dont parle Noar corrige des vulnérabilités connues. Pourquoi les corriger seulement maintenant ? Parce que l’exposition du code source les oblige à être un peu plus sérieux… Bref, tout le monde y gagne.

  4. Si il a le code source, il peut modifier les réglés d’authentification du logiciel.

    Donc, il pourrait se connecter à n’importe quel ordi ayant PCAnywhere sans la validation du destinataire !

    Là est le plus gros risque, non ?

  5. @Luc Step
    “La question, maintenant, est de savoir s’il y a ou avait bien un backdoor dedans pour le gouvernement.”
    J’ai lu sur slashdot un thread sur ce sujet (pas symantec spécifiquement), et il en ressortait que si quelqu’un devait insérer une backdoor dans un système, elle serait probablement déguisée en une erreur de programmation subtile, au niveau algorithmique ou au niveau du langage d’implémentation. Par exemple un off-by-one ( dépassement des limites du tableau), un = au lieu d’un ==, etc.. qui ne fait pas planter le programme mais qui l’affaiblit subtilement.
    Voir par exemple, la tentative d’ajout de backdoor dans le kernel Linux en 2003:
    2 lignes ajoutées qui donnaient au processus l’UID root dans des conditions bien précises, déguisées en une vérification, et parenthésée pour éviter un warning de GCC.
    + if ((options == (__WCLONE|__WALL)) && (current->uid = 0))
    + retval = -EINVAL;
    cf http://kerneltrap.org/node/1584

    Quelqu’un avait proposé par exemple d’affaiblir un PRNG pour rendre une partie du système plus vulnérable.

    @Tofe
    “Si le code source est correctement fait, il ne devrait pas y avoir de problèmes de sécurité.”

    Tu te rends compte que le “Si” de ton implication porte sur 1Go de sources ??
    Sur un petit projet (pas qui ne toucherait meme pas au système), c’est déjà pas evident que tu puisses le prouver, vu qu’a un moment tu vas forcement descendre au niveau du noyau du kernel. Feuillettes un livre sur les rootkits et tu verras bien.
    Et que des failles de sécurité sont restées visibles pendant des mois sur des projets open-source largement répandus?
    http://security-tracker.debian.org/tracker/CVE-2008-0166
    Ce n’est qu’un exemple, et la liste est longue.

  6. C’est de la prise de main / transfert de fichier sur des postes distants.

    Ca peut être remplacé gratuitement par du VNC ou en payant (gratuit pour usage personnel) par TeamViewer.

    Et dans ma boite, on se dirige vers ces deux solutions (selon les postes/besoins)… Car la mise à jour PCAnywhere devait être offerte aux clients ayants des vieilles versions (chez moi de la 8 (pas compatible XP donc plus utilisée), de la 9.2 (a peine compatible XP, donc en voie de disparition)) mais c’est la galère pour avoir la MàJ puisque leur service client que j’ai contacté hier n’est pas vraiment au courant et me suggère de tout racheter (certes au tarif “mise à jour” mais quand même)… sympa la notion de “gratuit”

  7. Dans la racine du projet:
    $ find . -iname “*.cpp” -print0 | xargs -0 grep “lstrcpy” | wc -l
    7921

    D’après:
    http://msdn.microsoft.com/en-us/library/windows/desktop/ms647490%28v=vs.85%29.aspx
    The lstrcpy function has an undefined behavior if source and destination buffers overlap.
    Security Remarks
    Using this function incorrectly can compromise the security of your application.

    should et shoudn’t donnent des tonnes de résultats

    $ find . -type f -iname “*.cpp” -print0 | xargs -0 grep -w “strcpy” | wc -l
    894

    Ils font sûrement des vérifications en amont, mais bon,
    Je parierai bien que certains vont s’amuser dans les jours qui suivent.. Personnellement je n’ai pas le temps de vérifier, mais comme le dit mon
    $ man strcpy:
    SECURITY CONSIDERATIONS
    The strcpy(), strncpy(), stpcpy(), and stpncpy() functions are easily misused in a manner which enables malicious users to arbitrarily change a running program’s functionality through a buffer overflow attack. (See the FSA and EXAMPLES.)

  8. @Antoine-xavier
    Merci de tes précisions, car j’avais lu sans trop de détails la tentative de fragilisation concernant le kernel Linux.

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *