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.
Je pense qu'il y a mieux que de limiter le nombre de programmes exécutables. On peut limiter ce que peut faire chaque programme. Par exemple il n'y a probablement pas de raison qu'un applet ActiveX touche à quoi que ce soit sur le disque dur. Une fois que tu as des permissions de ce type qui sont mises en place correctement, l'antivirus ne sert plus à grand chose puisque l'OS limite déjà ce que peut faire chaque programme (bon effectivement le problème c'est de créer et maintenir ces règles).
cf systrace et SELinux
Sinon l'idée de l'article (sur ce point là en tout cas) c'est de concevoir dès la base un système le plus résistant possible à tous les niveaux. Rien ne sert de patcher une passoire (et donc pour Windows c'est un peu mort de toute façon).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Le plus efficace pour éviter l'effet Slashdot c'est sans doute de ne pas parler d'informatique ou de "trucs de geeks" sur son site (ou de ne pas avoir de site).
Sinon pour résister à un slashdottage il faut s'arranger pour avoir suffisament de bande passante, des pages qui prennent le moins de ressources possibles (éviter le PHP mal foutu avec 50 requètes SQL par page,...) et configurer son httpd de manière à ce qu'il puisse gérer suffisament de connexions simultanées.
Par ailleurs, Mirrordot et Coral ne te sauveront pas d'un Slashdottage si le lien dans l'article pointe directement sur ton site (à moins de mettre un mod_rewrite qui va bien).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Le problème n'est pas que ça soit facilement personalisable ou non mais que ça soit mal organisé par défaut (et même avec un menu "personnalisé" tenu en ordre, je trouve plus facile d'aller désinstaller par le panneau de configuration, après tout le lien "désinstaller" n'a rien à faire dans le menu démarrer).
PS: si tu ne peux pas voter sur les commentaires, c'est sans doute que tu as épuisé tous tes votes pour aujourd'hui (pour savoir comment s'effectue le calcul du nombre de votes dispos par jour, s'adresser aux admins qui ignoreront)
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.
[^] # Re: Interessant...
Posté par Krunch (site web personnel) . En réponse au journal La sécurité, tout un état d'esprit. Évalué à 3.
cf systrace et SELinux
Sinon l'idée de l'article (sur ce point là en tout cas) c'est de concevoir dès la base un système le plus résistant possible à tous les niveaux. Rien ne sert de patcher une passoire (et donc pour Windows c'est un peu mort de toute façon).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# X est lancé mais pas KDE
Posté par Krunch (site web personnel) . En réponse au message Newbie. Évalué à 2.
ctrl+alt+backspace
Je décline toute responsabilité blablabla.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: mirrordot ?
Posté par Krunch (site web personnel) . En réponse au message Eviter l"effet Slashdot ./ ..??. Évalué à 2.
Sinon pour résister à un slashdottage il faut s'arranger pour avoir suffisament de bande passante, des pages qui prennent le moins de ressources possibles (éviter le PHP mal foutu avec 50 requètes SQL par page,...) et configurer son httpd de manière à ce qu'il puisse gérer suffisament de connexions simultanées.
Pour ce qui est de rendre plus rapide des pages dynamiques, il y a généralement moyen de monter un système de cache plus ou moins "intelligent" comme ça par exemple: http://www.00f.net/php/show-article.php/fast_php_cache_with_mod_rew(...)
Par ailleurs, Mirrordot et Coral ne te sauveront pas d'un Slashdottage si le lien dans l'article pointe directement sur ton site (à moins de mettre un mod_rewrite qui va bien).
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: et c'est nous qui devont éviter le troll ?
Posté par Krunch (site web personnel) . En réponse au journal Linux est il prêt pour le desktop?. Évalué à 3.
PS: si tu ne peux pas voter sur les commentaires, c'est sans doute que tu as épuisé tous tes votes pour aujourd'hui (pour savoir comment s'effectue le calcul du nombre de votes dispos par jour, s'adresser aux admins qui ignoreront)
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.