Apple corrige deux failles liées à Shellshock, mais deux autres sont déjà là

Apple corrige deux failles liées à Shellshock, mais deux autres sont déjà là

Les testeurs de Yosemite devront attendre

Avatar de l'auteur
Vincent Hermann

Publié dans

Logiciel

30/09/2014 3 minutes
63

Apple corrige deux failles liées à Shellshock, mais deux autres sont déjà là

Apple avait promis une mise à jour de sécurité pour corriger les failles relatives à Bash, et c’est désormais chose faite. Lion, Mountain Lion et Mavericks sont concernés par la mise à jour, mais alors que les deux failles connues sont colmatées, deux autres pointent le bout de leur nez.

Apple corrige les deux failles qui avaient été recensées

La faille touchant Bash, estampillée Shellshock, a provoqué l’arrivée de nombreuses mises à jour pour les systèmes d’exploitation concernés, pour la plupart des dérivés d'Unix et de Linux. Apple avait néanmoins réagi pour expliquer que les utilisateurs d’OS X n’avaient pas de raison de craindre cette faille, en dépit des fondations Unix du système maison. Pourquoi ? Parce qu'elle ne peut être exploitée que lorsque Bash est défini comme shell par défaut, ce qui ne peut arriver sous OS X à moins d’avoir configuré les services Unix dans ce sens.

 

Quoi qu’il en soit, Apple fournit désormais une série de mises à jour à télécharger en fonction du système concerné :

bash shellshock osxbash shellshock osx

Les tests ne font plus apparaître Shellshock dans les résultats après installation du correctif

 

On remarquera donc pour l’instant qu’aucune mise à jour n’est fournie pour Yosemite, actuellement en Developer Preview 8. Il y a fort à parier que la faille sera colmatée lors de la prochaine préversion. Notez en outre que les mises à jour ne sont pas encore disponibles dans les versions respectives de l’App Store. Il faut pour l’instant passer obligatoirement par les liens de téléchargement séparés pour installer les correctifs.

Deux autres failles apparaissent déjà

La première faille Shellshock a depuis enfanté d’autres petites brèches. Maintenant que les chercheurs en sécurité se sont penchés sur la question, Bash révèle d’autres faiblesses liées à sa gestion des variables d’environnement.

 

Comme indiqué par Ars Technica, le chercheur en sécurité David A. Wheeler a récemment indiqué dans un message sur la liste Open Source Software Security qu’il existait de vrais problèmes de sécurité avec Bash. En fait, les deux premiers patchs publiés ressemblent davantage selon lui à des rustines car ils ne commencent « même pas à résoudre le problème Shellshock sous-jacent ». Et d’expliquer que le parseur de Bash (qui analyse donc la syntaxe des commandes) n’a jamais été conçu pour être en phase avec les standards de sécurité d’aujourd’hui. Selon lui, Bash ne pourra pas être considéré comme sécurisé tant qu’il scannera automatiquement les variables d’environnement.

 

Il existe pour l’instant deux voies menant à des correctifs : l’une consiste à mettre en place des préfixes devant les fonctions Bash, l’autre à n’autoriser l’importation de variables d’environnement que lorsqu’elles sont spécifiquement réclamées. Mais dans un cas comme dans l’autre, ces changements cassent la rétrocompatibilité et demanderont souvent aux développeurs de revoir le fonctionnement de leurs applications.

 

Deux types de patchs sont donc en préparation, mais il est probable désormais que d’autres failles seront découvertes dans un futur proche. De fait, Apple et les autres éditeurs ont, dans la grande majorité des cas, corrigé les deux premières failles, mais il faut s'attendre à une autre série de correctifs.

Écrit par Vincent Hermann

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Apple corrige les deux failles qui avaient été recensées

Deux autres failles apparaissent déjà

Commentaires (63)


Cette faille met une sacré pagaille quand même.



Le pire c’est chez Amazon qui est obligé de rebooter EC2.



Ces prochaines semaines vont être tumultueuses. Déconnectez vos serveurs en attendant que ça se calme.


Ou utilisez sh ou ksh <img data-src=" />








gokudomatic a écrit :



Ces prochaines semaines vont être tumultueuses. Déconnectez vos serveurs en attendant que ça se calme.





Ou remplacez bash par un autre. C’est pas le seul shell qui existe sous Linux.

