Ubuntu, ou la pire distrib de MERDE

Kevin Denis <kevin@nowhere.invalid> a suggéré :

Le 15-11-2010, Hugues <hugues@hiegel.fr> a écrit :

Tu confonds virus/ver avec exploit/faille/trou de sécurité.

Et comment se réplique t'il, ce virus? En exploitant une faille.

Déjà, explique moi comment exploiter la faille de samba dans le cas d'un

'Execution arbitraire de code'. Ce qui signifie que si tu veux exécuter
un code qui va se réploquer, tu peux. Ou afficher un petit coin-coin.
Ou ouvrir ton chariot CD.

Seulement si l'utilisateur samba en a le droit.

virus/ver (jamais entendu parler), ou celle d'ImageMagick... De façon à
compromettre le système, pas "seulement" des fichiers utilisateur - ce
qui est déjà grave, mais tant que l'utilisateur X ne bouffe pas les
fichiers de l'utilisateur Y

ImageMagick, c'est l'exemple. Dans /tmp je colle les deux fichiers xml.
Tu arrives innocemment, et pouf je peux exécuter du code sous ton
identité. All your files belongs to me!

Yeps, au temps pour moi, c'est exact sur ces deux points.


Ce qui m'intéresse alors, c'est de savoir :
- combien de temps ces failles ont été mises à l'air
- en combien de temps ont-elles été colmatées
- combien de failles de ce type trouve-t-on sur les OS linux ?

Et comparer tout ça avec l'autre OS.


Il peut bien exister des virus sous Linux (je n'ai jamais prétendu le
contraire, d'ailleurs), mais ils sont trop peu nombreux, non parce que
Linux n'est pas répandu sur le desktop (il est répandu en tant que
serveur, et sur la quasi *TOTALITE* des box ADSL des particuliers...),
mais bien parce qu'une faille trouvée sur un Linux est plus
difficilement exploitable.
Je ne pense pas qu'on arriverait à un tel niveau d'insécurité si Linux
était plus répandu :
- la sécurité dépend avant tout de la distribution et de sa politique de
packaging/configuration/etc..
- un trou exploitable dans un système linux est généralement rapidement
colmaté (à part quelques cas de figure assez rares.. contrairement à
microsoft où il semblerait que ce soit dans leur politique de traîner
des pieds..)
- les distributions "non secure" ne vivraient pas très très longtemps..

et encore moins ceux de l'utilisateur root... bah...

Aujourd'hui, un user local qui peut exécuter du code est
quasiment root.

