DSM 4.3 et 5.x : Synology corrige la faille Shellshock, mais de manière partielle

DSM 4.3 et 5.x : Synology corrige la faille Shellshock, mais de manière partielle

Bientôt au tour de Thecus ?

Avatar de l'auteur
Sébastien Gavois

Publié dans

Sciences et espace

02/10/2014 3 minutes
34

DSM 4.3 et 5.x : Synology corrige la faille Shellshock, mais de manière partielle

Après QNAP, c'est donc au tour de Synology de publier une mise à jour de son Disk Station Manager (alias DSM) et il est évidemment question de boucher la faille Shellshock. Mais, à l'instar d'Apple, cela ne concerne que les deux premières découvertes et pas les deux autres, plus récentes.

Depuis la semaine dernière, la brèche Shellshock du Bash secoue Internet. Il faut dire qu'elle est importante et qu'on la compare souvent à Heartbleed puisqu'on la retrouve sur un nombre très important de systèmes : Linux, OS X, Unix et leurs dérivés. Bien évidemment, un premier correctif a rapidement été mis en ligne... puis un second, suite à une nouvelle faille. Depuis, deux autres ont été identifiées et cela pourrait continuer maintenant que le service est passé au peigne fin par de nombreuses personnes.

Synology corrige les deux premières failles de Shellshock, mais pas les autres 

Plusieurs sociétés ont évidemment publié des mises à jour. On retrouve ainsi Apple avec OS X Lion, Mountain Lion et Mavericks (pas Yosemite), suivi de près par QNAP. Mais dans les deux cas, cela ne concerne qu'une partie du problème, QNAP ne corrigeant par exemple que la toute première faille. À l'instar de la firme à la pomme, Synology propose désormais un correctif pour les deux premiers bulletins de sécurité estampillés CVE-2014-6271 et CVE-2014-7169. Pour les autres, il faudra donc certainement attendre une nouvelle mise à jour.

 

La bonne nouvelle, c'est que Synology reste fidèle à son habitude et propose une mise à jour de son DSM 4.3 et du DSM 5.0, laissant ainsi le choix à ses clients. De plus, le DSM 5.1 en version bêta a également le droit à son correctif dédié. Aucun autre changement n'est annoncé dans les notes de version.

 

Vous pouvez les installer directement depuis l'interface d'administration, ou les télécharger en suivant l'un des liens suivants : DSM 4.3 3827 Update 8, DSM 5.0 4493 Update 7 et DSM 5.1 4977 Update 1. Pour rappel, tous les NAS du taiwanais ne sont pas concernés (la liste complète se trouve par ici), et tous n'ont donc pas forcément une mise à jour qui les attend.

Thecus au courant, l'équipe R&D sur le brèche

De son côté, Thecus n'a toujours pas communiqué officiellement sur la question. Néanmoins, plusieurs clients ont remonté le problème à la société via ses forums et le responsable presse France indique que la balle est désormais dans le camp de l'équipe de recherche et développement. Une mise à jour devrait donc arriver prochainement.

Écrit par Sébastien Gavois

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Synology corrige les deux premières failles de Shellshock, mais pas les autres 

Thecus au courant, l'équipe R&D sur le brèche

Commentaires (34)


Pas besoin de reboot pour une fois <img data-src=" />


j’aime les 1511+ … concernés mais sans update <img data-src=" />


Ce côté alarmiste m’éclate au plus haut point.

Parcque vous croyez qu’il y a un HeartBleed , un ShellShock ?

Et les 200 autres failles que vous ne connaissez pas encore, elles vous disent quoi ?



Allez … bon biz.


Ca n’a pas l’air d’etre dispo pour tous les Syno visiblement…



Mon DS210j ne m’annonce pas de maj encore…


J’ai eu l’update 7, no problem








KP2 a écrit :



Ca n’a pas l’air d’etre dispo pour tous les Syno visiblement…



Mon DS210j ne m’annonce pas de maj encore…





Tu peux attendre encore longtemps: seulement quelques rares modèles Synology spécifiques embarquent un shell bash

(et même sur ceux la, la possibilité d’explotation de la faille à distance est loin d’être démontrée)



….Tu es le NAS qui m´aille, je te le dis sans faille

Reste cool bébé, sinon j´te dirai : “Bye bye”. <img data-src=" />








ledufakademy a écrit :