Par contre autant SSL je pouvais comprendre vu leur manque de moyen qu’il n’y ait pas d’audit & co, mais Gnu a quand même un peu plus de moyen je pense. Quand on cherche à construire un OS ça fait mal de se prendre des remarques comme ça : “le parseur de Bash n’a jamais été conçu pour être en phrase avec les standards de sécurité d’aujourd’hui” pour un truc aussi central que le shell…

Ou alors ils sont à la ramasse aussi niveau moyens (humains et financier)? Hurd prend trop de ressources <img data-src=" /> ?



bon, après une nuit à réinstaller ma CentOS suite à une pénétration douteuse, la prochaine nuit blanche sera consacrée à revenir sous FreeBSD …








loloemr a écrit :



Cette faille met une sacré pagaille quand même.



Le pire c’est chez Amazon qui est obligé de rebooter EC2.







Amazon a du reboot pas mal de machines à cause d’une faille dans Xen également. (tout comme Rackspace)









loloemr a écrit :



Cette faille met une sacré pagaille quand même.



Le pire c’est chez Amazon qui est obligé de rebooter EC2.





c’est une coincidence le fait que ca soit maintenant, c’est a cause d’une faille xen et pas bash.





Et d’expliquer que le parseur de Bash (qui analyse donc la syntaxe des commandes) n’a jamais été conçu pour être en phrase avec les standards de sécurité d’aujourd’hui.





Le code de Bash a été écrit dans les années 80 avec les standards des années 80 et n’a jamais été modifié.

Dans cet article, on a une petite vision de ce qu’il ne va pas dans le code.








cendrev3 a écrit :



c’est une coincidence le fait que ca soit maintenant, c’est a cause d’une faille xen et pas bash.





Oups, effectivement, on m’avait menti à l’insu de mon plein gré … et j’avais pas bien vérifié …<img data-src=" />









JCDentonMale a écrit :



Ou utilisez sh ou ksh <img data-src=" />





+1



Ou encore zsh, csh…









JCDentonMale a écrit :



Ou utilisez sh ou ksh <img data-src=" />





D’après ce qu’on sait pour le moment il n’y a pas de problème à utiliser bash en tant que shell (dans un terminal utilisateur).



Le problème de cette faille c’est quand bash est utilisé en tant qu’interpréteur de scripts pour des services (DHCP, CGI…). Dans ce cas il vaut mieux utiliser de vrais langages de programmation ( python, ruby)









Network a écrit :



“L’open source c’est plus securisé car tout le monde peut lire le code”

Un mauvais troll te répondra : entre heartbleed et shellshock, la sécurité opensource tire un peu la gueule.







Tout le monde peut lire le code oui, ça veut pas dire que tout le monde le fait ^^

De plus, un bon troll recentrera le débat sur le fait que open-source est censé faciliter les audit de code et que donc c’est plus sécurisé, omettra volontairement la partie ou la communauté produit des patch correctifs assez rapidement, et prouvera, en prenant comme exemple les failles que tu cites qui sont présentes (et surement exploité) depuis des années (20 pour shellshock), que très peu de personne ne lit les codes open source.



C’est un dialogue de sourd entre d’un côté l’argument : “mais au final personne ne relit les codes open sources, les développeur n’aiment pas ça et les auditeurs préfèrent le faire pour de l’argent”

Et de l’autre : “Oui mais au moins l’open source offre la possibilité de le faire ! C’est plus rassurant de savoir qu’on peut lire le code de ce qu’on installe sur son poste.”









Khalev a écrit :



Ou remplacez bash par un autre. C’est pas le seul shell qui existe sous Linux.

Par contre autant SSL je pouvais comprendre vu leur manque de moyen qu’il n’y ait pas d’audit & co, mais Gnu a quand même un peu plus de moyen je pense. Quand on cherche à construire un OS ça fait mal de se prendre des remarques comme ça : “le parseur de Bash n’a jamais été conçu pour être en phrase avec les standards de sécurité d’aujourd’hui” pour un truc aussi central que le shell…

Ou alors ils sont à la ramasse aussi niveau moyens (humains et financier)? Hurd prend trop de ressources <img data-src=" /> ?







Je dirais plutôt «honte à ceux qui écrivent des serveurs qui lancent des processus sans réfléchir à toutes les effarantes possibilités du programme utilisé».

Appeller bash pour faire certaines choses, c’est tendre le fouet pour se faire battre.

Ne pas vérifier l’environnement, c’est relier le fouet à une génératrice.









