Si [...] l'utilisateur n'utilise pas le compte root pour bosser, alors le logiciel ne pourra pas [...] sniffer le clavier
Je ne m'avancerais pas tant. Une idée "simple" serait d'injecter tous les processes de l'utilisateur pour y intercepter tous les appels à read(2). Après si l'utilisateur fait un sudo pendant sa session, tu peux même avoir le root.
Écrire un spyware Unix n'est pas forcément très difficile. C'est juste que ça n'intéresse pas grand monde pour le moment (dans un but commercial en tout cas). Par contre si tu commences à utiliser SELinux/systrace/fakebust/... ça devient plus compliqué.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Un API équivalent est disponible sous Unix (et donc Linux) hein. Comment tu crois qu'il fait gdb notamment ? man 2 ptrace
Encore pire: sous Linux tu peux voir et modifier la mémoire des processes directement via /proc.
Le problème n'est pas que cet API existe mais que des processes malveillants puissent l'utiliser pour obtenir des droits plus élevés. Tant que les processes appartiennent au même utilisateur (en gros), Unix ne t'empéchera pas d'injecter ce que tu veux. Le problème c'est que deux processes ayant les mêmes droits Unix aient des droits différents pour ce qui est de l'accès internet par exemple puisque celui qui est interdit d'accès n'a qu'à injecter celui qui a accès. On a donc exactement le même problème que sous Windows.
La solution c'est d'utiliser des trucs genre SELinux ou Systrace mais pour le moment ça a pas l'air d'être fort répandu. Je suis à peu près sûr qu'il n'y a pas 20% des personnes qui ont lu ce post qui utilisent un tel système (et on est entre geeks, alors le grand public...).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
J'y connais rien en programmation Windows mais d'après ce que je me souviens de l'article de MISC (je l'ai pas sous la main) et d'après [0], on peut parfaitement injecter à peu près n'importe quoi dans la mémoire d'un process sans vraiment de difficulté et donc lui faire exécuter ce qu'on veut. Et je doute que ZoneAlarm recalcule la somme de contrôle du process en mémoire à chaque accès réseau.
Donc pour passer outre le firewall, tu trouves un process autorisé qui est en train de tourner (au hasard: IE ou Firefox), tu lui injectes le code voulu et tu le laisses faire tout ce que tu ne peux pas faire directement tandis que le firewall laisse passer puisque l'exe qui est sur le disque est bon.
Et tu te logs chez toi via SSH sur une machine dont tu n'es pas le root (et avec un mdp en plus) ? Je suis trop paranoïaque ou c'est toi qui ne l'est pas assez.
Des accents dans le mot^W^Wla phrase de passe ça augmente considérablement l'espace de recherche pour un "bruteforçage" (surtout que justement il faut que l'attaquant connaisse l'encodage utilisé).
Évidemment mettre des accents dans un mdp que l'on sait que l'on utilisera depuis une machine aux locales différentes c'est pas très malin mais utiliser son mdp depuis une machine "étrangère" (dans le sens, pas "de confiance") c'est encore moins malin. Par ailleurs l'utilisation de clés privées (pour SSH surtout) règle le problème: une clé par machine, donc une phrase de passe par machine (et même si c'est la même, les accents seront toujours avec la bonne locale).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Si Kat ne dépend pas de mono mais qu'il dépend de libkde$BLA, ça avance pas plus les utilisateurs non KDEistes (il n'y a pas que les utilisateurs de Gnome et KDE qui pourraient bénéficier d'un logiciel comme celui là).
Bon maintenant je me trompe peut-être complétement et Kat ne dépend pas du tout de 50Mo de libs KDE mais j'ai un sale doute quand même (et j'ai la flemme de vérifier).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
C'est la technique décrite par Thompson dans un papier qui date de 1984 (et l'idée originale remonte à plus loin mais il n'y a pas de référence précise). http://www.acm.org/classics/sep95/(...)
Non seulement le compilo peut inclure une backdoor dans le login(1) qu'il compile mais en plus il inclut de quoi mettre la backdoor quand il recompile le compilateur depuis les sources "propres".
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
J'avoue que je ne lis pas régulièrement Bugtraq mais il me semble qu'on y trouve plus des failles ponctuelles que des résultats d'audits de code complets.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
À noter qu'un firewall applicatif sous Linux ne serait pas forcément plus sûr. Un coup de ptrace(2) et hop tu injectes le code qui doit communiquer sur le réseau dans une application autorisée (bon c'est un peu plus compliqué quand même mais ça reste généralement possible, voire un autre MISC).
Sinon dans le genre "pop-up qui te demande si tu veux laisser l'application faire un truc", il y a Systrace qui permet de faire ça pour tous les appels systèmes (pas seulement les accès réseau). Enfoncé ZoneAlarm :op http://systrace.org/(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Il y a quelques temps il y avait un projet (Sardonix) fondé par le DARPA pour auditer un max de logiciels libres mais apparement ça a pas duré. Ca serait bien que ce genre de projet revienne à la mode (on peut rêver).
Le problème c'est que le binaire que tu télécharges ne correspond pas forcément à la source que tu peux inspecter (ou qui a été auditée), même si tu compiles toi même (suffit que ton gcc soit troyanisé aussi). Donc ça peut donner un faux sentiment de sécurité, ce qui est pire que d'avoir moins de sécurité mais d'en être conscient.
Le tout c'est de savoir que le LL c'est pas miraculeux non plus.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
C'est pas parce qu'un paquet est signé par le ftpmaster qu'il ne contient pas de backdoor. Parmi les centaines (milliers?) de packageurs Debian, il peut toujours bien y en avoir un qui peut avoir introduit une backdoor en toute discrétion. Et même si ça n'est pas le cas, ça peut avoir été fait par l'auteur en amont tout aussi discrètement. Par contre pour que ça reste indétecté faut vraiment avoir bien pensé le truc à la base (surtout pour un paquet très utilisé).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Si le script plante, il y a sans doute une trace dans les logs du serveur web. Pas oublier d'utiliser "use warnings" (ou -w). Il y a aussi sans doute moyen de rediriger STDERR vers un fichier (au pire il y a toujours $SIG{__WARN__}), RTFM.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Heu j'ai une Debian Sarge tout UTF-8 et j'ai pas de problème à ce niveau (bon je lance quand même irssi avec des locales 8859-15 sinon je me fait kicker par les extrêmistes de #linuxfr). J'utilise Perl et SSH quotidiennement (pour SVN je l'ai utilisé une fois pour récupérer des sources sans problème mais j'ai pas essayé de commiter).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
L'idée c'est que si le navigateur web d'Henry n'avait pas le droit de modifier le système, le problème n'existerait pas et il pourrait laisser le navigateur non patché pendant des mois sans problème (bon avec un navigateur web il reste les problèmes de phishing).
Par ailleurs dans l'article il dit bien qu'il ne croit pas en une solution qui passerait par l'éducation "forcée" des utilisateurs. Selon lui, mieux vaut concevoir des systèmes qui résistent aux "bêtises" des utilisateurs (ou mieux: qui les incitent à ne pas faire de "bêtises") plutôt que de passer son temps à essayer de leur expliquer comment ne pas faire de "bêtises". Si on suit cette logique, c'est pas la faute de l'utilisateur qui ne patch pas mais celle de celui qui a conçu le système puisqu'il y a besoin de patcher (et même s'il faut patcher, l'utilisateur ne devrait pas avoir à s'en soucier).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# nl
Posté par Krunch (site web personnel) . En réponse au message comment connaître le numéro d'une ligne dans un fichier. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# adequacy
Posté par Krunch (site web personnel) . En réponse au journal mieux que wikipédia (vu sur advogato). Évalué à 3.
http://www.adequacy.org/(...)
http://maddox.xmission.com/(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Liste des articles pour eventuelle contribution
Posté par Krunch (site web personnel) . En réponse au journal Station Linux. Évalué à 0.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Firestarter
Posté par Krunch (site web personnel) . En réponse au journal "j'me sens plus en secu sous win" j'ai pas pu lui repondre. Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: fireflier
Posté par Krunch (site web personnel) . En réponse au journal "j'me sens plus en secu sous win" j'ai pas pu lui repondre. Évalué à 3.
Écrire un spyware Unix n'est pas forcément très difficile. C'est juste que ça n'intéresse pas grand monde pour le moment (dans un but commercial en tout cas). Par contre si tu commences à utiliser SELinux/systrace/fakebust/... ça devient plus compliqué.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Firestarter
Posté par Krunch (site web personnel) . En réponse au journal "j'me sens plus en secu sous win" j'ai pas pu lui repondre. Évalué à 2.
Encore pire: sous Linux tu peux voir et modifier la mémoire des processes directement via /proc.
Le problème n'est pas que cet API existe mais que des processes malveillants puissent l'utiliser pour obtenir des droits plus élevés. Tant que les processes appartiennent au même utilisateur (en gros), Unix ne t'empéchera pas d'injecter ce que tu veux. Le problème c'est que deux processes ayant les mêmes droits Unix aient des droits différents pour ce qui est de l'accès internet par exemple puisque celui qui est interdit d'accès n'a qu'à injecter celui qui a accès. On a donc exactement le même problème que sous Windows.
La solution c'est d'utiliser des trucs genre SELinux ou Systrace mais pour le moment ça a pas l'air d'être fort répandu. Je suis à peu près sûr qu'il n'y a pas 20% des personnes qui ont lu ce post qui utilisent un tel système (et on est entre geeks, alors le grand public...).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Firestarter
Posté par Krunch (site web personnel) . En réponse au journal "j'me sens plus en secu sous win" j'ai pas pu lui repondre. Évalué à 4.
Donc pour passer outre le firewall, tu trouves un process autorisé qui est en train de tourner (au hasard: IE ou Firefox), tu lui injectes le code voulu et tu le laisses faire tout ce que tu ne peux pas faire directement tandis que le firewall laisse passer puisque l'exe qui est sur le disque est bon.
[0] "Using Process Infection to Bypass Windows Software Firewalls" Phrack#62 article#13 http://www.phrack.org/show.php?p=62&a=13(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Et si ...
Posté par Krunch (site web personnel) . En réponse au journal Vu sur la tribune:. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: La source du problème
Posté par Krunch (site web personnel) . En réponse au journal "j'me sens plus en secu sous win" j'ai pas pu lui repondre. Évalué à 6.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Logiciel proprio = format proprio
Posté par Krunch (site web personnel) . En réponse au journal "Tout progiciel installé doit être couvert par une licence". Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: UTF-8
Posté par Krunch (site web personnel) . En réponse à la dépêche Revue des nouvelles chez Ubuntu. Évalué à 3.
Des accents dans le mot^W^Wla phrase de passe ça augmente considérablement l'espace de recherche pour un "bruteforçage" (surtout que justement il faut que l'attaquant connaisse l'encodage utilisé).
Évidemment mettre des accents dans un mdp que l'on sait que l'on utilisera depuis une machine aux locales différentes c'est pas très malin mais utiliser son mdp depuis une machine "étrangère" (dans le sens, pas "de confiance") c'est encore moins malin. Par ailleurs l'utilisation de clés privées (pour SSH surtout) règle le problème: une clé par machine, donc une phrase de passe par machine (et même si c'est la même, les accents seront toujours avec la bonne locale).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Ubuntu vs Debian
Posté par Krunch (site web personnel) . En réponse à la dépêche Revue des nouvelles chez Ubuntu. Évalué à 1.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Kat
Posté par Krunch (site web personnel) . En réponse à la dépêche Beagle : Un "Desktop Search" sous Linux. Évalué à 4.
Bon maintenant je me trompe peut-être complétement et Kat ne dépend pas du tout de 50Mo de libs KDE mais j'ai un sale doute quand même (et j'ai la flemme de vérifier).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: ...
Posté par Krunch (site web personnel) . En réponse au journal Devons-nous nous méfier des logiciels Open Source ?. Évalué à 3.
http://www.acm.org/classics/sep95/(...)
Non seulement le compilo peut inclure une backdoor dans le login(1) qu'il compile mais en plus il inclut de quoi mettre la backdoor quand il recompile le compilateur depuis les sources "propres".
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Debian, fedora, ... & gpg
Posté par Krunch (site web personnel) . En réponse au journal Devons-nous nous méfier des logiciels Open Source ?. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Firestarter
Posté par Krunch (site web personnel) . En réponse au journal "j'me sens plus en secu sous win" j'ai pas pu lui repondre. Évalué à 10.
Sinon dans le genre "pop-up qui te demande si tu veux laisser l'application faire un truc", il y a Systrace qui permet de faire ça pour tous les appels systèmes (pas seulement les accès réseau). Enfoncé ZoneAlarm :op
http://systrace.org/(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: wget
Posté par Krunch (site web personnel) . En réponse au message script pour lancer firefox avec CRON (2). Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# dupe
Posté par Krunch (site web personnel) . En réponse au journal Yahoo, Google et autres pourris. Évalué à 10.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Debian, fedora, ... & gpg
Posté par Krunch (site web personnel) . En réponse au journal Devons-nous nous méfier des logiciels Open Source ?. Évalué à 4.
http://web.archive.org/web/20041123090110/http://www.sardonix.org/(...)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: De toute façon...
Posté par Krunch (site web personnel) . En réponse au journal Devons-nous nous méfier des logiciels Open Source ?. Évalué à 6.
Le tout c'est de savoir que le LL c'est pas miraculeux non plus.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Devons-nous nous méfier des logiciels Open Source ?
Posté par Krunch (site web personnel) . En réponse au journal Devons-nous nous méfier des logiciels Open Source ?. Évalué à 4.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: maizencor ?
Posté par Krunch (site web personnel) . En réponse au message Threads en Perl dans un CGI. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: UTF-8
Posté par Krunch (site web personnel) . En réponse à la dépêche Revue des nouvelles chez Ubuntu. Évalué à 3.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# maizencor ?
Posté par Krunch (site web personnel) . En réponse au message Threads en Perl dans un CGI. Évalué à 2.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Interessant...
Posté par Krunch (site web personnel) . En réponse au journal La sécurité, tout un état d'esprit. Évalué à 2.
Par ailleurs dans l'article il dit bien qu'il ne croit pas en une solution qui passerait par l'éducation "forcée" des utilisateurs. Selon lui, mieux vaut concevoir des systèmes qui résistent aux "bêtises" des utilisateurs (ou mieux: qui les incitent à ne pas faire de "bêtises") plutôt que de passer son temps à essayer de leur expliquer comment ne pas faire de "bêtises". Si on suit cette logique, c'est pas la faute de l'utilisateur qui ne patch pas mais celle de celui qui a conçu le système puisqu'il y a besoin de patcher (et même s'il faut patcher, l'utilisateur ne devrait pas avoir à s'en soucier).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.