Ce côté alarmiste m’éclate au plus haut point.

Parcque vous croyez qu’il y a un HeartBleed , un ShellShock ?

Et les 200 autres failles que vous ne connaissez pas encore, elles vous disent quoi ?



Allez … bon biz.







Bah elles disent rien, on les connait pas… Tu te proposes de les corriger ? Tu prends cher ? <img data-src=" />









ledufakademy a écrit :



Ce côté alarmiste m’éclate au plus haut point.

Parcque vous croyez qu’il y a un HeartBleed , un ShellShock ?

Et les 200 autres failles que vous ne connaissez pas encore, elles vous disent quoi ?



Allez … bon biz.







Et ? Sous prétexte qu’il y en a d’autres tu proposes qu’on ne fasse rien dans l’urgence ?



Une faille connue voit son utilisation augmenter de façon exponentielle. Il me parait plus que logique de la corriger ASAP.



Bref…









the_Grim_Reaper a écrit :



j’aime les 1511+ … concernés mais sans update <img data-src=" />





411+II idem <img data-src=" />



Moi j’arrive déjà pas a y accéder avec les pass à mon NAS alors je crains rien :p








Séphi a écrit :



Et ? Sous prétexte qu’il y en a d’autres tu proposes qu’on ne fasse rien dans l’urgence ?



Une faille connue voit son utilisation augmenter de façon exponentielle. Il me parait plus que logique de la corriger ASAP.



Bref…





tu connais quelques choses au dark web ?

tu connais les dernières failles (hors news mediatico/emotionnelles) ?

tu connais les prices de reventes de ces failles?

tu connais les canaux d’échanges ?



non. tu t’y intéresses comme moi j’ai eu à le faire, et on en reparles calmement.

Ou alors interroge Eric FILLIOL : il t’en apprendra plus que ce genre de news.



Tu veux sauver tes fesses ou celles de tes/Vos données ?

bosses sur un PRA béton et planifies des tests de récupération après désastre en fonctions de la criticité de ce que tu as à protéger : le reste c’est de l’enfumage pour neuneux de la sécurité !



… penses sauvegardes le reste ne vaut quasiment rien.



Pour compléter ce qui est dit dans l’article: QNAP, dont les NAS (Japon, Corée et US principalement) sont spécifiquement la cible d’attaquants via Shellshock http://www.fireeye.com/blog/technical/2014/10/the-shellshock-aftershock-for-nas-… ) a publié un nouveau fix :http://forum.qnap.com/viewtopic.php?f=73&t=98188 (notamment pour les CVE-2014-6271, CVE-2014-7169, CVE-2014-6277, CVE-2014-7186, et CVE-2014-7187).








CoooolRaoul a écrit :



Tu peux attendre encore longtemps: seulement quelques rares modèles Synology spécifiques embarquent un shell bash

(et même sur ceux la, la possibilité d’explotation de la faille à distance est loin d’être démontrée)







Ah oui c’est vrai !!

La plupart des syno embarquent un Blackbox (ou un truc du genre - je sui pas sur du nom)









ledufakademy a écrit :



Tu veux sauver tes fesses ou celles de tes/Vos données ?

bosses sur un PRA béton et planifies des tests de récupération après désastre en fonctions de la criticité de ce que tu as à protéger : le reste c’est de l’enfumage pour neuneux de la sécurité !







Un PRA ? Mais LOL…. Un PRA est une solution de réparation… En aucun cas un PRA te protègera contre des attaques…



Parce que tu crois qu’une attaque va tout simplement supprimer tes données façon “OLOL il a plus rien OLOL” ?



Et ne me sort pas de grands mots comme “drak web” et autres canaux d’échanges qui sont pour moi des mots assez banals en fait….

Bref t’as raison, ne protégeons rien et ne proposons que du PRA avec un RTO de quelques secondes/minutes. La confidentialité des données on s’en fout….









KP2 a écrit :



Ca n’a pas l’air d’etre dispo pour tous les Syno visiblement…



Mon DS210j ne m’annonce pas de maj encore…







Tu n’es pas dans la liste (lis jusqu’au bout !)









ledufakademy a écrit :



tu connais quelques choses au dark web ?

tu connais les dernières failles (hors news mediatico/emotionnelles) ?

tu connais les prices de reventes de ces failles?

tu connais les canaux d’échanges ?



