CoinKoin a écrit 698 commentaires

Linux est distribué sous forme de distributions, diverses et variées... Laquelle as-tu téléchargé? Une Mandriva, une Suse, une Fedora Core, autre chose?

Quelle est la marque de ton ordinateur, et celle de ton lecteur de DVD?

Oui, mais est-ce que l'utilisateur peut encore se logger graphiquement avec ça?

Si oui, la solution est insuffisante : en éditant ses fichiers de conf', il peut contourner la difficulté en se bricoler un raccourci vers une commande du style "xterm -e /bin/bash".

Le plus simple, pour parer ça, c'est de jouer sur les groupes pour lui interdire carrément l'exécution de /bin/sh, /bin/bash et `which tcsh` . Cela dit, si l'utilisateur est malin, il copiera à la main un binaire de shell sur son compte, et le tour sera joué.

A mon avis, pour empêcher vraiment un utilisateur d'utiliser le shell, il n'y a qu'une seule solution fiable : virer l'utilisateur.

dans un modele plat, le code et les données sont sur le meme segment. donc, un depassement d'allocation logique ne se retrouvant pas arreté, se retrouve à potentiellement écrire dans son code ou sa pile.


Pas nécessairement, il suffit d'insérer une page invalide entre le code et les données. Ce n'est pas parce que Linux ne le fait pas que c'est impossible.

plus sérieusement, tu as des données dans ES/DS et ta pile dans SS.
explique moi comment tu peux sortir de SS mais pas de ES/DS par overflow ?
si je ne m'abuse [SS:SP] est incremental et donc le pointeur de retour n'est pas accessible si l'on copie trop de données dans la pile.

Mais c'est pas ça, le principe d'une attaque par buffer overflow! Le principe, c'est justement de profiter de certaines données allouées sur la pile, donc dans le segment pointé par SS, pour écraser l'adresse de retour d'une fonction. La quantité de données qui y est copiée n'influe que sur la taille du buffer overflow nécessaire à l'attaque.


sinon, NX a à voir avec un modele plat de mémoire, ou ( de "ou bien" ) des segments données/code qui se superposent.
une page non executable qui se retrouvent dans CS ne sera pas executé ( fear ). NX palie juste au fait que le modele segmenté n'est plus mis en oeuvre dans les OS pour des soucis de portabilité et de facilité de developpement.

Ah, là, on est d'accord.


pour ce qui est de la pagination, tu proposais l'exception de gestion de faute de page et non de faute de segment ... je te disais juste que tu te trompais d'exception.



Oui, mais non, pas en modèle plat paginé...
Voilà le fichier de référence dont je me sers sur la question : ftp://download.intel.com/design/PentiumII/manuals/24319202.pdf(...)

