IdentifiantMot de passe
Mot de passe oublié ?Je m'inscris ! (gratuit)

Vous êtes nouveau sur Developpez.com ? Créez votre compte ou connectez-vous afin de pouvoir participer !

Vous devez avoir un compte Developpez.com et être connecté pour pouvoir participer aux discussions.

Vous n'avez pas encore de compte Developpez.com ? Créez-en un en quelques instants, c'est entièrement gratuit !

Si vous disposez déjà d'un compte et qu'il est bien activé, connectez-vous à l'aide du formulaire ci-dessous.

Identifiez-vous
Identifiant
Mot de passe
Mot de passe oublié ?
Créer un compte

L'inscription est gratuite et ne vous prendra que quelques instants !

Je m'inscris !

Linux : Faille critique corrigée dans le noyau 2.6.30
Mais l'auteur de cette découverte fustige les auteurs du noyau linux

Le , par ovh
20 commentaires

1PARTAGES

1  0 
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

Une erreur dans cette actualité ? Signalez-nous-la !

20 commentaires
Commenter Signaler un problème
jaimepaslelundi
Avatar de jaimepaslelundi
Nouveau membre du Club https://www.developpez.com
Le 22/07/2009 à 17:22
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
1  0 
Avatar de
https://www.developpez.com
Le 23/07/2009 à 8:50
Linux a des bugs ? On m'aurait menti ?

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

Cordialement
1  0 
granquet
Avatar de granquet
Membre expérimenté https://www.developpez.com
Le 23/07/2009 à 11:33
de ce que je sais; voici le code incrimine:

Code : Sélectionner tout 
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
1  0 
stephgil29
Avatar de stephgil29
Membre actif https://www.developpez.com
Le 26/07/2009 à 20:18
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
1  0 
s4mk1ng
Avatar de s4mk1ng
Membre expérimenté https://www.developpez.com
Le 27/07/2009 à 9:15
comme dit plus haut notons la rapidité de correction de la faille...
1  0 
LordMacharius
Avatar de LordMacharius
Membre averti https://www.developpez.com
Le 27/07/2009 à 13:26
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 =)
1  0 
gangsoleil
Avatar de gangsoleil
Modérateur https://www.developpez.com
Le 28/07/2009 à 16:15
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.
1  0 
gangsoleil
Avatar de gangsoleil
Modérateur https://www.developpez.com
Le 28/07/2009 à 16:19
Citation Envoyé par granquet Voir le message

Code : Sélectionner tout 
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.
1  0 
ZeRevo
Avatar de ZeRevo
Membre averti https://www.developpez.com
Le 12/08/2009 à 15:53
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.
1  0 
Gordon Fowler
Avatar de Gordon Fowler
Expert éminent sénior https://www.developpez.com
Le 20/09/2009 à 16:49
MAJ : Une faille également dans le nouveau noyau 2.6.31
1  0 
Commenter Signaler un problème