Quasiment ? Comment ça ?
Et pour moi, "quasiment root" n'est pas "root".
Effectivement, n'importe quel OS mal configuré de base pose un problème,
mais je reste persuadé que les installeurs des différentes distributions
Linux font un boulot a peu près correct, en comparaison de Windows
pendant de longues années (ils se sont améliorés, mais la gestion
des droits Admin reste à mon sens trop pénible, et le système trop
archaïque en soi, pour que la majorité des gens s'y tienne, et retrouve
vite ses mauvaises habitudes d'antan..)

CVE-2009-2692, entre autre. Je parle pour les machines
serveurs. Pour les machines 'desktop' ou l'user est également
admin, c'est encore plus simple:
http://www.geekzone.co.nz/foobar/6229#compact

Je rappelle que pour qu'un ver soit actif, aucune action de
l'utilisateur n'est nécessaire pour que ton système soit corrompu...

Parceque pour samba, tu crois que l'user à quelquechose à cliquer?

C'est ce que j'avais compris, au temps pour moi.

Ensuite, ta définition est surprenante. Certains virus sous windows
demandent à l'utilisateur d'installer un codec pour visionner une
vidéo. Ver? Virus? Malware? Que penser des failles pdf, alors? On
t'envoie un pdf piégé. Ver ou pas ver?

Je parlais de ver. Un virus a besoin d'un "hôte" pour se propager et se
reproduire (typiquement, un programme ou un fichier *lu par un programme
ciblé*, comme le cas des mails).

On est loin des iloveyoublastersasser ..

I love you, c'était une faille du mailer de windows. Dans l'ordre, c'était
je reçois un mail, je l'ouvre, bam.

Tous les clients mails étaient-ils concernés ? Ou bien seulement ceux
qui utilisaient une technologie particulière ? (le moteur de rendu d'IE
? les Active X ? ...)

Voyons, tu utilises mutt?
http://www.cert.org/advisories/CA-1998-10.html

C'est intéressant de voir que parmi les mailers concernés, il est un des
rares a avoir déjà des patches à l'époque...
C'est justement ce point-là, entre autres, que je souligne dans la
différence entre le monde unix et microsoft..

Tu reçois un mail, tu l'ouvres, bam. Il n'y a que peu de
différences.

Si : quand je "clique" sur un mail dans mutt, il ne me l'affiche pas
immédiatement. Contrairement à plein de mailers....
Et même si je l'avais fait, si tu lis bien ton lien : " Depending on the
operating system on which the mail client is running and the privileges
of the user running the vulnerable mail client, the intruder may be able
to crash the entire system".

Mes privilèges étant assez bas ...
J'ai un gros doute pour les clients Windows, ou ceux qui ont l'habitude
d'utiliser le compte root pour tout et n'importe quoi.

Tu utilises un autre mailer? Je suis à peu près sur qu'on peut
trouver une faille équivalente.

Qui fasse crasher totalement mon Linux ? Bon courage.

Je rappelle qu'à la base on parlait de virus/ver sous Linux, et du fait
qu'il n'y en a que très peu et que ce n'est pas sa popularité qui va
changer quoi que ce soit.
Windows est un système qui traîne de grosses casseroles dont Microsoft
tarde à se débarasser, ce qui explique qu'il y ait autant de moyen de
crasher totalement le système..
Avec Linux, la diversité des versions disponibles dans le monde, la
diversités des softs et la meilleure granularité dans la gestion des
droits divers, rien ne m'a été démontré.

--
Hugues Hiegel [http://www.hiegel.fr/~hugues/]

Tonton Th <tth@la.bas.invalid> a suggéré :

On 11/15/2010 03:23 PM, Hugues wrote:

Parce que j'ai egalement investigues sur des serveurs infectes et que
je sais de quoi il s'agit et de comment ils sont rentres.

Tiens, je suis curieux de connaître la méthode que tu as employée..
Car je ne connais aucun outil capable de déterminer de façon 100% fiable
l'OS d'un noeud réseau...

bah, quand tu as un serveur infecté, c'est assez simple de
l'éteindre, de sortir le disque, et de regarder sur une autre
machine, non ?

J'ai eu à le faire une fois, et c'est assez instructif...

Un serveur pris au pif sur le réseau ???
T'es rigolo, toi :)

--
Hugues Hiegel [http://www.hiegel.fr/~hugues/]

Ce cher DuboisP <patrickr.dubois.don't.spam@free.fr.invalid> a posté :

les ubuntu, faut quand même les rebooter, quand il y a un changement
de noyau

tout OS doit être rebooté lors d'un upgrade du kernel, c'est évident.
quoique on peut tricher avec kexec..

mais qu'une mise à jour d'un soft purement userspace nécessite un reboot
du système, ça me dépasse. c'est le genre de trucs qui m'a dégoûté de
windows et de macosx.


--
Hugues Hiegel [http://www.hiegel.fr/~hugues/]

Le Tue, 16 Nov 2010 13:12:14 +0100,
Hugues <hugues@hiegel.fr> écrivait :

Ce cher DuboisP <patrickr.dubois.don't.spam@free.fr.invalid> a posté :

les ubuntu, faut quand même les rebooter, quand il y a un changement
de noyau

tout OS doit être rebooté lors d'un upgrade du kernel, c'est évident.
quoique on peut tricher avec kexec..

C'est un peu casse-gueule car il faut virer toutes les structures en
mémoire pour redémarrer sur un noyau propre. Cela signifie aussi
repartir sur une VM propre avec de nouvelles structures. Bref, c'est
beaucoup plus sûr de redémarrer lorsqu'on touche au noyau.

mais qu'une mise à jour d'un soft purement userspace nécessite un reboot
du système, ça me dépasse. c'est le genre de trucs qui m'a dégoûté de
windows et de macosx.

Donc de Ubuntu aussi parce que c'est maintenant ce qui est
préconisé...

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

Ce cher JKB <jkb@koenigsberg.invalid> a posté :

Le Tue, 16 Nov 2010 13:12:14 +0100,
Hugues <hugues@hiegel.fr> écrivait :

Ce cher DuboisP <patrickr.dubois.don't.spam@free.fr.invalid> a posté :

les ubuntu, faut quand même les rebooter, quand il y a un changement
de noyau

tout OS doit être rebooté lors d'un upgrade du kernel, c'est évident.
quoique on peut tricher avec kexec..

C'est un peu casse-gueule car il faut virer toutes les structures en
mémoire pour redémarrer sur un noyau propre. Cela signifie aussi
repartir sur une VM propre avec de nouvelles structures. Bref, c'est
beaucoup plus sûr de redémarrer lorsqu'on touche au noyau.

Bien d'accord.
Et de toutes façons, kexec ne permettait pas de préserver l'uptime,
alors bon.. ;o)

mais qu'une mise à jour d'un soft purement userspace nécessite un reboot
du système, ça me dépasse. c'est le genre de trucs qui m'a dégoûté de
windows et de macosx.

Donc de Ubuntu aussi parce que c'est maintenant ce qui est
préconisé...

J'exècre Ubuntu. J'ai été bluffé pendant 2/3 jours quand je l'ai testé
pour la première fois, sur mon iBook, mais j'ai vite déchanté.


--
Hugues Hiegel [http://www.hiegel.fr/~hugues/]

Le Tue, 16 Nov 2010 13:53:25 +0100,
Hugues <hugues@hiegel.fr> écrivait :

Ce cher JKB <jkb@koenigsberg.invalid> a posté :

Le Tue, 16 Nov 2010 13:12:14 +0100,
Hugues <hugues@hiegel.fr> écrivait :

Ce cher DuboisP <patrickr.dubois.don't.spam@free.fr.invalid> a posté :

les ubuntu, faut quand même les rebooter, quand il y a un changement
de noyau

tout OS doit être rebooté lors d'un upgrade du kernel, c'est évident.
quoique on peut tricher avec kexec..

C'est un peu casse-gueule car il faut virer toutes les structures en
mémoire pour redémarrer sur un noyau propre. Cela signifie aussi
repartir sur une VM propre avec de nouvelles structures. Bref, c'est
beaucoup plus sûr de redémarrer lorsqu'on touche au noyau.

Bien d'accord.
Et de toutes façons, kexec ne permettait pas de préserver l'uptime,
alors bon.. ;o)

Disons que le développement de kexec (et équivalent) permet à des
équipes de dev de manger. Mais pour mettre régulièrement mes mains
dans le coeur d'OS (pas de Linux, je ne suis pas fou, mon psy
m'interdit de retoucher au coeur de Linux car il a peur pour ma
santé mentale), je ne ferai _jamais_ confiance à un truc pareil. Le
seul moyen de faire quelque chose de propre est d'utiliser un
micronoyau (un vrai de type L4, pas Mach qui n'est pas un
micronoyau), ce qui permet en théorie de mettre à jour tout ce qui
n'est pas dans le micronoyau et la roottask (on se contrefiche de
sigma0 qui devrait normalement avoir fini son boulot). Cela englobe
tous ce qui n'est ni la gestion des processus ni la gestion de la
mémoire.

mais qu'une mise à jour d'un soft purement userspace nécessite un reboot
du système, ça me dépasse. c'est le genre de trucs qui m'a dégoûté de
windows et de macosx.

Donc de Ubuntu aussi parce que c'est maintenant ce qui est
préconisé...

J'exècre Ubuntu. J'ai été bluffé pendant 2/3 jours quand je l'ai testé
pour la première fois, sur mon iBook, mais j'ai vite déchanté.

Moi aussi. Mais c'est une boubouneterie qui est présentement dans
debian.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

JKB avait énoncé :

Le Tue, 16 Nov 2010 13:12:14 +0100,
Hugues <hugues@hiegel.fr> écrivait :

Ce cher DuboisP <patrickr.dubois.don't.spam@free.fr.invalid> a posté :

les ubuntu, faut quand même les rebooter, quand il y a un changement
de noyau

tout OS doit être rebooté lors d'un upgrade du kernel, c'est évident.
quoique on peut tricher avec kexec..

C'est un peu casse-gueule car il faut virer toutes les structures en
mémoire pour redémarrer sur un noyau propre. Cela signifie aussi
repartir sur une VM propre avec de nouvelles structures. Bref, c'est
beaucoup plus sûr de redémarrer lorsqu'on touche au noyau.

Ca semble logique (quelque soit l'OS). Cela semble un procès
d'intention car j'ai l'impression que si certains linuxiens n'aiment
pas Ubuntu, c'est qu'il se rapproche trop en facilité d'utilisation du
cliquodrôme honni. Modifier ses fichiers conf avec un éditeur normal et
sans utiliser vi, par exemple, en rend certains malades.

mais qu'une mise à jour d'un soft purement userspace nécessite un reboot
du système, ça me dépasse. c'est le genre de trucs qui m'a dégoûté de
windows et de macosx.

Donc de Ubuntu aussi parce que c'est maintenant ce qui est
préconisé...

Et tout système moderne qui stockera des trucs et des machins en
mémoire (pas pour rien qu'on enfile des barrettes de plus en plus
grosse) sera soumis à la malédiction du reboutage. Paradoxalement
Windows, dès fois, n'ose pas demander de rebouter alors que c'est quand
même conseillé (après l'instalaltion de SQL Server, par exemple). Sur
mon serveur 2008, il est bien élevé, il regroupe les MAJ pour ne
demander qu'un seul reboutage.

Le Tue, 16 Nov 2010 14:03:19 +0100,
Williamhoustra <williamhoustra@trapellun.net> écrivait :

JKB avait énoncé :

Le Tue, 16 Nov 2010 13:12:14 +0100,
Hugues <hugues@hiegel.fr> écrivait :

Ce cher DuboisP <patrickr.dubois.don't.spam@free.fr.invalid> a posté :

les ubuntu, faut quand même les rebooter, quand il y a un changement
de noyau

tout OS doit être rebooté lors d'un upgrade du kernel, c'est évident.
quoique on peut tricher avec kexec..

C'est un peu casse-gueule car il faut virer toutes les structures en
mémoire pour redémarrer sur un noyau propre. Cela signifie aussi
repartir sur une VM propre avec de nouvelles structures. Bref, c'est
beaucoup plus sûr de redémarrer lorsqu'on touche au noyau.

Ca semble logique (quelque soit l'OS). Cela semble un procès
d'intention car j'ai l'impression que si certains linuxiens n'aiment
pas Ubuntu, c'est qu'il se rapproche trop en facilité d'utilisation du
cliquodrôme honni. Modifier ses fichiers conf avec un éditeur normal et
sans utiliser vi, par exemple, en rend certains malades.

Ce n'est absolument pas mon cas. Je déteste Ubuntu parce que c'est
un mélange entre une debian/testing et unstable et qu'on peut avoir
de grosses surprises. Je l'exècre parce que cette distribution sort
à des moments précis de façon totalement indépendante de sa qualité.

mais qu'une mise à jour d'un soft purement userspace nécessite un reboot
du système, ça me dépasse. c'est le genre de trucs qui m'a dégoûté de
windows et de macosx.

Donc de Ubuntu aussi parce que c'est maintenant ce qui est
préconisé...

Et tout système moderne qui stockera des trucs et des machins en
mémoire (pas pour rien qu'on enfile des barrettes de plus en plus
grosse) sera soumis à la malédiction du reboutage. Paradoxalement
Windows, dès fois, n'ose pas demander de rebouter alors que c'est quand
même conseillé (après l'instalaltion de SQL Server, par exemple). Sur
mon serveur 2008, il est bien élevé, il regroupe les MAJ pour ne
demander qu'un seul reboutage.

Je ne vois pas le rapport. L'OS sait que telle ou telle application
utilise telle ou telle bibliothèque et peut tout à fait faire les
choses proprement sans rebooter (c'est ce que fait une distribution
debian par exemple lorsqu'on change la libc). On reste en userland.
Le problème est de mettre à jour le noyau.

JKB

--
Si votre demande me parvient sur carte perforée, je titiouaillerai très
volontiers une réponse...
=> http://grincheux.de-charybde-en-scylla.fr

Kevin Denis <kevin@nowhere.invalid> a suggéré :

Aujourd'hui, un user local qui peut exécuter du code est
quasiment root. CVE-2009-2692, entre autre. Je parle pour les machines
serveurs. Pour les machines 'desktop' ou l'user est également
admin, c'est encore plus simple:
http://www.geekzone.co.nz/foobar/6229#compact

Site très instructif, merci,
et comme tu as lu le lien que tu m'as filé, tu auras noté que :

"I should point out: The vulnerabilities we will be taking advantage of
are 'features' of the most popular modern Linux desktop environments,
Gnome and KDE. The actual core of Linux itself does not have any of
these vulnerabilities. A Linux (or any other *nix) system without
running Gnome or KDE will not exhibit any of these problems, which is
one of the huge advantages of properly separating the core OS from other
applications such as the desktop environment."


Ça reste limité à l'utilisateur.

Point de virus dévastateur qui t'oblige à réinstaller ton système
derrière.



--
Hugues Hiegel [http://www.hiegel.fr/~hugues/]

Ce cher Williamhoustra <williamhoustra@trapellun.net> a posté :

JKB avait énoncé :

Le Tue, 16 Nov 2010 13:12:14 +0100,
Hugues <hugues@hiegel.fr> écrivait :

Ce cher DuboisP <patrickr.dubois.don't.spam@free.fr.invalid> a posté :

les ubuntu, faut quand même les rebooter, quand il y a un changement
de noyau

tout OS doit être rebooté lors d'un upgrade du kernel, c'est évident.
quoique on peut tricher avec kexec..

C'est un peu casse-gueule car il faut virer toutes les structures en
mémoire pour redémarrer sur un noyau propre. Cela signifie aussi
repartir sur une VM propre avec de nouvelles structures. Bref, c'est
beaucoup plus sûr de redémarrer lorsqu'on touche au noyau.

Ca semble logique (quelque soit l'OS). Cela semble un procès
d'intention car j'ai l'impression que si certains linuxiens n'aiment
pas Ubuntu, c'est qu'il se rapproche trop en facilité d'utilisation du
cliquodrôme honni. Modifier ses fichiers conf avec un éditeur normal
et sans utiliser vi, par exemple, en rend certains malades.

Non, car l'un n'empêche pas l'autre. C'est plutôt son incompatibilité
notoire avec les dépôts Debian alors qu'il est basé dessus qui m'a
profondément agacé, plus tout plein de petits détails absolument
inintéressants pour l'utilisateur lambda.
Perso, le reproche que je fais à ubuntu est valable à mandrake (à
l'époque où je l'avais testé), et à globalement toutes les usines à gaz
qui veulent toutes te faciliter la vie, en ne faisant que foutre un peu
plus de bordel sur ton disque dur. J'ai le même reproche à faire à
Gnome, KDE, Compiz.. Sauf que pour Gnome par exemple, je peux n'en
utiliser que quelques bouts (gnome-panel, gnome-settings-daemon), et
puis c'est marre.

Chacun son truc : moi je veux un disque propre dans lequel je retrouve
mes fichiers correctement rangés, quitte à me farcir une page man juste
pour modifier une option à la con. Je veux pouvoir tout contrôler, c'est
*MA* machine, bon sang.


--
Hugues Hiegel [http://www.hiegel.fr/~hugues/]