Articles précédents : Sécurité
- [7] Faille dans le noyau 2.6.31 : Brad remet le couvert
- [17] FRHack : Conférence de RMS en accès gratuit
- [8] Retour d'expérience sécurité sur 11 ans de LinuxFr.org
- [27] La République Populaire de Chine impose un logiciel de contrôle d'accès défaillant
- [6] Herdict.org pour contourner la censure de l'internet
- [1] La convention Netfilter en 2008 à Paris
- [329] Découverte d'une faille de sécurité critique dans OpenSSL de Debian
- [44] Effets pervers du modèle de sécurité BitFrost de OLPC
- [51] Un pas de plus vers la démocratisation du sftp
- [57] Important bug de sécurité sur noyau 2.6.17 à 2.6.24
Liens connexes
- CVE-2009-3547: Linux kernel Pipe NULL Pointer Dereference Race Condition (278 clics)
- Informations sur mmap_min_addr dans le wiki Debian (279 clics)
- Hole in the Linux kernel allows root access (the H security) (239 clics)
Dépêche modérée par
Dépêche éditée par
Sécurité : Faille locale dans les fonctions pipe_*_open() du noyau Linux
Posté par Victor STINNER (Jabber id, page perso, ). Modéré le 05 novembre 2009.
L'histoire pourrait s'arrêter là, mais Eugene Teo de Red Hat a découvert cinq jours plus tard que le bug est une faille de sécurité. La faille est facile à exploiter avec la boîte à outils de Brad Spengler. Comme les dernières failles du noyau Linux (vmsplice(), tun_chr_pool() et perf_counter), la faille est liée au déréférencement d'un pointeur NULL. Brad Spengler a écrit un exploit (pouvoir passer root à partir d'un compte utilisateur) fonctionnant sur, au moins, Debian Etch, Fedora (6, 10 et 11), et RedHat (5.3 et 5.4). L'exploit contourne les protections SELinux dans le cas de Fedora 10 et RedHat 5.4. Il devrait publier son exploit dans les prochains jours.
Pour se protéger (ou vérifier si votre système est vulnérable ou non), assurez-vous que la valeur de /proc/sys/vm/mmap_min_addr ne soit pas nulle. Debian Sid, Mandriva Linux 2010.0, Fedora 12, Ubuntu (Ibex et supérieurs) et les noyaux patchés avec grsecurity ne sont pas vulnérables. Alors que Debian Lenny et Squeeze ont une valeur nulle par exemple (il est prévu de changer ça à partir de Debian 5.0.4). Comme l'option mmap_min_addr a été introduite dans Linux 2.6.23, Debian Etch (qui utilise un noyau 2.6.18) est vulnérable : vous pouvez utiliser les paquets etchhalf pour installer un noyau 2.6.24. Des correctifs pour RedHat sont déjà disponibles.
![[en]](../../../images/en.png)
CVE-2009-3547: Linux kernel Pipe NULL Pointer Dereference Race Condition (278 clics)-
Informations sur mmap_min_addr dans le wiki Debian (279 clics)
-
Hole in the Linux kernel allows root access (the H security) (239 clics)
> Lire la suite (88 commentaires, moyenne: 3,3). [dépêche : 2080 caractères]
Une des raisons pour laquelle /proc/sys/vm/mmap_min_addr est toujours nul sur certaines distributions Linux est que cela pose problème avec quelques applications comme Qemu (pouvoir exécuter Qemu en tant qu'utilisateur non root, limitation supprimée dans les versions récentes), Wine ou DOSEMU.
Notons que la classe de bug « déréférencement de pointeur NULL » n'est pas spécifique à Linux, FreeBSD en est aussi victime par exemple. Pour preuve, ce bug récent découvert dans devfs : FreeBSD-SA-09:14 (lire Devfs/VFS NULL Pointer Race Condition pour les explications). Il existe une protection pour FreeBSD interdisant d'allouer une page mémoire à l'adresse NULL : FreeBSD-EN-09:05. Elle est activée par défaut sous FreeBSD 8, mais doit être activée manuellement sur les versions plus anciennes (ajoutez la ligne « security.bsd.map_at_zero="0" » dans /etc/sysctl.conf).
Rien à voir mais
Au lieu de Eugene Teo de Red Hat, j'ai lu Eugene Theo De Raadt et j'ai failli m'étouffer en croyant apprendre que le responsable du projet OpenBSD était passé passé sous Linux...
-
[^]Re: Rien à voir mais
-
[^]Re: Rien à voir mais
Posté par Raphaël Berbain () le 05/11/2009 à 10:12. (lien). Évalué à 10.C'est une erreur d'autant plus savoureuse quand on connait la réaction du Theo de Raadt sur la question: http://article.gmane.org/gmane.os.openbsd.misc/164894
Ça me rappelle que vendredi s'approche, tiens. En même temps, pour Theo, c'est un peu vendredi tous les jours.-
[^]Re: Rien à voir mais
Posté par Victor STINNER (Jabber id, page perso, ) le 05/11/2009 à 10:30. (lien). Évalué à 10.Le commit OpenBSD date de juin 2008, alors que Linux possédait déjà l'option mmap_min_addr depuis octobre 2007 (noyau 2.6.23). Mais il est vrai que la valeur par défaut ne protège pas des exploits noyau (c'est à la distribution de bien configurer Linux, choix discutable, alors qu'OpenBSD décide pour l'utilisateur).
The #1 reason why the Linux team has not commited this by default is because it breaks Wine
Petite précision pour Wine : seule l'exécution de programme Win16 (Windows 3.1 ?) dans Wine pose problème avec mmap_min_addr. Mais il n'y a pas que Wine qui est impacté par mmap_min_addr : dosemu, qemu et BitBake le sont également. Oui, qemu peut servir à émuler un système d'exploitation propriétaire, mais il est beaucoup utilisé pour tester (voir même utiliser !) Linux. kvm est d'ailleurs basé dessus. Il me semble que certains utilisent même qemu pour exécuter Linux sous Windows (mais là c'est hors sujet) :-)
Je pense également que SELinux et grsecurity protègent des bugs « déréférencement de pointeur NULL » depuis fort longtemps (ex: option « UDEREF » de PaX), mais j'ai la flemme de chercher une date.-
[^]Re: Rien à voir mais
Posté par Mickaël L () le 05/11/2009 à 18:17. (lien). Évalué à 1.> Je pense également que SELinux et grsecurity protègent des bugs « déréférencement de pointeur NULL » depuis fort longtemps
Au contraire, il me semble que les premiers exploit « déréférencement de pointeur NULL » avaient besoin de SELinux our fonctionner.
En gros, sur redhat (ou fedora, sais plus), SELinux positionnait cette fameuse mmap_min_addr à zéro, alors que par défaut dans linux ce n'était pas le cas.
A moins que je ne mélange avec autre chose.
-
-
[^]Re: Rien à voir mais
-
[^]Re: Rien à voir mais
Posté par Mr Kapouik () le 05/11/2009 à 10:48. (lien). Évalué à 2.Sa réaction n'est pas drôle : c'est Linus qui a commencé :)
--
Software is like sex: it's better when it's free
-
-
encore et toujours la meme faille (ou presque)
cela se corrige en mettant une valeur differente de zero dans /proc/sys/vm/mmap_min_addr
la question qui reste etant de savoir si ce mmap_min_addr est un patch pour corriger une faille du noyau
ou une fonctionnalité de securité non utilisée par certaines distribs pour mettre de faire fonctionner des logiciels comme Wine (il parait que Wine ne fonctionne plus si mmap_min_dir n'est pas 0 )
Apprendre par les autres, c'est bien.
Apprendre par soi-meme (RTFM, man, et notre ami google) c'est mieux
-
[^]Re: encore et toujours la meme faille (ou presque)
Posté par Victor STINNER (Jabber id, page perso, ) le 05/11/2009 à 10:41. (lien). Évalué à 2.Tiens, en lisant http://lwn.net/Articles/347390/ j'ai trouvé la justification de RedHat sur le fait que mmap_min_addr soit toujours nul : « In RHEL5 the boolean is enabled by default for backwards compatibilitally, as mmap_min_addr was introduced during the lifetime of RHEL5, allowing all unconfined domains to mmap_zero. (...) We are not planning on changing the default in RHEL5, to maintain backawards compatability. »
http://danwalsh.livejournal.com/30084.html
Pour Debian Stable, je pense que la raison est la même. Pour Debian Testing par contre, il me semble que mmap_min_addr soit toujours nul, mais j'espère que ça sera changé (c'est prévu pour Debian 5.04 en tout cas).-
[^]Re: encore et toujours la meme faille (ou presque)
Posté par maderios () le 05/11/2009 à 15:12. (lien). Évalué à 0.'il parait que Wine ne fonctionne plus si mmap_min_dir n'est pas 0'
A l'instant, chez moi, avec un noyau 2.6.31.5
Wine ouvre un .exe avec
cat /proc/sys/vm/mmap_min_addr
4096-
[^]Re: encore et toujours la meme faille (ou presque)
Posté par Mildred (Jabber id, page perso, ) le 05/11/2009 à 15:51. (lien). Évalué à 2.Et pour les applications Windos 16 bits ?
-
[+] [^]Re: encore et toujours la meme faille (ou presque)
Posté par maderios () le 05/11/2009 à 16:36. (lien). Évalué à -1.'Et pour les applications Windos 16 bits ? '
Aucune idée, vu mon niveau de connaissance concernant W$. Tout ce que je sais, c'est que si j'ai besoin d'ouvrir un fichier de tablature guitare en .rat (oui, cela existe) avec randytab.exe, aucun souci.
-
-
-
Vérification à faire avec Ubuntu
Le dépêche affirme que Ubuntu karmic n'est pas vulnérable. Or sur l'un de mes systèmes j'observe ceci:
$ cat /proc/sys/vm/mmap_min_addr
0
et sur un autre l'observe ceci:
$ cat /proc/sys/vm/mmap_min_addr
65536
Je ne sais pas encore d'où vient la différence, mais en tout cas, j'encourage tous les utilisateurs d'Ubuntu à vérifier eux mêmes.
-
[^]Re: Vérification à faire avec Ubuntu
Posté par Grunt () le 05/11/2009 à 10:43. (lien). Évalué à 10.Fais gaffe, il peut arriver que
0 == 65536-
[^]Re: Vérification à faire avec Ubuntu
Posté par Laurent Bonnaud () le 05/11/2009 à 10:53. (lien). Évalué à 4.Dans ce contexte (adresse 32 bits), je ne pense pas :>.
-
[^]Re: Vérification à faire avec Ubuntu
Posté par Misc (page perso, ) le 05/11/2009 à 14:21. (lien). Évalué à 10.Pour des très grandes valeurs de zero uniquement :)
-
-
[^]Re: Vérification à faire avec Ubuntu
Posté par Laurent Bonnaud () le 05/11/2009 à 10:49. (lien). Évalué à 10.Finalement, je viens de trouver la différence entre les 2 systèmes. Sur le système vulnérable, wine est installé et le package installe ce fichier qui modifie le paramètre mmap_min_addr du noyau:
$ cat /etc/sysctl.d/30-wine.conf
# Wine needs to access the bottom 64k of memory in order to launch
# 16 bit programs.
vm.mmap_min_addr = 0
Attention donc à ceux qui ont wine installé !-
[^]Re: Vérification à faire avec Ubuntu
-
[^]Re: Vérification à faire avec Ubuntu
Posté par Obsidian () le 05/11/2009 à 12:17. (lien). Évalué à 1.De mémoire, il me semble que cela peut être le cas avec DOSEMU également. Prudence, donc, si vous voulez relancer un System Shock ou un Day Of The Tentacle…
-
[^]Re: Vérification à faire avec Ubuntu
Posté par Possum Marsupial Power (Jabber id, page perso, ) le 05/11/2009 à 12:44. (lien). Évalué à 5.Pourquoi installer DOSEMU pour Day of the Tentacle alors que ScummVM (http://scummvm.org) est fait pour ?
Mes deux ¢ :)--
Sauvez les arbres, bouffez des castors !
-
[^]Re: Vérification à faire avec Ubuntu
-
[^]Re: Vérification à faire avec Ubuntu
Posté par Yth (Jabber id, ) le 06/11/2009 à 08:10. (lien). Évalué à 1.Ou qemu avec freedos installé dessus, ça marche très bien !
Yth.-
[^]Re: Vérification à faire avec Ubuntu
Posté par Grunt () le 06/11/2009 à 09:36. (lien). Évalué à 2.Ouais mais je sais pas si t'as suivi, Qemu => vm.mmap_min_addr = 0 => faille.
-
[^]Re: Vérification à faire avec Ubuntu
Posté par Julien Wajsberg () le 06/11/2009 à 10:12. (lien). Évalué à 3.Ben en fait, la dépêche dit le contraire :
"(pouvoir exécuter Qemu en tant qu'utilisateur non root, limitation supprimée dans les versions récentes)"-
[^]Re: Vérification à faire avec Ubuntu
-
-
-
[^]Re: Vérification à faire avec Ubuntu
Posté par Matthieu C () le 06/11/2009 à 21:39. (lien). Évalué à 3.Les versions récentes de dosemu aussi : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=505247#17
-
-
-
-
[^]Re: Vérification à faire avec Ubuntu
Posté par Laurent Bonnaud () le 05/11/2009 à 12:23. (lien). Évalué à 2.Dans le package "officiel" de wine (version 1.0.1-0ubuntu8), c'est ce fichier qui rend le système vulnérable:
/etc/sysctl.d/wine.sysctl.conf
Le fichier mentionné ci-dessus est celui d'un package non officiel, mais plus récent (version 1.1.32~winehq0~ubuntu~9.04-0ubuntu1).
-
[^]Re: Vérification à faire avec Ubuntu
Posté par Laurent Bonnaud () le 06/11/2009 à 16:12. (lien). Évalué à 1.J'ai soumis un rapport de bug concernant le package wine et il devrait être rapidement corrigé:
https://bugs.launchpad.net/ubuntu/+source/wine/+bug/475540
-
-
[^]Re: Vérification à faire avec Ubuntu
-
[^]et la question intéréssante est donc
Posté par SQP () le 05/11/2009 à 19:59. (lien). Évalué à 2.vu que la plupart des jeux de l'époque etaient sous dos, qu'est ce qui reste comme programmes windows 16 bits intéréssant qui pourrait justifier de changer ce paramètre pour tous les utilisateurs de wine (au lieu d'un message disant de modif le flag ou d'installer un paquet qui le fait, et en prévenant du risque pour la sécurité) ?
-
[^]Re: et la question intéréssante est donc
-
-
-
[^]Re: Vérification à faire avec Ubuntu
Posté par Dorian (page perso, ) le 05/11/2009 à 13:04. (lien). Évalué à 4.je suis à 0 chez moi... et j'ai essayé l'exploit : il fonctionne ! (ca essaye même d'envoyer quelque chose par tcp... !)
--
Ne lisez en aucun cas cette signature (et encore moins le message ci-dessus).-
[^]Re: Vérification à faire avec Ubuntu
Posté par Laurent Pointal (page perso, ) le 05/11/2009 à 15:00. (lien). Évalué à 5.T'as pas vu, après avoir compté ta machine dans les exploitées, y'avait un rm -f / dedans.
-
Mais wine marche !
$ cat /proc/sys/vm/mmap_min_addr # Valeur non nulle par défaut (gentoo)
4096
$ wine notepad # wine-1.1.27 fonctionne...
-
[^]Re: Mais wine marche !
Posté par Victor STINNER (Jabber id, page perso, ) le 05/11/2009 à 11:19. (lien). Évalué à 9.Extrait du 2e lien (wiki Debian) : « wine
Only Win16 binaries require the ability to mmap low addresses, Win32 binaries do not. It is recommended that you test your application with the increase mmap_min_addr setting. If the application starts up without issue, then you should not need to remove the mmap_min_addr restriction. »-
[^]Re: Mais wine marche !
Posté par Matthieu C () le 08/11/2009 à 10:32. (lien). Évalué à 3.C'est faux, j'ai pris un vieux jeux win16 (il y en a plein sur les sites abandonware) et ca marche.
Le seul pb, c'est pour les jeux dos utilisant vm86 et des jeux qui font des trucs un peu louche.
Du coup on se demande pourquoi autant de machine n'ont pas un mmap_min_addr non null...
-
Inverse de Ubuntu
Comme Laurent Bonnaud nous le fait remarquer pour Ubuntu, j'ai vérifié sur ma Fedora 11.
Fedora 11 non mise à jour (si !) depuis aout.
La valeur de /proc/sys/vm/mmap_min_addr est non nulle (65536 ici,...)
-> Selinux est activé en mode enforcing. Avec config, et pour un repertoire, à la racine, non standart : /local
Je ne dirai pas que la dépêche se trompe, loi de là :-) (au passage merci Victor pour cette dépêche : concise, précise, complète et agréable), simplement un message pour les autres utilisateurs de Fedora 10 et 11 : vérifiez... chez moi, une F11 non mise à jour, le bug n'existe pas.
-
[^]Re: Inverse de Ubuntu
Posté par tankey () le 05/11/2009 à 12:00. (lien). Évalué à 2.Wine est installé également : wine-core-1.1.29-1.fc11.i586 et sa suite (desktop, jack, twain...) Cette faille est exploitable à cause d'un packaging de wine ?
Donc encore une fois, la qualité Fedora, c'est quelque chose, quant même :-)-
[^]Re: Inverse de Ubuntu
Posté par Victor STINNER (Jabber id, page perso, ) le 05/11/2009 à 14:51. (lien). Évalué à 4.Sur Fedora 11, si on écrit 0 dans mmap_min_addr, l'exploit fonctionne, arrive à contourner SELinux (et aucun avertissement SELinux n'est affiché). En plus, il affiche une image se moquant du modèle de sécurité de SELinux (Discretionary access control vs Mandatory Access Control).
-
[^]Re: Inverse de Ubuntu
Posté par tankey () le 05/11/2009 à 16:47. (lien). Évalué à 3.Il faut donc pouvoir être root au préalable, pour pouvoir remplacer la valeur de la mmap_min_addr, et la placé à zéro. Et ensuite on peux s'amuser avec le nouvel exploit de Brad ?
"hé les gars, j'ai un nouvel exploit pour passer root sous linux : bon d'abord vous devez être root..."
-
-
-
[^]Re: Inverse de Ubuntu
Posté par Victor STINNER (Jabber id, page perso, ) le 05/11/2009 à 12:15. (lien). Évalué à 4.Au sujet de ma phrase « Brad Spengler a écrit un exploit (pouvoir passer root à partir d'un compte utilisateur) fonctionnant sur, au moins, Debian Etch, Fedora (6, 10 et 11), et RedHat (5.3 et 5.4). L'exploit contourne les protections SELinux dans le cas de Fedora 10 et RedHat 5.4. », j'ai utilisé les captures d'écran publiées par Brad (j'ai utilisé le peu d'infos disponibles sur le net). Pour Fedora 11 par exemple : http://grsecurity.net/~spender/fc11.png (mise en ligne le 3 novembre). Peut-être que cette capture d'écran n'est pas liée à l'exploit MooseCox (pipe) ou que c'est une Fedora 11 pas à jour.
Je viens de tester l'exploit sous une Fedora 11 à jour, et 1) l'exploit ne fonctionne 2) beaucoup mieux : SELinux affiche un avertissement comme quoi il y a eu une attaque. Bravo Fedora ! Bravo SELinux ! clap clap clap !
http://www.haypocalc.com/tmp/fedora_enlightenment.png
Brad a publié son exploit
Vous ne pouvez plus ignorer la faille maintenant que l'exploit est public : http://grsecurity.net/~spender/enlightenment.tgz
Lancez "./run_null_exploit.sh", c'est l'exploit « MooseCox: Linux-2.X->Linux.2.6.31.unfixed pipe local root ». L'exploit ne fonctionne pas sur Ubuntu (car mmap_min_addr est non nul), mais fonctionne très bien sur Debian Lenny. J'espère que Debian va se bouger les fesses.
-
[^]Re: Brad a publié son exploit
Posté par Mr Kapouik () le 05/11/2009 à 12:24. (lien). Évalué à 7.Avec des noms d'exploit comme ça on a pas fini de troller sur enlightenment ...
--
Software is like sex: it's better when it's free
-
[^]Re: Brad a publié son exploit
Posté par Mildred (Jabber id, page perso, ) le 05/11/2009 à 12:58. (lien). Évalué à 2.Suer une Fedora 12 (rawhide pour le moment) à jour de ce matin:
./run_null_exploits.sh
Compiling exp_cheddarbay.c...OK.
Compiling exp_ingom0wnar.c...OK.
Compiling exp_moosecox.c...OK.
Compiling exp_paokara.c...OK.
Compiling exp_powerglove.c...OK.
Compiling exp_therebel.c...OK.
Compiling exp_vmware.c...OK.
Compiling exp_wunderbar.c...OK.
[+] Personality set to: PER_SVR4
Pulseaudio is not suid root!
./run_nonnull_exploits.sh
Compiling exp_cheddarbay.c...OK.
Compiling exp_ingom0wnar.c...OK.
Compiling exp_moosecox.c...OK.
Compiling exp_paokara.c...OK.
Compiling exp_powerglove.c...OK.
Compiling exp_therebel.c...OK.
Compiling exp_vmware.c...OK.
Compiling exp_wunderbar.c...OK.
Choose your exploit:
[0] Ingo m0wnar: Linux 2.6.31 perf_counter local root (Ingo backdoor method)
[1] Exit
> 0
------------------------------------------------------------------------------
Before the Law stands a doorkeeper. To this doorkeeper there comes a man
from the country who begs for admittance to the Law. But the doorkeeper
says that he cannot admit the man at the moment. The man, on reflection,
asks if he will be allowed, then, to enter later. 'It is possible,' answers
the doorkeeper, 'but not at this moment.' Since the door leading into the
Law stands open as usual and the doorkeeper steps to one side, the man bends
down to peer through the entrance. When the doorkeeper sees that, he laughs
and says: 'If you are so strongly tempted, try to get in without my
permission. But note that I am powerful. And I am only the lowest
doorkeeper. From hall to hall, keepers stand at every door, one more
powerful than the other. And the sight of the third man is already more
than even I can stand.' These are difficulties which the man from the
country has not expected to meet, the Law, he thinks, should be accessible
to every man and at all times, but when he looks more closely at the
doorkeeper in his furred robe, with his huge, pointed nose and long, thin,
Tartar beard, he decides that he had better wait until he gets permission to
enter. The doorkeeper gives him a stool and lets him sit down at the side
of the door. There he sits waiting for days and years. He makes many
attempts to be allowed in and wearies the doorkeeper with his importunity.
The doorkeeper often engages him in brief conversation, asking him about his
home and about other matters, but the questions are put quite impersonally,
as great men put questions, and always conclude with the statement that the
man cannot be allowed to enter yet. The man, who has equipped himself with
many things for his journey, parts with all he has, however valuable, in the
hope of bribing the doorkeeper. The doorkeeper accepts it all, saying,
however, as he takes each gift: 'I take this only to keep you from feeling
that you have left something undone.' During all these long years the man
watches the doorkeeper almost incessantly. He forgets about the other
doorkeepers, and this one seems to him the only barrier between himself and
the Law. In the first years he curses his evil fate aloud; later, as he
grows old, he only mutters to himself. He grows childish, and since in his
prolonged study of the doorkeeper he has learned to know even the fleas in
his fur collar, he begs the very fleas to help him and to persuade the
doorkeeper to change his mind. Finally his eyes grow dim and he does not
know whether the world is really darkening around him or whether his eyes
are only deceiving him. But in the darkness he can now perceive a radiance
that streams inextinguishably from the door of the Law. Now his life is
drawing to a close. Before he dies, all that he has experienced during the
whole time of his sojourn condenses in his mind into one question, which he
has never yet put to the doorkeeper. He beckons the doorkeeper, since he
can no longer raise his stiffening body. The doorkeeper has to bend far
down to hear him, for the difference in size between them has increased very
much to the man's disadvantage. 'What do you want to know now?' asks the
doorkeeper, 'you are insatiable.' 'Everyone strives to attain the Law,'
answers the man, 'how does it come about, then, that in all these years no
one has come seeking admittance but me?' The doorkeeper perceives that the
man is nearing his end and his hearing is failing, so he bellows in his ear:
'No one but you could gain admittance through this door, since this door was
intended for you. I am now going to shut it.' --Kafka
------------------------------------------------------------------------------
[+] Resolved ima_audit to 0xc0acd58c
[+] Resolved ima_file_mmap to 0xc057da68
[+] Resolved ima_bprm_check to 0xc057da8d
[+] Resolved ima_path_check to 0xc057d742
[+] Resolved selinux_enforcing to 0xc0acb1f8
[+] Resolved selinux_enabled to 0xc097232c
[+] Resolved security_ops to 0xc0aca1cc
[+] Resolved default_security_ops to 0xc0971e4c
[+] Resolved sel_read_enforce to 0xc05714a3
[+] Resolved audit_enabled to 0xc0a6e46c
[+] Resolved commit_creds to 0xc0455765
[+] Resolved prepare_kernel_cred to 0xc04555c6
System is not vulnerable.
-
[^]Re: Brad a publié son exploit
Posté par bilboa () le 05/11/2009 à 15:07. (lien). Évalué à 1.il suffit de trouver un autre exec que pulseaudio...
-
[^]Re: Brad a publié son exploit
Posté par Mildred (Jabber id, page perso, ) le 05/11/2009 à 15:51. (lien). Évalué à 3.En passant, SELinux est désactivé et cat /proc/sys/vm/mmap_min_addr affiche 4096
Maintenant si
$ sudo sh -c 'echo 0 > /proc/sys/vm/mmap_min_addr'
$ cat /proc/sys/vm/mmap_min_addr
0
Et l'exploit fonctionne, avec un joli message qui moque SELinux, et j'ai un shell root.
$ ./run_null_exploits.sh
Compiling exp_cheddarbay.c...OK.
Compiling exp_ingom0wnar.c...OK.
Compiling exp_moosecox.c...OK.
Compiling exp_paokara.c...OK.
Compiling exp_powerglove.c...OK.
Compiling exp_therebel.c...OK.
Compiling exp_vmware.c...OK.
Compiling exp_wunderbar.c...OK.
[+] MAPPED ZERO PAGE!
Choose your exploit:
[0] Cheddar Bay: Linux 2.6.30/2.6.30.1 /dev/net/tun local root
[1] MooseCox: Linux-2.X->Linux.2.6.31.unfixed pipe local root
[2] Paokara: Linux 2.6.19->2.6.31.1 eCryptfs local root
[3] Powerglove: Linux 2.6.31 perf_counter local root
[4] The Rebel: Linux < 2.6.19 udp_sendmsg() local root
[5] CVE-2009-2267: VMWare vm86 guest local root
[6] Wunderbar Emporium: Linux 2.X sendpage() local root
[7] Exit
> 1
------------------------------------------------------------------------------
With people of limited ability modesty is merely honesty. But with those
who possess real talent it is hypocrisy. --Schopenhauer
------------------------------------------------------------------------------
[+] Resolved ima_audit to 0xc0acd58c
[+] Resolved ima_file_mmap to 0xc057da68
[+] Resolved ima_bprm_check to 0xc057da8d
[+] Resolved ima_path_check to 0xc057d742
[+] Resolved selinux_enforcing to 0xc0acb1f8
[+] Resolved selinux_enabled to 0xc097232c
[+] Resolved security_ops to 0xc0aca1cc
[+] Resolved default_security_ops to 0xc0971e4c
[+] Resolved sel_read_enforce to 0xc05714a3
[+] Resolved audit_enabled to 0xc0a6e46c
[+] Resolved commit_creds to 0xc0455765
[+] Resolved prepare_kernel_cred to 0xc04555c6
[+] Using newer pipe_inode_info layout
[+] We'll let this go for a while if needed...
[+] got ring0!
[+] detected cred support
[+] Disabled security of : nothing, what an insecure machine!
[+] Got root!
...
(GConf errors)
...
sh-4.0# id
uid=0(root) gid=0(root)
sh-4.0# exit
Et je ne pense pas que PulseAudio ait grand chose a voir avec cet exploit, il me semble qu'il s'agit d'autre chose.
Maintenant:
$ sudo sh -c 'echo 4096 > /proc/sys/vm/mmap_min_addr'
-
-
[^]Re: Brad a publié son exploit
Posté par Mildred (Jabber id, page perso, ) le 05/11/2009 à 15:52. (lien). Évalué à 2.uname -a:
Linux kylae 2.6.31.5-96.fc12.i686.PAE #1 SMP Fri Oct 23 19:39:36 EDT 2009 i686 i686 i386 GNU/Linux
-
-
[^]Debian : ça, c'est fait
Posté par Tanguy Ortolo (Jabber id, page perso, ) le 05/11/2009 à 18:20. (lien). Évalué à 2.L'équipe de sécurité Debian vient de publier une nouvelle version du noyau, je crois.
linux-2.6 (2.6.26-19lenny2) stable-security; urgency=high
* tc: Fix uninitialized kernel memory leak (CVE-2009-3228)
* random: make get_random_int() more random (CVE-2009-3238)
* netlink: fix typo in initialization (CVE-2009-3612)
* drm/r128: Add test for initialisation to all ioctls that require it
(CVE-2009-3620)
* AF_UNIX: Fix deadlock on connecting to shutdown socket (CVE-2009-3621)
* fs: pipe.c null pointer dereference (CVE-2009-3547)
* KVM: Prevent overflow in KVM_GET_SUPPORTED_CPUID (CVE-2009-3638)
-
[^]DSA 1927-1: New Linux 2.6.26 packages fix several vulnerabilities
Posté par Victor STINNER (Jabber id, page perso, ) le 05/11/2009 à 18:30. (lien). Évalué à 3.CVE-2009-3547
Earl Chew discovered a NULL pointer dereference issue in the
pipe_rdwr_open function which can be used by local users to gain
elevated privileges.
http://lists.debian.org/debian-security-announce/2009/msg002(...)
Le noyau ne corrige que la faille pipe. Par contre, mmap_min_addr est inchangé. Ça ne sera changé que dans Debian 5.0.4.-
[^]Re: DSA 1927-1: New Linux 2.6.26 packages fix several vulnerabilities
Posté par THR4K (page perso, ) le 06/11/2009 à 08:51. (lien). Évalué à 2.Petite précision : dans Lenny, cela n'est vrai que pour les images de noyau précompilées fournies par Debian (actuellement 2.6.26+17+lenny1).
Ceux qui, comme moi, compilent leurs propres version locales à partir des sources patchées par Debian, se seront peut-être rendu compte que la valeur mmap_min_addr est initialisé par défaut à 4096 depuis linux-source-2.6.26-19lenny1.
Cette fois, même les mauvaises langues ne pourront pas dire que compiler le noyau c'est inutile/dépassé/etc. :-p--
THRAK (def.) :1) A sudden and precise impact moving from intention and commitment, in service of an aim. 2) 117 guitars almost hitting the same chord simultaneously.-
[^]Re: DSA 1927-1: New Linux 2.6.26 packages fix several vulnerabilities
Posté par Victor STINNER (Jabber id, page perso, ) le 06/11/2009 à 12:37. (lien). Évalué à 2.Euh, un simple dist-upgrade t'aurait installé le nouveau noyau précompilé. C'est l'objet du dernier bulletin de sécurité Debian :
http://www.debian.org/security/2009/dsa-1927
« For the stable distribution (lenny), this problem has been fixed in version 2.6.26-19lenny2. »
Tu es tombé au moment où les sources du nouveau noyau étaient en ligne, mais pas encore les paquets binaires (le temps qu'ils soient compilés, puis copiés sur tous les miroirs).-
[^]Re: DSA 1927-1: New Linux 2.6.26 packages fix several vulnerabilities
Posté par THR4K (page perso, ) le 09/11/2009 à 16:45. (lien). Évalué à 2.Oui mais non.
D'abord, je n'utilise pas, en temps normal, les noyaux précompilés par Debian ; ensuite, comme je le précisais dans mon commentaire précédent, la faille a été fixée depuis la publication des sources patchées en 2.6.26-19lenny1.
Soit, d'après le changelog Debian:
linux-2.6 (2.6.26-19lenny1) stable-security; urgency=high
[...]
* selinux: prevent local users from bypassing mmap_min_addr
in unconfined domains (CVE-2009-2695)
[...]
-- dann frazier <dannf@debian.org> Sat, 17 Oct 2009 10:52:13 -0600
En vue de corriger le problème ci-dessus, la valeur mmap_min_addr a depuis été fixée à 4096 par défaut. En d'autres termes, cela implique que les personnes ayant compilé leur propre noyau à partir de cette version des sources (depuis le 20 octobre environ) ne sont pas impactés par la présente faille, même s'ils n'ont pas mis à jour leur système récemment ; voilà.--
THRAK (def.) :1) A sudden and precise impact moving from intention and commitment, in service of an aim. 2) 117 guitars almost hitting the same chord simultaneously.
-
-
-
-
-
[^]Re: Brad a publié son exploit
Posté par bradley_vier () le 05/11/2009 à 20:00. (lien). Évalué à 2.La parade pour Debian est sur le wiki : [http://wiki.debian.org/mmap_min_addr]
En résumé :
# echo "vm.mmap_min_addr = 4096" > /etc/sysctl.d/mmap_min_addr.conf
# /etc/init.d/procps restart
Les pauvres qui ont un blob binaire (genre Nvidia)
il fait partie de la version 2.6.32-rc6
Vu que pour les anciennes cartes il n'existe pas de drivers pour ces noyaux, et que pour les cartes plus récentes il faut attendre (pour le moment, c'est bloqué à 2.6.29), cela démontre encore une fois que l'utilisation de drivers fermés est un problème.
Sinon, dans le cas d'un serveur virtuel (sans X11) sous OpenVZ, comment ça se passe, vu qu'il n'y a pas de root dans ces machines virtuelles?
A bientôt
Grégoire
-
[+] [^]Re: Les pauvres qui ont un blob binaire (genre Nvidia)
Posté par mat3o () le 05/11/2009 à 13:57. (lien). Évalué à -10.Et moi je plains les pauvres qui utilisent des drivers open source fini au pipi qui ont la bonté de planter le système pile au moment ou il faut pas ...
-
[^]Re: Les pauvres qui ont un blob binaire (genre Nvidia)
Posté par Misc (page perso, ) le 05/11/2009 à 14:24. (lien). Évalué à 6.Dieu merci, il y a pas tant de gens qui arrivent à finir des drivers avec leur urine, et donc tu ne doit pas plaindre grande monde, car pour la plupart des pilotes libres, ils sont fini avec un éditeur de texte et de gcc ( sauf Jean Alesi ).
Au passage, tu semble affirmer qu'il y a des moment ou il ne faut pas planter. Est ce que tu veux dire qu'il y a des moments ou il faut planter ?-
[^]Re: Les pauvres qui ont un blob binaire (genre Nvidia)
Posté par Grunt () le 05/11/2009 à 14:35. (lien). Évalué à 3.ils sont fini avec un éditeur de texte et de gcc
Note qu'on pourrait très bien coder avec de l'urine:
http://www.snowgo.com/images/yellowsnow.jpg
Par contre ça risque d'augmenter (si c'est possible) la consommation de bière des libristes. Et il faudra doter gcc d'un module d'OCR.
-
[^]Re: Les pauvres qui ont un blob binaire (genre Nvidia)
Posté par Guillaume (Jabber id, page perso, ) le 05/11/2009 à 15:06. (lien). Évalué à 3.Est ce que tu veux dire qu'il y a des moments ou il faut planter ?
Oui, des moments comme celui-ci : http://www.youtube.com/watch?v=TrAD25V7ll8
Au vu des applaudissements, il semble que c'était le bon moment, exactement comme dans les sitcoms américaines :-)--
Un bon écolo est un écolo mort ! Bah oui, il ne rejette plus de CO2 et en plus il fait engrais naturel...
-
-
Exploitabilité *réelle*
J'ai un peu du mal à capter la dangerosité de la faille. En particulier du fait que le bug permette une escalade de droits à partir d'un compte utilisateur normal.
Ainsi, par exemple, je ne me soucie pas trop de cette faille sur ma machine personelle. Je suis le seul à avoir un accès. D'autre part, si on parle d'accès distant sur un serveur, alors il y a de grandes chances que WINE et consors soient complètement hors-jeu, donc l'administrateur a juste à positionner le flag qui va bien, et je suis sur que c'est deja probablement le cas..
Pour finir, je rejoins totalement la position de Linus dans ce message:
http://article.gmane.org/gmane.linux.kernel/706950
one reason I refuse to bother with the whole security circus is that I think it glorifies - and thus encourages - the wrong behavior.
It makes "heroes" out of security people, as if the people who don't just fix normal bugs aren't as important.
In fact, all the boring normal bugs are _way_ more important, just because there's a lot more of them. I don't think some spectacular security hole should be glorified or cared about as being any more "special" than a random spectacular crash due to bad locking.
-
[^]Re: Exploitabilité *réelle*
Posté par Laurent Cligny (page perso, ) le 05/11/2009 à 18:52. (lien). Évalué à 7.l'administrateur a juste à positionner le flag qui va bien, et je suis sur que c'est deja probablement le cas
Et bien justement, vu le nombre d'"admins" qui ne suivent pas les failles des softs utilisés en production dans leur parc et se contentent d'appliquer les mises à jours quand elles sont dispo (et encore certains ne font même pas ça), la faille a des chances d'être exploitée tant que le noyau et les distribs ne sont pas patchés, via un exploit sur un soft tiers ne donnant à la base accès qu'à un compte non root.
-
[^]Re: Exploitabilité *réelle*
Posté par Grunt () le 05/11/2009 à 22:31. (lien). Évalué à 6.J'ai un peu du mal à capter la dangerosité de la faille. En particulier du fait que le bug permette une escalade de droits à partir d'un compte utilisateur normal.
Ainsi, par exemple, je ne me soucie pas trop de cette faille sur ma machine personelle. Je suis le seul à avoir un accès. D'autre part, si on parle d'accès distant sur un serveur, alors il y a de grandes chances que WINE et consors soient complètement hors-jeu, donc l'administrateur a juste à positionner le flag qui va bien, et je suis sur que c'est deja probablement le cas..
Ben je vais te donner un exemple tout con qui m'est réellement arrivé.
J'avais un PC de bureau, sous Debian. Il ne servait rien sur Internet, n'était utilisable physiquement que par des gens de confiance et des noobs. J'avais créé dessus un compte "invite" avec comme mot de passe "invite", pour les gens de passage.
Et puis je déménage, je prends une connexion @Internet. Ah, zut, je n'ai pas de serveur sous la main (j'aime bien avoir un serveur chez moi). Bon ben pas grave, je récupère mon vieux Desktop, c'est cool il a deux cartes réseau, j'en fais une passerelle, avec NAT, iptables et tout ça. Je configure iptables comme il faut, en laissant juste le port 22 ouvert (en fait je laisse un screen + irssi dedans, c'est ma principale utilisation pour l'instant d'un "serveur").
Bon, certes, je n'ai pas viré le compte "invite/invite", mais je fais toujours gaffe à avoir un mot de passe, et perso, et root, qui soient solides, question de principe. Bon.
Ben ce qui devait arriver m'est arrivé: bruteforce, et quelqu'un est entré sur le compte "invite".
Tu me diras, "ouais ben j'avais qu'à pas faire de la merde", et j'admets avoir fait de la merde. Je le dis tout haut: J'ai merdé!
Bon, pour la petite histoire, le gars n'a pas réussi à passer root: coup de bol, je n'utilise pas pulseaudio, et ça date d'avant la publication de cette faille (à quelques jours prêts, j'ai eu chaud).
Ceci dit, un OS sur lequel n'importe quel utilisateur lambda peut passer root, ben heu..
Moralité: je vais passer mes serveurs à BSD, _et_ apprendre à administrer correctement mes machines. Deux sécurités valent mieux que zéro.-
[+] [^]Re: Exploitabilité *réelle*
Posté par Romain Be. () le 05/11/2009 à 23:34. (lien). Évalué à -2.Merci pour l'histoire :-)
Ceci dit, sans nier que cela ait pu t'embêter, les failles dites de sécurité sont prétendument critiques à cause des risques majeurs, entendre financiers, qu'elle peuvent faire courir.
On lit souvent, dans la réponse au mail de Linus que j'ai cité, que les faille de sécurité sont la porte ouverte au *vol de centaines de cartes bleues* et autres conséquences exagérées.
Ici, je ne vois pas vraiment en quoi la faille est si problématique. D'ailleurs, en rêgle générale, les failles d'escalade de droits à partir d'un compte local me semblent toujours des failles secondaires, les principales étant celles qui permettent d'avoir un shell à partir d'une application distante...
Tout ça pour dire que le rush style « ouah encore une faille dans linux » et les « héros » de la sécurité style Brad Spengler, perso j'adhère pas, et je me sens plus proche de ce que dit Linus sur le sujet...-
[^]Re: Exploitabilité *réelle*
Posté par Grunt () le 06/11/2009 à 00:08. (lien). Évalué à 4.On lit souvent, dans la réponse au mail de Linus que j'ai cité, que les faille de sécurité sont la porte ouverte au *vol de centaines de cartes bleues* et autres conséquences exagérées.
Ben, tu m'excuseras, mais si sur le serveur qui gère les numéros de carte bleues, y'a un technicien, ou un développeur, qui a un compte, et qu'il y a une faille qui permet de passer root, il peut effectivement "voler des centaines de cartes bleues". S'il y a une séparation des droits sur un OS c'est pas pour rien, et ce n'est pas juste pour empêcher qu'une fausse manip ne casse tout.-
[+] [^]Re: Exploitabilité *réelle*
Posté par Romain Be. () le 06/11/2009 à 00:26. (lien). Évalué à -1.Mouais... D'expérience, les faille qui permettent de passer root n'ont souvent rien à voir là dedans. De base le technicien ou le développeur a accès à la base de données client en clair, et on parle plus d'un employé mal intentionné que d'une faille de sécurité..
Enfin, si il y a une faille de sécurité, mais je crois pas qu'elle se situe dans le noyau linux dans ce cas-là :-)
-
[^]Re: Exploitabilité *réelle*
Posté par d-jo (page perso, ) le 06/11/2009 à 08:34. (lien). Évalué à 4.>y'a un technicien, ou un développeur, qui a un compte,
Ou une faille dans le code d'un site. Tu uploade l'exploit, tu ouvre un shell avec la fonction exec de n'importe quel langage de script, tu passe root et voilà.
Si le type est pas trop con, il peut se balader pendant des jours, piquer des infos, installer des backdoors des phishings, balancer du spam et même s'il a de la chance récupérer des screens, des clés sans passphrases (genre pour les backup) et compromettre tout ton parc
-
-
-
[^]Re: Exploitabilité *réelle*
Posté par Yth (Jabber id, ) le 06/11/2009 à 08:36. (lien). Évalué à 1.Erf, j'ai fait à peu près la même avec un compte de test www/www.
Le « serveur » à l'époque (~2004) était un vieux 486.
Le type est passé root et a essayé d'installer un ircbot, et tout.
La charge était tellement énorme pour une si petite machine, qu'il l'a juste mise à genoux, j'ai repéré tout de suite qu'il y avait un problème (plus d'accès internet... plus d'accès au routeur, ah !), débranché le câble et réglé le problème en direct.
Depuis, plus rien, plus personne ne passe...
Yth.
-
[^]Re: Exploitabilité *réelle*
Posté par Laurent Cligny (page perso, ) le 06/11/2009 à 13:43. (lien). Évalué à 4.+1 pour le servuer sous BSD. Mais ça ne te protègera pas d'erruers humaines, et les BSD, comme tout logiciels ne sont pas exempts de failles. Mais tout ça tu le savais déjà.
Faits juste attention, une fois qu'on à goûté à BSD on ne peut plus s'en passer ;)-
[^]Re: Exploitabilité *réelle*
Posté par Grunt () le 06/11/2009 à 14:40. (lien). Évalué à 1.Faits juste attention, une fois qu'on à goûté à BSD on ne peut plus s'en passer ;)
C'est principalement ce genre de remarques qui me fait envie de tester, justement..
D'abord on utilise un truc, on trouve que c'est bien, puis on découvre quelque chose qui est carrément mieux mais différent à prendre en main, au début on galère puis quand on s'y est fait, on se demande "Mais comment j'ai pu utiliser un truc aussi moisi avant?" et on n'a plus aucune envie de revenir en arrière.
C'est l'impression que donne une migration Windows => GNU/Linux, et j'attends la même chose d'un passage de GNU/Linux à BSD ;+)
-
-
[^]Re: Exploitabilité *réelle*
Posté par Cereal Killer (Jabber id, ) le 08/11/2009 à 13:48. (lien). Évalué à 2.Sinon dans man sshd_config, on découvre un paramètre très utile pour ce genre d'erreur : AllowUsers ... pis tant que tu y es, tu peux aussi rajouter PermitRootLogin no.
C'est aussi valable sous *BSD ;)
Sans être un maniaque de la sécurité, il y a quelques règles très simple à mettre en place sur tout linux fraîchement installé :
- limité le nombre de services réseaux (ou pas) au maximum.
- sécurisé un minimum ces points d'entrées.
Après, utiliser/configurer iptables aux petits oignons sur un desktop, c'est plus un luxe que vraiment utile amha.-
[^]Re: Exploitabilité *réelle*
Posté par Tanguy Ortolo (Jabber id, page perso, ) le 09/11/2009 à 07:17. (lien). Évalué à 2.Tu as aussi AllowGroups, et le module PAM access_if, également utilisable pour cela.
-
-
-
[^]Re: Exploitabilité *réelle*
Posté par Alek_Lyon () le 06/11/2009 à 10:11. (lien). Évalué à 5.Un exemple qui me vient en tête : à l'université. J'imagine que si les élèves peuvent avoir un accès root rien qu'en lançant un shell-script, ça craint...
Je sais que moi, si j'avais eu connaissance d'une telle faille il y a quelques années, il y aurait eu petit diable sur mon épaule droite pour me dire : Alleeeer, tente l'exploit, juste pour voir si les admins font bien leur boulot c'est tout. ;-)
Surtout que dans mon cas (mais j'imagine que c'est courant), on pouvait se connecter à n'importe quel compte à partir de n'importe où et accéder à toutes les données, vu que les utilisateurs et les données étaient partagées (NFS, etc.). On pouvait déjà dénicher des informations assez intéressantes grâce aux droits mal réglés de certains étourdis, mais si en plus on peut les modifier...
Alek.-
[^]Re: Exploitabilité *réelle*
Posté par Grunt () le 06/11/2009 à 11:34. (lien). Évalué à 6.Me fait penser à la réaction idiote d'un pote geek qui avait un serveur dédié..
il était root dessus (normal, c'est lui qui payait le dédié) et il y avait plusieurs comptes utilisateurs.
En apprenant l'existence d'une faille du noyau Linux qui permettait de passer root depuis un compte utilisateur, je lui en cause..
Il me fait "Ah mais attends c'est une faille locale??"
Moi: "Ben oui. Les utilisateurs locaux peuvent devenir root."
Lui: "Ah ben ça risque rien alors, y'a personne en local sur le serveur, on y accède à distance via SSH..."
Bon, il s'est vite rendu compte de son erreur.
-
[^]Re: Exploitabilité *réelle*
Posté par viking1404 () le 06/11/2009 à 12:19. (lien). Évalué à 2.Dans mon université l'expoit fonctionne, et oui je peux avoir un accès root à toutes les données de la fac.
Je n'ai pas envie de faire mon salaud mais, j'avoue que c'est assez tentant.
En fait je me pose plutôt la question : est-ce que j'envoie un mail aux admins. du parc pour leurs faire comprendre qu'ils sont incompétent ?
Affaire à suivre ^^-
[^]Re: Exploitabilité *réelle*
Posté par Guillaume (Jabber id, page perso, ) le 06/11/2009 à 12:46. (lien). Évalué à 2.J'ai une autre idée : comme tu as fait tes preuves, tu proposes d'intégrer l'équipe d'admin pour sécuriser tout ça. Rémunéré, bien sûr ;-)
--
Un bon écolo est un écolo mort ! Bah oui, il ne rejette plus de CO2 et en plus il fait engrais naturel...-
[^]Re: Exploitabilité *réelle*
-
-
[^]Re: Exploitabilité *réelle*
-
[^]Re: Exploitabilité *réelle*
Posté par nono14 (page perso, ) le 06/11/2009 à 13:19. (lien). Évalué à 2.Attention, si tu enfreins la charte informatique...
--
solutions / support / formation open source
-
[^]Re: Exploitabilité *réelle*
Posté par Alek_Lyon () le 06/11/2009 à 13:33. (lien). Évalué à 3.Il faut bien connaître les admins... Parce qu'aller dire que tu as commis un acte illégal (s'introduire dans un système, même sans rien faire d'autre, est illégal il me semble), c'est un peu te jeter dans la gueule du loup si jamais ils ne sont pas très ouverts... Et même s'ils le sont et qu'ils comprennent bien ta démarche, peuvent-ils garder une telle intrusion secrète sans que ce soit une faute de leur part ? Ne doivent-ils pas vérifier et faire vérifier par précaution que tu n'as vraiment rien fais ?
Mhh déjà je serais toi j'effacerais bien toute trace car si des admins d'université trainent dans le coin, nul doute qu'ils vont faire un petit find . -name enlightenment.tgz pour te trouver. ;-)
Alek.
-
[^]Re: Exploitabilité *réelle*
Posté par Laurent Cligny (page perso, ) le 06/11/2009 à 13:55. (lien). Évalué à 3.Tu leur envoie un mail, sans leur dire qu'ils sont incompétants (ça a beaucoup de fierté un admin, et beaucoup de pouvoir de nuisance aussi), leur parlant de la faille, avec des liens vers les "advisories" et pourquoi pas vers ce journal, ainsi il verrons que l'exploit fonctionne très bien. et tu leur demande juste si les machines de l'université ont bien été protégées contre ce problème.
Ils te diront certainement que oui ;), et feront le tour des serveurs pour appliquer le workaround en attendant les mises à jours officielles du noyau et des distribs.
-
[^]Re: Exploitabilité *réelle*
Posté par SQP () le 06/11/2009 à 14:54. (lien). Évalué à 3.j'enverrais un mail sans rien chercher à minimiser :
si tu as vraiment testé la faille par curiosité et que tu n'as rien à te reprocher, il vaut mieux les prévenir carrément que la faille est exploitable en l'état, avec un peu de liens d'info et le patch, et qu'ils feraient mieux de faire vite
un bon admin te remerciera, un mauvais t'engueulera parce que c'est vendredi après midi-
[^]Re: Exploitabilité *réelle*
Posté par Sylvain Sauvage () le 06/11/2009 à 15:29. (lien). Évalué à 9.un mauvais t'engueulera parce que c'est vendredi après midi
Mais non, car c’est justement le vendredi après-midi, juste avant de partir en week-end de trois jours, ou carrément en vacances, que le mauvais admin décide de modifier toute la configuration des serveurs, directement en production, sans test, pour tout foutre en l’air et pouvoir demander une augmentation à son retour vu que, quand il est absent, il n’y a plus rien qui marche…
-
[^]Re: Exploitabilité *réelle*
-
-
-
-
[^]Re: Exploitabilité *réelle*
Posté par Victor STINNER (Jabber id, page perso, ) le 06/11/2009 à 12:52. (lien). Évalué à 6.Ainsi, par exemple, je ne me soucie pas trop de cette faille sur ma machine personelle. Je suis le seul à avoir un accès.
Sais-tu que les navigateurs web sont devenus le principal point d'entrée des malwares ? Les failles (HTML, Javascript, Flash, etc.) sont très courantes. Si un pirate arrive à exécuter du code dans ton navigateur web, c'est comme si c'était un utilisateur local. Avec ça, il peut déjà voir tes photos de vacances, lire tes mails, sniffer tous tes mots de passe, récupérer tes clés SSH/GPG, etc. C'est déjà pas mal.
Maintenant, en utilisant un exploit pour passer root, il peut modifier le système, très utile pour la furtivité (supprimer quelques lignes compromettantes dans des fichiers de log, compiler et charger un module noyau à la volée, remplacer tes programmes par des versions piratées, etc.). Ça permet également de mettre en place un serveur web, FTP et/ou ssh : un utilisateur ne peut pas écouter sur les ports TCP inférieurs à 1024 (bien qu'on puisse très bien utiliser des ports non standards, mais c'est moins furtif, après ça dépend des usages).
Bien sûr, le navigateur n'est pas le seul vecteur d'entrée. N'importe quel support amovible (clé USB, disque dur externe, CD/DVD) et tout ce qui vient d'Internet (web, mail, photos, paquets, etc.) peut servir pour infecter ta machine.
Aujourd'hui, le plus grand fléau sont les botnets qui servent à envoyer du spam : des troyans s'installent sur des postes Windows. Des postes de travail, pas des serveurs, car justement le but est d'avoir le botnet le plus gros possible, donc infecter le maximum d'ordinateurs.
Je n'essaye pas de te rendre parano, juste de t'expliquer les risques ;-) C'était pour dire que même si tu n'as aucun port en écoute, tu n'es pas protégé pour autant.
s/RedHat/Red Hat Enterprise Linux/g
http://www.redhat.com/f/pdf/corp/trademark_usage.pdf
Vous pouvez aussi gagner du karma en dénonçant le fait que ce PDF a été généré avec des outils propriétaires.
Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
Cette page a été générée par Templeet en 0.2502s (dont 0.0174 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.
Faire un don !
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.