Jed08 a écrit :



en prenant comme exemple les failles que tu cites qui sont présentes (et surement exploité) depuis des années (20 pour shellshock), que très peu de personne ne lit les codes open source.





c’est surtout que les experts sécurité ont peu de raisons de s’intéresser à Bash: ils vont te dire de ne pas utiliser bash comme langage de script pour des services accessibles à distance.

Malheuresement ce genre de précaution n’a pas été prise pour certains logiciels comme le client DHCP de l’ISC



Il n’y a aucun vecteur d’attaque connu sur OSX actuellement avec ShellShock.

Sans parler du fait que 99% des Mac ne seront de toute façon jamais concerné par cette faille vu qu’extrêmement peu d’entre eux font tourner les services Unix nécessaire à pouvoir ensuite faire interpréter la variable par Bash.








Jed08 a écrit :



Le code de Bash a été écrit dans les années 80 avec les standards des années 80 et n’a jamais été modifié.

Dans cet article, on a une petite vision de ce qu’il ne va pas dans le code.





Je confirme et malheureusement y’a pas que bash…



Quelques exemples au hasard :














Jed08 a écrit :



Le code de Bash a été écrit dans les années 80 avec les standards des années 80 et n’a jamais été modifié.

Dans cet article, on a une petite vision de ce qu’il ne va pas dans le code.





J’imagine déjà les articles de 2040 qui vilipenderont le code écrit aujourd’hui.





  • Le code est écrit en C++, un langage connu pour n’avoir à peu près aucun mécanisme de sécurité, rendant très difficile l’analyse de code et la détection de failles, et dont le système de types n’a pas été conçu avec la testabilité à l’esprit.



  • Le parsing des entrées et des messages réseau est fait à la main plutôt que de s’appuyer sur un parser.



  • Le recours à de la programmation dynamique interdit la séparation des pages de code et de données.



  • Les états sont gérés manuellement plutôt que d’avoir recours à des outils déclaratifs et réactifs, ou à un éditeur graphique d’automate. Il n’y a aucune trace de déclaration d’invariants ni même de mécanismes pour en déclarer et les faire vérifier automatiquement. Seul le paradigme impératif est utilisé et autorisé même lorsqu’il est inadapté.



  • La concurrence est gérée manuellement sans aucune sémantique dédiée de haut niveau pour automatiser l’implémentation et valider la cohérence.









Jed08 a écrit :



Le code de Bash a été écrit dans les années 80 avec les standards des années 80 et n’a jamais été modifié.

Dans cet article, on a une petite vision de ce qu’il ne va pas dans le code.





Ho, putain, ceci est une perle. Certes, les gars code mieux que moi (il faut se l’avouer, j’ai rapidement lu les première ligne de grep.c, c’est lisible), mais c’est moche. Putain, ya certain truc qui aurait du jamais être open source quoi !





On me dit que l’on est pas vendredi… rooh!









Glyphe a écrit :



Il n’y a aucun vecteur d’attaque connu sur OSX actuellement avec ShellShock.

Sans parler du fait que 99% des Mac ne seront de toute façon jamais concerné par cette faille vu qu’extrêmement peu d’entre eux font tourner les services Unix nécessaire à pouvoir ensuite faire interpréter la variable par Bash.









Il suffit de double cliquer sur un fichier .sh, dans un spam par exemple, à vrai dire peu de gens savent ce que c’est et un paquet le feront sans hésiter.









Jed08 a écrit :



Le code de Bash a été écrit dans les années 80 avec les standards des années 80 et n’a jamais été modifié.

Dans cet article, on a une petite vision de ce qu’il ne va pas dans le code.





merci <img data-src=" />



Hello,



En parlant de Maverick, sait-on quand est-ce que la sortie est prévue?








Skruybutt a écrit :



Hello,



En parlant de Maverick, sait-on quand est-ce que la sortie est prévue?







Yosemite tu veux dire ?



A priori dans le semaines à venir, on en est à la build 8, ça devrait pas tarder, après Apple donne une conf sous peu aussi, il y a des chances que ce soit à cette occasion.









Zyami a écrit :



Il suffit de double cliquer sur un fichier .sh, dans un spam par exemple, à vrai dire peu de gens savent ce que c’est et un paquet le feront sans hésiter.





