ouah a écrit 152 commentaires

nan c'est "Au temps en emporte le vent"

Vu que généralement avec ce genre de sujets on va vite gloser sur les vulnérabilités d'Internet Explorer et défendre le modèle de sécurité supérieur de Linux, je vous laisse apprécier la petite histoire de Brad Spengler (mainteneur de grsecurity) postée sur bt. A mon avis cela montre deux choses: il n'y a pas vraiment de prise de conscience sécurité dans le noyau Linux. Et ensuite que le modèle "bazar" de Torvalds - "distribuez vite et souvent " , je cite Eric S. Raymond - ne convient pas trop à des kernels sécurisés à leur sortie (je parle bien des toutes dernières versions du noyau).

Let me begin by giving you a timeline:

December 15th: I send Linus a mail with a subject line of
"RLIMIT_MEMLOCK bypass with locked stack" December 27th: The PaX team sends Linus a mail with a subject line of "2.6.9+ mlockall/expand_down DoS by unprivileged users" January 2nd: The PaX team resends the previous mail to Linux and Andrew Morton

Between December 15th and today, Linus has committed many changes to the kernel. Between January 2nd and today, Andrew Morton has committed several changes to the kernel. 3 weeks is a sufficient amount of time to be able to expect even a reply about a given vulnerability. A patch for the vulnerability was attached to the mails, and in the PaX team's mails, a working exploit as well. Private notification of vulnerabilities is a privilege, and when that privilege is abused by not responding promptly, it deserves to be revoked.

Using 'advanced static analysis': "cd drivers; grep copy_from_user -r ./* | grep -v sizeof", I discovered 4 exploitable vulnerabilities in a matter of 15 minutes. More vulnerabilities were found in 2.6 than in 2.4. It's a pretty sad state of affairs for Linux security when someone can find 4 exploitable vulnerabilities in a matter of minutes. Since there was no point in sending more vulnerability reports when the first hadn't even been responded to, I'm including all four of them in this mail, as
well as a POC for the poolsize bug. The other bugs can have POCs written for just as trivially. The poolsize bug requires uid 0, but not any root capabilities. The scsi and serial bugs depend on the permissions of their respective devices, and thus can possibly be exploited as non-root. The scsi bug in particular has a couple different attack vectors that I haven't even bothered to investigate. Some of these bugs have gone unfixed for several years.
The PaX team discovered the mlockall DoS. It has been fixed in PaX for 2 years. I have attached their mail and exploit code.

I'd really like to know what's being done about this pitiful trend of Linux security, where it's 10x as easy to find a vulnerability in the kernel than it is in any app on the system, where isec releases at least one critical vulnerability for each kernel version. I don't see that the 2.6 development model is doing anything to help this (as the spectrum of these vulnerabilities demonstrate), by throwing experimental code into the kernel and claiming it to be "stable". Hopefully now these vulnerabilities will be fixed in a timely manner.

C'est vrai mais l'interview est beaucoup plus intéressante que celle de Linus qui elle était complètement superficielle.

Personnellement je ne suis pas fan de Stallman mais pourtant j'ai trouvé ses réponses plutôt cohérentes et bien construites contrairement aux réponses creuses et parfois vraiment moqueuses du Torvalds de la dernière interview.

Enfin :

"Since we now have a free kernel that works, namely Linux, it's no longer essential to develop the Hurd". J'imagine que les développeurs de Hurd apprécieront.

> Pour le user-space, on verra après.

Il n'est pas question de user-space. Quand tgl parle de "entièrement" kernel-space, il fait la distinction entre un driver qui modifie les sources du kernel (ajout du hook) pour passer la main au code du module et le driver classique avec un module sans modifier les sources existantes du kernel.

Maintenant à ce que je me rappelle et vu qu'il y a une partie propriétaire dans le driver, il n'est pas certain que le mainteneur puisse faire autrement que de proposer une modif des srcs du noyau. Auquel cas, le driver serait continué à être maintenu mais pas intégré dans le kernel officiel (pour les raisons précédemment invoquées dans la lkml).

pour les photons mal placés, se référer à MISC 12 sur la crypto quantique

Parinux organise la première Trouduc Party?

c'est bon, c'est bon, je ->[]

> D'ailleurs c'est amusant, chez d'autres OS propriétaires il y a
> plusieurs vulnérabilités par an qui donne un root access, sous
> linux c'est quand même pas si souvent (le bug ptrace est déjà > vieux... date des alentours du 2.4.20 IIRC).


c'est beau de rêver.

Si on prend seulement les adviso de isec.pl durant la période janvier à avril de cette années, on a arrive à 4 local root sur le kernel Linux. C'est peu glorieux et aucun autre kernel n'a eu un aussi piètre palmarès durant la même période.

A décharge de Linux toutefois, si les autres OS profitaient de la même attention des hackers, il y aurait certainement autant de bug de sécurité de leur côté.

cyberféministes? guh

> Sauf qu'entre ce qu'on réussit a faire en labo et ce qu'il est possible de faire dnas la vraie vie, il y a parfois
> qq différences.
>
> La crypto quantique en fait partie, tout comme la téléportation.

Concernant la crypto quantique, tout t'abord. L'article que djrom donne montre le contraire. Faire une expérience entre deux villes suisse distantes de 67 km (avec les fibres télécom d'un opérateur téléphonique suisse), c'est justement montrer que la crypto quantique sort des laboratoires. Depuis cet article de début de 2002, de l'eau a encore coulé sous les ponts. La création de deux sociétés (id Quantique et MagiQ) dont le but est la vente de système de cryptographie quantique ainsi qu'une récente expérience d'un groupe de recherche de Vienne qui en collaboration avec une banque de la place a effectué des opérations bancaires sécurisées par la crypto quantique semblent aller dans ce sens.

> On sait téléporter en labo un photon d'un endroit a un autre. Le «record» est d'un dixaine de km a
> l'heure actuelle.
>
> Mais on ne saura jamais aller plus loin, pour la simple raison que l'énergie nécessaire pour téléporter un
> photon n'est pas tres grande, mais si on veut teleporter un objet massif, c'est tt de suite plus difficile.
>
> ALors on peut croire au pere noel, mais ça ne fait pas avancer beaucoup les choses.

Il ne faut pas tout confondre. La téléportation quantique ne téléporte pas l'objet lui-même (un photon) mais bien un état quantique de celui-ci (c'est-à-dire une de ses caractéristiques). Il ne s'agit donc pas encore de téléporter les particules elle-mêmes et encore moins des obets macroscopiques.


> Le lien vers quantum-ph que tu nous propose est tres bien, mais j'attend de voir l'article RÉELLEMENT
> publié. truc-ph, c'est juste une sorte de dépot(oir) géant pour tous les articles, et rien n'est vérifié.
> Ce n'est donc absolument pas une source fiable d'information

L'article en question a été publié dans New Journal of Physics, 4 (2002) 41.1–41.8.

Depuis environ 5 ans, c'est la mode pour les groupes de recherches de faire de la crypto quantique et il y a beaucoup d'articles régulièrement publiés. Si on excepte les journaux spécialisés "quantiques" comme Quantum Information and Computation, les articles publiés apparaissent massivement dans des revues "plus généralistes" comme Physical Review Letters, Physical Review A ou Nature pour les plus connus.

l'info a été donné en russe parske, en fait, beaucoup de linuxiens d'ici parlent le russe couramment

bon peu de comparaisons avec grsec. Depuis le 2.6.6, la pile est donc non exécutable mais seulement pour les processeurs qui le supportent.

Cela veut donc dire pas pour le x86. De même exit les powerpc, mips, arm etc...

Pour une pile non exec avec Linux et x86, il faut toujours soit PaX soit Openwall.

