vendredi 05 février
Accueil :: Dépêches :: Entretiens :: Journaux :: Forums :: Sondages :: Suivi :: Statistiques :: Contact :: Plan

Liens connexes

Dépêche modérée par

Dépêche éditée par

: Exploit local dans le noyau Linux 2.6.30

Posté par Victor STINNER (Jabber id, page perso, ). Modéré le 18 juillet 2009.
27
Brad Spengler, mainteneur du projet Grsecurity, a publié un exploit local pour le noyau Linux. Seule la version 2.6.30 du noyau est impactée. L'exploit a été publié rapidement car aucune distribution n'utilise cette version pour le moment. Il est capable de contourner les protections AppArmor, SELinux, LSM, et désactive l'audit. La faille concerne les interfaces réseaux virtuelles tun et a été introduite en février dernier. D'abord considérée comme un simple bug, elle a été découverte le 4 juillet, corrigée le lendemain, puis Brad a publié son exploit le 15 juillet.

Brad profite de l'exploit pour dire tout le mal qu'il pense de la gestion de la sécurité dans le noyau Linux (lire notamment tous les commentaires présents dans le fichier exploit.c du tgz). Il reproche notamment la correction silencieuse de failles qui pose problème aux distributions Linux : les mainteneurs ne savent pas quels patchs doivent être backportés dans les branches stables. Il reproche également l'absence d'analyse de l'impact d'un bug en terme de sécurité : certaines failles sont considérées comme non exploitables, alors qu'elles le sont.

La seconde partie de cette dépêche détaille la faille.

> Lire la suite (128 commentaires, moyenne: 3).   [dépêche : 1285 caractères]

La faille est intéressante, car en lisant le code source, elle ne semble pas exploitable. En fait, comme le pointeur est déréférencé avant qu'on teste si le pointeur est NULL, gcc supprime le test car il suppose que de toute façon le déréférencement causera une erreur fatale. L'option -fno-delete-null-pointer-checks de gcc permet de désactiver cette optimisation. Extrait du code posant problème :
struct sock *sk = tun->sk;
...
if (!tun) return POLLERR;
L'exploit alloue de la mémoire à l'adresse 0 (NULL) dans l'espace utilisateur où le code de l'exploit sera écrit. Le déréférencement du pointeur NULL ne cause donc pas d'erreur dans le noyau.

En décembre 2008, Julia Lawall avait posté 3 patchs (drm, agnx et go7007) corrigeant des bugs similares. Les patchs ont été générés avec Coccinnelle : outil permettant de patcher les pilotes Linux en utilisant des règles décrites dans un langage haut niveau.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

Kernel 2.6.30

Posté par Kazuya () le 18/07/2009 à 12:47. (lien). Évalué à 6.

Hello,
'[...]car aucune distribution n'utilise cette version pour le moment.'

Et bien moi si (avec la version tildarchée de Gentoo) et il y a également Pardus 2009 qui utilise un kernel 2.6.30 (et peut-être d'autres...).

ArchLinux

Posté par Peres Martin (page perso, ) le 18/07/2009 à 12:51. (lien). Évalué à 4.

Il y a aussi ArchLinux ;) Mais comme on installe un nouveau kernel dès la sortie d'une version de sécurité, on a pas de problèmes à se faire.

Quelques commentaires

Posté par patrick_g (page perso, ) le 18/07/2009 à 12:56. (lien). Évalué à 10.

>>> Brad profite de l'exploit pour dire tout le mal qu'il pense de la gestion de la sécurité dans le noyau Linux

Brad a toujours été hyper-critique sur la sécurité du noyau Linux. Il faut bien voir que son gagne pain c'est grsecurity c'est à dire un patch de sécurité à appliquer sur le noyau vanilla. Il a donc tout intérêt à dénigrer le noyau normal afin de souligner la plus-value de son patch.
Donc il faut prendre ce qu'il dit avec un gros grain de sel.
Néanmoins on est forcé de constater que ses déclarations ont plus de force quand elles sont accompagnés d'un exploit 0-day qui passe à travers SELinux ;-)