Je dis peut être une bétise, mais si un utilisateur clique sur un fichier “.sh”, il executera le script qu’il y ait la faille ou non, non ? <img data-src=" /><img data-src=" /><img data-src=" />



Maintenant remplacez Bash par Systemd et admirez le carnage








pentest a écrit :



Maintenant remplacez Bash par Systemd et admirez le carnage





c’est quoi le rapport entre Bash et Systemd ? L’un est un shell et l’autre s’occupe plutot du lancement de service <img data-src=" /> <img data-src=" />









Skruybutt a écrit :



Hello,



En parlant de Maverick, sait-on quand est-ce que la sortie est prévue?







Pour Yosemite, on parle d’une sortie fin octobre, comme l’année dernière pour Mavericks. Apple pourrait profiter d’une conférence pour lancer en me^me temps des nouveaux Mac mini et un iMac Retina.









Zyami a écrit :



Il suffit de double cliquer sur un fichier .sh, dans un spam par exemple, à vrai dire peu de gens savent ce que c’est et un paquet le feront sans hésiter.







J’ai testé sur plusieurs machines et par défaut l’utilisation de fichier avec extension .sh n’ouvre pas du tout le Terminal. (sans que l’utilisateur ne définisse lui-même la correlation entre extension .sh et Terminal)



Testé sous Mavericks et Yosemite.









Glyphe a écrit :



J’ai testé sur plusieurs machines et par défaut l’utilisation de fichier avec extension .sh n’ouvre pas du tout le Terminal. (sans que l’utilisateur ne définisse lui-même la correlation entre extension .sh et Terminal)



Testé sous Mavericks et Yosemite.







Ah oui, ça m’ouvre sublime text, je viens de voir.

Mea culpa.









Jed08 a écrit :



Dans cet article, on a une petite vision de ce qu’il ne va pas dans le code.







Il critique surtout la sémantique et certaines fonctions utilisées pour manipuler les chaines de caractères qui ne faciliteraient pas le travail des outils d’analyse automatique de vulnérabilité ou de ceux qui revoient le code.



Moi j’aurais tendance à penser qu’un outil d’analyse qui ne sait pas traiter un entête K&R est un mauvais outil. Franchement, c’est pas la mer à boire.



De même, l’utilisation de fonctions basées sur des listes variables de paramètres pour éviter des enchainements de strcat/strcpy et apparentés, a l’époque ou cela a été codé une liste variable d’éléments c’était un surcoût de cycles processeurs non négligeable. C’est certes moins fluide à lire, mais on pourrait opposer qu’une revue de code bien lisible et commentée s’apparente hélas plus à la lecture d’un roman: Beaucoup de problèmes sont alors loupés. D’ailleurs ceux qui en faisaient beaucoup me semblent en revenir: Ce type de job, c’est celui de bons outils. On en revient là.



Et faire de tels bons outils, cela pourrait être un job plus utile pour un sec-guy qu’un article de blog assassin.









yl a écrit :



Et faire de tels bons outils, cela pourrait être un job plus utile pour un sec-guy qu’un article de blog assassin.





Le problème c’est que de tels outils sont limités par le langage. L’arithmétique de pointeurs en C++ ou l’introspection (reflexion) en Java/C# (Field.Set, FieldInfo.SetValue), ou le typage dynamique en JS & co tendent à empêcher les outils d’analyse de pouvoir faire leur boulot correctement.



Ça gêne également le compilateur et ça empêche en prime le développement de plusieurs sémantiques de haut niveau qui nécessiteraient de transformer en profondeur le code pour être efficace (contraintes déclaratives, invariants, sémantique de sériabilité, etc).



Le jour où un outil sera capable de circonvenir ces limitations, alors cet outil pourra écrire le code lui-même selon tes spécifications verbales et interactives. C’est pas demain la veille alors en attendant il va falloir changer de langages.









HarmattanBlow a écrit :



Le problème c’est que de tels outils sont limités par le langage.







Oui, mais de là a dire que ne pas savoir traiter les paramètres d’une fonction C en mode K&R est excusable c’est un peu abuser.



Les outils automatiques garderont certes encore longtemps leur limites, leur paramétrage étant aussi important histoire de ne pas faire trop de faux positifs lassants (et potentiellement eux-mêmes inducteurs de bugs!). Tant mieux, on aura encore du boulot!



Mais bon, l’exemple n’est juste pas bon.









Zyami a écrit :



Yosemite tu veux dire ?