Bon y a toujours des choses qui sont pas très claires avec la GPL pour moi. Imaginons, je construis un routeur firewall hardware et j'utilise dedans une librairie en GPL.

Aucune modification n'a été apporté à la librairie en GPL, elle est simplement linkée à la compilation. Que dois-je faire?

Bon indiquer que le produit utilise un produit GPL, fournir la source du produit GPL (si elle est pas modifiée fournir la source originale) et quoi d'autres.

Ma grande question c'est:

Dois-je donner les sources de mon programme aussi?
(Si tel est le cas, que se passe-t'il si mon programme (càd mon routeur) est linké aussi avec une autre librairie pas programmée par moi mais en closed source.)

Dans le domaine des fontes, on lui doit surtout la fonte si caractéristique des documents LaTex.

cela me parais bien plus compliqué que ça. nmap n'est pas le seul soft sur les systèmes SCO et divers licenses cotoyent divers softs. SCO peut très violer la license GPL pour certains softs en la modifiant et être en accord pour d'autres où elle est la license est laissé intacte.

Une violation de license s'applique au cas par cas, pour chaque soft GPL inclus. Si la license n'a pas été violé pour nmap, il n'y a aucune base pour l'interdire.

Maintenant si suivant les allégations de SCO, on peut interdire un soft GPL, cela devient dangereux. En effet, une entreprise qui vend un produit contenant un soft en GPL peut se sentir légitiment en danger si elle sait que suivant ses opinions on a le droit de lui interdire la distribution d'un soft GPL.

Ainsi ce genre de propos d'interdiction me semble complètement hors-contexte dans l'affaire nmap et SCO. Si cela n'est pas le cas (et à moins qu'on ait avancé d'autres arguments), la crédibilité de la license GPL en prendrait en coup.

Fyodor stoppe donc le support de nmap sur les OS SCO ce qui est totalement dans son droit.

Par contre, on apprend qu'en vertu de l'article 4 de la GPL, Fyodor interdit la distribution de nmap sur les produits SCO (ce qui le cas actuellement).

L'article 4 stipule in extenso:
"You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance. "

En ce qui concerne nmap, SCO a t'il modifié la license de nmap (et pas du reste)? S'il ne l'a pas fait, je ne vois pas bien ou se situe la violation et dans ce cas, la légitimité d'une telle interdiction par Foyodor.

Concernant Blueberry,

> Bref, les avis sont assez partagés sur ce films, pour ma part, j'ai trouvé pas mal.

soyons francs, la majorité des critiques le jugent infecte

prims!

tiens, mais c'est Dupond et Dupont!

> c est naze y a ni le poulpe ni l'endive.

euh c 'est un animal un poulpe?

> arf, j'y etait y'a 2 ans , et qd il chante tt l'monde est debout, il fait 1 tabac ;)

cette année, c'est possible que ce soit Claude Vorilhon qui le remplace au chant

> Question : à qui reviendrons les sousous gagnés en vendant les timbres électroniques ?

des sousous dans la popoche

grève

justement, c bien pour ça que la news devrait etre en deuxième page: un bug de sécurité dans un logiciel que personne ne sait à quoi il sert et dont 3 gars à peine connaissent l'existence. Si c'était pour faire de la pub au programme, il aurait mieux fallu s'y prendre autrement.

Bon j'ai pas trop lu le truc, mais si j'ai bien suivi: le départ de Keith Packard et son fork de xfree n'étaient-il pas du à des désaccords avec la core team elle-même? Cette dissolution viendrait-elle alors donner raison à Keith Packard face au conflit qui les divisait?

> Sur un forum bien géré tu serais censuré, voir banni.

oui mais là on est pas sur #scientologie, donc on peut s'exprimer. Maintenant au lieu de t'offusquer d'un peu de légèreté, tu peux toujours contre-argumenter sur le fond de mes propos.