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. Les fonctions pipe_read_open(), pipe_write_open() et pipe_rdwr_open() ont été introduites dans la version 1.3.44 du noyau Linux (novembre 1995). Un verrou a été ajouté dans la version 2.3.15 (août 1999). Sa découverte est sûrement due à la popularisation des processeurs multi-cœurs (exécution de plusieurs processus réellement parallèle, augmentant la probabilité des situations de compétition), et on peut craindre que d'autres bugs similaires soient découverts (bugs difficiles à identifier manuellement et à reproduire). Consultez l'article CVE-2009-3547: Linux kernel Pipe NULL Pointer Dereference Race Condition pour des explications sur la faille.
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
Posté par Laurent Cligny (site web personnel) . Évalué à 10.
[^] # Re: Rien à voir mais
Posté par lejocelyn (site web personnel) . Évalué à 10.
[^] # Re: Rien à voir mais
Posté par Raphaël Berbain . Évalué à 10.
Ç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 (site web personnel) . Évalué à 10.
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 mickabouille . Évalué à 1.
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
Posté par Vroum . Évalué à 1.
[^] # Re: Rien à voir mais
Posté par Mr Kapouik (site web personnel) . Évalué à 2.
# encore et toujours la meme faille (ou presque)
Posté par NeoX . Évalué à 2.
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 )
[^] # Re: encore et toujours la meme faille (ou presque)
Posté par Victor STINNER (site web personnel) . Évalué à 2.
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 . Évalué à 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
"L'art est fait pour troubler. La science rassure" (Braque)
[^] # Re: encore et toujours la meme faille (ou presque)
Posté par Mildred (site web personnel) . Évalué à 2.
[^] # Re: encore et toujours la meme faille (ou presque)
Posté par maderios . Évalué à -1.
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.
"L'art est fait pour troubler. La science rassure" (Braque)
# Vérification à faire avec Ubuntu
Posté par Laurent Bonnaud . Évalué à 2.
$ 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 . Évalué à 10.
0 == 65536THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Vérification à faire avec Ubuntu
Posté par Laurent Bonnaud . Évalué à 4.
[^] # Re: Vérification à faire avec Ubuntu
Posté par Misc (site web personnel) . Évalué à 10.
[^] # Re: Vérification à faire avec Ubuntu
Posté par Laurent Bonnaud . Évalué à 10.
$ 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
Posté par Grunt . Évalué à 10.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Vérification à faire avec Ubuntu
Posté par Obsidian . Évalué à 1.
[^] # Re: Vérification à faire avec Ubuntu
Posté par Fopossum . Évalué à 5.
Mes deux ¢ :)
cd /pub && more beer
[^] # Re: Vérification à faire avec Ubuntu
Posté par Grunt . Évalué à 3.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Vérification à faire avec Ubuntu
Posté par Yth (Mastodon) . Évalué à 1.
Yth.
[^] # Re: Vérification à faire avec Ubuntu
Posté par Grunt . Évalué à 2.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Vérification à faire avec Ubuntu
Posté par Julien Wajsberg . Évalué à 3.
"(pouvoir exécuter Qemu en tant qu'utilisateur non root, limitation supprimée dans les versions récentes)"
[^] # Re: Vérification à faire avec Ubuntu
Posté par Yth (Mastodon) . Évalué à 3.
Yth.
[^] # Re: Vérification à faire avec Ubuntu
Posté par M . Évalué à 3.
[^] # Re: Vérification à faire avec Ubuntu
Posté par Laurent Bonnaud . Évalué à 2.
/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 . Évalué à 1.
https://bugs.launchpad.net/ubuntu/+source/wine/+bug/475540
[^] # Re: Vérification à faire avec Ubuntu
Posté par oliwek . Évalué à 1.
[^] # et la question intéréssante est donc
Posté par SQP . Évalué à 2.
[^] # Re: et la question intéréssante est donc
Posté par KiKouN . Évalué à 1.
[^] # Re: Vérification à faire avec Ubuntu
Posté par Dorian . Évalué à 4.
« En fait, le monde du libre, c’est souvent un peu comme le parti socialiste en France » Troll
[^] # Re: Vérification à faire avec Ubuntu
Posté par lolop (site web personnel) . Évalué à 5.
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# Mais wine marche !
Posté par JGO . Évalué à 1.
4096
$ wine notepad # wine-1.1.27 fonctionne...
[^] # Re: Mais wine marche !
Posté par Victor STINNER (site web personnel) . Évalué à 9.
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 M . Évalué à 3.
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
Posté par bubar🦥 (Mastodon) . Évalué à 3.
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 bubar🦥 (Mastodon) . Évalué à 2.
Donc encore une fois, la qualité Fedora, c'est quelque chose, quant même :-)
[^] # Re: Inverse de Ubuntu
Posté par Victor STINNER (site web personnel) . Évalué à 4.
[^] # Re: Inverse de Ubuntu
Posté par bubar🦥 (Mastodon) . Évalué à 3.
"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 (site web personnel) . Évalué à 4.
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
Posté par Victor STINNER (site web personnel) . Évalué à 9.
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 (site web personnel) . Évalué à 7.
[^] # Re: Brad a publié son exploit
Posté par Mildred (site web personnel) . Évalué à 2.
./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 . Évalué à 1.
[^] # Re: Brad a publié son exploit
Posté par Mildred (site web personnel) . Évalué à 3.
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 JGO . Évalué à 2.
sudo sh -c 'echo 4096 > /proc/sys/vm/mmap_min_addr'
Et hop la machine est protégée (on peut le mettre dans un script de démarrage).
[^] # Re: Brad a publié son exploit
Posté par geb . Évalué à 4.
echo "vm.mmap_min_addr=4096>>/etc/sysctl.conf" && sysctl -p # le sysctl -p est refait à chaque démarrage.
ou via /etc/sysctl.d/.
[^] # Re: Brad a publié son exploit
Posté par Mildred (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 2.
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 (site web personnel) . Évalué à 3.
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 . Évalué à 2.
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, direction and commitment, in service of an aim. 2) 117 guitars almost striking the same chord simultaneously.
[^] # Re: DSA 1927-1: New Linux 2.6.26 packages fix several vulnerabilities
Posté par Victor STINNER (site web personnel) . Évalué à 2.
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 . Évalué à 2.
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, direction and commitment, in service of an aim. 2) 117 guitars almost striking the same chord simultaneously.
[^] # Re: Brad a publié son exploit
Posté par bradley_vier . Évalué à 2.
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)
Posté par GG (site web personnel) . Évalué à 3.
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
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
[^] # Re: Les pauvres qui ont un blob binaire (genre Nvidia)
Posté par mat3o . Évalué à -10.
[^] # Re: Les pauvres qui ont un blob binaire (genre Nvidia)
Posté par Misc (site web personnel) . Évalué à 6.
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 . Évalué à 3.
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.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Les pauvres qui ont un blob binaire (genre Nvidia)
Posté par zebra3 . Évalué à 3.
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 :-)
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
# Rien sous ArchLinux ?
Posté par sam101 . Évalué à 1.
# Debian Squeeze pas touché
Posté par gpe . Évalué à 4.
# Exploitabilité *réelle*
Posté par Romain Be. . Évalué à 1.
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 (site web personnel) . Évalué à 7.
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 . É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. 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.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Exploitabilité *réelle*
Posté par Romain Be. . Évalué à -2.
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 . Évalué à 4.
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.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Exploitabilité *réelle*
Posté par Romain Be. . Évalué à -1.
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 Joris Dedieu (site web personnel) . Évalué à 4.
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 (Mastodon) . Évalué à 1.
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 (site web personnel) . Évalué à 4.
Faits juste attention, une fois qu'on à goûté à BSD on ne peut plus s'en passer ;)
[^] # Re: Exploitabilité *réelle*
Posté par Grunt . Évalué à 1.
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 ;+)
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Exploitabilité *réelle*
Posté par Cereal Killer . Évalué à 2.
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 (site web personnel) . Évalué à 2.
[^] # Re: Exploitabilité *réelle*
Posté par Alek_Lyon . Évalué à 5.
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 . Évalué à 6.
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.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Exploitabilité *réelle*
Posté par viking1404 . Évalué à 2.
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 zebra3 . Évalué à 2.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Exploitabilité *réelle*
Posté par Antoine . Évalué à 3.
[^] # Re: Exploitabilité *réelle*
Posté par Grunt . Évalué à 3.
THIS IS JUST A PLACEHOLDER. YOU SHOULD NEVER SEE THIS STRING.
[^] # Re: Exploitabilité *réelle*
Posté par nono14 (site web personnel) . Évalué à 2.
Système - Réseau - Sécurité Open Source - Ouvert à de nouvelles opportunités
[^] # Re: Exploitabilité *réelle*
Posté par Alek_Lyon . Évalué à 3.
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 (site web personnel) . Évalué à 3.
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 . Évalué à 3.
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 . Évalué à 9.
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*
Posté par KiKouN . Évalué à 1.
[^] # Re: Exploitabilité *réelle*
Posté par Victor STINNER (site web personnel) . Évalué à 6.
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
Posté par Krunch (site web personnel) . Évalué à 1.
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.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.