A priori dans le semaines à venir, on en est à la build 8, ça devrait pas tarder, après Apple donne une conf sous peu aussi, il y a des chances que ce soit à cette occasion.





<img data-src=" />



Exact, Yosemite&nbsp;<img data-src=" />. Merci pour vos réponses sur le hors sujet&nbsp;<img data-src=" />









Aphelion a écrit :



Pour Yosemite, on parle d’une sortie fin octobre, comme l’année dernière pour Mavericks. Apple pourrait profiter d’une conférence pour lancer en me^me temps des nouveaux Mac mini et un iMac Retina.





Merci&nbsp;<img data-src=" />









athlon64 a écrit :



c’est quoi le rapport entre Bash et Systemd ? L’un est un shell et l’autre s’occupe plutot du lancement de service <img data-src=" /> <img data-src=" />







haters gonna hate.

Les anti systemd communiquent beaucoup, ils ont monté un site web (sans intérêt, je n’ai pas le lien sous la main). Ça doit occuper, et une soirée troll doit bien valoir un soirée youporn (cette phrase pourrait-elle être validée comme «Inpactien certified»? <img data-src=" />).

La seule approche potentiellement constructive bien que trollesque, c’est un projet concurrent à systemd nommé uselessd, dont le principe est de reprendre le code de systemd, en enlevant tout ce qui ne plaît pas. Aux dernières nouvelles ils en avaient retiré assez pour que uselessd ne puisse pas servir de système d’init, aucune idée de la façon dont ça a évolué…





édit: m’enfin le package systemd fait bien plus que de l’init de services/daemons.

Perso je n’ai rien à redire sur journald par exemple, ce truc était nécessaire.

Globalement, AMHA systemd est plus complexe dans sa structure, mais nettement plus propre et plus puissant que InitV.









yl a écrit :



Oui, mais de là a dire que ne pas savoir traiter les paramètres d’une fonction C en mode K&R est excusable c’est un peu abuser.





A ressources limitées, vaut-il mieux améliorer le pouvoir prédictif de l’analyse ou supporter un obscur sous-point de la spécification du C rendu obsolète il y a trente-cinq ans ?



Alors non c’est pas la mer à boire mais entre une intervention sur un parser déjà bien chargé et les tests c’est déjà plusieurs jours de boulot. Moins s’ils ont utilisé un parser generator et que tout va bien, plus s’ils ont utilisé un parser generator et que la définition crée une ambiguïté insoluble sans abandonner l’outil tout entier. Et ne parlons même pas du cas où ils se seraient appuyés sur un compilateur tiers et open source qui aurait fait le choix de ne pas supporter cette norme dépréciée : dans ce cas le seul choix serait de maintenir un fork.









lateo a écrit :



haters gonna hate.

Les anti systemd communiquent beaucoup, ils ont monté un site web (sans intérêt, je n’ai pas le lien sous la main). Ça doit occuper, et une soirée troll doit bien valoir un soirée youporn (cette phrase pourrait-elle être validée comme «Inpactien certified»? <img data-src=" />).

La seule approche potentiellement constructive bien que trollesque, c’est un projet concurrent à systemd nommé uselessd, dont le principe est de reprendre le code de systemd, en enlevant tout ce qui ne plaît pas. Aux dernières nouvelles ils en avaient retiré assez pour que uselessd ne puisse pas servir de système d’init, aucune idée de la façon dont ça a évolué…





<img data-src=" />



<img data-src=" /> j’ai pas tout compris. Qu’est ce qui déplait dans Systemd ?



J’ai aucune idée de ce qui est utilisé sur ma Debian fraichement installé, mais mes démons se lancent bien <img data-src=" />.



C’était simplement pour dire que Systemd ca pue ? Parce que je vois pas le rapport entre un shell particulier et ce qui sert a lancer des services/démons









athlon64 a écrit :



<img data-src=" />



<img data-src=" /> j’ai pas tout compris. Qu’est ce qui déplait dans Systemd ?







Principalement : son auteur, sa personnalité (tendance mégalo visionnaire auto-proclamé).

Après c’est beaucoup de FUD, il y a très peu de bons arguments contre systemd.



La vérité c’est que ça change les usages et habitudes des admins, qui doivent réapprendre la gestion de l’init, des logs etc. Avec des changements comme ça, tu mets facilement 15 ans d’expertise système DTC au fond à droite, et la plupart des gens apprécient peu <img data-src=" />









lateo a écrit :



Principalement : son auteur, sa personnalité (tendance mégalo visionnaire auto-proclamé).

Après c’est beaucoup de FUD, il y a très peu de bons arguments contre systemd.



La vérité c’est que ça change les usages et habitudes des admins, qui doivent réapprendre la gestion de l’init, des logs etc. Avec des changements comme ça, tu mets facilement 15 ans d’expertise système DTC au fond à droite, et la plupart des gens apprécient peu <img data-src=" />





<img data-src=" /> ok je vois.



Actuellement c’est init qui est principalement utilisé ou Systemd ? parce que si ce dernier permet de faire du system init, mais que le truc useless(d) ne le permet pas, ca fait utiliser plus d’outils pour le même résultat <img data-src=" />









athlon64 a écrit :



Actuellement c’est init qui est principalement utilisé ou Systemd ?







init est progressivement mais massivement remplacé par systemd dans les distributions linux majeures.



uselessd, perso je pense que c’est juste un magnifique troll. Mais ça pourrait aussi (à terme et avec plein de réserves) servir de couche de compatibilité entre les linux “nouvelle génération / pur systemd” et les linux “old school” ou autres *bsd.









lateo a écrit :



init est progressivement mais massivement remplacé par systemd dans les distributions linux majeures.



uselessd, perso je pense que c’est juste un magnifique troll. Mais ça pourrait aussi (à terme et avec plein de réserves) servir de couche de compatibilité entre les linux “nouvelle génération / pur systemd” et les linux “old school” ou autres *bsd.





C’est Systemd qui permet de faire “service apache start” par exemple ?



Tant que ca fonctionne, ca m’importe peu celui utilisé <img data-src=" />









athlon64 a écrit :



C’est Systemd qui permet de faire “service apache start” par exemple ?



Tant que ca fonctionne, ca m’importe peu celui utilisé <img data-src=" />





oui, même si avec systemd, tu vas plutôt faire “systemctl start apache” <img data-src=" />









guildem a écrit :



oui, même si avec systemd, tu vas plutôt faire “systemctl start apache” <img data-src=" />





le service c’est grace à quoi ? <img data-src=" />



Je viens de voir que sur Mac OS X (SL) c’est directement apachectl









athlon64 a écrit :



le service c’est grace à quoi ? <img data-src=" />



Je viens de voir que sur Mac OS X (SL) c’est directement apachectl





La commande apachectl est présente sur tous les systèmes sur lesquels apache est installé, il n’a pas de rapport avec l’init :)



La commande service était utilisée par sysvinit, qui était présent avant systemd (et est encore présent par défaut sur debian, et quelques autres distributions).



Mais ya des paquets de compatibilité sur à peu près chaque distribution avec systemd, qui permettent d’imiter les commandes de sysvinit. Sur archlinux, ce paquet s’appelle systemd-sysvcompat par exemple.









guildem a écrit :



La commande apachectl est présente sur tous les systèmes sur lesquels apache est installé, il n’a pas de rapport avec l’init :)



