Linux : Une faille dans le nouveau noyau 2.6.31

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.

Citation:

---

[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é :fleche: http://article.gmane.org/gmane.comp....sclosure/68469

---

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

Linux a des bugs ? On m'aurait menti ? :aie:


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



Cordialement

de ce que je sais; voici le code incrimine:

Code:

---

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 :aie:

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

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

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 =)

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.

Citation:

---

Envoyé par granquet

Code:

---

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 :aie:

---

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.

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.

MAJ : Une faille également dans le nouveau noyau 2.6.31

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.

Citation:

---

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à ? ;)

Pas les programmeurs mais les specs

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.

Bonjour,

Citation:

---

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.

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

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

Citation:

---

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/

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?

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!

Citation:

---

Envoyé par chemanel

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?

---

Dans les 2 cas la faille a été patchée avant l'annonce "médiatique" (le lendemain de sa découverte pour celle du noyau 2.6.30)