(C'est le manuel du programmeur système sur i386).

Tu y verras (page 5-44) que, dans un modèle plat paginé, en cas d'écriture à une adresse non autorisée, c'est bien l'exception 14 qui est levée; et les noyaux d'UNIX récupèrent cette exception pour envoyer un SIGSEGV au processus fautif.


sinon pour obtenir une faute sur un segment ... il te faut des segments ( c'est d'une logique assez vile je l'admet ), que le segment soit un segment de mémoire alloué "physiquement" ( LDT / GDT ) ou "logiquement" ( table d'allocation noyau geré a coup de malloc/free ). dans le cas où l'allocation "logique" n'est pas contrainte par une allocation "physique" je vois mal comment le systeme peut gerer cela ( à moins d'utiliser des appels systemes pour acceder aux zones mémoire qui fait qu'il peut y avoir des controles de dépassement ).


Ah, ben voilà! Je n'avais pas compris que nous n'avions tout simplement pas la même définition du segment (je n'y incluais pas les segments logiques gérés par pagination). Effectivement, dans cette définition-là, je suis entièrement d'accord avec toi.

PS. : Pour ce qui est des bouquins, laisse tomber ceux liés au 286, d'abord, c'est un processeur 16 bits, ensuite, je crois bien qu'il ne comporte pas de pagination.

Dans ton programme, tu fais effectivement un buffer overflow hors de la pile, mais cela le rend à peu près inutilisable : comment veux-tu convaincre le processeur de faire un saut dans tes données??


Au fait, explique moi comment dernierement certains ont presenté les raisons du flag NX au niveau de la gestion des pages ?

Comment? Avec des transparents, je suppose...

NX est un bit de pagination. Tu as écrit sur les archi IA32, un segment marqué code n'est accessible en théorie, qu'en écriture par le systeme bas niveau.
NX n'a rien a voir avec les segments.

Si deux segments se superposent comme dans un modele plat, alors cela peut faire deux jeux de pages dont l'un est ecrivible l'autre non.

Je n'ai jamais dit le contraire.


Puis sais tu que tu n'es pas obligé d'activer la pagination ?

Oui. Et je ne vois pas le rapport avec ce dont on parlait, à savoir ton affirmation selon laquelle pour avoir un "segmentation fault", il te faut un systeme ayant des segments, dont je maintiens le caractère erronné.

Ah, oui, c'est vrai, j'avais oublié. D'un autre côté, ça ne s'applique qu'aux pages de l'espace utilisateur, pas à celles du noyau lui-même.

sur les archi IA32, un segment marqué code n'est accessible en théorie, qu'en écriture par le systeme bas niveau.


Définir "système bas niveau". Processus en espace utilisateur? Non, un tel processus ne peut pas écrire dans un tel segment. Ni le lire, d'ailleurs : il peut seulement y exécuter des instructions.


Par contre, si la gestion disque est mal faite et qu'il y a un gestionnaire de mémoire paginée ... alors il est possible d'injecter du code en modifiant la partie sur le disque.

Très très très mal faite, alors, mais c'est vrai. Cela dit, on appelle ça un bogue de l'OS, pas une fonctionnalité.

Sinon, pour avoir un "segmentation fault", il te faut un systeme ayant des segments ...

Faux. L'écriture dans une page marquée en lecture seule par un processus en espace utilisateur provoque (sur i386) la levée de l'interruption 14 du processeur (faute de page), avec un vecteur précisant que l'erreur est due à une écriture dans une page en lecture seule. Le système d'exploitation récupère alors cette erreur et la traduit par un SIGSEGV à l'égard du processus fautif.

mais etrangement la mode au modele plat de mémoire lève cette bariere et permet de faire des merveille d'injection par buffer overflow ( qui ne font plus de segfault puisque pouvant acceder comme donnée au segment de code ).

Adepte d'OpenBSD et de son modèle segmenté, hein? Ben non, ce n'est pas ça : les buffer overflows ont lieu sur la pile, pas dans la zone de code, et la protection supplémentaire qu'apporte le modèle segmenté tient non pas à ce qu'il interdit la modification des zones exécutables, mais à ce qu'il interdit à l'exécution de se poursuivre sur la pile.

Cela dit, cette protection est elle aussi contournable, mais il faut une connaissance très fine du binaire attaqué.

Et des compilateurs; mais pas à proprement parler des langages employés (pourvu qu'ils soient compilés).

Oui, sauf en espace noyau, du moins sur i386.

En effet, ces processeurs n'ont aucune protection en écriture vis-à-vis des instructions exécutées en mode privilégié (ce qui est d'ailleurs assez gênant...), du coup, la modification est parfaitement possible.

Ah, et au fait : même en espace utilisateur, cela dépend aussi de l'OS employé. Certains petits UNIX (Minix, notamment, je crois), ne mettent pas en place cette protection, du coup, la partie statique est quand même modifiable.

Donc, nan, ton i[2] = 0; ne va pas.

Alors, c'est une extension à la norme, parce que, de fait, ça marche. Evidemment, il faut savoir ce qu'on écrase éventuellement, mais ça marche, je viens de le vérifier manuellement en espace utilisateur.

Pariel, pour les truc[-1], tout dépend comment tu as obtenu truc. Si c'est comme ça, pas de problèmes :

[...]

C'était approximativement ça :-) .

Tiens, ca me rappelle des "challenges informatiques" ... Par exemple, sur un noyau minimum permettant un accés illimité à l'ensemble de la mémoire pour les processus, le but étant de créer un processus capable de corrompre les autres processus tout en assurant sa protection.
Tous les processus sont déclenchés ex-equo et le survivant faisait gagner son codeur.


Marchera jamais...

<Ce que j'aurais joué>
memset du noyau à la valeur de l'instruction "cli", puis mise d'un joyeux "leave iret" à la fin, et victoire assurée (plus d'interruptions horloge, donc plus de main aux autres processus), à moins de jouer en multiproc.
</Ce que j'aurai joué>

A mon avis, ça devait être des threads ayant un accès illimité à la mémoire utilisateur, mais pas à celle du noyau. Dommage, mais bon...

Ce sont de simples avertissements de compilation (dans le fichier handsfree.c), pas des erreurs. Bizarre, mais sans importance pour toi.

Ouah!

Quatre réponses en une après-midi, chapeau! Bon, je vais vous répondre tous ici, plutôt que de poster quatre réponses.

En fait, le code que j'ai posté n'était là pour faciliter la compréhension du problème, pas pour fournir un exemple concret. Si vous en voulez un, voilà :

http://www.uwsg.iu.edu/hypermail/linux/kernel/0503.3/0957.html(...)

L'exemple que j'ai posté n'en était qu'une version simplifiée. Donc, comme vous le voyez, on peut faire des off-by-one (et pas out-by-one, comme je l'avais écrit précédemment, mea culpa) raisonnablement propres, au point de les intégrer le noyau Linux en toute connaissance de cause.

Pour ma part, j'ai déjà procédé à l'inverse : de magnifiques packet[-1] parsemaient mon code, et je t'assure que c'était parfaitement correct (c'était pour accéder à l'en-tête d'un paquet, dans une pile réseau), et proprement documenté (par l'intermédiaire des commentaires, encore une fois).

Donc, sisisisi, ce style de codage est parfaitement acceptable, il ne casse pas nécessairement la portabilité, ce qui compte, c'est qu'il soit effectué avec précaution, et bien explicité.

En revanche, je veux bien croire que ce genre de choses ne soit jouable qu'en espace noyau, où les informations dont le programmeur dispose sont nettement plus importantes qu'en espace utilisateur (il connait, ou peut connaître, la position physique de son code, le déplacer si nécessaire, kmalloc() alloue toujours des zones mémoires de tailles 2^n, d'où d'autres informations, etc...).

Et pour conclure, les expériences vécues sur des off-by-one involontaires en espace utilisateur ne sont absolument pas transposables à des off-by-one volontaires en espace noyau.

On peut donc parfaitement effectuer des off-by-ones sans commettre de bogue.

Je croyais que les BSD se permettaient de baver sur Linux en disant que eux ils codaient proprement et correctement ?

Ah, je ne sais pas, je ne suis pas tellement leur activité... En fait, tout ce que je sais, à ce sujet, c'est qu'on m'a dit que le code d'openssh était assez horrible, et que c'était pour ça qu'on n'en faisait pas une bibliothèque.

Cela dit, pour en revenir sur la propreté du code, celui qui suit me semble parfaitement propre, malgré son dépassement :

int i[2];

[...]

/* This is an out-by-one, but it's volunteer, and we are sure there is enough place into memory for it. */
i[2]=0;

Oui, surtout s'il copie un pilote Linux sous licence GPL/BSD (il y en a un nombre non négligeable).

Sinon, c'est franchement improbable, ou alors, ce codeur se livre à du piratage.

1,224 millions de lignes, et non 1.224 millions, bien sûr...

Petite remarque : Si tu savais déjà que FreeBSD comportait un bogue (potentiel) pour 4000 lignes, il n'était pas nécessaire de calculer son nombre total de lignes pour en déduire son taux de 0.25 bogues par milliers de lignes.

De plus, nombre de ces soi-disant bogues sont en réalité sans danger. Ainsi, certains dépassements de tableaux dans des cas où l'on est sûr de disposer de la place nécessaire en mémoire.

Autre exemple : dans certains cas, le programmeur a placé des sécurités pour traiter des configurations improbables, mais qu'il ne juge pas impossibles. De son côté, le coverity check détecte que la condition testée ne peut jamais être vraie, et le signale donc comme un bogue. Evidemment, c'est plus qu'inoffensif...

Du coup, ces chiffres peuvent aussi être interprétés comme traduisant une plus grande prudence de la part des programmeurs de FreeBSD.

J'estime donc qu'en tirer une comparaison entre les qualités des deux noyaux est très, très prématuré.

Ils parlent de la racine des sources que tu as téléchargées. Mais, à priori, c'est plutôt pour les développeurs, ce truc, et je pense que tu peux t'en passer.

Pas que je sache : X.org ne prévoit qu'un seul pointeur, pas moyen de le modifier.

$ which amule

Pour trouver le binaire,et

# rm -f `which amule`

pour le supprimer. En espérant qu'il n'aura pas laisser trop de fichiers de conf' globaux et autres...

Ben, c'est déjà un journal!

Y'a un certain louseb qui a exactement le même problème que toi : http://linuxfr.org/forums/12/9923.html(...) ... Tu devrais lui en parler, à deux, ça irait sans doute mieux. ;-)

Bof, ça, ça ne veut rien dire : c'est une formule toute faite, archi-classique, qui ne signifie en aucun cas que son auteur approuve le principe de ces brevets. Sinon, avec ce genre de raisonnements, tu finiras par boycotter IBM et Redhat...

Pas chez moi... Comment tu as fais? Tu as installé le plugin flashçapuec'estpaslibre?

Mmmh... Il y a quand-même un moyen : couper les services permettant des connections distantes.

Supprime le fichier /etc/rc.d/rc5.d/S??sshd (où ?? est un nombre que je ne connais pas), cela aura pour effet de ne plus démarrer le démon sshd lors du démarrage de ton ordi. Du coup, plus de possibilité de se connecter de l'extérieur...

Ensuite, il faut bricoler un peu pour supprimer son mot de passe du fichier /etc/shadow. Le problème, c'est que c'est une assez mauvaise idée, de ne pas mettre de mot de passe, donc je te déconseille franchement de le faire, ne serait-ce que pour prendre les bonnes habitudes pour la suite, par exemple quand tu utiliseras Linux au travail.

Du coup, ce n'est pas une très bonne idée... Mais si tu y tiens, bah, mets-toi un mot de passe court, ça suffira amplement si tu n'as pas de service de connection à distance.

Pas de chance. Tu as trois possibilités :
- faire une appli GPL,
- utiliser une autre bibliothèque,
- réécrire cette bibliothèque.

Quand une bibliothèque est sous GPL, c'est justement pour empêcher qu'on ne l'utilise depuis un programme non GPL.