La commande service était utilisée par sysvinit, qui était présent avant systemd (et est encore présent par défaut sur debian, et quelques autres distributions).



Mais ya des paquets de compatibilité sur à peu près chaque distribution avec systemd, qui permettent d’imiter les commandes de sysvinit. Sur archlinux, ce paquet s’appelle systemd-sysvcompat par exemple.





Ce que j’ai du mal a comprendre c’est pourquoi de plus en plus je vois le conseil d’utiliser service plutot que /etc/init.d/nom <img data-src=" /> alors que ca vient d’un truc plus vieux qui doit etre remplacé









athlon64 a écrit :



Ce que j’ai du mal a comprendre c’est pourquoi de plus en plus je vois le conseil d’utiliser service plutot que /etc/init.d/nom <img data-src=" /> alors que ca vient d’un truc plus vieux qui doit etre remplacé





Ca je ne saurai pas te dire, j’utilisais service avant de passer sur systemd sur archlinux, et je l’utilise toujours sur mes debian…



Et pour le moment, debian (qui est une des distributions serveur les plus utilisées) a toujours sysvinit, donc demande toujours l’utilisation de service. Mais sauf si je fais erreur, service appelle les fichiers de /etc/init.d… donc bon…



Ha et Ubuntu n’utilise ni sysvinit ni systemd, mais upstart. De base je crois que la commande d’upstart s’appelle initctl, cependant, upstart a aussi une compatibilité avec la commande service de sysvinit.