non. tu t’y intéresses comme moi j’ai eu à le faire, et on en reparles calmement.

Ou alors interroge Eric FILLIOL : il t’en apprendra plus que ce genre de news.



Tu veux sauver tes fesses ou celles de tes/Vos données ?

bosses sur un PRA béton et planifies des tests de récupération après désastre en fonctions de la criticité de ce que tu as à protéger : le reste c’est de l’enfumage pour neuneux de la sécurité !



… penses sauvegardes le reste ne vaut quasiment rien.









Attend mec… pourquoi tu montes sur tes grands chevaux ?



Que vient faire un expert Crypto dans l’histoire sachant qu’on parle d’une faille bash qui n’a rien à voir avec une quelconque cryptographie?



Ensuite ton PRA il te sert à quoi? faire de la sauvegarde.. oui.. mais ça n’empêche en rien une attaque ça.. tout au mieux ça te permet de ne pas te faire effacer tes données… ça n’empêche en rien que le gars peut les exploiter au final..



Et au pire tu pourras aussi sauvegarder pas mal de backdoors qu’il t’aura laissé dans ton système si jamais tu ne l’as pas détecté.



Si je peux me permettre… si tu veux vraiment donner des conseils pour se protéger de tout ça alors je conseille plutôt de dire:





  • Toujours mettre à ses tes systèmes exposées au net (ainsi que les autres derrière bien évidemment).

  • Utiliser un IPS/IDS et du honey pot pour prévenir les attaques frontales et essayer de gagner du temps.

  • Faire du remote log sur des serveurs distants de tes serveurs front end pour t’assurer que le pirate ne puisse pas effacer ses traces facilement.

  • T’inscrire sur des mailing liste de sécu afin de recevoir les dernières news sur les exploits dès que possible.

  • Séparer ton serveur passerelle de tes NAS/serveurs de données et au mieux utiliser plusieurs systèmes d’exploit pour éviter de se faire avoir avec une seule faille, mais multiplier les difficultés pour l’attaquant.

  • Utiliser toi même les outils de hacking contre tes serveurs, régulièrement, pour savoir ton niveau de compliance et de sécu par rapport aux dernières failles.





    Et encore… c’est vraiment pas parfait ce que je propose.. il y a tellement de conseils à donner et de choses à regarder que.. sauf si t’es spécialisé là dedans et que tu ne fais que ça de ta journée… le mieux finalement c’est de ne pas connecter tes données à internet et au moins on n’en parle plus.



    Laisse ton NAS sans aucun ethernet/wifi et passe par une clef usb pour récupérer tes données… finalement c’est presque le plus safe <img data-src=" />









Fredoo a écrit :



411+II idem <img data-src=" />





+1 ils attendent quoi? <img data-src=" />









ledufakademy a écrit :



… penses sauvegardes le reste ne vaut quasiment rien.







Si tu savais combien Google, Facebook (pour les ‘gentils’) et compagnie (les vrais pirates) gagnent sans effacer une seule de tes données, voire même en les répliquant partout pour toi …

T’as rien compris aux problèmes de sécurité, l’effacement kikoolol des débuts des attaques webbased des années 80, ça fait longtemps que ça n’existe plus .. maintenant on monnaye tes data ou on t’empêche d’y accéder (et tes backup serviront à rien, ils seront ré-attaqués aussitôt que tu les auras restaurés), c’est d’un autre niveau … mais heureusement que tu t’es bien renseigné … <img data-src=" />









CoooolRaoul a écrit :



Tu peux attendre encore longtemps: seulement quelques rares modèles Synology spécifiques embarquent un shell bash

(et même sur ceux la, la possibilité d’explotation de la faille à distance est loin d’être démontrée)





C’est exactement ce que je me dis, et pas que pour les NAS.









Séphi a écrit :



….. La confidentialité des données on s’en fout….







a l’heure de facebook, google et la nsa, tu oses parler de confidentialités des données ? A l’heure ou toute la france, à 90 %, est sur du microsoft ?

je stope le débat.

tu ne m’apprends rien.









usky a écrit :



Tu n’es pas dans la liste (lis jusqu’au bout !)







Oui j’ai zappé une ligne… <img data-src=" />









Beurt-le-vrai a écrit :



