Linux : Une faille dans le nouveau noyau 2.6.31

**ovh** · 22/07/2009, 16h20

Mise à jour du 20/09/09

Linux : Une faille dans le nouveau noyau 2.6.31

Brad Spengler en remet une couche.

Après avoir trouvé une faille dans le kernel 2.6.30 (cf news précédente), le responsable du projet grsecurity s'est cette fois-ci attaqué à la toute dernière mouture du noyau sortie le 9 Septembre dernier.

L'exploit est avéré par deux vidéos :

[ame="http://www.youtube.com/watch?v=ShoAOdx0K7I"]YouTube - Linux 2.6.31 perf_counter 0day Local Root Exploit[/ame]

[ame="http://www.youtube.com/watch?v=zsSTukox8ZA"]YouTube - Linux 2.6.31 perf_counter x64 Local Root Exploit[/ame]

De quoi raviver la polémique qu'avait lancée Brad Spengler sur la sécurité de Linux qui serait, d'après lui, prise par dessus la jambe par les développeurs du Kernel ?

Mise à jour de Gordon Fowler.

[Linux] Faille critique corrigée dans le noyau 2.6.30 et polémique

Brad Spengler, responsable du projet grsecurity, a réussi à exploiter une faille critique dans le noyau 2.6.30 (corrigée dans le 2.6.30.2). Initialement considérée comme un "simple" bug non dangereux, le programmeur a prouvé, code d'exploit à l'appui, que la faille était bien réelle. C'est une optimisation de GCC, le compilateur C libre, qui permet d'exploiter la faille, qui rend possible la désactivation de dispositifs de sécurité comme SELinux, AppArmor ou LSM.

L'auteur de cette découverte fustige les auteurs du noyau linux dans les commentaires de son code source, en leur reprochant leur politique de développement, notamment la gestion des bugs dont l'impact sur la sécurité serait sous-évalué.

Pas de panique cependant si vous utilisez le noyau par défaut de votre distribution : aucune d'entre elle n'utilise encore cette version.

L'expoit commenté

http://article.gmane.org/gmane.comp....sclosure/68469

**jaimepaslelundi** · 22/07/2009, 17h22

Pas de panique cependant si vous utilisez le noyau par défaut de votre distribution : aucune d'entre elle n'utilise encore cette version.

Si certaine distributions comme la archlinux utilisent ce noyau. Il faut donc que les utilisateurs mettent à jour leurs systèmes

Invité · 23/07/2009, 08h50

Linux a des bugs ? On m'aurait menti ?

Notons quand même la rapidité de correction de la faille

Cordialement

**granquet** · 23/07/2009, 11h33

de ce que je sais; voici le code incrimine:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
struct sock *sk = tun->sk; // initialize sk with tun->sk
...
if (!tun)
return POLLERR; // if tun is NULL return error

n'importe quel codeur C auras compris d'ou viens le probleme, tun est dereference pour initialiser la structure sk.
si tun est NULL, alors il y'as un crash (comportement indetermine pour etre precis)
il n'est donc pas necessaire de verifier si tun est NULL par la suite ... d'ou "l'optimisation" faite par gcc.

pour moi la faute ne viens absolument pas de gcc, mais d'une grosse etourderie dans le code

**stephgil29** · 26/07/2009, 20h18

Il n'y a que ce qui font rien qui ne risque rien. L'erreur est humaine, est en plus quand elle est bénévole j'ai du mal à la condamner.
Plutôt que de jeter la pierre à celui qui fait une erreur, je préfère le remercier de faire parti de ceux qui me permettent d'avoir le choix.

Stephane

**s4mk1ng** · 27/07/2009, 09h15

comme dit plus haut notons la rapidité de correction de la faille...

**LordMacharius** · 27/07/2009, 13h26

La faille a été corriger rapidement mais il reste important de pense au faille de sécurité !

j'en ai fait les frais moi même cette année et depuis je suis beaucoup plus vigilant .
L'erreur est humaine , et la machine est programmée par l'homme dont défaillante par nature =)

**gangsoleil** · 28/07/2009, 16h15

Bonjour,

Le probleme pointe par Brad Spengler ne concerne ni la qualite du code, ni le temps necessaire a la correction du prcbleme une fois celui-ci identifie, mais la facon dont la dangerosite des bugs est evaluee.

Le fait de voir dans cet exploit un "simple bug" et non pas une faille de securite qui implique des devs immediats indique un reel soucis dans la politique de developpement :
"L'auteur de cette découverte fustige les auteurs du noyau linux dans les commentaires de son code source, en leur reprochant leur politique de développement, notamment la gestion des bugs dont l'impact sur la sécurité serait sous-évalué."

Si on pense que chaque probleme n'est qu'un bug et ne peut pas avoir d'impacts sur la securite, alors on n'a que tres rarement des problemes de securite.

**gangsoleil** · 28/07/2009, 16h19

Envoyé par granquet

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
struct sock *sk = tun->sk; // initialize sk with tun->sk
...
if (!tun)
return POLLERR; // if tun is NULL return error

pour moi la faute ne viens absolument pas de gcc, mais d'une grosse etourderie dans le code

A ce niveau la, ce n'est plus une etourderie, mais un sacre probleme !

Le code du noyau se doit d'etre irreprochable, car la moindre faille peut s'averer extremement dangeureuse.

**ZeRevo** · 12/08/2009, 15h53

Dans des milliers de ligne de code, ca saute pas aux yeux désolé ~~

Avant de critiquer les programmeurs, ça serait bien de revoir les optimisations faites par gcc. Il supprime le code inutile dans un but d'"optimisation" mais je préférais qu'avant de supprimer du code, il vérifie que ce code n'a pas été placé par hasard.

**Gordon Fowler** · 20/09/2009, 16h49

MAJ : Une faille également dans le nouveau noyau 2.6.31

**exodev** · 20/09/2009, 23h12

Apparemment la faille dans le noyau 2.6.31 est produite avec une fonctionnalité introduite depuis ce même noyau. Aucun problème avec les noyaux précédents donc.

**Aurelien.Regat-Barrel** · 21/09/2009, 09h19

Envoyé par ZeRevo

Avant de critiquer les programmeurs, ça serait bien de revoir les optimisations faites par gcc. Il supprime le code inutile dans un but d'"optimisation" mais je préférais qu'avant de supprimer du code, il vérifie que ce code n'a pas été placé par hasard.

T'es pas en train de critiquer les programmeurs de gcc là ?

**ZeRevo** · 21/09/2009, 10h30

Pas les programmeurs mais les specs

**Neko** · 21/09/2009, 10h34

faute partagée. C'est clairement une erreur du programmeur du kernel, mais GCC détectant manifestement l'erreur devrait au moins afficher un warning au lieu de "bêtement" l'optimiser. Après, si GCC affiche effectivement un warning c'est complètement la faute du programmeur du kernel.

Parce-que c'est quand même mieux de vérifier si un pointeur est null avant de l'utiliser qu'après.

**gangsoleil** · 21/09/2009, 11h33

Bonjour,

Envoyé par Neko

GCC détectant manifestement l'erreur devrait au moins afficher un warning au lieu de "bêtement" l'optimiser. Après, si GCC affiche effectivement un warning c'est complètement la faute du programmeur du kernel.

Reste donc a savoir quelles sont les options de compilation utilisees lors de la compilation... Parce que si ce sont des options du type de celles qu'utilise Emmanuel Delahaye, alors il y a de fortes chance pour qu'il y ait au moins un warning.

**granquet** · 21/09/2009, 14h21

je ne suis pas au courant d'un quelquonque warning de gcc a ce sujet (mais on vas attendre les pros pour etre sur

)

voila ce que dis gcc sur l'optimisation en question.

Envoyé par man gcc

-fdelete-null-pointer-checks
Use global dataflow analysis to identify and eliminate useless
checks for null pointers. The compiler assumes that dereferencing
a null pointer would have halted the program. If a pointer is
checked after it has already been dereferenced, it cannot be null.

In some environments, this assumption is not true, and programs can
safely dereference null pointers. Use
-fno-delete-null-pointer-checks to disable this optimization for
programs which depend on that behavior.

Enabled at levels -O2, -O3, -Os.

ca semble logique ... et etre le comportement desire par 90% des programmeurs en userland ...
je vous redirige vers un article bien foutu de chez LWN en briton: http://lwn.net/Articles/342330/

**chemanel** · 21/09/2009, 16h50

Est ce que cette faille a déjà été patchée?
Quel est le temps de réaction de la communauté pour patcher une faille de ce genre?

Invité · 21/09/2009, 18h38

Bonjour, je tenais à dire que je suis limite content de voir ça car c'est peouve contrairement à ce que certains affirment ou croient que Linux a des failles!