Ceci est la FAQ seulement pour le patch, assurez-vous de lire README en
premier.

Q: Où puis-je trouver les nouvelles versions du patch ?
Q: J'ai seulement le patch pour Linux 2.0, où puis-je obtenir une version
pour Linux 2.2 (ou vive versa) ?
R: http://www.openwall.com/linux/

Q: Mettrez-vous à jour le patch pour la nouvelle version de noyau 2.0.x ?
R: Si jamais une 2.0.40 est sortie, je la supporterai probablement.

Q: Et à propos de 2.2.X ?
R: Je supporterai sans aucun doute les futures versions 2.2.x du noyau.

Q: Et à propos de 2.4.x ?
R: Je commencerai probablement à supporter ces noyaux 15 révisions après
2.4.0. Mon conseil est d'utiliser 2.2 sur les systèmes de "production"
jusqu'alors.

Q: Est-ce que le patch est spécifique à x86 ?
R: Seulement la fonctionnalité de la pile non exécutable du patch est
spécifique à x86. Le patch est testé et utilisé sur d'autres architectures
également. En fait, j'ai sorti quelques mises à jour mineures du patch après
les avoir testées sur Alpha seulement dans le passé.

Q: Il y a t'il des problèmes avec le patch sur des systèmes SMP ?
R: Aucun dont je sois actuellement au courant. J'ai exécuté toutes les
versions de ce patch depuis 2.0.33 sur SMP.

Q: Pourquoi ne le mettent-ils pas dans le noyau standard ?
R: Ceci n'est pas une question triviale à répondre. D'abord, quelques
parties de versions plus anciennes du patch (ou des rustines équivalentes,
mais différentes) sont en fait dans le noyau maintenant. C'est la raison
pour laquelle le patch pour 2.0.36 est plus petit qu'il était lors de
2.0.33. Maintenant le patch pour 2.2.13 est une fois encore plus petit que
sa dernière version 2.2.12. :-) Ainsi, les problèmes de sécurité dans le
noyau lui-même sont typiquement réparés. Il est vrai, toutefois, que les
fonctionnalités de "durcissement" du patch ne sont pas incluses. Une des
raisons pour ceci est que ces fonctionnalités pourraient résulter dans un
faux sens de sécurité. Quelqu'un pourrait alors décider de ne pas réparer un
trou sur un système qu'il administre ou un logiciel qu'il maintient juste à
cause de ces fonctionnalités noyau. Si une telle chose arrive, la sécurité
est en fait relâchée, non pas améliorée. Les restrictions rlimit que j'ai
ici sont des bidouilles temporaires à remplacer avec une solution réelle
(beancounters), ainsi je n'essaye pas de les faire mettre dans le noyau.
Finalement, il y a quelques fonctionnalités ici dont je pense qu'elles
pourraient être incluses (je ne connais pas de bonne raison contre faire
cela), tel que la rustine fd 0-2.

Q:J'ai appliqué le patch, et maintenant mon noyau ne compile plus ?
R: Êtes-vous sûrs d'avoir appliqué le patch exactement comme montré dans le
README ? S'il vous plaît, essayez encore avec une arborescence de sources
connue comme propre.

Q: Est-ce que les programmes compilés avec GCC qui utilisent les trampolines
fonctionnent avec la partie pile non exécutable du patch ?
R: Oui, si vous activez le support.

Q: Quand j'essaye d'utiliser 'print f()' dans gdb sur un système Linux 2.2
avec votre patch, mon programme plante. Que se passe t'il ?
R: Les changements faits dans Linux 2.2 ne m'ont pas laissé porter mon vieux
contournement pour ceci depuis la version Linux 2.0 du patch. Vous devrez
utiliser chstk.c sur le programme que vous déboguez afin d'utiliser cette
fonctionnalité de gdb.

Q: Pourquoi GCC utilise des trampolines ?
R: Les trampolines sont utilisés pour supporter pleinement une des
extensions du C GNU, "nested functions". Quand une telle fonction est
appelée depuis l'extérieur de celle dans laquelle elle était déclarée
(c.-à-d., via un pointeur de fonction), quelque chose a besoin de fournir le
"cadre de la pile". La mauvaise chose est que GCC met les trampolines dans
la pile (puisqu'ils sont générés en cours d'exécution). Vous pouvez trouver
un exemple dans stacktest.c, inclus avec ce patch.

Q: Comment différenciez vous un appel par trampoline d'une tentative
d'exploitation ?
R: Puisque la plupart des exploitations de débordements de tampons écrasent
l'adresse de retour, l'instruction à passer le contrôle à la pile doit être
un RET. En appelant un trampoline, l'instruction est un CALL. Notez que dans
quelques cas une telle autodétection peut être dupée en RET'ournant à une
instruction CALL et faire que ce CALL passe le contrôle à la pile (en
réalité, ceci requière également qu'un registre soit positionné à l'adresse,
et ne fonctionne de cette façon que sous Linux 2.0). Lisez l'aide de
l'option de configuration de 'Autodetect GCC trampolines'.

Q: Et à propos de glibc et de la pile non exécutable ?
R: Vous devez activer l'autodétection de trampolines en utilisant glibc
2.0.x, ou le système ne démarrera même pas. Si vous exécutez Linux 2.0, vous
voudrez aussi probablement activer l'émulation d'appel par trampoline pour
éviter d'exécuter un processus privilégié avec une pile exécutable.

Q: J'ai juste compilé glibc sur mon système, mais "make check" échoue en
essayant de charger testobj1.so. Que se passe t'il ? Est-ce que la glibc
nouvellement compilée fonctionnera avec votre patch dans le noyau ?
Q: Quel est le but de glibc-2.1.3-cvs-20000504-dl-open.diff ?
R: La partie pile non exécutable du patch change l'adresse par défaut où les
bibliothèques partagées sont mmap()'ées. Malheureusement, quelques parties
de la glibc dépendent que cette adresse soit au dessus des sections ELF.
C'est un bogue. La bonne chose est que probablement le problème ne se montre
seulement qu'avec la fonctionnalité ORIGIN peu utilisée, et seulement quand
l'éditeur de liens dynamiques est exécuté en tant que programme standalone.
Il est ainsi hautement improbable que ceci cause une cassure de quelque
chose d'autre que "make check". Vous pouvez, toutefois, utiliser la rustine
incluse avec ce patch.

Q: Qu'est-ce que le patch procps-2.0.6-ow1.diff fait ? Est-il requis pour
que le patch noyau fonctionne ?
R: Ce patch procps met à jour la vérification des entrées viciées de utmp,
afin que w(1) dans procps 2.0.x jusqu'à 2.0.6 fonctionne correctement sur
les systèmes avec l'option /proc restreint. Si vous ne connaissez pas de
problème avec w(1), vous n'avez pas besoin d'installer le patch procps.

Q: Pourquoi est chstk.c ?
R: Le patch ajoute un drapeau supplémentaire aux entêtes ELF et a.out, qui
contrôle si le programme sera autorisé à exécuter du code sur la pile ou
non, et chstk.c est ce que vous devez utiliser pour gérer ce drapeau. Vous
pouvez le trouver utile si vous choisissez de désactiver l'autodétection des
trampolines GCC. En passant, définir le drapeau restaure également l'adresse
originale où les bibliothèques partagées sont mmap()'ées, au cas où quelques
programmes dépendent de cela.

Q: Et si un attaquant utilise chstk.c dans une exploitation de débordement
de tampon ?
R: Rien ne change. C'est le programme vulnérable qui est exploité qui a
besoin d'une pile exécutable, non pas l'exploitation. L'attaquant aurait
besoin d'un accès en écriture au binaire de ce programme pour utiliser
chstk.c avec succès.

Q: Ai-je besoin de redémarrer avec un noyau non patché pour essayer une
nouvelle exploitation de débordement pour voir si je suis vulnérable ?
R: Non, vous pouvez utiliser chstk.c sur le programme vulnérable pour
l'autoriser temporairement à exécuter du code sur la pile. N'oubliez pas de
redéfinir le drapeau comme avant quand vous avez fini. Également soyez
attentifs en comptant sur de tels tests : typiquement, ils ne peuvent pas
prouver que vous n'êtes pas vulnérables, ils peuvent seulement de temps en
temps prouver le contraire. Notez que définir ce drapeau sur les systèmes
Linux 2.2 changera la position par défaut de la pile de 8 Mo plus bas que là
où beaucoup d'exploitations espèrent qu'elle est.

Q: Des applications sont elles connues pour requérir une pile exécutable
et/ou l'adresse mmap() traditionelle par défaut ?
R: Oui. JDK 1.3 and XFree86 4.0.1 (seulement avec les pilotes commerciaux
nVidia GeForce) ont été reportés de ne pas fonctionner à moins qu'ils aient
été chstk'és. Beaucoup d'applications Win32 et de DLL (telles que celles de
codages/décodages vidéo) sont non repositionables et doivent être chargées à
leur adresse par défaut qui ne doit pas être déjà prise par les
bibliothèques partagées d'une application Linux telle Wine ou MPlayer.
chstk'er simplement les binaires "wine" et "mplayer" résoud ce problème.

Q: Pourquoi modifiez vous le code de retour du traitement du signal ?
R: Originellement le noyau met du code dans la pile pour retourner depuis
les gestionnaires de signaux.  Maintenant les retours depuis les
gestionnaires de signaux sont plutôt faits par le gestionnaire de GPF (une
adresse de retour invalide et magique est mise dans la pile).

Q: Que faire si un programme a besoin de suivre un lien symbolique dans un
répertoire +t pour ses opérations normales (sans introduire un trou de
sécurité) ?
R: D'habitude un tel lien n'a besoin d'être créé qu'une seule fois, donc
créez le en tant que root (ou le propriétaire du répertoire, si ce n'est pas
root). De tels liens sont suivis même quand le patch est activé.

Q: Que va t'il arriver si quelqu'un fait :
	ln -s /etc/passwd ~/link
	ln -s ~/link /tmp/link
et que le programme vulnérable s'exécute en tant que root et écrit vers
/tmp/link ?
R: Le patch ne regarde pas la cible du lien symbolique dans /tmp, il vérifie
seulement si le lien symbolique lui-même appartient à l'utilisateur en tant
que qui le programme vulnérable s'exécute, et ne suit pas le lien sinon
(comme dans cet exemple).

Q: Il y a t'il des impacts en performances à utiliser ce patch ?
R: Bien, normalement la seule chose affectée est le retour des gestionnaires
de signaux. Je ne voulais pas modifier l'appel système sigreturn, donc il y
a du code supplémentaire pour définir sa "stack frame". Je ne pense pas que
cela ait un effet visible sur la performance (et mes tests de performance le
prouvent) : les vérifications des contextes sauvegardés et autres affaires
de traitement du signal prennent bien plus de temps. Également, les
programmes utilisant les trampolines GCC s'exécuteront plus lentement si les
appels par trampolines sont émulés. Toutefois, Je ne connais pas de
programme utilisant les trampolines où la performance soit critique (ce
serait une chose stupide de faire cela de toutes façons).