guildem a écrit :



Ca je ne saurai pas te dire, j’utilisais service avant de passer sur systemd sur archlinux, et je l’utilise toujours sur mes debian…



Et pour le moment, debian (qui est une des distributions serveur les plus utilisées) a toujours sysvinit, donc demande toujours l’utilisation de service. Mais sauf si je fais erreur, service appelle les fichiers de /etc/init.d… donc bon…



Ha et Ubuntu n’utilise ni sysvinit ni systemd, mais upstart. De base je crois que la commande d’upstart s’appelle initctl, cependant, upstart a aussi une compatibilité avec la commande service de sysvinit.



La prochaine Debian sera systemd avec une couche de compatibilité sysvinit, Ubuntu abandonne upstart pour passer sur systemd.





Il n’y a aucun vecteur d’attaque connu sur OSX actuellement avec ShellShock.





Ce qui n’est ni vraisemblable ni rassurant.



Passer des scripts au bash c’était chercher la fessée et c’est donc mérité.

Maintenant en ce qui concerne ce qui a été écrit dans les années 80 j’aimerais bien qu’on me sorte un seul OS qui a été réellement refondu depuis cette époque.

Les injections SQL et autres sont toujours d’actualité quasiment 10 ans après leur explosion.

Ensuite les systèmes GNU/LINUX/BSD sont toujours largement en avance aux points en ce qui concerne la sécurité par rapport aux autres OS du marché.



Après je pense que les “programmeurs” auraient besoin d’un bon cours de remise à niveau, partant de l’électronique numérique, et allant jusqu’à leur langage plutôt que de partir direct sur du PHP et de forcer l’utilisation d’un script bash sans comprendre réellement ce qui se passe en dessous.



Enfin je ne vais pas perdre mon temps à lister toutes les bonnes blagues de windows mais disons BLASTER!!! Qui m’a pourri la vie pendant plusieurs mois …









GutsBlack a écrit :



La prochaine Debian sera systemd avec une couche de compatibilité sysvinit, Ubuntu abandonne upstart pour passer sur systemd.





Tout à fait. De mon coté, je parlais surtout de l’existant, mais en effet, à part les xBSD et quelques distributions moins grand public (Gentoo et Slackware entre autres, ainsi qu’Android qui est un cas particulier d’utilisation du noyau Linux), il n’y aura plus vraiment de Linux sans systemd par défaut…









guildem a écrit :



Ca je ne saurai pas te dire, j’utilisais service avant de passer sur systemd sur archlinux, et je l’utilise toujours sur mes debian…



Et pour le moment, debian (qui est une des distributions serveur les plus utilisées) a toujours sysvinit, donc demande toujours l’utilisation de service. Mais sauf si je fais erreur, service appelle les fichiers de /etc/init.d… donc bon…



Ha et Ubuntu n’utilise ni sysvinit ni systemd, mais upstart. De base je crois que la commande d’upstart s’appelle initctl, cependant, upstart a aussi une compatibilité avec la commande service de sysvinit.





<img data-src=" /> merci pour les détails. Etant sous Debian Wheezy et ne voulant pas tester d’autres distrib (habitude et stabilité qui conviennent) je me sers donc toujours de service ou /etc/init.d, quand ils passeront je me renseignerai plus









athlon64 a écrit :



<img data-src=" /> merci pour les détails. Etant sous Debian Wheezy et ne voulant pas tester d’autres distrib (habitude et stabilité qui conviennent) je me sers donc toujours de service ou /etc/init.d, quand ils passeront je me renseignerai plus





Oui tu as le temps, comme l’a précisé GutsBlack, le prochain Debian aura systemd, mais tu pourras utiliser la couche de compatibilité pour ne pas te sentir perdu ! (et si tu aimes debian, pas besoin de changer, c’est super stable, même si c’est au prix d’appli un peu moins récentes)



Mais concrètement, on utilise comment la faille bash sans passer en cascade par une autre faille ?








guildem a écrit :



Oui tu as le temps, comme l’a précisé GutsBlack, le prochain Debian aura systemd, mais tu pourras utiliser la couche de compatibilité pour ne pas te sentir perdu ! (et si tu aimes debian, pas besoin de changer, c’est super stable, même si c’est au prix d’appli un peu moins récentes)





