Je signalecette excellente interview de linuxfr si certains l’ont laissé passé.
ça fait suite à la publication d’un exploit sur linux 2.6.30 par la même personne, d’où les màj en …30.1 et …30.2 qui ont suivi.
Il y a l’explication de l’exploit ici, qui entre parenthèse m’a complètement abasourdi tant il devient évident pour moi que les pirates doivent parser le code automatiquement (source et binaire) pour utiliser ce genre de choses : ça ne se rencontre pas par hasard dans un source de 250Mo…
Ca veut dire aussi qu’en pratique je n’ai probablement écrit aucun code sûr, et pourtant, il y en a dans linux, et pourtant j’ai “essayé” de penser à la sécurité.
Comme le dit Brad Spengler, ceux qui codent le noyau ne peuvent pas se donner à la sécurité ni même la penser à la façon d’un pirate. il faut des personnes dédiées.
:jap:
Comprends pas.
Je suis HS là (creuvé et un peu malade) et je ne comprends pas du tout:
struct sock *sk = tun->sk; // initialize sk with tun->sk
if (!tun)
return POLLERR; // if tun is NULL return error
Heu…si tun est null, tun->sk va mal se passer donc on se fiche un peu du fait que gcc vire le if après avoir vu que tun a été assigné.
C’est donc la ligne struct sock *sk = tun->sk; qui est totalement daubée…ou alors je vais me coucher direct (bcp de sommeil en retard 
)
patchwork.kernel.org… : Ok. On teste AVANT. C’est censé.
Par contre, je ne comprends pas l’exploit (mais je n’ai pas encor elu son source) et le lien avec le fait que gcc vire le test:
si tun est nul, ca doit péter AVANT le test non? ca pète sur tun->sk?
Il y a une option de gcc qui empeche de toucher à ce genre de test. Si elle fonctionne correctement, il serait temps de l’utiliser.
v_atekor: L’analyse statique du code (par ex) permet “facilement” de détecter ce genre de pb. La preuve, gcc le fait à la compilation et vire le test. Il est clair qu’il existe de nombreux autre outils (surtout dans les labos) capable de lister tous les bugs de ce genre…
J’espère que les moulinettes ont tourné pour vérifier TOUS les if(!foo)
fakbill, qui retourne à son python 
Edité le 28/07/2009 à 13:52
En fait le pointeur est déréférencé (et non mis à NULL) avant un test if(!pointeur)
Ce qui normalement aboutit à un SIGFAULT lors du test if et comme on est dans le noyau on a droit à un dump : impossible de manquer un truc aussi gros.
Sauf que … par optimsation gcc supprime le test if(!pointeur) puisque à la base un pointeur déréférencé est non NULL, du coup tu te retrouves avec un pointeur dans le décors qui est réutilisé par l’exploit pour exécuter du code arbitraire.
Evidement un déréférencement avant un test tu le vois vite, mais c’est surtout la façon de penser du pirate qui me stupéfait. Je n’irai jamais chercher ce genre de raisonnements en codant
Forcer gcc à ne PAS optimiser ça me semble plus que nécessaire…
Admire l’outil qui permet de détecter/corriger ce genre de bug : git.kernel.org…
Edité le 29/07/2009 à 01:07