Il faut vraiment lire tout le blabla qu'il a mis en commentaire du fichier exploit.c car c'est très instructif sur le coté technique de la faille mais aussi sur le personnage qu'est Brad.
Ce qui m'a étonné c'est qu'il colle des extraits de mails issus de la liste de diffusion vendor-sec.
Cette liste est faite pour que des informations circulent entre les développeurs et les entreprises du libre au sujet des problèmes de sécurité. Bien entendu la liste est privée et dévoiler ainsi des mails privés comme le fait Brad est plus qu'impoli. Je me demande même si ce n'est pas illégal.

Il faut savoir que Brad avait commencé par poster des vidéos de son exploit à l'oeuvre mais sans donner de détails techniques. Dans les commentaires d'exploit.c il se délecte de lire les échanges de mails sur vendor-sec (en ne donnant pas le nom du type qui lui a fourni les mails) ou les gens essayent, en ayant la vidéo pour seule information, de comprendre d'ou peut bien venir la faille.
Il distribue les bons points et les mauvais points en fonction des analyses proposés, il casse du sucre sur le dos de Linus Torvalds, qualifié d'expert sécurité en fauteuil (arm-chair security expert) et enfin il balance un paragraphe final sur la sécurité du noyau qui serait déplorable.

Ci-dessous je traduis l'ironique paragraphe d'introduction et le paragraphe final (je refuse de traduire les mail privés de vendor-sec).

"Un mec monté sur son cheval m'a apporté ces informations : toutes mes félicitations aux membres de vendor-sec pour leur excellente analyse de la vidéo de mon exploit, dans la même veine que leurs analyses des vulnérabilités du noyau. Regardez les maitres à l'oeuvre".

"Aux membres de vendor-sec : Même si vous ne me remercierez jamais (ou sgrakkyu ou Julien) vous êtes les bienvenus pour toute cette recherche gratuite dans le domaine de la sécurité qui aurait aussi bien pu être vendue dans le privé à la place. L'industrie (NdT : le marché des exploits) n'est plus ce qu'elle était en 2000, les gens ne publient plus les exploits maintenant : ils font du fric avec.
Ne pas voir débouler des exploits ne signifie donc pas que vous faites du bon travail. Avez-vous noté les exploits très complexes qui apparaissent impossiblement rapidement juste après qu'une faille soit finalement patchée ? Il y a une raison pour ça.
Si le code vulnérable avait été incorporé dans le 2.6.29 au lieu de l'être dans le 2.6.30 je n'aurai pas publié mon exploit. Je n'ai pas l'utilité de cet exploit...mais une bonne poilade ne se refuse jamais.
- Ma suggestion est que vous engagiez des gars comme sgrakkyus ou Julien plutôt que ces vieux qui n'ont jamais écrit un exploit de toute leur vie. A part Stealth je ne connais personne de doué dans cette industrie et qui soit employé par vous.
- Deuxième suggestion : Comme vous êtes des compagnies qui poussent l'open source et le logiciel libre ce serait bien si les justifications pour vos classifications de vulnérabilités étaient plus transparentes (ou même qu'elle soient publiées tout simplement). La vieille habitude que vous avez de classifier toute faille pour laquelle un exploit n'a pas été écrit en Denial of Service devient très fatigante et ne trompe plus personne.
- Troisièmement, la politique officielle qui consiste à ne pas mentionner les informations qui concernent la sécurité lors des modifications du code de Linux est une honte et un mauvais service que vous rendez à vous même, aux autres vendeurs et à vos clients. Cela démontre un manque d'intégrité et de confiance dans vos propres produits. Je sais que vous n'avez aucune intention de changer cette politique puisque vous profitez grâce à celle-ci d'une réputation de sécurité indue et qui ne se base pas sur la réalité. Dire la vérité sur les vulnérabilités de vos logiciels ternirait votre image et ce n'est pas bon pour le business. Vous êtes félicités quand vous dissimulez des choses et pourtant c'est Microsoft qui à une mauvaise réputation.
Si vous suivez les conseils que je vous donne alors peut-être que votre sécurité ne sera plus la risée de toute l'industrie".