Pour compléter ce qui est dit dans l’article: QNAP, dont les NAS (Japon, Corée et US principalement) sont spécifiquement la cible d’attaquants via Shellshock http://www.fireeye.com/blog/technical/2014/10/the-shellshock-aftershock-for-nas-… ) a publié un nouveau fix :http://forum.qnap.com/viewtopic.php?f=73&t=98188 (notamment pour les CVE-2014-6271, CVE-2014-7169, CVE-2014-6277, CVE-2014-7186, et CVE-2014-7187).





Est-ce que tu as compris par quel mécanisme, la chaîne de caractère de l’User-Agent se retrouve exécutée par bash sur le QNAP ? <img data-src=" />









ledufakademy a écrit :



a l’heure de facebook, google et la nsa, tu oses parler de confidentialités des données ? A l’heure ou toute la france, à 90 %, est sur du microsoft ?

je stope le débat.

tu ne m’apprends rien.







Ben voyons…. Va dire ça aux entreprises… Je sens qu’on va rire un peu.



Je ne sais pas si je t’apprends quelque chose ou pas mais toi tu risques de me faire régresser.



Allez bisous <img data-src=" />









Séphi a écrit :



Ben voyons…. Va dire ça aux entreprises… Je sens qu’on va rire un peu.



Je ne sais pas si je t’apprends quelque chose ou pas mais toi tu risques de me faire régresser.



Allez bisous <img data-src=" />









Bon, soyons sérieux deux minutes… on va récapituler..



Les données de monsieur et madame Michu (pour ne citer qu’elle, la pauvre vieille tite dame.. elle est souvent embêtée décidémment…) ne sont pas vraiment des données qu’elle souhaite cacher.

En effet, elle utilise facebook (c’est mal, je suis d’accord) et n’a donc aucun respect pour sa vie privée.

Elle a aussi une boite mail google et se fait tracer. Cool!





En fait je crois qu’on parlait d’un autre niveau en fait… de données d’entreprises hyper sensibles..



Dans chaque entreprise un tant soit peu sérieuse… les webmails perso sont interdites.. déjà.. voilà.



Les mails sont filtrés via antivirus, règles en tout genre et le tout passe par des serveurs spécialisés. Déjà côté mail c’est plus clean.



Les proxy servent à filtrer les accès internet des gens. Donc normalement on évite de laisser trainer des sites douteux qui pourraient mettre en danger l’entreprise via un malware ou n’importe.



Les workstations sont isolées des serveurs via des dmz/firewalls, appliances… et antivirus. + patchs automatiques.



Tu crois sincèrement qu’un pirate en a quelque chose à faire du numéro de téléphone de Michu ou bien de son mot de passe? ils sont déjà connus.. il va se faire ch.. pour quoi? exploiter une vulnérabilité Bash pour récupérer quoi sur un NAS? le dernier film de captain brackmard? .. pourquoi faire?



Non.. ce qui intéresse les pirates c’est plutôt la possiblité d’accéder à des données sensibles des entreprises, avec des shemas, des propales… qu’il pourra ensuite revendre ou bien qui lui permettra de planifier par rebond une attaque sur une société connectée au réseau de la première boite…





Donc OUI! les données sont sensibles et les entreprises ne mettent pas des schemas tactiques et administratif sur google. La NSA a de toute façon accès à pratiquement tout… mais ils commencent à pleurer parce que les gens font de la sécurité et ça devient réellement difficile maintenant de rentrer dans une entreprise “vraiment” sécurisée (j’ai pas dit impossible).



Dernier point… je ne sais pas où il a vu que les données étaient toutes sur des serveurs windows…. pour ma part je vois plus les données sur des filers UNIX/LINUX ou bien des appliances spécialisées….



Il ne faut pas mélanger la confidentialité des gens en général et des entreprises… deux mondes à part.



Pour ma part je fais ZERO sécurité chez moi parce que de toute façon je n’ai pas réellement les moyens et l’envie de faire de la sécu poussée @home et ça ne servira pas à grand chose parce que je n’ai rien de sensible.



Par contre ça ne veut pas dire que c’est open bar… y’a quand même un minimum de fait pour éviter de servir de rebond/zombie…



A contrario.. au boulot… c’est clairement pas open bar… <img data-src=" />





Tout ça pour dire.. +1 Séphi avec toi. Je crois que ce monsieur est juste parano et confond plusieurs sujets.. celui de la privacy des utilisateurs lambda et celle des entreprises qui sont deux mondes différents pour moi.



<img data-src=" />



Petite question



Est-ce qu’on court un risque si le seul service ouvert est OpenVPN (avec certificat + auth) sur le NAS ? (pour ensuite accéder aux différents services du NAS)



Merci


A noter que Freenas a déjà publié une mise à jour pour Shellshock. Comme quoi la réactivité de ces boites n’est pas folle.








Soltek a écrit :



Pas besoin de reboot pour une fois <img data-src=" />





Si seulement ça pouvait devenir une habitude.









OlivierJ a écrit :



Est-ce que tu as compris par quel mécanisme, la chaîne de caractère de l’User-Agent se retrouve exécutée par bash sur le QNAP ? <img data-src=" />







Oui bien sûr ! C’est une des attaques de base liées à Shellschock dans laquelle Apache est utilisé comme passe plat pour transmettre via des variables d’environnement des instructions qui seront exécutées… cf.https://linuxfr.org/news/une-faille-nommee-shellshock qui explique ça très bien.









Beurt-le-vrai a écrit :



Oui bien sûr ! C’est une des attaques de base liées à Shellschock dans laquelle Apache est utilisé comme passe plat pour transmettre via des variables d’environnement des instructions qui seront exécutées… cf.https://linuxfr.org/news/une-faille-nommee-shellshock qui explique ça très bien.





Eh bien en fait non, ça n’explique pas par quelle magie la valeur de User-Agent va être exécutée par bash sur le QNAP. Cette valeur est juste utile soit pour les logs, soit parfois pour envoyer une réponse différenciée selon le User-Agent (en comparant ce UA avec des motifs, rien à voir avec son exécution).



L’article linuxfr précise bien : “avoir un service qui écoute le réseau et qui va exécuter bash” (et j’ajoute : avec des données envoyées, et pas n’importe lesquelles).

Le fait que OpenVPN et FTP soient dans le liste des programmes vulnérables est fâcheux (et m’étonne aussi).









the_Grim_Reaper a écrit :



j’aime les 1511+ … concernés mais sans update <img data-src=" />





Le mien a eu sa mise à jour hier (en version DSM 4.3).









OlivierJ a écrit :



Eh bien en fait non, ça n’explique pas par quelle magie la valeur de User-Agent va être exécutée par bash sur le QNAP. Cette valeur est juste utile soit pour les logs, soit parfois pour envoyer une réponse différenciée selon le User-Agent (en comparant ce UA avec des motifs, rien à voir avec son exécution).



L’article linuxfr précise bien : “avoir un service qui écoute le réseau et qui va exécuter bash” (et j’ajoute : avec des données envoyées, et pas n’importe lesquelles).

Le fait que OpenVPN et FTP soient dans le liste des programmes vulnérables est fâcheux (et m’étonne aussi).







Justement, les contenus des variables d’environnement reçues par apache (comme l’user-agent) sont passées à bash dans certains cas (quand apache a besoin de lancer d’autres programmes par exemple, ce qu’il fait via le shell)… En détail tu as ça:http://blog.cloudflare.com/inside-shellshock/









Beurt-le-vrai a écrit :



Justement, les contenus des variables d’environnement reçues par apache (comme l’user-agent) sont passées à bash dans certains cas (quand apache a besoin de lancer d’autres programmes par exemple, ce qu’il fait via le shell)… En détail tu as ça:http://blog.cloudflare.com/inside-shellshock/





Ah, j’ai enfin une explication qui semble satisfaisante avec ton article, merci. <img data-src=" />

Je retiens surtout :



If that variable gets passed into bash by the web server, the Shellshock problem occurs. This is because bash has special rules for handling a variable starting with () { :; };. Rather than treating the variable HTTP_USER_AGENT as a sequence of characters with no special meaning, bash will interpret it as a command that needs to be executed



Pour ma part, les serveurs que j’administre étant des LAMP (apache+mod_php), il faudrait que je regarde si dans le code (écrit par une société tierce), il y a des appels du type “system”. Mais en principe, comme lu chez RedHat, le couple apache+mod_php n’est pas concerné, probablement parce que l’appel à system() est fait sans variable d’environnements par défaut.









tmtisfree a écrit :



Le mien a eu sa mise à jour hier (en version DSM 4.3).





Le miens est en DSM 5.0 update 5, mais j’ai pas le droit encore à l’update 7 qui concerne ce problème.