c’est avant pour un serveur de fichier/HTPC et XBMC peut etre compilé en version Gotham donc ca me suffit.



Debian, même pour du desktop, je trouve ca vraiment génial, au moins c’est stable et quand j’ai un truc qui plante c’est souvent à cause de drivers spécifique pour le Wifi sinon quasiment jamais de MAJ a faire et qui risquent de tout péter <img data-src=" />









Zulgrib a écrit :



Mais concrètement, on utilise comment la faille bash sans passer en cascade par une autre faille ?





je ne suis pas assez calé pour te l’expliquer par moi-même, mais ce billet LinuxFr est plutôt bien rédigé :

http://linuxfr.org/news/une-faille-nommee-shellshock









athlon64 a écrit :



c’est avant pour un serveur de fichier/HTPC et XBMC peut etre compilé en version Gotham donc ca me suffit.



Debian, même pour du desktop, je trouve ca vraiment génial, au moins c’est stable et quand j’ai un truc qui plante c’est souvent à cause de drivers spécifique pour le Wifi sinon quasiment jamais de MAJ a faire et qui risquent de tout péter <img data-src=" />





J’ai bien aimé en desktop à une époque, mais depuis 6 ans je me sens plutôt l’âme d’un aventurier, et archlinux était donc faite pour moi <img data-src=" />

De plus cette distribution, de part le besoin d’aller gratter et comprendre vraiment ce qu’il se passe, pour pouvoir l’utiliser, permet d’apprendre plein de choses intéressantes sur le fonctionnement interne des composants (logiciels et matériels). Si on aime ça (et qu’on a le temps, au moins pour la période d’adaptation), c’est vraiment super.

Mais si on ne veut pas s’embêter, et qu’on peut attendre un peu pour les nouveaux logiciels, ou comme toi compiler les rares cas de logiciels devant être à jour… debian est parfaite :)









guildem a écrit :



je ne suis pas assez calé pour te l’expliquer par moi-même, mais ce billet LinuxFr est plutôt bien rédigé :

http://linuxfr.org/news/une-faille-nommee-shellshock





Donc le problème vient du logiciel qui cause avec bash, pas bash lui meme au final, ce qu’ils nomment une faille est le fonctionnement prévu de bash. (selon l’article de ton lien)



Merci pour le lien.









guildem a écrit :



J’ai bien aimé en desktop à une époque, mais depuis 6 ans je me sens plutôt l’âme d’un aventurier, et archlinux était donc faite pour moi <img data-src=" />

De plus cette distribution, de part le besoin d’aller gratter et comprendre vraiment ce qu’il se passe, pour pouvoir l’utiliser, permet d’apprendre plein de choses intéressantes sur le fonctionnement interne des composants (logiciels et matériels). Si on aime ça (et qu’on a le temps, au moins pour la période d’adaptation), c’est vraiment super.

Mais si on ne veut pas s’embêter, et qu’on peut attendre un peu pour les nouveaux logiciels, ou comme toi compiler les rares cas de logiciels devant être à jour… debian est parfaite :)





Oui Arch je me suis trouvé bloquer a l’installe quand j’ai voulu essayer sur une VM et après j’ai laissé tomber <img data-src=" />



Debian me conviennait quand j’étais en dualboot avec OS X dans le but d’avoir un système qui démarre vite, en bouffant peu de ressources (juste pour MPD et Internet). Pour les logiciels, sauf rare cas, ce qu’il propose convient et au moins j’ai pas besoin de faire des MAJ tous les 4 matins (gros flemard inside). Seul problème que j’ai eu c’est en voulant passer en “rolling-release” sur Sid (si je dis pas de bêtise) <img data-src=" />



Et pour un HTPC/serveur de fichiers, ca ira parfaitement <img data-src=" />



Une fois de plus, APPLE laisse sur le bas-côté les versions anciennes d’OS X…

Si vous voulez compiler et installer les correctifs, c’est expliqué ici :



http://forum.macbidouille.com/index.php?showtopic=384027&st=60&p=3899854…








ungars a écrit :



Une fois de plus, APPLE laisse sur le bas-côté les versions anciennes d’OS X…

Si vous voulez compiler et installer les correctifs, c’est expliqué ici :



http://forum.macbidouille.com/index.php?showtopic=384027&st=60&p=3899854…





En même temps c’est Apple. Niveau sécurité ils font souvent ça par dessus la jambe.