A noter, pour répondre à une partie des critiques de Brad, que les mainteneurs des versions stables des noyaux se refusent à classer les corrections de bugs en fonction de critères de sécurité car pour eux il n'est pas possible de savoir à l'avance toutes les implications en matière de faille d'un bug donné.
Brad affirme que cette politique de non classification empêche les gens de faire des choix quand aux corrections à appliquer et les mainteneurs lui répondent qu'il n'y a pas de choix à faire et qu'il faut de toute façon appliquer toutes les corrections.

Bien malin celui qui peut dire qui a raison et qui a tort dans cette controverse, si les développeurs du noyau sont suffisamment attentifs aux problèmes de sécurité ou pas, si la réputation de Linux est vraiment surfaite ou si Brad exagère afin de pousser sa solution.
Les pauvres péons que nous sommes sont bien en peine de trier et d'évaluer vraiment les affirmations des uns et des autres...mais en tout cas la controverse est lancée et la situation ne peut que s'améliorer.

Sus à l'anglois !

Posté par Grasyop () le 18/07/2009 à 14:35. (lien). Évalué à 7.

« Seule la version 2.6.30 du noyau est impactée. »

Impacter n'est pas français ; on dit « affecter » !

(Cette dépêche contient d'autres anglicismes, mais celui-là me déplaît particulièrement.)

Il me manque une piece du puzzle

Posté par flyer () le 18/07/2009 à 18:27. (lien). Évalué à 1.

Qui saurait expliquer comment une affectation de variable se transforme en appel de code arbitraire?

(desole pour l'absence d'accent)

Je ne comprends pas

Posté par Éric (Jabber id, page perso, ) le 19/07/2009 à 00:49. (lien). Évalué à 4.

Je ne connais pas assez pour juger mais quand je lis la news j'ai l'impression qu'on me dit "le code est bon n théorie mais le compilateur fait une optimisation foireuse qui créé la faille de sécurité".

Il me parait très sain de dire que le kernel en question a un problème et de palier ce problème, mais ce n'est pas surtout le compilateur qui dans ce cas a un énorme bug ? Un compilo qui ajoute des failles de sécurités c'est surtout ça qui me parait dangereux et qui est à corriger. Ce n'est pas vraiment aux développeurs de prévoir et contourner les optimisations foireuses du compilo.

Or je vois des annonces à propos du kernel mais pas à propos d'une correction critique de gcc. J'ai mal compris un truc ?

L'avis de Mingo

Posté par patrick_g (page perso, ) le 19/07/2009 à 08:24. (lien). Évalué à 4.

Un excellent commentaire d'Ingo Molnar à propos de la chronologie de cet exploit et surtout à propos de la personnalité (tordue) de Brad et des créateurs d'exploits.
Vraiment très intéressant à lire :

http://lwn.net/Articles/342163/

SELinux

Posté par Denis Montjoie (page perso, ) le 19/07/2009 à 10:23. (lien). Évalué à 2.

Il a l'air de dire que SELinux c'est pourri mais son exploit ne marche que parseque il est executé en contexte unconfined_t, ce qui n'arriverais pas si SELinux était "vraiment" utlisé (aka utilisateur en user_t, pulseaudio en pulseaudio_t etc... )
(information confirmé sur #selinux)

PS: unconfined_t ca veux dire "pas confiné par SELinux", pour ceux qui n'en ont jamais fait.


UPDATE: not just that, SELinux lets any user in unconfined_t map at
0, overriding the mmap_min_addr restriction! pulseaudio is not
needed at all! Having SELinux enabled actually *WEAKENS* system
security for these kinds of exploits!

Coccinnelle

Posté par Kyle_the_hacker () le 20/07/2009 à 10:45. (lien). Évalué à 1.

Un seul n à coccinelle (et non "coccinnelle")

[+] TUN

Posté par blubliblo () le 20/07/2009 à 10:53. (lien). Évalué à -3.

Bin j'ai un 2.6.30 mais j'ai pas tun de monté... en fait même pas compilé.
D'ailleurs pour le monter, il faut un programme SUID root genre pulseaudio (d'ailleurs à quand un mixer en C pour lui, qui ne descent pas tout gnome?)
Et puis il faut rappeler qu'aucun système n'est sûr. Certains sont justes de notoriété plus sûrs, c tout. Donc à partir de là autant privilégier des systèmes (A)GPL pour favoriser la publication de code correctifs de failles.

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.3877s (dont 0.0332 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !