La gravité de la faille serait confirmée par RedHat et Canonical ce qui ne semble pas être l'avis des développeurs concernés et contactés par Simone Margaritelli. Wait and see…
Il est probable que les conditions d'exploitation de la faille la rendent beaucoup moins préoccupante que tente de le faire cette anonce tonitruante.
C'est sûr que je retrouve dans son attitude quelque chose que je vois chez beaucoup d'autres "experts en sécurité": cette sensation qu'ils se sentent tellement importants qu'on devrait limite les idôlatrer et les couvrir de cadeaux pour les remercier et que le monde ne tournerait pas sans eux.
Quand je lis ce lien:
I've spent the last 3 weeks of my sabbatical working full time on this research
Les devs (ça ne dit pas de quel logiciel il s'agit) ont probablement fait de même pour développer leur logiciel, sauf que plutôt que 3 semaines, c'est depuis des années, voire décennies, et pour beaucoup d'entre eux en purs bénévoles.
Enfin je devine, puisqu'on parle de logiciel libre. Mais peut-être s'agit-il d'un logiciel d'entreprise?
with the sole purpose of helping
De même que ces dévs, très probablement (du moins toujours dans l'hypothèse d'un logiciel communautaire).
only got patronized because the devs just can't accept that their code is crap
LOL. Ce morceau de phrase vaut de l'or. Si qualifier leur code de "crap", c'est pas un symptôme même de "patronization" (prendre de haut, en gros), je sais pas ce que c'est. Un peu l'hôpital qui se fout de la charité.
Enfin bon… moi non plus, je n'ai aucune idée de quoi il s'agit et peut-être y a-t-il de vrais gros problèmes derrière cette "annonce tonitruante", mais je sais aussi que du point de vue dév, beaucoup "d'experts en sécurité" sont surtout fatigants. Ils arrivent sur leurs grands chevaux et limite veulent que la terre s'arrête de tourner le temps qu'ils soient là. On devrait tout arrêter et se préoccuper d'eux à temps plein de préférence (même lorsqu'on fait ça sur son temps libre et qu'on a une vie derrière).
On sent bien d'ailleurs dans le ton du message que cette personne ne s'est pas sentie suffisamment prise en compte, qu'elle a pris 3 semaines de son temps libre et donc que les dévs devraient se soumettre à elle à temps plein et ce bout de phrase qu'on lit si souvent est le parfait example:
you have a freaking responsibility to own and fix your bugs
Et oui, j'ai tronqué la phrase dont le reste explique que les dévs ont tort et que leur code est faux, parce que… ça ne change rien au problème.
Et oui mais… non, la plupart des dévs de logiciel libre n'ont aucune responsabilité dans la correction de bug. Désolé, c'est même expliqué dans la licence de la plupart des logiciels libres, par exemple la GPL:
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY
C'est d'autant plus vrai quand les développeurs sont bénévoles (ce qui est le cas d'énormément de logiciels libres), mais même lorsqu'ils sont payés pour le faire! Souvent on est payés dans un contexte. Par exemple, on peut être rémunérés pour pouvoir améliorer et utiliser le logiciel dans un contexte professionnel (par exemple: usage en production d'un film! 😛), pas parce qu'on le vend en service. Le fait que le logiciel soit aussi librement (et gratuitement) à disposition à côté n'est qu'un petit bonus parce qu'on ne fait pas partie des gens qui veulent s'approprier tous les moyens de production et raquer le moindre sou sur le dos du sacro-saint "droit d'auteur". Donc on laisse notre code pour que d'autres puissent le reprendre, le modifier et si ça leur plaît mais qu'ils trouvent des problèmes qui les gênent particulièrement (genre… un bug de sécurité!), ils sont libres de corriger eux-même (ou de payer des gens pour le faire: me sortez pas le vieil argument de "tout le monde est pas dév" -> on est aussi libres de pas utiliser un logiciel trop troué, comme on est libre de l'améliorer ou le faire améliorer, ce sans en faire porter la responsabilité sur ceux qui ont offerts le bout de code sans contrepartie; j'ai déjà eu des gens qui m'ont payé pour ajouter une fonctionnalité à un logiciel libre, et je parle pas de grosses boîtes mais bien de petits entrepreneurs! Si ton métier en dépend, c'est ton propre devoir de t'assurer de la sûreté de tes outils — et vérifier aussi qu'ils correspondent vraiment à ce dont tu as besoin pour ton usage —, pas celui d'autrui, et surtout pas de celui qui t'aurait en plus offert ces outils).
Le seul cas où on aurait effectivement une responsabilité, c'est si on avait vendu un logiciel sous la forme d'une licence ou service et qu'on découvre alors que ça présente un risque pour le client. Là oui, bien sûr. Mais hormis ça si un quidam moyen prend notre code sur internet, c'est sa responsabilité (tant qu'on n'a pas mis de failles exprès pour nous même agir contre eux, bien sûr, là c'est non seulement notre responsabilité, mais surtout illégal et un délit/crime).
Enfin bon, ce genre de comportements est exactement pourquoi tant de développeurs finissent par être dégoûtés du logiciel libre et un jour décident de tout laisser tomber. Dans les réponses aux tweets, je vois même que certains parlent de "mettre la pression" aux développeurs, etc. On se demande parfois si les gens se rendent compte qu'ils parlent d'autres humains avec une vie, des sentiments…
On se retrouve exactement dans le cas de figure du XKCD sur les dépendances avec le pauvre mainteneur d'un truc critique qui s'en prend plein la tronche et doit absolument agir vite (pour avant-hier svp) quand le gentil "expert sécurité" et les grosses boîtes qui se font plein de sous en vendant du service sur le logiciel offert en libre (RedHat, Canonical… mentionnés dans le billet) mettent la pression pour une correction.
Je me dis aussi que beaucoup du bruit généré est surtout une bonne excuse pour cette personne qui ne veut plus avoir à s'embêter à faire du "responsible disclosure" à l'avenir, c'est à dire ne plus s'embêter à être une personne décente qui ne met pas les autres dans la panade pour son gain personnel:
responsible disclosure: no more.
Ma conclusion sera sur le même commentaire que cette personne cite dans son message:
from a generic security point of view, a whole Linux system as it is nowadays is just an endless and hopeless mess of security holes waiting to be exploited
Apparemment (si je comprends bien, c'est pas dit clairement de qui est cette citation, on ne peut que deviner), ce serait une copie de ce qu'un des développeurs du logiciel ciblé a dû écrire dans le rapport de bug. Clairement cette "experte" finit sur cette citation pour se moquer mais je vais me permettre un tout autre point de vue dessus.
Déjà: c'est vrai (bon là on a tous le même point de vue!). Et surtout c'est bien d'en être conscient. Cela montre que ces développeurs ne sont pas de complets néophytes imbus d'eux même. Ensuite pourquoi c'est vrai? Parce que l'environnement du logiciel (libre et non libre) a énormément changé. Le "paradigme" a changé, dira-t-on pour briller lors des soirées. En une vingtaine d'années, on est passé de développements énormément basés sur la confiance des autres, sur l'échange, à un paradigme où il faut absolument se méfier de tout. On est dans un monde où une personne (qui n'est peut-être même pas une unique personne en vrai) peut prendre 3 ans de sa vie, prendre le temps de faire de l'ingéniérie sociale des années pour devenir mainteneur, etc. pour introduire des failles; on est dans un monde avec beaucoup plus de gens utilisant sans arrêt des logiciels et où les malwares pullulent dans des "stores" divers (et pas que dans les OS de téléphones, des cas ont été notifiés même sur les GNU/Linux historiques). La raison même pour laquelle les sandboxes (bacs à sable) tels que Flatpak et Snap existe est d'ailleurs ce problème sécuritaire: on ne peut plus faire confiance aux autres, et donc a fortiori aux développeurs de logiciels. Donc il faut bloquer de partout (quitte à perdre des fonctionnalités historiques ce qui fait grincer beaucoup de dents chez les développeurs qui sont là depuis longtemps et ne faisaient rien de mal).
On est donc effectivement dans ce monde, cet entre-deux, où beaucoup de logiciels ont des failles diverses — qui parfois étaient même considérées comme des fonctionnalités à une époque pas si lointaine! —, ce qui a toujours été le cas, et il faut effectivement les corriger, mais s'en étonner ou sembler outrée par ce fait montre seulement une forme d'amateurisme. Des bugs, j'en corrige toutes les semaines, à la volée. Et non, ce n'est pas parce que mon code (ou celui des autres dévs avec qui je contribue) est mauvais. C'est juste la vie. On est humain, on fait des erreurs (non l'IA ne ferait pas mieux), on apprend constamment, et c'est la vie d'un logiciel. Ces "experts" font un énorme pataquès de trucs qu'on corrige tous les jours, souvent parce qu'ils ne comprennent pas grand chose au développement (en fait, je ne suis pas sûr avoir jamais reçu un patch de la part de gens qui se présentaient comme experts/chercheurs en sécurité, ou alors de mauvais patchs qu'on ne pouvaient pas utiliser car ils font juste un changement vite fait sur le symptôme, ce qui créerait juste de nouveaux bugs si on l'acceptait). Et c'est pourquoi ils sont étonnés ou moqueurs devant ce type de déclaration alors que ça ne fait que montrer leur méconnaissance. Mais oui, en vrai, des bugs qui peuvent être exploités, aisément pour certains, si trouvés, il y en a à la pelle dans tous les logiciels.
Et un développeur qui ne serait pas conscient de cela et croit faire du code parfait, ben désolé, ce serait lui le mauvais développeur. Ça me fait d'ailleurs penser à cette discussion qui s'est récemment produite entre Linus et le mainteneur de bcachefs parce que ce dernier essayait de pousser du code de développement trop proche des sorties. Et ce dernier assurait que son code était super bon et n'avait aucun bug pour sûr, ce à quoi Linus rétorquait qu'il veut pas lire ce type d'absurdités de la part d'un mainteneur d'une partie du noyau. Car oui, les logiciels ont des bugs, tous. Constamment. Et beaucoup de ceux-ci peuvent effectivement être exploités (avec les bonnes conditions, qui heureusement est la partie plus compliquée à mettre en place). Ceux qui croient le contraire, c'est en général mauvais signe. J'ai mémoire de contributeurs qui étaient parmi les plus imbus d'eux-même et en général, en plus d'être des personnes assez imbuvables dans les échanges, c'étaient en fait de mauvais développeurs (mais vraiment en plus; j'ai un exemple en tête notamment de quelqu'un qui faisait vraiment du très mauvais code et s'énervait dès qu'on y touchait pour le nettoyer, debugger et réorganiser, car il pouvait plus y toucher… pour lui, on détruisait son code parfait!).
Bon pour conclure, je ferai pas de commentaire sur le fond du sujet car on peut pas, tout simplement. Cette personne soulève juste du vent pour l'instant pour se mettre en valeur en écrasant d'autres. Peut-être est-ce une chercheuse en sécurité absolument géniale, qu'elle a totalement raison et que les dévs étaient réellement mauvais et de mauvaise foi. On n'en sait rien, on nous donne rien pour en juger. Mais c'était juste un petit discours sur le sujet général des chercheurs en sécurité qui essaient de plus en plus de faire le buzz, parfois avec de vrais trucs, mais souvent quand même un peu avec du vent, et c'est vrai que c'est un peu fatigant.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
La faille est assez sérieuse et concerne le service CUPS. C'est une faille sérieuse, mais concerne très marginalement les serveurs exposés sur Internet (Web, DNS, SMTP, …).
Dans un environnement hostile (écoles d'ingé, certaines entreprises, …), il conviendra de faire les MAJ. Maintenant on connait les n° de CVE:
- CVE-2024-47076 dans libcupsfilters,
- CVE-2024-47175 dans libppd
- CVE-2024-47176 dans cups-browsed
- CVE-2024-47177 dans cups-filters
a vos apt update ; apt upgrade, et que ca ne traine pas, hein !
Le port UDP 631 atteignable, c'est un peu le but de la découverte automatique des imprimantes, non ? Donc si cups-browser est actif, j'ai l'impression que c'est faisable.
Et l'exploit présenté ici n'utilise même pas les multiple buffer overflow découverts dans cups-browser. J'imagine qu'une version plus élaborée pourrait être plus trompeuse pour l'utilisateur, voire mener à de l'éxécution de code dans le contexte de cups-browser…
Donc, oui, il faut patcher, mais un correctif est-il seulement disponible ?
Le port UDP 631 atteignable, c'est un peu le but de la découverte automatique des imprimantes, non ? Donc si cups-browser est actif, j'ai l'impression que c'est faisable.
Oui, mais le port est bloqué sur mon firewall. Donc il faut que cups-browser soit actif, et que l'attaquant soit sur un range d'IP autorisé. Ca fait pas beaucoup.
Après, comme disait quelqu'un "j'ai ouvert mon port UDP 631 sur internet en grand car si quelqu'un pouvait s'occuper de paramétrer mon imprimante ça serait juste génial" :D
Et l'exploit présenté ici n'utilise même pas les multiple buffer overflow découverts dans cups-browser.
Certes. Mais avec un OS raisonnablement moderne, l'exploit ne va pas être tivial. Alors certes aussi, c'est pas impossible. Mais bon, comme on est dans l'état
octane@brouette:~$ ss -4 -l -n | grep 631
octane@brouette:~$ bah je suis pas trop inquiet.
Je suis pas sûr qu’un serveur critique ait besoin d’une imprimante.
La réciproque est vrai, si tu as configuré une imprimabte ou traceur sur une machine, incl. un serveur d’impression, ce n’est pas une machine critique.
Ce problème est quand même sérieux.
Alors la fin du monde promis par kes tribuns linkedin , ce ne sera pas pour aujourd’hui.
Y'a plein de métiers ou pouvoir imprimer est important, voire critique (au hasard, une imprimerie). Donc un serveur d'impression peut être considéré comme critique.
En tout cas l'imprimante du service proctologie du CHU du coin est plus critique pour moi que les load-balancers de Facebook.
MacOS je ne sais pas, mais je suis certain qu'il existe plein d'imprimantes réseau qui utilisent Cups en interne. Ce ne sera pas forcément les plus simples à exploiter, mais y'a pas forcément de mises à jours très longtemps sur ces bestioles.
Plus critique que le serveur pgsql des patients?
Ça risque de bloquer un service oui donc c’est vraiment majeur, mais ne va pas bloquer entièrement le prod.
C’est vrai en imprimerie, mais elles n’utilisent en général pas ssh sur leur machine.
Bref, ne pas tomber dans l’histérie est la meilleure chose à faire face aux fud et utiliser cupsd sur openbsd en attendant
# À la source
Posté par Voltairine . Évalué à 8 (+7/-0).
Le tweet de Simone Margaritelli
https://threadreaderapp.com/thread/1838169889330135132.html
Le ton est assez curieux mais on peu avoir un ego surdimensionné, être très mauvais communicant et être un bon expert en sécurité.
La gravité de la faille serait confirmée par RedHat et Canonical ce qui ne semble pas être l'avis des développeurs concernés et contactés par Simone Margaritelli. Wait and see…
Il est probable que les conditions d'exploitation de la faille la rendent beaucoup moins préoccupante que tente de le faire cette anonce tonitruante.
[^] # Re: À la source
Posté par nud . Évalué à 3 (+1/-0).
Un dimanche! Pratique!
[^] # Re: À la source
Posté par Jehan (site web personnel, Mastodon) . Évalué à 10 (+17/-0). Dernière modification le 26 septembre 2024 à 18:25.
C'est sûr que je retrouve dans son attitude quelque chose que je vois chez beaucoup d'autres "experts en sécurité": cette sensation qu'ils se sentent tellement importants qu'on devrait limite les idôlatrer et les couvrir de cadeaux pour les remercier et que le monde ne tournerait pas sans eux.
Quand je lis ce lien:
Les devs (ça ne dit pas de quel logiciel il s'agit) ont probablement fait de même pour développer leur logiciel, sauf que plutôt que 3 semaines, c'est depuis des années, voire décennies, et pour beaucoup d'entre eux en purs bénévoles.
Enfin je devine, puisqu'on parle de logiciel libre. Mais peut-être s'agit-il d'un logiciel d'entreprise?
De même que ces dévs, très probablement (du moins toujours dans l'hypothèse d'un logiciel communautaire).
LOL. Ce morceau de phrase vaut de l'or. Si qualifier leur code de "crap", c'est pas un symptôme même de "patronization" (prendre de haut, en gros), je sais pas ce que c'est. Un peu l'hôpital qui se fout de la charité.
Enfin bon… moi non plus, je n'ai aucune idée de quoi il s'agit et peut-être y a-t-il de vrais gros problèmes derrière cette "annonce tonitruante", mais je sais aussi que du point de vue dév, beaucoup "d'experts en sécurité" sont surtout fatigants. Ils arrivent sur leurs grands chevaux et limite veulent que la terre s'arrête de tourner le temps qu'ils soient là. On devrait tout arrêter et se préoccuper d'eux à temps plein de préférence (même lorsqu'on fait ça sur son temps libre et qu'on a une vie derrière).
On sent bien d'ailleurs dans le ton du message que cette personne ne s'est pas sentie suffisamment prise en compte, qu'elle a pris 3 semaines de son temps libre et donc que les dévs devraient se soumettre à elle à temps plein et ce bout de phrase qu'on lit si souvent est le parfait example:
Et oui, j'ai tronqué la phrase dont le reste explique que les dévs ont tort et que leur code est faux, parce que… ça ne change rien au problème.
Et oui mais… non, la plupart des dévs de logiciel libre n'ont aucune responsabilité dans la correction de bug. Désolé, c'est même expliqué dans la licence de la plupart des logiciels libres, par exemple la GPL:
C'est d'autant plus vrai quand les développeurs sont bénévoles (ce qui est le cas d'énormément de logiciels libres), mais même lorsqu'ils sont payés pour le faire! Souvent on est payés dans un contexte. Par exemple, on peut être rémunérés pour pouvoir améliorer et utiliser le logiciel dans un contexte professionnel (par exemple: usage en production d'un film! 😛), pas parce qu'on le vend en service. Le fait que le logiciel soit aussi librement (et gratuitement) à disposition à côté n'est qu'un petit bonus parce qu'on ne fait pas partie des gens qui veulent s'approprier tous les moyens de production et raquer le moindre sou sur le dos du sacro-saint "droit d'auteur". Donc on laisse notre code pour que d'autres puissent le reprendre, le modifier et si ça leur plaît mais qu'ils trouvent des problèmes qui les gênent particulièrement (genre… un bug de sécurité!), ils sont libres de corriger eux-même (ou de payer des gens pour le faire: me sortez pas le vieil argument de "tout le monde est pas dév" -> on est aussi libres de pas utiliser un logiciel trop troué, comme on est libre de l'améliorer ou le faire améliorer, ce sans en faire porter la responsabilité sur ceux qui ont offerts le bout de code sans contrepartie; j'ai déjà eu des gens qui m'ont payé pour ajouter une fonctionnalité à un logiciel libre, et je parle pas de grosses boîtes mais bien de petits entrepreneurs! Si ton métier en dépend, c'est ton propre devoir de t'assurer de la sûreté de tes outils — et vérifier aussi qu'ils correspondent vraiment à ce dont tu as besoin pour ton usage —, pas celui d'autrui, et surtout pas de celui qui t'aurait en plus offert ces outils).
Le seul cas où on aurait effectivement une responsabilité, c'est si on avait vendu un logiciel sous la forme d'une licence ou service et qu'on découvre alors que ça présente un risque pour le client. Là oui, bien sûr. Mais hormis ça si un quidam moyen prend notre code sur internet, c'est sa responsabilité (tant qu'on n'a pas mis de failles exprès pour nous même agir contre eux, bien sûr, là c'est non seulement notre responsabilité, mais surtout illégal et un délit/crime).
Enfin bon, ce genre de comportements est exactement pourquoi tant de développeurs finissent par être dégoûtés du logiciel libre et un jour décident de tout laisser tomber. Dans les réponses aux tweets, je vois même que certains parlent de "mettre la pression" aux développeurs, etc. On se demande parfois si les gens se rendent compte qu'ils parlent d'autres humains avec une vie, des sentiments…
On se retrouve exactement dans le cas de figure du XKCD sur les dépendances avec le pauvre mainteneur d'un truc critique qui s'en prend plein la tronche et doit absolument agir vite (pour avant-hier svp) quand le gentil "expert sécurité" et les grosses boîtes qui se font plein de sous en vendant du service sur le logiciel offert en libre (RedHat, Canonical… mentionnés dans le billet) mettent la pression pour une correction.
Je me dis aussi que beaucoup du bruit généré est surtout une bonne excuse pour cette personne qui ne veut plus avoir à s'embêter à faire du "responsible disclosure" à l'avenir, c'est à dire ne plus s'embêter à être une personne décente qui ne met pas les autres dans la panade pour son gain personnel:
Ma conclusion sera sur le même commentaire que cette personne cite dans son message:
Apparemment (si je comprends bien, c'est pas dit clairement de qui est cette citation, on ne peut que deviner), ce serait une copie de ce qu'un des développeurs du logiciel ciblé a dû écrire dans le rapport de bug. Clairement cette "experte" finit sur cette citation pour se moquer mais je vais me permettre un tout autre point de vue dessus.
Déjà: c'est vrai (bon là on a tous le même point de vue!). Et surtout c'est bien d'en être conscient. Cela montre que ces développeurs ne sont pas de complets néophytes imbus d'eux même. Ensuite pourquoi c'est vrai? Parce que l'environnement du logiciel (libre et non libre) a énormément changé. Le "paradigme" a changé, dira-t-on pour briller lors des soirées. En une vingtaine d'années, on est passé de développements énormément basés sur la confiance des autres, sur l'échange, à un paradigme où il faut absolument se méfier de tout. On est dans un monde où une personne (qui n'est peut-être même pas une unique personne en vrai) peut prendre 3 ans de sa vie, prendre le temps de faire de l'ingéniérie sociale des années pour devenir mainteneur, etc. pour introduire des failles; on est dans un monde avec beaucoup plus de gens utilisant sans arrêt des logiciels et où les malwares pullulent dans des "stores" divers (et pas que dans les OS de téléphones, des cas ont été notifiés même sur les GNU/Linux historiques). La raison même pour laquelle les sandboxes (bacs à sable) tels que Flatpak et Snap existe est d'ailleurs ce problème sécuritaire: on ne peut plus faire confiance aux autres, et donc a fortiori aux développeurs de logiciels. Donc il faut bloquer de partout (quitte à perdre des fonctionnalités historiques ce qui fait grincer beaucoup de dents chez les développeurs qui sont là depuis longtemps et ne faisaient rien de mal).
On est donc effectivement dans ce monde, cet entre-deux, où beaucoup de logiciels ont des failles diverses — qui parfois étaient même considérées comme des fonctionnalités à une époque pas si lointaine! —, ce qui a toujours été le cas, et il faut effectivement les corriger, mais s'en étonner ou sembler outrée par ce fait montre seulement une forme d'amateurisme. Des bugs, j'en corrige toutes les semaines, à la volée. Et non, ce n'est pas parce que mon code (ou celui des autres dévs avec qui je contribue) est mauvais. C'est juste la vie. On est humain, on fait des erreurs (non l'IA ne ferait pas mieux), on apprend constamment, et c'est la vie d'un logiciel. Ces "experts" font un énorme pataquès de trucs qu'on corrige tous les jours, souvent parce qu'ils ne comprennent pas grand chose au développement (en fait, je ne suis pas sûr avoir jamais reçu un patch de la part de gens qui se présentaient comme experts/chercheurs en sécurité, ou alors de mauvais patchs qu'on ne pouvaient pas utiliser car ils font juste un changement vite fait sur le symptôme, ce qui créerait juste de nouveaux bugs si on l'acceptait). Et c'est pourquoi ils sont étonnés ou moqueurs devant ce type de déclaration alors que ça ne fait que montrer leur méconnaissance. Mais oui, en vrai, des bugs qui peuvent être exploités, aisément pour certains, si trouvés, il y en a à la pelle dans tous les logiciels.
Et un développeur qui ne serait pas conscient de cela et croit faire du code parfait, ben désolé, ce serait lui le mauvais développeur. Ça me fait d'ailleurs penser à cette discussion qui s'est récemment produite entre Linus et le mainteneur de bcachefs parce que ce dernier essayait de pousser du code de développement trop proche des sorties. Et ce dernier assurait que son code était super bon et n'avait aucun bug pour sûr, ce à quoi Linus rétorquait qu'il veut pas lire ce type d'absurdités de la part d'un mainteneur d'une partie du noyau. Car oui, les logiciels ont des bugs, tous. Constamment. Et beaucoup de ceux-ci peuvent effectivement être exploités (avec les bonnes conditions, qui heureusement est la partie plus compliquée à mettre en place). Ceux qui croient le contraire, c'est en général mauvais signe. J'ai mémoire de contributeurs qui étaient parmi les plus imbus d'eux-même et en général, en plus d'être des personnes assez imbuvables dans les échanges, c'étaient en fait de mauvais développeurs (mais vraiment en plus; j'ai un exemple en tête notamment de quelqu'un qui faisait vraiment du très mauvais code et s'énervait dès qu'on y touchait pour le nettoyer, debugger et réorganiser, car il pouvait plus y toucher… pour lui, on détruisait son code parfait!).
Bon pour conclure, je ferai pas de commentaire sur le fond du sujet car on peut pas, tout simplement. Cette personne soulève juste du vent pour l'instant pour se mettre en valeur en écrasant d'autres. Peut-être est-ce une chercheuse en sécurité absolument géniale, qu'elle a totalement raison et que les dévs étaient réellement mauvais et de mauvaise foi. On n'en sait rien, on nous donne rien pour en juger. Mais c'était juste un petit discours sur le sujet général des chercheurs en sécurité qui essaient de plus en plus de faire le buzz, parfois avec de vrais trucs, mais souvent quand même un peu avec du vent, et c'est vrai que c'est un peu fatigant.
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
# suite de l'affaire Simone Margaritelli
Posté par Marc Quinton . Évalué à 6 (+4/-0).
La faille est assez sérieuse et concerne le service CUPS. C'est une faille sérieuse, mais concerne très marginalement les serveurs exposés sur Internet (Web, DNS, SMTP, …).
https://www.it-connect.fr/linux-failles-de-securite-dans-cups-execution-de-code-a-distance/
Dans un environnement hostile (écoles d'ingé, certaines entreprises, …), il conviendra de faire les MAJ. Maintenant on connait les n° de CVE:
- CVE-2024-47076 dans libcupsfilters,
- CVE-2024-47175 dans libppd
- CVE-2024-47176 dans cups-browsed
- CVE-2024-47177 dans cups-filters
a vos
apt update ; apt upgrade, et que ca ne traine pas, hein ![^] # Re: suite de l'affaire Simone Margaritelli
Posté par vitanix . Évalué à 4 (+4/-0). Dernière modification le 27 septembre 2024 à 08:54.
L'auteur a fait un article pour présenter les problèmes rencontrés :
https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/
A la fin de l'article il explique les problèmes qu'il a eu pour que les développeurs concernés prenne en considération l'exploit.
[^] # Re: suite de l'affaire Simone Margaritelli
Posté par Jehan (site web personnel, Mastodon) . Évalué à 7 (+4/-0).
Euh… et le "responsable disclosure"? C'est déjà fini? 🤦♂️
Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]
[^] # Re: suite de l'affaire Simone Margaritelli
Posté par octane . Évalué à 4 (+2/-0).
le rapport a leaké ailleurs, donc il a plus de raison de garder le sien sous embargo
# ouais ouais ouais
Posté par octane . Évalué à 10 (+8/-0).
Donc.
Il faut que ton port UDP 631 soit atteignable.
Il faut que tu choisisses d'imprimer sur une imprimante que tu n'as jamais vu avant.
Alors là, le méchant pirate peut exécuter du code.
Ca m'a pas l'air très sérieux tout ça.
Oui c'est grave, oui, faut patcher, oui faut prendre ça en compte, non faut pas couiner sur internet que c'est la fin du monde
[^] # Re: ouais ouais ouais
Posté par Christophe . Évalué à 3 (+1/-0).
Le port UDP 631 atteignable, c'est un peu le but de la découverte automatique des imprimantes, non ? Donc si cups-browser est actif, j'ai l'impression que c'est faisable.
Et l'exploit présenté ici n'utilise même pas les multiple buffer overflow découverts dans cups-browser. J'imagine qu'une version plus élaborée pourrait être plus trompeuse pour l'utilisateur, voire mener à de l'éxécution de code dans le contexte de cups-browser…
Donc, oui, il faut patcher, mais un correctif est-il seulement disponible ?
[^] # Re: ouais ouais ouais
Posté par Marc Quinton . Évalué à 5 (+3/-0).
Ubuntu : c'est réglé !
[^] # Re: ouais ouais ouais
Posté par octane . Évalué à 4 (+2/-0).
Oui, mais le port est bloqué sur mon firewall. Donc il faut que cups-browser soit actif, et que l'attaquant soit sur un range d'IP autorisé. Ca fait pas beaucoup.
Après, comme disait quelqu'un "j'ai ouvert mon port UDP 631 sur internet en grand car si quelqu'un pouvait s'occuper de paramétrer mon imprimante ça serait juste génial" :D
Certes. Mais avec un OS raisonnablement moderne, l'exploit ne va pas être tivial. Alors certes aussi, c'est pas impossible. Mais bon, comme on est dans l'état
octane@brouette:~$ ss -4 -l -n | grep 631
octane@brouette:~$
[^] # Re: ouais ouais ouais
Posté par Eh_Dis_Mwan . Évalué à 3 (+2/-0).
Je suis pas sûr qu’un serveur critique ait besoin d’une imprimante.
La réciproque est vrai, si tu as configuré une imprimabte ou traceur sur une machine, incl. un serveur d’impression, ce n’est pas une machine critique.
Ce problème est quand même sérieux.
Alors la fin du monde promis par kes tribuns linkedin , ce ne sera pas pour aujourd’hui.
Macos utilise toujours cupsd?
[^] # Re: ouais ouais ouais
Posté par cg . Évalué à 1 (+0/-1).
Y'a plein de métiers ou pouvoir imprimer est important, voire critique (au hasard, une imprimerie). Donc un serveur d'impression peut être considéré comme critique.
En tout cas l'imprimante du service proctologie du CHU du coin est plus critique pour moi que les load-balancers de Facebook.
MacOS je ne sais pas, mais je suis certain qu'il existe plein d'imprimantes réseau qui utilisent Cups en interne. Ce ne sera pas forcément les plus simples à exploiter, mais y'a pas forcément de mises à jours très longtemps sur ces bestioles.
[^] # Re: ouais ouais ouais
Posté par Eh_Dis_Mwan . Évalué à 1 (+0/-0).
Plus critique que le serveur pgsql des patients?
Ça risque de bloquer un service oui donc c’est vraiment majeur, mais ne va pas bloquer entièrement le prod.
C’est vrai en imprimerie, mais elles n’utilisent en général pas ssh sur leur machine.
Bref, ne pas tomber dans l’histérie est la meilleure chose à faire face aux fud et utiliser cupsd sur openbsd en attendant
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.