Pour les utilisateurs de plateformes non x86, ca sert à rien d'essayer, ca compile pas :
This code only works on x86 Linux machines. This code does not compile (makes no executable) on sparc64 sun4u TI UltraSparc II (BlackBird). This doesn't affect NetBSD Stable.
This code only works on x86 Linux machines.[...] This doesn't affect NetBSD Stable.
Quel est le rapport ? Il dit tout d'abord que ça ne concerne que des machines sous Linux et parle de netbsd par la suite ... moi y en a pas trop comprendre ?
Bof pour win ça se télécharge aussi ce genre d'exploits...
Par contre pour OpenBSD c'est plus rare ce genre de trucs non ?
(Vu qu'ils se targuent d'être les plus sécurisés, y'a bien des raisons, non ?)
A priori c'est un gars qui voulait coder un truc et qu'était pas très doué donc qu'a fait qqchose de pas super propre et de buggé, et manque de bol il s'est bouffé un bug du noyau ;)
J'en avais découvert un une fois par moi meme (un while(fork())) qui est apparament assez connu...
Je trouve étonnant le fait que le code soit diffusé comme ca...
J'espere qu'un patch sera bientot mis à disposition.
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.
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.
A partir du moment ou le système de gestion des droits refuse les forks, ont peut affirmer que le système n'est pas vulnérable.
Sinon, c'est comme dire que tout les systèmes sont vulnérables au rm -Rf /...
Allouer trop de mémoire, ouvrir trop de fichiers, tout ça se limite (/etc/security/limits.conf)... et j'ai cru comprendre que certains systèmes permettaient une gestion encore plus fine des droits (par contre je connais pas objrmap).
> 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.
* Free Open Source (GPL) Linux kernel security extension
* Independent of governments and big companies
* Several well-known and new security models, e.g. MAC, ACL and RC
* Control over individual user and program network accesses
* Any combination of models possible
* Easily extensible: write your own model for runtime registration
* Support for current kernels
* Stable for production use
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....
* Free Open Source (GPL) Linux kernel security extension
* Independent of governments and big companies
* Several well-known and new security models, e.g. MAC, ACL and RC
* Control over individual user and program network accesses
* Any combination of models possible
* Le pierre tramo se nourrit de quarante deux
* Easily extensible: write your own model for runtime registration
* Support for current kernels
En fait... ce qu'il faudrait ça serait un moyen de faire que les ressources utilisées à cause d'appels systèmes soient comptée dans les ressources utilisées par le programe non ? Ça devrait permettre d'appliquer les méthodes quivontbien (kill si plus de 95% de cpu pendant 2 minutes etc) dans les cas qui posent problèmes.
Allez, où qu'il est joe que je code ça lol -_^ (et après, j'irais sur Mars...)
Allouer trop de mémoire, ouvrir trop de fichiers, tout ça se limite (/etc/security/limits.conf)... et j'ai cru comprendre que certains systèmes permettaient une gestion encore plus fine des droits (par contre je connais pas objrmap).
Oui..., sauf que si tu fais un calcul simple limite de processus, limite de memoire par processus, tu te rendra vite compte que limits.conf est completement inefficace....
# Un peu de recherche...
Posté par Mathieu Pillard (site web personnel) . Évalué à 10.
http://marc.theaimsgroup.com/?l=linux-kernel&m=108705064524391&(...) discute des implications dudit fix possible.
# x86 only
Posté par Olivier Grisel (site web personnel) . Évalué à 9.
Y a de l'assembleur dedans.
[^] # Re: x86 only
Posté par x0ra . Évalué à 1.
Quel est le rapport ? Il dit tout d'abord que ça ne concerne que des machines sous Linux et parle de netbsd par la suite ... moi y en a pas trop comprendre ?
[^] # Re: x86 only
Posté par 007 . Évalué à 2.
Ni windows. Super !
[^] # Re: x86 only
Posté par Pinaraf . Évalué à -2.
Par contre pour OpenBSD c'est plus rare ce genre de trucs non ?
(Vu qu'ils se targuent d'être les plus sécurisés, y'a bien des raisons, non ?)
# Re: Crashez votre noyau
Posté par Sten Spårvagnhög (site web personnel) . Évalué à 10.
# Mais comment font-ils ?
Posté par Pinaraf . Évalué à 2.
[^] # Re: Mais comment font-ils ?
Posté par Krunch (site web personnel) . Évalué à 5.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Mais comment font-ils ?
Posté par Christophe Fergeau . Évalué à 8.
# Oui...
Posté par Mr_max . Évalué à -7.
Je trouve étonnant le fait que le code soit diffusé comme ca...
J'espere qu'un patch sera bientot mis à disposition.
[^] # Re: Oui...
Posté par x0ra . Évalué à -1.
[^] # Re: Oui...
Posté par Christophe Fergeau . Évalué à 1.
[^] # Re: Oui...
Posté par ckyl . É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.
[^] # Re: Oui...
Posté par un_brice (site web personnel) . Évalué à 6.
Sinon, c'est comme dire que tout les systèmes sont vulnérables au rm -Rf /...
Allouer trop de mémoire, ouvrir trop de fichiers, tout ça se limite (/etc/security/limits.conf)... et j'ai cru comprendre que certains systèmes permettaient une gestion encore plus fine des droits (par contre je connais pas objrmap).
[^] # Re: Oui...
Posté par Pinaraf . Évalué à 1.
[^] # Re: Oui...
Posté par ckyl . É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: Oui...
Posté par Code34 (site web personnel) . Évalué à 2.
* Independent of governments and big companies
* Several well-known and new security models, e.g. MAC, ACL and RC
* Control over individual user and program network accesses
* Any combination of models possible
* Easily extensible: write your own model for runtime registration
* Support for current kernels
* Stable for production use
http://www.rsbac.org/(...)
http://forums.grsecurity.net/viewtopic.php?t=347&start=0(...)
[^] # Re: Oui...
Posté par ckyl . É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....
[^] # subliminal!
Posté par plagiats . Évalué à -1.
* Independent of governments and big companies
* Several well-known and new security models, e.g. MAC, ACL and RC
* Control over individual user and program network accesses
* Any combination of models possible
* Le pierre tramo se nourrit de quarante deux
* Easily extensible: write your own model for runtime registration
* Support for current kernels
acrostiche ? sens caché? subliminiminiminal ?
[^] # Re: Oui...
Posté par un_brice (site web personnel) . Évalué à 3.
Allez, où qu'il est joe que je code ça lol -_^ (et après, j'irais sur Mars...)
[^] # Re: Oui...
Posté par M . Évalué à 2.
Oui..., sauf que si tu fais un calcul simple limite de processus, limite de memoire par processus, tu te rendra vite compte que limits.conf est completement inefficace....
cf http://linuxfr.org/~mat_/9348.html(...) et notament http://linuxfr.org/comments/346573,1.html(...) pour le calcul...
[^] # Re: Oui...
Posté par un_brice (site web personnel) . Évalué à 2.
[^] # Re: Oui...
Posté par M . Évalué à 2.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.