• # keyloggers

    Posté par  . Évalué à 6. Dernière modification le 27 août 2020 à 01:16.

    Kikou, tu ne le précises pas (ou j'ai lu trop vite), mais sur une machine compromise les frappes du clavier ont pu être interceptées. Donc si tu as accédé à tes données sensibles pendant ce laps de temps (gestionnaire de mots de passe chiffrés), si je ne m'abuse, elles peuvent être considérées comme compromises aussi.
    Puisque tu évoques Docker, je suis au moins d'accord pour dire que ça donne au moins l'envie de faire du sandboxing partout, et me fait dire que la généralisation de trucs comme AppArmor n'est peut-être pas une si mauvaise idée…

    • [^] # Re: keyloggers

      Posté par  (site web personnel) . Évalué à 2.

      Donc si tu as accédé à tes données sensibles pendant ce laps de temps (gestionnaire de mots de passe chiffrés), si je ne m'abuse, elles peuvent être considérées comme compromises aussi.

      Effectivement. Si quelqu'un a des infos à ce sujet je suis preneur. :)

      Adhérer à l'April, ça vous tente ?

  • # Novice

    Posté par  . Évalué à 2.

    Merci pour ce lien au contenu très instructif. N'étant pas familier avec la recherche de compromissions ni spécifiquement le développement, je me suis achoppé sur les éléments suivants:
    - Comment la faille du "request" à été utilisée ? Question certainement très bête mais j'ai pas réussi à comprendre la méthode de compromission. Le pirate à vu que tu à mis request et ensuite profité de cette faille, mais comment?
    - Ta machine à été compromise mais qu'en est-il du site en production ? (propagation de la faille)
    - Pip: Tu parle des mauvaises pratiques par rapport à pip. As-tu éventuellement un lien ?

    Bonne journée

    • [^] # Re: Novice

      Posté par  . Évalué à 5.

      Comment la faille du "request" à été utilisée ? Question certainement très bête mais j'ai pas réussi à comprendre la méthode de compromission. Le pirate à vu que tu à mis request et ensuite profité de cette faille, mais comment?

      Il existe une bibliothèque très utilisée en python qui s'appelle request, il est facile de se tromper et d'aller chercher requests. Le script d'installation de ce dernier installe un petit logiciel de espion.

      Il explique que requests s'est fait éjecter de pip avant d'avoir le temps d'installer en prod. Donc il a eu une erreur (la dépendance n'existant plus) plutôt qu'une faille.

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # Agent GnuPG

    Posté par  . Évalué à 4.

    A minima un agent PGP ne me sert pas à grand-chose et devrait disparaître.

    Ça fait bien longtemps que l’agent GnuPG est indispensable au fonctionnement de GnuPG. Seul GnuPG 1.4.x peut encore fonctionner sans agent. Toutes les versions ultérieures ont besoin de l’agent, c’est le seul composant qui accède directement aux clefs privées. GnuPG sans son agent n’est tout simplement pas fonctionnel.

    puisque je les utilise quotidiennement, ils ont donc des fenêtres d'ouverture pendant lesquelles je ne peux que supposer qu'ils exposent mes accès.

    C’est vrai pour l’agent SSH, qui conserve en mémoire les clefs chargées sous une forme en clair, pour la durée de son existence.

    En revanche, l’agent GnuPG :

    • ne garde jamais les clefs en mémoire, que ce soit en clair ou non ; lorsque l’agent a besoin d’une clef privée, elle est lue depuis le disque, utilisée pour la tâche à accomplir (déchiffrer ou signer quelque chose), puis immédiatement supprimée de la mémoire de l’agent ;
    • ne garde les phrases de passe en mémoire que pour un moment (10 minutes par défaut), jamais pour la durée de vie de l’agent.

    • [^] # Re: Agent GnuPG

      Posté par  (site web personnel) . Évalué à 2.

      Merci pour les précisions. J'avoue avoir une connaissance imparfaite des agents et me fondre en spéculation (l'informatique moderne est si complexe que je ne me consacre qu'à comprendre ce qui fonctionne mal).

      Adhérer à l'April, ça vous tente ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.