Quand je parlais de planter, c'etait le lag qu'il entrainait. Le fait qu'il y ait un clavier comme interface ne te permet pas de construire tes phrases aussi facilement qu'une joute orale.
En gros c'est souvent tres interessant mais aussi contre productif du point de vue temps. Il y a tres peu de questions qui peuvent passer surtout si elles sont pertinentes et interessantes. Car bon même a 100 touches minutes (tres optimiste pour un discours bien tourné) on dit pas grand chose en 5/10 minutes :-p
Dans le genre tres interessant tu as les interview a la kerneltrap mais c'est un autre domaine :-)
Je doute que ca soit tres performant. Ce qui rend agreable les "lectures"/conf comme cours c'est l'interaction directe avec ceux qui ecoutent. Quand tu fais ta presentation tu vois tout de suite la tete des gens et ca te donne une facon d'adapter ce que tu presentes. C'est la valeure ajoutée des confs.
Sur IRC tu perds ca. Tu as en plus la lenteur du support, a l'oral tu as une adaptation tres rapide et le "droit" à l'erreur. Si tu te plante, tu reformules la phrase dans le bon sens. À l'ecrit il faut le temps de formuler la phrase dans sa tete, de l'ecrire, qu'elle soit lisible appuyer sur entree. L'interactivité est tres basse et la qualite plus faible qu'un document traditionel béton.
C'est a essayer mais j'ai quelques doutes sur les perfomances.
C'est vrai que la référence de gtk/gdk, ce qui n'est pas le plus volumineux, c'est JUSTE 190000 lignes de Docbook a traduire; l'histoire d'une apres midi quoi. (y'a beaucoup de ligne de code certe, par contre l'identation ils connaissent pas :-p)
De plus anglais facile ne veut pas dire traduction facile. L'anglais arrive tres bien a faire des phrases tres courtes pour d'écrire les methodes; si tu veux rester synthetique, garder le sens et que ca sonne bien ca prend un certain temps.
(amuse toi a traduire un fichier de 200 lignes et regarde le temps que tu y passes tu risques d'être surpris !)
Peut etre simplement que les gens comme toi se font moinsser/inutiliser/ce que tu veux simplement par ce qu'ils n'apportent rien ?
Si on regarde tes commentaires (presque tous negatifs :-)
-> deux "pwet"
-> un "."
-> une connerie sur slackware (ca arrive a tout le monde)
-> le troll^wdebut sur les failles de linux 2.4. Tu t'es fais allumer par ce que tu n'avais aucun argumentaire hormis de dire que le mec qui a publié etait un gros connard car il comprometait tes serveurs.
Apres c'est sur on peut appeller a la revolte et jouer son de gaule. Mais post des commentaires intelligents et argumentes tu te feras beaucoup moins allumer...
Depuis la mise en place du nouveau systeme, les threads de controverse (et non troll) se font beaucoup moins moinsser par opinion me semble t-il. Par contre le troll, sterile de mecs qui ne savent pas de quoi ils parlent c'est une autre affaire. Il reste les gens comme 007 qui s'en prennent plein la geule non pas par ce qu'ils disent des conneries mais par ce qu'ils sont un peu fatiguant a la longue (bien que tres interessant souvent).
De plus il ne me semble pas que la foule lapide en ce moment, m'enfin bon. Autrement tu peux aussi faire "comme tout le monde" tu navigues a -42 et tu ne postes pas un 150 iemes journal sur cetaitmieuxavent ou les XPsapue.
Question : quel est l'interet de traduire la documentation de classes ? A priori si tu es developpeur tu comprends un minimum l'anglais. Surtout que quand tu regardes la doc de gtk c'est de l'anglais qu'un eleve de 4ieme peut lire; anglais technique de base comprehensible meme par le plus mauvais en anglais.
Ce genre de traduction me semble etre une enorme perte de temps. Ca n'apporte pas grand chose pour beaucoup d'efforts.
Il y a des choses bien plus interessante a traduire (par exemple des docs qui se lisent au contraire d'une suite sans fin de methodes qui ne sont qu'un manuel de reference)...
N'étant pas utilisateur d'OpenOffice normalement; j'en avais besoin pour la premiere fois cette semaine (1.1.2). Effectivement ca semble stable par contre ca n'en reste pas moins de l'X11. C'est a peu pres aussi agreable à utiliser qu'une interface Java, c'est a dire pas du tout adapté a son environement.
En même temps si ton but est de nuire tu malloc() pas comme un débile tu t'arretes juste avant d'épuiser la quantité RAM + swap. Du coup sur les noyaux sans OOM-killer la charge va s'envoler et la machine devient souvent irrecuperable, et sur les nouyaux avec alors il va tuer les process demarrant.
Le problème c'est que dans les solutions offertes actuellement et accessible par le plus grand nombre tu as le choix entre ne rien permettre a l'utilisateur (restrictions tres forte) ou alors lui permettre le DoS.
/etc/security/console.perms
man console.perms
man pam_console
Après ca depend si ta distrib l'integre de base, autrement tu as a modifier la pile d'authentification de pam en plus pour ajouter le pam_console dedans.
Avec toutes ces infos tu devrais facilement trouver sur google des choses bien plus détaillées si tu en as besoin :p
Name: NetBSD kernel swapctl(2) vulnerability
Date: 11 June 2004
CVE candidate: not assigned
Author: Evgeny Demidov
Description:
There exists a integer handling vulnerability in NetBSD swapctl(2) system call. It seems that this vulnerability can not be exploited to gain super-user privilegies, but any local attacker can crash the kernel.
Bon ok je propose qu'on post tous un journal privé par doc que l'on met en ligne histoire de rigoler un peu (on me dit que dans mon cas ca fait dans les 40 messages/mois...). Quand il y a quelque chose d'exceptionel je m'en fou, mais faire un message par doc c'est relou.
> news de Linux.Dvpz.com comme de la propagande Borlandiste,
Non je vois ca comme un site (enfin un mec) qui se prend pour le centre du monde en croyant que chaque nouveauté de son site interesse tout le monde. Faire 3 journaux de suite pour 3 docs comme tu le fais, c'est déjà pas dans les bonnes manières. Mais si en plus ces journaux signalent des "critiques" de livre qui n'apportent rien, qui font 10 lignes... Le seul interet que je vois la dedans c'est ton lien vers amazon qui doit être remuneré non ? (ce qui ne change pas grand chose au probleme d'ailleur)
Pour ceux qui doutent dans les 15 derniers jours :
FreeBSD : possibilité de modifier les tables de routage depuis une jail()
NetBSD : There exists a integer handling vulnerability in NetBSD swapctl(2) system call. It seems that this vulnerability can not be exploited to gain super-user privilegies, but any local attacker can crash the kernel. The vulnerability has been discovered several months ago by Evgeny Demidov during NetBSD kernel source code au dit. It has been made availabe to VulnDisco clients two months ago.
IRIX : that under certain conditions non privileged users can use the syssgi system call SGI_IOPROBE to read and write kernel memory which can be used to obtain root user privileges.
Two local DoS fixes are also addressed in these patches
Mec tu veux pas creer une mailing list sur developpez.com pour les gens que ca interesse et arreter de nous casser les ***** avec tes journaux publicitaires en série ?
Tout en dépendant de la faille (y'en a des bien tordues) à partir du moment ou l'endroit est identifiée et la cause comprise le code n'est qu'une question d'heures ou de jours.
> Ca semble logique, si tu tombes sur une faille dans le kernel linux, t envoies ton rapport à Microsoft.
Tu fais expres de faire le boulet ? Tout les vendeurs ont un security@domaine qui est une adresse privée et seuls les interessées (la team securité) recoivent l'information ca permet justement d'éviter que trop d'info ne se balandent pour indiquer qu'une faille existe avant que ca soit patché. Il me semble que linux ne dispose pas d'une telle adresse; si pour signaler un probleme de sécu tu dois le poster sur lkml ca me parait un peu contradictoire avec ce que tu avances.
> On analyse pas les raisons, on analyse le code justement. Ce code fait crasher linux.
"Tu dois savoir qu'aucune motivation raisonnable, louable ne pousse des gens à publier des exploits" tu appels ca analyser le code ?!? C'est une intepretation des faits d'autruit. Quand le mec a balance le code sur le bugzilla de gcc il n'avait pas forcement compris l'impact a partir de ce moment c'était trop tard. La lecon de l'exploit dans la VM linux n'a pas marqué les esprits apparement. Les "pirates" ne sont pas tous des guignols du dimanche qui vont sur 1337.c0m pour chopper les exploits, y'en a aussi qui codent pour des projets libres, qui suivent les changelogs, les bugzilla, qui lisent du code.
> Non, il a juste rendu publique une faille de sécurité, ainsi que le programme rendant vulnérable la quasi totalité du parc informatique LINUX x86.
C'est un fait.
> Ton indifférence est compréhensible, car tu n'as pas de connaissances suffisantes en matière de développement ou d'administration système .
Mouhaha je l'a bookmark celle la :-)
Ce n'est pas de l'indifference, c'est qu'a partir d'un moment tu es conscient que les failles n'existent pas qu'a partir du moment ou ./ en a parlé. Des failles noyaux y'en a une trippotée non divulgée ca en a toujours été ainsi. Tu as le choix entre un truc inconnu possedé par peu de personnes ou quelques chose de très répendu qui sera vite corrigé. Si ton entreprise est sensible je prefere de tres loin la seconde solution. Si tu es qu'une societe X ou Y alors effectivement il y a plus de risques de casse dans le second cas. C'est une faille locale, a partir du moment ou tu laisses quelqu'un faire un exec() il doit y avoir un minimum de confiance et de controle. L'utilisateur doit savoir qu'il sera puni en cas d'abus les autres ne devraient pas acceder a la machine.
"Ensuite une dizaine de petits malins de votre boite se sont empressés de faire sauter les serveurs ."
Faute grave, licenciement, tribunal (godfrain/LSI). Tes employes peuvent foutre le feux aux locaux, ou voler le matos informatique. Ils ne le font pas soit pas ce que ce ne sont pas des crétins soit par ce qu'ils en connaissent les conséquences. En informatique il en va de même.
Ce n'est ni la premiere ni la derniere faille, il y en aura toujours certaines publiques, certaines privees les conséquences variant selon la sensibilité de ce à quoi sert le parc. Si tu n'arrives pas a dormir avec cette idée et cette gestion du risque change de métier. Je te signal qu'au moins 3 codes pour l'exploit de la VM ont été publiés très rapidement et qu'au moins un était fonctionel presque tel quel...
> Les crashers se sont des types qui se loguent sur les machines pour les torpiller, ils ont une place comme tout les autres types de pirate dans les associations mafieuses.
C'est quoi le rapport avec la tambouille ? Tu crois que le maichant pirate payer par la maichante concurence attend que l'exploit soit publique pour aller le chercher sur /. ? C'est bizare mais j'ai un doute. Ce genre de personne a deja access a l'info ca ne change justement rien de ce cote. Y'a simplement les gamins qui effectivement vont un peu jouer c'est le seul parametre qui varie. C'est une faille locale ca limite l'impact. Si j'ai besoin de couler la concurence c'est pas sorcier de trouver quelqu'un avec les competences requises.
> Je ne parlais pas de ça. Quand on découvre une faille critique, on ne publie pas un exploit sur un site d'information, mais une note expliquant la nature du bug au développeur .
Encore une fois ca ne change rien hormis pour les gamins. Si dans ton adviso tu indiques le code fautif et le parametre fautif c'est qu'une question d'heures pour produire le code. Un mail a l'equipe interne leur laissant de corriger le problème c'est ideologiquement mieux certe. D'ailleur y'a un security@linux ? Le developpement bazar toussa c'est bien mais si je decouvre une faille j'envois mon message où ?
> Tu dois savoir qu'aucune motivation raisonnable, louable ne pousse des gens à publier des exploits, même pour le bien de la communauté . Et que tout les exploits sans aucune exception, hormis celui la, on les retrouve sur les sites de pirate.
Mdr. Pour les motivations j'en sais rien et je m'en fou, ce n'est pas mon role que d'extrapoler les raisons pour lesquelles quelqu'un publie du code. (regarde le journal en dessous sur le pourquoi du vote blanc, c'est assez difficile de generaliser comme ca). Pour ce qui est des sites diffusants les exploits
http://k-otik.com/exploits/index.php(...)
je suis sur que se sont de mechant pirates terroristes qui se font chier a livrer une information en francais accessible au plus grand nombre.
D'ailleur securityfocus aussi c'est des pirates y'a tout les exploits postés sur bugtraq et vulndev d'archivé !
Essais d'etre credible 5 minutes.
Ici le mec a peu etre pas très bien géré ca arrive c'est pas la fin du monde non plus. Apres concretement, le bug est sur le bugzilla de gcc, un message a ete posté deux jours avant sur lklm (pas d'adresse de secu pour linux a ma connaissance donc le probleme est aussi du cote des devs). Qu'est ce que ca change que le code soit posté sur un site de news ? le code existe et est disponible ca change rien.
Non le "pirate" il garde son "exploit" pour lui bien au chaud par ce que c'est plus interessant d'avoir une faille sous la main non connue (toutes les machines sont vulnerables a priori) plutôt que de publier et que ca fasse du bruit donc ton code il vaut plus rien sauf sur les machines non mises a jour.
C'est cette publication du code qui permet de garder la pression sur les developpeurs des produits incriminés pour que ce soit corrigé. C'est bizarre mais souvent quand tu regardes l'historique des failles ca met un mois a etre corrigé quand tu mail en privé mais 4h quand c'est publique... Pourtant la faille n'est pas moins présente et exploitable.
Après si tu preferes qu'une faille reste dans la communauté black hat pendant 1 ans avant d'etre publique plutot que d'avoir une fenetre de 4 jours ou ta machine est vulnerable libre a toi.
Posté par ckyl .
En réponse au journal Format pdb.
Évalué à 4.
Q: How do I generate output for PalmPilot?
A: If you want to support AportisDoc convert your SGML source file to TXT first and convert with a command like: makedoc DOCUMENT.txt DOCUMENT.prc
If you want to support iSilo convert your SGML source file to HTML first and convert with a command like: iSilo386 -y -d0 -Idef DOCUMENT.html DOCUMENT.pdb
Carsten Wartmann pointed me to the following tools, which can convert TXT/HTML files to PalmPilot DOC format: txt2pdbdoc and html2pdbtxt
----------------------
Voila une petite recherche sur google te donne tres rapidement la réponse et des exemples de Makefile pour generer la sortie.
Tu parles certainement de la chose dans laquelle spender à trouvé une faille en 12 heures ? :-)
Bon pour pas trop faire dans la provocation sur le papier RSBAC est très bien, les papers sont pas mal. Il en reste que comme dit spender ce n'est actuellement qu'une boite a outil tout comme MAC si l'on a besoin de developper de son module. Aussi puissant que complexe et donc vecteur de faille que se soit du developpeur ou de l'administrateur (oui je parle entre autre des hiddeux menu de conf d'RSBAC ou il est si facile de se planter).
Après dans la pratique c'est un patch intrusif qui n'a pas été largement relu et audité. Le problème de ce type de patch c'est qu'en voulant augmenter la sécurité ils peuvent très facilement introduire autant de failles qu'ils n'en resolvent (cf systrace). Donc dans la vraie vie c'est pas encore ca comme en temoigne la jolie intervention de spender un patch de sécu dans lequel tu trouves une faille aussi rapidement (l'histoire ne dit pas s'il l'avait sous le coude ou non) c'est assez flippant.
Tant que les solutions de sécurité resterons des patchs externes tout le temps en train de se synchroniser sur l'arbre officiel ca me fera un peu peur. L'approche FreeBSD est beaucoup plus saine de ce côté.
De plus j'attend que tu me presente tes modules RSBAC pour m'empecher de plomber une machine et que je puisse quand meme travailler. C'est sans doute faisable mais je demande a voir :-) Les fonctionalités sont géniales mais peu appliquées et applicables....
> A partir du moment ou le système de gestion des droits refuse les forks,
Tout à fait excuse moi de cette imprécision/faute (cf la suite de mon commentaire).
Le n'importe quoi se rapportait à la remarque sur le 2.6 d'ailleur qui ne change rien par rapport à ce qu'il y avait avant.
Pour te dire à quel point il est difficile d'empecher des DoS locaux (hormis les cas triviaux comme la fork() bombe) FreeBSD n'emet plus d'adviso pour ceux ci. A partir du moment ou tu connais le système et le code qu'il y a derriere tu as presque toujours moyen (en pratique) de trouver comment plomber la machine. Le problème c'est qu'il y a une différence entre ralentir très fortement une machine ou lui faire bouffer de la RAM à gogo par les structures noyaux par exemple et un joli crash sauvage. Le deuxieme étant plus grave.
Effectivement certains système permettent des gestions plus fines, je pense a systrace d'openbsd, cerberNG de FreeBSD (patch non officiel et plutot désuet) ou MAC d'encore FreeBSD ou il est possible de faire plein de choses interessantes.
Pour objrmap (mémoire virtuelle) grosso modo le problème est qu'il y a quelques "foreach(vma)" qui trainent. Hors a chaque mmap() tu cree une VMA... Des trucs comme ca il y en a un peu partout si tu cherches et ca se limite pas si facilement que ca.
N'importe quoi. La mémoire est de taille finie, le CPU a une puissance donnée tu peux faire ce que tu veux ca sera toujours vulnerable. Ce qu'il y a c'est
1/ Ulimit / un module pam qui permettent de limiter le nombre de processus pour un utilisateur/session
2/ Mettre une limite au nombre de processus creables dans le système (FreeBSD par exemple). Et garder les 10 derniers pour que le root puisse se logger et botter le cul au jeuno tout content de sa découverte.
Le 2.6 aussi nouveau et super fort qu'il soit ne changera rien a ce probleme. Dans la serie DoS on a aussi
* Allouer trop de mémoire => SWAP, trashing
* S'amuser a lire le code du noyau trouver tout les algos en O(n) et plus et s'amuser a les appeler de facon pathologique pour ralentir le système le plus possible. objrmap reintroduit un scan des vma et un code de 5 lignes te fait geler la machine assez rapidement. Mais il doit y en avoir plein d'autre.
A partir du moment ou les ressources sont limitées le DoS arrive quand tu demandes plus qu'il n'y a. La seul chose est d'essayer d'empecher un utilisateur de demander trop.
# Yeah !
Posté par ckyl . En réponse au journal DLFPToolbar Reloaded. Évalué à 8.
Nouvelle : 9 secondes
Ca devient pas mal du tout :-) merci bien.
[camino, G3 600, 4.5 de charge]
[^] # Re: Performant ?
Posté par ckyl . En réponse au journal Cours sur IRC.. Évalué à 2.
En gros c'est souvent tres interessant mais aussi contre productif du point de vue temps. Il y a tres peu de questions qui peuvent passer surtout si elles sont pertinentes et interessantes. Car bon même a 100 touches minutes (tres optimiste pour un discours bien tourné) on dit pas grand chose en 5/10 minutes :-p
Dans le genre tres interessant tu as les interview a la kerneltrap mais c'est un autre domaine :-)
# Performant ?
Posté par ckyl . En réponse au journal Cours sur IRC.. Évalué à 6.
Sur IRC tu perds ca. Tu as en plus la lenteur du support, a l'oral tu as une adaptation tres rapide et le "droit" à l'erreur. Si tu te plante, tu reformules la phrase dans le bon sens. À l'ecrit il faut le temps de formuler la phrase dans sa tete, de l'ecrire, qu'elle soit lisible appuyer sur entree. L'interactivité est tres basse et la qualite plus faible qu'un document traditionel béton.
C'est a essayer mais j'ai quelques doutes sur les perfomances.
Un exemple de ce genre de test:
Invité : Rick van Riel
Sujet : Présentation de la MM
http://umeet.uninet.edu/conferencias/27-11-2000/2711.html(...) : log de la conf
http://surriel.com/lectures/mmtour.html(...) : slide accompagnant la conf
[^] # Re: ca abuse quand même
Posté par ckyl . En réponse à la dépêche Appel à l'aide pour la documentation de GTK#. Évalué à 4.
De plus anglais facile ne veut pas dire traduction facile. L'anglais arrive tres bien a faire des phrases tres courtes pour d'écrire les methodes; si tu veux rester synthetique, garder le sens et que ca sonne bien ca prend un certain temps.
(amuse toi a traduire un fichier de 200 lignes et regarde le temps que tu y passes tu risques d'être surpris !)
# Mouai
Posté par ckyl . En réponse au journal Résister sur Linuxfr. Évalué à 9.
Si on regarde tes commentaires (presque tous negatifs :-)
-> deux "pwet"
-> un "."
-> une connerie sur slackware (ca arrive a tout le monde)
-> le troll^wdebut sur les failles de linux 2.4. Tu t'es fais allumer par ce que tu n'avais aucun argumentaire hormis de dire que le mec qui a publié etait un gros connard car il comprometait tes serveurs.
Apres c'est sur on peut appeller a la revolte et jouer son de gaule. Mais post des commentaires intelligents et argumentes tu te feras beaucoup moins allumer...
Depuis la mise en place du nouveau systeme, les threads de controverse (et non troll) se font beaucoup moins moinsser par opinion me semble t-il. Par contre le troll, sterile de mecs qui ne savent pas de quoi ils parlent c'est une autre affaire. Il reste les gens comme 007 qui s'en prennent plein la geule non pas par ce qu'ils disent des conneries mais par ce qu'ils sont un peu fatiguant a la longue (bien que tres interessant souvent).
De plus il ne me semble pas que la foule lapide en ce moment, m'enfin bon. Autrement tu peux aussi faire "comme tout le monde" tu navigues a -42 et tu ne postes pas un 150 iemes journal sur cetaitmieuxavent ou les XPsapue.
[^] # Re: ca abuse quand même
Posté par ckyl . En réponse à la dépêche Appel à l'aide pour la documentation de GTK#. Évalué à 2.
On se demande bien ce que le lien fait la !
[^] # Re: ca abuse quand même
Posté par ckyl . En réponse à la dépêche Appel à l'aide pour la documentation de GTK#. Évalué à 5.
Ce genre de traduction me semble etre une enorme perte de temps. Ca n'apporte pas grand chose pour beaucoup d'efforts.
Il y a des choses bien plus interessante a traduire (par exemple des docs qui se lisent au contraire d'une suite sans fin de methodes qui ne sont qu'un manuel de reference)...
Toutefois si on regarde le premier lien (http://lists.ximian.com/archives/public/gtk-sharp-list/2004-June/00(...) ) il ne semble pas s'agir d'une traduction mais reellement d'ecrire la doc (de plus que la doc soit traduite on s'en fou royalement pour une 1.0 ce n'est pas bloquant)
[^] # Re: t'es sur ??
Posté par ckyl . En réponse au journal Quid du port MacOS X d'OpenOffice ?. Évalué à 2.
Une vraie version OS X ca serait pas plus mal.
[^] # Re: Le patch ne suffit pas
Posté par ckyl . En réponse à la dépêche Vulnérabilité de tous les noyaux 2.4.x / 2.6.x. Évalué à 3.
Le problème c'est que dans les solutions offertes actuellement et accessible par le plus grand nombre tu as le choix entre ne rien permettre a l'utilisateur (restrictions tres forte) ou alors lui permettre le DoS.
# Man :-)
Posté par ckyl . En réponse au journal Pam + permission sur les devices. Évalué à 2.
man console.perms
man pam_console
Après ca depend si ta distrib l'integre de base, autrement tu as a modifier la pile d'authentification de pam en plus pour ajouter le pam_console dedans.
Avec toutes ces infos tu devrais facilement trouver sur google des choses bien plus détaillées si tu en as besoin :p
[^] # Re: Trollons...
Posté par ckyl . En réponse à la dépêche Vulnérabilité de tous les noyaux 2.4.x / 2.6.x. Évalué à 7.
Name: NetBSD kernel swapctl(2) vulnerability
Date: 11 June 2004
CVE candidate: not assigned
Author: Evgeny Demidov
Description:
There exists a integer handling vulnerability in NetBSD swapctl(2) system call. It seems that this vulnerability can not be exploited to gain super-user privilegies, but any local attacker can crash the kernel.
[^] # Re: Bon...
Posté par ckyl . En réponse au journal Présentation du langage NICE. Évalué à 0.
> news de Linux.Dvpz.com comme de la propagande Borlandiste,
Non je vois ca comme un site (enfin un mec) qui se prend pour le centre du monde en croyant que chaque nouveauté de son site interesse tout le monde. Faire 3 journaux de suite pour 3 docs comme tu le fais, c'est déjà pas dans les bonnes manières. Mais si en plus ces journaux signalent des "critiques" de livre qui n'apportent rien, qui font 10 lignes... Le seul interet que je vois la dedans c'est ton lien vers amazon qui doit être remuneré non ? (ce qui ne change pas grand chose au probleme d'ailleur)
[^] # Re: Bravo linux ...
Posté par ckyl . En réponse au journal faille dans les linux 2.4.2x et 2.6.x. Évalué à 2.
FreeBSD : possibilité de modifier les tables de routage depuis une jail()
NetBSD : There exists a integer handling vulnerability in NetBSD swapctl(2) system call. It seems that this vulnerability can not be exploited to gain super-user privilegies, but any local attacker can crash the kernel. The vulnerability has been discovered several months ago by Evgeny Demidov during NetBSD kernel source code au dit. It has been made availabe to VulnDisco clients two months ago.
IRIX : that under certain conditions non privileged users can use the syssgi system call SGI_IOPROBE to read and write kernel memory which can be used to obtain root user privileges.
Two local DoS fixes are also addressed in these patches
# Herlok Shom
Posté par ckyl . En réponse au journal Viendez sur mon site !. Évalué à 2.
C'est bizarre les articles me font penser à cet autre site:
http://sidenux.ath.cx/?art=13(...)
http://www.stationlinux.org/articles/chroot.php(...)
http://sidenux.ath.cx/?art=8(...)
http://www.stationlinux.org/articles/multihead.php(...)
Salut lucky, ce coup ci c'est un peu mieux hormis le post en trois exemplaires.
# Bon...
Posté par ckyl . En réponse au journal Présentation du langage NICE. Évalué à 0.
https://linuxfr.org/~thetaz/(...)
Ce compte ne sert clairement qu'a faire de la pub donc ca serait bien d'arreter, de le fermer ou de le faire fermer :-)
Merci beaucoup
[^] # Re: J'ai testé...
Posté par ckyl . En réponse au journal faille dans les linux 2.4.2x et 2.6.x. Évalué à 3.
Ca serait rigolo comme warning tiens. Je vais soumettre un patch a gcc :-)
</>
[^] # Re: Bravo linux ...
Posté par ckyl . En réponse au journal faille dans les linux 2.4.2x et 2.6.x. Évalué à 4.
Réalité mon pauvre.
>T'es sérieux ?
Tout en dépendant de la faille (y'en a des bien tordues) à partir du moment ou l'endroit est identifiée et la cause comprise le code n'est qu'une question d'heures ou de jours.
> Ca semble logique, si tu tombes sur une faille dans le kernel linux, t envoies ton rapport à Microsoft.
Tu fais expres de faire le boulet ? Tout les vendeurs ont un security@domaine qui est une adresse privée et seuls les interessées (la team securité) recoivent l'information ca permet justement d'éviter que trop d'info ne se balandent pour indiquer qu'une faille existe avant que ca soit patché. Il me semble que linux ne dispose pas d'une telle adresse; si pour signaler un probleme de sécu tu dois le poster sur lkml ca me parait un peu contradictoire avec ce que tu avances.
> On analyse pas les raisons, on analyse le code justement. Ce code fait crasher linux.
"Tu dois savoir qu'aucune motivation raisonnable, louable ne pousse des gens à publier des exploits" tu appels ca analyser le code ?!? C'est une intepretation des faits d'autruit. Quand le mec a balance le code sur le bugzilla de gcc il n'avait pas forcement compris l'impact a partir de ce moment c'était trop tard. La lecon de l'exploit dans la VM linux n'a pas marqué les esprits apparement. Les "pirates" ne sont pas tous des guignols du dimanche qui vont sur 1337.c0m pour chopper les exploits, y'en a aussi qui codent pour des projets libres, qui suivent les changelogs, les bugzilla, qui lisent du code.
> Non, il a juste rendu publique une faille de sécurité, ainsi que le programme rendant vulnérable la quasi totalité du parc informatique LINUX x86.
C'est un fait.
> Ton indifférence est compréhensible, car tu n'as pas de connaissances suffisantes en matière de développement ou d'administration système .
Mouhaha je l'a bookmark celle la :-)
Ce n'est pas de l'indifference, c'est qu'a partir d'un moment tu es conscient que les failles n'existent pas qu'a partir du moment ou ./ en a parlé. Des failles noyaux y'en a une trippotée non divulgée ca en a toujours été ainsi. Tu as le choix entre un truc inconnu possedé par peu de personnes ou quelques chose de très répendu qui sera vite corrigé. Si ton entreprise est sensible je prefere de tres loin la seconde solution. Si tu es qu'une societe X ou Y alors effectivement il y a plus de risques de casse dans le second cas. C'est une faille locale, a partir du moment ou tu laisses quelqu'un faire un exec() il doit y avoir un minimum de confiance et de controle. L'utilisateur doit savoir qu'il sera puni en cas d'abus les autres ne devraient pas acceder a la machine.
"Ensuite une dizaine de petits malins de votre boite se sont empressés de faire sauter les serveurs ."
Faute grave, licenciement, tribunal (godfrain/LSI). Tes employes peuvent foutre le feux aux locaux, ou voler le matos informatique. Ils ne le font pas soit pas ce que ce ne sont pas des crétins soit par ce qu'ils en connaissent les conséquences. En informatique il en va de même.
Ce n'est ni la premiere ni la derniere faille, il y en aura toujours certaines publiques, certaines privees les conséquences variant selon la sensibilité de ce à quoi sert le parc. Si tu n'arrives pas a dormir avec cette idée et cette gestion du risque change de métier. Je te signal qu'au moins 3 codes pour l'exploit de la VM ont été publiés très rapidement et qu'au moins un était fonctionel presque tel quel...
[^] # Re: Bravo linux ...
Posté par ckyl . En réponse au journal faille dans les linux 2.4.2x et 2.6.x. Évalué à 10.
C'est quoi le rapport avec la tambouille ? Tu crois que le maichant pirate payer par la maichante concurence attend que l'exploit soit publique pour aller le chercher sur /. ? C'est bizare mais j'ai un doute. Ce genre de personne a deja access a l'info ca ne change justement rien de ce cote. Y'a simplement les gamins qui effectivement vont un peu jouer c'est le seul parametre qui varie. C'est une faille locale ca limite l'impact. Si j'ai besoin de couler la concurence c'est pas sorcier de trouver quelqu'un avec les competences requises.
> Je ne parlais pas de ça. Quand on découvre une faille critique, on ne publie pas un exploit sur un site d'information, mais une note expliquant la nature du bug au développeur .
Encore une fois ca ne change rien hormis pour les gamins. Si dans ton adviso tu indiques le code fautif et le parametre fautif c'est qu'une question d'heures pour produire le code. Un mail a l'equipe interne leur laissant de corriger le problème c'est ideologiquement mieux certe. D'ailleur y'a un security@linux ? Le developpement bazar toussa c'est bien mais si je decouvre une faille j'envois mon message où ?
> Tu dois savoir qu'aucune motivation raisonnable, louable ne pousse des gens à publier des exploits, même pour le bien de la communauté . Et que tout les exploits sans aucune exception, hormis celui la, on les retrouve sur les sites de pirate.
Mdr. Pour les motivations j'en sais rien et je m'en fou, ce n'est pas mon role que d'extrapoler les raisons pour lesquelles quelqu'un publie du code. (regarde le journal en dessous sur le pourquoi du vote blanc, c'est assez difficile de generaliser comme ca). Pour ce qui est des sites diffusants les exploits
http://k-otik.com/exploits/index.php(...)
je suis sur que se sont de mechant pirates terroristes qui se font chier a livrer une information en francais accessible au plus grand nombre.
D'ailleur securityfocus aussi c'est des pirates y'a tout les exploits postés sur bugtraq et vulndev d'archivé !
Essais d'etre credible 5 minutes.
Ici le mec a peu etre pas très bien géré ca arrive c'est pas la fin du monde non plus. Apres concretement, le bug est sur le bugzilla de gcc, un message a ete posté deux jours avant sur lklm (pas d'adresse de secu pour linux a ma connaissance donc le probleme est aussi du cote des devs). Qu'est ce que ca change que le code soit posté sur un site de news ? le code existe et est disponible ca change rien.
[^] # Re: Bravo linux ...
Posté par ckyl . En réponse au journal faille dans les linux 2.4.2x et 2.6.x. Évalué à 10.
C'est cette publication du code qui permet de garder la pression sur les developpeurs des produits incriminés pour que ce soit corrigé. C'est bizarre mais souvent quand tu regardes l'historique des failles ca met un mois a etre corrigé quand tu mail en privé mais 4h quand c'est publique... Pourtant la faille n'est pas moins présente et exploitable.
Après si tu preferes qu'une faille reste dans la communauté black hat pendant 1 ans avant d'etre publique plutot que d'avoir une fenetre de 4 jours ou ta machine est vulnerable libre a toi.
# Deja fait
Posté par ckyl . En réponse au journal Déguisements GNU et Tux ?. Évalué à 5.
De mémoire c'etait un certain L.T. dans le manchot mais il semble pas.
# FAQ Docbook
Posté par ckyl . En réponse au journal Format pdb. Évalué à 4.
A: If you want to support AportisDoc convert your SGML source file to TXT first and convert with a command like: makedoc DOCUMENT.txt DOCUMENT.prc
If you want to support iSilo convert your SGML source file to HTML first and convert with a command like: iSilo386 -y -d0 -Idef DOCUMENT.html DOCUMENT.pdb
Carsten Wartmann pointed me to the following tools, which can convert TXT/HTML files to PalmPilot DOC format: txt2pdbdoc and html2pdbtxt
----------------------
Voila une petite recherche sur google te donne tres rapidement la réponse et des exemples de Makefile pour generer la sortie.
[^] # Re: Oui...
Posté par ckyl . En réponse au journal Crashez votre noyau.... Évalué à 5.
Bon pour pas trop faire dans la provocation sur le papier RSBAC est très bien, les papers sont pas mal. Il en reste que comme dit spender ce n'est actuellement qu'une boite a outil tout comme MAC si l'on a besoin de developper de son module. Aussi puissant que complexe et donc vecteur de faille que se soit du developpeur ou de l'administrateur (oui je parle entre autre des hiddeux menu de conf d'RSBAC ou il est si facile de se planter).
Après dans la pratique c'est un patch intrusif qui n'a pas été largement relu et audité. Le problème de ce type de patch c'est qu'en voulant augmenter la sécurité ils peuvent très facilement introduire autant de failles qu'ils n'en resolvent (cf systrace). Donc dans la vraie vie c'est pas encore ca comme en temoigne la jolie intervention de spender un patch de sécu dans lequel tu trouves une faille aussi rapidement (l'histoire ne dit pas s'il l'avait sous le coude ou non) c'est assez flippant.
Tant que les solutions de sécurité resterons des patchs externes tout le temps en train de se synchroniser sur l'arbre officiel ca me fera un peu peur. L'approche FreeBSD est beaucoup plus saine de ce côté.
De plus j'attend que tu me presente tes modules RSBAC pour m'empecher de plomber une machine et que je puisse quand meme travailler. C'est sans doute faisable mais je demande a voir :-) Les fonctionalités sont géniales mais peu appliquées et applicables....
[^] # Re: Oui...
Posté par ckyl . En réponse au journal Crashez votre noyau.... Évalué à 6.
Tout à fait excuse moi de cette imprécision/faute (cf la suite de mon commentaire).
Le n'importe quoi se rapportait à la remarque sur le 2.6 d'ailleur qui ne change rien par rapport à ce qu'il y avait avant.
Pour te dire à quel point il est difficile d'empecher des DoS locaux (hormis les cas triviaux comme la fork() bombe) FreeBSD n'emet plus d'adviso pour ceux ci. A partir du moment ou tu connais le système et le code qu'il y a derriere tu as presque toujours moyen (en pratique) de trouver comment plomber la machine. Le problème c'est qu'il y a une différence entre ralentir très fortement une machine ou lui faire bouffer de la RAM à gogo par les structures noyaux par exemple et un joli crash sauvage. Le deuxieme étant plus grave.
Effectivement certains système permettent des gestions plus fines, je pense a systrace d'openbsd, cerberNG de FreeBSD (patch non officiel et plutot désuet) ou MAC d'encore FreeBSD ou il est possible de faire plein de choses interessantes.
Pour objrmap (mémoire virtuelle) grosso modo le problème est qu'il y a quelques "foreach(vma)" qui trainent. Hors a chaque mmap() tu cree une VMA... Des trucs comme ca il y en a un peu partout si tu cherches et ca se limite pas si facilement que ca.
[^] # Re: Avant ca..
Posté par ckyl . En réponse au journal CSS Linux Garden. Évalué à 3.
http://euterpe.unice.fr/~mathieuc/desktop.png(...)
Serieusement y'aurait pas un chtit chtit problème ? par ce que c'est pas tres tres accessible la !
(avec le fond noir c'est encore plus joli !)
[^] # Re: Oui...
Posté par ckyl . En réponse au journal Crashez votre noyau.... Évalué à 7.
N'importe quoi. La mémoire est de taille finie, le CPU a une puissance donnée tu peux faire ce que tu veux ca sera toujours vulnerable. Ce qu'il y a c'est
1/ Ulimit / un module pam qui permettent de limiter le nombre de processus pour un utilisateur/session
2/ Mettre une limite au nombre de processus creables dans le système (FreeBSD par exemple). Et garder les 10 derniers pour que le root puisse se logger et botter le cul au jeuno tout content de sa découverte.
Le 2.6 aussi nouveau et super fort qu'il soit ne changera rien a ce probleme. Dans la serie DoS on a aussi
* Allouer trop de mémoire => SWAP, trashing
* S'amuser a lire le code du noyau trouver tout les algos en O(n) et plus et s'amuser a les appeler de facon pathologique pour ralentir le système le plus possible. objrmap reintroduit un scan des vma et un code de 5 lignes te fait geler la machine assez rapidement. Mais il doit y en avoir plein d'autre.
A partir du moment ou les ressources sont limitées le DoS arrive quand tu demandes plus qu'il n'y a. La seul chose est d'essayer d'empecher un utilisateur de demander trop.