Brad profite de l'exploit pour dire tout le mal qu'il pense de la gestion de la sécurité dans le noyau Linux (lire notamment tous les commentaires présents dans le fichier exploit.c du tgz). Il reproche notamment la correction silencieuse de failles qui pose problème aux distributions Linux : les mainteneurs ne savent pas quels patchs doivent être backportés dans les branches stables. Il reproche également l'absence d'analyse de l'impact d'un bug en terme de sécurité : certaines failles sont considérées comme non exploitables, alors qu'elles le sont.
La seconde partie de cette dépêche détaille la faille. La faille est intéressante, car en lisant le code source, elle ne semble pas exploitable. En fait, comme le pointeur est déréférencé avant qu'on teste si le pointeur est NULL, gcc supprime le test car il suppose que de toute façon le déréférencement causera une erreur fatale. L'option -fno-delete-null-pointer-checks de gcc permet de désactiver cette optimisation. Extrait du code posant problème :
struct sock *sk = tun->sk;
...
if (!tun) return POLLERR;
L'exploit alloue de la mémoire à l'adresse 0 (NULL) dans l'espace utilisateur où le code de l'exploit sera écrit. Le déréférencement du pointeur NULL ne cause donc pas d'erreur dans le noyau.
En décembre 2008, Julia Lawall avait posté 3 patchs (drm, agnx et go7007) corrigeant des bugs similares. Les patchs ont été générés avec Coccinnelle : outil permettant de patcher les pilotes Linux en utilisant des règles décrites dans un langage haut niveau.
Aller plus loin
- Exploit "cheddar bay" (.tar.gz) (82 clics)
- A new fascinating Linux kernel vulnerability (ISC SANS) (48 clics)
- Article Linux Weekly News (26 clics)
# Kernel 2.6.30
Posté par Kazuya . Évalué à 6.
'[...]car aucune distribution n'utilise cette version pour le moment.'
Et bien moi si (avec la version tildarchée de Gentoo) et il y a également Pardus 2009 qui utilise un kernel 2.6.30 (et peut-être d'autres...).
[^] # Re: Kernel 2.6.30
Posté par zebra3 . Évalué à 3.
Debian Unstable. Même s'il ne s'agit pas vraiment d'une distribution au sens propre (vu qu'il faut passer par une stable qu'on upgrade), elle doit être assez utilisée tout de même.
Article Quarante-Deux : Toute personne dépassant un kilomètre de haut doit quitter le Tribunal. -- Le Roi de Cœur
[^] # Re: Kernel 2.6.30
Posté par Victor STINNER (site web personnel) . Évalué à 5.
J'ai testé l'exploit, mais il ne fonctionne pas sur ma Debian, car il a besoin de Pulse Audio (qui n'est pas installé chez moi). Il semble que l'exploit utilise 3 failles différentes :
* Faille noyau (tun)
* Bug (faille) Pulse Audio
* Bug dans la fonction personality() permettant de contourner la protection "mmap_min_addr" (adresse minimale qui peut être mappée). Par défaut, on n'a pas le droit de mapper une zone mémoire à partir de l'adresse NULL.
[^] # Re: Kernel 2.6.30
Posté par Victor STINNER (site web personnel) . Évalué à 5.
Ce bug a été corrigé le 26 juin dans la version git du noyau Linux :
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6(...)
Petite histoire du bug et de son correctif par Julien Tinnes :
http://blog.cr0.org/2009/06/bypassing-linux-null-pointer.htm(...)
[^] # Re: Kernel 2.6.30
Posté par Axel . Évalué à 2.
Je ne sais pas s'il faut qualifier cela de bug ou de faille, en fait l'exploit profite d'une fonctionnalité de pulseaudio : charger des modules binaires quelconques.
[^] # Re: Kernel 2.6.30
Posté par jeberger (site web personnel) . Évalué à 5.
[^] # Re: Kernel 2.6.30
Posté par steph1978 . Évalué à 1.
- sidux 2009-02
- ExTiX 7.0
- Frugalware Linux 1.1 Pre 2
- Pardus Linux 2009 RC (passé depuis en 2.6.30.1 dans la final)
- openSUSE 11.2 Milestone 3
- Ubuntu 9.10 Alpha 2
bon, ok, peu de versions finales de distributions majeures, mais quand même, cette version du noyau a été diffusée.
[^] # Re: Kernel 2.6.30
Posté par Nicolas SUFFYS . Évalué à 1.
On a aussi SabayonLinux 4.2 qui utilise ce noyau ^^
Pourquoi créer un noyau pour qu'il ne soit pas utiliser sinon ?!?
# ArchLinux
Posté par Martin Peres (site web personnel) . Évalué à 4.
[^] # Re: ArchLinux
Posté par Sylvain Blandel . Évalué à 1.
Au 18 juillet 2009, la version stable du noyau d'Archlinux est la 2.6.30.1-1.
La faille y est-elle corrigée ?
[^] # Re: ArchLinux
Posté par windu.2b . Évalué à 4.
yaourt -Si core/kernel26
Repository : core
Name : kernel26
Version : 2.6.30.1-1
[...]
Packager : Allan McRae <allan@archlinux.org>
Architecture : i686
Build Date : sam. 04 juil. 2009 13:18:23 CEST
MD5 Sum : 0ee6fdabf3f7a2c3be64f4cb5574975c
Description : The Linux Kernel and modules
[^] # Re: ArchLinux
Posté par windu.2b . Évalué à 4.
yaourt -Si testing/kernel26
Repository : testing
Name : kernel26
Version : 2.6.30.2-1
[...]
Packager : Tobias Powalowski <tpowa@archlinux.org>
Architecture : i686
Build Date : lun. 20 juil. 2009 13:24:01 CEST
MD5 Sum : 471b257bb598a00049a228ad4afc7747
Description : The Linux Kernel and modules
[^] # Re: ArchLinux
Posté par DitOuQueMon . Évalué à 1.
# Quelques commentaires
Posté par patrick_g (site web personnel) . Évalué à 10.
Brad a toujours été hyper-critique sur la sécurité du noyau Linux. Il faut bien voir que son gagne pain c'est grsecurity c'est à dire un patch de sécurité à appliquer sur le noyau vanilla. Il a donc tout intérêt à dénigrer le noyau normal afin de souligner la plus-value de son patch.
Donc il faut prendre ce qu'il dit avec un gros grain de sel.
Néanmoins on est forcé de constater que ses déclarations ont plus de force quand elles sont accompagnés d'un exploit 0-day qui passe à travers SELinux ;-)
Il faut vraiment lire tout le blabla qu'il a mis en commentaire du fichier exploit.c car c'est très instructif sur le coté technique de la faille mais aussi sur le personnage qu'est Brad.
Ce qui m'a étonné c'est qu'il colle des extraits de mails issus de la liste de diffusion vendor-sec.
Cette liste est faite pour que des informations circulent entre les développeurs et les entreprises du libre au sujet des problèmes de sécurité. Bien entendu la liste est privée et dévoiler ainsi des mails privés comme le fait Brad est plus qu'impoli. Je me demande même si ce n'est pas illégal.
Il faut savoir que Brad avait commencé par poster des vidéos de son exploit à l'oeuvre mais sans donner de détails techniques. Dans les commentaires d'exploit.c il se délecte de lire les échanges de mails sur vendor-sec (en ne donnant pas le nom du type qui lui a fourni les mails) ou les gens essayent, en ayant la vidéo pour seule information, de comprendre d'ou peut bien venir la faille.
Il distribue les bons points et les mauvais points en fonction des analyses proposés, il casse du sucre sur le dos de Linus Torvalds, qualifié d'expert sécurité en fauteuil (arm-chair security expert) et enfin il balance un paragraphe final sur la sécurité du noyau qui serait déplorable.
Ci-dessous je traduis l'ironique paragraphe d'introduction et le paragraphe final (je refuse de traduire les mail privés de vendor-sec).
"Un mec monté sur son cheval m'a apporté ces informations : toutes mes félicitations aux membres de vendor-sec pour leur excellente analyse de la vidéo de mon exploit, dans la même veine que leurs analyses des vulnérabilités du noyau. Regardez les maitres à l'oeuvre".
"Aux membres de vendor-sec : Même si vous ne me remercierez jamais (ou sgrakkyu ou Julien) vous êtes les bienvenus pour toute cette recherche gratuite dans le domaine de la sécurité qui aurait aussi bien pu être vendue dans le privé à la place. L'industrie (NdT : le marché des exploits) n'est plus ce qu'elle était en 2000, les gens ne publient plus les exploits maintenant : ils font du fric avec.
Ne pas voir débouler des exploits ne signifie donc pas que vous faites du bon travail. Avez-vous noté les exploits très complexes qui apparaissent impossiblement rapidement juste après qu'une faille soit finalement patchée ? Il y a une raison pour ça.
Si le code vulnérable avait été incorporé dans le 2.6.29 au lieu de l'être dans le 2.6.30 je n'aurai pas publié mon exploit. Je n'ai pas l'utilité de cet exploit...mais une bonne poilade ne se refuse jamais.
- Ma suggestion est que vous engagiez des gars comme sgrakkyus ou Julien plutôt que ces vieux qui n'ont jamais écrit un exploit de toute leur vie. A part Stealth je ne connais personne de doué dans cette industrie et qui soit employé par vous.
- Deuxième suggestion : Comme vous êtes des compagnies qui poussent l'open source et le logiciel libre ce serait bien si les justifications pour vos classifications de vulnérabilités étaient plus transparentes (ou même qu'elle soient publiées tout simplement). La vieille habitude que vous avez de classifier toute faille pour laquelle un exploit n'a pas été écrit en Denial of Service devient très fatigante et ne trompe plus personne.
- Troisièmement, la politique officielle qui consiste à ne pas mentionner les informations qui concernent la sécurité lors des modifications du code de Linux est une honte et un mauvais service que vous rendez à vous même, aux autres vendeurs et à vos clients. Cela démontre un manque d'intégrité et de confiance dans vos propres produits. Je sais que vous n'avez aucune intention de changer cette politique puisque vous profitez grâce à celle-ci d'une réputation de sécurité indue et qui ne se base pas sur la réalité. Dire la vérité sur les vulnérabilités de vos logiciels ternirait votre image et ce n'est pas bon pour le business. Vous êtes félicités quand vous dissimulez des choses et pourtant c'est Microsoft qui à une mauvaise réputation.
Si vous suivez les conseils que je vous donne alors peut-être que votre sécurité ne sera plus la risée de toute l'industrie".
A noter, pour répondre à une partie des critiques de Brad, que les mainteneurs des versions stables des noyaux se refusent à classer les corrections de bugs en fonction de critères de sécurité car pour eux il n'est pas possible de savoir à l'avance toutes les implications en matière de faille d'un bug donné.
Brad affirme que cette politique de non classification empêche les gens de faire des choix quand aux corrections à appliquer et les mainteneurs lui répondent qu'il n'y a pas de choix à faire et qu'il faut de toute façon appliquer toutes les corrections.
Bien malin celui qui peut dire qui a raison et qui a tort dans cette controverse, si les développeurs du noyau sont suffisamment attentifs aux problèmes de sécurité ou pas, si la réputation de Linux est vraiment surfaite ou si Brad exagère afin de pousser sa solution.
Les pauvres péons que nous sommes sont bien en peine de trier et d'évaluer vraiment les affirmations des uns et des autres...mais en tout cas la controverse est lancée et la situation ne peut que s'améliorer.
[^] # Re: Quelques commentaires
Posté par Victor STINNER (site web personnel) . Évalué à 6.
[^] # Re: Quelques commentaires
Posté par patrick_g (site web personnel) . Évalué à 9.
D'après les commentaires présents dans son code il n'a pas besoin de PulseAudio ou de quoi que ce soit :
"SELinux lets any user in unconfined_t map at 0, overriding the mmap_min_addr restriction! pulseaudio is not needed at all! Having SELinux enabled actually *WEAKENS* system security for these kinds of exploits!".
Quand au ton utilisé par Brad c'est clair qu'il est particulièrement exaspérant. Avec lui on a toujours le sentiment qu'il est l'être le plus intelligent sur cette planète et que tous les autres ne sont que de sombres abrutis et qu'ils devraient l'écouter comme le messie.
Mais bon comme le dit l'un des intervenants sur l'article de LWN : "Personally I don't give a shit how angry or insane he may appear to be. He did a good job finding the exploit and did a good thing being public about it.".
[^] # Re: Quelques commentaires
Posté par psychoslave__ (site web personnel) . Évalué à 8.
Je crois que lister les développeurs noyau dont la prose n'est pas du même style irait plus vite que l'opération inverse. :P
[^] # Re: Quelques commentaires
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
[^] # Re: Quelques commentaires
Posté par patrick_g (site web personnel) . Évalué à 1.
[^] # Re: Quelques commentaires
Posté par Maclag . Évalué à 5.
RAAAAH, un vendredi stratosphérique en perspective!
[^] # Re: Quelques commentaires
Posté par herodiade . Évalué à 5.
http://archives.neohapsis.com/archives/openbsd/2003-04/1678.(...)
Tout le thread (avec des « Yup, it is incredible. Liar liar, pants on fire. ») :
http://archives.neohapsis.com/archives/openbsd/2003-04/threa(...)
[^] # Re: Quelques commentaires
Posté par patrick_g (site web personnel) . Évalué à 3.
[^] # Re: Quelques commentaires
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 10.
Ce que je vois, c'est que Brad parle beaucoup, mais peut se le permettre car
1/ Il abat de la besogne autant que les autres
2/ Il donne des résultats
3/ Ses idées ne peuvent pas faire de mal : soutenir les pros (les engager, les financer) et avoir une politique morale…
Par ailleurs, tous ces gens qui codent du GPL se font des échanges *secrets* qui concernent le code. Certes, la "sécurité" peut justifier ça, mais je crois qu'il y a bien une cabale qui se fout du libre et qui veut juste pas perdre trop de fric. Je crois ainsi que Brad veut une économie et une politique responsables en matière de sécurité qui concerne autant l'industrie derrière linux que les "petits" utilisateurs qui ont autant le droit d'être correctement informés.
[^] # légal/illégal
Posté par Zenitram (site web personnel) . Évalué à 4.
Je ne connais pas la loi US, mais pour ce qui est de la loi française (merci Eolas, mais je n'ai plus le lien sur l'article précis), par défaut tu peux divulguer toute correspondance que tu veux du moment où elle t'était destinée (ça enlève du cadre la réception par erreur ou le piratage).
Après, si ils ont signé un NDA, c'est une autre histoire et c'est le non respect du NDA qui va jouer, pas le secret de la correspondance.
Bien malin celui qui peut dire qui a raison et qui a tort dans cette controverse,
Oh que oui... Chacun a des arguments qui se tiennent (la forme? Certes, mais il y a l'exploit, bien documenté, une bonne preuve), il n'y a pas d'un côté les gentils et de l'autre les méchants!
[^] # Re: légal/illégal
Posté par Guillaume Chanaud (site web personnel) . Évalué à 1.
Je ne vais pas dire que j'ai 100% raison, car je n'ai pas connaissances des textes de lois exacts, mais j'en suis plus que quasi certain.
Les divers articles qui en parlent sur Internet me confortent d'ailleurs dans cette position.
[^] # Re: légal/illégal
Posté par Zenitram (site web personnel) . Évalué à 10.
non, et re-non.
Puisque tu m'obliges à rechercher...
http://www.maitre-eolas.fr/post/2009/05/11/1406-pour-la-lett(...)
"Quand vous envoyez un courrier, qu'il soit épistolaire ou électronique, il cesse de vous appartenir et n'est protégé que pendant son acheminement vers son destinataire. Au-delà, son destinataire en devient le propriétaire et en fait ce qu'il veut, sauf si le courrier contient des éléments relatifs à votre vie privée, dont la divulgation est dès lors prohibée (art. 9 du code civil), ou que son destinataire est tenu au secret professionnel (comme un avocat). Et une prise de position politique d'un citoyen adressée à son ministre ne relève pas de la vie privée."
mais j'en suis plus que quasi certain
Tu l'es toujours maintenant? ;-)
Conclusion : arrêter de croire toutes les sottises qu'on trouve sur le net... (J'ai plus confiance en Maitre Eolas, avocat de profession, que tous les beaux parleurs sur le net)
[^] # Re: légal/illégal
Posté par patrick_g (site web personnel) . Évalué à 2.
Il n'est pas membre de la liste vendor-sec donc aucun de ces mails ne lui était adressé donc il n'avait pas le droit (toujours selon la loi française) de les publier.
[^] # Re: légal/illégal
Posté par Zenitram (site web personnel) . Évalué à 6.
Dans ce cas, oui c'est illégal si un membre de la liste ne lui a pas transféré les mails (car la, vu qu'un membre a transféré, il devient lecteur légitime de la correspondance, et peut donc en faire ce qu'il veut, comme les publier) (toujours selon la loi française).
Comment a-t-il eu les messages?
Car j'ai plus de doutes que toi sur l'illégalité que tu veux lui donner, du moins à la vue de la loi française.
[^] # Re: légal/illégal
Posté par patrick_g (site web personnel) . Évalué à 5.
Dans les commentaires de exploit.c il explique comment il est rentré en possession de ces mails...mais on ne peut pas dire que ce soit d'une précision absolue ;-)
"A man riding on horseback has delivered some news"
[^] # Re: légal/illégal
Posté par Zenitram (site web personnel) . Évalué à 2.
Sans cette information, tu ne peux pas dire que c'est illégal (ce que tu n'as effectivement pas dit ;-), tu t'es juste demandé), et je ne peux pas affirmer que c'est légal non plus (n'ayant pas une preuve que le mail lui a été passé volontaire).
Donc je ne peux que supputer : il y a de fortes chances qu'il ne soit pas l'illégalité au vue de la loi française, sinon ça signifierait de manière certaine que la liste vendor-sec a un gros trop de sécurité (piratable), et ça craindrait un peu beaucoup!
[^] # Re: légal/illégal
Posté par Stephane COLIN (site web personnel) . Évalué à 6.
Le messager du Poney Express — Eh, les pédés il y a une lettre pour vous ! Tenez. Bonne bourre !
Hugues — Pauvre con, va !
LA CLASSE AMÉRICAINE ...
[^] # Re: légal/illégal
Posté par ZeroHeure . Évalué à 4.
"La liberté est à l'homme ce que les ailes sont à l'oiseau" Jean-Pierre Rosnay
[^] # Re: légal/illégal
Posté par liberforce (site web personnel) . Évalué à 4.
[^] # Re: légal/illégal
Posté par croux . Évalué à 0.
* Comme le rappelle Me Eolas, si cette correspondance contient des éléments relatifs à la vie privée de l'expéditeur, le destinataire ne devient pas propriétaire du message et ne peut donc pas en disposer publiquement comme bon lui semble. Et c'est bien le cas en l'espèce puisque le mail contient dans ses entêtes le nom de l'expéditeur mais aussi l'adresse IP (le plus souvent personnelle) d'où a été envoyé le message.
* Me Eolas ne s'est basé que sur le code civil pour fournir sa réponse. Cependant on peut aussi se référer au code de la propriété intellectuelle, et considérer qu'en tant qu'oeuvre de l'esprit un mail bénéficie de sa protection. Il ne peut donc être diffusé publiquement sans le consentement de l'auteur.
[^] # Re: légal/illégal
Posté par Zenitram (site web personnel) . Évalué à 0.
Brad Spengler n'a pas divulgué les en-têtes. Quand au nom de l'expéditeur, cela n'appartient pas à la vie privée (ton nom est partout!).
Je t'invite à lire le post d'Eolas que j'ai pointé, à aucun moment il n'a été jugé illégal que le nom de la personne critiquant HADOPI arrive chez le chef de celui-ci en passant par parlementaire puis gouvernement : c'était dégueulasse, mais légal, et il n'y a pas plus dans les messages récupérés par Brad Spengler
et considérer qu'en tant qu'oeuvre de l'esprit un mail bénéficie de sa protection
Faut arrêter la fumette, un mail n'est aucunement une oeuvre de l'esprit, mais une correspondance. Je te défie de trouver le moindre juge qui n'éclatera pas de rire face à cette argumentation plus que bancale.
[^] # Re: légal/illégal
Posté par croux . Évalué à -1.
Peu importe, c'est tout le mail qui se trouve protégé et pas seulement les parties où n'apparaissent pas les données personnelles.
« Faut arrêter la fumette, un mail n'est aucunement une oeuvre de l'esprit, mais une correspondance. Je te défie de trouver le moindre juge qui n'éclatera pas de rire face à cette argumentation plus que bancale. »
En parlant d'arrêter la fumette... il n'y a pas que les oeuvres artistiques a être considérées comme des oeuvres de l'esprit mais aussi les logiciels, y compris le matériel de conception préparatoire
[http://www.industrie.gouv.fr/guidepropintel/fiches_pratiques(...)]
[^] # Re: légal/illégal
Posté par croux . Évalué à 0.
Me Eolas en tant qu'avocat sait tout à fait comment interpréter la loi pour faire valoir son point de vue. Cependant on ne peut affirmer de la légalité ou non du procédé tant que la justice ne ce sera pas prononcée.
Pour revenir au problème une correspondance privée (ce qui est le cas pour ceux qui participent à la liste de développement) ne peut pas être rendue publique sans l'accord des rédacteurs. C'est à la fois une atteinte à la vie privée au regard du droit français, et sans doute contraire au contrat d'utilisation tacite passé lors de l'inscription sur la liste.
Enfin, je maintiens que toute correspondance technique en vue du développement ou de l'amélioration d'un logiciel peut bénéficier de la protection du code de la propriété intellectuelle.
[^] # Re: légal/illégal
Posté par Éric (site web personnel) . Évalué à 4.
Quand un juge se prononce il dit si quelque chose *était* ou pas illégal, pas que ça le devient à partir de maintenant. Par conséquence, bien sur qu'on peut affirmer ou pas que quelque chose est légal. Éventuellement on peut se tromper ou ne pas tous être d'accord (et c'est entre autres pour ça que le juge est là), mais ça n'empêche pas le procédé d'être éventuellement illégal dès maintenant et de le dire dès maintenant.
[^] # Re: légal/illégal
Posté par Zenitram (site web personnel) . Évalué à 1.
Euh... Pourquoi cette question? Ici, les choses ne sont pas illégales car aucun article du code pénal (ou autre) ne condamne la divulgation de correspondance privée dont on est le destinataire (ni l'expéditeur au passage).
Pourquoi vouloir inventer des interdictions qui n'existent pas?
[^] # Re: légal/illégal
Posté par Éric (site web personnel) . Évalué à 6.
[^] # Re: légal/illégal
Posté par croux . Évalué à -1.
C'est bien de la correspondance privée avec de photos faisant partie du message, cela relève au final de la vie privée.
[^] # Re: légal/illégal
Posté par briaeros007 . Évalué à 1.
Le mail contenait bien une partie, lié au CPI (photos, droit à l'image) (qui n'as pas forcément a voir avec la vie privée)
Ainsi donc le contenu a bel et bien une importance cruciale pour savoir si on a le droit de divulger ou non un mail.
Croire de facto parce qu'on a recu quelque chose on a le droit d'en faire tout et n'importe quoi est relativement comique.
Si je recois un code source par mail, il devient ma propriété ?
Bien sur que non.
[^] # Re: légal/illégal
Posté par croux . Évalué à 0.
Ici il n'y a pas de certitude absolue, il y a matière à débat.
Au regard de la loi française on ne peut divulguer une correspondance privée qu'avec l'autorisation de l'expéditeur, ce n'est pas moi qui le dit c'est la loi:
A lire [http://blog-droit.over-blog.com/article-3186781.html]
[^] # Re: légal/illégal
Posté par lasher . Évalué à 2.
D'ailleurs, il faut voir le nombre de journalistes qu'on a mis en examen à cause de ça ...
Enfin, je maintiens que toute correspondance technique en vue du développement ou de l'amélioration d'un logiciel peut bénéficier de la protection du code de la propriété intellectuelle.
C'est ton avis ou bien tu as des sources sérieuses pour le confirmer ?
[^] # Re: légal/illégal
Posté par Zenitram (site web personnel) . Évalué à 3.
source, source, source...
de ce que je connais, les journalistes sont mis en examen car ni l'expéditeur ni le destinataire n'ont souhaité que le journaliste ai accès à la correspondance (violation de la correspondance privée, article L 226-15 du code pénal)
Et je n'ai jamais vu de journaliste mis en examen quand le destinataire du courrier a transmis au journaliste le mail de l'expéditeur.
J'ai l'impression qu'il y a un bon gros mélange entre les gens qui se font transférer un mail et les gens qui interceptent, l'un est légal (pas interdit, ou alors sortez moi l'article de loi), l'autre non (explicitement interdit)...
[^] # Re: légal/illégal
Posté par lasher . Évalué à 3.
En fait, c'était un commentaire ironique. :)
[^] # Re: légal/illégal
Posté par croux . Évalué à 2.
Ici : [http://www.industrie.gouv.fr/guidepropintel/reglementations/(...)]
au paragraphe 1.2 Les logiciels il est indiqué que le logiciel (dès lors qu'il est original) est considéré comme une oeuvre de l'esprit et est protégé par le droit d'auteur, de plus cette protection s'étend aussi aux travaux préparatoires (Article L. 112-2 du Code de la Propriété Intellectuelle).
L'article de loi en question : [http://droit-finances.commentcamarche.net/legifrance/68-code(...)] où on peut lire précisément « 13° Les logiciels, y compris le matériel de conception préparatoire ;
PS: Il est regrettable de constater que certains s'amusent sur linuxfr à « moinser » systématiquement des opinions contraires à la leur et obligent ainsi à redonner les mêmes explications avec les mêmes informations pertinentes...
[^] # Re: légal/illégal
Posté par claudex . Évalué à 2.
Pourquoi faut-il redonner les informations si le texte est moinsé? Si elles ont été jugée inutiles une fois, elles ne le seront pas plus utile (voire plus inutile) une deuxième fois dans le même contexte.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: légal/illégal
Posté par briaeros007 . Évalué à 4.
C'est a supposer que le moinssage a été parce qu'inutile, et non pas parce que bidule chouette aime pas truc muche (et que si bidule chouette moinsse trop truc muche, il ne pourras pas continuer indéfiniment).
[^] # Re: légal/illégal
Posté par claudex . Évalué à 3.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: légal/illégal
Posté par croux . Évalué à 1.
Le courrier appartient au destinataire (il peut l'imprimer, le détruire, ...), mais ce qu'il contient reste la propriété de l'expéditeur (ce que ne nie pas Me Eolas puisqu'il peut y avoir atteinte à la vie privée). Enfin le fait que le code de la propriété intellectuelle ne soit pas mentionné, ne signifie pas qu'il ne s'applique pas.
[^] # Re: légal/illégal
Posté par croux . Évalué à 2.
Secret de la correspondance:
[http://www.educnet.education.fr/legamedia/legadico/contenus/(...)]
[http://www.murielle-cahen.com/publications/page2310.asp]
Nature d'une liste de diffusion:
[http://www.cru.fr/faq/droit-net/quelle_est_la_nature_juridiq(...)]
[^] # Re: légal/illégal
Posté par Zenitram (site web personnel) . Évalué à 3.
Ah, j'ai une réponse logique : parce qu'elle était dans son droit (personne destinataire du mail).
A ton tour maintenant de trouver une raison, parce que le mec attaque TF1 en justice pour licenciement abusif, pas sa député pour rupture de la correspondance privée.
Tu veux plus de preuves que tu interprètes trop? Educnet et murielle-cahen parlent du L 226-15, qui punit toute personne qui intercepte une communication. Ne s'applique pas au destinataire:
Source : http://www.google.fr/search?q=L+226-15 (premier lien)
"Est puni des mêmes peines le fait, commis de mauvaise foi, d'intercepter, de détourner, d'utiliser ou de divulguer des correspondances émises, transmises ou reçues par la voie des télécommunications ou de procéder à l'installation d'appareils conçus pour réaliser de telles interceptions"
Mais bordel, tu insistes, et tu donnes le bâton pour te faire battre, c'est énorme ton obstination. En plus murielle-cahen, avocat, parle bien de violation de la correspondance privée, et pas du tout de ce que fait le destinataire, c'est toi qui en déduit ce qui t'arrange. (pour educnet, ils balance l'article du code pénal, et en font une tirade qui n'a rien à voir, aucune base solide, la honte)
Quitte à te le rappeler : du moment ou le destinataire a reçu un message de toi, il peut faire ce qu'il veut de ce message, il ne t'appartient plus (tu lui a donné.) La loi est (pour une fois) limpide à ce sujet, et parle d'interception, rien à voir, le destinataire n'interceptant pas mais recevant un message. Trouve-moi les articles de loi qui interdisent la publication par le destinataire d'une correspondance plutôt que des sites bizarres (le pire dans l'histoire, c'est que les gens vont faire confiance à ces sites et se retrouver jeté au tribunal sans comprendre...)
Il y a plein de jurisprudence sur le sujet, je te laisse chercher les décisions de justice, puisque tu as l'air de trouver tout ce qu'il te plait...
[^] # Re: légal/illégal
Posté par croux . Évalué à 2.
« Est puni des mêmes peines le fait, commis de mauvaise foi, d'intercepter, de détourner, d'utiliser ou de divulguer des correspondances émises, transmises ou reçues par la voie des télécommunications ou de procéder à l'installation d'appareils conçus pour réaliser de telles interceptions »
Donc comme vous le voyez la loi ne se restreint pas aux interceptions.
Puisque il vous faut d'autres explications :
« La divulgation non autorisée par l'émetteur du courrier électronique est une violation du secret des correspondances qui engage la responsabilité pénale de l'auteur de l'infraction sur le fondement de l'article L 226-15 du Code Pénal. »
[http://blog-droit.over-blog.com/article-3186781.html]
Et pour compléter, un cas concret comme quoi le destinataire d'un courrier ne peut en disposer comme bon lui semble :
[http://www.net-iris.fr/forum-juridique/personne-famille/1203(...)]
Pour l'affaire avec TF1, la priorité logique c'est d'attaquer TF1 pour le licenciement. Ensuite rien ne dit qu'il ne se retournera pas contre sa député UMP (qui avait transmis le mail au ministère de la culture pour obtenir des explications) ni contre le ministère lui-même. Au fait si d'après-vous il n'y a pas violation de la correspondance privée, pourquoi le collaborateur de Mme Albanel a-t-il été suspendu ?
[^] # Re: légal/illégal
Posté par nicoastro . Évalué à 4.
Le premier alinéa, qui parle clairement d’interception en connaissance de cause :
« Le fait, commis de mauvaise foi, d’ouvrir, de supprimer, de retarder ou de détourner des correspondances arrivées ou non à destination et adressées à des tiers, ou d'en prendre frauduleusement connaissance, est puni d'un an d’emprisonnement et de 45000 euros d'amende. »
C’est le second alinéa qui pose problème mais il faut lire « émises, transmises ou reçues-par-la-voie-des-télécommunications » tout attaché, le « reçues » notamment s’applique à « voie de télécommunications » (je ne sais pas si je suis bien clair). Cet alinéa que vous citez ne sert qu’à étendre le premier alinéa aux messages émis, transmis ou reçus par télécommunications (dont les mails).
[^] # Re: légal/illégal
Posté par croux . Évalué à 1.
Dans le premier alinéa on apprend que : « Le fait, commis de mauvaise foi, d'ouvrir [...] des correspondances arrivées ou non à destination et adressées à des tiers [...] est puni d'un an d'emprisonnement et de 45000 euros d'amende. »
Et dans le second alinéa : « Est puni des mêmes peines le fait, commis de mauvaise foi, [...] d'utiliser ou de divulguer des correspondances émises, transmises ou reçues par la voie des télécommunications [...]. »
Au final je soutiens que le fait, en toute connaissance de cause, de prendre connaissance de la correspondance par courrier électronique d'autri (c'est ce qui se passe lorsque l'on s'est vu transférer des messages personnels échangés entre d'autres personnes) et de la divulguer est condamnable.
Reste encore le problème de la correspondance personnelles entre soi et une autre personne, et là encore je soutiens qu'on ne peut rendre publique les messages expédiés par cette autre personne, car elle reste propriétaire (au sens de la propriété intellectuelle) de ses écrits, comme le signale Wikipedia au sujet du Secret_de_la_correspondance : « Une correspondance reste la propriété intellectuelle de son auteur bien que le support physique soit la propriété du destinataire. »
[^] # Re: légal/illégal
Posté par Zenitram (site web personnel) . Évalué à 0.
En quoi serait-ce de la mauvaise foi si je transmets au monde entier un mail que j'ai reçu?
Bon, maintenant, je te laisse en penser ce que tu veux, je n'ai personnellement trouvé que des décisions de justice sanctionnant une personne n'étant pas sensée lire les mail, et pas un destinataire qui divulgue une correspondance privée (par exemple un site qui liste des décisions de justice : http://www.google.fr/search?hl=fr&q=correspondance+privée+site%3Ajuriscom.net ), j'abandonne.
[^] # Re: légal/illégal
Posté par croux . Évalué à 2.
La mauvaise foi est avérée si l'on sait pertinemment que le contenu, auquel on accède, relève d'une correspondance privée. Comment peut-on nier la chose lorsqu'on reçoit un message dont on n'est pas le destinataire et qui est indiqué comme transféré dans son titre...
« je n'ai personnellement trouvé que des décisions de justice sanctionnant une personne n'étant pas sensée lire les mail, et pas un destinataire qui divulgue une correspondance privée »
* Parce qu'il est matériellement plus simple de démontrer que quelqu'un est en possession de courriers personnels et privés d'autres personnes. (On tombe là sur la violation de correspondance privée).
* Parce que c'est plus rémunérateur (journaux condamnés).
* Et parce qu'il est plus difficile de faire condamner le destinataire du courrier fuité. Il est fréquent que le responsable soit plutôt une personne de l'entourage (et on retombe sur la violation de correspondance privée). Mais aussi parce que le destinataire responsable de la fuite peut toujours invoquer l'exception de la copie privée, même s'il communique avec un journaliste, face au non respect de la propriété du contenu du message.
[^] # Re: légal/illégal
Posté par Benoît Sibaud (site web personnel) . Évalué à 4.
à cause de l'immunité parlementaire en France ? (à tort ou à raison)
http://fr.wikipedia.org/wiki/Immunité_parlementaire_en_France
[^] # Re: légal/illégal
Posté par croux . Évalué à 1.
[http://www.denistouret.net/constit/3931.html]
[^] # Re: légal/illégal
Posté par briaeros007 . Évalué à 1.
Moi j'ai une autre réponse, et qui est beaucoup plus logique et beaucoup moins "déliresque" que toi :
parce qu'il a attaqué tf1, et non pas la député.
C'est à la justice ensuite de dire :quels sont les responsabilité dans son licenciement (et si la député a bien une responsabilité en ne respectant pas la loi).
bref, plutot que de partir dans des délires, basé sur des hypothèses fausses, il peut etre bon ton de se renseigner un minimum.
[^] # Re: légal/illégal
Posté par claudex . Évalué à 1.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: légal/illégal
Posté par briaeros007 . Évalué à 2.
Ca ma toujours fait marrer les gens qui estiment qu'attaquer quelqu'un ou quelque chose c'est super simple, ca pose aucun problème et puis un individu sans formation juridique, qui travaille, a aucun problème pour mener deux attaques de front en même temps....
(et surtout, est totalement gratuit si il s'aide d'un avocat).
T'en as d'autres des comme ça ?
[^] # Re: légal/illégal
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: légal/illégal
Posté par briaeros007 . Évalué à 3.
Par contre si il souhaite _ensuite_ attaquer la député "voila, de la faute de la député, j'ai été licencié sans raison, _tel que la montré ce jugement_" .
Ca a un impact autrement plus fort, et donc d'un point de vu tactique est mieux.
Donc pour résumer
- Difficulté pour mener deux attaques de front
- Pas de gains avec l'attaque sur la député, contrairement avec celui sur tf1. Donc priorité à tf1
- Un jugement "postif" a tf1 aura une très bonne valeur pour montrer le préjudice qui lui a fait la député. Donc aucun intérêt à l'attaquer maintenant.
[^] # Re: légal/illégal
Posté par claudex . Évalué à 2.
C'est à la justice ensuite de dire :quels sont les responsabilité dans son licenciement (et si la député a bien une responsabilité en ne respectant pas la loi).
la justice va dire que la député n'a pas respecter la loi dans un procès qui ne concerne pas. (je ne pense pas que la manière dont celui qui a transmis l'information à TF1 entre en compte dans ce procès).
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: légal/illégal
Posté par briaeros007 . Évalué à 3.
Je pense surtout que la justice va (peut etre) dire
- qu'elle a eu accés a des informations alors qu'elle n'aurait pas du y avoir accés (relevant de la vie privée).
- Qu'elle a utilisée ces informations contre les règles établies sur le licenciement.
Le point qui interesse le jugement de tf1 est bien entendu le 2em. Mais le premier permet de remonter sans problème sur "qui a fournis les informations".
Et une décision de justice est difficilement contestable ;)
[^] # Re: légal/illégal
Posté par claudex . Évalué à 2.
Je ne sais pas si la justice se prononcera là-dessus car TF1 a obtenu ces informations par le ministre et c'est ce dernier qui n'aurait pas dû y avoir accès dans ce cas. De plus je ne sais pas si une cours qui juge un licenciement abusif est compétente pour juger cela.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: légal/illégal
Posté par briaeros007 . Évalué à 2.
(le ministère fait du recel (a récup des infos relevant de la vie privée), et de la diffusion de ces dernières, sans accord de la personne.
Petit apparté, on voit a quel point le ministère est attaché au droit et veut les faire respecter par hadopi...
)
[^] # Re: légal/illégal
Posté par claudex . Évalué à 2.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
[^] # Re: légal/illégal
Posté par briaeros007 . Évalué à 2.
A supposer. Cela ne l'autoriser toujours pas à diffuser.
Le(a) ministre a reçu en copie l'autorisation explicite pour transmettre ces infos ? Cette autorisation n'est pas présente sur le mail qu'elle a reçue.
De plus, l'email envoyé avec la copie contredit quelque peu la "bonne foi".
Pour mémoire
Bonjour Jean-Michel, vous avez des salariés qui, manifestement, aiment tirer contre leur camp. Cordialement
[^] # Re: légal/illégal
Posté par Zenitram (site web personnel) . Évalué à 2.
- Difficulté pour mener deux attaques de front
- Pas de gains avec l'attaque sur la député, contrairement avec celui sur tf1. Donc priorité à tf1
- Un jugement "postif" a tf1 aura une très bonne valeur pour montrer le préjudice qui lui a fait la député. Donc aucun intérêt à l'attaquer maintenant.
Ou alors plus simple : ce n'est pas illégal, et l'avocat lui a dit, donc il ne s'y aventure pas, il ne s'aventure même pas à dire aux médias à dire que c'était illégal et en violation de la correspondance privée (dans le cas de l'immunité parlementaire).
Ah? Ca doit être trop simple comme explication, donc faut en trouver une autre... Pourriez au moins dégoter un jugement si c'est si évidement, la correspondance privée est quand même un grand classique, ça serait étonnant qu'il n'y ai pas un seul jugement qui traine.
PS : j'ai cherché, et trouvé uniquement des dizaines de condamnations pour violation de correspondances privée par une personne externe à l'expéditeur/destinataire et une loi qui l'interdit aussi (toujours le même problème : mauvaise foi, interception...), rien quand le destinataire divulgue volontairement. J'ai pourtant pas mal cherché...
[^] # Re: légal/illégal
Posté par croux . Évalué à 0.
Parce que pour le destinataire du courrier c'est du domaine de l'atteinte à la vie privée la plupart du temps.
Tandis que pour celui qui publie, ce que lui a transmis le destinataire, c'est une violation de correspondance privée.
[^] # Re: légal/illégal
Posté par croux . Évalué à 0.
Ou alors l'avocat informe son client que les risques de perdre le procès sont trop importants, sachant que celui qui perd doit payer les frais du procès et d'avocat de la partie adverse. Et il faudrait en plus que la plainte soit enregistrée...
[^] # Re: Quelques commentaires
Posté par pasBill pasGates . Évalué à 1.
C'est absolument faux, c'est tout a fait possible, simplement ca demande du boulot et un peu de temps, ce qui ralentirait le developpement. Et oui, dans qqe cas il est possible de se tromper et mettre un bug en DoS plutot qu'EoP ou autre, mais c'est toujours mieux que ne pas le voir.
[^] # Re: Quelques commentaires
Posté par patrick_g (site web personnel) . Évalué à 3.
Cela a déjà été discuté as nauseam et manifestement les gens en charge des versions -stables du noyau ne sont pas du même avis que toi.
[^] # Re: Quelques commentaires
Posté par pasBill pasGates . Évalué à 3.
[^] # Re: Quelques commentaires
Posté par patrick_g (site web personnel) . Évalué à 7.
Le problème c'est que tu ne peux pas savoir si ceux que tu a mis dans le seconde catégorie ne relèvent pas en fait de la première...alors pourquoi dépenser de précieuses ressources à faire cette distinction qui n'a pas vraiment d'utilité ? Est-ce que ce n'est pas plus logique de dire aux utilisateurs d'appliquer toutes les corrections au lieu d'essayer de jouer au plus malin et de faire du pick and choose sur les correctifs ?
[^] # Re: Quelques commentaires
Posté par pasBill pasGates . Évalué à 4.
C'est vrai, tu ne peux pas _garantir_ que tu ne te tromperas jamais. Mais cela ne veut pas dire que le taux de tri correct est bas, il est au contraire haut. Quand a l'utilite, c'est extremement utile, nottament car ca te permet de savoir si les versions precedentes ont une faille ou pas (on corrige un bug dans Vista, on voit que c'est un probleme de securite, on va jeter un oeil a XP, si c'est pas un bug de securite, on ne regarde pas XP) et la corriger dans la version precedente.
Il est absolument irrealiste de demander aux gens de rester sur la derniere version du kernel pour des raisons de certification et autres, le backport de patchs de securite est donc une necessite.
Est-ce que ce n'est pas plus logique de dire aux utilisateurs d'appliquer toutes les corrections au lieu d'essayer de jouer au plus malin et de faire du pick and choose sur les correctifs ?
Justement non, parce que les utilisateurs ils vont devoir se taper un nombre de correctifs enorme alors qu'ils n'ont pas besoin de la plupart de ces correctifs la plupart du temps.
Si tu jettes un oeil sur ce qu'on fait depuis qqe annees, nos patchs contiennent 2 branches : une pour les patchs critiques (securite et autres patchs particuliers qui sont tres importants) et une pour les patchs "normaux" qui contient tout
Resultat, la grosse majorite des gens est sur la branche qui ne contient que les patchs critiques, et pas tout le bordel dont ils se fichent eperdument. Le jour ou ils auront besoin d'un patch pour un truc, ils changent de branche et c'est regle.
[^] # Re: Quelques commentaires
Posté par herodiade . Évalué à 7.
Mais est-ce applicable pour le lot commun des patchs concernant un OS ? Pour les trois que je connais, la tâche semble ardue : ce qui est reproché aujourd'hui à Linux l'est régulièrement à Microsoft. Et OpenBSD ne prétends par faire mieux : les devs anticipent la question en martelant : "nous préférons passer du temps à prévenir et corriger plein de choses qu'à évaluer la possibilité qu'un de nos patch répare une faille de sécurité" ; il leur arrive effectivement de découvrir avoir corrigé une faille longtemps après l'application d'un patch (par ex. sur leur version d'apache).
Autrement dit, tout les fournisseurs OS sont régulièrement accusés de cacher intentionnellement la poussière sous le tapis ; et le fait que ça touche tout les OS permet justement de douter du qualificatif "intentionnellement".
Détaillons le cas de la démarche dite "proactive" (= le principe de "mieux vaut prévenir que guérir") d'OpenBSD. L'équipe de développeur est assez réduite ; à chaque nouvelle faille, et à chaque découverte de paradigmes de programmation sécurisée, ils ont pour habitude de passer tout leur CVS (contenant un OS complet hein, pas seulement le noyau) à la moulinette du rechercher/remplacer. C'était le cas lorsqu'ils ont remplacé tout les srt[n]cat/cpy par des strlcat/cpy, la plupart des atoll/atoi par des strtonum, trouvé une méthodologie plus robuste pour prévenir les débordement d'entiers, activé tel ou tel warning supplémentaire du compilateur et corrigé tout ce qui bronche, etc. : un travail de titan, et des dizaines de milliers de patchs à chaque fois. Si, pour chacun de ces patchs, il avait fallu passer plusieurs heures à chercher s'il corrigeait une faille effective, ils n'auraient jamais pu mener ces chantiers à terme, loin s'en faut.
Moralité : dans ce cas, l'effort de transparence (catégorisation des modifications appliquées dans les branches de développement de l'OS) est antithétique et préjudiciable à la sécurité effective du système. Tout simplement parce que les ressources humaines ne sont pas illimitées (peut-être qu'elle le sont chez Microsoft, mais ce n'est pas le cas pour les OS libres que je connais). Et si le "armchair security expert" était, justement, celui qui juge le résultat de haut et de loin, sans mettre les mains dans le cambouis ?
[^] # Re: Quelques commentaires
Posté par reno . Évalué à 2.
Pas vraiment d'utilite, tu exageres la: la prise en compte d'un patch a un cout pour les utilisateurs (installation, temps de reboot, test de la nouvelle version, etc) donc si le fournisseur de l'OS diminue le nombre de changement a prendre en compte, cela a vraiment une utilite pour l'utilisateur!
[^] # Re: Quelques commentaires
Posté par Gniarf . Évalué à 3.
[^] # Re: Quelques commentaires
Posté par pasBill pasGates . Évalué à 4.
# Sus à l'anglois !
Posté par Grasyop . Évalué à 7.
Impacter n'est pas français ; on dit « affecter » !
(Cette dépêche contient d'autres anglicismes, mais celui-là me déplaît particulièrement.)
[^] # Re: Sus à l'anglois !
Posté par croux . Évalué à 3.
Méditons ensemble ce proverbe chinois « Quand le sage montre la Lune, l'imbécile regarde le doigt. »
[^] # Re: Sus à l'anglois !
Posté par Zenitram (site web personnel) . Évalué à 2.
Et c'est à double sens (pleins de mots français sont utilisés en anglais et en allemand, et en bonus avec l'accent français, rigolo :) ).
Une langue s'alimente des autres langues, évolue, se transforme, et c'est ce qui fait son charme.
D'autres diront que, horreur, "Week-end" est dans le Larousse (http://www.larousse.fr/dictionnaires/francais/Week-end ), vade retro satanas, mais la majorité continueront à faire vivre la langue.
On a bien "impact" (http://www.larousse.fr/dictionnaires/francais/Impact ) dans le Larousse, ça me parait assez naturel de prendre "impacter". Ca rentrera un jour dans les dicos, faudra t'y faire.
Sur ce, bon Week-end ;-)
[^] # Re: Sus à l'anglois !
Posté par psychoslave__ (site web personnel) . Évalué à 8.
On en arrive à voir des gens incapable de s'exprimer avec des mots de leur langue maternelle alors même qu'il existe déjà un équivalent, et même, c'est là que ça deviens vraiment n'importe quoi, des gens qui connaissent les mots dans leur langue natale mais ne savent même pas que le mot étranger est son stricte équivalent.
Par exemple, sur linuxfr j'avais vu un bonhomme qui ne savais pas traduire backup, et dans le même file de discussion, on me disait que «en amont» traduisait mal «upstream».
https://linuxfr.org//comments/982038.html#982038
Le problème que cela soulève n'est pas tant la racine des mots que la compréhension des mots qu'on emploi.
[^] # Re: Sus à l'anglois !
Posté par croux . Évalué à 5.
Impacter (v. tr.) Avoir un impact, une incidence sur, toucher.
ex. Les charges ont fortement impacté le résultat.
[^] # Re: Sus à l'anglois !
Posté par psychoslave__ (site web personnel) . Évalué à 2.
[^] # Re: Sus à l'anglois !
Posté par croux . Évalué à 2.
[^] # Re: Sus à l'anglois !
Posté par neologix . Évalué à 4.
De même pour "les fondamentaux de l'enseignement" : fondamental est un adjectif, pas un nom.
Ce n'est pas parce que 1000 personnes pensent la même connerie que ce n'est pas une connerie...
[^] # Re: Sus à l'anglois !
Posté par croux . Évalué à 2.
[^] # Re: Sus à l'anglois !
Posté par Dr BG . Évalué à 2.
C'est par une extension abusive qu'on emploie Impact en parlant d'une influence diffuse ou générale.
[^] # Re: Sus à l'anglois !
Posté par Grasyop . Évalué à 4.
Quand toutes les langues seront inondées d'anglais et se ressembleront, je ne sais pas où sera leur charme...
Une langue vit et importe des mots d'autres langues : oui bien sûr, mais autant certains imports se justifient en ce qu'ils viennent remplir un vide dans notre langue, autant d'autres font doublon avec un terme déjà existant et finissent parfois par le supplanter. Bref, je partage essentiellement le point de vue exprimé plus haut par Mathieu Stumpf, si ce n'est que, justement, impacter me choque dans la mesure où il existe un équivalent en français. C'est nous qui faisons vivre la langue, elle évolue dans la direction où on la mène.
Croux, désolé, j'en suis encore au Petit Robert 1992. (Il y a quand même écrit « nouveau » dessus !) Impacter n'est pas dedans.
En fait, je crois qu'il y a une autre raison pour laquelle, personnellement, le mot « impacter » ne me plaît pas beaucoup quand je le lis dans les médias : l'image d'un impact lui donne peut-être un coté un peu spectaculaire par rapport au classique « affecter », et je n'aime pas trop la surenchère médiatique dans le spectaculaire.
[^] # Re: Sus à l'anglois !
Posté par croux . Évalué à 0.
1992 ! A cette époque là internet et les emails n'existaient sans doute pas pour le Petit Robert...
[^] # Re: Sus à l'anglois !
Posté par Grasyop . Évalué à -2.
[^] # Re: Sus à l'anglois !
Posté par croux . Évalué à 2.
Au fait « courriel » ne serait-il pas un québécisme ?
[^] # Re: Sus à l'anglois !
Posté par claudex . Évalué à 2.
Il me semble que le mot vient du Québec mais qu'il est actuellement recommandé par l'Académie Française.
« Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche
# Il me manque une piece du puzzle
Posté par flyer . Évalué à 1.
(desole pour l'absence d'accent)
[^] # Re: Il me manque une piece du puzzle
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
[^] # Re: Il me manque une piece du puzzle
Posté par Victor STINNER (site web personnel) . Évalué à 5.
L'exploit est assez compliqué, alors je suis pas sûr de ce que je raconte. Mais bon, ça te donnera une meilleure idée de ce qui se passe.
[^] # Re: Il me manque une piece du puzzle
Posté par neologix . Évalué à 7.
C'est l'optimisation de gcc qui supprime la vérification
if (!tun) return POLLERR;Du coup, derrière, au lieu de sortir de la fonction, on se retrouve avec sk qui pointe vers l'adresse
0 + offsetof(tun, sk).Et là, c'est le drame. Par exemple, si le socket et supprimé, c'est
sk->sk_destruct(sk)qui est appelé, et donc si tu as mis la fonction qui va bien à l'adresse0 + offsetof(tun, sk) + offsetof(sk, sk_destruct), tu deviens calife à la place du calife...[^] # Re: Il me manque une piece du puzzle
Posté par neologix . Évalué à 6.
Dans mon exemple, sk est un pointeur, situé à l'adresse
offsetof(tun, sk).Donc, si
sk->sk_destruct(sk)est appelé, le code appelé est situé à l'adresse pointée par sk, plus offsetof(sk, sk_destruct).Mais ce n'est qu'un exemple...
Ce qui est marrant c'est que c'est optimisation de gcc qui permet au code d'être exécuté, au lieu de faire un oops.
# Je ne comprends pas
Posté par Éric (site web personnel) . Évalué à 4.
Il me parait très sain de dire que le kernel en question a un problème et de palier ce problème, mais ce n'est pas surtout le compilateur qui dans ce cas a un énorme bug ? Un compilo qui ajoute des failles de sécurités c'est surtout ça qui me parait dangereux et qui est à corriger. Ce n'est pas vraiment aux développeurs de prévoir et contourner les optimisations foireuses du compilo.
Or je vois des annonces à propos du kernel mais pas à propos d'une correction critique de gcc. J'ai mal compris un truc ?
[^] # Re: Je ne comprends pas
Posté par Zenitram (site web personnel) . Évalué à 7.
Le compilo a viré du code car le code en question est sensé ne jamais être utilisé (le pointeur est utilisé la ligne d'avant, donc ne peut pas être à NULL).
Le compilo a fait son boulot en virant du code inutile, juste "trop bien" alors qu'il y avait un bug (test fait trop tard), et c'est le bug qui rend le code inutile donc viré.
Le compilo a fait ce qu'on lui a demandé, sauf que la demande était bugguée (faire le test avant), une fois la demande corrigée le compilo fait correctement son boulot.
Le compilo n'a juste pas la fonctionnalité de correction des bugs dans la demande humaine.
[^] # Re: Je ne comprends pas
Posté par Éric (site web personnel) . Évalué à 2.
[^] # Re: Je ne comprends pas
Posté par Kerro . Évalué à 2.
Si le compilateur n'avait pas "fait son boulot" alors l'exploitation de la faille ne serait pas possible (si j'ai bien compris). Par exemple un autre compilateur n'aurait pas engendré le problème. Donc le compilateur modifie le comportement du programme.
Dans mon esprit simplet, un compilateur qui modifie le comportement d'un programme, ça se nomme nomme bug.
[^] # Re: Je ne comprends pas
Posté par lasher . Évalué à 6.
Il ne modifie pas le comportement du programme, dans le sens où du point de vue formel, il n'a rien fait d'illégal. Voici un autre exemple, plus simple :
void dummy(double *array, size_t len) {double acc = 0.0;
for (int i = 0; i < len; ++i)
__acc += array[i];
}
Un bon compilateur, qui optimise bien, va tout simplement supprimer la boucle (et avec l'inlining, il ne subsistera plus rien du code original). Un mec qui voudrait (par exemple) utiliser dummy() pour flusher arbitrairement la mémoire cache ne pourrait plus le faire.
Autre exemple : memset fait partie des fonctions standard du C. À ce titre, elle est donc « magique », et le compilateur peut faire un peu ce qu'il veut avec du moment que ça ne viole pas les contraintes du programme. Si par exemple je tape un code du genre (piqué à Marc Espie sur fclc)
void f() {char passwd[250];
// code qui demande un mot de passe a l'utilisateur.
// code qui s'en sert
memset(passwd, 0, sizeof passwd);
}
Ben là, le compilateur peut dire « hé mais de toute manière, passwd est local à la fonction, donc faire un memset dessus ça prend du temps et des ressources pour rien ». Et paf, il le vire. Sauf qu'en fait, le memset était là pour éviter qu'un petit malin essaie ensuite de lire dans la zone mémoire où passwd est alloué (par exemple pour lire une ancienne valeur de passwd). Du point de vue du « sens » du programme, tout est respecté. Du point de vue sécurité, c'est une « catastrophe ».
[^] # Re: Je ne comprends pas
Posté par oao . Évalué à 2.
[^] # Re: Je ne comprends pas
Posté par lasher . Évalué à 3.
Parce que la plupart du temps le compilateur a raison de supprimer le code. Sauf quand il a tort. Il ne va pas faire un warning pour chaque boucle simple qu'il optimise, sinon on est pas rendu (mais on peut lui dire de générer un rapport si on veut savoir ce qu'il a fait ...). Dans le cas de la fonction qui agit sur un mot de passe, je dirais que 9 fois sur 10, le memset est réellement inutile car il ne s'agit pas de code ni de données sensibles.
Est-ce car les cas réels ne sont pas aussi simples?
Je me sers d'une boucle à peine plus compliquée que la première donnée pour faire des micro-benchmarks (j'accumule dans une variable acc que j'affecte ensuite à un pointeur pacc pour empêcher le compilateur de supprimer le code).
Concernant le deuxième exemple, je l'ai emprunté à Marc Espie, qui s'en servait sur fr.comp.lang.c pour donner un exemple de suppression automagique (car memset est une fonction standard, donc le compilateur « sait » comment elle fonctionne, quand il peut se permettre de la virer, etc.) de code de la part de gcc. C'est un « vrai » code dans le sens où je pense qu'il est légitime de vouloir nettoyer la mémoire quand on est un peu obsédé niveau sécurité.
Dans la vraie vie, avec des codes réels, il y a plein de cas où le compilateur supprime avec raison tout un tas de trucs en se disant « au final c'est pareil ». Sauf quand c'est pas vrai.
[^] # Re: Je ne comprends pas
Posté par Mathieu Schroeter (site web personnel, Mastodon) . Évalué à 1.
Ça s'appelle de l'optimisation, dans le cas contraire il suffit de compiler le noyau en -O0 et tu es sûr qu'il ne supprimera pas le test (et accepter les conséquences au niveau des performances). Autrement faut chercher quel flag de GCC effectue ce type d'optimisation dans son manpage monstrueux.
[^] # Re: Je ne comprends pas
Posté par Mathieu Schroeter (site web personnel, Mastodon) . Évalué à 3.
-fdelete-null-pointer-checks
Use global dataflow analysis to identify and eliminate useless checks for null pointers. The compiler assumes that dereferencing a null pointer would have halted the program. If a pointer is checked after it has already been dereferenced, it cannot be null.
In some environments, this assumption is not true, and programs can safely dereference null pointers. Use -fno-delete-null-pointer-checks to disable this optimization for programs which depend on that behavior.
Enabled at levels -O2, -O3, -Os.
[^] # Re: Je ne comprends pas
Posté par reno . Évalué à 3.
Soit quand tu rentres des informations erronees en entree, tu auras un resultat errone en sortie.
Dans ce cas present le programme C etait errone (avait un bug), ce bug etait expose ou non suivant l'implementation du compilateur, le probleme ne vient donc pas du compilateur mais du programme.
[^] # Re: Je ne comprends pas
Posté par Thierry . Évalué à 1.
Et il me semble bien que ce n'est pas la première fois que ça cause un problêème; de mémoire, il y a quelques mois/années, c'était un memset à 0 «optimisé», laissant ainsi des données sensibles sur la pile en sortie de fonction...
[^] # Re: Je ne comprends pas
Posté par neologix . Évalué à 2.
Déréférencer un pointeur NULL est une "undefined behavior", autrement dit l'implémentation est libre de faire _ce qu'elle veut_. Crasher, générer du code foireux, imprimer "42", etc.
Définition de "undefined behavior" :
behavior, upon use of a nonportable or erroneous program construct, of erroneous data, or of indeterminately valued objects, for which this International Standard imposes no requirements
NOTE Possible undefined behavior ranges from ignoring the situation completely with unpredictable results, to behaving during translation or program execution in a documented manner characteristic of the environment (with or without the issuance of a diagnostic message), to terminating a translation or execution (with the issuance of a diagnostic message).
En l'occurrence, gcc supprime le test puisqu'il "suppose" que le programme aura crashé.
C'est un choix comme un autre, par contre je ne comprends pas pourquoi il ne lève pas un warning à la compilation, s'il _pense_ que le code va crasher...
[^] # Re: Je ne comprends pas
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: Je ne comprends pas
Posté par neologix . Évalué à 1.
Je suis curieux de voir un exemple de telle utilisation volontaire...
Je dirais que dans 99% des cas, un tel code est très très douteux, le choix fait par gcc me paraît foireux...
[^] # Re: Je ne comprends pas
Posté par pasBill pasGates . Évalué à 2.
Si la valeur est nulle, la variable a ete dereferencee avant, donc le test ne s'executera jamais vu que le systeme crashera avant.
Ce test est dans tous les cas inutile et gcc a tout a fait raison de l'enlever.
gcc ne peut pas non plus savoir si la variable est potentiellement nulle ou pas, et il ne peut pas mettre un warning a chaque cas ou il n'est pas sur, sinon tu aurais 35222 warnings a chaque compilation.
[^] # Re: Je ne comprends pas
Posté par neologix . Évalué à 4.
C'est la toute la différence...
[^] # Re: Je ne comprends pas
Posté par Mathieu Schroeter (site web personnel, Mastodon) . Évalué à 2.
Néanmoins, ce problème est peut être une bonne occasion d'ajouter un flag d'avertissement (actif également avec -Wall ?) si GCC applique cette optimisation?!
Bien que dès le moment qu'on la lui demande directement il n'y a pas vraiment de raison de créer un warning. Quand on passe des flags à GCC on est sensé savoir ce qu'on fait et accepter les conséquences.
# L'avis de Mingo
Posté par patrick_g (site web personnel) . Évalué à 4.
Vraiment très intéressant à lire :
http://lwn.net/Articles/342163/
[^] # Re: L'avis de Mingo
Posté par pasBill pasGates . Évalué à 0.
Sa maniere de decrire les chercheurs en securite est honteuse et montre qu'il n'y connait foutrement rien, c'est le moins qu'on puisse dire.
[^] # Re: L'avis de Mingo
Posté par patrick_g (site web personnel) . Évalué à 5.
[^] # Re: L'avis de Mingo
Posté par pasBill pasGates . Évalué à 1.
[^] # Re: L'avis de Mingo
Posté par oliv . Évalué à 4.
Sérieusement, le problème a été découvert par Coverity
http://www.internetnews.com/dev-news/article.php/3831716
et corrigé.
Et Brad Spengler fait semblant d'avoir découvert la faille pour récolter les lauriers, alors que sa contribution se limite à regarder les changelogs. Ingo Molnar souligne ce point.
# SELinux
Posté par Denis Montjoie (site web personnel) . Évalué à 2.
(information confirmé sur #selinux)
PS: unconfined_t ca veux dire "pas confiné par SELinux", pour ceux qui n'en ont jamais fait.
UPDATE: not just that, SELinux lets any user in unconfined_t map at
0, overriding the mmap_min_addr restriction! pulseaudio is not
needed at all! Having SELinux enabled actually *WEAKENS* system
security for these kinds of exploits!
# Coccinnelle
Posté par Kyle_the_hacker . Évalué à 1.
# TUN
Posté par blubliblo . Évalué à -3.
D'ailleurs pour le monter, il faut un programme SUID root genre pulseaudio (d'ailleurs à quand un mixer en C pour lui, qui ne descent pas tout gnome?)
Et puis il faut rappeler qu'aucun système n'est sûr. Certains sont justes de notoriété plus sûrs, c tout. Donc à partir de là autant privilégier des systèmes (A)GPL pour favoriser la publication de code correctifs de failles.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.