Depuis quelque jours, la nouvelle est tombé dans toute les oreilles: un bug dans vmsplice permet d'élever ses privilèges de simple mortel à Dieu tout puissant.
Le code malfaisant est comme d'habitude sur milw0rm ici => http://www.milw0rm.com/exploits/5092 et là => http://www.milw0rm.com/exploits/5093
Heureusement un patch on-the-fly du kernel est possible: => http://www.ping.uio.no/~mortehu/disable-vmsplice-if-exploita(...)
Le kernel est déjà patché et les distributions devraient incessament sous peu distribué de nouveaux kernel patchés.
http://it.slashdot.org/it/08/02/10/2011257.shtml
----
NdM : Victor Stinner rajoute
Deux exploits root locaux circulent sur Internet : Linux Kernel 2.6.17 - 2.6.24.1 vmsplice Local Root Exploit et Linux Kernel 2.6.23 - 2.6.24 vmsplice Local Root Exploit.
Ils exploitent un bug dans l'appel système vmsplice(). Le noyau 2.6.24.1 corrige partiellement le bug et la version 2.6.24.2 semble le corriger définitivement.
Plus d'informations :
* LKML: "Niki Denev": kernel 2.6.24.1 still vulnerable to the vmsplice local root exploit
* Gentoo : Gentoo Bug 209460 - kernel 2.6.17 - 2.6.24.1 splice: missing user pointer access verification (CVE-2008-{0009,0010})
* Ubuntu : Bug #190587 in linux (Ubuntu): “Local root exploit in kernel 2.6.17 - 2.6.24 (vmsplice)”
* Debian : #464953 - linux-2.6: mmap() local root exploit - Debian Bug report logs
Les patchs dans le noyau : splice: fix user pointer access in get_iovec_page_array() (2.6.24.2) et splice: missing user pointer access verification (CVE-2008-0009/10) (2.6.24.1).
Identifiants CVE : CVE-2008-0009 et CVE-2008-0010.
# Commentaire supprimé
Posté par Victor STINNER (site web personnel) . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Victor STINNER (site web personnel) . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Bruce Le Nain (site web personnel) . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Amaury . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par chl (site web personnel) . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par chl (site web personnel) . Évalué à -1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par inico (site web personnel) . Évalué à 0.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Rah, j'étais en train d'écrire un journal
Posté par paul . Évalué à 10.
En plus, en faisant "répondre" à un message, on voit son contenu :p
[^] # Re: Rah, j'étais en train d'écrire un journal
Posté par IsNotGood . Évalué à 2.
> C'est ni inapproprié ni illégal :)
Ben alors ?
# Au sujet de disable-vmsplice-if-exploitable.c
Posté par Victor STINNER (site web personnel) . Évalué à 5.
[^] # Re: Au sujet de disable-vmsplice-if-exploitable.c
Posté par inico (site web personnel) . Évalué à 2.
Les deux exploit echouent tout le temps.
[^] # Re: Au sujet de disable-vmsplice-if-exploitable.c
Posté par anakin . Évalué à 2.
[^] # Re: Au sujet de disable-vmsplice-if-exploitable.c
Posté par inico (site web personnel) . Évalué à 1.
Enfin c'est comme ça que je comprend ce oops:
------------[ cut here ]------------
kernel BUG at /home/nico/novmsplice/novmsplice.c:59!
invalid opcode: 0000 [#1]
Modules linked in: novmsplice iptable_filter ip_tables it87 hwmon_vid hwmon i2c_isa xt_physdev x_tables i2c_i801 i2c_core
CPU: 0
EIP: 0061:[] Not tainted VLI
EFLAGS: 00010287 (2.6.20-xen-r6 #1)
EIP is at nosuchsyscall+0x0/0x4 [novmsplice]
eax: 0000013c ebx: 00000004 ecx: bfde2a2c edx: 000000d8
esi: 00000000 edi: b7f8d000 ebp: c6c30000 esp: c6c31fb4
ds: 007b es: 007b ss: 0069
Process jessica_biel_na (pid: 6408, ti=c6c30000 task=c6de4550 task.ti=c6c30000)
Stack: c0104784 00000004 bfde2a2c 00000001 00000000 b7f8d000 bfde29d8 0000013c
0000007b 0000007b c0410000 0000013c 0804825c 00000073 00000286 bfde29c0
0000007b 08074e90 00000000
Call Trace:
[] syscall_call+0x7/0xb
[] io_schedule_timeout+0x15/0x16
=======================
En tout cas, c'est vraiment pas discret maintenant :)
==> http://www.linux.it/~md/software/novmsplice.tgz
# fermer la porte à double tour
Posté par B16F4RV4RD1N . Évalué à 6.
Donc avant de sortir de chez vous si vous n'avez pas le temps de patcher votre noyau : fermez la porte à double tour, ou barricadez-là, l'attaque ne pourra pas venir d'ailleurs !
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: fermer la porte à double tour
Posté par inico (site web personnel) . Évalué à 10.
Il ne suffit de pas grand chose pour que l'exploit, au lieu d'ouvrir un shell bash, télécharge un r00tk1t et le lance.
[^] # Re: fermer la porte à double tour
Posté par BAud (site web personnel) . Évalué à 6.
Effectivement pour ceux qui ont débranché le cable réseau c'est bon (sans aller jusqu'à éteindre le PC si vous n'en avez pas besoin et débrancher son cable d'alim' pour les plus paranos).
[^] # Re: fermer la porte à double tour
Posté par B16F4RV4RD1N . Évalué à 1.
J'ai testé le code ici : http://www.milw0rm.com/exploits/5092 sur mon ordinateur perso, et cela fonctionne vraiment bien, c'est impressionnant !
C'est mieux qu'un sudo, pas besoin de mot de passe ni même l'autorisation :)
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: fermer la porte à double tour
Posté par anakin . Évalué à 5.
Communiqué de OVH :
Bonjour,
Une importante faille de sécurité a été mise en évidence ce week-end
sur l'ensemble des noyaux Linux 2.6.XX que vous pouvez utiliser chez
Ovh (et pas seulement). Aucun patch de sécurité (grsecurity, PaX,
Openwall, etc) ne bloque ce bug. La seule possibilité de fixer le
bug est de mettre à jour votre kernel vers la dernière version de
Linux 2.6.24.2 (mis à jour hier soir à 21H51 !!).
Ce bug est TRÈS dangereux: n'importe quel utilisateur du serveur
permet d'avoir les droits de root en moins de 10 secondes !! Très très
simplement. En suite c'est foutu car il fait réinstaller le serveur.
Même si vous ne proposez pas de shell/bash sur vos serveurs, à travers
les scripts php, cgi etc on peut avoir l'accès root sur la machine.
Ne remettez pas à demain ou à ce soir cette mise à jour ! Il y a 1h
environ, on vient de bloquer le 1er serveur hacké avec cette méthode.
Et avec ce bug, c'est la sécurité du réseau qui est en dangers. Nous
n'allons donc pas hésiter 1 seconde de bloquer votre serveur s'il est
hacké. Prenez donc 10 minutes là pour exécuter ces quelques commandes
simples.
Ovh propose des noyaux patchés, verifiés et sécurisés contre ce bug
de sécurité. Aussi, le nouveau noyau supporte mieux les cartes réseaux
utilisés sur le hardware chez Ovh, l'iSCSI, ainsi qu'une tonne de
petits bugs du Kernel.
Comment mettre à jour le noyau en moins de 5 minutes ? Très simplement.
Même si vous n'avez jamais fait, vous allez réussir cette mise à jour smile
1.)
Connectez vous sur le serveur en SSH et tapez (copier coller):
# wget -q ftp://ftp.ovh.net/made-in-ovh/dedie/pat … e-sysfs.sh -O - | /bin/bash
# wget -q ftp://ftp.ovh.net/made-in-ovh/rtm/install_rtm.sh -O - | /bin/bash
Ceci met à jour votre RTM, le patch sysfs, 3ware. Une sécurité de plus
avant le reboot.
2.)
Dans le manager, choisissez "netboot" et puis "ipv4", puis la version
"32bits" ou "64bits" (ça dépend la distribution que vous utilisez)
Par exemple "bzImage-xxxx-std-ipv4-32"
En suite reconnectez sur sur le serveur en SSH et tapez
# reboot
Attendez le redémarrage du serveur (entre 2 et 5 minutes en fonction du
serveur) puis reconnectez-vous sur le serveur en SSH puis tapez:
# uname -a
La commande doit vous renvoyer la version 2.6.24.2. Par exemple:
# uname -a
Linux oles2.ovh.net 2.6.24.2-xxxx-std-ipv4-32 #1 SMP Mon Feb 11 14:51:26
Si vous n'utilisez pas le netboot, vous pouvez telecharger nos noyaux
sur ftp://ftp.ovh.net/made-in-ovh/bzImage
bzImage-2.6.24.2-xxxx-std-ipv4-32
bzImage-2.6.24.2-xxxx-std-ipv4-32-hz1000
bzImage-2.6.24.2-xxxx-std-ipv4-64-hz1000
bzImage-2.6.24.2-xxxx-std-ipv6-32
bzImage-2.6.24.2-xxxx-std-ipv4-32-filer
bzImage-2.6.24.2-xxxx-std-ipv4-64
bzImage-2.6.24.2-xxxx-std-ipv4-64-rescue
bzImage-2.6.24.2-xxxx-std-ipv6-64
Les noyaux GRSecurity ne sont pas encore disponible. Le patch sera dispo
sous quelques jours.
Si vous compilez vous-même le noyau, vous pouvez trouver notre .tar.gz
ainsi que les .config sur ftp://ftp.ovh.net/made-in-ovh/bzImage
Si vous avez des problèmes, merci d'utiliser le forum ou la mailing list
afin qu'on vous aide très directement. N'oubliez pas mettre le nom de
votre serveur dédié dans vos messages (chaque message). Sur le forum:
http://forum.ovh.com/showthread.php?t=31396
Merci à tous et bon patch !
Les clients qui ont pris l'option sécurité totale sont en cours de mise
à jour (déjà).
Amicalement
Octave
[^] # Re: fermer la porte à double tour
Posté par briaeros007 . Évalué à -2.
Parce que le ton (un peu trop copain pour un pro a mon gout) et les fautes d'ortho , voila quoi /o\
[^] # Re: fermer la porte à double tour
Posté par Toto . Évalué à 6.
Pour le ton, je saurais pas dire, je l'ai toujours vu parler comme ça sur la mailing / ng, la première fois ça surprend, après ça passe tout seul
[^] # Re: fermer la porte à double tour
Posté par Sufflope (site web personnel) . Évalué à 4.
En effet il n'est pas francophone d'origine, et il mâche pas ses mots (c'est plus sympa).
# Pourquoi donner le source ?
Posté par Paul . Évalué à 0.
Pour que les admins puissent tester leurs machines ok, sauf que la n'importe qui, qui a un shell sur une machine ou il ne doit pas etre root peut l'etre en 20sec.
Quel est donc l'utilité de mettre le source à disposition de tout le monde aussi facilement ?
[^] # Re: Pourquoi donner le source ?
Posté par ragoutoutou . Évalué à 10.
Que tout le monde ait l'info et ait un outil de vérification?
De toutes façons, la sécurité par l'obscurité, ça marche pas plus d'une demie journée pour ce genre de trucs...
[^] # Re: Pourquoi donner le source ?
Posté par Paul . Évalué à 3.
Je me mets à la place de l'admin en fac d'info, il a du se jeter sur le cable reseau...
[^] # Re: Pourquoi donner le source ?
Posté par ragoutoutou . Évalué à 5.
En pratique, le temps de réaction est toujours plus lent que ça... faut être couillu pour changer le noyau sur des serveurs de prod en une demie journée sans faire de tests de régression...
[^] # Re: Pourquoi donner le source ?
Posté par ribwund . Évalué à 2.
[^] # Re: Pourquoi donner le source ?
Posté par iznogoud . Évalué à 2.
==> []
[^] # Re: Pourquoi donner le source ?
Posté par - - . Évalué à -1.
les étudiants se font du mal à eux même.
-
les serveurs eux sont hors d'atteinte de tout code permettant de l'exécution distante ou de login par des personnes extérieures au service informatique.
ce qui laisse de quoi préparer tranquillement les mises à jour sans risque de régression.
et non, je n'ai pas de parc sous (open)solaris pour simplement des postes de travail matlab et autres nastran pour les étudiants.
[^] # Re: Pourquoi donner le source ?
Posté par Sylvain (site web personnel) . Évalué à 3.
Le mieux c'est pas de l'éviter mais d'y faire face et de la corriger dans un délai minimal. Apres si les admins systemes ne mette pas à jour leur systemes c'est un autre probleme.
[^] # Re: Pourquoi donner le source ?
Posté par inico (site web personnel) . Évalué à 2.
[^] # Re: Pourquoi donner le source ?
Posté par tuXico . Évalué à 2.
Parceque le libre arbitre est censé aider les gens à ne pas être débile/faire des choses débiles ?
Parceque ça pourrait aider à hacker le site du FN si il tourne sous mollusk ?
En fait, la vraie question est "pourquoi ne pas donner le source ?"
Si Ta réponse est "pour éviter le hack", sache que les hackers se passent ce genre de choses très rapidement. Ensuite et bien le coup de "Le pouvoir sait mieux que vous ce qui est bon pour vous" est -selon moi- une très mauvaise chose (confer hack-tualités et autres "traités-faits-par-simplet"...
[^] # Re: Pourquoi donner le source ?
Posté par ragoutoutou . Évalué à 5.
Bon, maintenant il est clair que cet exploit est diffusé à un plus grand nombre de personnes que les hackers classiques et que les script kiddies vont s'en donner hacker joie ...
Mais de toutes façons, la sécurité par l'obscurité, ça se résume souvent à un veilleur de nuit aux yeux bandés traquant des cambrioleurs équipés de lampes de poches...
[^] # Re: Pourquoi donner le source ?
Posté par abramov_MS . Évalué à 3.
[^] # Re: Pourquoi donner le source ?
Posté par Yth (Mastodon) . Évalué à 4.
Ben on te file la faille ET la nouvelle version du kernel qui la corrige *en même temps*, je crois que les « hackers du kernel » sont donc bien au courant, et ont déjà réagit, non ?
Donc tout va bien, t'es au courant toi, tu as la solution pour corriger ton problème, l'affaire est entendue, les choses ont été faite au plus vite et au mieux, non ?
Yth.
[^] # Re: Pourquoi donner le source ?
Posté par Troy McClure (site web personnel) . Évalué à 2.
[^] # Re: Pourquoi donner le source ?
Posté par IsNotGood . Évalué à 1.
Mais on serait des trous du cul si on empéchait les trous du cul de le faire.
Faut vivre avec. Le monde parfait n'existe pas.
[^] # Re: Pourquoi donner le source ?
Posté par Yth (Mastodon) . Évalué à 5.
Par exemple mettre ton ssh sur un autre port que le 22 est efficace *uniquement* parce que la très grande majorité des gens le laisse sur le port par défaut. Les cracker ou autres script-kiddies qui cherchent une machine à compromettre en cherchent une facile, ils en testent plein et tapent sur la plus faible.
Ca serait complètement inutile si par exemple quelqu'un cherchait à entrer chez toi précisément, il doit falloir dix secondes de scan pour trouver sur quel port se trouve ton ssh.
Une faille de sécurité comme celle-ci, mieux vaut en parler beaucoup, partout, que les gens soient au courant et mettent à jour, mine de rien si la majorité des machines sont à jour, ça rend le travail de recherche d'une machine vulnérable nettement plus difficile, et peut suffire à protéger ceux qui ne se sont pas foulés.
Yth.
[^] # Re: Pourquoi donner le source ?
Posté par Étienne . Évalué à 6.
Le problème c'est justement qu'on en a parlé beaucoup, partout, avant que les gens ne puissent mettre à jour. On n'a pas laissé le temps aux distribs de publier les mises à jour. Il aurait suffit de 3 ou 4 jours, ça aurait permis aux packagers de bien faire leur boulot, de mener leurs tests et de faire une publication sereinement, au lieu de ça tout a été fait dans la précipitation et l'exploit a été diffusé avant le correctif officiel.
Ne me fait pas croire que ne pas divulguer un exploit pendant 3 jours c'est de la sécurité par l'obscurité. Surtout qu'à la limite, ce n'est pas tant le fait d'avoir révélé le problème qui est reproché, c'est d'avoir publié un exploit accessible au premier décérébré venu en même temps que la faille.
Pour conclure je pense que vous ne savez pas ce que c'est que la sécurité par l'obscurité. Garder une faille découverte secrète pendant quelques jours en prévenant l'auteur du soft, et lui laisser ce laps de temps pour ne pas tout faire dans la précipitation, ce n'est pas de l'obscurité, et c'est d'ailleurs comme ça que ça se passe dans la majorité des cas. Jusque là je n'ai entendu personne se scandaliser qu'une faille ne soit révélée que le jour où le correctif est présent (lorsque le délai est raisonnable bien entendu).
[^] # Re: Pourquoi donner le source ?
Posté par Paul . Évalué à 0.
Je ne critique pas le fait de faire que tout le monde soit au courant de cette faille, il le faut. Mais que le premier venu puisse l'exploité aussi facilement ...
Que tout le monde explique le fonctionnement de l'exploit, les mécanismes du pourquoi. Oui, il faut le diffuser pour pas que ca se reproduise.
"Ca serait complètement inutile si par exemple quelqu'un cherchait à entrer chez toi précisément, il doit falloir dix secondes de scan pour trouver sur quel port se trouve ton ssh."
Tout à fait d'accord, la personne qui veut s'introduire sur un serveur, fera tout ce qu'elle peut pour y rentre, mais pourquoi lui facilité la tache?
Mais donner le fichier .c qui fait tout tout seul. Je ne vois pas l'interet, c'est un peu comme donner une arme aux "méchants" en leur disant "de toute façon vous en trouverez".
Si je vous écoutes il faudrait enlever les alarmes, les caméras vidéos dans les banques puisque de toute façon ca n'empeche pas le vol mais ca ne fait que ralentir ...
Comme le dit l'expression "C'est l'occasion qui fait le larron".
[^] # Re: Pourquoi donner le source ?
Posté par Thomas Douillard . Évalué à 4.
[^] # Re: Pourquoi donner le source ?
Posté par Yth (Mastodon) . Évalué à 3.
Changer un port c'est à la portée de n'importe qui en plus c'est trivial.
Tu peux faire le test, si tu as une machine sur internet, ou sur laquelle tu transfère le port 22, tu logges les tentatives de connexion sur le port ssh, et tu vois que tu te prends des vagues d'attaques régulières, de parfois plusieurs heures, et plusieurs fois dans la journée, des tentatives de login/mot de passe, des trucs bizarres...
Change de port ensuite, et tout disparaît.
Tu gagnes donc énormément en tranquillité, mais uniquement contre les attaques aléatoires, et pas vraiment en sécurité contre ce qui est dirigé contre toi directement.
Bref, à mon avis ça ne change pas grand chose que le script ait été fournis ou pas, un équivalent devait déjà traîner sur des sites de crackers.
Il ne doit pas falloir plus de quelques heures à un type qui s'y connaît pour exploiter une faille quand on la lui montre du doigt.
Enfin, c'est mon avis, et je pense vraiment que très peu de mal a été causé par le fait de fournir le code directement, et qu'au contraire ça peut filer un coup de fouet aux admins systèmes un peu paresseux qui vont tester pour le fun et voir que ça marche au poil. Ca oui, ils auront passé une demi-journée stressante, mais c'est mieux que de se retrouver dans trois mois avec un type qui fout tout en l'air parce que la faille a été oubliée dans un coin.
Encore une fois c'est juste mon avis...
Yth.
[^] # Re: Pourquoi donner le source ?
Posté par Thomas Douillard . Évalué à 2.
Ce qui est pas forcément le cas.
[^] # Re: Pourquoi donner le source ?
Posté par Psychofox (Mastodon) . Évalué à 1.
Change de port ensuite, et tout disparaît.
Tu gagnes donc énormément en tranquillité, mais uniquement contre les attaques aléatoires, et pas vraiment en sécurité contre ce qui est dirigé contre toi directement.
Ce que tu gagnes, c'est surtout d'avoir moins de log à parser en cas d'attaque plus sérieuse.
bon sinon avec pf on peut toujours s'amuser avec des :
table persist
block quick from
pass quick proto { tcp, udp } from any to any port ssh \
flags S/SA keep state \
(max-src-conn 10, max-src-conn-rate 5/2, \
overload flush global)
et le calme revient :)
[^] # Re: Pourquoi donner le source ?
Posté par Paul . Évalué à 1.
Mettez vous 2sec a la place de l'admin qui a un serveur qu'il ne peut pas rebooter comme il veut pour X raisons, et qu'il a des utilisateurs qui se connectent dessus, que ces utilisateurs n'ont pas les compétences pour implémenter de tel mécanismes(ce qui doit être a vu de nez plus de 50% des utilisateurs de linux)
Maintenant dans ces utilisateurs combien vont "essayé" le .c qu'ils vont trouver sur leur site de news linux favoris ?
La faille est connu depuis longtemps : Surement
Mais moi simple developpeur, je n'ai vu la faille que parce que je lis linuxfr, je n'aurais pu être root sur une machine ou je n'avais pas le droit que parce que je lis linuxfr et que j'ai cliqué sur tous les liens de la news.
Mon admin attendait deseperement une maj debian qui est arrivé vers 17-18h le jour de poste de ce journal(je ne le critique pas il fait ce qu'il peut)
Tout ca pour dire que cacher l'info c'est mal, mais faciliter l'exploitation d'une telle faille c'est encore plus mal.
[^] # Re: Pourquoi donner le source ?
Posté par Maxime (site web personnel) . Évalué à 1.
Là n'importe qui capable de faire gcc exploit.c -o exploit && ./exploit peut l'exploiter...
C'est quand même un problème. Je sais que dans mon école, ya des trucs qui ne sont pas super sécurisés mais on sait bien que personne ne va l'exploiter, se donner la peine de faire des recherches etc.
Alors que là, c'est super tentant quand même ! (non je vous rassure, j'en ai surtout parlé au responsable)
Imaginez, être root en 30 secondes à peine... C'est vraiment trop à la portée de tous.
[^] # Re: Pourquoi donner le source ?
Posté par Gniarf . Évalué à 2.
# Fix pour debian dispo
Posté par kolter (site web personnel, Mastodon) . Évalué à 1.
http://lists.debian.org/debian-security-announce/debian-secu(...)
M.
[^] # Re: Fix pour debian dispo
Posté par finss (site web personnel) . Évalué à 1.
\_o<
[^] # Re: Fix pour debian dispo
Posté par IsNotGood . Évalué à 3.
# x86 only
Posté par benoar . Évalué à 0.
Vive les PPC \o/
(meme si vu la gueule du code, i.e. mettre 2 ou 3 trucs sur la pile et faire un return, ca doit etre adaptable a d'autres archis ...)
[^] # Re: x86 only
Posté par z a . Évalué à 2.
[^] # Re: x86 only
Posté par benoar . Évalué à 2.
Pour ce bug en particulier, dans l'exploit tu vois bien du :
"movl %0, 0x10(%%esp) ;"
"movl %1, 0x0c(%%esp) ;"
"movl %2, 0x08(%%esp) ;"
"movl %3, 0x04(%%esp) ;"
"movl %4, 0x00(%%esp) ;"
"iret"
et encore un :
#else
#error "unsupported arch"
#endif
si c'est pas i386 ni x86_64 ...
[^] # Re: x86 only
Posté par IsNotGood . Évalué à 4.
Ça montre seulement que la démonstration de l'exploitation de la faille a été faite sur i386 et x86_64.
Ça n'indique pas que la faille n'existe pas sur ppc.
La faille existe pour toutes les architectures.
[^] # Re: x86 only
Posté par benoar . Évalué à 2.
Mais bon, si on peut même plus troller tranquille ...
# Depeche de premiere page?
Posté par Guillaume Estival . Évalué à 3.
Il serait donc probablement judicieux de rediger une depeche de premiere page pour les gens qui regardent juste linuxfr a la va vite (et c'est surement le seul site de news linux qu'ils regardent)
est ce que quelqu'un s'est deja devoue? sinon je fais un truc dans la journee...
[^] # Re: Depeche de premiere page?
Posté par Psychofox (Mastodon) . Évalué à 5.
Ceux qui sont aveugles à ça ne vont pas être "sauvés" par linuxfr...
[^] # Re: Depeche de premiere page?
Posté par eon2004 . Évalué à 2.
La news LinuxFR sera surement rerise par d'autres sites d'informatique plus généralistes
# CVE
Posté par ribwund . Évalué à 3.
[^] # Re: CVE
Posté par superna (site web personnel) . Évalué à 1.
# Question qui a son importance....
Posté par Chris K. . Évalué à 2.
[^] # Re: Question qui a son importance....
Posté par Chris K. . Évalué à 2.
# EEEPC
Posté par Dr Archy . Évalué à 2.
http://www.vulnerabilite.com/asus-eee-pc-vulnerabilite-samba(...)
[^] # Re: EEEPC
Posté par GG (site web personnel) . Évalué à 0.
J'ai acheté hier cet Asus EEE
Je sens que je vais remplacer vite fait Xandros par Linux Debian, parce que je connais bien Debian.
Le système de mise à jour de ce Linux Xandros ne m'a pas plu du tout (je ne sais pas si la mise à jour de Samba était proposée, je ne m'y suis pas intéressé, et pour le moment j'ai prêté ce portable).
J'ai voulu installer Miro, mais le clic sur le lien de DL pour Linux à été sans effet.
Pour ma part, je sais que sous Debian, un aptitude install miro règlera cet obstacle.
De même, je pourrai y installer kphotalbum....
Enfin bref, je pourrai gérer cet ordinateur comme j'ai l'habitude de le faire, c'est à dire de manière conviviale :) une fois qu'il sera sous Linux Debian (un vrai Linux quoi).
A bientôt
G
Pourquoi bloquer la publicité et les traqueurs : https://greboca.com/Pourquoi-bloquer-la-publicite-et-les-traqueurs.html
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.